| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:30 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 07:48 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:59 | |
| paulsherwood | rjek: morning :) | 09:26 |
|---|---|---|
| persia | paulsherwood: Looking at your jetson upgrade: what precisely does "no_console_suspect=1" mean? Without background, that looks like it suspends the machine until/unless it has console, but I may be misreading it. | 09:36 |
| paulsherwood | persia: as i've just commented on the ml, i just took this directly from the wiki instructions | 09:50 |
| paulsherwood | i have no idea what's actually going on :) | 09:50 |
| paulsherwood | note this is my weak, belated attempt to save future jetsons from the lobotomy i gave to pris :) | 09:51 |
| paulsherwood | by having a jetson-upgrade explicitly in definitions, folks may be less tempted to run morph --update with the default devel-update, as i did. | 09:53 |
| persia | Heh. Oh well. If you do it without HOSTNAME, remember to specify on the command line (as with upgrade-devel). | 09:53 |
| persia | Indeed. I think the goal is good: I just worry as to whether that particular argument means it doesn't work without serial console and/or attached HDMI+usb. | 09:53 |
| * persia will have to read docs | 09:53 | |
| paulsherwood | i'll try. i'm steadfastly refusing to attach a serial console until i've killed another jetson | 09:54 |
| persia | Good choice. | 09:55 |
| persia | Turns out that no_console_suspend does almost the opposite of what I would expect from the name: it *enables* continuous console output during the suspend process, rather than suspending it for delivery at resume (the default). | 09:56 |
| paulsherwood | my flashing process is depressingly slow, still, though. my usb passthrough speed varies between bad and appalling. looks like it may take well over an hour at this rate | 09:57 |
| persia | You either need to install another operating system on your laptop or morph should support it (unfortunately, it doesn't have the syscalls upon which morph depends). | 09:58 |
| paulsherwood | and give up my beloved macos? surely you are joking :) | 09:59 |
| persia | Again, "or" | 10:00 |
| persia | Hmm. Seems jail(8) aren't available in OS X, and chroot(8) isn't strong enough, although I do wonder why morph uses linux-user-chroot and still requires root (as the point of linux-user-chroot was to allow for non-root). | 10:05 |
| persia | s/8/2/g | 10:06 |
| persia | Err, rather, without the substitution | 10:07 |
| * persia decides to postpone understanding man sections yet again | 10:07 | |
| paulsherwood | :) | 10:12 |
| persia | sandbox(7) looks interesting, but I can't find much documentation about it (although I did find some complains about lack of documentation :) ) | 10:21 |
| persia | It's the protection used to separate iOS apps, so at least some believe it to be safe. | 10:22 |
| persia | Also probably requires using ZFS, as HFS+ can't support building some systems, and btrfs has no support. | 10:24 |
| paulsherwood | never mind. i've rebooted | 10:24 |
| persia | Without completing the flash? | 10:24 |
| paulsherwood | yup | 10:24 |
| persia | You might be able to get away with a live environment: if you have an OS that can run over EFI from USB, just hold down the option key on boot. | 10:25 |
| paulsherwood | can baserock do that? | 10:25 |
| persia | I don't know: I haven't been following the boot-from-USB work. | 10:27 |
| * paulsherwood remembers richard_maw had something running a while ago | 10:27 | |
| persia | But Apple EFI has some hacks to more easily boot legacy USB sticks, which may mean that it works better on Macs than other places. | 10:27 |
| paulsherwood | after reboot, my usb is running at least 10 times faster than before | 10:27 |
| persia | So 6 minutes then? | 10:28 |
| paulsherwood | no, i reckon it'll be 30 mins now. it was on for taking most of today, before | 10:28 |
| persia | Oh my. | 10:28 |
| * paulsherwood 'loves' software | 10:28 | |
| * paulsherwood wonders why franred has responded to richard_maw's patches the workflow tweaks thread now | 10:45 | |
| paulsherwood | the more time goes by, the more i think persia may be right to insist on killing morph edit entirely | 10:46 |
| franred | paulsherwood, they were on review and they fix some behavior that we want to fix. Remove morph edit would be a future task | 10:49 |
| paulsherwood | franred: have you tried the change? i did, at the time, but then i got distracted | 10:53 |
| paulsherwood | the actual change, not the yarns | 10:53 |
| franred | paulsherwood, not yet, I've just read the thread and reviewed the code which looks sensible | 10:55 |
| paulsherwood | i wonder if it still works. i'll try it :) | 10:55 |
| paulsherwood | all tests pass, so that's a start :) | 11:08 |
| paulsherwood | franred: do you have supercowpowers to revert a commit in morph? | 11:23 |
| franred | paulsherwood, I think so | 11:23 |
| paulsherwood | i can't see any record of a review of 23e86c643a82731aba6561321b8bb5b168e80598 on the list. and afaict it breaks morph edit for me | 11:25 |
| paulsherwood | i'm not suggesting we revert unilaterally, but if others can confirm it causes breakage, i suggest it gets taken out | 11:26 |
| paulsherwood | http://fpaste.org/128222/96605714/ | 11:28 |
| paulsherwood | so i tried the same sequence three times. first time with the always-use stuff. broke. then with head. still broken. then with 35f3a8779a316ed6a44ce5bb62bea9e2d7c67a16. works | 11:29 |
| persia | paulsherwood: From your log, I don't see how always-use-current differens from not-always-use-current | 11:34 |
| paulsherwood | i could have been clearer with my naming. the only change in each case is i used a different version of morph. | 11:36 |
| paulsherwood | HEAD is broken HEAD~1 is not, for me | 11:36 |
| persia | I believe you: I just don't see anything in your paste indicating switching beween versions of morph | 11:37 |
| paulsherwood | true. | 11:38 |
| paulsherwood | i did it in a different window | 11:38 |
| persia | Maybe next time, useful to run `morph --version` midstream :) | 11:38 |
| paulsherwood | yes indeed | 11:39 |
| persia | So, anyway, rather than fixing this, I think we should just remove morph edit: this would mean you couldn't replicate the bug, and everyone would be happy, right? | 11:39 |
| paulsherwood | i hope you are being ironic? | 11:40 |
| persia | Hard to say. I've yet to find anyone willing to tell me good things about morph edit, but I've also failed to find anyone who is willing to remove it, so whether I'm being ironic or hopeful is a difficult question. | 11:43 |
| paulsherwood | i'm ok with the general idea of removing morph edit, but i don't think this bug should be the trigger | 11:43 |
| paulsherwood | removing morph edit means fixing quite a lot of documentation. fixing this bug involves reverting one commit | 11:44 |
| persia | I can accept that. | 11:45 |
| persia | On the other hand, the implications of reverting are worrying: without this patch, we can't expect the content of a ref to be consistent, which rather breaks the definitions model. | 11:46 |
| petefoth | /me volunteers for 'fixing quite a lot of documentation' when required | 11:46 |
| paulsherwood | heh | 11:46 |
| persia | This is not a documentation issue, sadly. It's a repeatability issue. | 11:46 |
| persia | Since it has become possible to change the content available from a ref, without this class of hackery, a ref is insufficient to be able to have confidence in stable source. | 11:47 |
| paulsherwood | i think it was always possible? is this a recent thing? | 11:51 |
| persia | Relatively, yes. | 11:52 |
| persia | Err, Hmm.. Rather, it has become more prominent lately: it seems that `git replace` has been in the codebase for quite some time. | 11:55 |
| paulsherwood | in our codebase? or git's? | 11:55 |
| persia | git's | 11:55 |
| persia | So in fact, every version of morph prior to HEAD was unable to reproduce builds if the user happened to have run git replace locally. | 11:56 |
| paulsherwood | iiuc from richard_maw's explanation there would be evidence of replace in any actual repo affected by this? | 11:57 |
| persia | Yes. We should be able to detect that this was happening, and so detect if it was happening *differently* than it was happening before. | 12:00 |
| persia | What I'm less sure about is if we can cause a git-replaced environment to be git-replaced in the manner it was the last time we did something, rather than in the manner it is replaced currently. | 12:00 |
| franred | paulsherwood, I've reproduced the error, I will send the error log to the mailing list but I wouldn't like to revert the patch if it can wait until tomorrow | 12:02 |
| paulsherwood | persia: no, what i meant was, for an affected repo, wouldn't there be evidence in refs/replace/ ? | 12:04 |
| paulsherwood | if so we can visit all repos and see if there are any? :) | 12:04 |
| persia | Yes, but I'm not sure that if we find one, we can know at what point in time any given entry was added. | 12:05 |
| persia | Which makes me agree with richard_maw's initial decision to just make it not work until more thought is applied. | 12:05 |
| paulsherwood | persia: remember that algorithm script i mentioned last week? this would be a good usecase for that - check for replace on all upstreams | 12:06 |
| persia | Yep. | 12:06 |
| persia | But I'm not sure how knowing that helps anything. | 12:06 |
| paulsherwood | i'm ok with richard_maw's initial decision. i'm not ok with him breaking the default current workflow | 12:06 |
| paulsherwood | well, if there are none, it's a moot point :) | 12:07 |
| persia | No, because lorry could add one in an hour or two. | 12:07 |
| paulsherwood | at least for gbo repos to-date. | 12:07 |
| paulsherwood | fair enough - so has lorry been fixed to spot this? | 12:08 |
| persia | How do you mean "fixed"? | 12:08 |
| * persia wouldn't expect any lorry behaviour changes around this issue | 12:08 | |
| paulsherwood | ok, i may be off track here. if upstream does git replace, how do we ensure repeatability? | 12:10 |
| persia | That is the problem that remains to be solved. | 12:10 |
| persia | Perhaps there is a means to track when a given replacement entry was added. | 12:10 |
| persia | Perhaps we need to cache the state of refs/replace at the time of build. | 12:11 |
| persia | Perhaps there's another solution that doesn't come to mind immediately for me, but would be obvious to someone with a deeper understanding of git internals. | 12:11 |
| paulsherwood | so, what's the benefit of the patch, if the above remains to be solved? | 12:11 |
| persia | Note that this may also affect definitions notation, because one may want to build the same SHA with different replace contents, and may need a way to indicate that. | 12:12 |
| paulsherwood | i'm pretty sure normal users of morph would not be doing the fancy git trickery we're afraid of | 12:12 |
| persia | This patch ensures that no replace is ever followed: morph just ignores it entirely. | 12:13 |
| paulsherwood | wow | 12:13 |
| persia | Users need not: if someone pushes a replace upstream, then everyone gets it, even if they don't understand. | 12:13 |
| paulsherwood | ok. and now, suddenly, morph starts ignoring any existing replaces? amazing. | 12:14 |
| radiofree | persia: it will work without serial console and/or attached HDMI+usb | 12:14 |
| radiofree | however there's no default password, so you won't be able to login | 12:14 |
| radiofree | so you'll need.... a serial console and/or attached HDMI+usb keyboard to set the password | 12:14 |
| paulsherwood | aha, understood, thanks radiofree | 12:15 |
| persia | radiofree: Can't I just inject an ssh key? | 12:15 |
| radiofree | sure, but you'd have to do that at the deployment stage right? | 12:15 |
| persia | Ah, good point. | 12:15 |
| * persia should probably just try this, rather than speculating | 12:16 | |
| paulsherwood | back to the replace discussion - if there are any official upstream replaces, in what morph has been building, it will now build something different? | 12:17 |
| persia | paulsherwood: Hrm. Interesting point: we go from having no idea whether we can reproduce, to being able to reproduce from now, but no idea whether we can reproduce the current cache objects (as they may have used replace). | 12:17 |
| persia | Yes. | 12:17 |
| paulsherwood | revert | 12:17 |
| paulsherwood | this was not thought through, and not discussed. it may be a real problem, but this patch is not an actual solution | 12:18 |
| persia | definitions is still at 35f3a8779a316ed6a44ce5bb62bea9e2d7c67a16, so only a few folk have ever used this new broken morph. | 12:19 |
| * paulsherwood would prefer if a real git wizard could comment, since our interpretation may be wrong | 12:19 | |
| paulsherwood | true, persia. | 12:19 |
| persia | Having gone through it, despite my initial discomfort, I think I agree that unless discovery was performed to ensure there were no replace users for at least the refs in current definitions (but ideally every repo referenced by every trove in use), I agree that perhaps this is dangerous (even aside from the minor issue of it breaking a tool for which I don't see the point). | 12:21 |
| persia | If such discovery *was* performed, then I'd rather not revert the patch, as it ensures reproducibility for at least g.b.o history. | 12:22 |
| persia | (although it ought get adjusted to not break things) | 12:22 |
| * paulsherwood wonders if franred fancies helping him create a discovery script | 12:23 | |
| paulsherwood | in other news, the actual branch i was testing does not seem to behave as i expected it would. i'm thinking it would probably be better to spend time agreeing what our desired workflow should be, and get to that asap | 12:23 |
| * paulsherwood wonders what to do, to ensure the replae discussion doesn't get lost | 12:34 | |
| *** genii [~quassel@ubuntu/member/genii] has joined #baserock | 14:22 | |
| *** richard_1aw [~richard_m@xvm-21-133.ghst.net] has joined #baserock | 14:30 | |
| *** richard_maw [~richard_m@xvm-21-133.ghst.net] has quit [Ping timeout: 260 seconds] | 14:32 | |
| * paulsherwood fiddles with putting a trove into a public OpenStack, while building a new jetson image on one jetson and braining another.... | 15:40 | |
| persia | So, how well does morph cope with doing multiple things at once? | 15:41 |
| paulsherwood | i wouldn't try that. the flashing (non-morph) and openstack (morph) stuff on one br machine - the jetson build is directly on the jetson | 15:42 |
| paulsherwood | s/wouldn't try/haven't tried/ | 15:42 |
| paulsherwood | i notice that recent changes to morph (needing to specify relative paths to morph files) have invalidated some of the wiki documentation | 15:45 |
| persia | Outdated, rather than invalidated, I'd say. | 15:46 |
| persia | petefoth: Did you mention earlier you wanted to fix docs? There's an opportunity there. | 15:46 |
| paulsherwood | i've fixed the ones i've hit | 15:48 |
| * franred is still trying to fix error in gerrit, nss is not installed in the system and to compile, it we needs libc6-dev... | 16:19 | |
| franred | s/error in gerrit/the java configuration in gerrit to have access/ | 16:20 |
| persia | I'd expect NSS to build out of morphologies: do you have a log? | 16:27 |
| franred | http://fpaste.org/128321/14089845/ - this is not an error but when I try to add an user I've gotten http://fpaste.org/128322/84652140/ - I've try to solve as [1] http://stackoverflow.com/questions/3705656/openid-with-gerrit-not-working (no luck) [2] http://blog.nerdability.com/2013/01/tech-how-to-fix-sslpeerunverifiedexcept.html which tells me that http://fpaste.org/128323/14089848/ so I've tried to compile nss from debian packages | 16:44 |
| franred | getting http://fpaste.org/128324/98506314/ | 16:44 |
| franred | and looking for gnu/stubs-32.h on google, I found that I need libc6-dev | 16:45 |
| juergbi | franred: in case that's not clear, libc6-dev are just the dev files of (e)glibc | 16:57 |
| juergbi | franred: if you're building nss on x86-64, you need | 16:58 |
| juergbi | export USE_64=1 | 16:58 |
| juergbi | otherwise it tries to build a 32-bit version which won't work with a pure 64-bit glibc | 16:58 |
| juergbi | (yes, the nss build system is not particularly smart) | 16:59 |
| franred | juergbi, cheers :) - I got nss compiled (yep, it is not very smart) | 17:12 |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:52 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:10 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:10 | |
| *** franred_ [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 18:10 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 18:43 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 18:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:45 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:46 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 18:50 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:50 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 18:51 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:56 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 18:59 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:00 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 19:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 19:06 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:12 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:16 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:19 | |
| *** franred [~franred@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 19:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 19:44 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 19:56 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 20:16 | |
| *** 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: 240 seconds] | 20:22 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:23 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 20:27 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:28 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 20:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 20:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 20:42 | |
| *** 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: 255 seconds] | 20:56 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:07 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 21:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:16 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 246 seconds] | 21:32 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 21:34 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 21:54 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:00 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 22:09 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:11 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 22:17 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:23 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 260 seconds] | 22:30 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:33 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 22:51 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 22:57 | |
| *** genii [~quassel@ubuntu/member/genii] has quit [Remote host closed the connection] | 23:04 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 23:12 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:25 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 250 seconds] | 23:37 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:38 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 23:53 | |
| *** flatmush [~flatmush@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 23:54 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!