[04:23] <pitti> Good morning
[13:15] <elfy> balloons: hi - not sure if you caught the earlier ping, but ubuntu, xubuntu and lubuntu at least still have this seat0 issue, I have found that it appears to only be a vm issue - but an issue nonetheless, I did bug 1366206 against lightdm for the moment, but I think it is a vbox bug atm
[13:15] <balloons> elfy, I did see and was going to ask thanks
[13:16] <elfy> just added a screenshot to the bug of the 3 vt's
[13:16] <elfy> given that we push people to test in vm's it'll need looking at I suppose lol
[13:20] <balloons> Ilm syncing today's iso to see what remains for me
[13:21] <elfy> :)
[13:21] <elfy> have fun
[13:21] <elfy> I did those tests with synced iso's 30 minutes ago
[14:22] <elfy> balloons: any luck with it?
[14:23] <balloons> synced, but haven't yet been able to try
[15:06] <balloons> elfy, I get the same issue
[15:06] <balloons> I can confirm
[15:09] <elfy> balloons: thanks - though I wish not ;)
[16:49] <balloons> knome, elfy did you meet yesterday to discuss the tracker?
[16:50] <knome> yes
[16:50] <knome> http://pad.ubuntu.com/trackers
[16:50] <knome> see that
[16:52] <balloons> knome, I'm getting info from stephane today so I should be able to review and update things.. :-)
[16:52] <knome> yep
[16:52] <elfy> nice
[16:52] <balloons> so I'll try and get your stuff landed as my first exercise of power :-)
[16:54] <knome> that's a start...
[16:54] <elfy> balloons: you got any idea who to prod about this vm no graphic issue? if it doesn't get looked at soon we'll be all over final beta
[16:55] <elfy> and with I'm wandering off for a bit
[16:56] <balloons> elfy, when you get back let's look at the bug together a bit more and see if we can come to a conclusion on what's failing
[16:56] <elopio> hello ubuntu-qa. Can I get a review here please? https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/autopilot-upstart_local_modules/+merge/232650
[16:57] <elfy> balloons: ok - I'll be about an hour or so
[18:10] <elfy> balloons: about when you are
[18:15] <balloons> elfy, your timing is good. let's roll
[18:15] <elfy> not sure if you have seen the old lightdm bug - but seems that xserver-xorg-video-vmware is affected by it
[18:16] <elfy> not used vmware for ~6 years so no idea :p
[18:16] <balloons> elfy, we should try this on qemu
[18:16] <elfy> nor that - only virtualisation I bother with is vbox
[18:18] <balloons> elfy, I suspect this is still a vm driver thing
[18:18] <elfy> yea - I'd agree with that
[18:19] <balloons> so actually I'm not sure there's much more to go after here
[18:19] <elfy> you can try with qemu?
[18:21] <balloons> elfy, ok, so I can get the livesession to boot if I start it manually.. That's the same as you right?
[18:21] <elfy> yep
[18:22] <elfy> but sometimes get xfce session instead of xubuntu
[18:23] <elfy> balloons: but prior to starting manually you get the CanGraphic=no?
[18:24] <balloons> elfy, yep
[18:25] <elfy> ok - so vbox/vmware and qemu all fail the same - with I assume different xorg drivers
[18:25] <balloons> could just be a udev issue, which is messed up currently
[18:25] <elfy> yep
[18:27] <elfy> not sure what to report this against - I couldn't report it against vbox - use the prop. one :)
[18:32] <balloons> elfy, I assume on boot we're getting xserver-xorg-video-vesa
[18:33] <balloons> so that's where I would place the bug
[18:34] <elfy> aah yes - I did check the logs once I got in
[18:34] <elfy> I'll change the one I reported the other day to affecting that
[18:35] <balloons> excellent
[18:35] <elfy> there done :)
[18:36] <balloons> elfy, it would be useful to have the logs for that tho
[18:36] <elfy> I'll boot vm and attach anything I can think of :D
[18:37]  * balloons is checking what apport pulls now
[18:37] <elfy> doing that now or I will forget
[18:37] <balloons> you going to simply add the bug to https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1365336?
[18:37] <elfy> oh actually I could apport-cli ubuntu-bug foo-vesa I guess
[18:38] <elfy> dupe it ?
[18:39] <elfy> balloons: actually - add the -vesa package to that bug would be best perhaps
[18:39] <balloons> elfy, yes that's what I think
[18:40] <elfy> not sure I can add -vesa to that bug
[18:41] <balloons> done
[18:42] <elfy> ta - to do that is it the Also affects distribution/package button?
[18:42] <balloons> yes, and I duped your bug
[18:43] <elfy> ok cheers - just getting the logs from a vbox boot to add to it
[19:04] <elfy> balloons: attached as many logs as I could think of to 1365336 :)
[19:35] <balloons> elopio, re: https://code.launchpad.net/~nskaggs/ubuntu-calculator-app/ap-fix-missing-keypress/+merge/233534/comments/570815. I need to file a bug in autopilot as the click duration does not work on phablet devices.https://bugs.launchpad.net/autopilot/+bug/1366949. I also left a larger comment explaining my reasoning
[20:20] <elfy> balloons: seems that Laércio is on the case again - I shall wait to get a .rule to try somehow :p
[20:37] <balloons> knome, I don't see any proposed branches?
[20:37] <balloons> knome, lol, I see them now.. You just committed them
[21:01] <elopio>  balloons: that is https://bugs.launchpad.net/autopilot/+bug/1268782
[21:01] <elopio> fixed but not yet released.
[21:01] <balloons> elopio, you are ALWAYS one step ahead of me..
[21:01] <balloons> superherp
[21:02] <balloons> elopio, is the mp otherwise a-ok for you/
[21:02] <elopio> balloons: but why is the default click duration not enough for the calculator?
[21:03] <balloons> elopio, it's possible it's fine now that I fixed the issue with not waiting for the screen before pressing keys, but I think verifying the keypress is the better way to go
[21:03] <balloons> it seems to run faster now than before
[21:05] <elopio> balloons: the default on autopilot should simulate what a standard user does as close as possible. So if it doesn't work sometimes on the calculator it would mean either that it would fail for a default user or that the parameter needs and adjustment on autopilot.
[21:05] <elopio> that's why I don't like the workaround, it's not clear which one is happening.
[21:06] <balloons> elopio, you think checking for the keypress is a workaround?
[21:07] <elopio> balloons: I do. That must always happen when we call autopilot's click_object.
[21:07] <balloons> sadly we must also think about slow machines.. the tests run in an xvfb environment as well.. There is some input lag and the default is REALLY quick
[21:07] <balloons> elopio, click_object isn't going to check for any response, it's simply going to send a click
[21:08] <thomi> balloons: you think 100ms between key press and key release is 'really quick' ?
[21:08] <elopio> balloons: then I think it is a problem on autopilot.
[21:08] <elopio> and we need a combination of low level and autopilot tests to make sure that a mouse click fires the pressed signal.
[21:08] <elopio> if this is a standard button, that test must be on Qt upstream.
[21:09] <balloons> thomi, I think the issue is that we fire off 5 presses in 550 ms
[21:09] <balloons> it's possible to miss one in a quick fire sequence
[21:09] <thomi> balloons: so you're suggesting that there needs to be a pause _after_ the key press, which is a different issue to the touch_duration MP then
[21:10] <balloons> thomi, well I suppose I wouldn't argue that ap needs to change actually. But a real user certainly won't hit keys that fast. The test could stagger the key presses
[21:10] <elopio> balloons: yes, I didn't understand that. From your MP, that would mean to put a sleep after click_object, not between the press and release.
[21:11] <balloons> elopio, yes, that might be the issue.. I say might because I didn't try solving it that way
[21:11] <balloons> but I like my check much better than adding sleeps anywhere
[21:11] <thomi> otp - will get back to this when I'm done
[21:12] <veebers> elopio, balloons: Will getting elopios MP released (press_duration) help with this at all?
[21:12] <balloons> elopio, I do know the first keypress is lost because it fails to wait for the screen to come up. adding a wait_for.visible(True) fixed that.
[21:12] <veebers> (balloons I'm just taking a look at your MP now too :-) )
[21:13] <balloons> veebers, without his MP I have to press, sleep, release to get the press_duration, which was my original change
[21:13] <balloons> elopio, I think other keypresses get lost, but you could simply run trunk tests or check the dashboard to confirm or deny this
[21:13] <veebers> balloons: ok, well it should be a pretty simple release, if it will help I can get that in  motion
[21:14] <elopio> balloons: what I asked on your MP was for a clarification of why the default is not good enought. What you are doing actually corresponds more or less with what a user would do, that's taking into account the button UI feedback when it's pressed.
[21:14] <balloons> veebers, if I get my way however I don't need press_duration, lol :-) I'm checking the key state, but not sure I'll convince the others it's the way to go
[21:14] <elopio> that makes sense. I would be happy with that comment on the code. Just a little worried that it might be affecting users somehow.
[21:15] <balloons> does the comment do it justice? since you asked it's worth making sure the comment makes sense
[21:15] <veebers> balloons: ack, let me know if you need it urgently. It will be released in the near future but we can do it sooner if required
[21:15] <balloons> veebers, and yea, I finally got a free minute to fix that little functional test failure
[21:16] <veebers> balloons: ah cool, was just loading the MP
[21:16] <balloons> this has been the longest mp I've my life
[21:18] <elopio> balloons: I'm happy you took that autopilot branch instead of me :)
[21:18] <elopio> ballons taking the bullet for the team
[21:19] <balloons> lol.. it pushed me, all good stuff
[21:19] <elopio> balloons: about calc, yes, the comment makes sense. If you are not sure if it's needed or not, I would prefer to land the branch with a normal click_object and see how it goes.
[21:19] <veebers> balloons: yeah sorry part of that was me not reviewing in time :-P
[21:19] <elopio> balloons: but if you prefer to land it as is, I won't object.
[21:19] <elopio> the comment makes it clear in case somebody wants to go deeper and eventually remove it.
[21:20] <veebers> balloons: hey, put my mind at ease, what changes (if any) will need to happen within app acceptance tests with this change? i.e. have you tested against the cal. app?
[21:21] <balloons> elopio, there is a slowdown fix branch that is depending on this to land.. maybe it can be swapped back after. Still, I prefer this implementation for the reasons I mentioned above
[21:22] <elopio> balloons: then go forth and land.
[21:22] <balloons> I was somewhat forced into it because of the AP bug, but I prefer it to adding sleeps or tweaking press_duration
[21:22] <elopio> I'll leave my +1
[21:22] <balloons> elopio, ty sir
[21:23] <elopio> balloons, thomi, veebers: I'll report a bug on autopilot for the missing sleep after click argument.
[21:24] <balloons> elopio, well that's a bigger discussion I think. Do you think it should sleep by default after a click?
[21:24] <elopio> balloons: I think it should at least give you the option to do it. And ideally the default will be something close to what a user would do.
[21:24] <elopio> the second part is the hard one.
[21:24] <balloons> it might fix some of the random failures we see I suppose
[21:24] <veebers> elopio: perhaps I missed something, why should click have a sleep?
[21:25] <veebers> ah, this is between clicks?
[21:25] <balloons> but I'm not convinced AP should change for it
[21:25] <elopio> veebers: because if you call click_object two times in a row, it will do it a lot faster than a human could.
[21:25] <balloons> yes, we're discussing for instance the calc which started this. Currently the test can enter operations insanely fast compared to a human
[21:26] <veebers> hmmm
[21:26] <elopio> what do you think veebers? should it be autopilot's API, or the sleep should be added by a higher level loop?
[21:26] <balloons> but imho, the test should account for this and not the tool
[21:26] <balloons> I would argue you should check the UI for a response
[21:26] <balloons> no sleep
[21:27] <elopio> balloons: I think the response test is a low level QML test.
[21:27] <balloons> unless you wanted to stagger input to completely mimic a user's input speed
[21:27] <veebers> I don't think 'click_object' should have an pre/post sleep as it's a stand alone action, if it was 'click_objects' (i.e. plural) sure it would make sense
[21:27] <elopio> on autopilot you should just assume that if you click, the button receives the input and fires the signal.
[21:27] <veebers> elopio: I agree with you there
[21:28] <elopio> veebers: click objects makes sense only for calculator and osk, so I won't file the bug.
[21:28] <balloons> click_objects.. that's interesting
[21:28] <elopio> we can solve it on the higher level project.
[21:29] <veebers> right, if anything click_objects can start as a UUTK helper (as that's where it's used)
[21:29] <balloons> the osk is interesting thought
[21:29] <elopio> thanks for the review robotfuel
[21:35] <veebers> balloons: re: your datetime MP you'll need a packaging persons ack on the packaging changes (shouldn't be to hard, they're quite simple)
[21:37] <balloons> veebers, who do you suggest?
[21:37] <balloons> just anyone?
[21:37] <veebers> balloons: I've asked robru in the past, but any packaging person is fine (I'm not sure of that list of people off the top of my head though)
[21:38] <balloons> veebers, ok, :-)
[22:31] <thomi> hi guys - I'm back
[22:31] <knome> welcome back
[22:31] <thomi> what about having AP keep track of the last time it sent a click command, and delaying if that is < 100ms ago?
[22:31] <thomi> veebers: balloons, elopio ^^
[22:31] <thomi> that would keep the API clean, and mimic what a user would do
[22:32] <elopio> thomi: that works for me. My only concern would be how to define the right delay.
[22:33] <veebers> thomi: sounds nice and clean, I can't imagine it stepping on anyones toes either (i.e. I want a test that taps as fast as hell on this button)
[22:33] <thomi> elopio: 100ms seems reasonable. We can always land a conservative guess and tweak it if it causes problems
[22:33] <elopio> I agree.
[22:33] <thomi> we could even land a branch that just measures the gap and reports that statistic to a test attachment, but doens't do any sleeping
[22:34] <thomi> then, in phase 2, we could use that data to come up with a sensible value
[22:34] <thomi> but TBH, that sounds like a lot of work
[22:34] <thomi> I'd just land the first idea, myself
[22:34] <thomi> but I'll levae it in veebers hands.
[22:34]  * thomi needs coffee
[22:36] <veebers> elopio: do you mind filing the bug you mentioned earlier re between tap delays so we don't loose the conversation. The idea is sound, just needs to be scoped out and implemented
[22:36] <elopio> veebers: on it.
[22:36] <veebers> thanks :-)
[22:36] <balloons> interesting you all agree
[22:37] <elopio> veebers: you have some code to get information from click list --manifest
[22:37] <balloons> I guess I might be the lone dissenter on this
[22:37] <elopio> veebers: I need something similar. Is there a good place to put those helpers so we can all use them?
[22:38] <veebers> elopio: it depends on what you're needing :-) What are your requirements?
[22:38] <balloons> thomi, ofc you'll make it an optional arg. In theory it will have no effect on 99% of the running tests as they are rather unlikely to send taps that quickly
[22:38] <elopio> veebers: give the package id and receive the version number.
[22:39] <veebers> elopio: hmm, I thought that was there too, I'll take a look shortly and get back to you
[22:39] <elopio> veebers: oh, and I also need the directory
[22:50] <thomi> balloons: I wasn't going to make it optional - I missed some of the scrollback - want to tell me why you think that's a bad idea? I'm interested in dissenting opinions :)
[22:54] <balloons> thomi, so having a global wait on click if you will isn't nearly as concerning as a wait after each click. From elopio's perspective autopilot should clone the user as much as possible. That's an interesting thought, but I'm not sure autopilot as a tool has attempted to do that historically persay. That is to say, it's not tried to prevent you from shooting yourself in the foot
[22:59] <balloons> so I wouldn't dissent too much about a global wait on click; especially something so small as 100 ms. I suppose my concern there would be the inability to avoid having to wait 100 ms between each tap. No I don't have a use case for way, but I don't like arbitrary restrictions. And it's probably non-trivial to make the global wait be 0.. autopilot doesn't really have any global options..
[23:00] <elopio> balloons: I think that if you try to test something that requires you a really small amount of time between events and you use autopilot, you would be shooting yourself on the foot.
[23:00] <thomi> balloons: you are correct that we haven't tried very hard to stop people shooting themselves in the foot in the past, but I think that's a bad thing, and something I want to change
[23:01] <elopio> it has a lot of overhead, and you could do better with QML in that case.
[23:01] <thomi> I think that AP should, whenever possible, mimic the user - this is what sets us apart from squish, for example
[23:01] <elopio> and anyway, it wouldn't be hard to make the time between events configurable, if that's needed for a good reason.
[23:01] <balloons> elopio, thomi I'm in full agreement. Ok, so you recognize at least you are steering autopilot into that direction.
[23:01] <thomi> balloons: absolutely
[23:02] <thomi> balloons: and if someone every comes up with a use case for wanting faster clicks that fits in with the autopilot testing strategy, then we can look at making it configurable
[23:02] <elopio> +1. It should be user simulation. Not just task automation.
[23:02] <balloons> thomi, for my own sanity, if this was implemented at a method level, what's the harm in an optional arg?
[23:03] <elopio> having said that, selenium has a nice mode that runs the tests in cocaine mode.
[23:03] <balloons> elopio, lolololol
[23:03] <thomi> balloons: options are to be avoided at all costs. They make the API much harder to use, and introduce bugs
[23:03] <elopio> that's not really useful to get stable executions, but it's good to exercise the application and gather some interesting bugs.
[23:03] <balloons> I feel like python does them quite well.. althought in general I understand and agree conceptually
[23:03] <thomi> balloons: basically, it adds complexity where none is required
[23:05] <balloons> thanks for the discussion. . . +1 from me for the global wait
[23:05] <balloons> So elopio, when will we be tapping on the OSK for all input? :p
[23:06] <elopio> balloons: I hope to have all set by the sprint. Then we can hack an evening to make sure all apps are using it.
[23:07] <elopio> balloons: there's a big list of things to do. First, get the osk tests running on MPs and dashboard.
[23:07] <balloons> more UITK goodness
[23:07] <elopio> then, get the toolkit helpers working in a way that lets us enable the OSK one suite at a time.
[23:07] <balloons> yep, awesome. that aligns with my thoughts
[23:07] <elopio> and then enable them on all projects. I expect many troubles on this last step, because many tests assume too much.
[23:08] <balloons> we've gotten much better.. I feel like it won't be nearly as painful as you think
[23:08] <balloons> the helpers might be a bit
[23:08] <elopio> balloons: dios lo oiga.
[23:08] <veebers> elopio: out of interest, what's the haps with the OSK autopilot stuff, it used to work and there was work to get it in the dash + used by other tests
[23:08] <elopio> you see? I can use weird sayings too :)
[23:09] <elopio> veebers: the tests are not running on MPs, so I expect the helpers to be a little outdated.
[23:09] <elopio> then the problem was about restarting the keyboard with testability
[23:09] <elopio> we now have many ways of doing it. We just need to pick one, that's not a big problem.
[23:10] <elopio> and then, the helpers on the toolkit are not using osk, they are using uinput. So we need to extend that to use osk if it's available.
[23:11] <elopio> veebers: not a big deal in general. It just requires one or two weeks of work, and lately we haven't been able to duplicate the available weeks.
[23:11] <balloons> elopio, oie
[23:12] <veebers> elopio: ack


