[06:17] <al-maisan> Good morning!
[09:56] <jtv> henninge: care to review?
[09:56] <jtv> https://code.edge.launchpad.net/~jtv/launchpad/bug-440445/+merge/12777
[10:03] <henninge> jtv: so you are assuming that it will also need access to language and translator?
[10:04] <jtv> henninge: yes; it's looking at TranslationGroup to check for membership, and that definitely involves Translator.
[10:04] <henninge> jtv: valid assumption, I guess.
[10:05] <henninge> jtatum: r=me
[10:05] <jtv> Not sure about Language, but it's one of those things that are likely to be fetched by the ORM as a side product
[10:05] <jtv> henninge: no, the other person.  :)  Thanks.
[10:05] <henninge> jtv: r=me
[10:05] <jtv> :)
[10:05] <henninge> jtatum: whatever branch you want reviewed, I have *not* approved it! ;-)
[10:05] <henninge> jtatum: sorry to bother you ...
[10:07] <henninge> jtv: please remember to set the mp to "approved". For some reason I cannot do it.
[10:07] <jtv> henninge: sure, thanks
[10:19] <al-maisan> hello adeuring -- could you please have a look at a small/simple branch?
[10:19] <al-maisan> it is here: https://code.launchpad.net/~al-maisan/launchpad/cmsg-425800/+merge/12774
[10:19] <adeuring> al-maisan: I'm already doing this :)
[10:19] <al-maisan> adeuring: ah, wow!
[10:20] <al-maisan> adeuring: I am duly impressed :)
[10:29] <adeuring> al-maisan: there are two new tests: test_requestMirror_doesnt_demote_branch() and test_requestMirror_can_promote_branch(). Perhaps I'm missing something obvoius there -- but isn't future_time in the latter test a timestanp in the past: future_time = datetime.now(pytz.UTC) - timedelta(days=1) ?
[10:29]  * al-maisan looks
[10:30] <al-maisan> adeuring: argghh
[10:30] <al-maisan> the diff generated for the MP is wrong
[10:30] <al-maisan> just a minute
[10:31] <al-maisan> adeuring: http://pastebin.com/m4c94727b
[10:32] <al-maisan> sorry about that
[10:32] <al-maisan> this is a *really* simple branch
[10:32] <al-maisan> bbiab
[10:32] <adeuring> al-maisan: Ah, indeed quite much shorter ;)
[10:32] <adeuring> al-maisan: but the other test is there nevertheless ;)
[10:33] <al-maisan> adeuring: aha
[10:34] <al-maisan> adeuring: I don't see any of that in the diff I provided you with
[10:34]  * al-maisan rubs his eyes
[10:34] <adeuring> al-maisan: what I menat: I am simply curious about this test, even it is is not part of the patch.
[10:35] <al-maisan> adeuring: yep, 'future_time' would have to lie in the past .. provided the time on the test machine is set correctly :)
[10:37]  * adeuring is quite confused... future time in the past?
[10:37] <adeuring> al-maisan: but let's put that aside.
[10:38] <adeuring> al-maisan: al-maisan: just one question about the short diff: You removed the text "Did you mean to upload to a PPA?". Isn't this sometimes a useful hint for users?
[10:38] <al-maisan> adeuring: not really .. it would rather confuse people
[10:38] <adeuring> al-maisan: OK, so r=me
[10:39] <al-maisan> adeuring: thanks
[10:41] <allenap> adeuring: Fancy a devscripts.ec2test branch to review?
[10:41] <allenap> https://code.edge.launchpad.net/~allenap/launchpad/ec2-test-race-bug-422433/+merge/12778
[10:41] <adeuring> allenap: sure
[10:41] <allenap> adeuring: Thanks :)
[10:51] <bigjools> al-maisan: don't remove that error text
[11:03] <al-maisan> bigjools: alright; what do you suggest instead?
[11:03] <bigjools> al-maisan: I don't have any context - what are you doing?
[11:04] <al-maisan> bigjools: https://bugs.edge.launchpad.net/soyuz/+bug/425800
[11:04] <mup> Bug #425800: confusing message if signer can upload packages from some package sets but not others <packagesets> <soyuz-upload> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/425800>
[11:05] <bigjools> al-maisan: that error text is still correct, but only if the uploader has no packagesets
[11:05] <bigjools> he can upload to
[11:06] <al-maisan> bigjools: that's not quite right.
[11:06] <al-maisan> this error message indicates that the uploader has no upload permissions whatsoever
[11:06] <bigjools> al-maisan: yes, that's exactly what I mean
[11:07] <bigjools> so the existing check for that error text needs to also check packagesets
[11:07] <al-maisan> however, he may end up in this situation if he has *some* package set based permissions but is lacking one
[11:07] <bigjools> no, that is wrong
[11:08] <al-maisan> hmm .. I looked at the code .. the source package based permissions (including package sets) are checked before this error is raised
[11:09] <bigjools> the error should be raised if the upload has no component-based *and* no packageset-based permissions
[11:09] <al-maisan> is that error (formulated that way) useful in first place?
[11:10] <bigjools> yes - it distinguishes between NO permissions and SOME permissions but the wrong ones
[11:10] <al-maisan> aha
[11:10] <bigjools> PPA packages fall foul of it a lot, hence the extra text
[11:11]  * al-maisan takes another look at verify_upload()
[11:12] <bigjools> al-maisan: basically if the uploader is trying to upload to say, main, but only has universe permissions, this error is not used
[11:12] <bigjools> the same needs to apply with packagesets
[11:12] <al-maisan> bigjools: I see what you mean.
[11:12] <bigjools> great
[11:50] <adeuring> allenap: r=me
[11:50] <allenap> adeuring: Thanks :)
[11:51] <adeuring> allenap: what I forgot to say iin the review: thanks for splitting the diff into two parts!
[11:52] <allenap> adeuring: I'm glad it helped :)
[13:55] <allenap> adeuring: I replied to your review of ec2-test-race-bug-422433 with an incremental diff. Could you sanity check it, then I'll send it all off to ec2? Thanks.
[14:02] <adeuring> allenap: looks good. Thanks for the change!
[14:02] <allenap> adeuring: Thanks.
[14:19] <noodles775> barry, have you checked some bug pages also? The "Bug #440220 reported by Barry Warsaw 16 hours ago" is also using the registration slot iirc...
[14:19] <mup> Bug #440220: registering slot interferes with watermark <post-ui-3-cleanup> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/440220>
[14:19] <noodles775> which means that it will *always* wrap (unless you've got a 2m screen ;) ).
[14:20] <barry> noodles775: right.  let me paste a bug page s/s
[14:23] <barry> noodles775: attached two more s/s.  they do always wrap but it doesn't look too bad to me
[14:26] <noodles775> barry, I think the thing I don't like is that it's wrapping when it doesn't need to.
[14:27] <noodles775> Have you tried leaving it where it was after adding the no_wrap on the app-tabs?
[14:28] <barry> noodles775: it will run into the tabs if the registering contents are long (long person name).  maybe that's rare enough to not worry about it though?
[14:30] <noodles775> barry, if you give the registration slot a large left-margin (maybe 2em) it shouldn't get too close? (and will wrap since the app tabs can't, iirc?)
[14:30] <barry> noodles775: e.g. this does not look as good to me: http://launchpadlibrarian.net/32862698/ff-nowrap.png
[14:31] <barry> noodles775: that's a possibility too.  i kind of like that the registering information sits neatly above the portlet
[14:33] <noodles775> barry, hmm.... to me it often (ie. with longer slots like on bugs pages) looks like it's been squashed into a space that's too small.
[14:34] <noodles775> barry, I personally agree with rockstar's comment - if it was just below the app tabs, it wouldn't need to wrap at all, and would not interfere... but maybe there's a reason for not doing that?
[14:34] <barry> noodles775: it is a pretty small space (21%).
[14:34] <barry> noodles775: i definitely want to explore that, but iirc beuno really wants that registering slot on the right side
[14:35] <barry> noodles775: so i kind of wanted to run that to ground to see if we could make it work
[14:35] <noodles775> barry, it would be on the right side wouldn't it? I just mean a little bit down from where it is in the last link above.
[14:36] <barry> noodles775: hmm... possibly so.  give me a few minutes and i'll try that
[14:36] <noodles775> k
[14:36] <barry> btw, thanks!
[14:37] <noodles775> np!
[14:48] <barry> noodles775: take a look at the s/s in comments 13-16
[14:51] <noodles775> barry, what do you think? My first thought is that the only thing that looks ugly about it is the super long username?
[14:53] <barry> noodles775: agreed.  i just did that to see worst case.  this works for me
[14:55] <noodles775> barry, great. Thanks for fixing it!
[14:55] <barry> noodles775: thanks!  can i request you as one of the two ui reviewers for the branch?
[14:55] <noodles775> barry, sure!
[14:55] <barry> awesome
[15:07] <barry> adeuring: ping
[15:07] <adeuring> barry: yes?
[15:07] <barry> adeuring: have time for a 39 line CSS review?
[15:07] <adeuring> barry: sure
[15:07] <barry> cool.  sending mp now
[15:20] <adeuring> barry: I have also an MP (a bit larger than yours, but just trivial refactoring): https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-refactor-haldevice-3/+merge/12733 could you review it?
[15:26] <barry> adeuring: sure!  this feels so incestuous though :)
[15:26] <adeuring> barry: ;)
[15:33] <adeuring> barry: r=me
[16:06] <barry> adeuring: thanks!
[16:11] <barry> adeuring: did you request me as a reviewer on your branch?
[16:11] <adeuring> barry: no
[16:11] <barry> adeuring: url?
[16:11] <adeuring> barry: https://code.edge.launchpad.net/~adeuring/launchpad/hwdb-refactor-haldevice-3/+merge/12733
[16:22] <al-maisan> hello adeuring, can you please have a look at the fix for bug #425800 (2nd try) ?
[16:22] <mup> Bug #425800: confusing message if signer can upload packages from some package sets but not others <packagesets> <soyuz-upload> <Soyuz:In Progress by al-maisan> <https://launchpad.net/bugs/425800>
[16:22] <al-maisan> https://code.launchpad.net/~al-maisan/launchpad/cmsg-2-425800/+merge/12791
[16:22] <adeuring> al-maisan: sure
[16:22] <al-maisan> adeuring: thanking you :)
[16:26] <barry> adeuring: when you raise NotImplementedError in your properties, you don't need to instantiate them if they have no arguments.  Python will DTRT for you here, and it's also somewhat more efficient
[16:27] <adeuring> barry: Ah, thanks! didn't know that
[16:27] <adeuring> (Though I hope the excpetion will never be raised ;)
[16:28] <barry> adeuring: if the exception has arguments, instantiating it in place is the right thing to do though.
[16:28] <barry> adeuring: right! :)
[16:32] <adeuring> al-maisan: r=me
[16:33] <al-maisan> adeuring: thank you very much!
[16:33] <adeuring> al-maisan: immer gerne :)
[16:33] <al-maisan> adeuring: :)
[16:38] <barry> adeuring: with that fix, r=me
[16:38] <adeuring> barry: thanks!
[16:40] <barry> rockstar: ping
[16:40] <rockstar> barry, yo
[16:41] <barry> rockstar: hiya!  could you do a quick second ui review on https://code.edge.launchpad.net/~barry/launchpad/440220-slot/+merge/12786
[16:41] <rockstar> barry, sure.
[16:41] <barry> rockstar: thanks!
[16:41] <mrevell> barry: Can you take a look at small help branch? https://code.edge.launchpad.net/~matthew.revell/launchpad/bug-215798/+merge/12792
[16:42] <barry> mrevell: sure thing
[16:42] <mrevell> thanks barry
[16:43] <barry> mrevell: did you forget to bzr add register-branch.html perhaps?  it's not in the diff
[16:43]  * mrevell hangs head in shame
[16:44] <mrevell> barry: Yup. Sorry. Pushing new version now
[16:44] <mrevell> barry: done
[16:44] <barry> mrevell: can you add the file as a comment.  i don't think the mp will update the diff
[16:44] <rockstar> mrevell, I have bzr ci aliased to `bzr commit --strict` and I use that all the time.  It makes sure you don't have any rogue files laying around.
[16:44] <barry> rockstar: +1
[16:44] <rockstar> barry, it will update the diff.
[16:44] <mrevell> barry: I thought we had moving diffs now
[16:44] <mrevell> rockstar: thanks for the top!
[16:45] <rockstar> barry, it updates the diff on push of the source branch now.
[16:45] <barry> rockstar: \o/
[16:45] <mrevell> s/top/tip
[16:45] <rockstar> barry, abentley is pretty amazazing.
[16:45] <barry> rockstar: he's amazing, too!
[16:46] <mrevell> :)
[16:46] <rockstar> barry, I was using a word from a movie, so the apparent typo was actually purposeful.
[16:46] <barry> rockstar: oh!  what movie?
[16:48] <rockstar> barry, it's from "The Benchwarmers"  The dialogue goes something like "You guys think you're ath-a-letes now?"  "I didn't know athletes had three syllables.  That's amazazing!"


