[13:30] <gnrp> hu? 20.10 is out?
[13:30] <gnrp> Why didn' I update yet?
[14:18] <xtao> please do so I can see if you get the same bug I get :)
[16:51] <Tenpenchii> hi i new using This system and i really need to know .....whatś the way to set proxy server on the OS
[16:54] <diogenes_> Tenpenchii, click on network icon > edit connections, double click on your network > proxy.


[10:13] <teknico> uh oh, uistage is broken
[10:14] <teknico> I just landed a branch, but it's only doc changes, it shouldn't have broken it
[10:48] <frankban> teknico: working on it, it's not your branch
[10:48] <teknico> frankban, great, thanks
[11:30] <teknico> frankban, it worked :-)
[11:31] <frankban> teknico: yes indeed, it was just a missing reference in modules.js
[11:32] <teknico> yep
[13:00] <gary_poster> thank you for fixing uistage et al, frankban
[13:04] <frankban> gary_poster: welcome
[13:13] <frankban> gary_poster: is "needs retrospective" the right tag for when you want to discuss some details of that card during our Friday's call?
[13:13] <frankban> I mean: "class of service" -> "needs retrospective"
[13:13] <gary_poster> goodspud, hi.  I have a local lunch meeting at the time of the unit and service view meeting.  mm, benji or bac, you have experience with those pages.  Are you willing and able to attend a meeting at 1630-1700UTC and then report back to the group with minutes as I describe in "Engineer responsibilities" at the end of https://docs.google.com/a/canonical.com/document/d/1GevzPVClAJaGX7YHG6SmdX2geGvR7uXc4xnuc7VY3t4/edit
[13:13] <gary_poster> # ?
[13:14] <gary_poster> Specifically:
[13:14] <gary_poster> Engineer keeps minutes of the questions received, the input given, the decisions made, and the outstanding engineer-related questions and action items.
[13:14] <gary_poster> Engineer sends minutes to Juju GUI team and design team.
[13:14] <gary_poster> Engineer is responsible for getting the answers to each outstanding question from the meeting, or explicitly getting someone else to take over for that question.  If someone else takes responsibility, this hand-off is sent to the Juju GUI team and the design team.  The same goes for action items.
[13:14] <gary_poster> If an engineer is still on the hook for an answer or action item when a new meeting is called, they should consider themselves volunteered for the next meeting.
[13:14] <gary_poster> frankban, yes
[13:14] <frankban> gary_poster: cool thanks
[13:15] <bac> gary_poster: yes
[13:15] <gary_poster> welcome
[13:15] <gary_poster> thanks bac, I'll add you to the invitation
[13:15] <bac> i like the coercion of that last point.
[13:15] <bac> way to light a fire
[13:15] <benji> heh
[13:16] <goodspud> I'll bring snacks along to the meeting
[13:16] <goodspud> :)
[13:16] <gary_poster> :-)
[13:23] <gary_poster> benji, out of pur nosy curiosity, any progress on getting the production tests to pass?  I'm very curious as to what the resolution will be
[13:24] <benji> yep, I am down from approximately eight billion failures to 2
[13:24] <gary_poster> benji, lol, excellent
[13:24] <benji> they both appear to be of different classes of failures, so they will probably require different fixes, but I feel pretty good about it
[13:26] <gary_poster> cool, benji, thanks for overview.  once you get it working I'm thing that the default test target ought to test the production story, so we all are testing the end result by default.  we'd keep the previous test target as a way to debug.  wdyt?
[13:27] <gary_poster> teknico, approved Friday, no worries
[13:27] <benji> that's reasonable; if the tests were not so slow I would suggest running them both (or all three?), but that is not the case
[13:27] <gary_poster> right
[13:27] <gary_poster> I know!  we could parallelize them with lxc!
[13:27] <gary_poster> wait, no...
[13:29] <frankban> lol
[13:38] <gary_poster> bcsaller, could you update kanban board to reflect your current progress please?
[13:38] <bcsaller> gary_poster: done
[13:39] <gary_poster> thanks bcsaller
[13:41] <hazmat> bcsaller, what's next after ultra-mega?
[13:42] <bcsaller> hazmat: panzoom is in progress, put it on the board
[13:42] <bcsaller> one of the smaller ones to sort out remaining issues
[13:42] <bcsaller> part way through it after yesterday
[14:14] <teknico> gary_poster, thanks
[14:14] <gary_poster> welcome
[14:18] <teknico> in the code we have README and HACKING files, while in the charm we have README.txt , does anyone care about the extension?
[14:23] <gary_poster> I usually add it, but don't care a lot.  teknico, you available for a quick call on another topic (Makefile fun)?
[14:24] <teknico> gary_poster, in five minutes?
[14:24] <gary_poster> teknico, I have another meeting in 5 minutes :-) can do it in 35
[14:24] <teknico> gary_poster, ok, I'll hop on right away then
[14:24] <gary_poster> ok thanks
[14:39] <teknico> bac, what happens if the kanban active lanes are full and lp2kanban needs to put a card there?
[14:40] <bac> teknico: i'd be really surprised if that is handled gracefully.
[14:40] <teknico> bac, I guess we'll find out soon enough ;-)
[14:40] <bac> teknico: yes, should be interesting.  put on your eye protection!
[14:42] <teknico> bac, and earplugs too, for good measure!
[15:17] <teknico> uhm, nothing happened
[15:29] <gary_poster> bac bcsaller benji frankban goodspud hazmat jovan2 Makyo teknico call in 1
[15:31] <gary_poster> bac goodspud starting
[15:31] <bac> coming right there
[16:28] <goodspud> hazmat, bac - use the team hangout for the meeting
[16:30] <bac> goodspud: ok
[17:46] <frankban> could anyone please review https://codereview.appspot.com/6929057 ? no rush, I am near my EOD. Anyway, charm tests work again.
[17:53] <Makyo> frankban, taking a look.
[17:54] <frankban> thanks Makyo
[19:30] <hazmat> gary_poster, login stuff fwiw in lp:~hazmat/juju/rapi-login
[19:31]  * hazmat moves on to annotation support
[19:31] <gary_poster> hazmat awesome thanks.  we should switch to that from rollup?
[19:31] <hazmat> gary_poster, no.. i need to do some testing, i'll merge it into rollup after i get annotation support going
[19:31] <gary_poster> cool
[19:31] <hazmat> gary_poster, there are a couple of unit tests, but i'd like to do an end to end test with the gui & charm
[20:17] <gary_poster> sounds good
[21:28] <gary_poster> bac, benji, bcsaller, I'm reviewing all three cards up for review (only one left).  teknico's and Makyo's still need a second review, if you are willing and able.
[21:28] <benji> k
[21:29] <bcsaller> I can take one as well, tell me which you want benji and I'll take the other
[21:29] <bac> gary_poster: ok.  i will in a bit.  i just put my shoes on so the dogwalk cannot wait.
[21:29] <gary_poster> benji bcsaller bac I suggest you coordinate using the tags on the kanban cards.  put your nick on the one you plan to do or are doing
[21:30] <benji> I don't especially want one (or any), bcsaller; have at it
[21:30] <gary_poster> thanks all
[21:30] <gary_poster> :-)
[21:47] <gary_poster> Makyo, I take it the target-specific variables didn't have the characteristics we were hoping for?  Maybe they were evaluated anyway?
[21:48] <gary_poster> (lloking at https://codereview.appspot.com/6873071/diff/1/Makefile)
[21:48] <gary_poster> looking
[21:58] <Makyo> gary_poster, Correct.  Additionally, the variable containing the target name contained the current target (which changed as make worked through the dependency tree)
[21:58] <gary_poster> Makyo, yeah I saw that second one.  Too bad target specific variables are not lazy, but I guess that makes sense
[21:59] <gary_poster> in the context of other make decisions, I mean
[22:00] <Makyo> gary_poster, yeah.  Additionally the env var solution fits with the other release patterns, i.e.: PROD=1 make tarball
[22:00] <gary_poster> yeah, I thought of that.  I'm mostly just going to be asking for comments explaining why we have to do this stuff.
[22:01] <Makyo> gary_poster, okay.
[22:01] <Makyo> gary_poster, additionally, found out that bzr ls without the -V option lists all files in the directory (but still contacts the parent branch to do so), so the later instances of that translated neatly to find commands.
[22:02] <gary_poster> Makyo, cool, though we need to exclude editor effluvia from them at the least
[22:02] <Makyo> gary_poster, okay.  Wasn't before, but that's a good addition.
[22:02] <gary_poster> Makyo, it did, because we were using bzr ls
[22:03] <gary_poster> and we don't commit editor effluvia
[22:03] <Makyo> gary_poster, bzr ls without the -V option would include those files.  -V wasn't used in those latter two instances.
[22:03] <gary_poster> ah!
[22:03] <gary_poster> suck
[22:03] <Makyo> But that is a good addition for omitting.
[22:03] <gary_poster> well, then yes, please make it better :-)
[22:03] <Makyo> \o/
[22:03] <gary_poster> :-)
[22:09] <gary_poster> benji, for the charm, I'd like to be able to make a release file without uploading it.  you removed the phony target to do so.  Am I correct in assuming that you don't object to adding it back as long as we have a use case?
[22:12] <benji> gary_poster: ah, I hadn't reallized that was a use case; sure add it back
[22:13] <gary_poster> cool thanks
[22:13] <benji> I would love for us to have tests of the Makefile; I claim that we need a card to that end
[22:15] <gary_poster> benji, make a slack card to show us how we coudl do it please
[22:16] <gary_poster> we could do that in the charm too fwiw
[22:16] <gary_poster> though granted it would be nicer and more appropriate in the code itself
[22:20] <gary_poster> Makyo, reviewed: "Land with changes" :-)
[22:20] <gary_poster> running to get son from acting class...
[22:20] <Makyo> gary_poster, thanks :)
[22:25] <bac> gary_poster: i'm back but looks like all the reviews are taken
[22:48] <Makyo> Going to lay down for a bit.


[06:30] <ball> hello escoload_
[06:34] <escoload_> hey hey
[06:34] <escoload_> you in indiana?
[06:36] <escoload_> brb
[06:42] <escoloader> ball?
[06:42] <ball> No, I'm just across the state line in Illinois
[06:42] <ball> ...but there doesn't seem to be an Illinois Loco team.
[06:49] <escoloader> oh
[06:49] <escoloader> where in illinois?
[06:50] <ball> Bradley, right by Kankakee
[06:50] <escoloader> oh
[06:50] <escoloader> i was just down in charleston/matoon last weekend
[06:50] <escoloader> dont ask me why
[06:50] <escoloader> :)
[06:51] <ball> I used to live in Charleston, worked in Mattoon.
[06:51] <escoloader> brb
[06:51] <escoloader> oh, really?
[06:52] <escoloader> thats crazy
[06:52] <escoloader> brb
[06:54] <escoload_> hey