[03:02] <nigelb> ajmitch: heh, the world is tiny. I didn't know you lived in Dunedin :)
[03:04] <lifeless> nigelb: you don't live in Dunedin do you?
[03:04] <nigelb> lifeless: No, but someone I'm good friends with does!
[03:05] <lifeless> ah :)
[03:05] <lifeless> thumper does too
[03:05] <lifeless> I used to
[03:05] <nigelb> Yeah, that was the other small world dunedin story.
[03:08] <ajmitch> nigelb: yeah :)
[06:57] <vibhav> good morning
[07:43] <ESphynx> vibhav how are you :)
[07:44] <vibhav> ESphynx: i HAVE STARTED WORKING
[07:45] <ESphynx> you have? :) congratulations hehe
[07:45] <ESphynx> You finished your exams yet?
[07:46] <vibhav> yes
[07:47] <ESphynx> ah nice :)
[07:47] <ESphynx> Will you still have some time to get Ecere into Debian with your new job? :P
[07:54] <vibhav> ESphynx: By work, I meant the work to bring ecere into debian
[07:56] <ESphynx> Oh! you did :) hehe
[07:56] <ESphynx> I thought you were saying you started a job or something :P
[07:57] <vibhav> no
[07:57] <ESphynx> how's that going? What did you have to do? :)
[07:57] <vibhav> currently I am downloading the source
[07:57] <ESphynx> Did you see the debian folders we have on the Github branches?
[07:57] <vibhav> You have debian folders?
[07:57] <ESphynx> yes the debian/
[07:58] <ESphynx> https://github.com/ecere/sdk/tree/debian
[07:58] <dholbach> good morning
[07:58] <ESphynx> 'morning dholbach :)
[07:59] <vibhav> hi dholbach
[07:59] <ESphynx> vibhav: I think it all already works... it's just a matter of testing it and then adding it to sid :)
[07:59] <dholbach> hi ESphynx, vibhav
[07:59] <vibhav> ESphynx: I will still check it for any mistakes
[07:59] <ESphynx> vibhav ok :) thanks
[08:06] <ESphynx> well good night guys :)
[08:11] <vibhav> ESphynx: Have you filed any ITP or RFP bug for ecere?
[09:56] <erbo> I'm trying to package a daemon that comes with a manpage. The manpage gets (well, should get) installed as /usr/share/man/man1/daemon-name.1.gz but when I install the .deb it doesn't get installed.. If I do dpkg --contents pkg.deb it's listed as part of the package
[09:56] <erbo> what am I missing :)
[09:58] <vibhav> the debian/install file might not be listing the manpage
[09:58] <vibhav> You can move the page to the debian directry
[09:58] <Zhenech> erbo, could you paste dpkg --contents blah.deb and dpkg -L blah?
[09:58] <tumbleweed> vibhav: one generally installs manpages with dh_installman not dh_install
[09:59] <vibhav> ok
[10:00] <tumbleweed> it's easier :)
[10:00] <erbo> Zhenech: http://pastebin.com/d3Rx51d7 (dpkg --contents)
[10:01] <tumbleweed> erbo: the manpages are there. What's the problem?
[10:01] <erbo> tumbleweed: that ls /usr/share/man/man1/ shows nothing right after installing the deb
[10:02] <erbo> Zhenech: http://pastebin.com/qPGJvgTF (that's from dpkg -L)
[10:02] <Zhenech> well, dpkg thinks it did everything right
[10:02] <tumbleweed> you sure you haven't disabled the manpage installation?
[10:02] <tumbleweed> dpkg coa be told to skip directories
[10:02] <tumbleweed> can
[10:02] <Zhenech> is your fs not loving you today? or do you have something like "localepurge" installs
[10:03] <erbo> tumbleweed: that might be it, where's is that controlled?
[10:03] <tumbleweed> erbo: http://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/
[10:04] <erbo> Ah, that's it
[10:04] <erbo> thanks a bunch, I thought I was going crazy
[12:47] <vibhav> I have fixed around 68 typos in a program, how do I submit these to Ubuntu\Debian?
[12:49] <sagaci> what program is it
[12:50] <vibhav> adunn.app
[12:51] <vibhav> http://lintian.ubuntuwire.org/tags/spelling-error-in-binary.html
[12:52] <tumbleweed> vibhav: send them upstream, not to Ubuntu/Debian
[12:53] <tumbleweed> typos in documentation are worth fixing in Debian/Ubuntu, sometimes. But typos in code are not really
[12:53] <vibhav> thanks tumbleweed
[13:00] <vibhav> I cannot see any thingy for contribution
[13:00] <vibhav> It just has a link to join the developer mailing list
[13:00] <tumbleweed> if they don't have a bugtracker, mail th emaintainer
[13:02] <vibhav> What if I dont get a reply?
[13:03] <tumbleweed> unfortunately, you've then probably wasted your time
[13:03] <tumbleweed> we do have things in the archives that have dead upstreams
[13:09] <vibhav> Then can I submit them to Debian or upstream??
[13:11] <tumbleweed> then we should consider whether the package should be in Debian
[14:36] <shadeslayer> question, if I have a arch all package that fails to build on armel because some of the icons were not built, will it fail to buildd's as well? ( The arch all package will only be built on x86 right? )
[14:36] <shadeslayer> The arch all package builds fine on x86
[14:48] <tumbleweed> shadeslayer: correct re arch-all on i386
[14:49] <shadeslayer> tumbleweed: okay, then for some reason kipi-plugins-common fails to build on my armel pbuilder
[14:49] <shadeslayer> I've worked around it for the moment by making the package arch any and having .install.armel
[14:52] <tumbleweed> shadeslayer: err I meant it'll only build the arch-all packages on i386
[14:52] <tumbleweed> so that shouldn't result in a failure
[14:52] <shadeslayer> exactly, I have no idea why debhelper is trying to build a arch all package in a armel pbuilder
[14:53] <tumbleweed> because pbuilder builds arch-all packages unless you tell it not to
[14:53] <shadeslayer> so how do I tell it not to build arch all packages?
[14:53] <tumbleweed> --binary-arch
[14:55] <shadeslayer> tumbleweed: do I have to pass that when creating the tarball or when calling pbuilder-dist build ?
[14:55] <geser> shadeslayer, tumbleweed: pbuilder behaves by default like a i386 buildd (not caring on which arch it is run)
[14:55] <geser> shadeslayer: you pass it when test-building
[14:55] <shadeslayer> hmm
[14:56] <geser> pbuilder-dist precise build --binary-arch ... (or something like that, don't remember the exact pbuilder-dist syntax)
[15:00] <geser> the buildd will only build the arch:all package on i386 but you should be able to build them on armel too
[15:00] <tumbleweed> that's not critical, though
[15:01] <geser> no, but it would be nice to fix it anyways as it probable shows a bug somewhere
[15:02] <tumbleweed> there are arch-all packages in the archive which only build on certain archs. Some of those only build on non-x86, unfortunatly for us (although, that could be worked around with multiarch, these days)
[15:03] <tumbleweed> when debian eventually gets around to implementing building arch-all packages on the buildds, debian will probably implement a way to say which arch the arch-all package should build on
[15:04] <ogra_> it will definitely break if someone tries to rebvuild the package locally on an arm machine
[15:04] <geser> but those are very special
[15:04]  * ogra_ agrees with geser
[15:04] <ogra_> (that it should be fixed)
[15:04] <tumbleweed> fair enough, but there are more important FTBFSs to deal with
[15:04] <geser> I doubt shadeslayer is working on such a package
[15:05]  * shadeslayer reads backlog
[15:05]  * tumbleweed doubts so too
[15:05] <shadeslayer> my main gripe is that pbuilder is not smart enough
[15:05] <shadeslayer> building on armel takes time
[15:05] <shadeslayer> and when you get FTBFS's .... more time is lost
[15:06] <shadeslayer> so by default, pbuilder should not build arch all pacakges unless the pbuilder is a i386 pbuilder
[15:06] <shadeslayer> \end gripe
[15:07] <tumbleweed> shadeslayer: you can achive that with 3 lines of pbuilderrc
[15:07] <geser> not in general, as it is useful to check if the arch:all package builds too before uploading even if test building on amd64
[15:07] <tumbleweed> geser: totally agreed
[15:08] <shadeslayer> ok, if the pbuilder is amd64 or i386, build arch all
[15:08] <shadeslayer> else don't build arch all
[15:08] <shadeslayer> tumbleweed: I'm talking about defaults here :)
[15:08] <shadeslayer> it just doesn't make sense to me personally
[15:08] <tumbleweed> shadeslayer: I think it's fairly sensible for pbuilder to build arch-all packages by default
[15:08] <tumbleweed> I don't see why one wouldn't want to do that
[15:09] <shadeslayer> tumbleweed: because it takes time to build pacakges on arm?
[15:09] <tumbleweed> sbuild doesn't build them by default, but that's because it aims to be like a buildd
[15:09] <geser> shadeslayer: and then you test-build a package you want to try which has an strict version check on e.g. -common which is arch:all and you can't install it without --force-deps
[15:09] <tumbleweed> shadeslayer: right, but then you've got less confidence that your package still builds
[15:10] <shadeslayer> also, this brings in a interesting question, kipi-plugins-common ftbfs on armel because of missing files, should it be made arch any?
[15:11] <geser> no
[15:11] <tumbleweed> I see absolutely no reason to do anything like that
[15:11] <geser> why are those files missing when build on armel but there if build on i386?
[15:11] <tumbleweed> all vs any is strictly about the arch-independant nature of the package content
[15:12] <shadeslayer> because I've disabled libqt4-opengl-dev on armel
[15:12] <shadeslayer> tumbleweed: what if the content is not built on armel ( as proven by my current build )
[15:13] <tumbleweed> which is a fairly intrusive change, affecting a lot of armel/armhf. But clearly worth the pain
[15:13] <geser> in this case build your package with --binary-arch
[15:13] <geser> *test-build
[15:13] <tumbleweed> shadeslayer: as long as the arch-all package you are generating on x86 works on armel, I think we are fine here.
[15:13] <shadeslayer> ok
[15:13] <tumbleweed> the difference in content isn't because of a bug, just different environment
[15:14] <shadeslayer> yep
[15:14] <tumbleweed> if it concerns you, make the build abort on arm :)
[15:14] <shadeslayer> well, I'm trying to fix that, so that's not a viable solution :P
[15:15] <tumbleweed> but it sounsd like any builds on arm of this package wouldn't behave correctly on other archs?
[15:16] <geser> tumbleweed: wouldn't that be a problem only for Debian?
[15:16] <tumbleweed> geser: what?
[15:17] <geser> that the arch:all package build on arm would cause problems for other archs?
[15:18] <geser> as for Debian the arch:all package would be part of the upload while in Ubuntu it gets build by the i386 buildd
[15:18] <tumbleweed> practically, yes
[15:19] <tumbleweed> but generally speaking, if we know that a deb we've built is bad, we should do something to taint it
[16:46] <Corey> Not entirely sure why this is failing: + git-dch --verbose --auto --debian-branch=master --snapshot --id-length=8 --snapshot-number=53
[16:46] <Corey> You are not on branch 'master' but on '(no branch)'
[16:46] <Corey> Then it urges me to: Use --debian-branch to set the branch to pick changes from
[16:46] <Corey> (This is being done within Jenkins)
[17:00] <pabelanger> Afternoon, I'm looking for help with a FeatureFreezeException for a SyncRequest for rebuildd (bug 956188).  Included in the output from syncrequest plus the build.log from pbuilder
[17:02] <micahg> pabelanger: normally, you just use -e when requesting a sync and fill in the blank
[17:04] <pabelanger> micahg: Okay, should I redo the request using it?
[17:04] <micahg> pabelanger: you can just do it locally without submitting and edit the request on launchpad
[17:05] <pabelanger> ack'd
[17:05] <micahg> pabelanger: I'll unsubscribe sponsors for you, just subscribe ubuntu-release when you're done
[17:07] <pabelanger> roger
[17:09] <pabelanger> micahg: thanks for the tip
[18:18] <psusi> when a process is blocked in a system call, is there a way to get gdb to show what all and its args?
[18:18] <jtaylor> strace can do that
[18:19] <jtaylor> though probably youi can't attach it to a running process :/
[18:19] <psusi> you can... just was wondering if gdb can too
[18:20] <jtaylor> doesn't setting a breakpoint work?
[18:20] <sbeattie> both gdb and strace can attach to a running process;
[18:22] <psusi> yea, I can attach,  but is there a way once attached to have gdb show what system call and arguments the process is in, similar to strace?
[18:22] <jtaylor> ^C and look at the frame
[18:23] <psusi> that just tries to show the user mode stack frames
[18:23] <psusi> ( which are all unknown when you don't have debug syms )
[19:09] <PaoloRotolo> Hi all!
[19:39] <mfisch> Following up on the Ubuntu fix I made last week, I'm sending it to debian.  Do I just attach the patch to an email to the bug?
[19:39] <mfisch> I assume there might be some magic phrase that tells everyone I added a patch
[19:40] <mfisch> actually I just found TFM, I'll read
[19:41] <jtaylor> reportbug -B debian will do everything correctly
[19:44] <micahg> alternatively, if you have the new source that was uploaded and the old source package, you can use submittodebian
[19:57] <mfisch> I did not know about either of those tools
[19:57] <mfisch> and I misspoke, I didn't mean sending the bug, I meant sending the fix
[20:02] <arand> mfisch: Yeah, you send the patch as an email attachment to the debian bug, if you are able to confirm that the patch works *on Debian* then you can CC the control server with "tag [bugnumber] + patch"
[20:02] <arand> reportbug with automatically do the patch sending correctly.
[20:03] <arand> (as already mentioned)
[20:03] <mfisch> arand: I harassed a local colleague/debian dev to confirm that after reading the manual
[20:04] <mfisch> arand: trying to avoid looking like an idiot today...  but anyway the patch is attached and the bug is tagged
[20:04] <arand> Nice :)
[20:05] <mfisch> when debian accepts the fix, we can nuke the ubuntu one
[20:05] <mfisch> which is our goal I think
[20:11] <arand> mfisch: Usually is, yeah, is it a native package then?
[20:11] <mfisch> arand: yeah, live-manual
[20:11] <arand> Ah, right (since otherwise the patch wouldn't be nuked, per se)
[20:12] <mfisch> if debian re-did a fix and their patch also worked for ubuntu, we'd just switch to theirs right?
[20:13] <arand> Yeah, but we'd still carry the patch in the package, it would just be synced in from debian.
[20:13] <arand> (hence not nuked, per se)
[20:14] <arand> Isn't live-manual-* non-native? or is live-manual something else than live-manual-all?
[20:42] <cormiert> Hi!
[21:27] <ESphynx> Are Unity developers left-handed?


[01:08] <Rodrigo3x> hi everybody! I'm interested in becoming an Ubuntu developer, but it's still unclear to me what step I must follow
[01:08] <Rodrigo3x> can somebody point me in the right direction?
[01:16] <Rodrigo3x> hi everybody! I'm interested in becoming an Ubuntu developer, but it's still unclear to me what steps I must follow...can somebody point me in the right direction?
[01:17] <micahg> Rodrigo3x: just start fixing stuff
[01:19] <Rodrigo3x> micahg: Hi! I would like to do so, I'm a senior Java developer, who loves to open to new technologies, languages and the like, but I'm a complete noob to the process of getting some source, grab a bug report, then fixing and submitting the changes I'd made
[01:20] <micahg> Rodrigo3x: are you familiar with VCS workflows
[01:20] <Rodrigo3x> micahg: No
[01:21] <micahg> Rodrigo3x: https://wiki.ubuntu.com/MOTU/TODO#Patch_Testing_and_Review
[01:30] <Rodrigo3x> micahg: Thanks, I'm reading the page you provided, and found that Harvest/Opportunities are quite interesting...I certainly want to fix some of these!
[01:30] <micahg> Rodrigo3x: that would be wonderful, we have no shortage of bugs, feel free to ask any questions you might have
[01:31] <micahg> Rodrigo3x: if you have a favorite java package, that might be a good place to start
[01:34] <Rodrigo3x> micahg: I'm still wondering how to get the sources related to a certain bug and begin playing with it, I've been reading some docs, but can't still get it
[01:35] <Rodrigo3x> is there any doc you recommend?
[01:35] <micahg> Rodrigo3x: ah, sorry, that piece was missing :)
[01:35]  * micahg looks for it
[01:37] <Rodrigo3x> micahg: haha :D I'll keep reading the docs and trying to get it to work, again, the opportunities of Harvest look interesting
[01:37] <micahg> Rodrigo3x: here's the full packaging guide: https://wiki.ubuntu.com/PackagingGuide/Complete#Patching_Other_People.27s_Packages
[01:37] <micahg> oops, without the # and what's after it that is
[01:38] <micahg> if you'd like to try the method with version control, there's a link at the top to the new guide
[01:38] <nhandler> http://developer.ubuntu.com/packaging/html/ might be a bit more up-to-date
[01:39] <micahg> right, that's the version control version :)
[01:39] <nhandler> :)
[01:43] <Rodrigo3x> micahg / nhandler: http://developer.ubuntu.com/packaging/html/ has a example of fixing a bug in tomboy, seems very informative to me
[01:43] <micahg> Rodrigo3x: if that workflow looks good, go for it :0
[01:43] <micahg> :)
[01:43] <Rodrigo3x> micahg / nhandler: I'll take some time to read the entire doc, but I'll be back!!!
[01:44] <Rodrigo3x> thanks you all!
[02:45] <Rodrigo3x> hi again people, I'm setting up my environment to begin contributing, and reading the docs, I'm seeing many times the "upstream" concept
[02:45] <Rodrigo3x> can anyone explain the upstream concept?
[02:47] <ScottK> Rodrigo3x: Most of the software in Ubuntu is not written specifically for Ubuntu.  It's written by a separate upstream and we package it for Ubuntu.
[02:47] <ScottK> Upstream is wherever we get stuff from.
[02:52] <Rodrigo3x> ScottK: Hi! ok, got it now. Sorry, I'm constantly improving my english, some things fall out my understanding, and I'm a newbie in becoming a Ubuntu contributor
[02:54] <ScottK> Glad to help.
[03:01] <raltamirano> quit
[09:36] <hrw> ~hail licensecheck script