[04:08] <hatch> Makyo I found the culprit
[04:09] <Makyo> hatch, oh yeah?
[04:09] <hatch> yep it's the tokens
[04:09] <hatch> the delay was so odd because it was locking up the UI layer
[04:09] <Makyo> What was causing the problem within the tokens?
[04:10] <hatch> I haven't quite narrowed it down but the Widget/WidgetParent/WidgetChild stuff seems to be draining a ton of cycles
[04:10] <hatch> these will probably need to be converted to views
[04:12] <hatch> it takes up to 300ms per token to render
[04:13] <hatch> instantiation is fast though so it might not be related to the widget bits
[04:13] <hatch> still  need to do more digging there
[04:13] <Makyo> Yikes, yeah.  I was wondering where those cycles were disappearing, since it didn't seem to be any of the blobs I'd debugged.  Lets sync up tomorrow morning after the call or something to try and nail this down further.
[04:15] <hatch> 1.21s PER frame when it's doing that lol
[04:15] <hatch> high perf man
[04:15] <hatch> haha
[04:16] <hatch> yeah definitely, we now have a starting point
[04:18] <Makyo> Yep!
[04:18] <Makyo> I'm crashing, though, damn meds.  Catch up tomorrow morning?
[04:23] <hatch> fo sho!
[04:24] <hatch> I'm also done for the night
[07:53] <rogpeppe> hmm, i'm getting this from the canonical irc servers:
[07:53] <rogpeppe> The certificate authority's certificate is invalid
[07:53] <rogpeppe> The root certificate authority's certificate is not trusted for this purpose
[07:53] <rogpeppe> The certificate cannot be verified for internal reasons
[07:54] <rogpeppe> anyone else seeing the same thing?
[07:56] <huwshimi> rogpeppe: I'm seeing the same thing, but I've asked a couple of other people and they seem to connecting be ok.
[07:56] <rogpeppe> huwshimi: ok. so it's not just me. the bad guys are selectively targeting us :-)
[07:56] <huwshimi> :)
[07:56] <rogpeppe> huwshimi: so did you just continue to connect anyway?
[07:57] <huwshimi> rogpeppe: I can't connect at all.
[07:57] <rogpeppe> huwshimi: hmm, i have a "Continue" option, but I don't want to use it, as it potentially gives a middle man total access to canonical IRC
[07:58] <huwshimi> rogpeppe: I've just done without today.
[07:59] <rogpeppe> huwshimi: the odd thing is this line "The root certificate authority's certificate is not trusted for this purpose"
[08:00] <rogpeppe> huwshimi: i wonder what purpose it's trying to verify against
[08:00] <rogpeppe> huwshimi: what IRC client do you use?
[08:00] <huwshimi> rogpeppe: xchat-gnome
[08:00] <rogpeppe> huwshimi: hmm, bang goes that theory :-)
[08:01] <huwshimi> rogpeppe: Which tells me the certificate may have expired.
[08:01] <rogpeppe> huwshimi: the cert is valid until 2015
[08:01] <huwshimi> rogpeppe: Oh :)
[08:02]  * rogpeppe wishes that certificates were more humanly readable, rather than entirely obscure ASN.1
[08:05] <huwshimi> Well, I'm done for the day, hopefully they resolve it tonight!
[08:05] <huwshimi> rogpeppe: Have a good day :)
[08:05] <rogpeppe> huwshimi: see ya :-)
[09:07] <frankban> rogpeppe: morning, git migration completed! could you please move the card you are working on in the code lane? oh, also, the card from yesterday (http.go) should be moved to daily accomp. thanks. FWIW, I used this quick and dirty script to check packages' deps: http://pastebin.ubuntu.com/7586126/
[09:10] <rogpeppe> frankban: just FYI, you could do {{join .$2 "\n"}} rather than the range loop (well, modulo some quoting issues :-])
[09:11] <rogpeppe> frankban: nice script BTW
[09:13] <frankban> rogpeppe: thanks, it seems I have to work on a JS branch this morning, hope to be able to switch back to our migration plan asap this afternoon.
[09:13] <rogpeppe> frankban: ok
[12:33] <hazmat> woot, bzr installable via pip
[12:40] <hazmat> iotl == internet of things light ;-)
[13:08] <redir> morning
[13:09] <kadams54> morning
[13:10] <rogpeppe> frankban: your script didn't quite do what i was after (i wanted it a little more scriptable), so i took 30 minutes to write a slightly different version. http://paste.ubuntu.com/7587381/
[13:11] <frankban> rogpeppe: nice! bash also looks better in your version ;-)
[13:12] <bac> hi frankban.  did you see my change to quickstart re: tls?
[13:13] <frankban> bac: yeah, that's awesome, good to see the solution was that simple. thank you!
[13:14] <bac> frankban: i wish it were so simple for jujuclient...  it uses websocket.create_connection, which has no sslopt.
[13:14] <bac> not sure how much surgery would be required to replace with WebSocket object use
[13:14] <bac> s/WebSocket/WebSocketConnection/
[13:16] <frankban> bac: it should be similar to what we do in quickstart (and originally we did that for other reasons, logging stuff IIRC). perhaps we can contribute upstream by adding the sslopt to create_connection
[13:16] <bac> frankban: that's a thought...
[13:17] <jcsackett> morning (or afternoon) all.
[13:21] <frankban> bac: actually it seems you can already pass sslopt to create_connection: https://github.com/liris/websocket-client/blob/v0.12.0/websocket.py#L198
[13:23] <bac> frankban: silly me, i believed the docstring
[13:23] <bac> options: current support option is only "header".
[13:23] <bac>              if you set header as dict value, the custom HTTP headers are added.
[13:24] <bac> and didn't think the sslopt was part of the headers
[13:28] <frankban> bac: yeah that docstring was never updated :-/ and no longer reflects reality: it seems it used to in a very old version: https://github.com/liris/websocket-client/blob/v0.9.0/websocket.py#L172
[13:29] <frankban> bac: so it actually seems your solution can also fix jujuclient \o/
[13:30] <bac> frankban: so it should be quite easy to update jujuclient.  i'll update the bug and make a slack card.  it is no longer directly affecting us, afaict.
[13:31] <frankban> bac: no, since we use a customized way to establish the ws connection it doesn't affect us now
[13:31] <frankban> bac: so +1
[13:53] <hatch> bac can you kick comingsoon? It's not updating the css again
[13:54] <bac> hatch: i will.  should i not be around recall that you can too.
[13:54] <hatch> oh?
[13:54] <hatch> are instructions in the wiki?
[13:55] <bac> hatch: instructions?
[13:55] <bac> hatch: try it now.  is it still messed up?
[13:56] <hatch> yeah - like how to log into the server and whatnot
[13:56] <bac> it's the whatnot that always bites you
[13:56] <hatch> bac yesh it's still broken
[13:56] <bac> urhg.
[13:57] <bac> hatch: ok, doing a make clean build-prod now
[13:57] <hatch> thanks
[13:57] <hatch> any idea why it does this?
[13:57] <bac> hatch: now?
[13:58] <hatch> bac yep fixed, thanks
[13:58] <hatch> luca comingsoon is ready
[13:59] <bac> hatch: we're missing some dependency in the css generation part of the makefile
[13:59] <bac> hatch: i'll make a card
[13:59] <luca> hatch: thanks
[13:59] <hatch> bac great thanks
[14:00] <hatch> luca there are a couple known bugs - no databdinging on unit details breakout, and slow rendering when switching between views in the sidebar, anything else that you find that should block release lemme know!
[14:01] <hatch> databinding
[14:03] <luca> hatch: thanks
[14:03] <luca> hatch: I’ll check it out
[14:04]  * rogpeppe goes to grab some lunch
[14:05] <frankban> guihelp: I need two reviews and QA for https://github.com/juju/juju-gui/pull/363 . Anyone available? thanks!
[14:05] <hatch> on it
[14:05] <kadams54> frankban: I can take a look.
[14:05] <hatch> thanks for picking this up frankban!
[14:05] <frankban> thank you both!
[14:05] <bac> hatch: hey, it was already there.  including the whatnot: https://wiki.canonical.com/CDO/Juju/GUI/CI?highlight=%28comingsoon%29
[14:06] <hatch> oh look I have access
[14:06] <hatch> lol
[14:06] <bac> hatch: give it a run sometime and let me know if that doc is incomplete
[14:06] <hatch> sure I'll try and get to it today
[14:11] <frankban> rogpeppe: are you migrating utils?
[14:14] <rick_h_> Makyo: around?
[14:17] <rogpeppe> frankban: yup
[14:18] <rogpeppe> just trying to figure out how filter-branch works
[14:19] <redir> rogpeppe: what are you trying to do?
[14:19] <rogpeppe> redir: factor utils out of juju-core
[14:19] <redir> what have you tried?
[14:19] <redir> or what are you trying
[14:21] <hatch> rick_h_ not sure if you saw the scrollback but last night I found the perf issue
[14:23] <rogpeppe> redir: this (suggested by frankban) seems to have worked: git filter-branch --subdirectory-filter utils -- --all
[14:23] <redir> rogpeppe: http://pastebin.ubuntu.com/7587828/ notes from my brief look at removing store
[14:24] <rogpeppe> redir: i just wanted to have some idea of what it was actually doing
[14:24] <hatch> frankban comments made - could you check them out and reply before I hop on QA'ing
[14:25] <frankban> rogpeppe: great! redir: yeah that's the same command, and we no longer need bzr-export since we start from a git repo
[14:26] <rogpeppe> hmm, apparently i no longer have permission to create repos in github.com/juju
[14:26] <redir> right so clone, promote, add remote, push
[14:27] <frankban> rogpeppe: could you please take notes while doing the migration, so that we can follow those when moving other parts (and eventually also merge those notes in juju docs)? Also, when you actually start, could you please send an email to juju-dev saying we are migrating a utils/*?
[14:27] <redir> oh, I missed something
[14:29] <redir> clone, promote, add remote, push promoted, whatnot in core, commit, push updated core
[14:29] <redir> the all important whatnot
[14:29] <frankban> redir, rogpeppe: I imagine it would be 1) create juju/utils in github, 2) fork in github 3) clone the fork 4) add juju/utils/ as remote upstrem 5) create a new local branch 6) migrate 7) push to origin 8) propose the branch
[14:30] <frankban> then remove the moved parts and fix imports in core
[14:30] <frankban> (and also update dependencies
[14:33] <luca> hatch: the charm details link in the IotL doesn’t work
[14:33] <redir> frankban: can you rewtrite history only in a local branch? won't that affect the whole repo?
[14:33] <hatch> luca what does IotL stand for?
[14:33] <hatch> I know it means Inspector Left but the letters are all garbled
[14:33] <hatch> lol
[14:34] <luca> hatch: Inspector on the Left
[14:34] <hatch> luca, confirmed - can you create a bug plz
[14:34] <luca> not…garbled…
[14:34] <hatch> ohhh :)
[14:35] <hatch> brb
[14:35] <frankban> hatch: replied on your comments
[14:38] <rogpeppe> so, a git weirdness - i thought git checkout updates all the files in the current working directory, but after doing the above filter-branch command (in a new branch), i did "git checkout master" to revert to the original juju master, and no files changed
[14:38] <frankban> redir: not sure if I understood your question: we need to split the juju/juju history, then create a juju/utils branch with the history obtained by splitting out utils. At that point we just propose a local juju/utils branch (with the history) to be merged into the newly created (and empty) upstream, right?
[14:39] <rogpeppe> i then tried removing all the files other than .git, and it is still not checking out the files
[14:39] <frankban> rogpeppe: git reset --hard?
[14:39]  * frankban bbiab
[14:40] <redir> rogpeppe: that may only have an effect on the INDEX so you may need to reset --hard to make the directory reflect the changes to the index
[14:40] <redir> like frankban said
[14:41] <rogpeppe> pwd
[14:41] <redir> rogpeppe: /irc
[14:41] <rogpeppe> hmm, git reset --hard did bring some files back (why didn't checkout do that?) but it brought back the files from the new branch, not master
[14:42]  * rogpeppe doesn't understand the subtle difference between checkout and reset
[14:42] <hatch> frankban thanks
[14:43] <rogpeppe> redir: i don't know about INDEX
[14:43] <rogpeppe> redir: is that a manifest of files on disk?
[14:43] <redir> frankban: I think we are saying the same thing. I was interpreting your steps as all in the same repo with different local branches and remotes for different upstream repos, which I don't think would work. However, reading your clarification I understand you are working in two repos
[14:44] <hatch> frankban I was under the impression that the ghost service callback converted the ghost service into a real service
[14:44] <redir> rogpeppe: something like that, I don't really get into git that deeply usually as I don't need to
[14:45] <rogpeppe> redir: i was just trying to understand the git-reset help page, which mentioned the "index" all over the place
[14:45] <redir> rogpeppe: index is like the staging area
[14:45] <redir> so you make changes in the directory
[14:46] <rogpeppe> redir: ah, that's where "git add" puts stuff to i guess
[14:46] <redir> then you git 'add' it and that tells the index to stage the change
[14:47] <redir> so a lot of the filter-branch and fast-import and other bits actuall just update the index
[14:47] <redir> letting you commit later
[14:47] <redir> also impying that your directory isn't up to date when only the index is altered
[14:47] <redir> or something like that
[14:48] <rogpeppe> redir: i don't think that can be the case with filter-branch, because it's rewriting all of history
[14:48] <rogpeppe> redir: so it surely must update HEAD and everything it points to?
[14:49] <redir> rogpeppe: idk, because I haven't had to use filterbranch much -- mostly only to remove sensitive info from repos:)
[14:49] <redir> and usually I am in a panic at that point, so not much sticks other than get it out get it out
[14:50] <Makyo> jujugui call in 10
[14:50] <redir> but I think head is just like a sticky note pointing at the place you are working (most recent commit)
[14:50] <redir> rogpeppe: ^^
[14:51] <redir> so adding a commit just moves the sticky note to point at then newly added commit (new head)
[14:51] <rogpeppe> redir: yeah, but if i do "git checkout master", it should bring me back to where i was
[14:52] <redir> rogpeppe: if you rewrote history it would bring you back to where you were rewritten to
[14:52] <redir> or somehtign
[14:52] <redir> rogpeppe: I try hard not to peek under the git porcelin
[14:54] <rogpeppe> hmm
[14:54] <rogpeppe> the odd thing is, i haven't done a single commit
[14:54] <rogpeppe> and everything seems to have changed on master and on my checked-out branch
[14:55] <rogpeppe> this is what my reflog looks like
[14:55] <rogpeppe> http://paste.ubuntu.com/7587997/
[14:55] <redir> rogpeppe: I think you noted that if you fitler-branch --some-filter it rewrites history for you. If you want to pair for a minute, I can pretend to know more about git than I really do
[14:56] <rogpeppe> redir: let's do that after the standup
[14:56] <redir> ok
[14:56] <rogpeppe> redir: or actually, let's join the standup now and see how far we get :-)
[14:57] <rick_h_> hatch: didn't see it. What was up?
[14:57] <rick_h_> Makyo: reping
[14:57] <Makyo> rick_h_, oops, missed the earlier one, what's up?
[14:57] <rick_h_> Makyo: got a sec for a call?
[14:57] <hatch> rick_h_ the perf issue is somewhere in the token widget parent/child rendering
[14:57] <Makyo> Sure
[14:58] <redir> brt, biobreak pre stanup
[15:11] <bac> jujugui: was my audio less awful today via the phone?
[15:12] <rogpeppe> redir: i fixed the issue by manually resetting to a revid i found in the reflog
[15:12] <rogpeppe> redir: but i have no idea how i ended up in the state i did
[15:12] <redir> rogpeppe: cool
[15:13] <redir> rogpeppe: that will prolly happen several more times:)
[15:13] <rogpeppe> redir: it looks like filter-branch changed two branches at once
[15:13] <redir> rogpeppe: I think it does
[15:13] <rogpeppe> redir: really?!
[15:14] <redir> rogpeppe: have you read this http://bit.ly/1i0DBcw
[15:16] <rogpeppe> redir: i've read something pretty similar in the past. nice summary.
[15:17] <redir> rogpeppe: right so if you rewrite a commit, that commit is used in several branches -- because it is all one graph -- then both branches h ave changed
[15:17] <rogpeppe> redir: i don't think that quite gets into why filter-branch changes two branches at once rather than just affecting the current branch
[15:18] <rogpeppe> redir: um, i was under the impression that commits weren't really rewritten, but just that a whole new history was fabricated and HEAD changed to point to that new history
[15:19] <redir> history rewritten equal new different commits in the graph and new trees under those commits
[15:20] <redir> rogpeppe: so why wouldn't it affect all branches?
[15:20] <redir> they aren't clones like in bzr
[15:20] <rogpeppe> redir: but doesn't each branch have an associated revid?
[15:20] <redir> I think revid is a bzr term
[15:20] <rogpeppe> redir: SHA-1 hash
[15:20] <rogpeppe> redir: whatever the term is
[15:20] <redir> ahh
[15:21] <redir> a sha1 hash its a commit
[15:21] <frankban> rogpeppe, redir: so the lesson here is that when we split packages we have to use an ad-hoc juju clone right?
[15:21] <redir> which points at a tree (dir structure)
[15:21] <redir> rogpeppe: ^^
[15:21] <redir> frankban: yes I think so
[15:22] <frankban> thanks redir
[15:23] <rogpeppe> redir: what's the right git name for the SHA hash that you see
[15:23] <rogpeppe> ?
[15:24] <redir> rogpeppe: I think they are just ids for commit objects that you are dealing with
[15:25] <rogpeppe> redir: right
[15:25] <redir> so they are just commiits
[15:25] <rogpeppe> redir: so each branch points to a particular commit object, right?
[15:25] <redir> right but more than one branch can point at the same commit object
[15:25] <rogpeppe> redir: and if you operate on a branch, it updates the commit object pointed to by that branch, yes?
[15:26] <rogpeppe> redir: but the branch points to the commit object via its id, no?
[15:26] <redir> it should create a new commit object pointing at the associated tree and blob objects
[15:26] <rogpeppe> redir: rather than pointing to a mutable thing
[15:26] <redir> the id is a hash of the object and an header (commit msg, etc)
[15:27] <redir> each commit updates the graph and points the branch at the new commit
[15:27] <redir> fo rthat branch
[15:28] <redir> but if you change an existing commit it changes it for anything in the graph that uses that commit
[15:28] <redir> hopefully I am making some sense
[15:29] <rogpeppe> redir: the point i'm finding odd is "changing an existing commit"
[15:29] <rogpeppe> redir: that implies that branches have some kind of a symbolic reference to the commit rather than just storing a hash of it
[15:30] <redir> rogpeppe: rewriting history updates the graph, the blobs, trees, commits, and tags
[15:30] <hatch> frankban should I be able to drag and drop a token on a container with a service in it?
[15:30] <rogpeppe> redir: and if so, that turns everything i *thought* i knew about git on its head
[15:30] <rogpeppe> redir: but it doesn't *change* any of the existing blobs, does it?
[15:30] <rogpeppe> redir: it just adds new ones, no?
[15:30] <redir> rewriting history changes them
[15:31] <redir> depending on what is rewritten
[15:31] <rogpeppe> redir: i'm not sure how it's possible to change a blob, because everything is content-addressed
[15:32] <frankban> hatch: drag a token on a container?
[15:32] <redir> well if you want to remove a password from a file you rewite history
[15:32] <redir> which changes a file
[15:32] <hatch> frankban yeah so drag and deploy mysql to a machine, confirm, then drag another token to the bare metal on that machine
[15:33] <hatch> it throws an error notification now
[15:33] <redir> rogpeppe: and that blob then hash a different hash value
[15:33] <rogpeppe> redir: so if i do "git branch --list -v", i see the branches and the hashes of their commit objects
[15:33] <hatch> this may have always been broken but I'm pretty sure you can deploy to a container
[15:33] <hatch> with something else in it
[15:33] <rogpeppe> redir: are you saying that if i do a filter-branch on one branch, the hash of the commit object for another branch can change?
[15:34] <frankban> hatch: it does not work, and needs to be fixed
[15:34] <redir> rogpeppe: that is my understanding
[15:34] <hatch> frankban but that's out of scope of this branch right?
[15:34] <redir> because it is not it's own repo
[15:34] <frankban> hatch: is it a regression introduced by this branch?
[15:35] <redir> rogpeppe: should be easy enough to do an experiment:)
[15:35] <rogpeppe> redir: wow. so even though i've done "checkout -b" to try and isolate my changes, the original branch gets mutated anyway.
[15:35] <rogpeppe> redir: so if you use filter-branch, you'd *always* need to use the reflog to rewind that other branch
[15:36] <redir> rogpeppe: if you do it in one repo yes
[15:36] <hatch> frankban ahh I don't know - yours makes it error, whereas before it would just create a new machine haha
[15:36] <hatch> I'm going to say - out of scope for your branch :)
[15:36] <frankban> hatch: ok cool then :-)
[15:37] <redir> rogpeppe: if I am understanding everyting we are talking about correctly I think the answer is yes
[15:37] <hatch> +1'd
[15:37] <frankban> hatch: now that a pattern is established, it shouldn't be hard to fix all the variations
[15:37] <hatch> frankban yeah true true
[15:38] <hatch> who knew ECS would end up being so complex :)
[15:38]  * rick_h_ raises hand
[15:38] <rick_h_> :P
[15:38] <rogpeppe> redir: wow, you're right.
[15:38] <redir> rogpeppe: there's a first
[15:38] <rogpeppe> redir: that is so counter-intuitive
[15:38] <redir> quick record this moment!
[15:38] <rogpeppe> :-)
[15:39] <rogpeppe> so i guess a branch must be more than just a (SHA hash) pointer
[15:39] <redir> rogpeppe: when you do those kinds of perations it does tore a back up somewhere in .git but I don't know the details of the top of my head
[15:40] <redir> rogpeppe: just different from bzr
[15:40] <rogpeppe> redir: when i did the operation again, it said this:
[15:40] <rogpeppe> Cannot create a new backup.
[15:40] <rogpeppe> A previous backup already exists in refs/original/
[15:40] <rogpeppe> Force overwriting the backup with -f
[15:40] <redir> yeah there
[15:40] <redir> I usually do rewrites in a whole seperate clone
[15:41] <redir> and keep a pristine copy in case something happens later
[15:41] <redir> and I need it
[15:41] <redir> at least for a reasonable period
[15:41] <rogpeppe> ah! i got it!
[15:41] <rogpeppe> i think
[15:41]  * rogpeppe checks
[15:42] <frankban> rogpeppe: git supports both clones a-la bzr and branches. IIUC with checkout you just navigate the tree, and that's why they are so fast, and maybe that's also the reason why when you rewrite history you really rewrite history. it does not seem that weird to me. in our case, we need to use clones
[15:42] <redir> rogpeppe: branches with different histories in bzr don't make sense to me
[15:43] <redir> it is very rare that I need a seperate clone (bzr branch)
[15:43] <redir> rogpeppe: frankban nailed it there
[15:43] <redir> I htink
[15:43] <rogpeppe> redir: actually, i think i was right :-)
[15:44] <rogpeppe> redir: the culprit was the --all argument to the filter-branch command
[15:44] <redir> I thought I was wrong, turns out I was right
[15:44] <redir> ah all branches
[15:44] <rogpeppe> redir: which was specifically asking to rewrite history on *all branches*
[15:44] <frankban> redir: in bzr some of us works with lightweight checkouts which mimic named branches and allow us to always work in the same directory
[15:44] <rogpeppe> redir: if you just specify the current branch, it works just as i'd thought
[15:44] <rogpeppe> phew
[15:45] <redir> frankban: yes but it still creates real branches in real directories somewhere else
[15:46] <rogpeppe> frankban: FWIW when you rewrite history, you don't really rewrite history
[15:46] <frankban> redir: yes, that's true, well, real branches, you can init your repo with --no-tree so that no files are written on disk, but yes, they are not as lightweight as git ones
[15:46] <hatch> kadams54 I
[15:46] <hatch> bah
[15:46] <rogpeppe> frankban: you just rewrite the history of the current branch
[15:46] <hatch> kadams54 I'm thinking that the cards you created should probably go in On Deck or Pool until we put a priority on them
[15:46] <rogpeppe> frankban: or whatever branches you've specified
[15:46] <hatch> thoughts?
[15:46] <kadams54> Sure
[15:47] <frankban> rogpeppe: cool even better then
[15:47] <redir> rogpeppe: I'd be wary of thinking that you are at the bottom of it:)
[15:47] <rogpeppe> redir: i am still very wary :-)
[15:48] <rogpeppe> redir: but at least experiment seems to support that point of view :-)
[15:48] <Makyo> jujugui tiny branch https://github.com/juju/juju-gui/pull/364
[15:48] <frankban> rogpeppe: I'd be still inclined to use a disposable clone for this kind of work ;-)
[15:49] <redir> rogpeppe: I think you are right, but I can imagine scenarios where things end up different than you expect
[15:49] <hatch> Makyo on it
[15:49] <rogpeppe> frankban: BTW, what was the reason you gave the --all flag to filter-branch?
[15:49] <redir> also in the case of promoting a sub project I would want all branches to be done
[15:50]  * rogpeppe tries to understand "
[15:50] <rogpeppe>            Pretend as if all the refs in refs/ are listed on the command line
[15:50] <rogpeppe>            as <commit>.
[15:50] <rogpeppe> "
[15:50]  * redir tries to understand quote
[15:50] <rogpeppe> ah, got it!
[15:51] <frankban> rogpeppe: heh, I don't remember, maybe because I was converting from bzr and I had just a single branch in the target
[15:51] <rogpeppe> jeeze, they don't write for people that don't understand the internals, do they?"
[15:51] <rogpeppe> so the "refs/" there is referring to the .git/refs directory, where branch references are held (amongst other things)
[15:52] <redir> rogpeppe: perl people
[15:53] <hatch> Makyo +1'd
[15:53] <kadams54> frankban: QA and review finished on your PR. Didn't have anything to add to what hatch had.
[15:53] <redir> rogpeppe: I was using all because I wanted to capture the tags and anything else that came over from bzr
[15:54] <frankban> kadams54: thanks
[15:54] <redir> maybe that isn't necessary for working solely within git but I think I'd still want tags and branches preserved in the new repo
[15:54] <redir> rogpeppe: ^^
[15:55] <redir> bbiab
[15:55] <rogpeppe> redir: i can see why --all would be useful if you *really* wanted to rewrite history, rather (say) creating a new repo
[16:05] <redir> rogpeppe: TMTOWTDI
[16:06] <rogpeppe> redir: that is a severe understatement when talking about git :-)
[16:10] <rick_h_> Makyo: lint issue, any reason it's faster to remove the cache than to tie the indicator into there?
[16:10] <Makyo> rick_h_, Yeah, fixed the lint issue.  Re the cache - the entire UI thread is hanging, so the indicator would hang as well.
[16:11] <rick_h_> but a hanging spinner > odd non readable ui
[16:11] <redir> rogpeppe: frankban http://pastebin.ubuntu.com/7588475/ are aliases I use a lot. Particularly tr and missing
[16:11] <rick_h_> Makyo: ok cool, just curious
[16:12] <redir> rogpeppe: dunno if the colors work without bash and don't know about acme and shells...
[16:12] <rogpeppe> redir: colours are for colouring books :)
[16:13] <Makyo> rick_h_, The spinner was being put in there, but was hanging before it could even render.  We're looking at ways to lighten the render load on charm tokens.
[16:13] <hatch> this is coming from the guy who doesn't even use syntax highlighting rogpeppe ;)
[16:13] <rick_h_> Makyo: gotcha.
[16:14] <rogpeppe> hatch: you gottit :-)
[16:14] <hatch> haha
[16:14] <redir> rogpeppe: tell that to tufte
[16:15] <hatch> rick_h_ the solution may be to write them as Views or remove the Parent/Child bit (still too early to tell)
[16:15] <hatch> that'll be post release though
[16:17] <redir> rogpeppe: replace --pretty with --no-color
[16:18] <rick_h_> frankban: http://ci.jujugui.org:8080/job/juju-gui-merge/376/ test failure. Odd one, not see it before. It's not one fo the usual temp errors
[16:18] <hatch> noooo more renderTo!!!!
[16:18] <redir> rogpeppe: nm that doesn't work you'd need to remore the colors from the foramtting
[16:18] <hatch> I thought I got rid of youuuuu
[16:18] <rick_h_> hatch: ugh and ugh. The parent child has worked out so well and worked when we had a cache.
[16:18] <hatch> rick_h_ we are just too fast now :)
[16:18] <rogpeppe> redir: thought so
[16:18] <rick_h_> hatch: will take a look in a bit
[16:18] <rick_h_> hatch: then it's easy to slow things down in a smooth way :P
[16:19] <rick_h_> hatch: or even just cache the rendereted html node tree and replace it on home. There's got to be a better way to move forward than rewrite all the code
[16:20] <frankban> rick_h_: weird this comes after two passes, without no changes other than rebasing
[16:20] <rick_h_> frankban: yea, not sure.
[16:20] <hatch> it's too early to tell what the actual problem is - but it's definitely in the token rendering - it might be as simple as blowing away the old list and re-rendering, it spends a ton of time in rendering/gc
[16:21] <rick_h_> hatch: huh? isn't that what it does now?
[16:21] <rick_h_> I guess what is getting cached? It should just be the model list
[16:21] <hatch> the json is being cached
[16:21] <rick_h_> the api json?
[16:21] <hatch> yeah
[16:21] <rick_h_> then what's not 'blown away'?
[16:22] <hatch> the DOM when switching from search results to curated
[16:22] <rick_h_> the old cache was the models generated. There was the _cache and _cache.interesting
[16:22] <hatch> right
[16:23] <hatch> Makyo and I decided that making the view caching aware was odd and that it should just be sent data and render it. We know that the model caching bit needs to be done, but the quickest way was to cache the response
[16:23] <rick_h_> yea, not a fan of the api layer caching at all
[16:23] <rick_h_> that's at the browser/web service layer
[16:24] <rick_h_> the view isn't, it's the application (browser.js)
[16:24] <rick_h_> or the state
[16:24] <rick_h_> which is a fine place to cache data that is used across state renders/etc
[16:24] <hatch> right - the view shouldn't be concerned about the data - it should request it from the same place - that place should return the data, be it cached or not
[16:25] <rick_h_> well, the view is updated with new data, and should destroy/redraw based on the new data. /me goes to look at what the view does
[16:25] <rick_h_> Makyo: I'd vote to not comment that out but kill it
[16:25] <rick_h_> we know it doesn't work well and isn't a good path forward
[16:26] <rick_h_> it doesn't address the caching of individual charm models and doesn't fit the cards on the board for a new cache module that could be shared across views in the app
[16:26] <rick_h_> it looks like a single purpose hack to speed up the home button click but fails to do that
[16:26] <hatch> that is a valid point - however a proper cache will take time to implement
[16:27] <hatch> it speeds it up dramatically if you remove the rendering issue
[16:27] <rick_h_> sure, but we've commented out this anyway
[16:27] <rick_h_> so what does leaving this in help us with?
[16:27] <hatch> like 300ms response time
[16:27] <hatch> once we solve the render issue we can re-implement this cache and not have to schedule the proper one right away if time doesn't permit
[16:28] <rick_h_> but the only reason we're seeing a rendering issue is that teh cache isn't working correctly it seems to me?
[16:28] <rick_h_> you've traded one chunk of work for two
[16:28] <hatch> no it's the rendering, if you comment out the rendering of the tokens it's very fast
[16:29] <rick_h_> ok fine, but those same tokens rendered with a browser.js cache of ._cache and ._interesting didn't exhibit an issue that I recall
[16:29] <rick_h_> you're still trading two problems for one
[16:29] <hatch> the rendering needs to be fixed regardless - we 'can' push caching off with the api cache 'hack'
[16:29] <rick_h_> it seems to me the rendering iss, and some 400ms delay during a change of state is something that can be smoothed over much easier
[16:30] <hatch> the state change is instant, <10ms
[16:30] <rick_h_> ok, I understand that, but there's no useful 10ms UI update for users
[16:30] <hatch> maybe we should have a hangout :) it'll be much easier to discuss haha
[16:30] <rick_h_> sure thing :)
[16:30] <hatch> sec
[16:31] <hatch> https://plus.google.com/hangouts/_/canonical.com/daily-standup
[16:31] <rick_h_> Makyo: ^
[16:34] <frankban> rick_h_: another branch, similar failure: http://ci.jujugui.org:8080/job/juju-gui-merge/377/console
[16:45] <redir> rogpeppe: frankban you guys using precise or trusty?
[16:45] <rogpeppe> redir: i'm using trusty
[16:45] <frankban> redir: trusty
[16:46] <redir> for splitting out the juju-core bits?
[16:46] <redir> rogpeppe: frankban ?
[16:47] <frankban> redir: git version 1.9.1 here, on trusty
[16:47] <frankban> redir: git tr is very cool
[16:48] <redir> frankban: it is like a you are here directory for the repo:)
[16:53] <bac> hey frankban, i'm trying to create a brew recipe based on the lastest tgz we have released.
[16:54] <bac> frankban: but 1.3.2 has the problem with not specifying the 0.12 for websocket-client, thus it grabs the wrong one
[16:54] <bac> frankban: so, any chance of cutting a release soonish?
[16:55] <frankban> bac: looking
[17:00] <frankban> bac: we can release a 1.3.3 if required, after a proper QA with the new juju stable (1.18.4 IIRC). Why are we working on the brew formula now? I supposed that's the very final step for osx support. If that's not the case, I'll try to prepare a new release tomorrow
[17:02] <hatch> not going to lie.....every breakout panel shouldn't be working right now heh
[17:02] <hatch> that might mean this card won't be huge
[17:02] <hatch> :)
[17:12] <rogpeppe> redir: ok, another little git question...
[17:12] <hatch> uh oh
[17:12] <redir> rogpeppe: I'm ready to provide another wrong answer:)
[17:13] <hatch> lol
[17:13] <hatch> teamwork!
[17:13] <redir> partially wrong answer...
[17:13] <rogpeppe> redir: if i want to take a subdirectory out of an existing project (juju/juju), keep its history and the same directory, then merge it with another project, essentially merging two different branches with no shared root
[17:13] <rogpeppe> redir: is that possible?
[17:13] <redir> rogpeppe: yes
[17:14] <redir> wait
[17:14] <redir> me rereads
[17:14] <rogpeppe> redir: i want to take juju/juju/testing/filetesting and add it to juju/testing, with all its history intact
[17:14] <redir> so
[17:14] <rogpeppe> redir: i guess i could use filter-branch twice
[17:14] <redir> I think the answer is yes
[17:15] <rogpeppe> redir: once with --subdirectory-filter, then with --tree-filter moving the directory back to its original place
[17:15] <rogpeppe> redir: and then kinda hope that git merge works when the two branches share no common history
[17:16] <rogpeppe> hatch: does that sound like a feasible approach?
[17:16] <redir> rogpeppe: I know that you can have more than one commit with no parent
[17:17] <rogpeppe> redir: ok, that's good
[17:17] <hatch> rogpeppe no idea I've never needed to do that
[17:17] <hatch> sorry
[17:17] <redir> rogpeppe: which means that two projects merged and have separate starting points
[17:17] <redir> but I don't know what that means for keeping the full history of the branch being merged in
[17:17] <redir> rogpeppe:
[17:19] <redir> rogpeppe: I think I would add repo getting merged in as a remote for the one being added to
[17:20] <redir> then work out how I wanted them to be merged
[17:21] <redir> they don't share a time line so you might just cherry-pick commits
[17:21] <redir> or do a subtree merge
[17:21] <redir> rogpeppe:
[17:22] <rogpeppe> redir: ok, we'll see
[17:22] <redir> yeah so
[17:23] <redir> rogpeppe: something like
[17:28] <redir> rogpeppe: http://pastebin.ubuntu.com/7589025/
[17:28]  * redir googles for magic incantation
[17:37] <redir> rogpeppe: in the filter-branch man page
[17:37] <redir> http://pastebin.ubuntu.com/7589077/
[17:38] <redir> rogpeppe: NB: I haven't done that before and it seems very magical
[17:39] <rogpeppe> redir: ah, update-index is not a command i've come across before
[17:40] <redir> rogpeppe: index-filter only updates the index not everything
[17:40] <redir> also  see subtree merges
[17:40] <redir> I don't know if that will keep history how you want though
[17:40] <rogpeppe> redir: yeah, update-index seems to be magic that allows us to manipulate stuff without actually checking things out
[17:41] <redir> rogpeppe: http://bit.ly/1kCOYwh
[17:42] <rogpeppe> redir: what's a "tree-ish"
[17:42] <rogpeppe> ?
[17:43] <redir> rogpeppe: a branch I think
[17:44]  * rogpeppe thinks git would be quite a bit simpler without the index concept
[17:44] <redir> rogpeppe: I don't think that keeps full history though
[17:45] <redir> rogpeppe: I haven't ever needed most of this stuff before this.
[17:45] <redir> filter-branch for removing things from history is about it
[17:47] <redir> rogpeppe: from the read-tree man page it looks to me like you won't get history just a merge, so I think if you want history you need filter-branch with magic
[17:48] <rogpeppe> redir: i think filter-branch with the update-index --index-info magic seems like it might do the trick
[17:50] <rogpeppe> redir: i'm guessing that it's expecting me to set $GIT_INDEX_FILE to my_repo/.git/index
[17:50] <redir> rogpeppe: note that I think that will change the hashes in history which is bad if other people have it checked out...
[17:50] <redir> rogpeppe: git might do that itself
[17:50] <rogpeppe> redir: i'm not quite sure what you mean there
[17:50] <redir> rogpeppe: I would guess it would
[17:51] <redir> when you run the git command it reads the repo it is in and sets env variables
[17:51] <redir> rogpeppe: maybe
[17:51] <redir> git env
[17:52] <rogpeppe> redir: ah, so that command will have the env var set
[17:52] <redir> rogpeppe: maybe
[17:52]  * redir is guessing
[17:52]  * rogpeppe misses the inferno shell, which did commands-as-arguments with no quoting necessary
[18:07] <redir> damn, where'd the day go
[18:28] <rogpeppe> redir: hey, it seems to have worked!
[18:29] <redir> angels sing, trumpets blare!
[18:29] <redir> world peace is at hand
[18:30] <rogpeppe> redir: my specific version of the update-index magic was this: http://paste.ubuntu.com/7589371/
[18:30] <rogpeppe> i actually feel like i understood most of what was going on there
[18:31] <rogpeppe> except i still get confused around remote branches and fetch vs checkout vs reset
[18:32] <redir> hehe
[18:35] <redir> git fetch, uh, fetches named heads or branches, tags, and the associated trees, blobs, commits etc
[18:35] <redir> and puts them into .git/FETCH_HEAD
[18:36] <redir> git merge merges them into a local branch
[18:36] <redir> git pull does both
[18:36] <redir> fetch then merge
[18:36] <rogpeppe> redir: what's the significance of .git/FETCH_HEAD there?
[18:36] <redir> rogpeppe: it is non local copies of stuff
[18:37] <rogpeppe> redir: anyway, review appreciated: https://github.com/juju/testing/pull/11
[18:37] <redir> or copies of non local stuff
[18:40] <rogpeppe> hmm, it's a pity that none of the resulting history includes the commit comments that are actually important
[18:40] <redir> checkout (and reset) update the files in the working tree to match the index or a specified tree (specified by a commit)
[18:40] <redir> git reset has --soft, --mixed and --hard
[18:41] <redir> I think --soft updates the index to match some specified tree
[18:41] <redir> and --hard updates the working directory and index
[18:42] <redir> rogpeppe: ^^
[18:42] <rogpeppe> redir: i still haven't got my head around the difference between reset and checkout
[18:42] <rogpeppe> i'm done for the day
[18:42] <rogpeppe> gotta go and make chicken and wild mushroom and tarragon pie
[18:43] <redir> rogpeppe: that sounds tasty
[18:43] <redir> later
[18:43] <rogpeppe> redir: hopefully :-)
[18:43] <redir> don't git reset your oven
[18:58] <kadams54> guihelp: looking for review and QA on https://github.com/juju/juju-gui/pull/365
[19:10] <kadams54> guihelp: Bueller?… Bueller?… anyone?… anyone?… --^
[19:10] <kadams54> ;-)
[19:10] <Makyo> kadams54, on it.
[19:10] <kadams54> Thanks :-)
[19:10] <hatch> nice the footer is FINALLY being used
[19:10] <kadams54> lol
[19:11] <hatch> I added it in in the beginning....thinking that it will probably be used at some point haha
[19:11] <kadams54> Gotta run to pick up my kids from school, but will be back in about 30 minutes.
[19:11] <redir> rogpeppe: LGTM, all the tests pass with your PR merged, but I don't know the QA or merge process for it
[20:28] <bac> this is a nice touch i'd never noticed. when brew successfully installs something you get a little mug o' beer:
[20:28] <bac> 🍺  /usr/local/Cellar/juju-quickstart/1.3.3: 2 files, 40K, built in 2 second
[20:29] <rick_h_> bac: :)
[20:33] <hatch> :)
[22:13] <hatch> rebooting
[23:17] <huwshimi> Morning
[23:29] <rick_h_> morning huwshimi
[23:31] <huwshimi> rick_h_: Hey
[23:34] <rick_h_> having fun huwshimi ?
[23:34] <huwshimi> rick_h_: Today, I'm writing tests... yes, lot's of fun! :)
[23:40] <hatch> huwshimi hey, frankban landed the branch to fix that bug
[23:41] <huwshimi> hatch: Yay!
[23:42] <hatch> huwshimi you can pretty much follow the same pattern for doing the container stuff if you end up going that far
[23:43] <hatch> here is the pr https://github.com/juju/juju-gui/pull/363
[23:47] <huwshimi> hatch: I'm not sure what you mean about following the pattern for container stuff. This looks like it handles machines and containers.
[23:48] <hatch> huwshimi there is an issue with placing a unit on an existing container
[23:48] <hatch> I wasn't really sure where your cards were taking you
[23:48] <huwshimi> Ah I see
[23:51] <hatch> I got to run but hopefully that gets you un blocked
[23:52] <huwshimi> hatch: Thanks, looks like it. Thanks!
[23:53] <hatch> no probelm


[07:10] <Keybuk> I think they use it to switch back to the dpkg console
[07:10] <Keybuk> more as a "dpkg needs to ask something" than anything else
[07:10] <Diziet> Ah, right.
[07:11] <Diziet> I see it doesn't suppress the dpkg-generated messages.
[07:11] <Keybuk> yeah
[07:11] <mvo> Keybuk, Diziet: it should carry enough information. I hide the dpkg prompt and display a gtk dialog
[07:11] <Keybuk> it's just so you can hide the usual scroll
[07:11] <Keybuk> oh, there you go, he does something else
[07:11] <hughsie> Robot101: thanks, it would apear your laptop doesn;t support brightness!
[07:11] <hughsie> Robot101: what kernel you running?
[07:11] <mvo> it does not supress because a terminal (vte) is still runing (because postinst script do nasty things sometimes that require a terminal)
[07:12] <mvo> Diziet: what information is missing?
[07:12] <Robot101> hughsie: it's definitely in the ibm_acpi 0.8 module?
[07:12] <Robot101> hughsie: 2.6.12-6-686
[07:12] <hughsie> Robot101: definatly. I'll ask davidz as I *know* he got this to work.
[07:12] <hughsie> thanks for your help tho
[07:13] <mvo> (it's very likely that I overlooked something, I haven't dived deep into dpkg
[07:13] <Kamion> mvo: I've never seen that myself, although I haven't tried today's
[07:13] <Diziet> Well, if you wanted to be able to automatically answer the question, it should contain the `what' information, ie cfof_... flags.
[07:13] <Kamion> mdz: I doubt that would be sufficient for anything more than the default case
[07:14] <Kamion> mdz: i.e. as soon as, say, xserver-xorg needed to ask a question, I'd have to drop back to debconf anyway, and I don't really want to deal with *any* extra complexity there
[07:14] <mvo> Kamion: looks like a bad burn, the second run I'm workig fine so far
[07:14] <Kamion> mvo: ah good, thanks
[07:14] <Diziet> I've just had a horrid thought.  How can dpkg tell the difference between `this conffile is removed from the package and its conffiles and so the user should be asked whether to remove it' and `this conffile is now going to be handled by the maintainer scripts and dpkg should leave the existing one in place'.
[07:14] <Robot101> hughsie: np, feel free to ping if you want anything else tested... or happen to know why http://pastebin.com/351131 happens :D
[07:15] <Robot101> hughsie: (when hald starts, it makes it crash... 0.4.7-3sarge1 though, but dbus foo makes it hard to upgrade)
[07:16] <hughsie> Robot101: okay, will do. and your trace... are you running a tainted kernel?
[07:16] <Robot101> nope
[07:16] <hughsie> hmm. hald shouldn;t do that...
[07:17] <Robot101> it is hella old and my kernel is 0-day breezy crack, but I'd like to know the path of least resistance to having sarge but have all my hardware work too :)
[07:17] <zyga> mvo: will you apply the patch before midnight?
[07:18] <hughsie> Robot101: you can't use the ubuntu dbus?
[07:18] <mvo> zyga: yes
[07:18] <mdz> Kamion: good point
[07:18] <Robot101> hughsie: 0.3x is incompatible with 0.2x, it would mean pulling essentially the whole of breezy
[07:19] <Robot101> hughsie: and I have a seperate partition for that, and it's utterly broken :P
[07:19] <hughsie> Robot101: I thought that would be the case.
[07:20] <mvo> Diziet: I don't understand why I would want to automatically answer it? isn't that the job of dpkg? The status is only send if dpkg prompts at the terminal and then the submitted information is enough, no?
[07:21] <Diziet> I naively assumed that the status-fd stuff was supposed to let you completely bury dpkg :-).
[07:21] <mvo> Kamion: daily install fine so far except the cdrom prompting because "mozilla-firefox-locale-en-gb" is not copied by archive-copier
[07:21] <mvo> Diziet: oh, right :) unfortunatly *cough* not
[07:22] <Robot101> mjg59: I realised that having sarge and breezy share the same swap partition doesn't break swsusp provided I have the same kernel on both. the initrd of whichever boots first will just clobber the running system with the suspended one... theoretically
[07:22] <Robot101> mjg59: so I'll resume sarge and be in breezy, or vice versa :D
[07:23] <Kamion> mvo: right, I'm working on that right now
[07:23] <mvo> Kamion: sure, it was just FYI
[07:26] <jbailey> Robot101: Resumng wit hthe wrong partition is bad fu, in general.
[07:27] <jbailey> Nothing good can come of it.
[07:27] <Robot101> oh I know :)
[07:27] <pef> bye !
[07:34] <Diziet> keybuk: see my latest mail.
[07:34] <fabbione> dpkg-source: error: unrecognised file suffix `.diff'
[07:34] <fabbione> hmm
[07:35] <pitti> fabbione: where did the .gz go?
[07:35] <fabbione> pitti: that's what i am trying to undestand
[07:35] <fabbione> it's the build log of kio-locate on sparc
[07:35] <Keybuk> fabbione: update dpkg to 11
[07:35] <fabbione> that seems to be ok on other arches..
[07:35] <Keybuk> or ubuntu2
[07:35] <Keybuk> depending on whether it's a Debian or Ubuntu buildd
[07:36] <fabbione> Keybuk: ah ok.. thanks
[07:36] <fabbione> it's a mix..
[07:36] <Keybuk> and send a small tac-nuke to bod
[07:36] <fabbione> i will just install one :)
[07:36] <Keybuk> pitti: it can be either diff.gz or diff.bz2
[07:37] <fabbione> mehhhhh
[07:38] <fabbione> this update would cost me a lot...
[07:38] <fabbione> given that apt-ftparchive goes in bus error with new glibc
[07:41] <Kamion> fabbione: changelog suggests that new apt-listchanges works around that?
[07:43] <fabbione> Kamion: oh.. i didn't check in a long while..
[07:43] <fabbione> thanks for noticing :)
[07:43] <mvo> fabbione: apt-listchanges segfaults for you?
[07:45] <fabbione> mvo: apt-ftparchive
[07:45] <fabbione> well we will see in not too long from now :)
[07:46] <fabbione> i an upgrading the box
[07:46] <fabbione> am even
[07:47] <mdz> Kamion: another cron.daily?
[07:47] <mdz> Kamion: I had just finished building a set
[07:47] <mdz> Kamion: we need a live build when you're finished
[07:48] <mjg59> Robot101: True
[07:49] <mvo> fabbione: if it still segfaults, could you please send me a backtrace?
[07:49] <Kamion> mdz: testing fixes for install CD breakage
[07:49] <Robot101> mjg59: unless I boot a new kernel by mistake, when it will ignore the swsusp image, and swapon and nuke it just after it craps up the journalling filesystem... so either way it /should/ work
[07:50] <mdz> Kamion: how do you feel about a colony tomorrow?
[07:50] <Kamion> mdz: not enough data yet
[07:50] <Kamion> may be able to answer you later tonight
[07:50] <fabbione> mvo: sure..
[07:51] <fabbione> if still segafault the roof of your house will be bombed with lightnings
[07:51] <fabbione> mvo: because that will kill my local cache :)
[07:52] <mvo> *cough*
[07:52] <mdz> Kamion: I was feeling pretty good about it mondayish
[07:52] <mdz> let me know
[07:53] <Kamion> mdz: I'm out of your way now; go ahead and cron.daily-live
[07:53] <mdz> Kamion: launched, thanks
[07:54] <Kamion> mdz: the language-support-* copying mess is release-critical, I think; lots of bugs about that
[07:55] <hunger> Hey, X came up without me having to run udevstart to generate /dev/input/mice! Thanks for working on that!
[07:57] <hunger> Damn... you are busy! I updated less than 4h ago and already there are abaut 40MiB new packages!
[07:58] <pitti> hunger: nice that the new udev works :-)
[07:59] <xhaker> today is the last day of summer of code isn't it?
[08:00] <mdz> Kamion: will you still be around a bit later?  we should review blockers for preview
[08:02] <Kamion> mdz: I'll be out for the next hour or so returning hired glasses from the wedding reception, and then making dinner for the child; but I'll be back after that
[08:03] <hunger> Is xdm broken or did I break my config again? It fails in postinst with status 1.
[08:03] <mdz> Kamion: ok, ping me if you're available, otherwise, we'll talk in your morning
[08:04] <fabbione> mvo: still bus error :/
[08:05] <Kamion> hunger: bug #14412
[08:06] <fabbione> mvo: what can i do to help debugging?
[08:07] <mvo> fabbione: a backtrace would be good
[08:07] <hunger> Could someone please add an if [ -d /dev/hda ] ; then ... fi around the hdparm stuff in /etc/init.d/acpi-support?
[08:08] <hunger> My laptop has no hda and the script keeps nagging about that.
[08:08] <ivoks> hi
[08:10] <mjg59> hunger: There's only one reference to hda in acpi-support, and it won't be triggered unless you've altered your configuration
[08:11] <mjg59> Try upgrading
[08:12] <hunger> mjg59: acpi-support runs hdparm twice.
[08:14] <mjg59> hunger: Where?
[08:14] <hunger> mjg59: In fact two in start and one in stop...
[08:14] <mjg59> hunger: No it doesn't
[08:15] <hunger> mjg59: It does here... let me check where that file comes from...
[08:15] <mjg59> hunger: Which file?
[08:16] <hunger> mjg59: /etc/init.d/acpi-support lines 22,23 and 34.
[08:17] <hunger> mjg59: Just purged and reinstalled... it is there.
[08:17] <mjg59> hunger: My apologies, you're entirely right
[08:17] <mjg59> hunger: Please file a bug, I'll fix that
[08:17] <hunger> mjg59: Thanks!
[08:22] <hunger> mjg59: #14431
[08:27] <mjg59> hunger: Thanks!
[08:28] <Robot101> mjg59: did you fix the RTC thing? :P
[08:29] <mjg59> Robot101: Not yet
[08:29] <Robot101> mjg59: can you set the RTC to wake you from sleep after a fixed period of time?
[08:30] <mjg59> Robot101: Yes
[08:30] <mjg59> See /proc/acpi/alarm
[08:30] <Robot101> mjg59: or when the battery gets down to a particular level? :)
[08:30] <mjg59> No
[08:30] <Robot101> aww
[08:30] <mjg59> That's hardware dependent
[08:30] <mjg59> Most modern machines seem to resume shortly before the abttery runs out
[08:30] <elmo> eh, am I being particulary stupid or something; a web browser should respect /etc/hosts right?
[08:31] <hunger> elmo: depends on your resolver config IIRC.
[08:31] <Robot101> elmo: modulo proxy settings...?
[08:31] <fabbione> elmo: nsswitch.conf? or whatever is called?
[08:31] <mjg59> elmo: Mozilla certainly used to have its own resolver
[08:32] <fabbione> night everybody
[08:32] <fabbione> cya tomorrow
[08:33] <sabdfl> night fabbione
[08:34] <ivoks> fabbione: bye
[08:34] <pitti> cu fabbione
[08:40] <slomo> hi... can someone with main upload rights upload this for me? fixes FTBFS and is a really small change... http://yggdrasil.sytes.net/files/debdiff/mono_<IP_ADDRESS>-1ubuntu4.debdiff
[08:41] <Diablo-D3> hey all
[08:42] <pitti> tseng: here to help slomo?
[08:42] <Diablo-D3> No one seen daniels lately?
[08:42] <Diablo-D3> he asked me to "output of DEBUG_XORG_PACKAGE=yes sudo dpkg-reconfigure -phigh xserver-xorg, please."
[08:42] <pitti> nope, he is certainly deep asleep
[08:42] <tseng> pitti: sure
[08:42] <tseng> pitti: whats up?
[08:42] <Diablo-D3> how would one do that and still be able to control debconf?
[08:42] <pitti> tseng: see slomo above
[08:42] <slomo> pitti: tseng is busy atm ;) otherwise he would've uploaded it already
[08:43] <pitti> tseng: ah, ok
[08:43] <tseng> ah i told him i was just leaving
[08:43] <Diziet> I should stop and log off, really.
[08:43] <Diziet> Then I can have dinner.
[08:43] <pitti> slomo: ok, I can do that
[08:43] <slomo> pitti: thanks :)
[08:43] <Diablo-D3> anyone?
[08:43] <tseng> thanks pitti, later all
[08:45] <Diziet> Goodnight everyone.
[08:45] <pitti> night Di
[08:45] <pitti> night Diziet
[08:45] <Diablo-D3> beuler?
[08:46] <pitti> slomo: uploaded
[08:47] <slomo> pitti: thanks
[09:30] <sivang> does anybody esle try to msg nicksrv without success?
[09:31] <sivang> pitti: do you have any specific g-c-m stuff you'd like me to have a look at, or should I just browse the ones assigned to you?
[09:41] <sladen> Robot101: grep . /proc/acpi/ibm/*   is good
[09:41] <sladen> hughsie: on ThinkPad's the brightness is hardware controlled and pass though 3 bits in the /dev/nvram
[09:46] <hughsie> sladen: davidz has a /proc/acpi/ibm/brightness file
[09:46] <Diablo-D3> you know
[09:46] <Diablo-D3> openbox rocks
[09:46] <hughsie> sladen: perhaps a newer ibm_acpi?
[09:52] <CarlFK> breezy: "cannot touch `x': Read-only file system" but mount shows /dev/sda1 on /media/sda1 type ntfs (rw)
[09:52] <CarlFK> shouldn't mount show (ro) ?
[09:53] <sladen> CarlFK: good point
[09:54] <CarlFK> but i did mount it with the mount command, so I am not sure what could be done about it
[09:58] <Robot101> jdub: ping
[09:58] <Robot101> jdub: what's the deal with mdnsresponder in sid?
[10:05] <elmo> christ, bugzilla searching is teh useless
[10:06] <sivang> elmo: you have hard time finding stuff by package? I also get annoyed by that
[10:06] <sivang> elmo: it seems to ignomre my serach phrase
[10:07] <slomo> mdz: will we get something done with ffmpeg for breezy? seems like our version is also the cause for mplayer crashing on ac3 audio... but i'm not entirely sure yet
[10:08] <mdz> slomo: if kino is changed not to use it, it will fall out of main naturally
[10:08] <mdz> assuming nothing else depends on it
[10:08] <mdz> I'm happy to move it if kino is changed, but I don't know what the effect on kino would be
[10:09] <pitti> mdz: are you opposed to adding postgresql-pl{perl,python} to the seeds? These packages were split out of the main server package in breezy
[10:10] <slomo> mdz: the only effect on kino would be possible slower dv decoding on non-x86 architectures (i don't know if this is still valid... that was 2003 iirc). it would loose no features
[10:10] <mdz> pitti: no
[10:10] <mdz> slomo: ok
[10:10] <pitti> mdz: ok, thanks
[10:10] <mdz> pitti: could you review slomo's patch and upload it if you agree?
[10:11] <pitti> mdz: sure
[10:11] <pitti> slomo: which patch?
[10:11] <mdz> pitti: thanks
[10:11] <mdz> pitti: forwarding it to you now
[10:11] <slomo> pitti: http://yggdrasil.sytes.net/files/debdiff/kino_0.75-7ubuntu1.debdiff
[10:12] <slomo> mdz: will i get preview freeze exception for changing ffmpeg and recompile everything against the new one?
[10:12] <mdz> slomo: since nothing in main is affected, the preview freeze doesn't apply
[10:12] <sivang> pitti: I can handle #11282 unless we want it handled upstream, pretty trivial i guess
[10:13] <slomo> mdz: oh, i thought preview freeze applies also to universe... thanks for clarifying this :)
[10:13] <mdz> slomo: MOTU are free to set their own schedule for universe; if there is a policy in place then it comes from MOTU and not from me
[10:14] <pitti> sivang: sure, that's easy; just send the patch upstream as well :-)
[10:14] <slomo> mdz: ok, i'll talk to ogra about that
[10:18] <sivang> pitti: funny, there is a lot of space down the dialog , I wonder how no one thought aobut using it before L:)
[10:21] <elmo> did these ttf fonts always take so long to run their postinsts?
[10:21] <Mithrandir> elmo: we have a fair amount more of them now, I think.
[10:22] <pitti> slomo: ok, so kino works as before without libavcodec?
[10:24] <slomo> pitti: i didn't test it (i have no dv encoded stuff lying around) :( but this is from kino's configure: "--with-avcodec       Use FFMPEG libavcodec for DV video decoding instead of libdv."
[10:24] <pitti> slomo: ok, I just read the mail you sent to Matt; the reasons sound sane
[10:25] <pitti> slomo: and thanks for eliminating static libraries! :)
[10:26] <slomo> pitti: np :) so you will upload this?
[10:27] <pitti> slomo: yes, doing now
[10:27] <slomo> pitti: thanks :)
[10:27] <pitti> slomo: *removing* packages from main is something I always like to do :-) It happens seldom enough
[10:28] <elmo> mjg59: ?
[10:28] <slomo> mdz: and please care that ffmpeg gets into multiverse, not universe ;) otherwise we won't be able to use marillat's package and can't support aac through faad2 for example
[10:29] <pitti> slomo: if ffmpeg is not actually used any more anyway, why should we care?
[10:29] <pitti> slomo: or can it be used dynamically?
[10:29] <mdz> slomo: I will
[10:29] <slomo> pitti: it is used by some multiverse stuff (transcode, mplayer, smilutils, ....)
[10:32] <hunger> Is NM updated again? j^ did lots of work on it from what I heared.
[10:32] <slomo> hunger: afaik it only waits for someone to upload it ;)
[10:33] <pitti> slomo: Accepted kino 0.75-7ubuntu1 (source)
[10:34] <slomo> pitti: :)
[10:37] <slomo> elmo: can you remove the old mplayer binaries from the archive for breezy? mplayer-custom, mplayer-amd64, mplayer-686, mencoder-k7, mencoder-custom, mencoder-amd64
[10:37] <mdz> pitti: new install and live CDs are now up with dbus 0.36.2-0ubuntu2
[10:49] <sivang> night all
[11:06] <dieman> yay, came back to one of my old bugs and fixed it. :)


[22:26] <davecheney> wowo, google compute engine is really janky
[22:26] <davecheney> shithouse first user experience
[22:27] <davecheney> Project '{{deleted.name}}' is now scheduled to be deleted after {{deleted.date|date:'short'}
[22:27] <davecheney> ^ awesome
[22:30] <davecheney> Error
[22:30] <davecheney> API rate limit exceeded. Rate limit may take several minutes to update if Google Compute Engine has just been enabled, or if this is the first time you use Google Compute Engine.
[22:32] <davecheney> this is not a consumer service
[22:36] <davecheney> Creating instance "bootstrap", this may take a few minutes. Do not refresh or navigate away from this page.
[22:36] <davecheney> wow, thanks 90's
[22:57] <davecheney> % juju switch "null"
[22:57] <davecheney> ERROR "null" is not a name of an existing defined environment
[22:57] <davecheney> ^ the docs say to do this
[22:58] <davecheney> ignore
[22:58] <davecheney> copy and paste error
[23:05] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1247688
[23:05] <_mup_> Bug #1247688: manual provisioning fails on debian wheezy host <juju-core:New> <https://launchpad.net/bugs/1247688>
[23:10] <davecheney> W: Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/raring-backports/multiverse/source/Sources  404  Not Found [IP: <IP_ADDRESS> 80]
[23:10] <davecheney> what the f is going on with the mirrors this morning
[23:24] <davecheney> http://paste.ubuntu.com/6355925/
[23:24] <davecheney> bootstrap is fucked, AGIAN
[23:42] <davecheney> has anyone been able to use saucy ?
[23:42] <davecheney> i can't bootstrap any saucy series charms
[23:42] <wallyworld_> davecheney: the metadata you have uploaded for tools does not contain tools for saucy
[23:42] <wallyworld_> you may need to re-generate and upload
[23:42] <davecheney> well shit
[23:43] <davecheney> wallyworld_: i did bootstrap --upload-tools
[23:43] <wallyworld_> what was the client?
[23:43] <wallyworld_> series
[23:43] <wallyworld_> the metadata has
[23:43] <wallyworld_>             "products": [
[23:43] <wallyworld_>                 "com.ubuntu.juju:12.04:amd64",
[23:43] <wallyworld_>                 "com.ubuntu.juju:13.04:amd64"
[23:43] <wallyworld_>             ]
[23:43] <wallyworld_> so raring and precise
[23:44] <davecheney> raring client
[23:44] <wallyworld_> right
[23:44] <wallyworld_> so a araring client doesn't upload tools for saucy
[23:45] <wallyworld_> there is a work around
[23:45] <davecheney> wallyworld_: thanks, i'll just deploy local:raring/ubuntu
[23:45] <wallyworld_> ok. sorry about confusion
[23:46] <davecheney> nah, it's ok
[23:46] <davecheney> this is only a problem in the dev version
[23:46] <wallyworld_> yeah
[23:48] <davecheney> AWWW FUCK
[23:49] <davecheney> now my provisioner is broken because it can't ever get past that fauly saucy machine to provision my raring machine


[16:11] <wasabi_> So why doesn't upstart have a 'user' stanza?
[16:11] <wasabi_> I can imagine it being hard for pid 1 to do namemapping, yeah.
[16:12] <sadmac2> wasabi_: nobody's gotten around to implementing one
[16:13] <sadmac2> wasabi_: su does the trick
[16:13] <wasabi_> Ahh.
[16:14] <wasabi_> Hmm. Does su end up execing, or does it fork first?
[16:15] <wasabi_> Want to make sure upstart's TERM still goes to the right place.
[16:15] <sadmac2> su should just exec
[16:17] <jMCg> wasabi_: you need a TERM? More importantly: upstart has a TERM!?
[16:17] <wasabi_> stop sends TERM, n o?
[16:17] <wasabi_> sigterm.
[16:18] <jMCg> Ah. I thought you meant the environment variable.
[16:18] <wasabi_> Oh.
[16:24] <wasabi_> Using 'su' sure creates a lot of unnecessary processes, though.
[16:25] <jMCg> wasabi_: whatabout sudo -u $user ?
[16:26] <sadmac2> wasabi_: huh?
[16:26] <sadmac2> wasabi_: su shouldn't create any additional processes methinks
[16:26] <jMCg> Maybe your various wrappers do.
[16:26] <wasabi_> 'su' keeps running, and it creates a shell to run the specified command in.
[16:26] <wasabi_> Since the -c option is a shell script.
[16:27] <sadmac2> wasabi_: check the manpage. there should be a way to make that not happen
[16:27] <wasabi_> Doesn't seem to.
[16:27] <sadmac2> either way it shouldn't "create" a shell. It should exec() a shell
[16:27] <jMCg> "-c will cause the next argument to be treated as a command by most command interpreters. The command will be executed by the shell specified in /etc/passwd for the target user."
[16:27] <wasabi_> Well, it's not. Clearly.
[16:28] <wasabi_> and yeah, stopping it sends sigterm to the wrong place.
[16:28] <wasabi_> Heh.
[16:28] <sadmac2> fun
[16:28] <jMCg> Now, one could try to specify -s /binhrmpfzd... bleh. exec is a shell-builtin....
[16:29] <wasabi_> Yeah. No way to pass an arg list though
[16:29] <wasabi_> Oh I see
[16:29] <jMCg> Anyways, I'm pretty much very sure (because I myself abuse it) that sudo does not start a funky shell.
[16:29] <jMCg> jmcg@metis ~ % ps -cafe|grep -i [s]udo
[16:29] <jMCg> 1 jmcg@metis ~ %
[16:30] <jMCg> As opposed to (and I'm only giving a grep -c here): jmcg@metis ~ % ps -cafe| grep -c [h]ttpd
[16:30] <jMCg> 91
[16:31] <jMCg> And script starts this with sudo, but there's no trace of..
[16:32] <jMCg> http://dpaste.com/89133/ nope.. no trace of shell or su or sudo or anthing.
[16:39] <wasabi_> Can't get sudo to run from upstart though. Grrr.
[16:39] <wasabi_> Ahh. I see
[16:39] <wasabi_> -c on sudo does not support args.
[16:39] <wasabi_> it tries to exec the string, and finds no command.
[16:53] <wasabi_> Argh. And I can't use -g in sudo. Says the root user isn't allowed to do it.
[16:53] <wasabi_> And I'm not going to monkey with perms.
[16:55] <Keybuk> exec su -c "exec command" user
[16:55] <Keybuk> ;)
[16:55] <wasabi_> su stays around.
[16:55] <Keybuk> yes
[16:56] <Keybuk> but the process group is the same
[16:56] <wasabi_> Oh
[16:56] <Keybuk> so init sends SIGTERM to both su and its child process
[16:58] <wasabi_> From what I can tell the child does get it.
[16:58] <wasabi_> Begins a shutdown process (which can take awhile)
[16:58] <wasabi_> ANd then init reports it exists with 255.
[16:58] <wasabi_> exits
[16:58] <wasabi_> And the child keeps shutting down.
[16:58] <wasabi_> So su is disappearing.
[16:59] <Keybuk> oh, right
[16:59] <Keybuk> yeah that can happen
[16:59] <wasabi_> Uh huh.
[16:59] <Keybuk> it's not ideal
[16:59] <wasabi_> Sure isn't.
[17:00] <wasabi_> I think a 'user' stanza added to upstart would make me happy.
[17:00] <Keybuk> it wouldn't make me happy
[17:00] <wasabi_> Name lookup?
[17:00] <Keybuk> no, it's wrong
[17:00] <wasabi_> Oh. Why?
[17:00] <Keybuk> give me 30s and I'll describe how I see it working ;)
[17:01] <Keybuk> just need to finish a function
[17:01] <wasabi_> okay
[17:11] <Keybuk> right
[17:11] <Keybuk> so "run as user" means lots of different things
[17:11] <Keybuk> for example, a user's cron job
[17:11] <Keybuk> that doesn't just run setuid the user
[17:11] <Keybuk> but it runs *as* the user
[17:11] <Keybuk> it's setuid, initgroups() is used *and* PAM is invoked to set up a full user session
[17:12] <Keybuk> and Upstart needs to support user owned jobs that behave in this fashion
[17:12] <Keybuk> *separate* to that is the notion of dropping privileges
[17:12] <Keybuk> dropping privileges may include calling setuid()
[17:13] <Keybuk> but that's a numpty's function
[17:13] <Keybuk> what you really want to specify is the real *and* effective uids of the job
[17:13] <Keybuk> and any capabilities to retain
[17:13] <wasabi_> Hmm
[17:13] <wasabi_> I see.
[17:14] <Keybuk> for example, you should be able to say that named runs with real and effective "bind" but retains CAP_NET_BIND_SERVICE
[17:14] <wasabi_> So it's obviously more complicated than just user.
[17:14] <Keybuk> yes
[17:14] <Keybuk> and then there's the permission side of ti
[17:15] <Keybuk> as "scott", I should be able to send init commands to start and stop my jobs
[17:15] <Keybuk> or start and stop jobs that I am permitted to start and stop, which runs as my user
[17:15] <wasabi_> Yeah.
[17:15] <Keybuk> and that then brings the problem of security on a job
[17:15] <Keybuk> and interestingly, means that the "user" of a job need not be specified in the config
[17:15] <Keybuk> (or "any user" for example)
[17:17] <ion> keybuk: Did whatshisnick talk to you about Linux capabilities? In Solaris SMF, he said, you can declare a job to run as an unprivileged user but with the rights to open port <1024 for instance. Linux has equivalent capabilities functionality, Upstart would just need to implement support for that along with the rest of the run-as-user functionality.
[17:18] <ion> /usr/include/linux/capability.h
[17:19] <ion> Better: capabilities(7)
[17:21] <ion> user www-data
[17:21] <ion> capabilities net-bind-service
[17:21] <ion> exec /usr/bin/apache2 --foo
[17:42] <Keybuk> right
[17:42] <Keybuk> that's exactly what I was waffling about above
[17:42] <Keybuk> though I wouldn't use "user" there
[17:42] <Keybuk> it's more "real uid www-data" ;)
[17:55] <ion> Hah, now that i actually look at the discussion, i realize i was just repeating what was already said. I’ve been watching a movie and missed the discussion; just noticed something about the ”user” of a job and mentioned what jmcg talked about recently.
[18:00] <sadmac2> Keybuk: so what does the UI for that look like?
[18:01] <sadmac2> Keybuk: To play devils advocate, a "user" stanza would do something that most end users would understand. There's a very simple expectation for the behavior of that.
[18:01] <Keybuk> that's the bit I don't know
[18:02] <Keybuk> right
[18:02] <Keybuk> and I want the simple expectation to always fail
[18:02] <Keybuk> which is why I want to avoid a "user" stanza
[18:03] <sadmac2> Keybuk: we should probably discuss the "and" operator while I'm thinking of it. You want to keep it around and non-deprecated last I brought it up?
[18:04] <Keybuk> for while, yes
[18:05] <sadmac2> Keybuk: ah. That's very different :)
[18:06] <sadmac2> Keybuk: and for events is wrong, wrong and terribly wrong. For states it makes perfect sense.
[18:08] <Keybuk> right
[18:08] <Keybuk> while something and something or someting
[18:08] <Keybuk> on foo
[18:08] <Keybuk> on bar
[18:08] <Keybuk> on baz
[18:08] <Keybuk> hourly
[18:08] <Keybuk> at the hour of scampering
[18:08] <Keybuk> 40 minutes after tea
[18:09] <Keybuk> etc.
[18:09] <Keybuk> all of the "event" bits are OR
[18:09] <Keybuk> if you want AND
[18:09] <Keybuk> from event until SOME OTHER EVENT and while something
[18:09] <Keybuk> on foo
[18:10] <sadmac2> Keybuk: 0.6 compatibility means we have to keep AND around, which hurts since ripping it out deletes about 1/4 of upstart's code :)
[18:10] <Keybuk> yeah
[18:10] <sadmac2> its kinda-sorta less painful with triggers.
[18:11] <Keybuk> but then you guys never went with 0.6 anyway, did you? :p
[18:11] <sadmac2> we didn't... so there is that...
[18:11] <Keybuk> which means you have nice crasher bugs
[18:11] <Keybuk> but hey ;)
[18:12] <sadmac2> you picked a bad time in our release cycle for 0.6 :(
[18:12] <Keybuk> you picked a bad time in your release cycle to ship a version of init with known serious bugs ;)
[18:12] <sadmac2> also our system is kind of dependent on state transfer working (even the broken version we got)
[18:12] <ion> All the major Linux distributions should live together for a while, so their periods would get synchronized.
[18:13] <sadmac2> ion: well, we certainly have enough douches to clean the mess up.
[18:15] <ion> *zing*
[18:16] <sadmac2> Keybuk: there's bugs and then there's bug reports. The loudest userbase in linux is staying quiet on upstart. Life is good.
[18:16] <Keybuk> loudest userbase? :)
[18:18] <sadmac2> Keybuk: curmudgeons love fedora
[18:19] <Keybuk> yes, but there's so few of them ;)
[18:19] <sadmac2> I wish
[18:43] <sadmac2> Keybuk: you aren't perchance going to JLS?
[19:01] <sadmac2> http://gcc.gnu.org/wiki/Var_Tracking_Assignments
[21:05] <jMCg> wuhwvmpfzd.. for a second there, I read "JCL" ...


[01:01] <lmthatguy> Hi im in need some help. Can anyone assist me?
[01:07] <lmthatguy> when i try to execute ./nvflash, nothing happens
[01:07] <lmthatguy> keeps saying no such file or directory
[01:08] <lmthatguy> and i have everything i need in one directory
[01:08] <zeroseven0183> Hi imthatguy, where did you store the file ./nvflash?
[01:09] <zeroseven0183> You can check where you are in the Terminal by typing 'pwd'
[01:09] <zeroseven0183> See if you are in the correct directory
[01:10] <lmthatguy> root@ubuntu:/home/sharonholmes/Desktop/CR_Unbricker#
[03:55] <invisigothik> greets!
[03:56] <invisigothik> or greetings, or hello.
[04:59] <zimio> anyone from nyc?
[06:33] <bluphoton> hello all, anyone knows why doesn't any program on ubuntu can input a text into yahoo chatroom ??
[06:34] <bluphoton> i can see the text i put in.. but its not displayed to anyone..
[06:34] <bluphoton> i use finch.. i have also tried in pidgin
[13:01] <duanedesign> o/
[13:13] <raju> hi guys
[13:19] <eyadof> hi everyone , i want to ask if someone know how to change proxy setting from terminal ?
[13:24] <raju> eyadof: http://wazem.blogspot.in/2008/01/how-to-change-gnome-proxy-settings-on.html
[13:24] <raju> http://stackoverflow.com/questions/5020261/firefox-proxy-settings-through-terminal-in-ubuntu-10-04
[13:26] <eyadof> thank MR raju but i have ubuntu server there isn't any GUI to work with
[13:27] <eyadof> is there a pure text mod way
[13:27] <raju> eyadof:  scroll the first link
[13:28] <raju> i have seen there is text mode
[13:28] <raju> read it , it have both GUI and text modes
[13:30] <duanedesign> o/
[13:32] <eyadof> raju: it's use " gconftool "
[13:32] <raju> how is the 2nd one ?
[13:34] <raju> eyadof:  ok forums have one HOWTO , look at this , it may  helpful   http://ubuntuforums.org/showthread.php?t=1575
[13:37] <eyadof> raju: thnks that work !
[13:39] <raju> eyadof:  nah! say to those guys
[13:39] <raju> lol :P
[13:39] <raju> welcome my friend
[15:59] <Louco-Diamante> hi there
[15:59] <Louco-Diamante> guys, need to know what to choose from. Ubuntu 32 or 64bits?
[17:51] <anonymousinuk> hey ppl, can anyone help me with wlan0 channel config? or point me in the right dirrection?
[17:54] <Jeroen___> Hello people, I have a small problem with newly installed Ubuntu 11.10. The second monitor attached to my notebook is not recognized. Oddly, it *does* work when I booted from the live USB ubuntu, but not on the ubuntu I installed on the hard drive (from that same USB drive).
[18:14] <duanedesign> Jeroen___: do you have an NVIDIA card?
[18:14] <Jeroen___> Yes, nvidia.
[18:15] <duanedesign> Jeroen___: do you know if you are using the open source or proprietary driver?
[18:17] <Jeroen___> Iḿ using a prorietary driver
[18:21] <duanedesign> Jeroen___: does only one monitor show in 'nvidia-settings'?
[18:23] <Jeroen___> where do i find ´nvidia-settings´? Under ´displays´ only one monitor is shown, named ´unknown´, When I boot from the live USB drive, however, it shows both monitors, one as ´laptop'  and one (correctly) as ´samsung ...'
[18:25] <duanedesign> Jeroen___: if you search in the Dash for 'nvidia' it should pop up. You can also launch it from the Terminal with the command nvidia-settings
[18:25] <duanedesign> if it is not installed you can install it with the command: sudo apt-get install nvidia-settings
[18:33] <duanedesign> Jeroen___: this might be helpful. http://askubuntu.com/questions/67495/getting-dual-monitors-to-work-on-11-10
[18:36] <Jeroen___> nvidia-settings did the trick! Thanks! :-)
[18:43] <duanedesign> Jeroen___: that is great!
[23:01] <samuel> hello all
[23:02] <samuel> i'm having problems installing ubuntu on my dell laptop, i wonder if anyone could offer some insight into the problem?
[23:16] <benonsoftware> samuel: Whats the problem?
[23:18] <samuel> ah hello, thankyou for your response, i cant resize the os partition in either gparted or the ubuntu installer
[23:18] <benonsoftware> What happenes?
[23:19] <samuel> after the installer failed i booted into the live cd and fired up gparted, it shows an exclaimation mark against the os partition, i have a dell vostro btw
[23:19] <samuel> the only partition that the ubuntu installer can install on has something like 10gb, and i'm a little concerned about formatting that
[23:19] <samuel> the total hard drive capacity is 500gb
[23:20] <benonsoftware> samuel: is it possible for you to wipe the whole drive?
[23:20] <samuel> well, i would rather leave windows 7 on there, reformatting would be a last resort
[23:20] <samuel> as its an oem install i get no windows disc
[23:23] <samuel> ah i think i might have found what the problem is
[23:24] <samuel> i may be able to fix it somehow with the recovery discs
[23:28] <samuel> thanks for your response, aparrently i need to use window's shrink partition tool, or format the hard drive, partition it, then use the recovery disc to install on the desired partition
[23:29] <stlsaint> samuel: wait what is the issue here?
[23:30] <samuel> i'm trying to set up a dual boot on my dell vostro laptop which has windows 7 preinstalled
[23:31] <samuel> when i do it via the ubuntu installation process it cannot access the main os partition
[23:31] <stlsaint> what are you using a recovery disc for?
[23:31] <samuel> i have been reading the multi boot guide via the ubuntu documentation
[23:32] <samuel> aparrently you can use the windows recovery disc to restore to any partition
[23:32] <samuel> (except for with HP computers)
[23:32] <samuel> i will try resizing the partition using the tool in windows first though as it seems the least destructive
[23:32] <stlsaint> im still not seeing what the issue is
[23:33] <stlsaint> use windows disk management to make a separate partition and then use the ubuntu disc to install
[23:33] <samuel> yup, that is my first option, this is the first time i have encountered this problem with an oem windows system thats all
[23:34] <samuel> perhaps its because the systems i have so far encountered are already set up with a partition, or i have been happy to completely remove windows
[23:35] <stlsaint> alright
[23:36] <samuel> like when did oem machines start having a single partition? every laptop or pc i have seen with windows up until now has had a partition for "backing up" (even if it has only one physical drive)
[23:36] <duanedesign> samuel: it is not letting you resize the windows partition/
[23:37] <samuel> thats correct, not from gparted or the ubuntu installation process anyways, i'm doing it via the windows disk management now as advised
[23:39] <duanedesign> if the windows partition has a red exclamation point you can right-click and select Information to see if it gives any clues as to what the exclamation point is for
[23:40] <samuel> anyway thank you all who as pitched in on this so far! on #ubuntu all i could get was a debate over the advantages of GS or Unity or Fallback mode **sigh**
[23:40] <duanedesign> :)
[23:41] <duanedesign> coug**Unity**cough
[23:41] <duanedesign> ;)
[23:41] <samuel> yeah i got a list of problems too long for the screen to display
[23:41]  * samuel typing this from GS on ubuntu 11.10
[23:41] <duanedesign> oh boy
[23:41] <samuel> according to the ubuntu documentation there is a thing with windows 7/vista where certain files are not moveable
[23:42] <samuel> the work around is to use the windows disk manager as i have just done
[23:43] <samuel> the reason why i didnt find this out sooner is i had a mind blank as to how to phrase my google search, oh well, glad we all have IRC
[23:44] <duanedesign> ahh
[23:44] <samuel> btw did you know that on linux mint you get xchat by default and when you start it, it dumps you straight into their support channel - not sure if thats an awesome idea or just asking for it
[23:46] <duanedesign> another issue that has been popping up is that windows has 4 primary partitions m
[23:46] <duanedesign> 4 Primary partitions is the maximum allowed on an mbr partitioned disk
[23:47] <samuel> hmmmm i noticed that there are some 1mb partitions! thanks for the heads up, i could easily remove those
[23:47] <samuel> what is the result, ubuntu doesnt boot? or worse, no bootable os??
[23:48] <samuel> BTW apart from this problem, i cannot fault this laptop, anyone in the UK reading this, got it in tesco for approx £360, AMD E450, 4GB DDR3 & 500GB HDD
[23:48] <samuel> from the live CD all essential hardware is functioning
[23:49] <duanedesign> nice
[23:52] <samuel> ah bollox, the unallocated space that i just created is unusable!!!
[23:52] <samuel> lets see if i can do anything with gparted
[23:53] <samuel> haha, and suprise surprise its because there are too many primary partitions!
[23:54] <duanedesign> aha
[23:55] <samuel> its ok, i lost one of the partitions, i can leave that space empty its like 4.67gb of nothing
[23:55] <duanedesign> if you can only get down to three you can install the two Linuc partitions in two logical partitions within an extended partition
[23:55] <duanedesign> Linux*
[23:55] <samuel> i bet deliberately put there to stop people from installing 3rd party os's
[23:56] <duanedesign> heh, i would not be suprised
[23:56] <samuel> i like to do my partitions /, /home and swap
[23:56] <samuel> allows for easy reinstallation of the os if things go badly
[23:56] <duanedesign> ahh, yes. that is a good idea
[23:57] <duanedesign> makes upgrading and reinstalling so much easier
[23:57] <samuel> yup, a simple case of formatting /
[23:57] <samuel> would be cool if the ubuntu installation did that from the upgrade option
[23:57] <samuel> rather than wiping everything off which is what it did last time i tried it
[23:59] <samuel> the company i work for does linux computers for grannies so an upgrade process like that would be a great idiot proof upgrade with no data loss


  You're online!
[16:51] <mrutland> Martyn: what trouble are you having?
[16:52] <Martyn> okay, so I am trying to bring up on a Juno board
[16:52] <mrutland> Those have upstream support in EDK2, so what exactly are you trying to do?
[16:53] <Martyn> I'm trying to boot over PCIe
[16:53] <Martyn> so I need to initialize the PCIe bus early, in UEFI
[16:54] <Martyn> ( this is on the A57 )
[16:55] <Martyn> However, once I do that initialization and copy/unpack the kernel into a bootable memory address -- The kernel fails to boot as -it- tries to re-initialize it
[16:56] <mrutland> Martyn: which Juno revision?
[16:57] <Martyn> r2
[16:57] <Martyn> r2p0
[16:58] <Martyn> oh wait -- that's wrong
[16:58] <Martyn> I have Cortex A57 - r1p1
[16:58] <Martyn> and the a53 is r0p3
[16:58] <Martyn> so it's juno r1
[16:59] <mrutland> Hmm, that _should_ work. Which FW, which kernel, and are you using ACPI or DT?
[17:00] <Martyn> I'm using devicetree, kernel 4.6-rc5 ( current mainline ), and unsure which firmware
[17:01] <Martyn> Also, I've tested booting from SATA just to make sure that I'm not having some weird XAUI issue, and I can boot from SATA just fine
[17:01] <Martyn> also I can boot from 10GigE ( also XAUI )
[17:02] <mrutland> Martyn: So which PCIe device(s) do you have plugged in in the failing case?
[17:02] <Martyn> but when I try to cluster boot over PCIe .. somehow initializing the PCIe bus early results in a deadlock condition once the mainline kernel starts to boot.  I don't have a 1wire debug available, or KEIL debug over JTAG, so I'm kind of stuck
[17:03] <mrutland> Martyn: I was under the impression that the SATA was over PCIe, so what do you mean by "boot over PCIe"? Which device?
[17:03] <Martyn> just a PCIe debug board I built.  I'm clocking the data in, and all the data is well ordered
[17:04] <Martyn> I'm trying to do something San Mehat did back at VA Linux Systems back in the early 2000's ... I am putting together a TCP/IP stack over PCIe, so that I can use one a64 card to boot another directly.
[17:05] <mrutland> Martyn: given that SATA works (over PCIe), the issue sounds specific to your debug board; I'm not sdure I can be of much help. :/
[17:06] <Martyn> so the board that's plugged into the PCIe bus is fairly simple -- a SPEAr 1340 w/ single channel PCIe 2.0 RC/EP port
[17:06] <Martyn> and all it does it clock in the data -- the kernel does load correctly into memory, and I have uncompressed it into RAM and can even start booting it
[17:07] <Martyn> the -problem- is that the entire PCIe bus locks up right afterwards.  I don't think the PCIe bus likes being re-initialized by when the kernel reboots
[17:07] <Martyn> reboots/boots
[17:07] <Martyn> Is there a way to prevent the kernel from attempting to re-initialize the PCIe bus, given that I've already done it during UEFI?
[17:12] <Martyn> oh .. interesting.  I just tried to checkout a fresh copy of EDK2 -- issues with git
[17:12] <Martyn> warning: remote HEAD refers to nonexistent ref, unable to checkout.
[17:12] <mrutland> Martyn: I don't follow why that would only be a problem when your board is plugged in? Surely it re-initialises it anyway?
[17:13] <Martyn> That's what I was thinking... PCIe has to be initialized to get SATA working, so I figured this would be safe as houses
[17:13] <Martyn> however, I'm not doing anything significantly more complex than what happens during SATA boot
[17:14] <Martyn> I am copying data from the card I built, the data copies in, and as soon as the kernel does a PCIe probe -- BANG
[17:14] <Martyn> deadlock
[17:15] <Martyn> Bah .. I need to get JTAG on this
[17:19] <mrutland> It may be worth asking on the linux-arm-kernel mailing list; this sounds like a PCIe issue, and people there are more familiar with the ARM/ARM64 details for that than I am
[17:19] <Martyn> Yeah.  With the A57/v8 chips starting to get a lot more popular out there ... I figured that y'all might be doing some unusual cluster booting techniques like I am here
[17:19] <Martyn> Will do
[17:20] <Martyn> LKML can be ... contentious :)
[17:20] <Martyn> LAKML is also .. contentious :)
[17:22] <mrutland> I boot my Juno with GRUB and TFTP, which works well enough for me
[17:23] <mrutland> There are some nice people on LAKML (and LKML), if you can ignore the noise
[17:25] <Martyn> Heh .. this work doesn't end with the Juno, of course.  just like with Smooth-Stone/Calxeda -- early steps
[17:25] <Martyn> Well, for now I'll stick to booting on 10gigE
[17:25] <Martyn> But I need to crack this PCIe issue
[19:03] <Martyn> mrutland : GAH!  solved it.
[19:04] <Martyn> mrutland : It was an out-of-order transaction happening on the PCIe bus... for some weird reason, the PCIe IP on the Juno isn't allowing it.
[19:05] <Martyn> IS there a limitation on the a57's architecture that breaks when there are out-of-order transactions on PCIe? ( like there was on the A9's? )
[19:06] <Martyn> Is relaxed ordering allowed?
[19:06] <Martyn> ( If I turn off the relaxed ordering bit in the TLP, things work )
[19:07] <Martyn> that would be bad news for things like 8 and 16 lane graphics cards...