*** zoli__ has joined #baserock | 04:45 | |
*** zoli__ has quit IRC | 05:15 | |
*** zoli__ has joined #baserock | 05:40 | |
*** mike has joined #baserock | 07:08 | |
*** mike is now known as Guest47315 | 07:08 | |
*** petefoth has joined #baserock | 07:27 | |
*** rdale has joined #baserock | 07:50 | |
*** a1exhughe5 has joined #baserock | 08:01 | |
*** fay_ has quit IRC | 08:30 | |
*** fay_ has joined #baserock | 08:31 | |
bjdooks | Hi, who do I need to prod to get a latest armv7be image? | 08:35 |
---|---|---|
bjdooks | baserock-8-armv7a-be.tar.bz2 last uploaded 15jul2013 | 08:35 |
persia | bjdooks: I think you need someone from ops, but I think they stopped uploading things for which there were not public distbuild clusters & cache. | 08:36 |
*** CTtpollard has joined #baserock | 08:36 | |
persia | I know that at least a couple of them have some Jetsons around, so it might be possible for one of them to bring it up to date. | 08:37 |
persia | Actually, it's probably important to do that: I don't think that a tarball that old can be used to build a current one. | 08:42 |
bjdooks | tftpboot 0x3000000 zybo.be; tftpboot 0x3800000 zynq-zybo.dtb; bootm 0x3000000 - 0x3800000 | 08:54 |
*** jonathanmaw has joined #baserock | 08:55 | |
persia | Is that the BE environment booting on the Zynq hybrid ARM/FPGA board? | 08:55 |
bjdooks | yes | 08:55 |
persia | Nifty! I've seen a couple designs using that chip, but nothing with a traditional userspace. | 08:56 |
bjdooks | 4 files changed, 25 insertions(+), 17 deletions(-) | 08:56 |
bjdooks | of which part of that is already in net-next | 08:56 |
bjdooks | Linux vexpress-tc2 4.0.0-rc3-00003-gfac9018 #15 SMP Mon Mar 16 08:43:14 GMT 2015 armv7b GNU/Linux | 08:58 |
bjdooks | just rebased to -rc4 | 08:59 |
*** bashrc has joined #baserock | 09:02 | |
*** mdunford has joined #baserock | 09:07 | |
*** gary_perkins has joined #baserock | 09:23 | |
*** gfinney has joined #baserock | 09:33 | |
wdutch | I've just made a clean definitions branch but it's failing at stage1-gcc build-commands | 09:56 |
*** ssam2 has joined #baserock | 09:57 | |
*** ChanServ sets mode: +v ssam2 | 09:57 | |
wdutch | http://paste.baserock.org/tilexumeve | 09:59 |
persia | wdutch: Could you share a bit more context? | 10:00 |
wdutch | persia: I'm trying to build base-system-x86_64-generic, it goes splat at stage1-gcc build-commands, should I paste the whole output? | 10:04 |
*** lachlanmackenzie has joined #baserock | 10:08 | |
*** Krin has joined #baserock | 10:10 | |
ssam2 | wdutch: just the last 100 or so lines would be fine | 10:12 |
ssam2 | what you have there is a series of messages from nested 'make' instances going 'something failed in a subprocess', but it doesn't contain the original error message | 10:13 |
radiofree | what happens to the build log when a chunk fails? | 10:13 |
*** edcragg has joined #baserock | 10:13 | |
ssam2 | it goes in morph.log with something like 'ERROR LOG FROM FAILED BUILD' prefixed to each line | 10:13 |
radiofree | ah | 10:15 |
*** pacon has joined #baserock | 10:15 | |
wdutch | http://paste.baserock.org/uridixufus | 10:16 |
radiofree | that's a bit unwieldy, could it also be copied to the failed staging area? | 10:16 |
ssam2 | no reason why not | 10:16 |
ssam2 | wdutch: looks like `makeinfo` is failing with an error | 10:17 |
ssam2 | i've no idea why. maybe we updated it recently? | 10:17 |
ssam2 | seems we updated texinfo on 3rd feb, but surely we'd have hit this issue already if that was the cause | 10:18 |
radiofree | i recompiled stage1-gcc several times last week, on arm though | 10:20 |
rdale | maybe the version of texinfo on the host hasn't been updated since then? | 10:21 |
radiofree | i have 5.2 on my 15.10 host | 10:22 |
pedroalvarez | I wonder why anyone making a clean definitions branch is building gcc-stage1 | 10:22 |
persia | wdutch: what are you using as a cache server? | 10:23 |
wdutch | pedroalvarez: maybe I'm using that term wrongly, I've just checked out definitions and hav made no modifications | 10:23 |
wdutch | persia: how can I find that out? | 10:24 |
persia | Look at your morph.conf | 10:24 |
pedroalvarez | /etc/morph.conf | 10:24 |
SotK | wdutch: check if is artifact-cache-server set in your morph.conf? | 10:24 |
wdutch | artifact-cache-server = http://cache.baserock.org:8080/ | 10:24 |
persia | That makes it especially strange that you would need to rebuild that, unless something else is odd. | 10:25 |
petefoth | wdutch: or /src/morph.conf if you followed the steps in http://wiki.baserock.org/quick-start/ | 10:25 |
persia | wdutch: Try building an unmodified reference system. | 10:25 |
SotK | wdutch: are you using latest morph? | 10:26 |
straycat | i think connectivity issues might be involved | 10:26 |
straycat | morph only attempts one cache lookup, if that fails then it will fallback to a build | 10:26 |
* straycat got a ERROR: <urlopen error [Errno 111] Connection refused> this morning whilst morph was doing a cache lookup | 10:27 | |
pedroalvarez | there are log's entries of someone trying to fetch stage1-gcc, but a version that is not present in the cache server | 10:28 |
straycat | then again, if it's connectivity it would likely just work on a second attempt | 10:30 |
* SotK wonders if wdutch is using an old version of morph | 10:30 | |
wdutch | I'll try reinstalling morph | 10:31 |
pedroalvarez | wdutch: these instructions would be enough: http://wiki.baserock.org/using-latest-morph/ | 10:32 |
wdutch | pedroalvarez: thanks | 10:33 |
pedroalvarez | anyway, if morph is not complaining about missing "build-depend" fields, then is a recent enough version of morph | 10:33 |
pedroalvarez | or an old version of definitions | 10:33 |
persia | What could have happened to morph that upgrading would fix it? | 10:33 |
persia | Because for nearly any answer, we ought consider that a bug, and revert it. | 10:33 |
SotK | cache key algorithm may have changed, but I doubt it since its a while since it did | 10:34 |
persia | Yes, but we should revert that. | 10:34 |
persia | We should never change it without changing the key in the code to indicate it changed. | 10:34 |
SotK | which key is that? | 10:36 |
* SotK is probably confused | 10:37 | |
persia | No, rather, I haven't been following the code closely. | 10:39 |
persia | At one point in the past, we had a version string for the way we calculated cache keys, which I thought was in CacheKeyComputer, but looking at the code in blob c3a01b9ed87b6db90c5b93909421d335c2e127bc , I don't see it anymore. | 10:40 |
ssam2 | there is a versioning field *in* the cache key | 10:41 |
ssam2 | but changing that causes cache keys to change. there's nothing at present that could tell a user 'warning: cache keys are different now' | 10:42 |
ssam2 | i'm not sure how that would even work | 10:42 |
paulsherwood | me neither | 10:46 |
*** pacon has quit IRC | 10:47 | |
ssam2 | persia: I agree that it'll be worrying if upgrading morph causes wdutch's problem to magically go away, though | 10:47 |
wdutch | it didn't | 10:47 |
*** pacon has joined #baserock | 10:48 | |
ssam2 | wdutch: if you've got time to debug, try cloning gcc-tarball.git somewhere in your baserock devel system and building it manually | 10:49 |
ssam2 | using the same configure and build-commands that the stage1-gcc.morph uses | 10:49 |
ssam2 | if it that succeeds, then morph is doing something weird. if it fails, something is broken in your baserock system (and possibly all of them) | 10:50 |
ssam2 | or something is up with stage1-binutils, but given that it's 'makeinfo' failing, that seems unlikely | 10:51 |
wdutch | I'll give it a go | 10:51 |
persia | It would be really cool if morph had a subcommand to process a chunk morphology against the current working directory to ease this sort of replication. | 10:51 |
petefoth | persia: why not create story for that? | 10:52 |
persia | Because I have a very hairy yak standing between me and storyboard.baserock.org today :( But I'll put it on my list. | 10:53 |
petefoth | :) | 10:54 |
*** pacon2 has joined #baserock | 10:59 | |
mwilliams_ct | ssam2: I'm having a look at the openid error when used with storyboard today ("I could not reach..."). Trying to deploy a development instance, but packer seems to take a long time "pulling docker image fedora 20". is this expected? | 11:01 |
mwilliams_ct | long time ~30 minutes and still going | 11:02 |
*** pacon has quit IRC | 11:02 | |
ssam2 | cool, thanks for looking it | 11:02 |
ssam2 | I've kind of stopped using 'docker' for developing these systems | 11:02 |
pedroalvarez | wdutch: I'd be intereseted on the sha1 of definitions.git you are using, and `morph --version` sha1 | 11:02 |
ssam2 | mwilliams_ct: I just deploy them straight to openstack now | 11:03 |
ssam2 | so might be easier for you to do the same | 11:03 |
mwilliams_ct | ssam2: OK, I'll give that a try thanks. I'll try and add a separate patch to README.mdwn if that goes well while I'm at it | 11:03 |
mwilliams_ct | cheers | 11:03 |
ssam2 | also, Packer is quite fiddly, feel free to work around it. I thought it might be better than `morph deploy`, but it's actually just equally annoying in different ways | 11:03 |
ssam2 | thanks, updating the readme would be cool (just removing the 'development' instructions might make sense) | 11:04 |
ssam2 | also, note that infrastructure.git embeds a copy of django_openid_provider and has a couple of fixes that aren't upstream. this isn't ideal, but upstream doesn't seem very active and there are several equally inactive forks, so I've not been too motivated to persue upstreaming things so far | 11:07 |
*** jonathanmaw has quit IRC | 11:07 | |
mwilliams_ct | much obliged, I'll poke you if I get stuck (but hopefully not too much ;) ) | 11:07 |
*** jonathanmaw has joined #baserock | 11:09 | |
jjardon | Hey, in case anyone is interested, I've just found this app to track our gerrit instance from your phone: Mgerrit | 11:23 |
wdutch | from my baserock VM in kvm I can git clone and ssh but I can't ping the outside world, is this normal? I set it up following this guide http://wiki.baserock.org/guides/vm-setup/#index4h2 | 11:30 |
richard_maw | wdutch: running it directly with kvm like that blocks the ping protocol. | 11:31 |
* richard_maw generally recommends the virt-manager approach instead of direct kvm | 11:31 | |
*** XuLiu has joined #baserock | 11:32 | |
rjek | +! | 11:34 |
rjek | 1 | 11:34 |
*** CTtpollard has quit IRC | 11:44 | |
*** CTtpollard has joined #baserock | 11:46 | |
*** wschaller has joined #baserock | 12:04 | |
jjardon | ssam2: some patches in gerrit already have a +2; is there anything I can do to merge them? | 12:33 |
ssam2 | when you say +2, what do you mean? | 12:35 |
ssam2 | a +2, or multiple +1's ? | 12:35 |
ssam2 | in Gerrit's world 1+1 doesn't make +2 | 12:35 |
*** pacon2 has quit IRC | 12:37 | |
jjardon | ssam2: +2 | 12:42 |
jjardon | (given by you IIRC) | 12:42 |
ssam2 | oh, you should just be able to click the 'Submit' button | 12:43 |
ssam2 | if you see it | 12:43 |
ssam2 | it's hidden if you can't click it | 12:43 |
jjardon | oh, ok, I just found it, thanks! | 12:45 |
*** a1exhughe5 has quit IRC | 13:03 | |
*** mdunford has quit IRC | 13:17 | |
*** a1exhughe5 has joined #baserock | 13:18 | |
*** mdunford has joined #baserock | 13:21 | |
straycat | ssam2, thanks for merging the fix, though i hadn't done the fixup richard_maw suggested, in practice it can't be triggered but probably still worth making the fix | 14:00 |
ssam2 | oh, thanks for pointing that out | 14:02 |
straycat | as for the git@ thing, it works without it, but should also work with, i have a habit of specifying it because you can't tell from the url whether it's a mercurial repo or a git repo | 14:02 |
ssam2 | ok. seemed not to work for me, but i didn't leave it very long | 14:02 |
* straycat probably should have acted sooner but was a little preoccupied | 14:02 | |
ssam2 | i'll do the msg= fix directly in master, since i was going to do it at merge time anyway | 14:03 |
straycat | :) thanks | 14:03 |
straycat | *because otherwise | 14:05 |
richard_maw | straycat: in practice it's very unlikely to be triggered, but you could trigger it by having a filename with a % character in it, which is perfectly legal | 14:15 |
straycat | ahh yes that's true :/ forgot we had filenames in the key | 14:22 |
straycat | someone could put a % in the repo too if they wanted | 14:25 |
richard_maw | probably ref too | 14:30 |
straycat | ahh but it's a sha by that point i think | 14:30 |
ssam2 | krin: does zookeeper require Gerrit ? | 15:02 |
ssam2 | oh, never mind | 15:02 |
ssam2 | was wondering why github:franred/gerrit-installation-binaries appeared in the zookeeper stratum, but it's because it needs JAva | 15:03 |
franred | ssam2, yep, it is just for that | 15:04 |
ssam2 | franred: i'm planning on sending a patch to remove gerrit from definitions.git, I hope you don't mind :) | 15:04 |
ssam2 | i don't think we need it now it's in infrastructure.git | 15:04 |
franred | ssam2, I don't mind, but java is required for zookeeper so I imagine you are not going to be able to rid off the github reference | 15:05 |
ssam2 | yeah :( | 15:05 |
franred | unless until we are able to bootstrap Java | 15:05 |
* ssam2 discovers that Gerrit lets you easily diff the second version of a patch against the first version of a patch | 15:07 | |
CTtpollard | nice | 15:08 |
petefoth | My '[PATCH] Add link to Import Tool wiki pages' patch for Import Tool now has 2 * +1s. Do I need to do anything further to get it merged (other than wait for someone with commit access to get a round tuit)? | 15:11 |
ssam2 | just remind people to do it | 15:14 |
ssam2 | i'll do it | 15:15 |
ssam2 | perhaps you can thank me by submitting your next patch through gerrit.baserock.org instead | 15:15 |
pedroalvarez | :) | 15:16 |
petefoth | ssam2: thanks. My post was intended as a 'reminder' :) Registering with Gerrit is on my to-do list (submitting more patches *isn't yet though). | 15:17 |
petefoth | How hard would it be to allow gerrit to be used (optionally) for reviewing possible changes to wiki.baserock.org? I think that could be useful if we wanted to have a tracked discussion about proposed 'specification' pages such as the one I sent recently. I think that gerrit is a better way of tracking such discussions than the ML (though I recognise that others may not agree). | 15:20 |
CTtpollard | It sounds possible | 15:22 |
*** zoli__ has quit IRC | 15:27 | |
*** zoli__ has joined #baserock | 15:27 | |
bashrc | searching for a missing cluster: baserock-firehose/baserock-firehose.morph | 15:28 |
pedroalvarez | nothing like that in master. Maybe in another branch/repo? | 15:33 |
bashrc | checking | 15:33 |
*** wschaller_ has joined #baserock | 15:36 | |
bashrc | appears here: perhaps it was never added http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/firehose.git/tree/README?h=baserock/lauren/firehose | 15:38 |
ssam2 | petefoth: not impossible, we could use gerrit-replication to push changes to branchable after they're reviewed in Gerrit | 15:38 |
*** wschaller has quit IRC | 15:38 | |
persia | The difficulty with using gerrit for wiki edits is that there's a good chance some other wiki edit happened (e.g. from a browser) in the meantime, potentially causing merge issues. | 15:40 |
petefoth | ssam2: I think it would be worth doing but, even if others agree, I don't think there's any great rush. It can probably wait until the next time the OPs team don't have enough to do :) | 15:40 |
persia | If we did do that, I'd prefer no merge automation: just using gerrit for discussion and manual merge (unless we're willing to remove all web-edit features). | 15:40 |
ssam2 | when you mean 'merge automation', do you mean disable the 'Submit' button in Gerrit? | 15:41 |
ssam2 | or something else? | 15:41 |
petefoth | persia: I don't think it's often that people will be changing the same parts of the same pages, but I may be wropng about that. I don't feel strongly about the merge, but I think you are correcxt that it shouldn't happen automatically on receprt fo a +2 | 15:41 |
persia | ssam2: I mean anything that causes gerrit to try to push a merged branch to branchable. The Submit button is part of that. | 15:42 |
ssam2 | ok. | 15:42 |
petefoth | I think we *should* have a 'Submit' button, so that gerrit can do the grunt work of the merge | 15:42 |
persia | petefoth: I agree it's not often, but I think the chance is increased if there is an ongoing review for a couple days. And although rare, I have had to resolve merge conflicts with the baserock wiki in the pat. | 15:42 |
petefoth | nut I don't hink we need to agree on that now :) | 15:43 |
bashrc | I think the final decision would always be manual | 15:43 |
persia | As long as we allow non-reviewed changes, I agree. | 15:43 |
petefoth | bashrc: agreed | 15:43 |
petefoth | persia: oh definitely! I would only envisage using it for stuff where the author thinks "we really need some agreement on this before it goes live' | 15:44 |
persia | petefoth: Makes sense. I just don't trust automation to get merges right in that sort of timeframe. | 15:45 |
petefoth | persia: I agree - technology? Just say 'No!' ;) | 15:47 |
*** zoli__ has joined #baserock | 16:03 | |
jjardon | ssam2: thanks for the reviews | 16:41 |
jmacs | I can't seem to sign into gerrit using my Google account; should that work? | 16:42 |
ssam2 | no, it's limited to http://openid.baserock.org/ | 16:45 |
ssam2 | richard_maw: how do you feel about jjardon's v3 simple-network patch? it'd be really handy to have it merged for some work I'm doing | 16:53 |
* jjardon finds gerrit much better to send/review different versions of patch series | 16:53 | |
persia | jjardon: The main complaint about this when gerrit was first proposed was the need for Change-ID:, and that it meant that if you pushed, you needed to update your local copy to gain the Change-ID:. How do you find this workflow? | 16:54 |
richard_maw | ssam2: ok, I'll take a look | 16:56 |
wdutch | I've heard that somebody made a stratum of GNU utilities but I can't find it in definitions or an obvious branch, does anybody remember anything about it? | 16:56 |
jjardon | persia: there is a hook that do that for me, so I basically dont care about the Change-ID line :) | 16:56 |
jjardon | wdutch: coreutils? | 16:56 |
persia | jjardon: Heh, cool. | 16:57 |
*** XuLiu has quit IRC | 16:59 | |
wdutch | jjardon: if that's it it's not what I need, I was wondering if there was a GNU grep, I git grepped GNU grep but didn't see anything, I was told it might be helpful | 16:59 |
mwilliams_ct | wdutch: are you just going for maximal alliteration there? | 17:00 |
wdutch | mwilliams_ct: I think I broke out into jazz improve there | 17:01 |
mwilliams_ct | :-) | 17:01 |
wdutch | lol at herbal aromas | 17:02 |
pedroalvarez | wdutch: do you really need GNU grep? | 17:02 |
wdutch | pedroalvarez: I do it's a dependecy for what I'm building | 17:03 |
pedroalvarez | if so, you can try to send a patch to add it to coreutils? | 17:03 |
wdutch | will do | 17:03 |
*** a1exhughe5 has quit IRC | 17:03 | |
pedroalvarez | looks like we have it already lorried : http://git.baserock.org/cgi-bin/cgit.cgi/delta/grep.git/ | 17:03 |
wdutch | pedroalvarez: that one has a lot of prereqs, I was hoping to mirror the tarball which has fewer | 17:04 |
jjardon | wdutch: in general, Its prefereable to lorry (and build) from git repos instead tarballs | 17:05 |
* jjardon remembered we should move tar to the coreutils stratum as well | 17:06 | |
richard_maw | jjardon: biff | 17:07 |
richard_maw | ssam2: ^ I guess | 17:07 |
jmacs | OK, got logged into gerrit now. Is the idea that replies on gerrit will get emailed to baserock-dev eventually? | 17:08 |
jjardon | dont think so. To the author and the people that is watching the specific project only | 17:09 |
ssam2 | hmm, not to baserock-dev | 17:09 |
ssam2 | it doesn't send any emails right now though, which is a known issue. | 17:09 |
ssam2 | would be too noisy to send them to baserock-dev I think | 17:10 |
ssam2 | thanks richard_maw! jjardon: do you have time to do the fixes richard asked for? | 17:11 |
ssam2 | i can maybe tomorrow if not | 17:11 |
jmacs | Doesn't that mean baserock-dev contains a partial view of the patch's progress, then? | 17:11 |
* richard_maw has applied his usual disclaimer that he doesn't require nit-picks to be taken care of before merge | 17:12 | |
jjardon | ssam2: I have | 17:13 |
pedroalvarez | jmacs: well, gerrit won't contain patches anymore when we move to it (if we move) | 17:15 |
ssam2 | you mean baserock-dev won't contain patches any more | 17:15 |
pedroalvarez | yes | 17:15 |
ssam2 | jmacs: yes, patch review is split between baserock-dev and gerrit.baserock.org now | 17:15 |
jmacs | Oh, that's fine then. I thought gerrit was going to continue alongside the mailing list. | 17:16 |
ssam2 | I hope not. I thought it'd be too disruptive to force everyone onto gerrit right away, but unless people strongly object i'll disable push access to git.baserock.org/baserock/* in a few weeks | 17:17 |
*** jonathanmaw has quit IRC | 17:23 | |
*** gfinney has quit IRC | 17:28 | |
*** gary_perkins has quit IRC | 17:31 | |
*** ssam2 has quit IRC | 17:35 | |
*** Krin has quit IRC | 17:43 | |
*** bashrc has quit IRC | 17:52 | |
*** Guest47315 has quit IRC | 18:06 | |
*** rdale has quit IRC | 18:21 | |
*** mdunford has quit IRC | 18:32 | |
*** zoli__ has quit IRC | 18:36 | |
*** edcragg has quit IRC | 18:41 | |
*** mdunford has joined #baserock | 18:45 | |
*** wschaller_ has quit IRC | 19:01 | |
*** lachlanmackenzie has quit IRC | 19:02 | |
*** mdunford has quit IRC | 19:25 | |
*** zoli__ has joined #baserock | 20:01 | |
*** zoli__ has quit IRC | 20:08 | |
*** zoli__ has joined #baserock | 20:27 | |
*** zoli__ has quit IRC | 21:30 | |
*** gfinney has joined #baserock | 22:56 | |
*** radiofree is now known as justache | 23:56 | |
*** justache is now known as radiofree | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!