[02:35] <LaserJock> hi robotgeek
[02:36] <robotgeek> hey LaserJock
[02:36] <LaserJock> how's it going?
[02:37] <robotgeek> busy day today, got to touch the PC only now, and i gotta run for dinnner again
[02:37] <LaserJock> hmm, me too. I just got done putting in a new kitchen fauchet
[02:37] <robotgeek> ah, nice
[02:38] <LaserJock> but I wanted to do some doc work tonight
[02:38] <robotgeek> on the packaging guide?
[02:39] <LaserJock> yes
[02:39] <robotgeek> nice, it served as a good resource (and still does)
[02:40] <LaserJock> did you use the one on doc.ubuntu.com?
[02:40] <robotgeek> yeah, the 'latest' one
[02:40] <LaserJock> I actually haven't read through that all the way
[02:40] <robotgeek> i got confused by the draft version which was linked from the fridge, IIRC
[02:42] <LaserJock> hmm, I didn't know about that
[02:42] <robotgeek> okay LaserJock , i gotta run now. i'll be back later. i did sumbit some corrections to the guide, (typos) , you might wanna look at that, it was last month, i think
[02:43] <LaserJock> robotgeek: ok, I might look at them but I'm doing a rewrite so I don't know that it will matter much
[02:43] <robotgeek> hmm, okay. cya later then
[02:43] <LaserJock> cya
[06:52] <mhz> It this useful for the Team purposes if I don't understand DocBook>
[06:52] <mhz> ?
[06:52] <mhz> http://<IP_ADDRESS>/tcwiki/FitlChile?action=format&mimetype=xml/docbook
[06:53] <mhz> This DocBook 'format' was generated by MoinMoin
[06:53] <mhz> and if it is of any use... then I can say i can finally collaborate
[06:54] <mhz> please let me know ASAP
[06:54] <mhz> by all
[06:54] <mhz> bye all
[07:17] <jsgotangco> hi all
[11:51] <robotgeek> hey jsgotangco
[11:52] <jsgotangco> hey
[11:52] <robotgeek> for bugs on documentation?
[11:53] <jsgotangco> more of laptop mission bugs
[11:53] <robotgeek> ah..
[11:53] <robotgeek> i finally joined the "wiki team"
[11:54] <jsgotangco> ahhh
[11:54] <jsgotangco> i've seen a lot of wiki changes
[11:54] <robotgeek> heh, yeah..curse me if anything's wrong :)
[11:58] <mdke> robotgeek, https://wiki.ubuntu.com/DocumentationTeam/News2
[11:58] <robotgeek> mdke: yes, i saw that. thanks
[12:01] <mdke> :)
[12:01] <robotgeek> i keep refreshing that page very often.
[12:02] <robotgeek> i think you are going to need to add much more, if i stick on to my "one page per day" pace :)
[12:03] <jsgotangco> hey mdke
[12:03] <jsgotangco> how's things?
[12:04] <mdke> robotgeek, that's good
[12:04] <mdke> jsgotangco, fine thanks
[12:04] <mdke> robotgeek, WPAHowto isn't in your WifiDocs collection
[12:05] <robotgeek> there are a several more i found after searching more extensively. i need to add them.
[12:05] <mdke> ah cool
[12:05] <robotgeek> mdke: i think it's there, last link first section
[12:06] <mdke> ah i didn't check, i just meant as a subpage
[12:06] <mdke> fine, my bad
[12:06] <robotgeek> i did not want to change the links to those, should i got and add all howto's as a subpage with redirects?
[12:06] <mdke> actually I don't think subpages are such a good idea right now
[12:07] <mdke> there are too many pages
[12:07] <mdke> robotgeek, if you want a good task, it would be to merge all the ndiswrapper pages :D
[12:07] <robotgeek> yeah, i'm refraining since i don't know a awful lot about it.
[12:07] <robotgeek> but i think i will know enuf after going thru them all
[12:08] <mdke> heh
[12:09] <mdke> robotgeek, we need to get you involved in docbook too for some official docs action :D
[12:10] <robotgeek> mdke: doc book shouldn't be a problem, though i dunno much about it. i've used html before, and latex too. xml will be similiar, i guess
[12:10] <mdke> yep, it's real easy
[12:10] <mdke> (reboots)
[12:13] <jsgotangco> argghh
[12:13] <jsgotangco> these regressions are irritating me
[12:13] <robotgeek> having other machines around is a good thing then
[12:14] <jsgotangco> yes at least anoter partition if not a new machine
[12:14] <robotgeek> yeah, that too.
[12:15] <robotgeek> i'm planning to spend some time to get it working on a external usb disk
[12:15] <robotgeek> that way, i can carry it around
[12:16] <robotgeek> lol
[12:16] <jsgotangco> heh
[12:16] <jsgotangco> yeah
[12:16] <mdke> jeez
[12:16] <jsgotangco> well
[12:16] <mdke> what are they on
[12:16] <jsgotangco> it needs a lot of anti-aliasing love
[12:17] <jsgotangco> as well as hmmm new colors
[12:17] <mdke> i can see no possible justification for a diagonal bottom line
[12:17] <robotgeek> the old one was very readable, why fix it if it ain't broke?
[12:17] <jsgotangco> well yeah
[12:18] <jsgotangco> at least the logoff/shutdown dialogs are much better
[12:18] <robotgeek> true, i agree with that
[12:18] <mdke> the buttons are too big
[12:18] <robotgeek> it's very slick and *usable*
[12:18] <mdke> and there are too many of em
[12:18] <mdke> but its definitely better
[12:19] <jsgotangco> well its way better than the one that looked like tango icons
[12:20] <mdke> i prefer this: http://bugzilla.gnome.org/attachment.cgi?id=57474&action=view
[12:20] <mdke> gtg
[12:20] <mdke> shopping
[12:20] <jsgotangco> oh that is nice
[12:20] <robotgeek> later mdke
[12:21] <robotgeek> windowzy look
[12:21] <robotgeek> or was theat the mac,
[12:21] <robotgeek> yes, it's a windows look with the mac text, lol
[12:23] <jsgotangco> they call it tango
[12:23] <jsgotangco> heh
[12:23] <robotgeek> yeah, it takes 2 to tango
[02:03] <mdke> perhaps it is time to drop the html builds from ubuntu-docs now
[02:04] <mdke> yelp seems to have the speed hits in dapper now, so it handles xml much quicker
[02:04] <mdke> jdub, any progress on the ubuntu yelp stylesheets?
[02:16] <jsgotangco> hmm yelp works in dapper?
[02:16] <jsgotangco> last i check it just crashes
[04:23] <SteveMyers> mdke: you have a minute?
[04:23] <mhz> re
[04:23] <mhz> Could anyone read my last question (9 hours ago)?
[04:24] <mdke> SteveMyers, yes shoot
[04:24] <SteveMyers> mind if I pm?
[04:24] <mdke> mhz, i read it, but I don't understand it
[04:24] <mdke> SteveMyers, ok
[04:25] <mdke> mhz, that page has nothing to do with ubuntu/documentation?
[04:26] <mhz> mdke: oh, sure. My question is if people (with no knowledge of DocBook nor XML) like me could use Moin1.5 to provide DockBook output you guys could use
[04:29] <mdke> mhz, ah.. well you can make articles like that and then tidy up the code I suppose
[04:29] <mdke> but it won't help you contribute to existing documents
[04:29] <mhz> hmmm
[04:29] <mdke> docbook xml is so easy to learn though dude
[04:30] <mhz> mdke: why it won't help?
[04:31] <mdke> mhz, because the existing documents are not in Moin, they are already in docbook, and that output is a whole article
[04:31] <mdke> mhz, but seriously, it's SO easy to learn
[04:31] <mhz> ohhh
[04:31] <mdke> if you look at the output, it's basically just like html
[04:31] <mhz> mdke: I know it is tag like
[04:34] <mdke> you just write stuff, and learn as you go along
[04:36] <mhz> okis
[04:36] <mdke> but maybe the moin plugin can help you get used to the tags
[04:39] <mhz> mdke: that was my initial thought
[04:40] <mhz> but if it wont help the docing cause.. I don't see the point of keeping it
[04:40] <mdke> maybe one day the plugin will be so good that we can work directly on a wiki and create xml for the distribution
[04:40] <mdke> but i am fairly sure that day is not here yet
[04:41] <mhz> no problem
[04:41] <mhz> I needed to ask because it looked good to have it as a 'default' option in Moin 1.5
[04:41] <mdke> yeah
[04:41] <_jason> hi everyone, sorry to interrupt (you can get to this whenever you get a minute).  A wiki page I created was added to categoryCleanUp a while ago.  I got around to making some formatting changes.  What's the standard procedure for removing a page from CleanUp.  I would do it myself, but I think it would be a good idea to let you guys see it and suggest if something else should be changed/updated.  Here's the link: https://wiki.ubuntu
[04:42] <mdke> _jason, we missed the end of that, what's the page?
[04:43] <mhz> mdke: Moin guys have tried to let people (with xml knowledge) that Moin 1.5 let them work with DocBook (I imagined it was only a matter of defining s 'sheet' for the output)
[04:43] <_jason> mdke: https://wiki.ubuntu.com/MX1000Mouse
[04:43] <mhz> let +know
[04:45] <mdke> _jason, looks nice. I would remove the rst stuff, and probably remove all the terminal icons, they get in the way a bit
[04:46] <mdke> _jason, I'll show you what I mean, if you don't mind me editing the page a sec
[04:46] <irvin> j #ubuntu-desktop
[04:46] <_jason> mdke: go for it
[04:47] <mdke> _jason, you are editing it at the moment, I can't edit it
[04:47] <mdke> brb
[04:47] <_jason> mdke: ok, check now
[05:21] <mdke> _jason, I've made a few changes and removed Cleanup
[05:23] <_jason> mdke: alright cool, thanks
[06:35] <mkde> man xchat-gnome rocks
[06:35] <mkde> dunno why people complain
[06:36] <mkde> geez it's absolutely awesome


