| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:02 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 00:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 00:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 00:17 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 01:27 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 01:35 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 01:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 01:48 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 02:19 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 02:22 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 02:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 03:55 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 04:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 04:35 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 04:41 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:05 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 05:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 05:19 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 05:35 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 05:45 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 05:49 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 06:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:08 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 06:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 06:34 | |
| paulsherwood | is there a way to kill "A start job is running for dev-disk-by\x2dlabel-src.device" ? | 08:10 |
|---|---|---|
| paulsherwood | ah... it gives up on its own | 08:11 |
| *** franred [~franred@host-78-148-19-173.as13285.net] has joined #baserock | 10:07 | |
| *** franred [~franred@host-78-148-19-173.as13285.net] has quit [Client Quit] | 10:11 | |
| paulsherwood | dumb question - is one of our *rootfs artifacts usable as an img ? | 12:51 |
| paulsherwood | or is there a way to create an img file from *rootfs other than morph deploy? | 12:52 |
| persia | No, and yes, but it's ugly | 13:01 |
| straycat | The image needs to have some sort of file system, probably btrfs in our case and then possibly some bootloader stuff on top. | 13:01 |
| persia | Also needs to be configured: there's lots of stuff that gets deferred to deploy time that should run to make the software work. | 13:02 |
| persia | (from the chunks,and separate from the configuration extensions: the "integration scripts") | 13:02 |
| paulsherwood | ughh... it's 2014! :) | 13:18 |
| Kinnison | It is. Had you not noticed? | 13:22 |
| Kinnison | :_) | 13:22 |
| persia | This is not this way because it's old and nasty: this is this way to ease multiple deployments from the same rootfs artifact without the ugliness of configuration management-based solutions. | 13:22 |
| paulsherwood | so, here's my catch 22 - | 13:22 |
| paulsherwood | on jetson, i can use morph build to create rootfs, then use morph deploy to create img | 13:23 |
| paulsherwood | but i can't run nvidia flashing tool (it's x86) | 13:23 |
| Kinnison | Have an x86 VM, build on the jetson and transfer the artifact cache contents to your x86 vm and deploy from there | 13:24 |
| persia | Is there no longer an ARM binary for that? There used to be one. | 13:24 |
| persia | (assuming we're talking about the fastboot manipulation utility) | 13:24 |
| straycat | Hrm? Doesn't the nvidia tool take a tarball? | 13:24 |
| Kinnison | Or, set your jetson up as a distbuild worker/controller pair and use distbuild from a VM on your x86 | 13:24 |
| persia | straycat: It can take a tarball *or* a filesystem image. | 13:25 |
| persia | (or it could, last I used it, years ago) | 13:25 |
| paulsherwood | Kinnison: the distbuild route is too complex for me, i'm afraid | 13:25 |
| Kinnison | I can understand that :-( | 13:25 |
| paulsherwood | and so are netcat, and scp. i feel brainless today | 13:25 |
| Kinnison | It's probably beyond me to describe on a Sunday too | 13:25 |
| * persia wants a simple build-on-target command | 13:25 | |
| * Kinnison recommends a beer and a book, in a room with music | 13:26 | |
| Kinnison | that usually renews braincells | 13:26 |
| paulsherwood | i have music - my youngest is playing piano | 13:26 |
| persia | paulsherwood: To be clear, do you want to run the new image on the jetson that built it, or another jetson? | 13:27 |
| paulsherwood | is there some way i can upload an img to downloads.baserock.org? or some other internet space for the mo? | 13:27 |
| persia | Also, is the other jetson already running *some* baserock? | 13:27 |
| persia | (if the latter) | 13:27 |
| paulsherwood | persia: i can cause an out-of-box jetson to be brained as baserock, with the nvidia kernel: http://wiki.baserock.org/guides/baserock-jetson/ | 13:28 |
| paulsherwood | now i would like to brain one with my own choice of baserock system, in the smallest number of steps possible | 13:29 |
| persia | Then just use radiofree's work to do upgrades. | 13:29 |
| paulsherwood | it must be me, but i honestly get confused by radiofree's instructions | 13:29 |
| persia | And upgrade your target from whatever random state (that was baserock) to the one you want. | 13:29 |
| paulsherwood | and i have never done a baserock upgrade, on any system. i know that makes me a wuss | 13:29 |
| straycat | Or deploy to tarball, scp tarball to x86 system, flash rootfs over, then extract kernel from tarball and flash that? | 13:30 |
| paulsherwood | you guys make it sound easy | 13:30 |
| persia | It's also safe to s/tarball/image/ in straycat's instructions | 13:30 |
| persia | paulsherwood: So, as a first step, read upgrade-devel.morph, and run the command listed there, so you have experience with a local upgrade. Once you know how to upgrade, just upgrade your target. | 13:31 |
| persia | Aside from the poor documentation, this is supposed to be easy: built on devel ,upgrade target for testing. It's part of basic workflow for hardware-based solutions. | 13:32 |
| persia | Mind you, it requires a native devel environment, which is why I want a simple build-on-target command. | 13:34 |
| persia | (because two boards per engineer is unlikely to be available to OSVs for prerelease hardware) | 13:35 |
| persia | (note that doing this is complex: one needs to share an artifact cache, possibly via sshfs, and somehow cause morph to run in an environment that doesn't depend on features of the target system, etc.) | 13:36 |
| * paulsherwood has never used scp, for example, and curses netcat every time he has to google how to use it | 13:40 | |
| Kinnison | Have you used cp before? if so, scp is pretty simple, just learn to prefix filenames with machine-name: to transfer across networks | 13:40 |
| Kinnison | e.g. scp somehost:/path/to/somefile mylocalcopy | 13:41 |
| Kinnison | the only really irritating limitation is you can't do scp somehost:/path/to/somefile anotherhost:/path/to/somewhere/ | 13:41 |
| persia | Or `scp somefile somehost:somefile` in the simple form | 13:41 |
| Kinnison | aye | 13:41 |
| paulsherwood | Kinnison: tvm | 13:41 |
| persia | Kinnison: For that, you should use ftp. Unfortunately, nobody has written a good command-line client for ftp. | 13:42 |
| Kinnison | paulsherwood: YOu might find http://yakking.branchable.com/posts/ssh/ to be of some use | 13:42 |
| Kinnison | persia: mmm, ftp is overused on the internet and underused on private networks | 13:42 |
| persia | Sadly. It's because ftp+ssl is no undersupported in both clients and servers. | 13:42 |
| Kinnison | mmmm | 13:43 |
| persia | Plus nobody seems to understand using X.509 certificates | 13:43 |
| Kinnison | FTPs is barely supported anywhere | 13:43 |
| * persia is unhappy about both these things, as ftp is really cool | 13:43 | |
| Kinnison | To be fair, I think even the people who specced them didn't really understand them | 13:43 |
| persia | Yes, but ignoring the implementation details, folk seem to create new key strategies in preference to using X.509 | 13:43 |
| * persia is somewhat annoyed at the proliferation of services that use ssh certs for authentication, when ssh certs can't be authenticated | 13:44 | |
| Kinnison | I'm not fond of the "oracle of all truth" aspect which people who misunderstand/misuse x.509 often expect | 13:44 |
| Kinnison | I did the research once to sort out a way to have an x509 cert (with authentication/authority chains) convertible to an SSH key | 13:45 |
| Kinnison | so you could have both worlds with one private key | 13:45 |
| persia | I suspect the fact that the US Government restricted use of strong keys while promoting use for secure transactions (with weak keys) helped with both of our complaints. | 13:45 |
| persia | Yep. You can even have that private key be a GPG secret key. | 13:45 |
| Kinnison | Indeed | 13:45 |
| persia | Unfortunately, client support for doing that is *awful* | 13:46 |
| * persia thinks that it ought be the default | 13:46 | |
| paulsherwood | Kinnison: do you know if i have supercowpowers to publish to download.baserock.org? | 13:46 |
| * Kinnison doubts you do | 13:46 | |
| Kinnison | let me check | 13:46 |
| persia | paulsherwood: What do you want to publish? | 13:46 |
| paulsherwood | a jetson img with docker, if i can get it to work | 13:47 |
| persia | Just publish the definitions. | 13:47 |
| Kinnison | paulsherwood: actually you ought to have the rights, but if you want, you can upload it to your ~ on that box and I'll publish it for you | 13:47 |
| * persia doesn't think it's interesting to publish images for consumption, because the desireable baserock target audience should be excited about *modifying* systems, rather than consuming them. | 13:48 | |
| paulsherwood | persia: you're missing my point, slightly... it's currently non-trivial to get started on jetson | 13:48 |
| Kinnison | persia: Publishing an image to help people get started is well worth it IMO | 13:48 |
| persia | Yes, but it should be a *devel* image, no? | 13:48 |
| paulsherwood | it will be a devel image with docker | 13:49 |
| * persia would be very happy to see jetson devel images kept up to date on download.baserock.org | 13:49 | |
| persia | How does docker help? | 13:49 |
| persia | I'm not saying docker isn't cool, but I don't see why the jetson devel image should be different. | 13:49 |
| paulsherwood | i'm not sure yet | 13:49 |
| persia | So, when you're confident, change *all* devel images to be docker, and publish those :) | 13:50 |
| paulsherwood | my current itch is jetson | 13:50 |
| persia | So let's define a jetson devel image that match.es other devel images, and get it into the release morphology | 13:51 |
| radiofree | It's not non-trivial if you're familiar with u-boot/bootloaders/flashing etc.. | 13:51 |
| * persia fiddles with PalmDetect harder | 13:51 | |
| paulsherwood | that's already there - we just haven't done a 'release' with the jetson devel so far | 13:51 |
| paulsherwood | radiofree: s/familiar with/expert at/ | 13:52 |
| persia | Oh, right, because we bundle stuff. | 13:52 |
| persia | Are we still dependent on Codethink resources to do a release, or can we just do one if we have folk with supercowpowers about? | 13:53 |
| Kinnison | In theory, the latter if they have resources to hand and the jetson stuff Paul is trying to release now | 13:53 |
| Kinnison | Which would be nice | 13:53 |
| persia | I'm happy to build a bunch of x86 artifacts to populate the cache if others are up for trying a release today. I don't have arm hardware available to me at the moment. | 13:54 |
| Kinnison | I'm not sure what the state of things are, but I'd like to be certain things like the distbuild plugin are good before we do a release | 13:55 |
| Kinnison | I think it'd be nice to have a release beyond 14.20 where we're confident about distbuild | 13:55 |
| persia | Oh, right. So really we need someone with a distbuild environment to do a release, and that's rare on weekends. | 13:56 |
| Kinnison | Aye, in theory you can do it all on one system (the mason work has build, controller and worker all on one VM) but I don't personally know how to set that up | 13:56 |
| paulsherwood | i can get to a jetson distbuild network | 13:56 |
| persia | I can try to instantiate an x86 distbuild network on my private (in-laptop) cloud, but I don't know how slow that might run. | 13:57 |
| persia | My ML thread about governance hasn't garnered much response: do we need approval from anyone to do a release? | 13:58 |
| paulsherwood | radiofree: sorry to bug you, but i'm trying baserock-jetson-flash.sh and getting 'file does not exist' | 13:59 |
| paulsherwood | http://fpaste.org/126147/83987140/ | 13:59 |
| paulsherwood | persia: weren't you the one saying releases are meaningless? | 14:00 |
| paulsherwood | :-) | 14:00 |
| persia | paulsherwood: I'd like them to be, yes, but I've been convinced by the number of times I've lost entire days to rebuilding that we need cache population to happen. | 14:00 |
| persia | So unless we have a distbuild network building definitions master when changes land, we need to coordinate cache population, which is a "release". | 14:01 |
| straycat | Does the cd system not continually populate the cache? | 14:01 |
| persia | I don't think the generated artifacts are particularly interesting, and I think that the conceptual model of "releasing" slows development and encourages user-unfreindly changes to land, but there are structural issues that need to be resolved to be release-free. | 14:02 |
| persia | straycat: Is there a public CD system in place? | 14:02 |
| paulsherwood | straycat: i don't think we have a public cd system yet | 14:02 |
| * persia has seen lots of code that might make that happen, but thought it was still in the "here's a toolkit from which you could build CD" stage. | 14:03 | |
| Kinnison | I think we are | 14:03 |
| Kinnison | I think Mason is still a little bit lashed-together while technology decisions get made | 14:04 |
| Kinnison | particularly around the CI engine core. I'm currently favouring buildbot when asked | 14:04 |
| * persia is partial to zuul+gearman | 14:05 | |
| Kinnison | I'd love for you to spend some time this week telling me about those | 14:05 |
| Kinnison | because I've no experience of them | 14:06 |
| persia | You'll like zuul: it's python | 14:06 |
| persia | http://ci.openstack.org/zuul | 14:06 |
| Kinnison | What, not Lua? | 14:06 |
| * Kinnison pouts | 14:06 | |
| ratmice__ | persia: hmm, i think there is a ton of value in publishing images for some use cases | 14:06 |
| persia | ratmice__: I'm of mixed minds. I don't think there's value in publishing images for users of Baserock who are building random stuff or hacking baserock tooling. I agree there's value in images that do things, but I think the folk who curate those images ought be somewhat separate from the folk doing tooling (although some folk may wear multiple hats). | 14:08 |
| persia | For that matter, I even think there's value in batching and releases for image creation (although having dailies for testing is handy), whereas I prefer CD for the core tooling. | 14:09 |
| persia | I'm not sure any of the current reference images other than the devel systems for new users are particularly useful as curated targets though (I'd be delighted to be wrong) | 14:10 |
| ratmice__ | persia: in our case bulding toolchains for bootstrapping a couple of related OS's it becomes impossible to make available a toolchain for every OS/os version someone might want to build/modify our source base from, so having a single image everyone can use to bootstrap from keeps everyone on the same page, and saves much time | 14:13 |
| radiofree | Paulsherwood | 14:14 |
| radiofree | Try giving it the full path to the img | 14:14 |
| persia | ratmice__: This makes perfect sense. You are exactly of the class of users who I consider to be the set who would curate images that have a release schedule. | 14:15 |
| radiofree | E.g /home/me/image/bar.IMG | 14:15 |
| paulsherwood | radiofree: ok | 14:15 |
| persia | ratmice__: I'm just not sure that the same applies for many of the reference images in definitions.git master. | 14:16 |
| ratmice__ | ahh | 14:16 |
| persia | And I'm perhaps overly critical of releasing images in part because many of the folk who seem to be regulars on this channel seem to hack on morph with using-latest-morph so rarely (if ever) run the "released" images. | 14:17 |
| ratmice__ | I suppose i'm somewhat confused, because new users have to start from somewhere, and the current mechanism for that is releasing images, need to read this more carefully to figure out what/how we are suggesting to replace that with :) | 14:25 |
| paulsherwood | ratmice__: i agree with you. sometimes, our discussion tends to lose track of the ground | 14:27 |
| persia | My thought is that for the tooling for system developers, there is ideally a development image built from the latest commit to definitions for every supported architecture (and possibly a minimal target image, if my dream of build-on-my-target even gets implemented~). | 14:27 |
| persia | And there may also be a collected set of curated images that are collaboratively developed using the baserock tooling, which would be released together on some schedule that worked well for the various curators. | 14:28 |
| paulsherwood | persia: build-on-target is already happening? maybe not in a dreamy way, though :) | 14:28 |
| persia | (but this latter presumes the existence of a community of curators) | 14:29 |
| persia | paulsherwood: Not quite what I want. The current model involves having *two* target systems: one to build, and one to test (or maybe one with removable media). | 14:29 |
| persia | I want to be able to run my devel system on whatever arch I want (probably ARM/x86 because I like laptops), and be able to cause my target (probably MIPS or PPC, because that's the sort of hardware I usually play with) to build a system and then deploy as upgrade into that system. | 14:31 |
| paulsherwood | persia: me too :) | 14:31 |
| Kinnison | Sounds like defaulting to making single system controller+worker systems would be a good path to persia's goal | 14:31 |
| persia | Kinnison: Maybe. I need pictures and architectural discussions to know if I agree. | 14:32 |
| * Kinnison nods | 14:32 | |
| Kinnison | Fair | 14:32 |
| * Kinnison is only half-paying-attention to this discussion anyway, watching baby-snake care videos | 14:32 | |
| paulsherwood | what's the value of distbuild in that scenario? why not just build? | 14:32 |
| persia | My initial response is "not at all" because I read that as implying that I'm running some special system on my target to build. | 14:32 |
| persia | paulsherwood: I think Kinnison is using "distbuild" as shorthand for "building on a system other than the devel system". | 14:33 |
| * Kinnison is | 14:33 | |
| Kinnison | Also the current distbuild infra is as good as anything else we have for getting the workspace content to the target for building | 14:34 |
| Kinnison | shared FSes are often too slow or awkward | 14:34 |
| Kinnison | Of course, it implies some kind of trove-like system which I know is becoming contentious | 14:34 |
| persia | Yes, but, troves, ... | 14:34 |
| paulsherwood | docker :) | 14:34 |
| Kinnison | persia: I have some half-baked ideas about distbuild using the initiator to acquire git content | 14:35 |
| persia | So, there's two bits here that need network data: | 14:35 |
| Kinnison | persia: and using git bundles and/or archive tarballs across the link | 14:35 |
| persia | 1) current state (for which I'd be happy with just git refs to accessible locations) | 14:35 |
| persia | 2) tooling (remember, the target system may not have morph) | 14:35 |
| persia | Kinnison: I think we should stop supporting building random uncommitted stuff. | 14:36 |
| Kinnison | I'm not convinced we can get very far without morph (or some minial variant thereof) and supporting tooling (linux-user-chroot) etc. | 14:36 |
| * persia believes this to be irresponsible and/or confusing, depending on the user's knowledge of git | 14:36 | |
| Kinnison | persia: I think you'd be throwing away the chance of a fast change/build/test cycle if you forced user-driven commit/push at every change | 14:36 |
| persia | Maybe. When I'm hacking source for fun, I generally commit before build anyway. Commits are cheap. | 14:37 |
| Kinnison | For a lot of people, they worry about commits | 14:37 |
| Kinnison | the commit-often and rebase-at-some point methodology is not widely used IME, particularly outside of people already deeply invested in git workflows | 14:38 |
| persia | Sadly misled by the terminology. A git "commit" doesn't mean the same thing as for a real VCS. | 14:38 |
| * persia commits often and rebases continuously | 14:38 | |
| * Kinnison commits somewhat often and rebases usually before a push, regardless of intent to merge | 14:39 | |
| paulsherwood | i don't worry about commits. i just want there to be no possibility that morph and i disagree about what to build | 14:40 |
| ratmice__ | fwiw, I do sometimes wish everything might work as some sort of large series of self contained filesystems which can be mounted like /opt rather than devel/release shenanigans, but its somewhat harder to maintain a consistent risk-free image :/ | 14:40 |
| persia | paulsherwood: I agree. I believe that using commit to ensure shared understanding is sensible. Morph does that today, but hides the details in ways that cause git visualisation tools to lose track. | 14:40 |
| persia | (although richard_maw's recent changes may have changed this: I haven't rebuild my gitk+tig system with them yet) | 14:41 |
| persia | ratmice__: It's a dependency issue: you'd need to have each piece know the complete set of other things for which it is integrated as it drops in place. | 14:41 |
| * persia also wants this, but expects it to be enterprise-only, due to the massive infrastructural requirements | 14:42 | |
| ratmice__ | i do nutty things, branch per patch in a series, merge branch, and a scripts-to-merge-it branch, so committing can be rather involved | 14:43 |
| persia | Hrm? If you have branch-per-patch, you have lots of git commits, although perhaps not a classic VCS "commit". | 14:43 |
| persia | I actively don't believe users should have a classic VCS commit except at the end of their series of work. | 14:44 |
| * persia is perhaps overly excited about git's failures as a VCS allowing for lots of useful hackery for unpublished branches | 14:44 | |
| ratmice__ | persia: the 'merge' branch contains the classic VCS commit, and each patch branch gets rebased/etc as patch series evoles... | 14:45 |
| persia | Understood: I've seen discussion of this workflow recently in a few contexts, but all the changes you make are typicaly commited in the git sense regularly, and the cost of --amend is light, no? | 14:47 |
| persia | (Although I'm not sure precisely why I'm arguing for my workflow, when I really only care about whether morph exposes when it commits stuff, so users aren't surprised) | 14:49 |
| ratmice__ | not exactly, part of it is ensuring that each patch in the series builds/tests appropriately by some per-commit continuous integration, a lot of the actual programming gets done in the merge branch, then I go to various satellites only to commit... | 14:50 |
| persia | Ah, that's a little different than the patch-per-branch workflow I saw discussed recently. | 14:51 |
| persia | As I understand it, distbuild currently does a commit (into a new branch) on morph build, and pushes that new branch to a shared location. | 14:52 |
| persia | My thought was that this should be exposed to users more clearly, rather than morph trying hard to restore state (including staging state) after the commit. | 14:53 |
| persia | But maybe you need that state for something? | 14:54 |
| ratmice__ | fwiw I don't use this all the time, but have maintained some fairly intrusive patches for a long period of time | 14:54 |
| persia | Right, but if you need the uncommitted git state at least sometimes, then it's probably worth continuing to support this. | 14:56 |
| persia | Whereas if you don't need the state, then I'll continue arguing we shouldn't store it until I find someone that does :) | 14:57 |
| ratmice__ | distbuild throws some uncertainty in my mind as to whether I ever want uncommited stuff to be available _to other people_, which is a resounding no :) | 15:00 |
| persia | Hmm.. I hadn't thought about that. | 15:03 |
| persia | I want build-on-target because I don't want to have to run a trove at home to patch my router. | 15:03 |
| persia | But I can well imagine a team environment in an organisation where it's tempting to have a change including a comment about a coworker's stupidity that needs to be built, but never seen by that coworker (especially if one is wrong). | 15:04 |
| paulsherwood | ratmice__: i agree with you, again :) | 15:04 |
| ratmice__ | it seems like the having 2 cache's a local one and a distbuild one is messing with my head and it'd be nice to get down to just one and a 'run distbuild locally' scenerio | 15:05 |
| persia | The issue there is really exposing that cache to the worker. | 15:09 |
| persia | (or paying the price in extra build time) | 15:09 |
| persia | Note that the lack of effective gc on trove caches currently means one has to care (for resource allocation reasons), but ideally one shouldn't. | 15:11 |
| ratmice__ | its not so much offending co-workers as much as testsite passes/coverage metadata which are trivially ignored in the local only scenerio but hogwash in a distributed scenerio (I understand it's technically offtopic for distbuild) but its a new separation to many developers, and i probably just need to track whats going on with mason more | 15:26 |
| * persia has read that several times and remains confused. | 15:30 | |
| persia | Do you mean something like not wanting to have published branches that don't pass the verification suite? | 15:31 |
| persia | (especially when you fixed the issue 2 minutes later) | 15:31 |
| ratmice__ | just not wanting every developers working branch to be listed together with the pass/fail % of coverage for the project as a whole until they publish, where that data is all keyed off of the build ID | 15:32 |
| persia | Ah, right. That's probably a matter of having different CI reporting for development branches and the project. | 15:35 |
| * persia hasn't been following the Mason work closely enough to know if this is currently enabled, but suspects that the per-branch nature of current Mason means that it is easiest to implement with current code by having separate CI environments per-developer (plus one for a merge target). | 15:36 | |
| ratmice__ | its probably important to note for the sake of verbosity i include coverage, because it requires special compiler flags, and thus affects the built stuff, which is irrelevent to whether and who the metadata is important to, anyhow if we could get a consistent workflow for all this i'd be a fairly happy camper :) | 16:09 |
| persia | Depending on how it's done, profiling can also require that sort of thing. | 16:13 |
| * persia suspects that the current cache key generation algorithm could be perplexed by these sorts of builds | 16:14 | |
| * paulsherwood must be doing something dumb... | 16:25 | |
| paulsherwood | http://fpaste.org/126185/14082927/ | 16:25 |
| paulsherwood | flashing seems to proceed ok, but the board doesn't seem to boot | 16:25 |
| * persia remembers spending a day or so trying to figure out nvidia's tegra tooling the first time | 16:26 | |
| persia | paulsherwood: When you boot, what happens? | 16:27 |
| paulsherwood | nada | 16:27 |
| * persia wonders why the flash is being repartitioned | 16:27 | |
| persia | Did you let the magic smoke out? The board should at least initialise. | 16:28 |
| paulsherwood | no magic smoke. power led is on. fan is spinning. i can force recover it. | 16:28 |
| persia | Hrm. | 16:29 |
| * persia wonders if the firmware is actually reading the GPT and can load EFI, rather than using u-boot | 16:30 | |
| paulsherwood | i can boot using the nvidia bootloader. this is me trying to dumb-down radiofree's distbuild instructions, for a single jetson | 16:31 |
| persia | And where are you in the instructions? I presume you've already gotten the dev image running, and are now trying for a cluster morphology? | 16:33 |
| paulsherwood | i had a devel image running, with the nvidia kernel. i now have a new jetson devel image, which i'm trying to put into the emmc | 16:35 |
| paulsherwood | with u-boot, btrfs | 16:35 |
| persia | So you've run `morph deploy`, and are on the "Flashing the distbuild images" section? | 16:36 |
| paulsherwood | not exactly. | 16:36 |
| paulsherwood | ah. that'll be it. | 16:37 |
| persia | What did you try to do between `morph build` and `baserock-jetson-flash.sh`? | 16:37 |
| paulsherwood | my deploy did not have all the magic set | 16:37 |
| paulsherwood | thank you | 16:37 |
| * persia vaguely wishes the deployment magic could go away in favour of ansible, but understands this would probably be bad for folk building highly-resource-constrained systems | 16:38 | |
| persia | So I hope you've found a solution, but I'm guessing you had booted u-boot, and didn't chain-load linux, and didn't have a serial console connected. | 16:42 |
| paulsherwood | your guess is almost certainly correct | 16:49 |
| paulsherwood | sadly my round-trip-time on this at the moment is approx 60 mins | 16:50 |
| persia | Part of that is that your target doesn't have native EFI loaded, making it hard to work with. | 16:52 |
| persia | But I don't understand the other 50 minutes: what takes so long? | 16:53 |
| paulsherwood | 30 mins to flash | 16:55 |
| paulsherwood | 10 mins to migrate my redeployed image to my x86 vm | 16:55 |
| persia | That should go away once you finish bootstrapping and can migrate to an upgrade-based workflow. | 16:55 |
| paulsherwood | and 20 mins futzing around | 16:55 |
| radiofree | I do hope you're not trying to flash a board without a serial connection | 16:55 |
| persia | radiofree: Why? | 16:56 |
| paulsherwood | yes, i am trying that | 16:56 |
| * persia has never used nvflash and a serial console at the same time, not much seeing the point | 16:56 | |
| paulsherwood | but to be clear, it's the bootstrapping i want to crack | 16:56 |
| radiofree | Because you have no idea what's going on | 16:56 |
| paulsherwood | radiofree: welcome to my world :) | 16:56 |
| radiofree | If u-boot has actually flashed.. If the kernel has loaded... If the kernel has panicked at some point | 16:57 |
| paulsherwood | footie's finished, i see :) | 16:57 |
| persia | paulsherwood: So, the sane bootstrapper would just flash the image from download.baserock.org twice. | 16:57 |
| radiofree | You have absolutely no way of knowing what's going on | 16:57 |
| persia | radiofree: For those of us who don't hack the kernel much, and like to assume bootloader folk did it right, that's fine | 16:57 |
| persia | (yes, sadly, this isn't usually a very safe assumption, but for this I blame the reliance of bootloader folk on serial consoles, rather than the problem being with the user expecting the device to work without one) | 16:58 |
| radiofree | Can't have this conversation ATM. On phone | 16:59 |
| persia | No worries. The nice thing about IRC is that timing is flexible (especially if one has infinite backscroll) | 17:00 |
| radiofree | I would just recommend using the serial when doing this type of stuff, just to make sure you know what's going on | 17:00 |
| radiofree | Also 30min to flash 3GB? | 17:01 |
| paulsherwood | yup - virtualbox usb passthrough on mac seems very slow | 17:01 |
| radiofree | What's the VM usb controller?? USB 1? | 17:01 |
| persia | It was probably performance validated for USB 1, and has since had more support added, but not new performance adjustments. | 17:02 |
| paulsherwood | it claims USB 2.0 | 17:02 |
| persia | If it doesn't work this time, just flash the devel image, and upgrade it to your target image, so you don't have to do this again. | 17:05 |
| persia | (as a side effect, the upgrade workflow probably extends the life of the flash medium, because btrfs understands about wear leveling) | 17:06 |
| paulsherwood | that would be giving up :) | 17:06 |
| * persia stops trying to channel Sancho Panza | 17:07 | |
| * paulsherwood surrenders for today... | 17:29 | |
| radiofree | in terms of what you're currently trying to achieve - get baserock on there so you can then use baserock to upgrade it | 17:52 |
| radiofree | it requires board specific stuff, this will be the same for all boards | 17:52 |
| radiofree | e.g for a wandboard it would be much more scary "use dd to flash this here, and that there.... then flash the image to this partition" | 17:53 |
| radiofree | it requires a certain amount of knowledge, if you were handing out these boards for developers to use i would imagine you would want them to be pre-flashed | 17:54 |
| radiofree | IMO for any board work, even after you've installed baserock, you'd always want a serial connection to it | 17:54 |
| radiofree | say you upgraded the kernel, if it didn't "boot" you'd be clueless about where it went wrong | 17:55 |
| radiofree | is it hanging waiting for the rootfs (which could mean maybe something's wrong in the new device tree), or is there a kernel panic before that? | 17:56 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 18:18 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:19 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 19:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:15 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 19:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:26 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 19:31 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:40 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 19:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:56 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 20:07 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:17 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 20:22 | |
| persia | radiofree: So, for my other tegra devices, when it didn't boot, I generally just reflashed it with something else, and then it booted. Only binary information, but this is sufficient for someone who isn't going to fix the kernel or bootloader. | 20:25 |
| persia | (it may also be worth noting that I would have had to drill a hole in the plastic to attach a serial cable, which is generally my experience with devices: I did roughly the same thing for i.MX51, although that involved a reinstall rather than a reflash (as there was XOR flash implementing multidevice kernel loading on that device)) | 20:27 |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 20:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 272 seconds] | 21:21 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:29 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 21:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:43 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 22:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:02 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 22:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!