[06:14] <bigjools> jam: thanks for the review - not sure what difference your suggestion makes as everything seems to work anyway.  I think it's more a UI validation thing isn't it?
[06:15] <jam> bigjools: I think if you get a form with multiple errors, the 'dict' method allows it to present both to users.
[06:15] <jam> I could be 100% wrong, though.
[06:15] <jam> I was just following along what other things did when I wrote a form recently.
[06:15] <bigjools> heh, I honestly have no idea.  Given this was an API call I figured a human readable string would be for the best but....
[06:16] <jam> bigjools: so the big win is to just not traceback, the rest is gravy
[06:16] <jam> If it works for you, that's enough for me for now.
[06:16] <bigjools> righto, cheers
[06:16] <jam> I'm certainly not blocking the fix, just something I thought I saw.
[06:16] <bigjools> well I am always open to improvements, otherwise what's the point of reviews
[06:16] <bigjools> :)
[08:23] <jam> rvba: merge conflict on your ssl-skip-check branch
[08:24] <rvba> jam: right, I'm on it, thanks for pointing it out.
[09:05] <rbasak> filter(arch=['armhf/highbank', 'armhf/armadaxp'])
[09:06] <w7z> arch__in=
[09:06] <allenap> filter(arch__in=['armhf/highbank', 'armhf/armadaxp'])
[09:07] <rbasak> arch_filter('arm')
[09:07] <rbasak> return filter(arch__in=['armhf/highbank', 'armhf/armadaxp'])
[09:48] <mgz> bug 1062340
[09:48] <mgz> ...nobot
[09:48] <mgz> thanks bot.
[11:14] <jtv> Any reviewers available for a smallish code extraction?  https://code.launchpad.net/~jtv/maas/maascli-fake-config/+merge/128466
[11:39] <jam> allenap: so after looking into it, it appears you *can* send application/json (or yaml, or a few things), but it doesn't come through transparetly.
[11:39] <jam> Instead of coming in as request.POST or request.GET, you get it as request.data
[11:40] <jam> (unless POST and GET also set data?)
[11:40] <jam> allenap: and performance wise, 42s with encode_multipart_data, and 33s as JSON with my hacks
[11:42] <allenap> jam: Cool. Not as conquer-all as hoped, but it's some improvement.
[11:42] <mgz> request.data makes more sense
[11:44] <jam> mgz: well, clearly I broke something as trying to revert to non JSON completed in 5s :) (with nothing getting updated, so clearly broken)
[11:44] <mgz> if you hack it to just concat the raw output and return in as application/octet-stream, what's the timing on that?
[11:45] <mgz> should give a baseline for the quoting, I suspect with C extentions json shouldn't be too bad though
[11:46] <jam> mgz: well, I'd still need to parse it, since we're dealing in batches.
[11:46] <mgz> (or is timing just that side difficult?)
[11:46] <jam> mgz: I can run it under lsprof to get feelings for timing as well. For 'how much time is spent in this C extension' lsprof is quite good
[11:46] <jam> because it doesn't hook the extension and slow it down.
[12:04] <rvba> allenap: I was just running the test suite in your branch 'make-docutils-happy' and I noticed a test failure that is also there in trunk (!): http://paste.ubuntu.com/1267323/
[12:05] <rvba> allenap: does it ring a bell?
[12:12] <jtv> Thanks for the review rvba
[12:13] <jtv> rvba: tests are passing for me... I hope I didn't accidentally land a bad maascli change.
[12:13] <jtv> Actually, I just ran tests in trunk and they passed...
[12:13] <rvba> jtv: really? That's weird…
[12:14] <jtv> Ah!  The test may be affected by the existence of maascli profiles.
[12:14] <jtv> Annoying global state.
[12:14] <jtv> That branch I have up for review will make it easier to patch that part.
[12:15] <rvba> jtv: you're right, if I move ~/.maascli.db the tests pass.
[12:15] <jtv> :/
[12:16] <jtv> rvba: if you move it back and run those same command lines that fail in the test, you may get a slightly more informative error.
[12:16] <jtv> Probably not very, since maascli swallows tracebacks, but some.
[12:21] <rvba> jtv: I'll file a bug.
[12:21] <jtv> Thanks.
[12:39] <mgz> if I do request.GET.get("something") what happens if non-ascii bytes are percent encoded in the query string value?
[12:39] <mgz> arbitrary bytestring? decoded to unicode as utf-8? left quoted?
[12:40] <allenap> jtv, rvba: Slighty related, but I may change the -d/--debug flag to be on the root argument parser, then we can consult it about displaying stack traces.
[12:40] <jtv> allenap: I'm about to move the parser into its own module.
[12:40] <allenap> jtv: Okay, I'll stay away from it for now.
[12:40] <jtv> I was having the same thought, actually.
[12:44] <allenap> Haha :)
[12:44] <allenap> roaksoax: Hi there. How do you feel about some package renames, a la https://bugs.launchpad.net/maas/+bug/1053507
[12:45] <allenap> or is it too late for that?
[13:23] <rbasak> mgz: I think I've got all the pieces, but what do I do about the test_POST_acquire_treats_unknown_arch_as_resource_conflict test? Now that I'm raising InvalidConstraint for an unknown architecture, the API returns an HTTP 400. Shall I just change the test accordingly, or is there some other behaviour that we want/
[13:23] <rbasak> ?
[13:44] <jam> rbasak: I think BAD_REQUEST is better than CONFLICT
[13:44] <jam> it just did conflict because that is what it was doing.
[13:47] <rbasak> thanks jam. I'll do that then
[13:58] <mgz> right, that test just wants adapting, should have left a comment in it to that effect
[14:15] <rbasak> smoser: do we have a precise ephemeral image released with a fix for bug 978127  yet, and if not, what's the schedule for this?
[14:15] <rbasak> (please)
[14:16] <roaksoax> allenap too late i think if u want to rename the packages you need to rename upstream so
[14:17] <roaksoax> otherwise it makes no difference
[14:18] <allenap> roaksoax: Okay, I'll stay away from that for now then.
[14:19] <roaksoax> allenap im not saying is not possible thought but Daviey was gonna accept the upload to the archives today
[14:20] <roaksoax> im on holliday today
[14:20] <roaksoax> allenap you might wanna check with him
[14:20] <rvba> Have a nice holiday roaksoax ;)
[14:21] <allenap> roaksoax: Right, sorry, didn't mean to bother you then.
[14:22] <roaksoax> rvba thanks ;)
[14:23] <roaksoax> allenap lol no worries im gonna be around just trying to stay away from work
[14:23] <roaksoax> ;)
[14:28] <smoser> rbasak, you want to test the daily there?
[14:28] <smoser> i can then promote that.
[14:28] <rbasak> matsubara: ^^ could you try the daily ephemeral on highbank please?
[14:29] <matsubara> rbasak, yes, will do today. I saw your email and the only workaround I didn't know how to do was to adjust the RTC for the arm board
[14:30] <rbasak> matsubara: yeah it's really awkward, since MAAS is the preferred tool to get an Ubuntu install on highbank in the first place
[14:30] <rbasak> matsubara: I think that if the daily does fix it then trying the daily will be the least work for all of us to verify it
[14:31] <matsubara> rbasak, cool
[14:31] <rbasak> matsubara: to verify that you have the problem, check the apache logs on the MAAS server. I think /var/log/apache2/access.log or something?
[14:32] <rbasak> matsubara: if you see a load of 40(1? 3?) messages for the same URL within a minute or two of booting into commissioning, then you have the RTC issue
[14:34] <matsubara> rbasak, ah ok. thanks for the pointer
[14:40] <smoser> rbasak, the other thing we need to hvae qa'd is at least that they do not regress 12.04
[14:40] <smoser> the 12.04 maas.
[14:41] <smoser> so if you wanted to walk http://bazaar.launchpad.net/~smoser/maas/maas-pkg-test/view/head:/maas-ephemeral-test-precise.txt to make sure we get those done, that'd be great.
[14:41] <rbasak> allenap: could you take a look at the test noise in http://paste.ubuntu.com/1267509/ please? The diff I'm working on is http://paste.ubuntu.com/1267475/. I can't see what I'm doing to introduce this, and the noise is particularly unhelpful.
[14:41] <smoser> i'm not here today.
[14:42] <allenap> rbasak: That's fixed in trunk.
[14:42] <allenap> Ignore it for now.
[14:42] <rbasak> allenap: how long ago? I pulled trunk an hour or so ago.
[14:42] <allenap> rvba: r1217
[14:43] <rbasak> allenap: ah
[14:43] <rbasak> allenap: thanks!
[14:49] <jtv> Any reviewers available?  I have some MPs waiting: https://code.launchpad.net/~jtv/maas/maascli-extract-parser/+merge/128501 and https://code.launchpad.net/~jtv/maas/maascli-profile-module/+merge/128510
[14:54] <jtv> allenap, can I prevail on you perhaps?
[14:54] <jtv> Or is "impose" the word I'm looking for?
[14:54] <mgz> does this error trying to run tests after pulling changes from today mean anything to anyone? <http://pastebin.ubuntu.com/1267528/>
[14:55] <jtv> Rings a bell.
[14:56] <jtv> Try "make distclean" and then "rm -rf db"
[14:56] <jtv> Then try again.
[14:56] <mgz> make clean and rm -rf db didn't help
[14:56] <mgz> I'll try distclean.
[14:56] <jtv> Best do the distclean first; it kills the postgres instances running inside your branch.
[14:57] <mgz> hm, and eggs, I might back them up first
[14:57] <jtv> back them up?
[14:57] <jtv> The db directory in your branch was designed to be utterly disposable.
[14:58] <mgz> I haven't bothered setting up an egg cache here, as I'm only using one working tree
[14:58] <jtv> Ah
[14:58] <mgz> getting everything from pypi again would be mildly annoying
[14:58] <jtv> Well you _can_ just kill postgres instances and rm -rf db.
[14:58] <jtv> If that didn't fix this problem, I don't think "make distclean" would.
[14:58] <rbasak> mgz: https://code.launchpad.net/~racb/maas/arch-constraint-wildcard/+merge/128513
[14:59] <jtv> Ohhhh this wasn't the weird problem involving transactional tests, was it?
[14:59] <rbasak> mgz: tests pass. I haven't tried a juju bootstrap yet though. I'll need to create a package and test from that, which will take a while
[14:59] <allenap> jtv: Sure, I'll take a look.
[15:00] <jtv> Thanks.
[15:00] <jtv> I'll shove some food into my face.
[15:00] <mgz> rbasak: ace, will have a look
[15:03] <mgz> gah, something weird is going on
[15:03] <mgz> I'll throw away the instance I think
[15:10] <jam> mgz: any luck with the search string is juju constraints?
[15:11] <jam> jelmer: any luck with the retry code?
[15:11] <mgz> rbasak: looks good
[15:11] <jam> After those things, the next important thing is to do pagination on the 'nodes' listings.
[15:11] <mgz> jam: I'm done, am just trying to get the test suite to actually run...
[15:16] <jam> mgz, allenap, jelmer: I'm trying to tune the 'batch_size' for tag processing. Bumping it from 100 to 1000 means downloading 25MB per batch (for the XML) vs 2.5MB for the batch.
[15:16] <jam> And speeds up the 12,000 unit case from 37s to 35s.
[15:17] <mgz> ....that doesn't seem much
[15:17] <jam> Trying to bump it to 10,000 increases the batch size to 250MB, which crashes on my 2GB VM
[15:17] <mgz> ehehe
[15:17] <jam> (I'm guessing there are multiple levels so that at peak we have >1 copy of the full text)
[15:17] <jam> json.loads() isn't streaming, etc.
[15:28] <mgz> ...some how my db is hosed in a way rming and destroying the vm does not fix...
[15:35] <mgz> hm, trunk is fine, rebase and hope time
[15:37] <jtv> mgz: we have observed some problems that seem to be affected by interactions between tests, and maybe test setup/teardown.  Did you add or remove any test cases?
[15:38] <jtv> Thanks for the reviews allenap!
[15:38] <allenap> Welcome.
[15:39] <mgz> jtv: yes, new test class, and nose stopped admitting to the existence of the whole module
[15:39] <mgz> (generally means something inside the module is raising ImportError, but I can't spot it)
[15:40] <jtv> mgz: then I'd look in that direction for suspects. Still a mystery why this happens.  Does your test case do anything weird?  Like rely on transactions behaving realistically, or models that exist only within the tests?
[15:40] <mgz> bin/py -c "import maasserver.tests.test_views_nodes" should tell me that much...
[15:41] <mgz> or not, because of django settings... >_<
[15:43] <jtv> I'll bet the problem goes away when you run your tests in isolation.
[15:43] <mgz> gah, no -1 option? noooose...
[15:44] <jtv> Man, using 4 kinds of pepper in one meal is awesome.  Two kinds as spices, two as vegetables.
[15:45] <mgz> okay, so I have an import error in a different bit of the tree
[15:46] <jtv> Is it a circular import or something like that?
[15:46] <mgz> typoed 'node' as 'name' from models when importing into views
[15:46] <mgz> so, shouldn't be circular (models don't care about views)
[15:47] <mgz> but is related to the test module that was misbehaving
[15:47] <mgz> ...implies some cleanup on db level isn't happening if test fails at too early a stage?
[15:47] <mgz> starts db setup, tries to setup tests, gets error, cleanup doesn't run, or similar?
[15:49] <jtv> We are completely in the dark.  Otherwise we'd probably have fixed it by now!
[15:49] <jtv> Note how incredibly early it happens.
[16:21] <mgz> okay, I'm all proposed up.
[16:28] <rbasak> mgz: may I have a +1 for https://code.launchpad.net/~racb/maas/arch-constraint-wildcard/+merge/128513 or do you not think it OK to land yet? I'm thinking that if I get it in the daily then we can easily test tomorrow - otherwise I'm tight for time for today's EOD anyway
[16:28] <allenap> jtv: Did you forget a prerequisite branch, or is the diff wrong on https://code.launchpad.net/~jtv/maas/maascli-cli-subcommand/+merge/128538?
[16:32] <mgz> rbasak: just done, with some minor comments
[16:32] <mgz> getting it in the daily sounds good.
[16:33] <rbasak> mgz: thanks, I'll get those changes done
[16:33] <jtv> allenap: let me have a look
[16:34] <jtv> allenap: I jumped the gun on that one and assumed the diff would update.  I'll see if I can trigger a re-diff.
[16:36] <allenap> jtv: Don't worry about it too much; I have generated it for myself.
[16:36] <mgz> rbasak: one option I didn't mention was you could avoid the aliased_value stuff by doing that in the same mapping too
[16:36] <jtv> allenap: too late :)
[16:36] <mgz> ie, `architecture_wildcards['arm'] = architecture_wildcards['armhf']`
[16:37] <mgz> or equivalent.
[16:37] <rbasak> mgz: that's very tidy - thanks!
[16:37] <mgz> moving as much of that logic out of the constrain_architecture function and into precalculated data I like
[16:38] <allenap> jtv: What did you do to make it update by the way?
[16:39] <jtv> allenap: I replaced some instances of "log-in" and "log-out" (used as verbs) with "log in" and "log out" in the api.py docstrings.
[16:40] <allenap> jtv: Haha :)
[16:40] <jtv> OCD-R-Us
[16:41] <allenap> rvba: Would you be able to give a second opinion on https://code.launchpad.net/~jtv/maas/maascli-cli-subcommand/+merge/128538?
[16:41]  * allenap has to go, urgently, to collect kids.
[16:42] <rvba> allenap: sure.
[16:42] <rvba> allenap: could you have a look at the branch I just put up for review when you get back: https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543
[16:50] <rvba> jtv: I'm having a look at the comment Gavin made on your maascli-cli-subcommand branch…
[16:51] <rvba> jtv: but the 'cli' subcommand is long gone am I right?
[16:51] <jtv> No, it's brand new.
[16:51] <rvba> arg, I mean s/cli/api/
[16:52] <rvba> jtv: So, I don't really get why you're introducing this new subcommand.
[16:53] <jtv> The api subcommand is long gone, but the next step is to remove the profile name as a subcommand.
[16:53] <jtv> Did I say "api"?  Mistake.
[16:53] <jtv> Right now you'd say something like "maascli mylogin acquire_node <node>"
[16:53] <rvba> Indeed.
[16:54] <jtv> and that should become, for the case where mylogin is the default profile:
[16:54] <jtv> "maascli acquire_node <node>"
[16:54] <rvba> Right, I get that… what does it have to do with 'api' or 'cli' then?
[16:55] <rvba> I'm just trying to understand what Gavin said in his comment.
[16:55] <jtv> If we _also_ have commands like "maascli login profile URL", then they live in the same namespace as the methods of the API.
[16:55] <jtv> Not a good idea: "list" could easily be used in both the CLI commands and the API, for instance.
[16:56] <jtv> So the CLI commands (login, logout, refresh, list) move into a separate subcommand.
[16:56] <jtv> That leaves the root namespace free for API commands.
[16:56] <rvba> Ah ok, I see.
[16:57] <rvba> I wasn't aware of the intention to move the CLI commands under 'cli'.
[16:57] <roaksoax> rvba: weird, you run into that db_ bug
[16:59] <jtv> rvba: sorry -- I've been trying to mention the big picture in all my MPs but it's hard not to start skipping things with so much repetition.
[17:00] <rvba> jtv: I understand.  But I've been asked to give a second opinion so I needed to put all the pieces of the puzzle together. :)
[17:00] <jtv> I hope that doesn't mean trouble for my branch!
[17:00] <jtv> It's a bit of a difficult transition, trying to do everything in small chunks.
[17:00] <rvba> I imagine :)
[17:01] <flacoste> roaksoax: has ipmi setting in enlistment landed?
[17:01] <rvba> I think Gavin is right though.  I'll summarize my thoughts on the MP.
[17:01] <roaksoax> flacoste: not as of friday... today I didn't check (i'm not really here, US holidays...)
[17:02] <flacoste> roaksoax: aren't you the one working on that?
[17:02] <roaksoax> flacoste: allenap was the one who was working on enabling the power settings for enlistment
[17:03] <rvba> flacoste: roaksoax I /think/ this has been landed.
[17:03] <rvba> Let me check.
[17:03] <rvba> flacoste: roaksoax: confirmed, https://code.launchpad.net/~allenap/maas/anon-power-setting/+merge/128127 has landed.
[17:05] <roaksoax> flacoste: landed today so tomorrow I'll take care of the enlistment IPMI temporary credentials then
[17:05] <flacoste> roaksoax: ok, and we'll 0-day SRU any hiccups from that?
[17:06] <roaksoax> flacoste: yeah
[17:06] <flacoste> landing this tomorrow seems very risky since we won't have time to react to any problem
[17:06] <flacoste> nor have matsubara do a proper round of  QA around the new changes
[17:07] <roaksoax> Daviey: until when can we make uploads?
[17:07] <roaksoax> to archive
[17:08] <roaksoax> flacoste: right, so landing this will only make use of the script that does the detection during the commissioning, but does need support from maas-enlist
[17:09] <flacoste> roaksoax: tomorrow 21UTC according to the ReleaseSchedule wiki page iuc
[17:10] <roaksoax> flacoste: right, so i'm wondering now, what's the latest upstream release that we are going to actually release to archives?
[17:10] <roaksoax> flacoste: i made an upload over the weekend that Daviey will process
[17:10] <roaksoax> flacoste: but I'm updating that (same upstream release though) with packaging fixes
[17:11] <flacoste> roaksoax: there have a couple of bug fixes in progress that should be released
[17:11] <flacoste> roaksoax: so we should plan on a new upstream tomorrow
[17:12] <roaksoax> flacoste: ok, right, so since new upstreams are mostly bug fixes, then we should be good
[17:18] <rvba> jtv: do you have time to review https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543 ?
[17:18] <jtv> I think I can, yes
[17:18] <rvba> Thanks a lot.
[17:19] <jtv> So it was Apache after all?
[17:19] <Daviey> roaksoax: Final Freeze kicks in tomorrow
[17:20] <Daviey> And this large upload certainly needs to be in by then
[17:20] <Daviey> After that, we can sneak in some last minute fixes.
[17:20] <roaksoax> Daviey: right, which means with the latests upstream release
[17:20] <Daviey> right
[17:20] <rvba> jtv: yes
[17:21] <roaksoax> Daviey: ok so instead of uploading today, I guess I'll make an upload tomorrow
[17:21] <roaksoax> Daviey: and the enlistment stuff... takes more than just add the support to MAAS
[17:22] <roaksoax> Daviey: cause needs work on maas-enlist as well
[17:22] <roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/packaging_updates_bzr1099-2/+merge/128551
[17:22] <roaksoax> please: )
[17:25] <Daviey> roaksoax: erm, getting trunk onto tomorows ISO i would consider vital
[17:25] <Daviey> so an upload today and another tomorrow
[17:25] <roaksoax> Daviey: alright!
[17:26] <roaksoax> Daviey: today's trunk on today's upload?
[17:27] <rvba> Daviey: roaksoax don't you think it's pointless to make an upload before we fix: bug 1063857 ?
[17:28] <roaksoax> rvba: that's fixed already
[17:28] <roaksoax> rvba: see above link  i sent you :)
[17:28] <rvba> roaksoax: it that fixing it?  Ok then :)
[17:29] <roaksoax> rbasak: i take that the branch you proposed for bug #1062340 takes care the i386 amd64 cases too?
[17:29] <Daviey> rvba: TBH, we keep saying that.. and the upload is embarrassingly large already
[17:29] <Daviey> heck, it still uses ipmitool
[17:29] <rbasak> roaksoax: I believe so. Could you clarify exactly what you mean? That "amd64" should work?
[17:30] <roaksoax> rbasak: i mean, it completely replaces my branch and if juju sends amd64 it gets mapped correctly and won't fail to acquire node?
[17:31] <rbasak> roaksoax: I believe so, yes
[17:32] <roaksoax> cool
[17:34] <rvba> jtv: I just posted a reply to your review on https://code.launchpad.net/~rvb/maas/bug-1062607/+merge/128543
[17:40] <jtv> coming
[17:46] <jtv> Replied.  I'll do a bit of rebooting to see if that'll bring back my window manager.  I've been working without one since before midnight.
[17:54] <rvba> jtv: that's funny, my window manager disappeared a few hours ago :)
[17:57] <jtv> Question is: who has them?
[18:00] <roaksoax> rvba: around?
[18:00] <roaksoax> rvba: can you test the package i just uploaded to experimental
[18:00] <rvba> roaksoax: sure
[18:11] <rvba> roaksoax: the problem is still there :/ http://paste.ubuntu.com/1267881/
[18:12] <roaksoax> rvba: sudo dpkg-reconfigure maas-cluster-controller ?
[18:12] <roaksoax> MAAS_URL=http://<IP_ADDRESS>/MAAS
[18:12] <roaksoax> that;s me
[18:13] <rvba> Yeah, now /etc/maas/maas_cluster.conf is populated…
[18:15] <rvba> roaksoax: but now I don't see the cluster worker… even if I restart maas-cluster-celery.
[18:16] <roaksoax> rvba: weird, I have  arunning cluster
[18:16] <rvba> roaksoax: can you pastebin 'ps aux | grep celery' ?
[18:16] <roaksoax> ubuntu@node2:~$ sudo service maas-cluster-celery status
[18:16] <roaksoax> maas-cluster-celery start/running, process 8009
[18:16] <roaksoax> https://pastebin.canonical.com/76065/
[18:16] <roaksoax> err
[18:18] <roaksoax> rvba: did you deploy on a new cloud instance?
[18:18] <rvba> roaksoax: yes
[18:20] <rvba> roaksoax: rarg, my fault, I made a mistake when I entered the url :/
[18:21] <rvba> roaksoax: Now it's fine
[18:22] <roaksoax> rvba: right, but initial autodetection is not working
[18:22] <rvba> roaksoax: indeed.
[18:22] <roaksoax> rvba: idk what bigjools might have changed
[18:22] <roaksoax> if any
[18:25] <roaksoax> rvba: i know what it is
[18:25] <rvba> ?
[18:26] <roaksoax> rvba: it doesn't ask for the dbconfig question if it couldn't be autodetected
[18:26] <roaksoax> rvba: but then it replaces it from loclhost to nothing
[18:36] <roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/packaging_update_cluster/+merge/128564
[18:36] <roaksoax> now it will be left as localhost/MAAS
[18:36] <roaksoax> rvba: the problme is that maas-region-controller installs after maas-cluster-controller, causing that the latter cannot autodetect the URL
[18:37] <rvba> roaksoax: can we control the order in which the packages are installed?
[18:38] <roaksoax> rvba: not really no
[18:41] <rvba> roaksoax: I've approved the branch.
[18:41] <roaksoax> rvba: what could be done for such case is allow the region-controller set that value
[18:44] <rvba> roaksoax: but that would mean having one package change the config of another one right?  Isn't it against the rules?
[18:47] <roaksoax> rvba: it is indeed., tjhat
[18:47] <roaksoax> that's where i was going next
[18:50] <roaksoax> Daviey: uploading now
[18:58] <jtv> smoser: having a look at bug 1050033... the old Precise version of maas-import-ephemerals has installed initrd files.  There is no .gz suffix, but I think they were already gzip-compressed.  Is that normal?  Can I assume that an initrd file will already be gzipped, so that I can just link or rename?
[19:05] <jtv> (I think gzip will do the right thing anyway if I try to compress an already-compressed file anyway)
[19:17] <rvba> roaksoax: is that normal that debian/changelog contains "maas (0.1+bzr1223+dfsg-0ubuntu1~ppa1) quantal; urgency=low"… I mean the 'ppa' part?
[19:45] <roaksoax> rvba wheres that
[19:45] <roaksoax> jtv: id you see the comment i made to your pscksging MP¿
[20:30] <Daviey> roaksoax: erm, this indicates 3 different uploads?
[20:30] <Daviey> can you fold debian/changelog to be accurate for the ubuntu archive?
[20:31] <roaksoax> Daviey it is just one upload
[20:32] <Daviey> roaksoax: the changelog shows 0.1+bzr1223+dfsg-0ubuntu1, 0.1+bzr1110+dfsg-0ubuntu1, 0.1+bzr1063+dfsg-0ubuntu1,
[20:32] <Daviey> two of them were never uploaded to quantal?
[20:33] <roaksoax> Daviey: yeah I know what's wrong
[20:33] <Daviey> PPA vs Archive changelog?
[20:33] <roaksoax> Daviey: yeah, bigjools made uploades and treated as releases in the packaging branch
[20:33] <roaksoax> uploads to PPA
[20:33] <Daviey> ahh
[20:33] <Daviey> blame bigjools then :)
[20:34] <roaksoax> Daviey: my fault for not telling him earlier that changelog entreies were for releases in quantla not in PPA :)
[20:36] <Daviey> roaksoax: don't try to cover for him.. :D
[20:37] <roaksoax> oh well, i should have been clearer though
[20:39] <Daviey> heh
[20:40] <roaksoax> Daviey: do you want me to fix it though?
[20:40] <roaksoax> and merge all of the changelogs?
[20:45] <Daviey> roaksoax: Up to you.. Personally, i'd prefer it.. as it is currently a lie, but not enough to reject
[20:51] <roaksoax> Daviey: alright fixing it then
[20:56] <roaksoax> Daviey: i'm ready to upload
[20:58] <roaksoax> Daviey: could you please reject the other one?
[21:03] <Daviey> ok
[21:04] <roaksoax> Daviey: ok, new version uploaded it's all yours :)
[23:17] <bigjools> morning
[23:32] <bigjools> roaksoax: around?
[23:34] <roaksoax> bigjools: barely.. in class.. what's up?
[23:35] <bigjools> roaksoax: just wanted to check in with you and see how things are going
[23:35] <roaksoax> bigjools: maas is in quantal... tomorrow we'll be making a new upload :)
[23:35] <bigjools> roaksoax: did anyone test upgrades from precise?
[23:37] <roaksoax> bigjools: not from the new packages (there's no way to do it as it disables PPA's). That's something that has to be done now
[23:38] <bigjools> there's always a way ;)
[23:38] <bigjools> ok, I guess I'll be firing up some canonistack instances today
[23:38] <roaksoax> bigjools: i tested from precise -> older quantal -> newer quantal so I'm pretty confidence it will wokr
[23:38] <roaksoax> bigjools: and yes I was planning to do the same after I come back home
[23:38] <bigjools> cool
[23:39] <bigjools> I will look at some things I know we had to hack hard on to make work for upgrades
[23:39] <roaksoax> bigjools: the cluster things will still be a problem
[23:39] <bigjools> in what way
[23:39] <bigjools> ?
[23:40] <roaksoax> bigjools: the question is not being asked being medium priority
[23:40] <roaksoax> rvba reported that today and I fixed a couple bugs there
[23:42] <roaksoax> bigjools: http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/121 http://bazaar.launchpad.net/~maas-maintainers/maas/packaging/revision/120
[23:45] <bigjools> ok
[23:46] <roaksoax> bigjools: the problme is that in some cases it seems that it gets installed before maas-region, hence it fails
[23:46] <roaksoax> bigjools: i think however, that in the installer i could override that questions
[23:46] <roaksoax> that question
[23:50] <bigjools> roaksoax: hmmm the config file should be on disk from the existing maas package though
[23:50] <bigjools> hence no question should ever be asked
[23:54] <roaksoax> bigjools: right, but it was resulting on the maas_cluster.conf having URL=
[23:54] <bigjools> that can only mean that the existing config was broken then
[23:54] <bigjools> oh this is the db_get cockup
[23:55] <roaksoax> bigjools: yeah, so db_get was returning empty
[23:55] <bigjools> so, the question should still not get asked
[23:55] <bigjools> and that logic was fixed I see, so... where's the problem? :)
[23:55] <roaksoax> bigjools: that the question should be asked on machines that do not have the region-controller
[23:56] <bigjools> roaksoax: that is perfectly fine
[23:56] <bigjools> the package is never auto installed
[23:56] <roaksoax> alright
[23:56] <bigjools> only on upgrades from maas
[23:56] <bigjools> where the config is guaranteed to exist
[23:56] <roaksoax> alright
[23:57] <bigjools> is that ok? makes sense?