[02:34] <stone_> hi
[02:44] <stone_> i have problem with ubuntu one ,when ubuntuone first release beta,i upload files,now i use ubuntu 10.10,when i login my account now it is empty,nothing i found ,what i can do ,contact canonical???
[02:45] <stone_> hello
[02:48] <stone_> hello?
[09:36] <rye> hi CardinalFang, what's the usual troubleshooting process for Ubuntu One Music (android) - alogcat debug?
[09:36] <rye> anybody here has Motorola Droid 2 with Ubuntu One Music Streaming app
[09:36] <rye> ?
[09:40] <duanedesign> <.<  >,>
[09:54] <JamesTait> Happy Wednesday folks!
[12:19] <snpresent> hello,is there anybodyhere?
[12:32] <snpresent> hello
[12:43] <snpresent> hello there
[12:45] <CardinalFang> rye, yes, "adb logcat" with SDK, or mail log from "aLogcat" app.
[12:47] <rye> CardinalFang, ok, it turned out there was a concurrent thread so the user already got the response, you can delete that message :)
[13:17] <CardinalFang> "Sorry, Bug Report Tool closed unexpectedly.\n...you can help to improve the application by reporting the problem."
[13:27] <rye> :-D
[13:33] <ralsina> good morning everyone
[13:34] <ralsina> sorry about the late chackin, my bank has decided I can't deposit checks when they are closed anymore.
[13:51] <ralsina> alecu CardinalFang dobey nessita thisfred vds standup in 10'
[13:52] <thisfred> yepyep
[13:52] <ralsina> mandel's not showing because of pain & drugs
[13:58] <nessita> ack
[13:58] <CardinalFang> me
[13:58] <ralsina> CardinalFang: early!
[13:58] <ralsina> me
[13:59] <vds> me
[13:59] <thisfred> me
[14:00] <nessita> me
[14:00] <alecu> me
[14:01] <ralsina> and dobey is late, so... CardinalFang please?
[14:01] <CardinalFang> DONE: Tracked down weird bug caused by U1 offline-db and middleware, and changed desktopcouch to avoid it.  Proposed fix for bug #711208.
[14:01] <CardinalFang> TODO: Release and package desktopcouch.  Finally work for Web&Mobile.
[14:01] <CardinalFang> BLOCKED: None
[14:01] <CardinalFang> ralsina, por favor
[14:01] <ubot4> Launchpad bug 711208 in ubuntuone-servers (and 1 other project) "desktopcouch-service doesn't like UbuntuOne-API error pages (affects: 1) (heat: 6)" [Undecided,Invalid] https://launchpad.net/bugs/711208
[14:01] <ralsina> DONE: reviews, did my canonicaladmin work, more research for sprint, team leads call, other calls.
[14:01] <ralsina> TODO: reviews, management stuff, sprint planning, someday actual coding ;-)
[14:01] <ralsina> BLOCKED: no
[14:01] <ralsina> LOVE: PyQt
[14:01] <ralsina> HATES: Not coding PyQt
[14:02] <ralsina> vds!
[14:02] <vds> DONE: eighth branch for #701029 landed ninth started
[14:02] <vds> TODO: url testing now
[14:02] <vds> BLOCKED: again nope, but I will need DAL to support uploading of files soon
[14:02] <vds> thisfred, please
[14:02] <thisfred> DONE: landed branch that adds counts to messages and updates to notifications | started mock test branch
[14:02] <thisfred> TODO: finish and land mock test branch | start hooking up messages
[14:02] <thisfred> BLOCKED: no
[14:02] <thisfred> nessita!
[14:02] <nessita> DONE: Split epic shares-subscription branch into smaller branches (already proposed 3 for review, I need reviews!). Started adding dbus methods to syncdaemon to manage shares subscription. Could not do the IRL testing due to service outage and later got stuck due to syncdaemon weirdness/bugs. Got also problems when building dbus-related tests, due to bug #711470.
[14:02] <nessita> TODO: really, finish dbus branch for bug #708335 and do some IRL testing, please.
[14:02] <nessita> BLOCKED: apparently today I'm ok, but yesterday got several blocks (already listed on DONE).
[14:02] <nessita> HATE: delays due to debugging of weird behaviors.
[14:02] <nessita> NEXT: alecu
[14:02] <ubot4> Launchpad bug 711470 in ubuntuone-client "u1trial is (somehow) using the real SD DBus service (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/711470
[14:02] <ubot4> Launchpad bug 708335 in ubuntuone-client "Add subscription capabilities to shares (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/708335
[14:02] <alecu> DONE: more notifications discussion, half way thru a big branch to rate limit and make everybody happy.
[14:02] <alecu> TODO: finish said branch, work on session logout blocking
[14:02] <alecu> BLOCKED: no
[14:02] <alecu> NEXT: dobey
[14:03] <ralsina> nessita: I'll do your reviews
[14:03] <ralsina> dobey will appear eventually. I really am going to call him at standup-10'
[14:03] <ralsina> any comments, things where you need help, etc?
[14:03] <alecu> nessita, regarding bug 711470...
[14:03] <ubot4> Launchpad bug 711470 in ubuntuone-client "u1trial is (somehow) using the real SD DBus service (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/711470
[14:04] <nessita> alecu: is fixed
[14:04] <alecu> nessita, how so?
[14:04] <nessita> alecu: but go ahead :-)
[14:04] <nessita> alecu: dobey added a branch late yesterday
[14:04] <nessita> DbusTwistedTestCase in test_dbus was not inheriting from DbusTestCase
[14:04] <alecu> ah, ok.
[14:04] <alecu> good to know.
[14:04] <nessita> but it took 2 to 3 hours of my life away :-)
[14:05] <nessita> I was struggling so much with some tests, until v-erterok made me notice the real SD was being used :-(
[14:05] <nessita> aaaanyways
[14:05] <ralsina> ouch
[14:05] <nessita> ralsina: what's with the API work?
[14:06] <ralsina> nessita: if you are done with the urgent stuff, then we can talk with vds, CardinalFang and thisfred to see what's still to be done
[14:06] <dobey> hi
[14:06]  * ralsina makes tick-tock noises in dobey's direction ;-)
[14:07] <nessita> ralsina: I'm not done, but wanted to know how that is going
[14:07] <ralsina> nessita: we can talk about it then.
[14:07] <dobey> λ DONE: bug 711452, bug 711462, bug 711470
[14:07] <dobey> λ TODO: finish bug 673012, evaluate SRUs for maverick
[14:07] <dobey> λ BLCK: None.
[14:07] <ubot4> Launchpad bug 711452 in ubuntuone-client "SyncDaemon-1.0.gir not usable from C (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/711452
[14:07] <ubot4> Launchpad bug 711462 in ubuntuone-client "libsyncdaemon needs a Vala .vapi binding (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/711462
[14:07] <nessita> ralsina, alecu, vds, dobey, CardinalFang, thisfred: let's schedule a talk to get us up to date with API works?
[14:07] <ubot4> Launchpad bug 711470 in ubuntuone-client "u1trial is (somehow) using the real SD DBus service (affects: 1) (heat: 6)" [Critical,Fix committed] https://launchpad.net/bugs/711470
[14:08] <ubot4> Launchpad bug 673012 in desktopcouch (Ubuntu) (and 1 other project) "Async monitoring of _changes (affects: 1) (heat: 39)" [Undecided,Confirmed] https://launchpad.net/bugs/673012
[14:08] <ralsina> nessita: it's not really done with a fixed goal, just "do as much as you can in this time slot" so it's going well by definition. You just need to know where you start the job :-)
[14:08] <thisfred> sure
[14:08] <nessita> right
[14:08] <ralsina> nessita alecu vds thisfred CardinalFang: sure
[14:08] <nessita> let's have a talk in 50 minutes?
[14:08] <nessita> that would be 15 UTC
[14:08] <vds> nessita, +1
[14:08] <ralsina> dobey has been doing other stuff and is now on shotwell so he's excused
[14:08] <ralsina> +1 for 50 minutes
[14:08] <nessita> ah ok
[14:09] <ralsina> We need a timezone bot
[14:09] <dobey> i did some work on the glib async thing
[14:09] <nessita> ralsina: 12 ART
[14:09] <ralsina> That receives "in 40 minutes" and says the UTC time :-)
[14:09] <ralsina> nessita: cool
[14:09] <alecu> 50': ack
[14:10] <dobey> but it's not working right, and i realized it has some other issues. and it is probably better to do the polling :(
[14:12] <dobey> i could use some reviews for https://code.launchpad.net/~dobey/ubuntuone-client/libsd-vapi/+merge/48238 though
[14:12] <dobey> it certainly adds to the API story :)
[14:12] <karni> hi everyone
[14:13] <ralsina> dobey: I'll check it but my Vala is unexistant
[14:13] <dobey> ralsina: not really much vala in it (just a simple test to ensure stuff will build with the generated .vapi)
[14:13] <ralsina> dobey: ok
[14:16] <ralsina> eom?
[14:16] <nessita> eom!
[14:16] <dobey> thisfred: is bug 675557 fixed then, since we updated to 0.8?
[14:16] <ubot4> Launchpad bug 675557 in desktopcouch (Ubuntu) (and 1 other project) "Incorrect encoding of slashes in paths (affects: 1) (heat: 42)" [Medium,In progress] https://launchpad.net/bugs/675557
[14:17] <thisfred> dobey, not sure, I thought it was fixed in 0.8 but saw some evidence since that it might not have been
[14:26] <alecu> dobey, branch approved.
[14:27] <nessita> ralsina: my reviews are, in order (each one has prerequisite the former): https://code.launchpad.net/~nataliabidart/ubuntuone-client/share-autosubscribe/+merge/48155
[14:27] <nessita> https://code.launchpad.net/~nataliabidart/ubuntuone-client/add
[14:27] <nessita> https://code.launchpad.net/~nataliabidart/ubuntuone-client/share-subscription-ops/+merge/48170
[14:27] <ralsina> nessita: will check them in 5'
[14:27] <nessita> the second one got messed up, proper link is https://code.launchpad.net/~nataliabidart/ubuntuone-client/add-subscribed-to-shares/+merge/48166
[14:27] <nessita> thanks!
[14:28] <alecu> dobey, you might want to know that on maverick that branch fails with: "configure: error: gobject-introspection is required to generate a vapi", even though the gobject-introspection package is fully updated
[14:28] <alecu> dobey, but no problems on natty, so I've approved.
[14:29] <dobey> alecu: you are missing something required for the gobject-introspection stuff to build
[14:33] <dobey> maybe i should change that to not be an ERROR; not sure
[14:36] <duanedesign> 'lo all
[14:37] <ralsina> dobey: this is pretty much natty-only at least when it comes to shotwell
[14:37] <ralsina> dobey: but the message is a bit confusing since it doesn't say what is missing
[14:38] <dobey> yeah, it doesn't know what's missing, it just knows that GOBJECT_INTROSPECTION_CHECK failed
[14:38] <ralsina> rephrasing: you are doing it so you can do the shotwell plugin, and that's for natty. It would be neat if it worked on other versions, but that's not really important right now unless it's very easy to fix.
[14:38] <dobey> it works on other versions
[14:38] <ralsina> dobey: it just has some mistery dependency?
[14:39]  * ralsina is trying to understand the problem, really
[14:39] <dobey> no
[14:39] <ralsina> BTW, approved it because it Works For Me (TM)
[14:39] <dobey> hrmm, well i guess it won't build on lucid as is there
[14:53] <ralsina> nessita: reviews will start after mumble because I have 350MB of nightlies (yay!)
[14:53] <nessita> no problem
[14:57] <alecu> anybody can help testing mumble?
[15:01] <ralsina> alecu: sure
[15:02] <ralsina> nessita alecu thisfred vds mumble!
[15:02] <alecu> ralsina, we are starting right now, aren't we?
[15:02] <thisfred> uh ok
[15:02] <nessita> ralsina: we're there! :-)
[15:02]  * thisfred goes looking for headphones
[15:02] <nessita> ralsina:  CardinalFang too?
[15:03] <ralsina> Yes
[15:03] <ralsina> CardinalFang: mumble!
[15:04] <ralsina> vds mumble ping?
[15:05] <dobey> hmm
[15:06] <vds> ralsina, starting it up
[15:07] <ralsina> dobey: you are welcome too, of course :-)
[15:07] <ralsina> dobey: I just suspect you'll be terribly bored by it ;-)
[15:07] <dobey> is it going to be long?
[15:07] <ralsina> who knows. I hope not.
[15:29] <thisfred> alecu, (mock) testing for messaging done, now working on notification.  I think I will restart it and try again, just in case.
[15:52] <ralsina> datahub*
[15:53] <dobey> hmm
[15:53] <dobey> no idea
[15:53] <ralsina> dobey: I'll try a couple of things and see if I can get some info or repeat the crash
[15:54] <dobey> ralsina: there is probably something wrong with your python installation
[15:55] <ralsina> dobey: I don't see how that could be, but I suppose it's possible.
[15:56] <dobey> well, it explains multiple python things "crashing" around the same time :)
[16:01] <ralsina> dobey: yes it does, it's just that I never touched the python here :-)
[16:01] <ralsina> dobey: the intltool complaining about mismatched quotes is normal, right?
[16:02] <ralsina> Hey, unity-2d has more things in the launcher now.
[16:04] <ralsina> no crashes so far. It may have been OOM killer.
[16:05] <ralsina> spoke too soon. At least apport seems to be working right
[16:05] <ralsina> "The problem cannot be reported: this is not a genuine Ubuntu package"
[16:05] <ralsina> WTF
[16:05] <dobey> well apt-get upgrade might have doen something or failed
[16:06] <dobey> and yeah the mismatched quotes isn't a big problem or fatal
[16:07] <ralsina> weirder: the tests are green anyway
[16:34] <thisfred> alecu:  https://code.launchpad.net/~thisfred/ubuntuone-client/mocky-horror-picture-show/+merge/48339
[16:38] <nessita> lunchtime!!!
[16:41] <ralsina> dobey ping: ubuntuone-client is not building
[16:42] <ralsina> dobey: it's the new vala stuff in lucid and also natty
[16:46] <alecu> thisfred, lovely! reviewing.
[16:47] <alecu> thisfred, remember the "notification" that was returned by show_notification and used by update_notification... are you going to do that change in a further branch?
[16:47] <alecu> thisfred, oh, it's already there?
[16:51] <duanedesign> conflicts that occur when a user has only one computer on his U1 account could be the file changing between the time the metadata syncs and the content syncs?
[16:57] <rye> facundobatista, ^
[16:58] <rye> duanedesign, i am really interested in that, i was told that conflicts are generated when client notices that server-side hash is not the same it has locally (i.e. upon upload/download md gets updated server-side hash)
[16:59] <karni> How twisted is that. ActionQueue uses ActionQueueCommands that are queued in RequestQueue that takes ActionQueue as a parameter. Can't decide where to bite first.
[17:10] <facundobatista> karni, and I'm changing that heavily
[17:10] <facundobatista> duanedesign, shouldn't be conflicts there... better to get logs and check
[17:10] <karni> facundobatista: it's you who was working on the command pool, weren't you?
[17:11] <facundobatista> duanedesign, otoh, we fixed some issues in the past about that, so please check the client version
[17:11] <facundobatista> karni, yes, and still working....
[17:12] <karni> facundobatista: right. I decided, however, that meta/content queues are quite good idea for Android. we don't have multiple streams (not really necessary on a mobile device), and queuing makes things clean.
[17:12] <karni> facundobatista: so, in the end, I decided to port that code
[17:12] <facundobatista> karni, those already disappeared
[17:13] <karni> facundobatista: I know. but it's because on a PC each command handles it's lifecycle on it's own, doesn't it?
[17:13] <facundobatista> yes
[17:14] <karni> facundobatista: Right. And I vote for one-command-at-a-time on Android :) Do you have anything to say about it? Any suggestions?
[17:14] <karni> facundobatista: It's good time to talk, as I've ported other parts and the action queue is the last that I need.
[17:14] <karni> that I *want ;)
[17:14] <facundobatista> karni, why one command at a time?
[17:15] <facundobatista> karni, why not two unlinks in parallel, for example?
[17:16] <duanedesign> facundobatista: thank you
[17:16] <karni> facundobatista: IRL, when do we have more then 1 unlink in parallel?
[17:16] <karni> when a folder is deleted?
[17:16] <karni> (or is it just 1 unlink per deleted folder?)
[17:17] <nessita> ralsina: any news on the reviews?
[17:17] <ralsina> nessita: almost done with the first one, sorry it took so long
[17:18] <nessita> no problem, I'm glad your system now works
[17:18] <karni> facundobatista: I'll head and read the merge proposal comment of yours again. The one from unleashed queues.
[17:18] <ralsina> nessita: I did get two errors on the tests but it's because of the strange crashes
[17:19] <ralsina> So I will approve it anyway. Not branch-related at all, it seems.
[17:19] <nessita> ralsina: wanna pastebin them?
[17:19] <ralsina> nessita: sure, 1 minute
[17:19] <facundobatista> karni, ok
[17:20] <ralsina> nessita: https://pastebin.canonical.com/42743
[17:21] <ralsina> Apparently the VBox extensions broke, so I have to copy by hand :-(
[17:22] <ralsina> Oh, unity2d does lots of new things (the automounter works great)
[17:22] <joshuahoover> nessita: ping
[17:23] <nessita> joshuahoover: pong
[17:23]  * thisfred holds out for unity-1d
[17:23] <ralsina> thisfred: you can use 2d and close the notebook's lid!
[17:23] <karni> facundobatista: all-pushing-kwargs-6 contains unleash-the-queues, doesn't it?
[17:23] <thisfred> if they can do it for wolfenstein, they can do it for unity
[17:23] <joshuahoover> nessita: ubuntuone-preferences from command line gives gnomekeyring.BadArgumentsError for a user...not sure what version of ubuntu
[17:24] <thisfred> ralsina: closing it so that only a single line of pixels is visible will be hard :)
[17:24] <ralsina> thisfred: you leave just a bit of reflected light escape and deduce from that :-)
[17:24] <facundobatista> karni, yes, but other unrelated changes... maybe get https://code.launchpad.net/~facundo/ubuntuone-client/unleash-the-queues-5/+merge/48179
[17:25] <karni> facundobatista: right right, thanks. I see it
[17:26] <nessita> joshuahoover: I have no idea what that can be. I do know that accessing the keyring using gnomekeyring is extremely buggy  and crashy, so I only can advice to move to a newer version of ubuntu
[17:26] <joshuahoover> nessita: ok, thanks!
[17:27] <nessita> joshuahoover: sorry for not being of much help :-(
[17:27] <joshuahoover> nessita: np, just wanted to see if it was something you knew about :)
[17:27] <nessita> joshuahoover: but the keyring has tons of weird corner cases, specially with autologin
[17:27] <joshuahoover> nessita: yes, sigh...
[17:27] <karni> facundobatista: dang. I think your merge proposal comment was nice and descriptive, but I can't find it anymore :< (the one form unleash-the-queues)
[17:29] <facundobatista> karni, https://code.launchpad.net/~facundo/ubuntuone-client/unleash-the-queues-3/+merge/46281 ?
[17:29] <karni> facundobatista: perfect! thanks
[17:32] <dobey> hrmm
[17:34] <dobey> grr
[17:34] <dobey> wtf, valac is in the control file
[17:36] <dobey> well, that's some ole bs
[17:39] <dobey> ralsina: not sure why the buildd didn't install vala on those. weird.
[17:39] <ralsina> dobey: I'm sure you will figure it out.
[17:40] <ralsina> dobey: these things hardly ever come up right the first time.
[17:41] <dobey> what it looks like, is that the recipe stuff pulled half of the revision or something
[17:42] <dobey> oh, no
[17:42] <dobey> doh
[17:43] <dobey> i see
[17:43]  * dobey fixes
[17:43] <dobey> next builds should work
[17:43] <dobey> and i just approved one of nessita's branches, so we'll have another build in a few minutes
[17:44] <nessita> dobey: thanks
[17:46] <dobey> wow, something on my phone has caused it to go nuts :(
[17:46] <ralsina> dobey: that's the one I've been testing for an hour :-D
[17:46] <dobey> heh
[17:46] <ralsina> oh, well, onto the next one
[17:46] <dobey> sorry :P
[17:46] <ralsina> dobey: np, I was getting misterious failures anyway
[17:47] <nessita> ralsina: there are 3 more in the queue, so you'll get more fun :-)
[17:47]  * dobey turns off the linkedin/facebook contacts
[17:48] <ralsina> nessita: he, this policy that I will review anything you guys ask is making me learn so much ;-)
[17:48] <nessita> :-D
[17:49] <ralsina> nessita: since the first branch is approved, now I only need to merge the second one to trunk, right?
[17:49] <nessita> ralsina: yes, becasue the prerequisite is already merged on my branch
[17:49] <ralsina> nessita: ok
[17:49] <dobey> meh, i hate finding bugs in our dependencies
[17:50]  * ralsina is using hg, bzr and git every day, and they are exactly different enough to make his head hurt
[17:50] <jdobrien> ralsina, like using python, javascript and c# at the same time :)
[17:51] <ralsina> jdobrien: yeah, if they were MORE different I could context-switch
[17:51] <ralsina> but right now I wonder why hg has multiple tips per branch and git doesn't and so on
[17:52] <ralsina> Or maybe git does and it just never happened to me. git is mysterious.
[17:52] <dobey> people use hg?
[17:52] <ralsina> dobey: well, on googlecode it's hg or svn
[17:52] <dobey> should have used svn :)
[17:52] <ralsina> dobey: so I've been using hg in my after-hours project these last week
[17:53] <dobey> or just move it to launchpad ;)
[17:53] <ralsina> dobey: I would have, but I am not the only one in the project and... well, they wanted to be modern ;-)
[17:53] <ralsina> dobey: I personally find googlecode much friendlier for a casual project. Less bureaucratic :-(
[17:54] <dobey> yeah, there is a lot of nonsensical madness on launchpad
[17:54] <ralsina> googlecode is like "here's a wiki, here's VCS, here's an issue tracker, start coding"
[17:56] <karni> facundobatista: are downloads run in parallel in unleashed-queues ?
[17:57] <dobey> hrmm
[17:57] <dobey> learning spanish by listening to Manu Chao is probably not the best way to learn it
[17:57] <beuno> it's not the worst either
[17:57] <dobey> well, yeah, i could just learn from mandel
[17:58] <ralsina> dobey: well, we understand what he says, at least.
[17:58] <ralsina> dobey: you would only learn synonims for excrement
[17:59] <karni> facundobatista: the thing is, I wouldn't want to run too many things at a time. plus, phones screen and 1 finger are somewhat less capable than nautilus and a mouse.
[17:59] <ralsina> And I must say spaniards are pretty hard to understand for most spanish-speakers :-)
[17:59] <karni> facundobatista: having said that, unleashed queues may be simpler - which is good. but I liked the control over queueing stuff..
[18:00] <dobey> ralsina: sure, i had a much easier time understanding/reading things in BA, than I did in Barcelona
[18:00] <karni> facundobatista: so I'll happily hear out what you've got to say
[18:00] <ralsina> dobey: with some spaniards is like learning english from scotsmen
[18:01] <dobey> hehe
[18:01] <ralsina> Sure, you will sound cool, like Desmond in Lost. But understanding what you say is something else :-)
[18:01] <ralsina> brodah!
[18:01] <facundobatista> karni, right now Uploads and Downloads have a semaphore to not run too many of those at the same time
[18:01] <dobey> ralsina: we'll have to introduce you to kevin
[18:01] <karni> facundobatista: ah, perfect!
[18:02] <facundobatista> karni, you may want to extend that to all commands, and may be simpler to reuse last code
[18:02]  * ralsina has a terrible-enough accent already
[18:02] <karni> facundobatista: this sound better every time we talk! great
[18:02] <facundobatista> karni, :D
[18:02] <karni> ;)
[18:06] <karni> facundobatista: so, just to be sure we're on the same page, I should get unleash-the-queues-5 to get me started with the latest action_queue, is that correct?
[18:07] <karni> facundobatista: or should I merge it with all-pushing-kwargs-6 (EventQueue is also important piece for me)
[18:09] <facundobatista> karni, my better recomendation will be for you to wait for unleash-the-queues-6, which impacts heavily in command life cycle (making it simpler)
[18:09] <facundobatista> karni, this branch should be proposed today or tomorrow...
[18:09] <karni> facundobatista: I see..
[18:09]  * karni tries to come up with something else to code
[18:10] <karni> facundobatista: I'll be waiting for it :) It'd be cool if you could ping me when that's ready
[18:13] <facundobatista> karni, ok
[18:13] <ralsina> I am about to add another CPU to the natty VM. make test takes forever :-(
[18:14] <dobey> ralsina: make sure whatever branch of ubuntuone-client your testing either has my fix from yesterday, or doesn't have the chane to remove test_preferences.py
[18:15] <dobey> ralsina: for some reason, that bug also ended up having insane memory usage by u1trial, and made things much slower
[18:15] <ralsina> dobey:  Is your fix in trunk? If it is, I have it.
[18:15] <dobey> yes it is in trunk
[18:15] <dobey> but if you're testing someone else's branch, they might not have the fix in their branch, if they branched before that chanage :)
[18:15] <ralsina> dobey: memory usage is ok, it's just maxing one i3 core all the time
[18:16] <ralsina> dobey: I branch trunk and merge the testing branch, so I should have it anyway
[18:16] <dobey> ah ok
[18:16] <ralsina> Besides, I have 8 freaking GBs of RAM now :-)
[18:18] <karni> ralsina: my first PC-class computer had 32 megs of RAM I think. And I know Bill Gates thought nobody would ever need more than 512KB ;)
[18:18] <ralsina> karni: I sold a bike to get a 286 with 640kb of RAM, two 5 1/4 floppies and no HD :-)
[18:18] <karni> ralsina: That sounds awesome
[18:19] <ralsina> I think I remember it being 12Mhz with a turbo button for 16Mhz of awesomeness
[18:19] <karni> I mean, selling a bike for a computer. That must have been times.
[18:19] <ralsina> karni: well, I am sure my biking career would have been less lucrative, so it worke out fine ;-)
[18:20] <dobey> ralsina: you should get a new machine with turbo button
[18:20] <ralsina> dobey: they are out there again!
[18:20] <ralsina> dobey:  I saw an atom netbook with an overclock switch at the back
[18:20] <karni> dobey: I had 166MMX. the turbo LED wouldn't turn off even if I pushed the turbo button multiple times ;d
[18:21] <ralsina> There was a guy that would overclock customer PCs by rearranging the leds that told you the Mhz on the cabinet
[18:21] <karni> ralsina: muahahahah
[18:21] <dobey> ralsina: the new i7 mobile chips have "turbo boost" too
[18:21] <karni> I am so tweeting this
[18:22] <ralsina> dobey: I will probably get an i7 this year, if they have decent battery life. I'm not a fan of 1st generation anything
[18:23] <dobey> i might if i can find a suitable form factor laptop
[18:24] <ralsina> karni, what's your twitter?
[18:24] <karni> ralsina: I just @ at you ;) mkarnicki
[18:24] <dobey> hrmm
[18:24] <ralsina> there, followed :-)
[18:24] <dobey> man
[18:25] <karni> ralsina: ^^
[18:25] <ralsina> dobey: for you that means a 6" i7 right?
[18:25] <dobey> i wish the weather would stay like this for the next 2 months
[18:25] <dobey> ralsina: ideally, 8 or 9
[18:25] <dobey> ralsina: but 8 or 9 with high resolution
[18:25] <dobey> not that 800x480 bollocks
[18:25] <ralsina> I would love a 9" with decent performance and at least 1280x1024 or something like that
[18:25] <ralsina> I miss 4:3 screens
[18:25] <ralsina> Somuch vertical space!
[18:26] <dobey> 1920x108 would be nice
[18:26] <dobey> on 9"
[18:26] <ralsina> 108? That's radical widescreen ;-)
[18:26] <dobey> 1080
[18:27] <ralsina> I don't think we are getting that on9" for a couple of years. At least at a reasonable cost
[18:27] <dobey> i don't see why not
[18:27] <ralsina> dobey: because 9" are expected to be cheap andultra densedisplays are expensive
[18:27] <dobey> well, aside from the fact that companies aren't producing 9" 1080p LCD/LED panels, because they think they won't sell
[18:28] <dobey> ralsina: they aren't that expensive
[18:28] <ralsina> Same reason apple isnot making a 300+ dpi ipad 2 this year :-)
[18:28] <dobey> ralsina: and the larger screens are usually cheaper
[18:28] <ralsina> dobey: yes, the expensive thing is pixel density, not quantity
[18:28] <dobey> not really
[18:29] <dobey> they don't even make 1920x1200 15" screens any more, and those weren't very expensive
[18:29] <ralsina> dobey: notebooks or desktop monitors?
[18:29] <dobey> notebook
[18:29] <dobey> i wish they made them like that for workstation
[18:29] <ralsina> the 15" notebooks are supposed to be dirt cheap too
[18:29] <ralsina> That's why they get crap screens
[18:29] <dobey> they are now
[18:30] <ralsina> The "premium" notebooks are 12" and17"
[18:30] <dobey> dell used to have a 1920x1200 15" laptop though
[18:30] <dobey> and it wasn't really expensive
[18:30] <ralsina> dell's adamo is not a terrible notebook and is not expensive anymore.  If they only had warranty on Argentina...
[18:31] <karni> vds: how's REST coming along :)?
[18:32] <ralsina> All dell's 15" are now 1366x768 => crap
[18:35] <dobey> hell
[18:35] <dobey> i would be happy if i could buy ONLY a 9" 1080p AM-OLED panel
[18:35] <dobey> i would make my own laptop case and shove some other hardware in it
[18:36] <dobey> because i am awesome like that
[18:37] <dobey> sigh, i fixed the one problem with the nightlies
[18:37] <dobey> and now, another one :(
[18:39] <dobey> it's going to take me like 6 hours to remove my linkedin/fb accounts from my phone i guess :(
[18:40] <dobey> hrmm, and i really need to apt-get upgrade my workstation, and reboot it and muck with these dram settings so i can tell the ocz guy they don't work, so i can hopefully get my rma
[18:40] <ralsina> chad ping
[18:40] <ralsina> Oops, CardinalFang ping :-)
[18:40] <dobey> oh yay, it built on natty
[18:40] <dobey> but not on m or l
[18:40] <dobey> doh
[18:42] <ralsina> nessita: test failure in the lp:~nataliabidart/ubuntuone-client/add-subscribed-to-shares branch: https://pastebin.canonical.com/42753/
[18:42] <ralsina> This is on natty +nightlies
[18:43] <nessita> ralsina: alredy fixed, please re pull
[18:43] <nessita> :-)
[18:43] <ralsina> ok
[18:43] <nessita> (I noticied a few minutes ago)
[18:45] <dobey> doh and lucid has some other issues
[18:45] <dobey> bother.
[18:48] <dobey> and i could do without all this wind here
[19:02] <CardinalFang> ralsina, hi
[19:03] <ralsina> hi chad
[19:03] <ralsina> I wanted to know ifyou made any progress with the replication problem
[19:04] <dobey> alecu: ping
[19:05] <dobey> alecu: you still do primary development on maverick?
[19:09] <alecu> dobey, yes. And testing on natty.
[19:10] <dobey> alecu: when you do 'make -C libsyncdaemon' in ubuntuone-client trunk, do you get a SyncDaemon-1.0.gir built?
[19:11] <alecu> let me check
[19:13] <CardinalFang> ralsina, I'm pretty sure it works.  I'm verifying for release now.
[19:14] <ralsina> CardinalFang: oh, that's GREAT news
[19:16] <Chipaca> ah!
[19:16] <Chipaca> CardinalFang:  not in nightlies even yet?
[19:17] <CardinalFang> Chipaca, I saw you say "HTTP 400".  I don't know what to make of that yet.
[19:17] <dobey> Chipaca: the nightlies should have the fixes yes
[19:17] <Chipaca> I just pulled the nightlies and am getting a traceback
[19:18] <Chipaca> (first the 400, and now a traceback, both with the nightlies)
[19:18] <dobey> or well should have the code, whether it works or not i don't know :)
[19:19] <Chipaca> ah, but maybe it's my disabling of stats that broke it. forgot to turn that back on. gimme a sec.
[19:19] <alecu> dobey, it does not generate any .gir files
[19:19] <CardinalFang> Hrm.
[19:20] <dobey> alecu: and you have ppa:ubuntuone/nightlies deb-src listed in software-properties-gtk?
[19:21] <alecu> dobey, oh, the deb-src were disabled
[19:21] <Chipaca> CardinalFang: is there a way to force a replication, or do i have to wait 10 minutes?
[19:21] <alecu> dobey, I'll try right now.
[19:21] <dobey> alecu: re-enable it and apt-get build-dep ubuntuone-client and try please :)
[19:22] <CardinalFang> Chipaca, you have to wait, or kill "desktopcouch-service"
[19:23] <Chipaca> *gasp*
[19:23] <Chipaca> CardinalFang: ok, some progress, but then it died
[19:23] <Chipaca> CardinalFang: sorry, it didn't die, but something tracebacked
[19:23] <Chipaca> CardinalFang: I'll be quiet now and upload the full log when it says it's done
[19:24] <CardinalFang> Chipaca, er, well, a traceback isn't necessarily bad.  I'm catching exceptions and logging them in a few places.
[19:24]  * CardinalFang waits.
[19:24] <Chipaca> ServerError: (500, ('json_encode', '{bad_term,<0.267.0>}'))
[19:24] <Chipaca> ^ that one does seem bad-ish :)
[19:24] <CardinalFang> Ah. That's probably bad.
[19:24] <Chipaca> the others are db_not_founds, which don't seem too bad.
[19:25] <CardinalFang> HTTP 500 from couchdb could mean corrupted DB.
[19:26] <CardinalFang> It's not likely something I could fix, in any case.
[19:26] <Chipaca> CardinalFang: https://pastebin.canonical.com/42761/
[19:27] <Chipaca> CardinalFang: was it /_all_docs?with_documents=1 ? (to get everything in a db)
[19:28] <CardinalFang> Chipaca, the rest looks normal.
[19:28] <CardinalFang> Chipaca, that looks right, or very close to it.
[19:28]  * Chipaca reads the api docs
[19:29] <Chipaca> CardinalFang: include_docs
[19:29] <CardinalFang> Ah, right.
[19:29] <Chipaca> and =true :)
[19:29] <nessita> dobey: newly user created in natty, started the desktop session for the first time, added computer to U1, and U1 is not in the shortcut section from nautilus (left panel, bottom half, next to Documents, Music, Pictures, Videos and Downloads)
[19:29] <Chipaca> so, I'm able to get all the docs fine
[19:30] <Chipaca> what's tripping couchdb up?
[19:31] <dobey> ah, launchpad's exceptional use of <blink>
[19:31] <Chipaca> dobey: ?!?
[19:31] <dobey> nessita: hrmm, don't know.
[19:31] <CardinalFang> Chipaca, are you talking to rayas or couchdb.one.u.c?
[19:31] <dobey> Chipaca: file a bug and watch the pulsing "Thank you for your bug report" info box
[19:31] <Chipaca> CardinalFang: to couchdb.one.u.c
[19:32] <Chipaca> CardinalFang: https://couchdb.one.ubuntu.com/u%2f651%2f2bd%2f11/contacts/_all_docs?include_docs=true
[19:33] <ralsina>  gack, my notebook crawled for 15 minutes and suddenly snapped back to life
[19:33] <CardinalFang> Chipaca, check local also.
[19:36] <Chipaca> CardinalFang: local didn't have a contacts prior to this; now it has one with no records other than _design
[19:37]  * CardinalFang boggles.
[19:38] <nessita> ralsina: how are the  reviews coming? can I help you somehow?
[19:39] <ralsina> nessita: it just takes forever to run the tests
[19:39] <ralsina> I amfinishing second branch in a few mintes, I hope
[19:39] <nessita> yeah, I've noticed that too, since a few weeks now
[19:41] <dobey> hmm
[19:41] <CardinalFang> Chipaca, want to go to #couchdb and fish for answers?
[19:42] <CardinalFang> Oh, you're already there.
[19:47] <dobey> verterok: it seems like dbus-daemon does not want to be run on lucid :(
[19:48] <verterok> dobey: it used to run ok in the with the old runner
[19:48] <verterok> s/in the//
[19:49] <dobey> verterok: the way dbus-daemon is started has not really changed :(
[19:49] <verterok> oh
[19:49] <dobey> anyway, i am looking
[19:49] <dobey> running dbus-daemon on the command line it is not wanting to start
[19:51] <dobey> oh
[19:51] <dobey> crap
[19:53] <dobey> ok, will have a fix shortly
[19:55] <dobey> verterok: can you report a bug against ubuntuone-dev-tools please?
[19:55] <verterok> sure
[19:56] <dobey> thanks
[19:56] <alecu> dobey, now I get errors while running valac: http://pastebin.ubuntu.com/561570/
[19:56] <dobey> grr, dbus-daemon
[19:56] <verterok> dobey: #712086
[19:57] <dobey> alecu: ok, the nightlies have the same error. can you help me debug that in a few minutes (as soon as i fix this devtools issue)
[19:57] <verterok> bug #712086 maybe?
[19:57] <ubot4> Launchpad bug 712086 in ubuntuone-dev-tools "dbus-daemon fails to start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/712086
[19:57] <alecu> dobey, sure
[19:59] <dobey> great
[20:25] <ralsina> nessita: I have to take a break to pick my kid. I am still running the tests on the 3rd branch, I looked at the code, and if all goes well I will approve it in a while when I come back.
[20:25] <nessita> ralsina: awesome, thanks
[20:26] <ralsina> hey, it finished! another +1 for you :-)
[20:37] <nessita> yey!
[20:40] <dobey> verterok: https://code.launchpad.net/~dobey/ubuntuone-dev-tools/fix-dbus-lucid/+merge/48380
[20:41] <verterok> dobey: k, thanks!
[20:49] <dobey> anyone else want to give a second review on that? https://code.launchpad.net/~dobey/ubuntuone-dev-tools/fix-dbus-lucid/+merge/48380
[20:49] <dobey> nessita: maybe you could real quick? :)
[20:50] <nessita> dobey: already testing it, at least to confirm it keeps working on maverick
[20:50] <nessita> I'm running client tests pointing devtools to this branch
[21:13] <ralsina> eod for me. have nice evening!
[21:18] <kieppie> howdy
[21:18] <kieppie> anyone online?
[21:26] <kieppie> hi guys. is anyone able to give me some insight into UbuntuOne, such as why there's no notification icon? (installing from PPA now)
[21:32] <dobey> there is no notification icon because we got rid of the tray applet a couple releases ago.
[21:32] <dobey> which PPA are you installing from?
[21:43] <kieppie> hey dobey: I'm installing from: ppa:rye/ubuntuone-extras . I'd like the U1 indicator applet for the same reason I'd use the DropBox one: so see what the sync status is, space, & to *explicitly* force a sync
[21:44] <kieppie> dobey: I use U1 on several machines (of course), sometimes next to each other, and I'd like to ensure the sync is up-to-date before disconnecting, especially w stuff like my keepass DB I'm migrating there
[21:44] <dobey> ok
[21:45] <dobey> i think that creates an application indicator, so you would need to have the application indicators applet on your panel for it to show up when you run it
[21:46] <kieppie> dobey: yip. which was present in earlier versions, but not any more, which doesn't make much sense
[21:47] <dobey> i'm not sure what you mean by that
[21:47] <dobey> earlier versions of what?
[21:49] <kieppie> dobey: I was an early adopter of U1 when it was 1st released, but didn't use it for a while. I've started using it again recently & notices the notification-area status-icon  missing, which seems by design, but I do not understand why such a decision has make, or why there is no setting available to enable the icon/staus to be shown
[21:50] <dobey> because it is an area of huge controversy, and we really shouldn't need to have one anyway. it was always planned that the tray icon would go away, and we would improve integration with the rest of the system
[21:51] <dobey> there will be some similar features in 11.04 again though, as there will be integration with the unity launcher, messaging menu, etc... to help provide better information
[21:53] <kieppie> I understand that changing accepted functions cause controversy, but what I do not understand is removing functionality without providing the aforementioned integration first. I can get used to changes (goodness knows I do with each release), but what I do not understand is what the new way is of doing the old thing
[21:53] <kieppie> unity laucnher integration I can dig. makes sense.
[21:53] <alecu> thisfred, approved your branch.
[21:53] <kieppie> it's the inter-release leap without that tool that troubling
[21:54] <thisfred> alecu thx, awesome!
[21:55] <alecu> thisfred, remember that "notification" that was returned by show_notification and was required as parameter by update_notification... are you going to move that to Notifcation.self in a further branch?
[21:56] <thisfred> alecu: I could do that, but then you can't use the same object to send/update multiple notifications easily...
[21:56] <thisfred> Don't know if that's a use case
[21:57] <alecu> thisfred, oh, I was planning on creating a new Notification object for each notification...
[21:57] <thisfred> of course, as it is, update does not really need to be on the class
[21:57] <alecu> I thought the api would look nicer
[21:57] <alecu> but anyway, its a minor detail... so don't worry.
[21:58] <thisfred> alecu: let's see when we use it a lot if it's easier one way or the other, it's easy enough to fix
[21:58] <alecu> perfect
[21:58] <dobey> alright, i'm out
[21:58] <dobey> later all
[21:58] <thisfred> bye dobey
[22:03] <nessita> bye everybody!
[23:34] <vds> karni, it is going ok