[02:26] <grantbow> meeting tonight in about a half hour :-)
[02:36] <jercos> shiny.
[02:40] <philballew> If anyone wants to add something to the meeting agenda before the meeting, now is the best time.
[02:58] <philballew> meeting in two minutes
[03:00] <grantbow> \o/
[03:00] <philballew> [03:00] <philballew> Well then, it is meeting time
[03:00] <grantbow> #startmeeting
[03:00] <darthrobot> Meeting started Mon Dec  3 03:00:51 2012 UTC.  The chair is grantbow. Information about MeetBot at https://wiki.ubuntu.com/meetingology.
[03:00] <darthrobot> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[03:01] <grantbow> #endmeeting
[03:01] <darthrobot> Meeting ended Mon Dec  3 03:01:10 2012 UTC.
[03:01] <darthrobot> Minutes:        http://ihas.5cat.com/~darthrobot/ubuntu-us-ca/2012/ubuntu-us-ca.2012-12-03-03.00.moin.txt
[03:01] <philballew> ah, yeah. Lets use the bot.
[03:01] <philballew> #startmeeting
[03:01] <darthrobot> Meeting started Mon Dec  3 03:01:31 2012 UTC.  The chair is philballew. Information about MeetBot at https://wiki.ubuntu.com/meetingology.
[03:01] <darthrobot> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[03:01] <grantbow> go for it, chair :-)
[03:01] <toddc> long meeting/
[03:02] <philballew> let me paste the agenda
[03:02] <philballew> https://wiki.ubuntu.com/CaliforniaTeam/Meetings/12December02
[03:02] <darthrobot> Title: [CaliforniaTeam/Meetings/12December02 - Ubuntu Wiki]
[03:02] <philballew> Currently nothing there
[03:03] <philballew> Does anyone have anything they would like to bring up or add?
[03:03] <grantbow> I do not have anything urgent for this meeting
[03:04] <philballew> Me as well.
[03:04] <philballew> Alright then, how about we call this a night.
[03:04] <grantbow> I announced the t-shirt art contest, please submit when you can.
[03:04] <philballew> ah yes.
[03:05] <philballew> I think having the booth workers wearing them for scale might be cool.
[03:05]  * philballew is a booth worker
[03:05] <grantbow> https://lists.ubuntu.com/archives/ubuntu-us-ca/2012-November/002097.html
[03:05] <darthrobot> Title: [[Ubuntu-US-CA] Shirt Design Contest]
[03:06] <grantbow> https://wiki.ubuntu.com/CaliforniaTeam/Projects/Shirts-2012
[03:06] <darthrobot> Title: [CaliforniaTeam/Projects/Shirts-2012 - Ubuntu Wiki]
[03:06] <grantbow> QT Developer days is Dec 5-7, Wed -Fri.
[03:06]  * philballew looks back into his closet to see both older tshirts
[03:07] <philballew> unity uses qt for those who did not know
[03:07] <grantbow> Anyone who is interested in speaking please reply to the email list. We have other speaking opportunities besides www.svlug.org
[03:08] <grantbow> Ubuntu Hours are happening all over. San Jose today.
[03:08] <philballew> Ubuntu San Diego in a week and a half, and pleia2 should be in the area and might pop in.
[03:08] <grantbow> Ubuntu Hour Berkeley did well yesterday with six people. Another one is already scheduled for the first Sat next month.
[03:08] <grantbow> +1 SD
[03:09] <philballew> alright then. Anything else anyone has?
[03:09] <grantbow> schedule event calendar is at http://loco.ubuntu.com/teams/ubuntu-california/
[03:09] <darthrobot> Title: [Ubuntu California | Ubuntu LoCo Team Portal]
[03:09] <grantbow> that's it for me
[03:11] <philballew> #endmeeting
[03:11] <darthrobot> Meeting ended Mon Dec  3 03:11:30 2012 UTC.
[03:11] <darthrobot> Minutes:        http://ihas.5cat.com/~darthrobot/ubuntu-us-ca/2012/ubuntu-us-ca.2012-12-03-03.01.moin.txt
[03:11] <grantbow> Thanks for chairing philballew
[03:12] <philballew> not a problem grantbow
[03:12] <grantbow> anyone else around that hasn't spoken yet?
[03:12] <grantbow> I announced the meeting through dvlug.org berkeleylug.com and sf-lug.com but I don't see anyone from the announcement.
[03:13] <grantbow> I mean nobody new seems to have shown up from the emails.
[03:17] <grantbow> I'll be around later this evening but I have dinner guests now. cya later :-)
[03:20] <philballew> peace
[03:22] <akk> I'm around but didn't really have anything to add.
[03:22] <akk> Except I didn't know unity used qt, that's interesting, but unrelated to the meeting.
[03:33] <pleia2> thanks philballew!
[03:34] <pleia2> philballew: it was actually Unity 2d that used a lot of Qt, that's no longer maintained :(
[04:00] <philballew> pleia2, unity 2d stopped last cycle?
[04:00] <philballew> thought it was stopping this cycle?
[04:00] <philballew> my bad
[04:00] <pleia2> philballew: yeah, 12.04 was the last one with Unity 2d
[04:00] <philballew> ah, having only one version of unity is better probably.
[04:01] <pleia2> with 12.10 they use the emulation library to use the same code even when your card isn't 3d accellerated (which is why Unity is so painfully slow on older machines and everyone says 12.10 sucks)
[04:01]  * philballew uses lxde on most machines
[04:01] <pleia2> yeah, xfce here
[04:02] <akk> Having only one version isn't so good if that one version lacks support for older machines. :(
[04:03] <pleia2> it doesn't lack support, it's just slow
[04:03] <akk> So slow as to be pretty much unusable -- ever tried to use unity inside virtualbox?
[04:03] <philballew> they are not as concerned about that group I think.
[04:03] <akk> I wanted to have a vanilla ubuntu around in virtualbox for testing things, but I've sorta given up on it.
[04:03] <pleia2> I have 3d accelleration turned on in virtualbox, but I get your point :)
[04:04] <akk> I tried to turn it on, but it was greyed out IIRC.
[04:05] <akk> Hmm, now it's not greyed out, maybe it's a kernel difference.
[04:05] <pleia2> support has improved a lot over the past couple cycles
[04:05] <philballew> my two laptops are unity and they use about 700 mb's or ram just sitting there
[04:05] <pleia2> I think I was first able to do 3d in virtualbox in 12.04
[04:06] <akk> There are some things from python-snippets that I want to test under unity if I ever manage to catch jono online to find out how to resolve bugs in that package.
[04:07] <pleia2> he tends to be online weekdays 9-5 in #ubuntu-community-team
[04:07] <pleia2> but he just beame a father, so YMMV :)
[04:07] <akk> ah, that might be the problem.
[04:07] <philballew> Good luck to him and what not.
[04:07] <akk> I've pinged him a couple times without an answer, but I haven't been around very consistently either.
[04:08]  * pleia2 nods
[04:09] <philballew> pleia2, so I got your email for sd and everything is gonna work out great
[04:10] <pleia2> philballew: yay!
[04:10] <pleia2> where will it be?
[04:11] <philballew> I see a few options currently, a starbucks 2 miles away, or downtown thats also two miles away. Both the bus goes right to them. I can take the bus with you there to both probably
[04:12] <pleia2> that would be helpful, I don't love the idea of taking a bus alone at night in a city I'm not familiar with
[04:12] <philballew> if you bring some roller skates, I might be able to pull you on my bike?
[04:12]  * philballew runs and hides
[04:12] <pleia2> lol
[04:13] <akk> Most Starbucks tend to be crowded and noisy -- I've had a lot of attempted meetings in Starbucks that didn't work out.
[04:13] <philballew> Its easy for people because they like the coffee though to.
[04:14] <pleia2> philballew: wednesday or thursday night?
[04:14] <pleia2> I still don't have plans for either, ariley said he might come along too if he's available though
[04:14] <philballew> pleia2, I think Thursday is the plan, but will know for sure in about two days.
[04:14] <pleia2> ok :)
[04:15] <pleia2> MJ is flying down friday night, so saturday and sunday we're doing the zoo and animal park!
[04:15] <philballew> The zoo is awesome!!!!
[04:15] <pleia2> yeah, I've wanted to go my whole life
[04:15] <akk> It's a really good zoo. I've never been to the animal park, but I bet it's great too.
[04:15]  * philballew flys out Friday night.
[04:16] <philballew> pleia2, you can spend a lot of time in the zoo.
[04:16] <philballew> At least that is what people tell me
[04:16] <pleia2> :)
[04:17] <pleia2> MJ should have his DSLR by then, that'll be fun
[04:17] <pleia2> camera
[04:17] <philballew> Have fun!
[06:59] <pleia2> http://www.huffingtonpost.com/2012/11/28/megabus_n_2206234.html
[06:59] <darthrobot> Title: [Megabus California: Low-Cost Bus Service Expands Into Golden State With $1 San Francisco To Los Angeles Service]
[06:59] <pleia2> I know megabus from the east coast, didn't realize they had plans for the bay area
[07:00] <pleia2> $1 is temporary, but still less than $10 a ride for their real prices (that article says $5-9)
[07:00] <pleia2> might be useful for scale :)
[08:00] <pleia2> doh, looks like I'll be traveling during both of the other December meetings
[08:03] <philipballew> pleia2, Ill be off school both of those. Assuming I am not out running around doing reckless teenage things I can do them.
[08:04] <pleia2> hehe
[08:04] <pleia2> ok, I'll touch base with grantbow too and see if he'll be around
[08:05] <pleia2> we might cancel one of them too, Dec 30th is a tricky date given proximity to holidays
[08:05] <philipballew> yeah, good point. seems fine to do that
[08:05] <philipballew> pleia2, I am correct to assume you will not be at ScaLE this year correct?
[08:10] <pleia2> philipballew: that's the plan, job situation is too uncertain right now
[08:11] <pleia2> it's ashame, would have liked to speak at it again, just can't make plans until I know what work looks like
[08:12] <philipballew> pleia2, alright.
[08:12] <philipballew> Hope to see you there anyway
[08:12] <philipballew> I  was considering getting some t shirts made from a ubuntu friendly group around here for the booth workers.
[08:13] <pleia2> cool :)
[08:14] <philipballew> pleia2, Darkwing would usually handle the conference packs and stuff right?  and the table cloth and all that jazz?
[08:14] <pleia2> no, that was me
[08:14] <pleia2> I can ship down whatever you need
[08:14] <pleia2> I have the banner and tablecloth right now, and some other booth stuff that can go down
[08:16] <philipballew> ah, seems easy enough then.
[08:16] <philipballew> I'm gonna have a lot of copies of the book Ubuntu made easy"  to give to people visiting
[08:17] <philipballew> and trying to get ll booth workers to help a copy of this and the art of community
[08:17] <philipballew> *all
[08:17] <pleia2> great!
[08:18] <philipballew> for sure.
[08:19] <philipballew> pleia2 might get some of this in her "Welcome to San Diego Ubuntu Hour Swag pack"
[08:19] <pleia2> I have both books
[08:19] <pleia2> publisher sent "made easy" and jono gave me the community book at oscon
[08:20] <pleia2> still need to review "made easy" but life went crazy busy :\
[08:21] <philipballew> pleia2, I have to review that to. college got in the way. Ironically I gave my copy to my mom...
[08:21] <pleia2> heh :P
[08:22] <philipballew> They'll sell more with the title they have.
[08:22] <philipballew> not the old one.
[08:22] <pleia2> for sure
[22:52] <bkerensa> pleia2: have you tried the netflix ppa on xubuntu?
[22:53] <pleia2> bkerensa: no, I haven't tried it at all