[01:02] <rbnswartz> DBO got a minute?
[01:02] <DBO> ya
[01:03] <rbnswartz> okay I think I have a fix but I want to test it on my own. How would I go about that?
[01:04] <DBO> rbnswartz, you need to build it :)
[01:04] <DBO> lemme see if I cant find a walkthrough on that
[01:05] <rbnswartz> would I just use cmake on a natty system.
[01:05] <DBO> yes
[01:05] <DBO> you probably need to get nux
[01:05] <DBO> https://wiki.ubuntu.com/Unity/InstallationGuideFromSource
[01:06] <DBO> some hints can be foudn there
[01:06] <rbnswartz> Duh I should have checked there first
[01:07] <rbnswartz> Okay that pretty much answers my question
[01:09] <rbnswartz> DBO This will only work on a natty system correct.
[01:09] <DBO> ya
[01:09] <rbnswartz> Okay also how do I commit it after I fix it?
[01:09] <DBO> did you check out from bzr?
[01:10] <rbnswartz> I have bzr installed (and loving it).
[01:10] <rbnswartz> I did not check it out
[01:10] <rbnswartz> what command would I use?
[01:10] <DBO> to check out unity you do
[01:10] <DBO> bzr branch lp:unity
[01:10] <DBO> then you modify the code in checks out
[01:11] <DBO> then to commit you
[01:11] <rbnswartz> I used bzr to get the code.
[01:11] <DBO> bzr commit -m "describe what you did"
[01:11] <DBO> bzr push lp:~LAUNCHPAD_ID/unity/unity.BRANCH_NAME
[01:11] <DBO> replace the obvious bits
[01:12] <rbnswartz> What obvious bit? :)
[01:12] <rbnswartz> Thanks for your help
[01:13] <DBO> instead of "describe what you did" something like "fixed bug blah blah blah"
[01:13] <DBO> LAUNCHPAD_ID == your launchpad id
[01:13] <rbnswartz> Yeah I got that. hence the smily
[01:13] <DBO> oh :)
[01:13] <DBO> sorry
[01:13] <DBO> you got me :P
[01:14] <rbnswartz> do you push or commit first
[01:16] <rbnswartz> DBO? ^^
[01:16] <DBO> commit
[01:16] <DBO> then push
[01:16] <DBO> commit == save this
[01:16] <DBO> push == now put it on the server
[01:16] <rbnswartz> then that will show up as a branch in unity correct?
[01:18] <DBO> rbnswartz, correct
[01:18] <rbnswartz> thanks for your time I have to go. Happy coding.
[01:19]  * spikeb_ just got his copy of "engineering usability" in the mail
[01:19] <spikeb_> er, i got the title words backwards. it is usability engineering
[01:21] <nnnaji> spikeb_: hi
[01:21] <spikeb_> hi nnnaji
[01:22] <nnnaji> ;)
[01:22] <nnnaji> spikeb_ , you've seen how that bug turned out, right?
[01:22] <nnnaji> did you poke in the code?
[01:23] <spikeb_> no, not a coder, so i tend to stay away from it
[01:23] <nnnaji> same here, but its only a string in a label in a title in a ...
[01:23] <spikeb_> haha
[01:24] <nnnaji> https://bugs.launchpad.net/synaptic/+bug/688811
[01:24] <nnnaji> i got as far as changing the string :P
[01:24] <nnnaji> http://launchpadlibrarian.net/60720091/Screenshot.png
[01:24] <spikeb_> i did see that :)
[01:25] <nnnaji> spikeb_ : now i'm trying my luck with some (easier) python code ...
[01:25] <nnnaji> update-manager has the same problem..
[01:25]  * spikeb_ nods
[01:25] <nnnaji> but i'm running into FTBFS
[01:25] <spikeb_> oh nice
[01:25] <nnnaji> well.. i guess i'm on my own for now..
[01:26] <spikeb_> good luck!
[01:26] <nnnaji> thanks ;)
[01:27] <nnnaji> your luck helped :D
[01:29] <spikeb_> great!
[01:38] <nnnaji> spikeb_ what do you think.. can Me Menu's Presence settings control notify OSD's behaviour?
[01:38] <spikeb_> so that if you're set to away, it doesn't bother you?
[01:38] <nnnaji> or should one just have a seperate toggle for "Do Not Disturb" aka "Silent Mode" in the Session Menu?
[01:38] <nnnaji> yeah, something like that
[01:39] <nnnaji> i was thinking of "Busy" aka "Not Avaiable" as the law
[01:39] <spikeb_> nnnaji, offhand, i would say that we should have a seperate setting for silent mode.
[01:39] <nnnaji> ok
[01:39] <spikeb_> too many use cases where the user wants to appear away or busy, but wants to know what is happening.
[01:40] <nnnaji> ok.. valid point
[01:41] <nnnaji> where should it be?
[01:41] <nnnaji> in the session menu?
[01:41] <spikeb_> hmm
[01:41] <spikeb_> that is a good question.
[01:41] <nnnaji> where else ? :D
[01:42] <spikeb_> i have no idea
[01:43] <nnnaji> well thanks a lot for your thoughts, you helped me see it from another perspective
[01:43] <spikeb_> you're welcome. i'm going to think some more and post on the mailing list if i get any ideas
[01:43] <nnnaji> that would be cool, since this thing needs be handled now, even sabdfl is pressing now
[01:44] <nnnaji> haaah
[01:48] <spikeb_> ok, quick survey of some people says your idea of putting it in the session menu is probably a good one
[01:48] <spikeb_> might want to run the idea past the folsk on the mailing list though
[01:49] <spikeb_> folks, not folsk
[01:49] <nnnaji> ok.. i guess that makes sense, too
[01:49] <nnnaji> i'll do some more thinking myself, before i write up more nonesense :D
[01:50] <spikeb_> sounds good :)
[05:30] <r2wj> anybody awake
[06:00] <spikeb> any of you read jakob nielson's "usability engineering" ?
[06:00] <spikeb> my brain is fried after three chapters!
[06:11] <jhuin> spikeb, good or bad fried? :P
[06:11] <spikeb> good - it is busy processing all the information i just read
[06:11] <spikeb> the author manages to pack information into every nook and cranny of the book.
[07:02] <kvalo> morning
[07:04] <spikeb> morning
[07:14] <kvalo> hi spikeb
[07:14] <spikeb> hi kvalo
[08:15] <evaluate> is there any function I could call to show the application indicator's menu? (in C)
[09:19] <theone_> hello ppl, I am a newbie, interestd in contributing to unity code. I have installed natty daily uild, bzr and have got the the code by it. Now what to proceed further?
[09:20] <seb128> hey theone_
[09:20] <seb128> did you read http://unity.ubuntu.com/getinvolved/?
[09:20] <seb128> https://wiki.ubuntu.com/Unity
[09:20] <seb128> as well
[09:20] <seb128> if not start by reading those
[09:20] <seb128> https://wiki.ubuntu.com/Unity/Bitesize as well
[09:21] <theone_> seb128, yes I have read and followed through all its steps
[09:21] <seb128> do you have specific questions?
[09:22] <seb128> or you can start trying to fix one of the bugs?
[09:23] <theone_> seb128 :  ya, I have never worked on a collaborative open source project using a VCS. so, how can I start working with the buglist. I mean, how it can be compiled and tested on the system?
[09:24] <seb128> http://unity.ubuntu.com/getinvolved/ has those steps
[09:25] <seb128> well, https://wiki.ubuntu.com/Unity/InstallationGuideFromSource
[09:25] <seb128> but if you just work on unity it's easier
[09:25] <seb128> we probably need to clean a bit the instructions on this one
[09:25] <seb128> see the Unity set on this page?
[09:25] <seb128> if you only want to build it drop "-DCMAKE_INSTALL_PREFIX=/opt/unity"
[09:28] <theone_> seb128, ok. i will try it now. thanks
[09:29] <seb128> just ask there if you have issues
[13:57] <mdeslaur> ronoc: since I updated this morning, rhythmbox isn't being displayed in the indicator-sound menu anymore. Any ideas?
[13:58] <ronoc> mdeslaur, natty ?
[13:59] <mdeslaur> ronoc: yes
[13:59] <ronoc> version 0.5.3 ?
[13:59] <mdeslaur> ronoc: yes
[14:02] <ronoc> mdeslaur, we are using a completely different mechanism for menu registration now. It is done exclusively with mpris, the last time I checked rhythmbox does not implement the root mpris spec correctly ( I have mailed Jonathon about this). The Desktopentry prop on the root interface should contain the name of the desktopfile minus the .desktop suffix. Rhythmbox exposes the full path to the file
[14:03] <ronoc> and as a result my service ignores it
[14:03] <ronoc> banshee should work fine
[14:03] <ronoc> big release yesterday so a few clients i suspect will break
[14:04] <mdeslaur> ronoc: ok, thanks
[14:04] <ronoc> mdeslaur, np
[14:04] <mdeslaur> ronoc: so I should re-file by bug against rhythmbox then I guess
[14:07] <mdeslaur> ronoc: fyi, bug 691556
[14:09] <ronoc> mdeslaur, okay thx
[15:24] <kenvandine> ronoc, indicator-sound SRU uploaded
[15:24] <ronoc> thanks kenvandine
[15:34] <evaluate> hello
[15:34] <nnnaji> hi
[15:35] <evaluate> I have an application in C that uses the indicator. I have to refresh the menu of the indicator periodically, but I don't want it to refresh when the menu is open (as in visible), because this looks ugly (the menu closes and opens automatically on refresh). Is there a way to tell if the menu is open?
[15:36] <evaluate> I tried gtk_widget_get_visible() but this doesn't seem to work...
[15:37] <nnnaji> i guess i won't get far past "hi" in this conversation :P
[15:37] <evaluate> nnnaji, :-)
[15:38] <nnnaji> evaluate_ : you mean AppIndicator, right?
[15:38] <evaluate> also, I looked up the indicator C API, but I can't see a signal that gets fired when the menu is opened...
[15:38] <evaluate> nnnaji, yup
[15:38] <nnnaji> yeah, they're not so well documented..
[15:39] <evaluate> nnnaji, that's why I'm here. I was hoping that someone had an idea of how I could do this...
[15:40] <nnnaji> evaluate_ : in webdesign, i would have worked with OnMouseEvent event handlers
[15:40] <nnnaji> but here.. !?!?
[15:41] <nnnaji> perhaps you can grab a hover for the area of an open menu somehow in gtk?
[15:43] <evaluate> nnnaji, I'm not sure what you mean, but I wouldn't want to use ugly "hacks" to accomplish this. IMHO this should be supported by the AppIndicator (I mean somehow getting the visible/hidden property of the menu)...
[15:43] <nnnaji> true.
[15:43] <nnnaji> have you tried ayatana-dev mailinglist?
[15:44] <evaluate> nnnaji, no, I hoped to find help here...
[15:46] <nnnaji> evaluate, ok, i'll keep out of it! ;)
[15:46] <evaluate> nnnaji, thing is, I curretly have a function that gets executed every half second. It would be most convenient for me to use that one and just skip the refresh when the menu is visible.
[15:47] <nnnaji> evaluate, curious, is this top secret or may i ask what you are working on?
[15:47] <evaluate> If I wouldn't use that one, I would have to insert the menu refreshing function into every function after which a menu refresh is needed, which is a lot more work for me
[15:47] <evaluate> nnnaji, I am working on a clipboard manager, it's name is clipit (sf.net/projects/gtkclipit)
[15:48] <kvalo> njpatel_: hi. do you have indent command line switches for unity coding style?
[15:49] <nnnaji> evaluate, thanks, i use another clipboard manager at the moment, i wish you well with your project, clipboard managers have potential, if well designed
[15:50] <evaluate> nnnaji, thank you! may I ask what you use atm?
[15:51] <njpatel_> kvalo, the C style?
[15:51] <njpatel_> kvalo, I had them somewhere....
[15:51] <njpatel_> will have to look them up
[15:52] <kvalo> njpatel_: no rush, I can ask you later
[15:54] <nnnaji> evaluate, i use pastie, it's feature rich and i don't exactly enjoy the UI
[15:55] <evaluate> nnnaji, ohh, don't know that one yet.
[15:58] <evaluate> nnnaji, hmm, it actually has less features then clipit as far as I can see...
[15:58] <nnnaji> then it isn't feature rich but chaotic
[15:58] <evaluate> nnnaji, lol :p
[16:00] <evaluate> nnnaji, if you like pastie, you should check out clipit if you have the time...
[16:01] <nnnaji> evaluate, of course i will, i love clipboard managers! i often have more than 2 links i want to paste into an email without switching windows repeatedly, but without a good clipboard manager, that is a horrible task to achieve
[16:02] <nnnaji> evaluate, do you include options in the edit portion of the context menu, e.g. 2 or more Paste items?
[16:03] <evaluate> nnnaji, sorry, but I don't understand what you mean...
[16:04] <evaluate> nnnaji, you mean if the number of items shown in the menu is editable?
[16:06] <nnnaji> evaluate, i mean in the context menu you have nothing but "copy", "cut" and "paste" and perhaps "delete"
[16:06] <nnnaji> perhaps you have multiple "paste" items with gtkclipit installed?
[16:06] <nnnaji> or even a "paste" submenu
[16:07] <nnnaji> or a "clipit" submenu
[16:07] <evaluate> nnnaji, ohh, clipit doesn't interfere with the context menu yet, but that is a good idea indeed... :-)
[16:09] <evaluate> nnnaji, currently I was struggling to make it cooperate nicely with the AppIndicator...
[16:12] <nnnaji> evaluate, looking forward to Clipit AppIndicator!!
[16:13] <nnnaji> evaluate, have you considered moving to launchpad.net ?
[16:14] <evaluate> nnnaji, I'm ok with sourceforge for now... I have a PPA on launchpad though...
[16:14] <nnnaji> ahaaaa... i'll check it out
[16:15] <evaluate> if you use the current PPA I have to inform you that currently the indicator menu doesn't refresh itself when you copy new items or change the history, so you will have to use the "small history" menu (there's a hotkey for that) if you want an up-to-date list
[16:17] <nnnaji> evaluate, i checked the ppa and did apt-get update, but i notice you have no natty packages, stimmts?
[16:17] <nnnaji> ;)
[16:19] <evaluate> kann sein
[16:20] <evaluate> I will look into that tomorrow :-)
[16:20] <nnnaji> :D - i'll be checking it out
[16:21] <evaluate> I didn't think there were people actually using a alpha, thought I'd have some more time until people switched. Appearently i was wrong :p
[16:31] <nnnaji> evaluate, many people love ubuntu alphas!!!
[16:35] <evaluate> I need a stable system for work, so I'm just checking them out in virtual boxes :-)
[16:55] <jcastro> evaluate: ask on ayatana-dev, ted is on holiday for the rest of the year so you'll likely not catch him on irc
[16:57] <evaluate> jcastro, ok. I have to go now, but I'll be bcak in a couple of hours and try my luck on ayatana-dev. thank you!
[16:57] <jcastro> no worries, good luck!
[17:09] <rbnswartz> DBO you around?
[17:10] <DBO> rbnswartz, yeah
[17:11] <rbnswartz> Okay I installed natty on my thumb drive to test my fix but the downloads that I was instructed to get to compile the source totalled to nearly 500MB is this all neaded?
[17:11] <rbnswartz> sorry needed
[17:13] <DBO> you are on a limited connection rbnswartz?
[17:14] <rbnswartz> occasional wifi but I can camp out at friends homes.
[17:16] <rbnswartz> but yes until monday I am on limited internet
[17:21] <rbnswartz> DBO ^^
[17:21] <DBO> unfortuantely coding kinda requires a good connection these days :/
[17:22] <rbnswartz> Yeah usuall every morning I have net connection.
[17:22] <rbnswartz> Is all 400mb required
[17:25] <rbnswartz> So long DBO I have to leave
[17:25] <DBO> cheers :)
[17:35] <ian__> I'd like to congratulate the Unity team on all the prgress they've made since the switch to compiz. Awesome job. I do have a question about the launcher and its autohide, though.
[17:40] <lamalex> ian__, what's the question
[17:42] <boulabiar> how to disable mt gestures in unity ?
[17:47] <dbarth> jcastro: hey jorge, have you heard of someone being interested in helping with the compiz bug here: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/684193
[17:48] <dbarth> jcastro: actually i realize that it's not linked to a unity bug, so the bitesize tag went unnoticed
[17:48] <jcastro> dbarth: it's ok, I'm about to start including compiz and indicators in the bitesize bits
[17:49] <jcastro> I can blog it now though, get it some pre-weekend attention
[17:49] <dbarth> i've linked it to unity anyway
[17:49] <dbarth> so now it shows up as well
[17:49] <jcastro> oh cool!
[17:49] <dbarth> i'd love to get more help on compiz
[17:49] <dbarth> sam is just struggling with a huge pile of bugs
[17:49] <jcastro> ah ok
[17:49] <jcastro> I am lunching now, I'll put together a call for help
[17:49] <jcastro> other than bitesizes what else does he need?
[17:50] <jcastro> he sent me a list earlier, I will include that as well
[18:07] <r2wj> Hello
[18:07] <r2wj> Can somebody comment on a ticket I opened please
[18:07] <r2wj> https://bugs.launchpad.net/hundredpapercuts/+bug/689468
[18:07] <r2wj> Just looking for some discussion about this
[18:38] <lamalex> cyphermox, is nm's appindicator going to get signal strength/security icons in the indicator menu?
[18:43] <cyphermox> lamalex, I would like to :)
[18:44] <cyphermox> appindicator doesn't seem to support that yet
[18:44] <lamalex> cyphermox, where is your branch for nm appindicator?
[18:44] <lamalex> I think it's supposed to snow this weekend so I might have some free time
[18:45] <cyphermox> ahaha
[18:45] <cyphermox> then you can ping me this weekend and maybe we can coordinate some work there :)
[18:46] <cyphermox> I was using a different branch for the initial stuff, but now it's a just a patch over the actual nm-applet packaging branch: lp:~network-manager/network-manager-applet/ubuntu.head
[18:49] <lamalex> cyphermox, the messaging indicator has those little circles with the counts in them
[18:50] <cyphermox> lamalex, in the patch I'm just bypassing code for building an NMNetworkMenuItem (or whatever it's called) and adding it to the menu, adding a standard GtkMenuItem instead
[18:50] <cyphermox> lamalex, yeah
[18:51] <cyphermox> lamalex, I also thought about doing something like this for signal strength numbers, but I really with it could be as close a possible as the standard non-indicator nm-applet rather than changing how it looks too much at the same time
[18:55] <lamalex> njpatel, know anything about this?
[18:55] <lamalex> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/687445
[19:22] <njpatel> lamalex, haven't seen that before
[19:22] <lamalex> pretty od
[19:22] <lamalex> d
[20:08] <Amaranth> DBO: Is nux-tools supposed to contain something useful?
[20:09] <DBO> no idea
[20:09] <Amaranth> All it has is /usr/lib/nux/unity_support_test
[20:09] <Amaranth> which nicely segfaults for me
[20:15] <evaluate> hello again
[20:17] <evaluate> I have sent a mail to<EMAIL_ADDRESS>(but I can't see it in the mailing list, nor did I receive any reply that the message was received successfully). Anyway, I just wanted to say that I only saw that last message from the list after I have sent the mail
[20:18] <evaluate> so if the mail actually belongs on the ayatana list, rather than the ayatana-dev list, I would like to ask someone to please move it there
[21:48] <Amaranth> eep, seems the last release of unity for the year is going to be a rather annoying one :/
[21:49] <Amaranth> menus only appear when I put my mouse on the panel :(
[21:49] <jamalta> Amaranth: i was seeing that issue.. what happens when you click on some blank space in the desktop?
[21:49] <Amaranth> and someone disabled fade so menus are crazy flickery now too
[21:49] <jamalta> mind you, unity is completely screwed for me at the moment :)
[21:49] <Amaranth> jamalta: I get no app name and menus still appear on hover
[21:50] <jamalta> is this the last work day of the year for canonical?
[21:50] <jamalta> s/this/today
[21:51] <Amaranth> jamalta: I dunno what the Canonical folks in general are going but I know it was seb128's last day for the year and he kept saying it was the last unity upload for the year
[21:51] <Amaranth> s/going/doing/
[21:51] <jamalta> ahh
[21:52] <jamalta> well, i'm trying to test to see if i experience your issue too.. just need to do an update
[21:52] <jamalta> ooh, grub's all purple now :)
[21:52]  * Amaranth tries to think
[21:52] <Amaranth> I think njpatel does the panel
[21:52] <jamalta> well, if seb128's last deploy is today then there won't be much we can do, unfortunately :)
[21:53] <Amaranth> Yeah, I only have compiz upload rights so I can't sneak any unity fixes in
[21:53] <jamalta> Amaranth: but you can push a merge proposal and ask someone like DBO to do so ;)
[21:53] <seb128> njpatel will be around next week I think
[21:53] <seb128> chrisccoulson and kenvandine as well
[21:54] <kenvandine> njpatel won't be
[21:54] <jamalta> well compiz is loading for me now!
[21:54] <jamalta> but unity isn't
[21:56] <seb128> kenvandine, ok
[21:56] <seb128> jamalta, the unity session doesn't start?
[21:56] <jamalta> Amaranth: ah ignore my rambling, i forgot i was using the daily ppa
[21:56] <seb128> is that natty?
[21:56] <jamalta> seb128: ignore me, i'm running the daily
[21:56] <seb128> ok
[21:56] <seb128> natty has just been updated you can switch back to that
[21:56] <jamalta> the error doesn't seem to occur in trunk so it must've been fixed already
[21:57] <kenvandine> brb, session restart
[22:09] <nmarques> anyone know if nux builds with libpng14 ?
[22:34] <toros> hi
[22:35] <toros> I've just filled a bugreport on Launchpad: https://bugs.launchpad.net/unity/+bug/691741
[22:35] <toros> do you need any further information regarding to this bug?
[22:40] <tareth> hmm chromium maximizes just fine for me right now
[22:40] <tareth> might be because I haven't upgraded at all today though
[22:41] <Amaranth> toros: thunderbird is going it too :/
[22:41] <Amaranth> but oddly not firefox, perhaps it's because I have libnotify-mozilla in thunderbird
[22:42] <toros> tareth: only unity 3.2.8 is affected, 3.2.6 isn't
[22:42] <Amaranth> oh actually chromium is just maximizing into the panel, I don't get duplicated titlebars
[22:43] <tareth> toros, I'm using the latest revision from source, so I'm already at 3.2.8
[22:43] <Amaranth> maybe it's because of autohide
[22:43] <Amaranth> nope, even with autohide it doesn't happen to me
[22:44] <Amaranth> although autohide makes the combined panel/decoration look ugly
[22:45] <Amaranth> ok, I get it with thunderbird even without libnotify-mozilla
[22:45] <toros> Amaranth: to reproduce the bug "use system title bar and borders" option in chromium should be turned on, and you should start chromium maximized
[22:45] <Amaranth> yeah, did that
[22:45] <Amaranth> oh, start maximized, hmm
[22:45] <toros> so opening a new window, or just maximizing it doesn't trigger the bug
[22:46] <Amaranth> yep, starting maximized does it
[22:46] <Amaranth> confirming bug
[22:46] <tareth> yeah I'm dumb, must've skimmed over that bit in the bug report.
[22:47] <Amaranth> toros: It's _every_ application
[22:47] <Amaranth> Start maximized == broken
[22:47] <toros> Amaranth: I'll check it
[22:48] <Amaranth> thunderbird is just extra broken, it doesn't work right even when not started maximized
[22:49] <Amaranth> I just confirmed nautilus, gedit, firefox, thunderbird, and chromium do it
[22:49] <toros> yepp, I've just reproduced it with gedit... altough the behaviour is a little bit different... because unmaximizing gedit, and then maximizing it again solves the issue
[22:50] <tareth> and system monitor. I think a more interesting question would be: can we find an application where this _doesn't_ happen?
[22:50] <toros> but not with chromium
[22:50] <toros> in chromium, I have to open a new window
[22:50] <toros> so there is a little difference in chromium and all the other apps
[22:51] <Amaranth> tareth: Well, we've just covered GTK+ apps, XUL apps, and custom/GTK+ apps
[22:51] <Amaranth> they all do things a little differently with the bug but have that same base problem
[23:10] <toros> well, I think I am going to sleep
[23:10] <toros> thank you guys for investigating this bug
[23:10] <toros> good night
[23:18] <coz_> hey guys... just noticed  that  the close,min,max buttons are now on the  upper panel..and no window decos...is this expected?
[23:19] <coz_> also notice that going to classic gnome there are no File Edit View  menus on the applications
[23:24] <lamalex> coz_, they /should/ be in the panel
[23:24] <lamalex> though honestly I'm not sure as I haven't used
[23:24] <coz_> lamalex,  yeah but they dont appear on classic gnome
[23:25] <coz_> I'll test again later,,, someone is trying to convince me to go to debian :)