[06:21] <fwereade> morning davecheney
[06:22] <davecheney> fwereade: hello
[06:22] <davecheney> thank you for your reviews
[06:22]  * davecheney is still pondering the theological implication of juju set KEY=""
[06:22] <fwereade> davecheney, a pleasure, sorry they've been a little vague
[06:22] <fwereade> davecheney, yeah, that is definitely a pain point...
[06:23] <fwereade> davecheney, but, have you been reading the "incompatible charm upgrades" thread?
[06:23] <davecheney> fwereade: not closely
[06:24] <davecheney> reading the python juju set
[06:24] <davecheney> it's a lot more complicated than KEY=VALUE
[06:24] <fwereade> davecheney, I *think* what that should always mean, based on clint's point re fallback-to-defaults, is "clear out the setting, use the service default instead"
[06:24] <davecheney> it's actually "key: value" _when_ the charm is a yaml charm
[06:24] <davecheney> and other options when the charm is something else
[06:24] <fwereade> davecheney, yeah, this is something I had not fully appreciated the intricacies of myself
[06:25] <fwereade> davecheney, sorry, what do you mean by "yaml charm"?
[06:25] <davecheney>     charm_format = (yield charm.get_metadata()).format
[06:25] <davecheney>     formatter = get_charm_formatter(charm_format)
[06:25] <davecheney>         options = formatter.parse_keyvalue_pairs(service_options)
[06:25] <fwereade> davecheney, oh, hell
[06:25] <davecheney> (insert dramatic chipmonk)
[06:25] <fwereade> haha
[06:26] <davecheney> however get_charm_formatter does allow for something called "PythonFormat"
[06:26] <fwereade> davecheney, I'm reluctant to claim possession of truth here, but please talk to niemeyer about this... I'm *sure* I saw him saying something to jimbaker yesterday that strongly implied that was not the correct approach on the client side
[06:26] <davecheney> T
[06:27] <davecheney> i'd suggest it's pretty crack for the user of a charm to have to specify the config data in the native charm format
[06:27] <davecheney> given we don't make it obvious what that format is
[06:29] <fwereade> davecheney, I *think* (again) that there was a recent thread which laid this out... or possibly just made reference to an earlier thread which did
[06:29] <davecheney> ill search the archive
[06:58] <rog> davecheney, fwereade: morning!
[07:00] <fwereade> rog, heyhey
[07:01] <fwereade> rog, PATH change is merged
[07:01] <fwereade> rog, is it just the security groups now?
[07:01] <rog> fwereade: i've just seen that. will pull and see what happens in my branch...
[07:01] <fwereade> rog, (that we currently know of ;))
[07:01] <rog> fwereade: no, they're in
[07:02] <rog> fwereade: it should just work now
[07:02] <fwereade> rog, ah, cool, I didn't try because https://code.launchpad.net/juju-core/+activereviews still shows it aproved but unmerged
[07:02] <rog> fwereade: although of course you won't be able to *tell* that it's working - the uniter-upgrade branch will do that
[07:02] <davecheney> hello lads
[07:02] <fwereade> rog, oh? what does that do
[07:03] <fwereade> rog, well, obviously it upgrades the uniter
[07:03] <rog> fwereade: good point - i'd moved it in to my "submitted" list, but it seems i never did
[07:03] <fwereade> rog, but... can't we tell anyway?
[07:03] <rog> fwereade: i suppose so, from the unit status
[07:03] <fwereade> rog, via status
[07:03] <fwereade> rog, yeah
[07:04] <rog> fwereade: will submit the security groups stuff pronto
[07:04] <fwereade> rog, cool
[07:05] <rog> fwereade: ah, no, it *is* submitted, but i had to remake the merge proposal because the prereq changed
[07:05] <rog> fwereade: i'll add a comment to the original
[07:09] <fwereade> rog, ah cool
[08:13] <fwereade> rog, dammit, it's the addresses again
[08:13] <rog> fwereade: ah, sorry, that fix is in the unit-upgrader branch
[08:14] <fwereade> rog, ahh that's why :)
[08:14] <rog> fwereade: i should push it out as a trivial
[08:14] <fwereade> rog, do it do it :)
[08:14] <rog> fwereade: although it's not *entirely* trivial - there's the arguable case over "latest" vs some fixed version number
[08:15] <rog> fwereade: which others might wish to weigh in on
[08:15] <rog> davecheney: ping
[08:15] <rog> fwereade: i have a feeling it was me that pushed for the fixed version in the first place. oh i am fickle.
[08:16] <rog> fwereade: anyway, if you want it to work, just change "1.0" to "latest"
[08:22] <fwereade> rog, I *kinda* think it's probably best to go with any specific version that has the metadata we need
[08:22] <fwereade> rog, I do in general trust amazon not to screw it up
[08:22] <fwereade> rog, but yu never know
[08:22] <rog> fwereade: ok, i'll do that then.
[08:22] <fwereade> rog, it's just one extra thing that *might* go wrong
[08:22] <rog> fwereade: perhaps a relatively recent version, so that we have access to other stuff as well if we want
[08:23] <fwereade> rog, yeah, the current target of latest would be fine with me
[08:23] <rog> fwereade: BTW what state are the relation hooks in?
[08:23] <fwereade> rog, basically, they're not
[08:24] <fwereade> rog, because so many of the details depend on lifecycles not just existence
[08:24] <rog> fwereade: ahhh
[08:24] <fwereade> rog, I have a branch that I'm 90 sure will work with only minor tweaks once the substrate is available
[08:24] <fwereade> rog, but it is 3 weeks old now
[08:24] <rog> substrate is such a good word
[08:24] <fwereade> rog, and I'm a bit worried about when I'll be able to make actual *progress* on it
[08:25] <fwereade> rog, fingers crossed for lisbon
[08:25] <rog> fwereade: yeah ikwym
[08:25] <rog> fwereade: what i tend to do is keep things roughly up to date, so i don't have an almighty job when i come to merge it later
[08:26] <rog> fwereade: but that can have its own problems of course
[08:26] <fwereade> rog, I gave up on that a long time ago, I'm just planning to recreate everything using it for inspiration
[08:26] <rog> fwereade: lol
[08:38] <fwereade> rog, ffs, git is not installed by default :)
[08:38] <rog> fwereade: nbd. we have other dependencies too.
[08:39] <fwereade> rog, indeed
[08:39] <fwereade> rog, just another irritating step ;)
[08:39] <rog> fwereade: and some time later, we will should provide images that don't take 5 minutes to get all their stuff before becoming usable
[08:39] <rog> s/will //
[08:40] <fwereade> rog, yeah, definitely
[09:05] <fwereade> rog, can I get a trivial LGTM on https://codereview.appspot.com/6495129 before I pop out for coffee please?
[09:06] <rog> fwereade: assuming it works, LGTM
[09:06] <fwereade> rog, it appeared to :)
[09:06] <rog> fwereade: cool
[09:07] <rog> fwereade: did you see the charm actually running some commands then?
[10:36] <fwereade-on-juju> so, the *only* hack this is using (compared to trunk) is the latest metadata
[10:37] <fwereade-on-juju> http://ec2-174-129-106-129.compute-1.amazonaws.com:3000/
[10:37] <fwereade-on-juju> rog, *surely* we can make that a trivial and get trunk actually *working* ..?
[10:38] <rog> fwereade-on-juju: so... you're actually connecting from a charm?
[10:39] <rog> fwereade-on-juju: YAYAYYAYAYAYAAYYA!!!!
[10:39] <rog> fwereade-on-juju: ok, i'll frikkin' do it
[10:40] <fwereade-on-juju> rog, oh yes I am :)
[10:40] <fwereade-on-juju> oops, bugger, need cash for cleaner, brb
[10:41] <rog> fwereade-on-juju: while you've got an instance up, could you do a quick curl http://<IP_ADDRESS>/ and paste me the results please?
[10:41] <rog> fwereade-on-juju: that is - do that on an ssh session in your instance
[10:42] <rog> fwereade-on-juju: actually, scratch that
[10:46] <rog> fwereade-on-juju: https://codereview.appspot.com/6498128
[10:53] <rog> fwereade-on-juju: hmm, pity your server doesn't seem to be actually connecting to IRC for me
[10:54] <rog> fwereade: oh yes, that CL also renames a directory, which the codereview page doesn't show.
[10:56] <fwereade-on-juju> rog, sorry, back; looking
[10:57] <fwereade-on-juju> rog, LGTM
[10:57] <fwereade-on-juju> rog, but... what's not working for you?
[10:58] <fwereade-on-juju> rog, you *should* just be able to do new connection to chat.freenode.net and pick a name
[10:58] <rog> fwereade-on-juju: i tried, but it hung. i did use "irc.freenode.net" though
[10:58] <fwereade> rog, tbh subway *does* apear to be a touch flaky, it misses messages occasionally
[10:59] <fwereade> rog, but I *think* we can blame the service rather than juju for that ;)
[10:59] <rog> fwereade: i tried it in two windows, different server names, etc
[10:59] <rog> fwereade: but yeah, i see the page!
[10:59] <rog> fwereade: i just wanted to join you as rog-on-juju :-)
[10:59] <fwereade-on-juju> rog, yeah, indeed
[10:59] <fwereade-on-juju> it's lonely up here ;p
[10:59] <rog> fwereade-on-juju: ok, so trunk should now be working!
[11:00] <fwereade-on-juju> rog, ok, I'm shutting this down and trying it out :)
[11:00] <rog> fwereade: "you were disconnected from the server" :-)
[11:01] <fwereade> rog, that works, anyway ;p
[11:01] <rog> fwereade: yeah, i could navigate other pages too
[11:01] <rog> fwereade: just not get through to irc
[11:37] <fwereade> rog, sorry, but I'm getting 404s from 2012-06-01...
[11:37] <rog> fuck
[11:37] <rog> fwereade: that's the version they mentioned on the web page
[11:37] <rog> fwereade: i just assumed...
[11:37] <rog> fwereade: bloody amz
[11:38] <rog> fwereade: have you got an instance up now?
[11:38] <fwereade> rog, bad luck
[11:38] <fwereade> rog, yeah, I was just about to poke around and try to figure out what it should be
[11:38] <rog> fwereade: ssh to it and do curl http://<IP_ADDRESS>/
[11:38] <rog> fwereade: that should give you the list of available versions i think
[11:39] <fwereade> rog, huh, latest is 2012-01-12
[11:39] <rog> fwereade: ok
[11:39] <rog> fwereade: i *so nearly* went for a 2011 version!
[11:39] <fwereade> rog, haha
[11:39] <fwereade> rog, wonder wtf the deal is with versions not existing :/
[11:40] <rog> fwereade: only amazon knows
[11:40] <rog> fwereade: ok, will change it
[11:40] <fwereade> rog, 2012-01-12 verified live btw ;)
[11:41] <rog> fwereade: thanks. i didn't want to wait for another live test to complete :-)
[11:42] <rog> fwereade: could you verify 2011-01-01
[11:42] <rog> ?
[11:42] <rog> fwereade: i think i'll go for that, as who knows how consistent amz is across regions
[11:42] <fwereade> rog, sorry, just killed the env -- but it was advertised
[11:43] <rog> fwereade: that gives us everything we want, i think
[11:43] <fwereade> rog, sgtm
[11:51] <rog> fwereade:  https://codereview.appspot.com/6494136
[11:52] <fwereade> rog, LGTM
[11:53] <rog> fwereade: submitted
[11:53] <fwereade> rog, trying it out
[12:14] <fwereade-on-juju> oh yes indeed
[12:16] <rog> fwereade-on-juju: fanbloodytastic!
[12:16] <fwereade-on-juju> rog, ain't it :D
[12:16] <fwereade-on-juju> rog, not one lick of manual intervention
[12:16] <rog> fwereade-on-juju: am very glad you got to be the first!
[12:17] <fwereade-on-juju> rog, bah, there's more than enough credit to go around :)
[12:17] <fwereade-on-juju> rog, http://ec2-23-20-195-110.compute-1.amazonaws.com:3000/ -- maybe subway will be happier this time
[12:17] <rog> fwereade-on-juju: you don't have to log in or register first?
[12:17] <fwereade> rog, I just picked a name and a server and that ws it
[12:20] <rog> fwereade: nah
[12:21] <rog> fwereade: tried from my phone too. page serves fine though
[12:21] <fwereade> rog, weird
[12:21] <fwereade> rog, ah well
[13:01] <mramm> For those wondering about sprint plans, Marianna says: "I'm booking the same venue as for the July's sprint"
[13:01] <fwereade> mramm, cool
[13:02] <mramm> something went wrong in the notification system, so she got started late
[13:02] <mramm> but is finalizing the details this morning
[13:02] <mramm> so we should be all set to go
[13:02] <fwereade> mramm, not sure if you saw that I just deployed a charm on trunk :)
[13:02] <mramm> rock and roll
[13:02] <mramm> great work everybody!
[13:27] <niemeyer> Hellos!
[13:46] <fwereade> niemeyer, heyhey
[13:47] <fwereade> niemeyer, with a pair of trivials merged by me and rog this morning, current trunk can deploy subway :)
[14:02] <niemeyer> fwereade: Wooooooo
[14:02] <fwereade> :D
[14:02] <niemeyer> fwereade: Sooooo awesome.. we should have a beer on Sunday :-)
[14:02] <fwereade> niemeyer, SGTM :) when are you getting in?
[14:04] <Guest96454> niemeyer: yo!
[14:05] <niemeyer> fwereade: Let me check
[14:05] <niemeyer> Guest96454: Morning! :-)
[14:05] <rogpeppe> how did that happen?!
[14:06] <rogpeppe> guess i was on the last available name
[14:38] <niemeyer> fwereade: Just sent another reply on the upgrade thread
[14:38] <fwereade> niemeyer, cool, looking
[14:58] <fwereade> niemeyer, replied
[14:58] <niemeyer> fwereade: Cheers
[15:16]  * fwereade acknowledges a good point by niemeyer, and goes off to think for a bit
[16:36] <niemeyer> Lunch time!
[17:10]  * rogpeppe wishes there was an easy way of splitting a branch in two
[17:21] <rogpeppe> gah!
[17:28] <niemeyer> rogpeppe: git is *slightly* better at that, via rebase
[17:29] <niemeyer> rogpeppe: Unfortunately we don't yet have something as complete as git's rebase yet
[17:29] <rogpeppe> niemeyer: i'm just gonna copy the files into a branch off trunk and lose the revision history
[17:29] <rogpeppe> niemeyer: sucks a bit, but i don't mind much
[17:36] <niemeyer> rogpeppe: Well, that's unavoidable unfortunately
[17:36] <niemeyer> rogpeppe: Splitting content in half always trashes or modifies history somehow
[17:37] <rogpeppe> niemeyer: unless you use darcs apparently
[17:37] <rogpeppe> niemeyer: well "alters" i'm sure
[17:37] <niemeyer> rogpeppe: I believe this is a theoretical constraint
[17:45] <rogpeppe> we have a place to stay!
[17:46] <niemeyer> rogpeppe: Yeah, that was tight :-)
[17:46] <rogpeppe> niemeyer: not quite as convenient as before
[17:52] <rogpeppe> niemeyer: here's the upgrader logic we talked about: https://codereview.appspot.com/6492123/
[17:54] <rogpeppe> niemeyer: unfortunately i can't propose the uniter upgrade branch until we decide about UnitWatcher
[17:55] <niemeyer> rogpeppe: I don't get the comment about WaitForEnviron
[17:55] <rogpeppe> niemeyer: WaitForEnviron absorbs the first event
[17:55] <rogpeppe> niemeyer: but we need to see it
[17:55] <niemeyer> rogpeppe: Yeah, it absorbs to return the environ
[17:55] <niemeyer> rogpeppe: We don't "miss it"
[17:55] <niemeyer> rogpeppe: It's handling the event for us
[17:55] <rogpeppe> niemeyer: yes, but we need that event in the upgrader loop
[17:56] <rogpeppe> niemeyer: unless...
[17:56] <rogpeppe> niemeyer: we could just start an independent environ watcher
[17:56] <niemeyer> rogpeppe: It just sounds a bit confusing.. the comment says that we can't use it because it does precisely what it should do
[17:56] <niemeyer> rogpeppe: The goal is precisely to "initialize the environ when we're first able"
[17:57] <rogpeppe> niemeyer: ok. i'll try to think of another way of phrasing the comment
[17:57] <niemeyer> rogpeppe: So far I'm arguing mainly about the comment.. I don't understand what's the constraint yet
[17:58] <niemeyer> rogpeppe: It says something like "we initialize the environ when we're first able, so we can't use WaitForEnviron" but that's *exactly* what WaitForEnviron does.. not sure if you see what I mena?
[17:59] <niemeyer> rogpeppe: It feels like we could just use it, to be honest
[17:59] <niemeyer> rogpeppe: Why can't we?
[18:00] <rogpeppe> niemeyer: if we use it and the environ config does not change, we won't see any more events on the watcher, so we'll never do an upgrade.
[18:02] <rogpeppe> niemeyer: here's a possible updated version of the comment:
[18:02] <rogpeppe> 	// We can't use worker.WaitForEnviron because then we don't
[18:02] <rogpeppe> 	// see the first event from the watcher, which we need
[18:02] <rogpeppe> 	// to see because it has version information in that we
[18:02] <rogpeppe> 	// must see.
[18:03] <rogpeppe> niemeyer: slightly better:
[18:03] <rogpeppe> 	// We can't use worker.WaitForEnviron because then we don't
[18:03] <rogpeppe> 	// see the first event from the watcher, which contains version information
[18:03] <rogpeppe> 	// that we must see.
[18:05] <rogpeppe> niemeyer: i need to go, i'm afraid
[18:05] <rogpeppe> niemeyer: looking forward to an awesome sprint!
[18:05] <rogpeppe> niemeyer: hope your travel goes well
[18:05] <niemeyer> rogpeppe: I see, it's still not entirely right, though
[18:05] <rogpeppe> niemeyer: oh?
[18:05] <niemeyer> rogpeppe: WaitForEnviron does more than simply waiting for first event
[18:06] <niemeyer> rogpeppe: We need it to handle the bootstrap behavior
[18:06] <rogpeppe> niemeyer: i *think* i do that
[18:06] <niemeyer> rogpeppe: Doesn't look like so..
[18:06] <niemeyer> rogpeppe: The logic within the switch says
[18:06] <niemeyer> 139 »       »       »       »       »       // continue on, because the version number is stil
[18:06] <niemeyer>      l significant.
[18:06] <niemeyer> rogpeppe: We can't move on with an invalid configuration
[18:06] <niemeyer> rogpeppe: We talk to the environment mid-way through
[18:07] <rogpeppe> niemeyer: what about line 132?
[18:07] <niemeyer> rogpeppe: Ah, yeah, you're right
[18:08] <niemeyer> rogpeppe: Anyway, we can talk next week.. have fun there
[18:08] <niemeyer> rogpeppe: and safe travels
[18:08] <rogpeppe> niemeyer: and you too.
[18:08] <niemeyer> rogpeppe: Thanks
[18:09] <rogpeppe> niemeyer: you too!


