| paulsherwood | rdale: http://paste.baserock.org/iyivunonop | 04:25 |
|---|---|---|
| paulsherwood | weird | 04:25 |
| *** zoli__ has joined #baserock | 05:39 | |
| *** zoli__ has quit IRC | 06:26 | |
| *** zoli__ has joined #baserock | 06:54 | |
| *** a1exhughe5 has joined #baserock | 07:00 | |
| *** mike has joined #baserock | 07:03 | |
| *** mike is now known as Guest75236 | 07:04 | |
| *** Albert has joined #baserock | 07:38 | |
| *** gary_perkins has joined #baserock | 07:48 | |
| *** franred has joined #baserock | 07:56 | |
| *** jonathanmaw has joined #baserock | 07:59 | |
| *** bashrc has joined #baserock | 08:03 | |
| *** mariaderidder has joined #baserock | 08:34 | |
| wdutch | baserock-chroot refers to the directory where the chroot lives in /opt/baserock/chroot as 'name' in some places and 'tag' in others. I'd like to sort this out and use the same term everywhere. I think refering to the 'name' of a chroot makes the most sense, what do people think? | 08:40 |
| *** Guest75236 has quit IRC | 08:45 | |
| radiofree | can you also fix it so you don't have to install in /opt? | 08:47 |
| DavePage | radiofree: You'd like to opt out of that? | 08:47 |
| * wdutch reads the makefile | 08:48 | |
| radiofree | DavePage: http://i.imgur.com/DUyiCbE.gif | 08:49 |
| wdutch | /opt is hardcoded, this needs fixing | 08:49 |
| pedroalvarez | guys, we have too many branches in definitions.git. I've just cleaned those that were under my namespace, can others do the same and clean the repo a bit today? | 08:54 |
| pedroalvarez | It's really relaxing, I promise :) | 08:55 |
| tlsa | pedroalvarez: on git.b.o or on gerrit, or both? | 08:58 |
| pedroalvarez | g.b.o | 08:59 |
| pedroalvarez | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/refs/heads | 08:59 |
| pedroalvarez | tlsa: you only have 2 :) well done | 08:59 |
| *** Guest75236 has joined #baserock | 08:59 | |
| pedroalvarez | tlsa: well, you have some more under mikedrake and michaeldrake | 09:00 |
| tlsa | pedroalvarez: 2 under tlsa, but a whole load under michaeldrake | 09:00 |
| tlsa | I'll attend to them later | 09:00 |
| pedroalvarez | tlsa: note that you can keep whatever you want | 09:00 |
| tlsa | mm | 09:00 |
| pedroalvarez | this is more like: remove the branches that were merged | 09:01 |
| tlsa | yep | 09:01 |
| * pedroalvarez just removed 30 or so | 09:01 | |
| *** ssam2 has joined #baserock | 09:02 | |
| *** ChanServ sets mode: +v ssam2 | 09:02 | |
| SotK | I'm seeing an error from Babel when I try to get a list of the running jobs from Zuul: http://paste.baserock.org/calukuluza | 09:08 |
| SotK | the advice it gives doesn't work, as that tries to download a zip file from somewhere | 09:09 |
| SotK | does anyone have a suggestion on the neatest way to fix this? | 09:09 |
| pedroalvarez | hm.. | 09:10 |
| pedroalvarez | previously we have done: | 09:11 |
| pedroalvarez | - Run the command, and commit&push the result to a branch | 09:11 |
| pedroalvarez | - Build from tarball if the tarball has those data files | 09:11 |
| *** edcragg has joined #baserock | 09:12 | |
| *** Krin has joined #baserock | 09:12 | |
| ssam2 | SotK: yeah, it depends on the nature of the .zip file | 09:12 |
| ssam2 | if it's something that rarely changes, it'd be ok in my opinion to commit it on a branch in the babel.git repo | 09:12 |
| ssam2 | if it changes a lot, and is generated somehow, it's probably worth the effort to find out how it's meant to be generated | 09:13 |
| jmacs | Does either morph or cache.baserock.org keep statistics on cache hits & misses? | 09:16 |
| radiofree | franred looks like the worst offender | 09:17 |
| * SotK investigates further | 09:17 | |
| radiofree | or maybe javier | 09:17 |
| franred | radiofree, me? ahhh regarding the number of branches in definitions? | 09:17 |
| radiofree | yep :) | 09:18 |
| * SotK also has many, I'll clean up later | 09:19 | |
| * richard_maw cleaned up all but his sshfs branch, which he'd like to revive some day | 09:20 | |
| ssam2 | jmacs: neither, I think | 09:21 |
| ssam2 | jmacs: there may be something going on involving 'atime' that i'm forgetting about | 09:21 |
| jmacs | ssam2: OK, I'll think about adding some then! | 09:21 |
| ssam2 | jmacs: `morph gc` has some kind of heuristic for detecting what chunks are least used, that's about it | 09:22 |
| ssam2 | jmacs: nice! | 09:22 |
| pedroalvarez | jmacs: cache.baserock.org has a log from were we can extrac that info I believe | 09:22 |
| jmacs | Just the httpd logs would do the job, I think - but don't worry about it for now | 09:25 |
| pedroalvarez | ok, let me know if you want to take a look at those logs | 09:27 |
| *** pacon has joined #baserock | 09:47 | |
| wdutch | are branches always necessary for gerrit? I only want to change one word in an echo command | 09:48 |
| jmacs | franred: Java is mentioned on the "Doing stuff with Baserock" page. I assume you mean OpenJDK? Any particular version? | 09:48 |
| ssam2 | jmacs: I don't see franred today. It was actually me that added him to that page as he mentioned it in the past ;) | 09:49 |
| richard_maw | AIUI a complicated circular dependency bootstrapping problem prevented us having a proper java bootstrap | 09:50 |
| ssam2 | jmacs: the hardest part is bootstrapping it, as all Java implementations seem to be implemented in Java, indeed. | 09:50 |
| richard_maw | but they're supposed to have fixed that with the latest major version | 09:50 |
| ssam2 | jmacs: is OpenJDK 8 the "best" available Java? I don't know much about it | 09:51 |
| SotK | ssam2: I pushed my mason branch: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/log/?h=baserock/adamcoldrick/mason-2015 | 09:53 |
| jmacs | ssam2: That's what I'm looking at now - the build instructions for OpenJDK seem to require the Oracle commercial JDK to bootstrap it. | 09:54 |
| franred | jmacs, I was having a look time ago, and as ssam2 said I was looking at OpenJDK 8 but when I looked at it I think it still required some java binaries | 09:54 |
| ssam2 | jmacs: right. | 09:55 |
| richard_maw | Kinnison did a lot of research into this, perhaps you could ask him for more details? | 09:55 |
| ssam2 | jmacs: which of course is possible, but if we have to have the JDK binary available in order to bootstrap a Baserock system, it kind of defeats the point a bit for me | 09:55 |
| ssam2 | jmacs: since one can also just download the JDK binary and use that directly, as we do now for https://gerrit.baserock.org/ | 09:55 |
| ssam2 | shall I create a storyboard story with this info? | 09:56 |
| *** flatmush has quit IRC | 09:56 | |
| jmacs | Oh, storyboard, forgot about that | 09:56 |
| ssam2 | a wiki page is fine if you prefer, just something that can be linked to from the 'doing stuff with baserock' page so this info isn't lost | 09:57 |
| *** flatmush has joined #baserock | 09:57 | |
| jmacs | Yep | 09:58 |
| *** robtaylo1 is now known as robtaylor | 10:04 | |
| * straycat will delete everything under baserock/richardipsum | 10:09 | |
| pedroalvarez | doesn't have to be everything, just whatever has been merged | 10:10 |
| pedroalvarez | thanks guys! It's getting cleaner :) | 10:10 |
| ssam2 | SotK: I've made a bunch of changes to https://storyboard.baserock.org/#!/story/8 ("continuous build and test") | 10:14 |
| pedroalvarez | I wonder how would be better a patch to upgrade all the components needed for openstack kilo | 10:15 |
| * straycat does the same for morph while he's there | 10:16 | |
| pedroalvarez | great thanks! | 10:16 |
| ssam2 | SotK: i've added it to http://wiki.baserock.org/doing-stuff-with-baserock/ as well | 10:16 |
| SotK | ssam2: thanks, looks good | 10:17 |
| pedroalvarez | would be acceptable to upgrade 30 chunks in one comit? | 10:17 |
| richard_maw | it would be ok IMO | 10:18 |
| pedroalvarez | right | 10:18 |
| pedroalvarez | I think I'd prefer that rather than 30 commits upgrading 1 chunk | 10:19 |
| * pedroalvarez continues squashing | 10:19 | |
| * SotK would definitely prefer 1 commit to 30 commits | 10:22 | |
| * SotK is reminded of duck sized horses vs horse sized ducks | 10:22 | |
| * richard_maw now has the duck song stuck in his head | 10:23 | |
| straycat | which duck song? | 10:23 |
| Kinnison | better than the llama song | 10:23 |
| *** ssam2 has left #baserock | 10:24 | |
| richard_maw | straycat: https://www.youtube.com/watch?v=MtN1YnoL46Q | 10:27 |
| mwilliams_ct | how do people even find videos like that? | 10:28 |
| Zara | through you? | 10:29 |
| straycat | oh i've seen that one before actually | 10:30 |
| *** ssam2 has joined #baserock | 10:30 | |
| *** ChanServ sets mode: +v ssam2 | 10:30 | |
| radiofree | is it safe to delete factory? | 10:31 |
| radiofree | i'll still be able to do upgrades right? | 10:31 |
| * Kinnison is actually unsure -- worth checking the upgrade path to see if you can specify a basis version? | 10:32 | |
| richard_maw | I think it uses the current version these days, rather than the factory version as the basis | 10:32 |
| pedroalvarez | radiofree: I removed factory yesterday and upgraded the system later | 10:32 |
| radiofree | thanks | 10:32 |
| * radiofree moves his / to the ssd to avoid this in the future | 10:33 | |
| ssam2 | i've created an initial story for 'firehose' as well: https://storyboard.baserock.org/#!/story/44 | 10:35 |
| mwilliams_ct | chatting to jjardon yesterday, I believe he was working on a write extension for jffs2. he's away for a few days, so I thought i'd have a look at where he was up to. Does anybody know where he's likely to have pushed any work he's done? | 10:36 |
| ssam2 | mwilliams_ct: no idea, but you could look through the branches with 'jjardon' in their name that are in definitions.git and morph.git | 10:39 |
| mwilliams_ct | on g.b.o? | 10:39 |
| ssam2 | I know that he uses storyboard so that might give you a clue (but it doesn't track branch names unless you post them in a comment, so maybe it won't be helpful) | 10:39 |
| ssam2 | mwilliams_ct: yes, probably | 10:39 |
| mwilliams_ct | Storyboard is a good idea too, thanks ssam2 :) | 10:40 |
| jmacs | Kinnison: Did you look into OpenJDK? Were there any results I could add to the baserock wiki? | 10:41 |
| Kinnison | jmacs: I started to try and work out how to bootstrap OpenJDK | 10:41 |
| Kinnison | jmacs: there's approaches involving eclipse's compiler and some other stuff, but bootstrapping from zero java support I hadn't gotten to | 10:42 |
| Kinnison | jmacs: there are guides out there, but I'd not had enough time | 10:45 |
| jmacs | Indeed, I'm sure I'll get to them | 10:46 |
| Kinnison | Sadly, similarly to Haskell, they expect you to have a previous JDK | 10:46 |
| richard_maw | what was it you needed to do to see more than 10 stories on storyboard? | 10:50 |
| Kinnison | ssam2: Any chance you can get the proper SSL certificate chain onto storyboard? | 10:51 |
| richard_maw | oh, page size preferences | 10:51 |
| Kinnison | ssam2: Also, isn't the last task on https://storyboard.baserock.org/#!/story/38 done? (isolating mason) ? | 10:54 |
| ssam2 | Kinnison: I want to redo storyboard completely, the current one is a hack | 10:58 |
| ssam2 | is the wrong SSL certificate causing you a problem? | 10:58 |
| ssam2 | good spot on story #38, thanks | 10:58 |
| Kinnison | ssam2: it may be related to the auto-errors | 10:59 |
| Kinnison | in story 2 | 10:59 |
| ssam2 | richard_maw: on http://storyboard.openstack.org there's a setting above the list of stories for how many you want to see, so I think updating storyboard would help there | 10:59 |
| ssam2 | Kinnison: good point | 10:59 |
| Kinnison | ssam2: also it's annoying :) | 10:59 |
| Kinnison | but a re-do seems a sane approach | 11:00 |
| Kinnison | clean deployment ftw | 11:00 |
| *** pacon has quit IRC | 11:24 | |
| *** Albert has quit IRC | 11:24 | |
| *** pacon has joined #baserock | 11:25 | |
| SotK | I'm thinking about how we would want to set up a Zuul Mason against our Gerrit. Does it make sense to have a few different criteria it votes on (for definitions at least) rather than just "Verified"? | 11:26 |
| SotK | For example "build" and "tests"? | 11:26 |
| SotK | I'm mostly thinking of trying to do that because getting feedback from a full test cycle may take a while, eg. if the devel system has to build itself from scratch with no cache. | 11:27 |
| ssam2 | I don't think it'll be possible to run a comprehensive set of tests for each branch in Gerrit | 11:28 |
| ssam2 | I think we should aim to provide quick quick feedback on branches in Gerrit, and then do a thorough test of 'master' once per week or so | 11:28 |
| Zara | hi, I'm looking at section 4a here: http://wiki.baserock.org/guides/how-to-cross-bootstrap/ . I'm wondering: do I run the first two steps inside a chroot? I'm also not sure about what the second step entails, but I guess I'll ask more about that when I get to it. | 11:29 |
| pedroalvarez | SotK, ssam2: indeed, quick feedback sounds ok to me | 11:29 |
| ssam2 | Sotk: with that in mind, I think just 'verified' would be OK in Gerrit. Although providing extra feedback in comments is important too, e.g. 'I just started building this, should be done in 5 minutes' | 11:30 |
| SotK | ssam2, pedroalvarez: so just checking that stuff in clusters/ci.morph still build then? | 11:30 |
| pedroalvarez | Zara: looking at it | 11:30 |
| SotK | that makes sense | 11:30 |
| ssam2 | yeah, that sort of thing | 11:30 |
| pedroalvarez | SotK: we can figure out better ways later | 11:31 |
| ssam2 | and run `morph certify` | 11:31 |
| pedroalvarez | maybe in the future, a quick first feedback would be to build only the strata that has changed | 11:31 |
| pedroalvarez | but for now, only build ci.morph would be brillian | 11:32 |
| pedroalvarez | t | 11:32 |
| pedroalvarez | Zara: 4 is confusing | 11:32 |
| pedroalvarez | Zara: all of it is confusing, although maybe not that much given that you managed to get there | 11:33 |
| ssam2 | thanks for cleaning up stale branches in definitions.git everyone!!!! | 11:33 |
| pedroalvarez | :D ;D | 11:33 |
| pedroalvarez | Zara: I think you can skip 4a, 4b and go to 4c | 11:34 |
| franred | ssam2, pedroalvarez, do we have to do it in the gerrit repo too? | 11:34 |
| pedroalvarez | I don't think so | 11:35 |
| pedroalvarez | well, I'm not sure | 11:35 |
| franred | pedroalvarez, I've checked and all the branches that were in gbo are in gerrit | 11:35 |
| franred | unless gerrit sync branches...we will have them stalled in gerrit mirror | 11:36 |
| Zara | pedroalvarez: I thought I needed that step because, when I tested with 'linux-user-chroot / /bin/sh' I got an odd message that looked like an error: 'mount(/, MS_PRIVATE | MS_REC): Invalid argument' | 11:37 |
| pedroalvarez | aha | 11:37 |
| pedroalvarez | Zara: you are right | 11:38 |
| Zara | :D | 11:38 |
| ssam2 | franred: it's up to lorry / lorry-controller to delete branches in gerrit that have been deleted in git.baserock.org | 11:39 |
| ssam2 | franred: I'm not sure whether it will or not, good point | 11:40 |
| franred | ssam2, I imagine they will stay, don't we have a policy/rule in lorry/lorry-controller for not removing branches? (if we treat our repos as the normal repos this shouldn't happen) | 11:43 |
| ssam2 | franred: I can't find such a rule documented anywhere | 11:44 |
| ssam2 | not in http://wiki.baserock.org/Trove/reference/ or lorry's README anyway | 11:44 |
| ssam2 | so I'm looking through the code so see what it does | 11:45 |
| ssam2 | seems that 'lorry' will run `git remote update --prune` in the repo in its working area, so branches get deleted in that repo | 11:45 |
| pedroalvarez | Zara: I've modified 4a a bit | 11:46 |
| Zara | ah, thanks. :) | 11:47 |
| ssam2 | franred: but then to update the actual repo in gerrit, it just does 'git push ssh://... +refs/heads/* +refs/tags/*' | 11:48 |
| edcragg | this kernel seems to be building with '-dirty' :( | 11:48 |
| ssam2 | franred: which I think won't remove any branches that are no longer present in lorry's copy | 11:48 |
| ssam2 | edcragg: I think nowster knows why that happens | 11:48 |
| nowster | yes | 11:49 |
| nowster | I do. | 11:49 |
| ssam2 | franred: so I guess we need a patch to 'lorry' to make it handle the case of deleting branches no longer present upstream | 11:49 |
| edcragg | nowster: ssam2: i've read about uncommitted files in git, but not sure how that would happen in baserock build | 11:49 |
| nowster | Add a "git status" above your "make xxxx_defconfig" | 11:50 |
| nowster | The git tree is in an inconsistent state at that point. | 11:50 |
| nowster | It's a morph bug, I suspect. | 11:51 |
| franred | ssam2, do we want to delete them or keep them? (Just thinking in the case we are building from a branch) | 11:51 |
| edcragg | nowster: ok, very nice :) odd, this the first time i've seen this | 11:51 |
| ssam2 | franred: delete them | 11:54 |
| ssam2 | franred: they wouldn't have been deleted in git.baserock.org if they were useful | 11:54 |
| franred | ssam2, yeah, I was thinking in other repos (git, linux...etch) | 11:55 |
| franred | s/etch/etc/ | 11:55 |
| ssam2 | franred: ah. that goes back to the problem we've discussed a bunch of times of consuming upstream commits | 11:56 |
| ssam2 | franred: i'd be happy if we deleted branches whenever upstream deleted them, and used `morph anchor` to ensure this didn't cause source code for released images of baserock to be lost... but others may disagree | 11:56 |
| Zara | most of the shiny new 4a instructions work fine for me, but I get an odd message when I run 'ldconfig' (this also cropped up several times when I was running the native-bootstrap script; not sure how significant it is): http://paste.baserock.org/ezogixocak | 11:57 |
| *** pacon has quit IRC | 11:59 | |
| franred | ssam2, yeah, that sounds sensible to me too | 11:59 |
| *** pacon has joined #baserock | 12:00 | |
| * SotK tries to figure out how Zuul's timer trigger works whilst waiting for his Mason test to finish | 12:02 | |
| *** Albert has joined #baserock | 12:08 | |
| pedroalvarez | Zara: first result in google: https://gcc.gnu.org/ml/gcc-help/2014-08/msg00053.html | 12:09 |
| pedroalvarez | Zara: looks like they might be just warnings | 12:09 |
| SotK | Zara: I'm pretty sure I've seen that every time I've run ldconfig in Baserock | 12:09 |
| edcragg | ssam2: nowster: the built zImage seems to have a modification date of Aug 24, 1991 not sure if that's a sign of something going a bit squiffy (the system's clock is correct) | 12:10 |
| Zara | hehe :) I wanted to check in case baserock was unusual, glad I can ignore it | 12:11 |
| radiofree | does anyone know why journalctl fails to work on genivi images? | 12:11 |
| radiofree | if you do systemctl restart systemd-journald it'll work for that session, however when you restart it's gone again | 12:11 |
| nowster | edcragg: same as all of mine! | 12:12 |
| SotK | edcragg: I think the mtime of everything in a chunk gets set to that date during the build, but I may be wrong | 12:12 |
| nowster | Aug 25 1991 vmlinux-4.0.0-rc7-be | 12:12 |
| ssam2 | radiofree: could be https://storyboard.baserock.org/#!/story/43 perhaps | 12:12 |
| pedroalvarez | radiofree: that has been failing for months | 12:14 |
| SotK | nowster, edcragg: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/morph.git/tree/morphlib/bins.py#n90 | 12:14 |
| radiofree | oh | 12:14 |
| pedroalvarez | radiofree: looks like the systemd service that waits untils /var is mounted to flush all the early logs, depends on /var being mounted, but looks like that is failing in baserock | 12:15 |
| radiofree | this makes it hard to debug systemd services | 12:15 |
| edcragg | SotK: ok, i guess that's not it, then | 12:16 |
| * straycat thinks ybd could possibly use a little arg validation | 12:17 | |
| straycat | maybe using argparse? | 12:17 |
| paulsherwood | straycat: you're right, i never got round to that | 12:19 |
| paulsherwood | but in general i'm aiming for no commandline args... i want all input from a yaml file | 12:19 |
| rjek | How will it know which one? | 12:20 |
| rjek | One of the problems I'm having with ansible is that /too/ much can only be specified via a yaml file | 12:20 |
| paulsherwood | rjek: ok, only one arg. | 12:20 |
| rjek | Making it difficult to do ad-hoc experiments. | 12:20 |
| paulsherwood | rjek: currently ybd has two. the second is $arch. i intend that it and all the other settings it needs come from yaml | 12:21 |
| paulsherwood | (and/or env variables) | 12:22 |
| pedroalvarez | paulsherwood: $arch should come from your system | 12:22 |
| paulsherwood | pedroalvarez: it can't | 12:22 |
| pedroalvarez | paulsherwood: and in the yaml maybe we should add the valid archs for that yaml | 12:22 |
| paulsherwood | my system can build various $arch | 12:22 |
| pedroalvarez | paulsherwood: I mean, I think we should aim for non-specific-arch systems | 12:23 |
| paulsherwood | agreed. but we still need to specify a target arch somehow | 12:23 |
| pedroalvarez | paulsherwood: given that you can't crosscompile, the target arch is your host arch | 12:24 |
| paulsherwood | not necessarily | 12:24 |
| paulsherwood | if i run ybd in a cluster, and all the artifacts i need exist, ybd should pull all the artifacts, integrate them, deploy them | 12:25 |
| pedroalvarez | I see | 12:25 |
| * paulsherwood has done *a lot* of thinking about this | 12:25 | |
| paulsherwood | also, ybd can be targeted to build a 'chunk' - which won't normally be arch specific, so we need to specify it when invoking ybd | 12:26 |
| pedroalvarez | paulsherwood: then, I think that to build something you don't need the $arch, to deploy something you might need it | 12:27 |
| pedroalvarez | s/might // | 12:27 |
| paulsherwood | $arch is part of the cache_key, so i think i do need it | 12:27 |
| pedroalvarez | this is a really big architecture discussion | 12:28 |
| paulsherwood | yup. | 12:28 |
| paulsherwood | actually now you mention it, might be better to have arch explicitly out of the cache_key | 12:29 |
| pedroalvarez | we need to start thinking about this more and more | 12:29 |
| pedroalvarez | mm | 12:29 |
| paulsherwood | who is 'we'? i can't think about it much more than i already do :) | 12:29 |
| pedroalvarez | it should go in, i think | 12:30 |
| ssam2 | how could 'arch' be out of the cache key? a build of GCC for ARM is totally different to a build of GCC for x86 | 12:30 |
| pedroalvarez | we = developers and users of Baserock | 12:30 |
| ssam2 | unless we had a 'cache per architecture', but I think that'd get confusing when sharing artifacts | 12:30 |
| paulsherwood | ssam2: systemd@e7f13e3f05fcfc054bc90a340f640d4083c873fcf5a9d646ea0824ee829ca39b.x86_64 | 12:30 |
| richard_maw | eww | 12:30 |
| ssam2 | paulsherwood: oh, that seems reasonable | 12:31 |
| paulsherwood | ybd currenly does systemd@e7f13e3f05fcfc054bc90a340f640d4083c873fcf5a9d646ea0824ee829ca39b | 12:31 |
| ssam2 | richard_maw: are you suggesting that such a cache ID is worse than what we have in Morph now? to me, it looks a bit clearer | 12:31 |
| nowster | mips32 and mips64 might be in the same cache... | 12:32 |
| paulsherwood | nowster: how? | 12:32 |
| richard_maw | ssam2: IMO we shouldn't have any identifying information in those file names | 12:32 |
| nowster | because you can build the same on same machine without rebooting | 12:32 |
| Zara | okay, I'm now on the 'move the bootstrap filesystem to the top level of another disk' instruction. am confused; I originally extracted and built this on the disk where I thought there would be room for it, and now I'm not sure where it's suitable to move it to. I have a jetson attached to an ssd; the bootstrap filesystem is on the ssd. | 12:33 |
| Kinnison | x86_64 and armv7blh can be on the same system in the same cache | 12:33 |
| * paulsherwood strongly disagrees with richard_maw's comment since paulsherwood is a human being, and needs to debug cache_keys from time to time | 12:33 | |
| Kinnison | because you can deploy any architecture from any other | 12:33 |
| paulsherwood | ah, i misunderstood. i thought nowster meant that mips32 and mips64 might be in the same cache *artifact* | 12:34 |
| * SotK isn't a fan of the @ but otherwise agrees that it is clearer | 12:34 | |
| pedroalvarez | I assume that richard_maw means that we shouldnt need to look at the cache artifacts ever | 12:34 |
| paulsherwood | i'm not a fan of the @ either, am thinking of going for '.' | 12:34 |
| richard_maw | pedroalvarez: either that, or if we need to work out what the artifact is, we look at the metadata inside it | 12:35 |
| paulsherwood | -1 | 12:35 |
| SotK | paulsherwood: I would like '.' | 12:35 |
| paulsherwood | anyway, this is the cache_key for ybd. i get to dictate it. morph can do what it likes :) | 12:36 |
| pedroalvarez | haha | 12:36 |
| SotK | the first iteration of the OSTree patch had the cached artifacts ref be just the cache key, and I thought it was really annoying | 12:36 |
| richard_maw | if we don't have tooling to inspect the cache then every time someone needs to inspect it, they hand-roll their own with varying degrees of success, often with false positives or negatives | 12:38 |
| ssam2 | richard_maw: I don't think ugly and unhelpful cache keys is a sensible way of encouraging the development of tooling to inspect the cache, though | 12:38 |
| paulsherwood | richard_maw: i still disagree | 12:38 |
| richard_maw | I still think the cache should be an implementation detail, hence we shouldn't need to inspect it unless something has gone wrong, at which point it doesn't need to look pretty, we just need a way to get the information we need out, and the file name is a poor place for structured data. | 12:40 |
| paulsherwood | noted :) | 12:40 |
| straycat | i think ybd could use morph-cache-server regardless, as far as i can tell the cache-server doesn't place any requirements on the format of the cache key | 12:45 |
| paulsherwood | really? that would be *awesome* | 12:53 |
| paulsherwood | how hard is it to spin up a local morph-cache-server? then i could try my 'crazytown' distbuild idea? :) | 12:54 |
| *** pacon has quit IRC | 12:56 | |
| *** zoli__ has quit IRC | 12:57 | |
| * SotK wonders what "'crazytown' distbuild" is | 12:58 | |
| SotK | paulsherwood: morph's test suite sets up a couple, so I think its probably fairly easy | 12:59 |
| paulsherwood | SotK: thanks | 12:59 |
| SotK | paulsherwood: specifically the distbuild yarn | 12:59 |
| paulsherwood | "'crazytown' distbuild": run the same build on several instances of ybd at once, where they all share the same cache server | 13:00 |
| paulsherwood | that's it :) | 13:00 |
| * paulsherwood waits for the flood of reasons why it won't work | 13:00 | |
| pedroalvarez | it's software | 13:01 |
| rjek | :) | 13:01 |
| paulsherwood | heh | 13:01 |
| rjek | It sounds racy, anyway | 13:01 |
| * paulsherwood considers tweeting 'The more i think about code, the less i like it' | 13:01 | |
| paulsherwood | rjek: yup. don't care | 13:01 |
| persia | If we trust the reproducibility story, racy doesn't matter. | 13:02 |
| rjek | I mean, in that, you may end up with things being built multiple times because it wasn't in the cache before they started | 13:02 |
| paulsherwood | yup | 13:02 |
| rjek | And we don't need any help to make builds slower. | 13:02 |
| persia | The part I don't like is the non-elastic nature of it, along with no obvious means to schedule jobs onto a set of workers (whether a fixed set or an elastic set) | 13:03 |
| rjek | ELB! | 13:03 |
| paulsherwood | persia: i think that's just 'cloud' once i prove the concept | 13:03 |
| persia | load-balancing is a decadent subset of scheduling. | 13:04 |
| paulsherwood | heh | 13:04 |
| persia | paulsherwood: At this level, 'cloud' has no concrete meaning. | 13:04 |
| Kinnison | concrete clouds wouldn't float very well in air | 13:05 |
| Kinnison | perhaps their seafaring clouds | 13:05 |
| Kinnison | their? their?! | 13:05 |
| rjek | they're | 13:05 |
| Kinnison | they're! | 13:05 |
| Kinnison | damnit | 13:05 |
| paulsherwood | persia: know. but no point in thinking about how to fix the problem you've described if the basic premise doesn't even work, so i need to try that first | 13:05 |
| persia | Right, which is why one needs to unfuzzy the details before actually deploying to clouds. | 13:05 |
| persia | paulsherwood: Fair, although I don't see any reason the premise doesn't work excepting the race condition (where all the nodes simultaneously build gcc, because it takes a long time) | 13:06 |
| SotK | persia: +1 | 13:06 |
| rjek | And gcc is one of the first things to get built, so it's going to be a massive slow down | 13:06 |
| SotK | I see no reason why sharing a cache server would be a problem? | 13:07 |
| persia | It doesn't slow final delivery much in clock time: it just wastes resources during the duplicate build. | 13:07 |
| * persia has been imagining a shared cache server for this application. | 13:07 | |
| paulsherwood | persia: are you imagining something other than morph-cache-server? | 13:09 |
| * rjek does not want a portal into persia's imagination. | 13:09 | |
| persia | In my imagination, any file server would work. Could just use Swift or Ceph as an object store, could use WebDAV, etc. | 13:09 |
| rjek | You'd want locks, though? Or would you do something like Maildir where only rename needs to be atomic? | 13:10 |
| persia | Something like Maildir, excepting that the name ought be determined by the cache key, so there is never a need to rename. | 13:10 |
| paulsherwood | atomic rename would be my favourite | 13:10 |
| persia | (excepting the publication moment) | 13:11 |
| paulsherwood | +1 | 13:11 |
| rjek | persia: You need the hostname of the builder who put it there in the filename, no? | 13:11 |
| rjek | Ah, right | 13:11 |
| paulsherwood | nope | 13:11 |
| persia | That said, Ceph or Swift handle this entirely differently, so atomic rename shouldn't be a requirement, so much as atomic availability. | 13:11 |
| rjek | otherwise two builders building the same thing would end up trying to create the same cache key entry? | 13:11 |
| paulsherwood | one fails, so what? | 13:12 |
| persia | That's fine. Make the cache server prevent overwrites, and make the builder gracefully fail if it cannot write to cache because of a cache key conflict. | 13:12 |
| rjek | I suppose you just call creat() and have it fail if the file already exists | 13:12 |
| paulsherwood | :) | 13:12 |
| persia | paulsherwood: Failure management needs to be specific: you want to retry in the case where the failure was for something other than overwrite rejection. | 13:12 |
| paulsherwood | details, details :) | 13:13 |
| persia | This is where the devil lives. | 13:13 |
| rjek | Actually, does creat(..., O_EXCL) even work on network file systems? | 13:13 |
| persia | rjek: Depends on the NFS in question. | 13:13 |
| rjek | "On NFS, O_EXCL is only supported when using NFSv3 or later on kernel 2.6 or later. In NFS environments where O_EXCL support is not provided, programs that rely on it for performing locking tasks will contain a race condition" | 13:13 |
| rjek | Right | 13:13 |
| Kinnison | rjek: NFS before that supports exclusive mkdir() | 13:14 |
| Kinnison | rjek: hence most NFS-safe software older than perhaps 10-12 years uses mkdir for its lock generation | 13:14 |
| rjek | nod | 13:15 |
| tlsa | pedroalvarez: removed a bunch of my old personal branches | 13:16 |
| pedroalvarez | tlsa: ta! | 13:17 |
| *** zoli__ has joined #baserock | 13:22 | |
| *** sambishop has quit IRC | 13:34 | |
| *** sambishop has joined #baserock | 13:34 | |
| * SotK fails to find a way to customise the message Zuul's Gerrit reporter sends when starting through layout.yaml :( | 13:37 | |
| persia | SotK ask upstream (#openstack-infra) | 13:41 |
| persia | Most of them will be at conference now, so UTC-7. | 13:42 |
| straycat | ahh so morph supports cpan, wonderful | 13:52 |
| rjek | SpamAssassin time! | 13:53 |
| SotK | richard_maw: thanks for the reviews/merge! | 14:14 |
| jmacs | OpenJDK8 makes no sense at all - I've spent several hours now just trying to build it on Ubuntu, let alone baserock | 14:26 |
| ssam2 | wow | 14:28 |
| *** petefoth has quit IRC | 15:02 | |
| Zara | (am still confused about step 2 in 4a here: http://wiki.baserock.org/guides/how-to-cross-bootstrap/ . details in backscroll at 13:33, not much has changed. might be worth mentioning that, as far as I can tell, my bootstrap filesystem ended up in the same directory as the extracted tarball.) | 15:05 |
| Zara | (jic that necessitates an extra step) | 15:06 |
| * paulsherwood has updated ybd readme https://github.com/devcurmudgeon/ybd | 15:07 | |
| *** Guest75236 has quit IRC | 15:11 | |
| straycat | "Currently YBD generates a lot of log output, which hopefully helps to explain what is happening." might make sense to switch to python's logging module and then just change the log level, rather than implementing that ourselves | 15:12 |
| pedroalvarez | Zara: that step means "move everything (bootstrap filesystem, with all the things that the tarball had) to another disk (usb stick, hard drive..)" | 15:12 |
| SotK | Zara: That page suggests that doing one of either the bind mount or the "move everything" should make it work to me. Is that not the case? (disclaimer: I've never done a cross-bootstrap) | 15:13 |
| Zara | SotK: I tried the bind mount step and didn't get an error at that step, but did get an error with the subsequent linux-user-chroot step, so I assume they're both necessary. | 15:15 |
| SotK | :( | 15:15 |
| *** mariaderidder has quit IRC | 15:15 | |
| *** a1exhughe5 has quit IRC | 15:15 | |
| Zara | pedroalvarez: Okay, that's quite awkward for me rn; maybe could do with a note at the start of the page warning people! | 15:16 |
| pedroalvarez | Zara: if 1 doesn't work, try 2, not sure if both are needed for 2 | 15:16 |
| pedroalvarez | Warning: don't do this ever! | 15:16 |
| pedroalvarez | Zara: what kind of warning :) | 15:17 |
| * SotK guesses "Warning, you may need two disks for this" | 15:17 | |
| pedroalvarez | hm | 15:17 |
| straycat | has anyone tried upgrading from 15.10 to current? | 15:17 |
| pedroalvarez | straycat: I think that yesterday I upgraded from something older | 15:18 |
| pedroalvarez | didn't hit any problem | 15:18 |
| straycat | hrm | 15:18 |
| pedroalvarez | (I might be wrong though) | 15:18 |
| pedroalvarez | Zara: maybe we can suggest to use a different disk to put the uncompressed-tarball at the start? | 15:19 |
| pedroalvarez | (given that it's likely that people hit this problem) | 15:19 |
| pedroalvarez | straycat: is it failing for you? | 15:20 |
| straycat | seemed to be, i'll see if i can reproduce it elsewhere | 15:20 |
| Zara | pedroalvarez: yeah, so if I've followed it right you need to extract the tarball and run the native-bootstrap script on one disk, then transfer it all to another disk (bearing in mind that both disks need to be big enough!)? (I personally quite like 'warning: don't do this ever' option) | 15:24 |
| *** sambishop has quit IRC | 15:27 | |
| pedroalvarez | :) | 15:27 |
| pedroalvarez | thing is that it might not be needed | 15:27 |
| pedroalvarez | I had it working once with the bind mount | 15:28 |
| *** sambishop has joined #baserock | 15:28 | |
| pedroalvarez | but later it stopped working and I had to move it to a disk | 15:28 |
| pedroalvarez | is just annoying | 15:28 |
| SotK | Zara: can you do the first step on the Jetson's built-in flash and then transfer the result onto an SSD? | 15:28 |
| *** mariaderidder has joined #baserock | 15:29 | |
| *** a1exhughe5 has joined #baserock | 15:29 | |
| SotK | I think the built-in flash is 16G so should be big enough? | 15:30 |
| radiofree | i wouldn't recommending resizing the btrfs partition on the emmc to 16G | 15:31 |
| radiofree | 10G seems to be ok | 15:31 |
| jmacs | Finally, jdk8 seems to be building (touch wood) | 15:31 |
| Zara | SotK: I'm not totally sure, haha, I built it in the bigger space to be on the safe side (and this jetson has been used before so I'd need to check how much of that 16G is usable) | 15:32 |
| SotK | Zara: I'd imagine there will be enough free for the (I assume small) bootstrap tarballs | 15:32 |
| Zara | I think there would be room for the tarballs, but I thought it needed to be moved after extraction and build? the total of the extracted stuff and the native bootstrap system seems to be around 18G, unless I've misinterpreted df -h . will pastebin the output because maybe I'm doing something weird. | 15:36 |
| Zara | http://paste.baserock.org/lukohuqoce | 15:37 |
| Zara | the extracted stuff + built bootstrap system is in /src/armv5 | 15:37 |
| SotK | 18G seems excessive | 15:42 |
| SotK | Zara: what's the output of `du -sh /src/armv5`? | 15:43 |
| Zara | a long pause, so far | 15:43 |
| Zara | I'll keep you posted :) | 15:43 |
| SotK | yeah, it takes a while if the directory is big | 15:44 |
| SotK | actually, maybe `du -sh /src/armv5/*` would have been better so we can see which bits are so big :3 | 15:45 |
| Zara | SotK: heh, it loaded anyway, and now I am more confused: / # du -sh /src/armv5 | 15:50 |
| Zara | 8.4G/src/armv5 | 15:50 |
| Zara | # du -sh /src/armv5 | 15:50 |
| Zara | 8.4G/src/armv5 | 15:50 |
| SotK | I imagine there is other stuff in /src which is making the df -h output confusing | 15:50 |
| SotK | looks like it will be able to fit on the emmc anyway | 15:51 |
| SotK | though from the looks of df -h you'll need to do something like `btrfs filesystem resize / 10G` | 15:52 |
| paulsherwood | straycat: +1 on logging, if it's in python by default. i've been learning python on the way :) | 15:52 |
| SotK | (maybe / and 10G should be the other way around) | 15:52 |
| *** jonathanmaw has quit IRC | 15:58 | |
| *** a1exhughe5 has quit IRC | 15:58 | |
| Zara | SotK: thanks :) | 16:00 |
| paulsherwood | rdale: i'm consistently failing to build your systemd. any ideas/ | 16:00 |
| rdale | is that using ybd? | 16:01 |
| paulsherwood | yup | 16:01 |
| rdale | the openwrt system doesn't have systemd, and so i'm not sure what is going on with your build | 16:01 |
| paulsherwood | interesting! :) | 16:01 |
| paulsherwood | thanks. i'll investigate | 16:01 |
| paulsherwood | rdale: have you produced a different foundation, then? | 16:02 |
| rdale | i created a clean system today, and built it from scratch and it worked. i needed to do a local checkout of 'iwinfo' and that was all, after i fixed the two things you found last night | 16:02 |
| paulsherwood | rdale: did/could you push your working branch? | 16:02 |
| rdale | it uses build-essential with a custom busybox config, core-wrt and cpe-wrt | 16:02 |
| rdale | i pushed the two changes to the baserock/rdale/openwrt branch, and pushed the commits that were on github into the baserock busybox git repo | 16:03 |
| paulsherwood | 2015-05-19 20:25:04 [linux-user-chroot] WARNING: multiple definitions of build-depends | 16:04 |
| paulsherwood | 2015-05-19 20:25:04 [linux-user-chroot] ['strata/core.morph', 'strata/python-core.morph'] | ['strata/foundation.morph'] | 16:04 |
| rdale | that's wrong | 16:05 |
| paulsherwood | i daresay :) | 16:05 |
| rdale | none of those strata are in the openwrt system | 16:05 |
| paulsherwood | ok | 16:05 |
| paulsherwood | 2015-05-19 20:25:05 [iptables] WARNING: multiple definitions of build-depends | 16:06 |
| paulsherwood | 2015-05-19 20:25:05 [iptables] ['strata/foundation.morph'] | ['strata/core-wrt.morph'] | 16:06 |
| rdale | core-wrt.morph is in, foundation.morph isn't | 16:06 |
| paulsherwood | yup, understood. thanks | 16:07 |
| rdale | iptables is in both connectivity.morph and cpe-wrt.morph | 16:08 |
| paulsherwood | yup | 16:09 |
| *** zoli__ has quit IRC | 16:23 | |
| nowster | a lot of stuff moved from foundation to core recently | 16:26 |
| *** wdutch has quit IRC | 16:44 | |
| *** wdutch has joined #baserock | 16:46 | |
| *** Krin has quit IRC | 16:54 | |
| *** ssam2 has quit IRC | 16:55 | |
| *** bashrc has quit IRC | 17:00 | |
| *** CTtpollard has quit IRC | 17:14 | |
| *** Albert has quit IRC | 17:18 | |
| *** mariaderidder has quit IRC | 17:20 | |
| *** gary_perkins has quit IRC | 17:45 | |
| *** edcragg has quit IRC | 17:50 | |
| *** zoli__ has joined #baserock | 18:02 | |
| *** franred has quit IRC | 18:43 | |
| *** edcragg has joined #baserock | 19:34 | |
| *** edcragg has quit IRC | 19:50 | |
| *** edcragg has joined #baserock | 20:13 | |
| *** zoli__ has quit IRC | 20:37 | |
| *** zoli__ has joined #baserock | 20:52 | |
| *** edcragg has quit IRC | 21:15 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