[03:43] <milk> http://awn.planetblur.org/index.php?shard=forum&action=g_reply&ID=1836&page=1&isLive=true - see the last comment. bless.
[04:03] <CensoredBiscuit> hello
[04:05] <CensoredBiscuit> milk, that sounds like something my girlfriend would do.
[17:03] <nhandler> So, I'm still trying to find some time to re-write that Submitting to the Fridge wiki page in bullet/wiki format instead of the way it is now. If anyone has some time, I would really appreciate the help
[17:05] <holstein> nhandler: i need to post a meeting there
[17:05] <holstein> and i was reading about how to do it
[17:05] <holstein> nhandler: ping me if i can do anything to help
[17:05] <nhandler> holstein: What do you mean? Add a meeting to the calendar?
[17:06] <holstein> nhandler: ubuntustudio IRC meeting
[17:06] <nhandler> holstein: https://wiki.ubuntu.com/Fridge/Calendar
[17:06] <holstein> im having a hard time conveying the meeting time properly to them
[17:06] <holstein> i was going to use the frige
[17:07] <nhandler> holstein: And https://wiki.ubuntu.com/Fridge/Submit is the page I need some help with
[17:07] <holstein> nhandler: yeah, thats not the one i was thinking of
[17:07] <holstein> either way
[17:08] <nhandler> holstein: The first link explains how to add events to the fridge calendar
[17:08] <holstein> i'll be free in a few hours
[17:08] <holstein> ping me if i can do anything