[09:20] <davmor2> cjwatson: should it be safe to test lvm got lots to test and not much time?
[09:26] <cjwatson> davmor2: wouldn't mind a coherent idea of its current state
[09:27] <cjwatson> it seemed to be working for me
[09:27] <davmor2> cjwatson: wilko I'll run a quick test now
[09:28] <davmor2> cjwatson: did you test on 32 or 64 bit?
[09:28] <cjwatson> i386
[09:29] <davmor2> right I'll try a 64bit then :)
[09:29] <cjwatson> shouldn't think that alone will matter
[09:29] <cjwatson> I know of the general problem that the LVM tools don't operate atomically, so quick successive operations may fail for one reason or another
[09:30] <cjwatson> therefore, the difference between kvm and real hardware is more likely to be significant than the difference between i386 and amd64, IMO
[09:31] <davmor2> cjwatson: I was thinking more along the lines of if i368 works for you and amd64 works for me then both are likely to work and be safe to test :)
[09:34] <cjwatson> davmor2: sure, just saying that I wouldn't expect the architecture difference to be significant here. If i386 works for me but amd64 fails for you then the difference is much more likely to be due to some other factor, not the difference in architecture
[09:38] <davmor2> cjwatson: fscking partitioner.  Error informing the kernel about modifications to partition /dev/sda2 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/sda2 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.  Ignore or Cancel
[09:39] <cjwatson> please don't reboot yet
[09:39] <cjwatson> what was the previous state of this disk?
[09:39] <davmor2> I'm not
[09:39] <cjwatson> (your goal here is to show me how to reproduce this)
[09:39] <davmor2> it had a standard whole drive install on
[09:40] <cjwatson> ok, and what did you do in this installation pass?
[09:40] <davmor2> encrypted LVM
[09:40] <cjwatson> so all guided partitioning?
[09:40] <davmor2> yes
[09:41] <davmor2> cjwatson: last page was the one about setting up lvm yes or no
[09:41] <davmor2> click on yes and then got the warning
[09:42] <cjwatson> click?
[09:42] <davmor2> well hit tab
[09:42] <cjwatson> I'm guessing you don't actually mean mouse-click in ubiquity since it doesn't have encrypted LVM support :)
[09:43] <davmor2> cjwatson: It's twirly
[09:43] <cjwatson> the failure's on the BLKPG_ADD_PARTITION ioctl, but I'm guessing that it's actually because a previous BLKPG_DEL_PARTITION failed
[09:43] <cjwatson> can I get /var/log/partman quickly?
[09:44] <davmor2> what was the ssh command to save some time
[09:44] <cjwatson> hmm, would be nice to know what the error code from the ioctl was but libparted probably doesn't show that
[09:44] <cjwatson> anna-install openssh-client-udeb
[09:44] <cjwatson> scp /var/log/partman user@host:target-file-name
[09:45] <cjwatson> exit code's probably EBUSY which would indicate another active overlapping partition
[09:45] <cjwatson> I wonder if there's any way I can get a list of active partitions
[09:45] <cjwatson> um, 'ls /sys/block/sda' maybe?
[09:45] <cjwatson> only the sda* ones
[09:46] <cjwatson> was this server or alternate?
[09:46] <cjwatson> (it probably doesn't matter ...)
[09:47] <davmor2> cjwatson: should be at http://www.davmor2.co.uk/partman1
[09:49] <davmor2> sorry it's not it's http://www.davmor2.co.uk/partman need to clean up my server again
[09:49] <davmor2> infact give me 2 ticks I'll wipe them both and reupload to be sure
[09:50] <cjwatson> arr. unique ids :)
[09:50] <davmor2> right it's definately the last link now
[09:52] <davmor2> It's cause I'm always dropping them on my server and forget to clean up after :)
[09:52] <cjwatson> oh, /dev/sda2 is the extended partition, ok
[09:53] <cjwatson> (I was wondering why there were two primaries)
[09:53] <cjwatson> is this definitely with the most current images?
[09:55] <cjwatson> davmor2: if you can reproduce this on demand, one piece of information that would be amazingly useful, if a bit fiddly to set up, would be the output from a run of 'udevadm monitor' from the point just before you press enter on the final LVM setup question to a point after the failure
[09:56] <cjwatson> davmor2: the reason I'm saying this is that it seems to me that the most likely cause for this bug is that we delete the partition and then sometimes udev is opening the disk to have a quick look at it before we add partitions
[09:56] <cjwatson> let me see if I can reproduce it here ...
[09:57] <davmor2> give me 5 mins and I'll re-run I'm just doing oem install on live on my other machine
[09:58] <cjwatson> OEM GTK/KDE frontends are known broken in user-setup
[09:58] <cjwatson> so you could skip that
[09:59] <davmor2> D'oh
[09:59] <davmor2> I thought that got fixed in a4
[10:00] <davmor2> or was I just dreaming
[10:04] <cjwatson> this problem was introduced after alpha 4
[10:05] <davmor2> yes I remember now doesn't it say username invalid before you put one in
[10:05] <cjwatson> yes
[10:05] <cjwatson> Evan fixed it in bzr but didn't upload ;-)
[10:06] <cjwatson> didn't notice until it was a bit too late
[10:06] <davmor2> I saw the bug on it
[10:06] <davmor2> well you could always respin before I start testing :)
[10:08] <cjwatson> I already checked with Steve, we decided to put this one in the errata
[10:13] <tjaalton> looks like that lvm bug is the same as mine
[10:14] <cjwatson> which lvm bug?
[10:14] <tjaalton> bug 334278
[10:14] <cjwatson> I'd really prefer to consider each one separately, anyway
[10:15] <cjwatson> that *is* your bug. which one are you saying is the same?
[10:15] <tjaalton> ah :)
[10:15] <tjaalton> the one davmor2 reported
[10:15] <tjaalton> here
[10:15] <cjwatson> so I agree that it looks similar but there are some differences: davmor2 started out with /dev/sda1 and /dev/sda5 whereas you started out with /dev/sda1 and /dev/sda2
[10:16] <cjwatson> it could be that the same kind of change needs to be made in different places, or it could all be due to the one core bug
[10:16] <tjaalton> it only depends on what you had on the disk
[10:16] <cjwatson> until I've investigated further I simply won't know
[10:16] <tjaalton> I get the same(ish) error when I try to install lvm on top of an old regular installation, or vice versa
[10:17] <cjwatson> IMO it is best to understand and diagnose the bug, and *then* deal with duplicates :)
[10:17] <tjaalton> sure
[10:17] <cjwatson> but yes, there is definitely a pattern here
[10:17] <cjwatson> it's my top thing to look at now
[10:17] <tjaalton> probably not something for this alpha?
[10:17] <cjwatson> not sure yet
[10:17] <tjaalton> ok
[10:18] <cjwatson> I'm inclined to say not provided that installations are at least sometimes possible ...
[10:18] <cjwatson> though it's not going to make for a pretty release note
[10:19] <tjaalton> heh :)
[10:19] <cjwatson> hopefully I can reproduce it here; if not it's a race condition and I'm going to have to bang my head against a few walls
[10:21] <davmor2> Meh cjwatson I just did the udevadm monitor hit yes and it's gone straight through to encryption password
[10:22] <tjaalton> I guess the pattern is; regular -> lvm FAIL, lvm -> regular FAIL, regular -> regular OK
[10:22] <cjwatson> davmor2: do you have the output of udevadm monitor, though?
[10:22] <cjwatson> that confirms that it is a race condition
[10:22] <tjaalton> but the last case might be successfull only because the layout is exactly the same
[10:22] <cjwatson> the monitor output may still be useful
[10:22] <davmor2> cjwatson: yes goes off the screen
[10:22] <cjwatson> argh
[10:22] <cjwatson> davmor2: redirect it to a file :-)
[10:23] <cjwatson> udevadm monitor >monitor-output 2>&1
[10:23] <davmor2> cjwatson: I was about to ask :) I'll re-run it
[10:23] <cjwatson> sorry, suppose I should have said
[10:23] <tjaalton> cjwatson: so not preseeding partman-auto/method, and running udevmonitor right before choosing the option?
[10:24] <cjwatson> tjaalton: regular->LVM works for me; this is a race condition
[10:24] <cjwatson> tjaalton: udevadm monitor, but yes
[10:24] <cjwatson> hmm, interesting, the default answer for the guided size question fails for me
[10:25] <tjaalton> cjwatson: but does the partition layout change for you when doing regular -> lvm?
[10:26] <davmor2> cjwatson: I think I just got the same thing doing whole drive over the whole drive oem on the live system
[10:26] <cjwatson> tjaalton: I'm reproducing davmor2's setup here, so I would imagine so
[10:26] <tjaalton> cjwatson: ok
[10:26] <cjwatson> tjaalton: I can't check because I just ran into bug 327348 AGAIN
[10:27] <tjaalton> ugh
[10:30] <davmor2> cjwatson: how do I get access to the output from udevadm now?  I'm used to just piping it to a file :)
[10:34] <davmor2> ah got it:)
[10:36] <davmor2> cjwatson: http://www.davmor2.co.uk/monitor-output
[10:47] <davmor2> cjwatson: I'm carrying on with the install now and I'll see if I can reproduce on the next install
[10:50] <cjwatson> hmm. blast. longint2human's rounding is not quite what I wanted
[11:02] <StevenK> cjwatson: I saw an issue with longint2human's display today, too
[11:03] <StevenK> cjwatson: Lemme get the photo somewhere more accessable than an SD card and I'll throw you a URL
[11:08] <StevenK> cjwatson: http://wedontsleep.org/~steven/IMG_2471.JPG
[11:09] <cjwatson> oh, that's different
[11:10] <CIA-3> partman-auto-lvm: cjwatson * r216 ubuntu/ (debian/changelog perform_recipe_by_lvm):
[11:10] <CIA-3> partman-auto-lvm: Cope with rounding errors in guided_size; if the value we convert back
[11:10] <CIA-3> partman-auto-lvm: from human-readable notation is in the round-off range at either end,
[11:10] <CIA-3> partman-auto-lvm: just use the appropriate extreme (LP: #334648).
[11:10] <StevenK> Sure, but it's still a fun problem. :-)
[11:10] <cjwatson> evand: ^- StevenK's bug seems like more your field, I'm not quite sure how ubiquity does that stuff these days
[11:10] <StevenK> cjwatson: Oh, right. Unrelated to longint2human then, sorry. I guessed.
[11:10] <evand> Yikes.  I'll look into that.
[11:10] <StevenK> evand: Prod me if you want a proper bug filed.
[11:11] <cjwatson> StevenK: well, could be related, who knows :)
[11:11] <evand> StevenK: please do, just so I have something to track it with.
[11:11] <cjwatson> though it seems more like some kind of order-of-magnitude bug; human2longint and longint2human have a small test suite now so I'm reasonably sure they don't have order-of-magnitude bugs
[11:12] <StevenK> evand: Oh, there's a neat bug with the timezone selector, too. The cities don't line up with the picture, at least on my Q1 and Jax10.
[11:12] <evand> Indeed, I suspect this is as the result of some change I've made to segmented_bar recently.
[11:12] <cjwatson> cities> yes, AOL, I think somebody filed that ...
[11:13] <StevenK> I didn't think Sydney was out to sea, but I'm not sure ...
[11:13] <cjwatson> reproducible in kvm
[11:14] <evand> indeed, very well aware of that one
[11:14] <evand> bug 334284
[11:15]  * StevenK subscribes himself to it
[11:17] <cjwatson> davmor2: thanks, summoning Keybuk ...
[11:17] <StevenK> evand: Bug filed.
[11:18] <davmor2> cjwatson: Will this be a show stopper or just a testing stopper?
[11:18] <cjwatson> I don't know
[11:21] <evand> thanks
[11:24] <cjwatson> evand: remind me, did you have a patch for bug 287635 (which I think is basically a dup of bug 34974, btw)? if so now would be a good time for me to commit it upstream and then we won't have to worry about translations
[11:26] <evand> I might, let me dig through my branches quickly
[11:28] <evand> cjwatson:  Apparently not.  Want me to write something up?
[11:30] <cjwatson> evand: if you have time, sure
[11:31] <evand> ok, will do.  I'll also dup to 34974 and attach it there.
[11:40] <davmor2> cjwatson: I can confirm it works the other way too so with the lvm install in place you can't then do a whole drive install over the top of it :(
[11:45] <CIA-3> partman-partitioning: cjwatson * r697 ubuntu/ (debian/changelog lib/resize.sh):
[11:45] <CIA-3> partman-partitioning: Cope with rounding errors while asking for the new partition size; if
[11:45] <CIA-3> partman-partitioning: the value we convert back from human-readable notation is in the
[11:45] <CIA-3> partman-partitioning: round-off range at either end, just use the appropriate extreme.
[11:46] <cjwatson> davmor2: ok, will need to wait for Keybuk to notice my /msg I think
[11:46] <cjwatson> I can't reproduce it myself (although I believe it) and this is getting outside my expertise ...
[11:51] <cjwatson> it sort of feels like a udev rule missing ACTION=="add|change" to me
[11:52] <davmor2> cjwatson: I'm well out of my depth :)
[12:20] <evand> cjwatson: patch attached to 34974
[12:33]  * davmor2 lunch for a bit can't do much else
[12:34] <cjwatson> evand: multi-line Description: fields don't work that way
[12:34] <cjwatson> evand: the first line is semantically separate from the short description; generally the first line should be thought of as a heading, not a sentence that might wrap
[12:34] <cjwatson> evand: so the first line should typically be limited to 65 characters, and not usually end with a full stop
[12:34] <evand> ah, indeed.  That completely slipped my mind
[12:43] <evand> cjwatson: http://pastebin.ubuntu.com/123280/ - better?
[12:48] <cjwatson> definitely better, might make some minor rewordings but I'll need to look at the surrounding text for that; please do attach that to the bug
[12:49] <evand> sure thing
[12:59] <CIA-3> ubiquity: evand * r3066 ubiquity/ (debian/changelog ubiquity/segmented_bar.py):
[12:59] <CIA-3> ubiquity: Always return an integer from get_size as the calcuation could produce a
[12:59] <CIA-3> ubiquity: float, and functions using the return value expect a number of bytes
[12:59] <CIA-3> ubiquity: (LP: #334677).
[13:00] <evand> hooray for poorly worded changelog descriptions
[13:03] <evand> slightly confused, I though implicit conversion occurred there.
[15:56] <cjwatson> Installer/FAQ> new page, feel free to add stuff
[16:10] <evand> oo, very cool
[16:17] <kirkland> cjwatson: hmm, booting degraded raid seems to have regressed
[16:17] <kirkland> cjwatson: this is the first time i've tested it in jaunty
[16:18] <kirkland> cjwatson: http://people.ubuntu.com/~kirkland/Screenshot.png
[16:44] <cjwatson> kirkland: ... OK - are you going to fix it? :-)
[16:44] <kirkland> cjwatson: i'm looking at it now
[16:44] <cjwatson> it probably shouldn't be trying to resolve user/group names in the initramfs, to start with
[16:45] <kirkland> cjwatson: keybuk suggested that it might be a kernel issue with the md driver
[16:45] <kirkland> cjwatson: i was curious if anything changed with user/group in initramfs between intrepid/jaunty
[16:46] <kirkland> cjwatson: okay, confirmed, kernel bug
[16:47] <kirkland> cjwatson: this is fixed by using 2.6.29rc6 vanilla kernel
[16:48] <kirkland> cjwatson: i'll binary search to find the kernel that fixes it
[16:50] <kirkland> cjwatson: regarding your kvm keypress issue, is there a chance that the keys are registering in the vm, but just not being reflect to screen?
[16:51] <kirkland> cjwatson: there's a couple of screen garbling issues that upstream is trying to fix;  i'm going to backport those as soon as they have them figured out
[16:51] <cjwatson> kirkland: no chance at all
[16:51] <cjwatson> kirkland: did you see my comment about it being clearly like a modifier key being held down?
[16:51] <kirkland> cjwatson: yes i did
[16:51] <cjwatson> tty changes do register and the screen updates as normal
[16:52] <cjwatson> and if I press Enter at the "would you like to start a busybox shell" prompt, that works
[16:52] <kirkland> cjwatson: i've been working in vm's all morning and haven't reproduced this yet
[16:52] <cjwatson> none of the symptoms suggest screen garbling in any way
[16:52] <kirkland> cjwatson: is there a path i can use that will trigger this every time?
[16:53] <cjwatson> I don't have anything consistent; it happens for me when detaching focus with Ctrl+Alt
[16:53] <cjwatson> but only sometimes
[16:53] <cjwatson> note that I also change virtual desktops with ctrl+alt+left, but (due to another problem) I generally move the mouse out of the kvm window before doing so
[16:53] <cjwatson> (well, ctrl+alt+cursors)
[16:53] <kirkland> cjwatson: sure
[16:54] <kirkland> cjwatson: compiz on?  (just curious)
[16:54] <kirkland> (mine's off)
[16:54] <cjwatson> off
[16:55] <cjwatson> this is one of those things that I can reproduce as long as I'm not paying attention to it ...
[16:56] <cjwatson> could it be related to I/O? usually what seems to happen is that the installer's doing something time-consuming, so I switch away to check IRC or something, and then switch back and it's hung
[16:56] <cjwatson> I notice, anecdotally, that it never happens unless I grab focus
[16:57] <cjwatson> but sometimes I have to in order to press alt-f<thingy> without some bit of desktop furniture grabbing that keystroke
[16:57] <kirkland> cjwatson: okay, where "hung" = pressing keys, keys not registering, must drop to a virtual console, and back to reset and have good keyboard io again?
[16:58] <cjwatson> *some* keys not registering, as I said before
[16:58] <kirkland> okay, i'll keep an eye on it
[16:59] <cjwatson> I may not have mentioned that in at least one context I saw ^] or something like that displayed after I pressed a key
[16:59] <cjwatson> obviously only when the vt in use is in raw mode or whatever so that it does that rather than trying to interpret the key sequence
[17:00] <cjwatson> the only way I know of to fix keyboard I/O is to kill the kvm and start again
[17:23] <kirkland> cjwatson: out of curiosity, have you tested raid5 in jaunty?
[17:23] <kirkland> cjwatson: mathiaz reported really slow performance in a kvm;  that's not wholly unexpected to me (parity + triple disk io)
[17:24] <kirkland> cjwatson: but i was checking if anyone else has tried it (i'm doing it now)
[17:24] <cjwatson> no, I haven't
[17:25] <kirkland> k
[17:28] <kirkland> cjwatson: can i put /boot on ext4?  does grub have the smarts?
[17:28] <cjwatson> yes
[17:39] <cjwatson> davmor2,tjaalton: can you try http://cdimage.ubuntu.com/tmp/20090226/jaunty-server-i386.iso? it should rsync reasonably well against the current server image
[17:39] <cjwatson> err, hmm, let me push that to mirrors first
[17:41] <kirkland> cjwatson: fyi, raid5 install clean on jaunty ;-)
[17:41] <cjwatson> davmor2,tjaalton: ok, that image is up now
[17:41] <cjwatson> kirkland: cool. It's not something I test very often myself ...
[17:41] <kirkland> cjwatson: agreed.  it takes 537 clicks in partman :-)
[17:45] <davmor2> cjwatson: seems to be syncing nicely :)
[17:54] <davmor2> cjwatson: doing a whole install now if all goes well I'll try an lvm after
[17:55] <tjaalton> cjwatson: first thing in the morning ;)
[17:57] <davmor2> tjaalton: I'm going to be working for a bit anyway if it works for me you can confirm in the morning :)
[17:58] <tjaalton> davmor2: great :)
[18:58] <davmor2> cjwatson: first one worked starting second install now
[19:16] <davmor2> kirkland: I know this isn't the place but is there any plan in the server team to switch off the ability to hit alt-ctrl-delete to reboot the machine by default?
[19:17] <cjwatson> I recommend not changing that by default
[19:18] <cjwatson> it's a very useful facility
[19:18] <cjwatson> and the server has a much lower idiot factor than the desktop :-)
[19:18] <cjwatson> (I include myself in the idiots who occasionally hit ctrl-alt-backspace on the desktop)
[19:19] <cjwatson> anyway, you can configure it really easily in /etc/event.d/control-alt-delet
[19:20] <cjwatson> e
[19:24] <davmor2> cjwatson: I knew there would be a way, it's just I know some server installs do it by default and wondered if Ubuntu would be going down that path to :)
[19:32] <kirkland> davmor2: not that i know of
[19:33] <kirkland> davmor2: ie, i know of no initiative to change that default
[19:34] <davmor2> kirkland: Ta just wondered as I'd done it to restart my test machine :)
[21:15] <boingboing> hello! I have installed ubuntu 8.04 on my sata drive (partition sda2) and the boot loader on a USB pen (sdb) but when i try to boot from the grub on the pendrive it says: GRUB and doesn't load the system on the SATA HDD. can you help me?
[21:27] <boingboing>  I need to create a GRUB to load my sda2 from my sdb (usb pen) please help me
[21:41] <sergiobi> Hi all, i'm not sure to be in the correct room in order to ask my question... i can try... i hope U help me to redirect to the correct room ;)
[21:41] <sergiobi> i'm using ubuntu 8.10 distro and i want to install kdiff
[21:41] <davmor2> yes
[21:42] <sergiobi> i've searched the application in my repository... but i didn't found them... :(
[21:42] <sergiobi> do U know which is the correct repository?
[21:42] <sergiobi> thx in advance ;)
[21:44] <davmor2> hmm
[21:48] <davmor2> sergiobi: I would try on #ubuntu or #kubuntu to be honest it looks like it should be in universe
[21:49] <sergiobi> ok! i'll try!  thank U davmor2!
[22:01] <cjwatson> sergiobi: indeed, this channel is more for initial installation of Ubuntu than for installation of further packages once you have Ubuntu installed
[22:02] <mark> hi
[22:02] <mark> what is the easiest fix if, in the installer, both grub and lilo report that there is no matching bios drive for the startup drive(s)?
[22:07] <cjwatson> mark: what's the Linux device name?
[22:07] <mark>  /dev/sdy and /dev/sdac
[22:07] <cjwatson> the easiest workaround is probably to edit /target/boot/grub/device.map and then try again
[22:08] <mark> ok, I will try that
[22:08] <cjwatson> that sounds   /* The rest is SCSI disks.  */
[22:08] <cjwatson>   for (i = 0; i < 16; i++)
[22:08]  * cjwatson kicks grub
[22:09] <mark> haha
[22:09] <mark> you know how much fun doing partitioning in the ubuntu installer is on a box with 48 disks, over a 9600bps serial connection?
[22:09] <mark> ;)
[22:09] <cjwatson> I'm going to bet "not much"
[22:10] <mark> I had to write a script to manage all the software raid partitions and lvm on top
[22:10] <mark> it gets really confusing otherwise ;)
[22:10] <cjwatson> wow, lilo has the exact same limitation, 16 disks
[22:10] <mark> anyway, lilo also didn't inst...
[22:10] <mark> ah that would be why :)
[22:11] <mark> should I... open a launchpad bug for this? :)
[22:11] <cjwatson> I guess the expansion to 256 disks is more recent than either
[22:11] <cjwatson> definitely!
[22:11] <cjwatson> this shouldn't be hard
[22:12] <mark> I guess yesterday I was lucky with a slightly different model server, which used /dev/sda and /dev/sdi
[22:12] <cjwatson> I'm going to bed now, but will be happy to sort this out
[22:12] <mark> thanks :)
[22:12] <mark> sleep well
[22:12] <cjwatson> "Ubuntu now supports installation on machines with up to 256 disks"
[22:12] <mark> i'll file a bug
[22:12] <cjwatson> I can get that past management I'm sure ;)
[22:13] <mark> it sounds like it ;)
[22:13] <davmor2> cjwatson: tell them google need it :D
[22:13] <mark> wikimedia needs it too
[22:13] <mark> and I think canonical was quite happy with that too ;)
[22:13] <cjwatson> oh yes
[22:14] <cjwatson> I think partman supports this OK, but would want to check for random limitations there
[22:14] <cjwatson> it certainly supports above sdz
[22:14] <mark> yes it does
[22:15] <mark> these boxes have 48 disks, and with different boot drives it works fine
[22:15] <cjwatson> but this is the sort of thing where you might find a random limit somewhere just because hardly anyone needs this
[22:15] <mark> indeed
[22:15] <mark> I was just trying to remove all traces of solaris on these boxes...
[22:16] <cjwatson> looks like libparted is agnostic about this. good
[22:17] <mark> hmm what package should I report the bug on?
[22:18] <cjwatson> well, it has stupid code that looks at hd[a-h] and sd[a-f]; but that's ok because it looks through /sys/block/ anyway
[22:18] <cjwatson> mark: I'd recommend one bug with three tasks, one on each of lilo, grub, and grub2
[22:18] <cjwatson> mark: i.e. pick one of those for the initial bug report, then "Also affects distribution" and select each of the others in turn
[22:18] <mark> ok
[22:21] <cjwatson> please also assign it to me so that it doesn't fall off
[22:21] <cjwatson> and to deter bug triagers from doing the wrong thing overnight :-)
[22:21] <cjwatson> perhaps say that I asked you to file the bug
[22:21] <mark> ok
[23:45] <stgraber> cjwatson: bug 328097