[14:50] <XioNoX> hi!
[19:00] <XioNoX> hi!
[19:00] <Jazzva> hey XioNoX
[19:00] <XioNoX> just on time ?
[19:00] <Jazzva> yep, still didn't officially start
[19:01] <Volans> Hi all
[19:01] <asac> hi!
[19:01] <Jazzva> hey, hey
[19:01] <asac> i think gnomefreak and fta wont make it.
[19:02] <asac> ok. agenda is https://wiki.ubuntu.com/MozillaTeam/Meetings
[19:03] <asac> i pushed "firefox 2 archive removal" to top ;)
[19:03] <asac> because mdke is blocked on it
[19:03] <asac> mdke wants to cleanup ubuntu-docs and remove all those complicated alternatives
[19:04]  * mdke nods
[19:04] <asac> which where introduced initially to all localized homepages
[19:04] <asac> s/where/were/
[19:04] <mdke> I'm right that firefox doesn't use those alternatives anymore right?
[19:04] <asac> mdke: yes. firefox without ubufox has the official mozilla homepage
[19:04] <Volans> asac: actually in FF3 how the localized Start Pages are managed?
[19:04] <asac> ubufox uses his own mechanism to detect the language
[19:05] <mdke> and whether the user is online/offline
[19:05] <asac> Volans: ubufox uses the preferred language and finds the right page automatically
[19:05] <asac> note: this is only an issue for the "offline" page. the online page uses the same "preferred language" on the webserver side
[19:06] <Volans> yes, I know
[19:06] <Volans> so ubufox have the translated page itself or open the one provided by the ubuntu-doc package?
[19:06] <asac> Volans: does this clarify a bit how it works?
[19:07] <mdke> Volans: the latter
[19:07] <asac> Volans: right. the code is http://bazaar.launchpad.net/~asac/ubufox/main/annotate/110?file_id=startpage.html-20080411000353-l3fxb4oqnnv18uwx-1
[19:07] <Volans> ok, thanks
[19:07] <mdke> ok, back to the agenda item - what are the issues over removing firefox-2?
[19:07] <asac> 7-36
[19:07] <asac> i think the only issue i can see would be that some extensions are not available
[19:08] <asac> thats true for addons.mozilla.org, but what is more important here is that - afaik - we also have some extension packages
[19:08] <asac> which then would need to be removed
[19:08] <asac> Jazzva: do you know how many are left?
[19:08] <Jazzva> I think there might be few of them... 2-3
[19:09] <Jazzva> asac, I'll check them after the meeting
[19:09] <asac> http://paste.ubuntu.com/46938/
[19:09] <asac> thats the list of rdepends
[19:09] <asac> ok.
[19:09] <asac> so would be be ok in case there is really an extension that still doesnt have 3.0 support?
[19:10] <Jazzva> huh?
[19:11] <asac> can we decide whether we will remove firefox-2 without looking at the extension list?
[19:11] <Jazzva> those that don't have ff-3.0 support would be removed. there are only 2 or 3 which don't support ff-3.0, iirc
[19:11] <asac> or should we postpone decision based on what extension packages we find are not upgradable
[19:11] <asac> Jazzva: right. maybe those even have new upstream version
[19:11] <Jazzva> yep... I'll go through the list to see...
[19:11] <Volans> asac: but removing FF2 means that a user cannot still install it via apt?
[19:12] <asac> Volans: yes.
[19:12] <asac> Volans: but its outdated and we wont be able to provide security support
[19:12] <Volans> of course
[19:13] <asac> ok. so firefox-2 will most likely be removed?
[19:13] <Volans> in this case I think that the extension compatibility checks is not fundamental, is an "obsolete" version of a program
[19:13] <asac> can we say that or does anyone object?
[19:13] <Jazzva> fine with me...
[19:13] <fta2> i agree (drop ff2)
[19:13] <asac> good.
[19:13] <mdke> yay
[19:13] <asac> [ACTION] remove ffox 2 from archive as well as extensions that cannot be upgraded
[19:14] <mdke> perhaps someone could poke me when that is done
[19:14] <mdke> or nudge, whatever is preferred
[19:14] <asac> mdke: do you have any deadline?
[19:14] <mdke> asac: nope, although I wouldn't want to do anything too close to release, in case I break a path or something
[19:15] <asac> mdke: in worst case i would suggest that you remove the alternatives. if people complain you can point them that mozillateam will remove that package anyway
[19:15] <asac> mdke: so imo you can just go ahead. or do you see any problems with that?
[19:15] <mdke> ah ok. If there will be no possible further upload of mozilla-firefox-locale-all, then I can remove the alternatives now
[19:15] <asac> mdke: have you asked Riddell about konqueror?
[19:15] <asac> mdke: right. those will be removed for sure
[19:15] <mdke> asac: I tried konqueror, it does it's own thing. And I posted to -devel, but I might ask him too to be sure
[19:16] <asac> mdke: right.
[19:16] <asac> ok moving on?
[19:16] <asac> [TOPIC] abrowser rdepends transition
[19:17] <asac> abrowser has its own metapackage which basically means that packages that currently depend on firefox cannot be installed with abrowser
[19:17] <asac> so what we need to do is to look at all rdepends of "firefox" package. and add a | abrowser there
[19:17] <asac> firefox-3.0 rdepends should be fine though and dont need any action
[19:18] <asac> fta: you think you have time to help here? e.g. uploading a batch of universe packages? should take like 2 minutes for each package - though there is always the risk that an upload might suddenly not build anymore ... but we would like to know about them anyway
[19:18] <fta> agreed
[19:19] <fta> asac, it's simpler than the other project so yes, i should able to help here
[19:19] <fta> +be
[19:20] <asac> fta: i think we could just go through the list and if we work together it should take 1h or so
[19:20] <Volans> asac: I can help with some extensions if you want (like mine and others of needed)
[19:20] <asac> fta: so when you think you have 1h time just ping me and we can upload everything
[19:20] <fta> asac, oh, you want to do that manually ?
[19:20] <asac> fta: well. i think it just takes 1h or even less
[19:21] <fta> ok
[19:21] <asac> not sure if we want to develop something
[19:21] <asac> Volans: thats good. extensions need be updated too
[19:21] <asac> most likely we could go through all branches and add firefox everywhere
[19:22] <asac> err abrowser ;)
[19:22] <fta> asac, I'll sure ping you when i have some time
[19:22] <asac> [ACTION] asac and fta to add abrowser to all firefox rdepends and upload; everyone to help updating extension branches
[19:23] <asac> [TOPIC] Mozilla Freeze Exceptions
[19:23] <asac> is there anything we want to get in that needs a freeze exception?
[19:24] <Volans> all those rebuilding in order to add abrowser need some exception?
[19:24] <asac> Volans: no.
[19:24] <fta> we discussed ff3.1 already, is it still a no-go ?
[19:24] <asac> Volans: those are bugs ... not a feature so can be fixed all the time
[19:24] <Volans> right
[19:25] <asac> fta: not sure. my idea is to say that in case 3.1 beta is released before intrepid we should upload it
[19:25] <fta> mozclient: i want to extend it a little bit so we can put project files inside packages instead of m-d
[19:25] <asac> but i am open to other ideas ;)
[19:25] <Jazzva> asac, will we upload extensions that have updates, if the version we currently have only support ff2?
[19:25] <fta> it should help downstream
[19:25] <asac> Jazzva: yes. we can surely provide exceptions for those
[19:26] <asac> fta: thats ok. cant that even be sold as a bug?
[19:26] <Jazzva> cool :)
[19:26] <fta> asac, if someone files one, sure :)
[19:26] <asac> fta: most likely the currently supported packages will still be maintained in moclient?
[19:26] <asac> fta: ok. we can get kgoetz to file one i think
[19:27] <asac> fta: but in the end i dont really mind if we have a bug or not
[19:27] <Jazzva> asac, fta: I read something about wmmode being fixed in some newer ff release. did we upload that?
[19:27] <asac> fta: its just that if we release it as 0.10.1 its a bug fix release ;)
[19:27] <asac> Jazzva: whatis wmmode?
[19:27] <asac> transparent (for plugins)?
[19:27] <fta> asac, possible, i'll find a way to accommodate both (ie, files inside packages preferred over the ones in m-d)
[19:28] <asac> fta: right. for me that sounds like a bug and definitly doesnt need an exception ... we should just try to keep the diff minimal - if possible at all
[19:28] <asac> but i think the change shouldnt be intrusive
[19:28] <Jazzva> asac, I think it's a windowless mode for flash (and maybe other plugins). Firefox had a bug with it, which caused a lot of crashing before, but now it should be fixed
[19:28] <fta> Jazzva, it's fixed in 3.0.2 iirc
[19:29] <Jazzva> ok, just wanted to check if we uploaded that fix...
[19:29] <asac> Jazzva: are you using mozillateam firefox build?
[19:29] <fta> so it should be in since yesterday
[19:29] <Jazzva> asac, yes
[19:29] <asac> that should be 3.0.2
[19:29] <asac> fta: huh?
[19:29] <asac> fta: did they commit to 3.0.2 ?
[19:29] <XioNoX> The last build in ppa for hardy, don't work well with flash
[19:29] <fta> didn't they ? i didn't check
[19:30] <asac> i presumed that they were doing quality assurance ;)
[19:30] <fta> ok, so it's still not in (oops)
[19:30] <asac> fta: not sure. in case it landed in 3.0.3 we should try to cherry pick it
[19:30] <asac> for sure
[19:30] <Jazzva> asac, fta: http://blogs.adobe.com/penguin.swf/ 3rd blog post, that's where I read about it...
[19:30] <XioNoX> npviewer.bin keep crashing
[19:30] <asac> as 3.0.3 might be after intrepid and everyting that can mak eplugin crashes less likely is high-prio for us i think
[19:30] <asac> XioNoX: on amd64?
[19:31] <asac> XioNoX: that is libflashssupport which is still in ia32-libs ... -> that needs to be removed
[19:31] <Jazzva> asac, fta: Also here... http://blogs.adobe.com/penguin.swf/2008/07/addessing_wmode_crashes.html
[19:31] <asac> [ACTION] file a bug about removing libflashssupport from ia32-libs
[19:31] <fta> asac, no, it has been committed upstream before 3.0.2, so 3.0.2 should be fine, in fact, people already reported that the 3.0.2~cvs version in my ppa was ok
[19:31] <asac> ^^ anyone wnats to do that?
[19:31] <asac> fta: ok good.
[19:31] <asac> fta: maybe thats why i dont see it here ;)
[19:32] <asac> XioNoX: can you try to manually remove libflashsupport.so and see if the crashes become less regularly?
[19:32] <Jazzva> asac, I can file a bug... that shouldn't be too much time-consuming... (exams)
[19:32] <asac> ;)
[19:32] <asac> Jazzva: thanks.
[19:32] <Jazzva> np
[19:33] <asac> ok ... i think we still can grant exceptions on demand.
[19:33] <asac> fta: 3.1 in intrepid. you think we could keep it updated for 6 month? (e.g. stable support)
[19:33] <asac> most likely people running that will upgrade to intrepid+1 anyway ... so saying that we provide updates for 6 month should be a good compromise
[19:34] <asac> fta: alpha 2 was just released right?
[19:35] <fta> the way i work now is to ppa build everything for intrepid and hardy so if someone agrees to test it, i can continue to build it for intrepid when it is released
[19:35] <asac> fta: ok cool. i can also help in time you really dont have time
[19:35] <Volans> asac: Alpha 2  19 August | Beta 1  Feature freeze. source: https://wiki.mozilla.org/Firefox3.1/Schedule
[19:35] <asac> so with that i would like to see 3.1 in intrepid ;)
[19:36] <asac> fta: we should just take care that we get the branding right (e.g. use the branding upstream uses)
[19:36] <asac> and dont suggest that its 3.1 final in the menu
[19:36] <Volans> damn... that page was not updated after august 24, sorry
[19:37] <asac> Volans: i think alpha2 was released last week or something
[19:37] <asac> but i might be completely worng
[19:37] <Volans> in the nightly builds I see 3.1b1pre
[19:38] <fta> I still use "Minefield 3.1 Web browser" for the desktop file, but i wanted to jump to "Firefox 3.1" once b1 is out like we did for 3.0
[19:38] <asac> hmm http://www.mozilla.org/projects/firefox/3.1a2/releasenotes/
[19:39] <asac> fta: right. but alpha2 should be Shiretoko 3.1 Web browser i think
[19:39] <fta> in fact, i remember upstream did that, ie start calling 3.0 firefox instead of granparadiso starting to b1
[19:39] <asac> yep.
[19:39] <asac> i think we should use whatever they use. and thats shiretoko i guess for alpha2
[19:39] <fta> sure, fixed releases are call Shiretoko 3.1, hg snapshots are called Minefield
[19:39] <fta> called
[19:39] <asac> ah
[19:39] <asac> ok
[19:40] <asac> fta: but snapshots are always called minefields ... arent they?
[19:40] <fta> today yes, it's just a flag
[19:40] <asac> its just that b1 b2 and such are called "firefox" ;)
[19:40] <asac> ok cool
[19:41] <asac> fta: ok. then maybe upload the build that is supposed to go to intrepid and let me test. then we can just upload and hope that archive admin will except that we (the mozillateam) granted an exception for that ;)
[19:41] <asac> [ACTION] fta and asac try to get 3.1 alpha2 into the archive
[19:42] <asac> [ACTION] team report
[19:42] <asac> we had one for the extension team done by Jazzva :) ... great!
[19:43] <fta> alpha2, ok. should be easy. i guess we want it with abrowser-3.1 right, not as it was a few weeks ago in my branch ?
[19:43] <asac> i would really like to write a complete team report. and do that regularly.
[19:43] <Jazzva> asac, I should prepare one for august...
[19:43] <asac> usually i face the problem that i dont know what was done
[19:44] <fta> we may have SEAMONKEY_1_1_12_RELEASE late
[19:44] <asac> and wonder if we could have a wiki page or even a bot in irc channel where we can add all small actions
[19:44] <asac> we did
[19:44] <asac> so we can better do a report at the end of the month
[19:44] <fta> may as i'm not sure it's out yet or still in QA upstream
[19:45] <Jazzva> asac, IRC bot would be cool... it's easier to say "action: something", than editing a wiki page :)
[19:45] <asac> fta: true. but it doesnt require an exception because its also a security release
[19:45] <asac> Jazzva: yeah "done: i did this" ;)
[19:45] <asac> anyone knows a good bot?
[19:45] <asac> or just an irssi perl script maybe?
[19:46] <fta> grep :)
[19:46] <Seveas> a small perlscript hooked to editmoin? :)
[19:46] <Jazzva> it would be great if it could be done automatically, but i don't have an idea how to do that (collect all the information, if all the information is available)
[19:46] <asac> Seveas: how would that work?
[19:47] <Seveas> asac, not knowing irssi very well, I'd guess something like: script parses all lines, if it matches [action] oslt, it would add it to a wikipage via the editmoin tool
[19:48] <asac> Jazzva: well. i think what a list of a) uploads, b) commits and c) DONE: together should give a good picture for the one drafting the team report
[19:48] <asac> i think that it will need some manual editing and polishing anyway. its just that all the data would be in the right place
[19:48] <asac> Seveas: ah ok.
[19:49] <asac> so can we say that if you have done something (even its just a tiny task) just writing a short [DONE] ... line to the mozillateam channel would be ok?
[19:49] <Seveas> asac, a post-commit hook using editmoin, and a simple cronjob using launchpadlib that extracts commits/uploads will complete that report ;)
[19:49] <asac> Seveas: post-commit hook. how is that done in bzr?
[19:49] <Jazzva> asac, also not to over-use done tag. we don't want very log month reports, right? :)
[19:50] <asac> Jazzva: true.
[19:50] <Jazzva> s/log/long/
[19:50] <Seveas> asac, #bzr knows, I don't :)
[19:50] <asac> Jazzva: i think DONE for commits and uploads shouldnt be done
[19:50] <asac> only for things that cant be tracked otherwise
[19:50] <asac> (e.g. like reworking wiki, etc.)
[19:50] <Jazzva> mhm
[19:51] <asac> commits and uploads should be gathered automatically ... so a done wouldnt really be needed
[19:51] <asac> ok ... ill note
[19:53] <asac> [ACTION] asac to write down how to get items into the monthly reports and send that to mailing list/wiki
[19:53] <asac> i think i have enough ideas now how to do that ;)
[19:53] <asac> if anyone else wants to draft this, feel free to high-jack that item from me ;)
[19:53] <asac> ok ... i think we should skip the intrepid status for now
[19:54] <asac> or is there anything more general about our state for intrepid that hasnt been covered above?
[19:54] <asac> [TOPIC] check status of automatic update for extensions
[19:55] <fta> i guess there's no need to discuss about chrome, there's nothing usable for us so far
[19:55] <asac> Jazzva asked what the status auf the auto updates of extension branches is
[19:55] <asac> fta: right. i think its not relevant for intrepid
[19:55] <asac> fta: we should use PPAs until we get something usable
[19:56] <fta> ok
[19:56] <XioNoX> back
[19:56] <Jazzva> yes... iirc, fta's check-extensions script is pretty much usable, we have written a process how to do that, so now we only need to get it working, right?
[19:56] <asac> but we should bug jcastro about the chromium "master" project
[19:56] <XioNoX> connexion problems :(
[19:56] <asac> XioNoX: welcome back ;)
[19:56] <asac> XioNoX: topic is [TOPIC] check status of automatic update for extensions
[19:57] <XioNoX> ok, thx, I'll read the log later
[19:57] <asac> Jazzva: i think we are pretty much stuck right now
[19:57] <Jazzva> asac, stuck with?
[19:57] <asac> Jazzva: stuck aka "we only have check-extensions"
[19:58] <asac> and we have no plan what steps are next ;)
[19:58] <asac> but i would like to change that
[19:58] <fta> mostly my fault. I'm sorry, lack of time :(
[19:58] <Jazzva> hmm, I think we have a plan :). download newer extensions, unpack, push to branch, notify maintainer :)
[19:58] <asac> fta: thats ok. i think the idea was to write something quite powerful
[19:58] <fta> yes
[19:58] <asac> maybe we can find a less work intensive solution
[19:58] <asac> what would be needed to get something useful?
[19:59] <asac> Jazzva: right. but there are a few undefined variables in that game
[19:59] <asac> 1. where do we configure branches that are auto-updated?
[19:59] <Jazzva> branch names and how extension is packaged...
[19:59] <asac> actually 1. where and how do we configure branches that are auto-updated?
[20:00] <asac> 2. what upstreams do we support? xpi-med-(un)pack only?
[20:01] <asac> 3. how do we notify maintainer about a pending merge (i think that would be the launchpad merge feature, but we need to find out how to do that from a script)
[20:02] <asac> ok. so we have check-extensions
[20:02] <asac> now we need a download script i gues
[20:02] <asac> e.g. download xpi for extension A with version B
[20:03] <asac> fta: we get the latest available version for extensions through check-extension right?
[20:03] <Jazzva> yep... afaics, it should determine if it's packaged from xpi, or branched from cvs
[20:03] <fta> asac, yes, those in amo
[20:04] <asac> ok ... that means once we have the download script, we just need a high level script that goes through all xpi branches then downloads the latest xpi and uses med-xpi-unpack
[20:04] <asac> and then would have a script we could run to auto update?
[20:04] <asac> oh ... we also need a script to ask for merge
[20:05] <asac> fta: have you looked at launchpad 2.0 rpc api?
[20:05]  * asac wonders if they have a "merge request" operation
[20:05] <fta> not deeply enough yet, i just read blog entries about it.
[20:05] <asac> ok.
[20:06] <fta> seems a WIP to me
[20:06] <asac> [ACTION] write a script "download-xpi-from-amo <extension-name> <version>"
[20:07] <asac> [ACTION] write a script "request merge <branch1> <branch2>"
[20:07] <Volans> sorry, I have to go now, but I'm interested in the automatic update of extension task, I will read the log and I would like to help doing something
[20:07] <fta> the 2nd a feature already in LP
[20:08] <fta> +is
[20:08] <asac> [ACTION] write a high level script that assembles check-extension, download-xpi-from-amo and request-merge to automatically update upstream branches for extension branches that use the med-xpi orig structure
[20:08] <Jazzva> we also have https://wiki.ubuntu.com/MozillaTeam/Extensions/LargeScaleMaintenance , we could use those ideas
[20:08] <asac> fta: right. but we still need to programmatically trigger that feature i think
[20:08] <Jazzva> (branch naming and stuff)
[20:08] <fta> ok
[20:08] <fta> should be trivial
[20:09] <asac> Jazzva: yes. thats the document we should keep in mind when doing this
[20:09] <asac> but imo we should rather try to do something incomplete than do nothing, because its too much work to do at one time
[20:09] <Jazzva> i agree
[20:10] <asac> anything else on this topic?
[20:10] <Jazzva> i think we're done with it
[20:10] <asac> great.
[20:11] <asac> [TOPIC] anything else ;)
[20:11] <asac> maybe one more announce: fta is MOTU now ;)
[20:11] <fta> :)
[20:11] <Jazzva> yay, fta :D
[20:12] <fta> i have yet to upload something ;)
[20:12] <asac> fta: yeah ;) ... lets do the abrowser transition ;)
[20:12] <fta> sure
[20:13] <asac> oh. i have one more thing. i think we should look over all extensions and see if they a) have been updated in this cycle at all or b) if they can be updated.
[20:13] <asac> but i think that check-extension probably isnt enough?
[20:13] <asac> fta: does check-extnesions already check against intrepid?
[20:14] <Jazzva> asac, i can help with that too... i'll be totally free from 20-24 september
[20:14] <fta> it does your current dist
[20:15] <fta> Jazzva, lucky guy ;)
[20:15] <asac> Jazzva: great. is the list on the wiki page more or less complete?
[20:15] <asac> or are there still extensions in the archive that we dont track there?
[20:16] <Jazzva> asac, more or less... I think there might be few more that aren't maintained in bzr, and not tracked on the wiki
[20:16] <asac> ok
[20:17] <asac> do we explicitly add them to that list (and hence making them MT maintained) or is that ok to leave them in the limbo until we hear from them (e.g. because people point to bugs et al)
[20:18] <fta> most come from debian
[20:18] <asac> i think having a complete list would be nice. but its not really high prio from what i can tell. especially because most of those not listed on that page come from debian
[20:19] <Jazzva> well, I think we are still diverged from debian regarding extensions...
[20:19] <Jazzva> So, I think most of them are listed there... we don't get that much extensions...
[20:19] <Jazzva> asac, which reminds me... are we gonna get mozilla-devscripts to debian?
[20:20] <asac> good point. someone should file a RFP ;) ... then we can upload it with that bug number in changelog
[20:20] <Jazzva> great :)
[20:20] <asac> [ACTION] file RFP for mozilla-devscripts and get it into debian archive
[20:20] <fta> remember it's a native package
[20:21] <asac> fta: is that a problem?
[20:21] <asac> or do you mean that RFP is the wrong wording ;)?
[20:22] <fta> if we need to tweak it for debian, then native is probably not good
[20:22] <asac> [ACTION] asac to find out if initial uploads to debian strictly require a wnpp bug
[20:22] <asac> fta: hmm. we can have a branch ... which usually should be the same i think
[20:22] <asac> fta: we could handle debian as downstream
[20:22] <asac> e.g. merge down
[20:22] <fta> lol
[20:23] <asac> fta: ok. could you bake an initial release of latest mozilla-devscripts with a debian1 version?
[20:23] <asac> e.g. 0.10debian1
[20:23] <asac> hmm
[20:24] <fta> we have to blacklist it
[20:24] <asac> fta: actually i think we need to use ubuntu1 ... otherwise it will get auto-synched ;)
[20:24] <asac> [ACTION] blacklist mozilla-devscripts for auto-syncher/MoM
[20:25] <fta> 0.10~debian1 ?
[20:25] <asac> [ACTION] create debian branch with initial mozilla-devscript debian1 version
[20:25] <asac> fta: i think we should use 0.10debian1
[20:25] <fta> so debian is always behind ?
[20:25] <asac> it would be similar to what we do with debian packages
[20:25] <asac> when ubuntu is downstream
[20:25] <fta>        apt | 0.7.14ubuntu6 | http://archive.ubuntu.com intrepid/main Sources
[20:25] <asac> so imo the same logic should apply if debian is downstream
[20:26] <asac> fta: but i dont mind. actually we could also maintain it in debian and synch it from there to ubuntu
[20:26] <asac> fta: you can decide what you prefer
[20:26] <fta> but with 0.10debian1, debian will be ahead of us, then the merge/sync bot needs to blacklist it
[20:27] <asac> fta: right. thats what i mean. either we should use ubuntu1 i ubuntu or we should blacklist it
[20:27] <asac> fta: maybe ~debian1 is also an option to consider
[20:27] <asac> but i think we should either blacklist or maintain in debian
[20:28] <fta> i prefer the blacklist option, as i'm only on the debian side ;)
[20:28] <fta> -debian+ubuntu
[20:28] <asac> ok
[20:28] <asac> fta: we can add you as maintiner for the package in debian ... so you can directly upload there
[20:29] <asac> but lets start in the way you suggested
[20:29] <asac> ok, so the two actions above correctly reflect what we just discussed here right?
[20:29] <fta> yes
[20:29] <asac> 21:20 < asac> [ACTION] file RFP for mozilla-devscripts and get it into debian archive
[20:30] <asac> < asac> [ACTION] asac to find out if initial uploads to debian strictly require a wnpp bug
[20:30] <asac> < asac> [ACTION] blacklist mozilla-devscripts for auto-syncher/MoM
[20:30] <asac>  < asac> [ACTION] create debian branch with initial mozilla-devscript debian1 version
[20:30] <fta> ok
[20:30] <asac> those are the four actions related to mozilla-devscripts ;)
[20:30] <asac> ok ... anything else?
[20:30] <asac> otherwise i guess ubottu just told me that the meeting is over ;)
[20:31] <fta> fine with me, nothing more to add
[20:31] <asac> Jazzva: XioNoX: Volans ?
[20:31] <Jazzva> same here...
[20:32] <asac> ok. thanks! anyone wants to write minutes or is that supposed to be me this time? ;)
[20:32] <Jazzva> I can do it tomorrow, I think...
[20:33] <XioNoX> asac, nothing to add, exept if you have an idea of what i can do
[20:33] <Jazzva> see you in #ubuntu-mozillateam
[20:33] <asac> XioNoX: we have plenty of actions in this meeting
[20:33] <asac> we could look if anything suites you
[20:33] <asac> but lets talk about that in -mozillateam
[20:34] <asac> thanks all. nice meeting
[20:34] <XioNoX> ok good
[20:37] <fta> bye