[00:00] <xnox> jbicha: no. i wish GNOME would accept patches I submit on bugzilla, before I show up to guadec ;-) otherwise i'd be one grumpy attendant.
[00:02] <jbicha> several GNOME modules are mostly unmaintained
[00:02] <xnox> larsu: darkxst: the ubiquity-panel, the way i test is, is stop lightdm & kill -9 X, and then from tty1: sudo start ubiquity, after changing stuff in-place in a VM..... not sure if this helps =) the highlight is old about ubiquity
[00:04] <xnox> jbicha: yeah, my point is other GNOME dev's that say "lgtm, why is this not merged?" should just commit. In Debian/Ubuntu we have NMU and/or strong team maintainership, yet the GNOME core people don't see this as a problem.
[00:04] <jbicha> GNOME upload procedures are rather different than Ubuntu's
[00:05] <jbicha> it's relatively easy to get git commit rights for everything GNOME so GNOME maintainers assume you have rights unless you tell them otherwise
[00:06] <jbicha> on the other hand, if you're not a maintainer you can get yelled at for not getting a commit reviewed on bugzilla first
[00:08] <jbicha> it's much much harder to get commit/upload rights for Debian or Ubuntu
[00:13] <jbicha> xnox: so the patches you're waiting on are for gnome-sudoku and gnome-power-manager? those are good examples of mostly unmaintained modules
[00:14] <jbicha> look in the .doap file to find out who the maintainer is and manually ping them on irc or by email
[00:16] <xnox> jbicha: that's not what gnome love / gnome goals say to do.
[00:16] <xnox> jbicha: i write a patch for gnome, not a pull request to individual person, maybe it's all should be up on github then instead.
[00:18] <jbicha> gnome-power-manager is no longer core GNOME (note that Ubuntu GNOME doesn't ship it either)
[00:24] <jbicha> nearly all of gnome-games went unmaintained when they split them into separate modules
[00:24] <jbicha> GNOME will never go full-on github because github isn't FOSS
[00:25] <jbicha> it's likely that the new "GNOME Software" app won't include support for paying money for proprietary apps
[01:16] <jbicha> attente: the indicator-keyboard tests still fail
[02:19] <sokky_> hello all, any ecrypt pros here?
[02:46] <attente> jbicha, is there an updated log? or is it the same as before?
[02:49] <jbicha> attente: I don't know http://paste.ubuntu.com/5923873/ also failed on the PPA builders but by default it doesn't give a nice log
[02:52] <attente> jbicha, thanks, yeah, that's a different problem
[03:00] <jbicha> and ibus-client-clutter needs fixing to build against ibus 1.5 http://paste.ubuntu.com/5923902/
[04:13] <pitti> Good morning
[04:24] <Mirv> good morning!
[04:30] <larsu> Good morning
[04:35] <darkxst> good afternoon!
[04:35] <darkxst> pitti, hey!
[04:35] <jbicha> attente: this is correct, right? https://launchpad.net/ubuntu/+source/ibus-client-clutter/0.0+git20090728.a936bacf-5ubuntu1
[04:36] <darkxst> pitti, would you have any idea why apt-get doesnt seem to pick up ddebs from ppa?
[04:36] <pitti> darkxst: I never tried that; do they appear in the Packages.gz index?
[04:40] <darkxst> pitti, nope
[04:40] <darkxst> pitti, although apport-retrace seems to find them mostly
[04:40] <pitti> darkxst: and a-retrace doesn't just take them from ddebs.u.c.?
[04:40] <pitti> apport just uses apt
[04:41] <pitti> well, python-apt, but that still just uses the normal package indexes
[04:41] <darkxst> pitti, gnome3 ppa
[04:41] <darkxst> those would not be on ddebs.u.c
[04:42] <pitti> ooh
[04:42] <pitti> http://ppa.launchpad.net/gnome3-team/gnome3/ubuntu/dists/saucy/main/debug/binary-amd64/Packages
[04:42] <pitti> darkxst: ^ they are there, in a /debug sub-hierarchy
[04:42] <pitti> so you need a "main/debug" series apt line in addition
[04:46] <darkxst> pitti, right! thanks
[07:07] <sil2100> Morning!
[07:08] <Mirv> sil2100: hello!
[07:17] <sil2100> Stacks seem to be a bit lazy since some days - I remember times when I woke up and had to publish/fix manually stuff, since I already had all stack results
[07:17] <sil2100> But now? I wake up and testing and building steps are still ongoing
[07:22] <sil2100> Morning didrocks !
[07:22] <sil2100> didrocks: stacks still not published, they're building and checking right now!
[07:22] <sil2100> didrocks: how's IoM? ;)
[07:23] <didrocks> hey sil2100!
[07:23] <didrocks> sil2100: foggy :p
[07:23] <didrocks> sil2100: stacks are under control? why they are not ready?
[07:23] <didrocks> like ATI machine down?
[07:24] <sil2100> Not sure, some stacks are still in the building stage (like settings), and check jobs are queued up
[07:24] <sil2100> I guess everything slowed down a bit after we enabled additional check jobs, like unity8
[07:24] <didrocks> sil2100: shouldn't
[07:24] <jibel> sil2100, ATI was donw
[07:24] <didrocks> sil2100: the tests are running on both machines, right?
[07:24] <jibel> down
[07:24] <sil2100> didrocks: hah, something's wrong with ATI
[07:25] <didrocks> ok, thanks jibel :)
[07:25] <sil2100> jibel: is it fixed now?
[07:25] <didrocks> sil2100: ensure you kill all the -head jobs please that are duplicated
[07:25] <didrocks> if it's down since saturday, we don't want to rebuild the same stacks 3 times
[07:25] <jibel> sil2100, I'm trying to bring it back but there is something strange
[07:25] <sil2100> jibel: since I see the ATI log of the current job and it doesn't seem to move
[07:25] <jibel> sil2100, since 3 or 4 days it always goes down when platform tests start
[07:26] <sil2100> hmm
[07:26] <jibel> didrocks, I restarted it saturday and yesterday
[07:26] <didrocks> robert_ancell: https://launchpad.net/~ubuntu-unity/+archive/next/+packages?field.name_filter=unity-api&field.status_filter=published&field.series_filter=
[07:27] <didrocks> jibel: urgh, so something wrong with the upstart job?
[07:27] <sil2100> jibel: I wonder what's wrong with the platform tests ;/ Could you give me a ping once ATI is unblocked again?
[07:27] <jibel> didrocks, it wouldn't freeze the whole machine
[07:28] <jibel> didrocks, it is a hardlock, machine is up, but ssh is dead and no console
[07:28] <jibel> sil2100, it's up
[07:28] <pitti> bonjour didrocks et jibel, comment allez-vous ?
[07:28] <sil2100> jibel: but could it be that something again is wrong? Since:
[07:28] <sil2100> http://10.97.0.1:8080/job/autopilot-saucy-daily_release/665/label=autopilot-ati/console
[07:28] <jibel> Bonjour pitti . Ça va bien et toi ?
[07:29] <sil2100> Oh, FAIL
[07:29] <didrocks> jibel: argh, not fine :/
[07:29] <pitti> jibel: je vais mieux, il ne fait plus autant chaude
[07:29] <didrocks> salut pitti!
[07:29] <jibel> sil2100, FATAL: Unable to delete script file /tmp/hudson1344923958933719703.sh means that jenkins lost contact with its slave
[07:29] <didrocks> sil2100: please publish the settings stack ASAP ;)
[07:29] <pitti> jibel: "chaud"
[07:29] <sil2100> didrocks: will do, waiting for it to finish building though!
[07:30] <sil2100> armhf is still building
[07:34] <jibel> didrocks, sil2100 , there is really something wrong, jenkins slave just died
[07:36] <jibel> sil2100, you can add unity8 to the list of tests to restart
[07:42] <sil2100> jibel: ok!
[07:43] <sil2100> didrocks: so, I assume you guys ACK the packaging changes for settings ;)?
[07:43] <sil2100> didrocks: publishing1
[07:44] <didrocks> sil2100: yep, ack! :)
[07:44] <didrocks> sil2100: thanks
[07:45] <sil2100> jibel: do you think that re-running tests for platform can cause the death of ATI machine again?
[07:45] <sil2100> jibel: since I re-ran it in the morning, so I guess it's queued up already
[07:46] <sil2100> pstolowski: welcome back! ;)
[07:46] <pstolowski> sil2100: hey!
[07:46] <jibel> sil2100, that's what I'd like to verify
[07:47] <jibel> sil2100, it just started fine
[07:48] <sil2100> jibel: indeed, so far so good
[07:48] <Mirv> didrocks: hello :) sdk packaging changes of adding devscripts to have licensecheck seems legit, can I publish?
[07:50]  * sil2100 ACKed the change himself to FTBFS
[07:50] <sil2100> ;)
[07:50] <didrocks> hey Mirv! welcome back
[07:50] <didrocks> Mirv: can you check with seb128? I'm on the IoM this week sprint, so not really available for packaging reviews :)
[07:51] <didrocks> Mirv: I trust that between you and sil2100, you'll get through it! :)
[07:52] <sil2100> seb128: morning!
[07:52] <seb128> sil2100, hey
[07:52] <sil2100> seb128: can we have your approval on http://10.97.0.1:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+13.10.20130729-0ubuntu1.diff ?
[07:52] <Mirv> didrocks: thank you :) ok, have a good IoM
[07:53] <didrocks> thanks!
[07:53] <seb128> sil2100, Mirv: seems fine to me
[07:54] <sil2100> Mirv: green light!
[07:54] <sil2100> Mirv: publish ;)
[07:57] <Mirv> seb128, sil2100: thanks
[07:58] <Mirv> sil2100: and thanks for taking care of my stacks in my absence :)
[07:59] <Mirv> sil2100: any idea of those ATI unity test failures? (platform)
[08:00] <sil2100> hm, not sure
[08:00] <sil2100> Mirv: maybe let's poke upstream maybe?
[08:01] <Mirv> sil2100: the other states D-Bus problem
[08:01] <Mirv> sil2100: it's not platform upstream but normal unity autopilot tests that are failing
[08:02] <sil2100> Mirv: what I would do - I would poke unity guys (or even fill in a bug about those and inform them) and publish anyway - or re-run the tests to see it it passes the second time
[08:02] <Laney> morning!
[08:02] <seb128> Laney, hey, how are you?
[08:02] <sil2100> didrocks: sorry to bother you, but maybe on the sprint you can poke someone now - I need to be part of ~cordova-ubuntu, or one of my sub-teams has to
[08:03] <sil2100> didrocks: since I can't re-deploy webapps to fix the stack ;/
[08:03] <Laney> hey seb128, not bad thanks
[08:03] <Mirv> sil2100: rerunning, a good way to find out also if it kills the ATI machine again..
[08:03] <Laney> part of my bike got stolen over the weekend so I had to carry it two miles home, but other than that ...
[08:04] <seb128> Laney, :-(
[08:04] <sil2100> Laney: hi! Part of your bike?
[08:04] <darkxst> Laney, which part?
[08:04] <Mirv> intel succeeded fine
[08:04] <Laney> yeah
[08:04] <Laney> the front skewer
[08:04] <darkxst> just the skewer? that sounds strange!
[08:04] <Laney> it was either just to be annoying or in the hope that i'd abandon it and they could come back and take the whole thing when it was more quiet
[08:04] <Laney> those are my theories anyway
[08:05] <pitti> Laney: ugh, I'm sorry for you; that suck!
[08:05] <pitti> s
[08:05] <Laney> but instead I carried it back and the nice man in the shop gave me a new one for free the next day
[08:05] <seb128> pitti, salut, ca va bien ?
[08:07] <pitti> seb128: salut Sebastien ! oui, je vais mieux, il ne fait plus chaud
[08:07] <pitti> seb128: et toi ?
[08:07] <seb128> pitti, c'est la même chose pour moi, ça fait du bien un peu de frais
[08:08] <tkamppeter> mlankhorst, hi
[08:09] <darkxst> Laney, I would normally say zip ties can fix anything, but probably not in your case ;)
[08:09] <didrocks> sil2100: there is nobody from this team AFAIK here :/
[08:09] <sil2100> Mirv: it passed now \o/
[08:09] <Laney> darkxst: heh
[08:09] <sil2100> didrocks: :( Too bad then, I hate when they create new teams without assigning them to others
[08:09] <Laney> I have some "pinheadz" on my other bike after having a similar incident there
[08:09] <Laney> will get some for this one now too
[08:12] <Mirv> sil2100: wow, nice!
[08:14] <darkxst> Laney, so stealing skewers is regular there? here they just take the whole bike ;(
[08:15] <darkxst> and they thieves don't care about it being busy. I had one bike stolen during peak hour on one of the busiest streets in Melbourne
[08:16] <Laney> :/
[08:16] <Laney> I had two good locks on it so maybe it would have required more time/effort
[08:17] <Laney> disable bike, go away to fetch more tools, come back in middle of night to take it
[08:17] <seb128> seems like lot of efforts to steal a bike
[08:17] <darkxst> seb128, angle grinders cut through even the best locks like butter!
[08:18] <Laney> haha
[08:18] <Laney> and I guess nobody would do anything if you look confident enough
[08:26] <sil2100> seb128: so, once ibus 1.5.3 moves out of -proposed, it will be hosted officially on the image, right?
[08:26] <sil2100> s/hosted/installed
[08:26] <seb128> sil2100, correct
[08:26] <seb128> sil2100, why?
[08:27] <sil2100> seb128: ah, just asking, since unity stack failed because it was requiring libibus-1.0-5, which is in proposed still - wanted to know for sure if it will be installed by default
[08:28] <sil2100> Since there was some discussion I guess
[08:28] <seb128> sil2100, oh right ... CI doesn't build with proposed right?
[08:28] <seb128> sil2100, we are going to need an upload of unity build with ibus 1.5 to move it out of proposed though
[08:30] <sil2100> seb128: it's building with proposed, but it fails if a package is not mentioned in packages: and not installed by default - which currently is the case with the new ibus, although for the time of transition I'll fix it up
[08:30] <seb128> sil2100, ok, great
[08:30] <sil2100> seb128: so we'll have a new unity released with the new ibus
[08:30] <seb128> sil2100, excellent
[08:30] <seb128> today?
[08:30] <sil2100> seb128: I'll fix the config now and let's see how the  tests roll
[08:30] <seb128> great
[08:34] <sil2100> seb128: https://code.launchpad.net/~sil2100/cupstream2distro-config/temporary_unity_new_ibus/+merge/177333 <- can you take a quick look and approve? I'll redeploy and re-run unity stack once all other stacks are green, since unity is hogging the test machines
[08:35] <seb128> sil2100, ok, approved
[08:36] <mlankhorst> tkamppeter: did you recheck 56578 with the xserver I uploaded + a newer version of onboard?
[08:38] <sil2100> Eek!
[08:47] <tkamppeter> mlankhorst, no, how do I get the new xserver and the new onboard?
[08:47] <tkamppeter> mlankhorst, can I do this with saucy?
[08:47] <mlankhorst> yeah needs saucy.. xserver in canonical-x/x-staging, onboard bzr branch lp:onboard iirc
[08:50] <tkamppeter> mlankhorst, xserver-common and xserver-xorg-core are 2:1.14.99.1-0ubuntu0.0~ppa3 and xserver-xorg-video-intel is 2:2.21.12-0ubuntu1~ppa1. Is this correct? Then all what I need is the onboard from BZR?
[08:53] <mlankhorst> probably
[08:53] <mlankhorst> intel version doesn't matter much, it was uploaded for other reasons :)
[09:02] <tkamppeter> mlankhorst, it is unbuildable. I get
[09:02] <tkamppeter> dpkg-source: error: unrepresentable changes to source
[09:02] <tkamppeter> dpkg-buildpackage: error: dpkg-source -b onboard gave error exit status 2
[09:02] <tkamppeter> cd ..
[09:03] <mlankhorst> ignore, or build with debuild -b
[09:03] <mlankhorst> it's probably trying to include the .bzr directory if you build a source file
[09:06] <tkamppeter> mlankhorst, even after "rm -rf .bzr" I can only build with "debuild -b", but at least I can test onboard now.
[09:14] <sil2100> seb128: can I ask you for a packaging ACK before publishing? http://10.97.0.1:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+13.10.20130729-0ubuntu1.diff
[09:14] <sil2100> seb128: (it has the qtdeclarative5-ubuntu-contacts0.1 package in it)
[09:16] <seb128> sil2100, +1
[09:17] <tkamppeter> mlankhorst, onboard works principally, but right-click emulation leads to a segfault.
[09:18] <tkamppeter> mlankhorst, onboard also does not take the black theme of the desktop.
[09:19] <sil2100> seb128: thanks! Another (last) quick one: http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_webbrowser-app_0.21+13.10.20130729-0ubuntu1.diff
[09:20] <mlankhorst> tkamppeter: yeah but I only care about stuck buttons atm
[09:20] <seb128> sil2100, +1
[09:22] <sil2100> seb128: thanks!
[09:25] <mlankhorst> Laney: yikes, here they try to steal your bike by adding another lock to the bike, wait until you unlock your own then steal the bike when you go leave it unattended :/
[09:25] <tkamppeter> mlankhorst, I get no stuck button, seems to work no (typing this with onboard on touch screen)
[09:25] <Laney> mlankhorst: haha, that's quite obvious
[09:27] <mlankhorst> Laney: but unfortunately, it works..
[09:27] <Laney> why would you leave it?
[09:27] <Laney> without your lock on
[09:27] <mlankhorst> seems to be a common reaction when it happens when people are not aware of that trick
[09:28] <tkamppeter> mlankhorst, so I can do tablet mode with the only problem of a missing right button, missing screen rotation, and xbmc not working.
[09:28] <mlankhorst> tkamppeter: the only useful data point to me is... do you still get stuck buttons like that?
[09:29] <mlankhorst> and does xorg stay stable
[09:31] <tkamppeter> mlankhorst, stuck button and X stability seems to be perfect, rest are apps which are not your scope.
[09:32] <mlankhorst> ok good, so I guess the stuck button was partially caused by onboard grabbing the mouse too then..
[09:33] <mlankhorst> or w/e, maybe there is still a bug in xserver but at least there's a workaround for it..
[10:24] <tkamppeter> mlankhorst, I have updated https://bugs.freedesktop.org/show_bug.cgi?id=56578 now.
[10:25] <ubot2`> Freedesktop bug 56578 in Server/Input/Core "race condition with active/passive grabs when opening menus with touch" [Normal,Assigned]
[10:25] <sil2100> thomi: hi! You in IoM too?
[10:25] <thomi> sil2100: yup
[10:26] <sil2100> thomi: awesome! Quick question - would you mind if I proposed a new version of python-evdev to ubuntu?
[10:26] <thomi> sil2100: sure, but please make sure you don't break autopilot - what's the change needed for?
[10:27] <sil2100> thomi: the upstream developer released a new version and simply asked me to sync it with Ubuntu, so no urgent fixes
[10:28] <thomi> sil2100: cool - in the past they;ve broken API, so we need to double check that
[10:28] <thomi> it's nice that they've realised we pushed it into distro though :)
[10:28] <sil2100> thomi: right, I'll poke you about testing later, at least for some guidelines how to check if AP is still working
[10:29] <thomi> sil2100: that's easy: bzr branch lp:autopilot; cd autopilot; autopilot run autopilot
[10:29] <sil2100> Ah, thought that jsut some specific tests use evdev ;)
[10:30] <sil2100> And/or only on certain configurations
[10:30] <thomi> sil2100: yeah, you could probably just run the input tests
[10:30] <thomi> nah, we run on all cofigs
[10:30] <thomi> as long as you have write acces sto /dev/uinput
[10:30] <thomi> sil2100: feel free to ping me and I can run the tests, if you like
[10:31] <sil2100> thomi: thanks :)
[10:56] <sil2100> thomi: hi! Can you give me power over launchpad.net/python-evdev ?
[10:57] <sil2100> thomi: it would be nice to be able to edit the data, could you make me the maintainer?
[11:11] <sil2100> seb128: hmm
[11:12] <seb128> sil2100, I don't like that hmmm :p
[11:12] <sil2100> seb128: I have a question related to releasing new upstream versions of packages where we're not upstream, but which I'm a maintainer of
[11:12] <seb128> ah
[11:12] <sil2100> seb128: when releasing a new upstream version then, in the changelog, should I list all the changes that have been made inbetween versions?
[11:12] <seb128> sure, ask
[11:12] <sil2100> seb128: or just write 'New upstream version'?
[11:12] <seb128> your call
[11:12] <seb128> there is not written rules
[11:13] <seb128> I tend to list things that close a bug
[11:13] <Laney> I like to put the interesting things from NEWS
[11:13] <seb128> and interesting changes
[11:13] <sil2100> Ok ;) Thanks guys
[11:13]  * Laney tries sbuild --arch armhf u-s-s on his desktop
[11:17] <seb128> Laney, u-s-s is a small build, building on the n7 takes less than a minute
[11:17]  * seb128 usually does build there
[11:17] <seb128> it's just a bit annoying having to reinstall the build-deps when putting a new image on it
[11:17] <Laney> yeah I don't have those atm
[11:17] <Laney> thought this might be fast but it's not really
[11:18] <seb128> Laney, let me know if cross building work
[11:18] <Laney> not cross building, qemu
[11:18] <Laney> is working though
[11:18] <seb128> ah
[11:20] <Laney> I think it's slower :P
[11:22] <Laney> oh, segfaulted in the testsuite
[11:30] <Laney> ah good, that makes it more responsive
[11:30]  * Laney breathes
[11:30] <xnox> brilliant indicators are finally crashing ubiquity panel =)
[11:30]  * Laney locks Qt in the cupboard under the stairs as a punishment
[11:32] <xnox> I think i will disable ubiquity panel as a workaround for bug 1161058
[11:32] <ubot2`> Launchpad bug 1161058 in ubiquity (Ubuntu) "panel crashed with SIGSEGV in indicator_object_get_entries()" [Medium,Confirmed] https://launchpad.net/bugs/1161058
[11:42] <xnox> Right, larsu if you need any help testing / porting ubiquity's panel to new indicator stack feel free to ping me =)
[11:45] <seb128> xnox, did you read the friday discussion on the topic?
[11:46] <xnox> seb128: hm, I don't think I did. Was it here?
[11:47] <seb128> xnox, yes, short summary: larsu is working on it, he might have it done today (if IRC crazyness stops pulling him off work)
[11:47] <xnox> seb128: there is a mega plan in the back of my head to drop ubiquity-panel and drop ubiquity-dm, and instead use upstart user session to start ubiquity on login, with dash hidden / not-loaded and with a few thing pre-emptied.
[11:47] <xnox> seb128: ok. cool.
[11:56] <seb128> sil2100, how is unity looking? did you retry it yet?
[11:56] <sil2100> seb128: I did, let me look at the status
[11:58] <sil2100> seb128: it finished, but intel has a few too many failures
[11:58] <seb128> sil2100, real bugs/issues? or system flackyness?
[11:59] <sil2100> Seems like system flackyness, since ATI was fine
[11:59] <seb128> so another retry?
[12:08] <sil2100> Yes, it's running already
[12:08] <sil2100> thomi: hi! I installed the new evdev and tested the test_input_stack tests and they passed, but if you have a moment, could you also test on your machine? I pushed the package to my PPA:
[12:08] <sil2100> thomi: ppa:sil2100/testing
[12:19] <desrt> good morning freedom lovers
[12:19] <desrt> . o O ( hmm... that didn't work... )
[12:19] <desrt> PANTS OFF!
[12:24] <seb128> desrt, howdy!
[12:24] <seb128> desrt, you are trying for GUADEC? ;-)
[12:24]  * desrt invokes jdub
[12:24] <desrt> seb128: i made a present for you over the weekend
[12:25] <seb128> desrt, I noticed, thanks for working on that ;-)
[12:25] <seb128> when is next tarball due? ;-)
[12:25] <seb128> well, you need to get it merged first I guess :p
[12:25] <desrt> i think this won't be done until after guadec
[12:25] <desrt> i've been generating a whole lot of work lately that he needs to review
[12:25] <seb128> ok, I might just distro patch it if I need it
[12:25] <desrt> whether in gio, file monitors, desktop files...
[12:26] <desrt> warning: i may change the name
[12:26] <seb128> ok
[12:26] <desrt> g_file_measure_disk_usage() sounds nicer than _query_disk_usage() i think
[12:26] <seb128> well, I've enough stuff to do that I can delay that for a few weeks
[12:26] <seb128> I should probably just wait for you to land it properly
[12:29] <thomi> sil2100: sure
[12:29] <sil2100> seb128: once I get this new package I am maintaining tested, how should I proceed to get the new version into the Ubuntu queue? Who should I poke and with what?
[12:29] <sil2100> thomi: thank you!
[12:30] <seb128> sil2100, either do a merge proposal against the ubuntu:<source> vcs or open a bug with a link to the ppa, or with the package files attached to the bug, and subscribe ubuntu-sponsors
[12:31] <sil2100> seb128: thanks :)
[12:31] <seb128> yw
[12:49] <sil2100> thomi: and then as well my previous question - could you assign me as the maintainer of launchpad.net/python-evdev?
[12:50] <thomi> sure
[12:50] <thomi> sil2100: done
[12:57] <thomi> sil2100: I don't get a new python-evdev with your PPA added
[12:58] <thomi> hmmm
[12:58] <sil2100> thomi: hm, let me see!
[12:59] <thomi> sil2100: it doesn't look like it's in your PPA yet (not published anyway) - I'll try again later
[12:59] <sil2100> thomi: ah, right, amd64 still pending ;/ Sorry about that!
[12:59] <sil2100> thomi: and thanks!
[12:59] <sil2100> :)
[12:59] <thomi> no worries
[13:09] <seb128> Laney, did you hit weird gsettings missing schemas bugs happening randomly with system-settings recently?
[13:10] <seb128> GLib-GIO-ERROR **: Settings schema 'com.ubuntu.touch.system' does not contain a key named 'r'
[13:10] <seb128> just hit that (but it's not the first time, it seems to try to read random keys)
[13:16] <Laney> seb128: no
[13:16] <Laney> no idea how to trigger it?
[13:17] <seb128> it happens on start every few runs here
[13:17] <seb128> with random key names, looks like corruption
[13:17] <seb128> could be an issue with gsettings-qt
[13:18] <Laney> that one in particular comes from orientation-lock
[13:18] <Laney> I can't see how that could be a bug in system-settings
[13:18] <Laney> have you seen it on the device or desktop or both?
[13:19] <seb128> desktop
[13:19] <seb128> but I don't test on the device that much
[13:19] <seb128> I mostly do check a few specific thing, otherwise run it when I update the image just to have a look
[13:19] <Laney> same
[13:22] <czajkowski> aloha
[13:24] <czajkowski> wondering who is the developer driving scopes? question on their functioning.  each time I lauch one in the dash it's instintive for me to double click but that just makes it disapear then I go and click it again and then have to hit launch.  Is there a way to change this so that if I find it in the dash and double click it, it opens?
[13:27] <seb128> czajkowski, you want to talk to mhr3_
[13:28] <czajkowski> seb128: cheers
[13:28] <pitti> robru: hey Robert, how are you?
[13:28] <czajkowski> maybe I'm just too used to double clicking
[13:28] <pitti> robru: would you mind having a look at friend's failing autopkgtest? it's blocking other packages like the new pygobject from entering saucy
[13:58] <sil2100> thomi: if anything, the amd64 binary has been built and published!
[14:11] <seb128> Laney, larsu:
[14:11] <seb128> GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.background' does not contain a key named 'picture-u\xa8-d\xb0\xb1'
[14:11] <seb128> there is something weird with gsettings-qt :/
[14:19] <desrt> seb128: aren't you glad that resulted in an abort with a helpful error message instead of strange difficult-to-trace-down behaviour? ;)
[14:20] <seb128> desrt, don't get me started on the abort thing... ;-)
[14:20]  * seb128 is pondering storing the ringtone in a ini style file instead of gsettings just to make sure the phone app on the phone is robust
[14:21] <Laney> when did you first start seeing this behaviour?
[14:21] <seb128> since we started using gsettings
[14:22] <Laney> interesting
[14:22] <Laney> locale related?
[14:22] <seb128> dunno, why would it?
[14:23] <seb128> it's a corruption
[14:23] <desrt> seb128: there's a much easier way to ensure the app is robust: install the schema
[14:23] <seb128> it works 9 times on 10 run
[14:23] <desrt> :)
[14:23] <seb128> desrt, robust means = if your disk is corrupted, the schemas missing, etc, you still have a chance the app keep working
[14:23] <seb128> it might not
[14:24] <desrt> if disk corruption results in part of the application going missing then it's true that the application may not run properly
[14:24] <seb128> but the chance is higher when it doesn't abort just because e.g the configured ringtone schemas is missing
[14:24]  * desrt raises a glass to not having old arguments
[14:24] <seb128> ;-)
[14:24] <seb128> I told you, don't get me started on that :p
[14:24] <desrt> fair enough!
[14:25] <seb128> we have to agree on disagreeing there
[14:25] <seb128> it also annoys me that I've to make system settings depends on the phone app, which is not available in the archive yet, to be able to start it
[14:25] <seb128> I would prefer have a if(key not there) hide that ui
[14:26] <desrt> this API exists now
[14:26] <desrt> and it's fast and convenient
[14:26] <desrt> g_settings_schema_source_lookup (g_settings_schema_source_get_default (), "your.schema.name")
[14:26] <seb128> yeah, I just need to get larsu to provide a qt api in gsettings-qt
[14:27] <seb128> since I'm calling from qml
[14:27] <desrt> i think he's already doing that, no?
[14:27] <desrt> with his dont-abort-like-desrt patch
[14:27] <seb128> it doesn't abort on missing key
[14:27] <seb128> but it does on missing schemas
[14:27] <desrt> ah
[14:28]  * desrt wonders how it could ever have aborted on missing keys
[14:30] <larsu> desrt: g_settings_get_range() with a missing key aborts iirc
[14:30] <larsu> seb128: hm, when do you get this message?
[14:30] <desrt> larsu: but don't you have to enumerate the keys in the schema in the first place in order to spin up the property map?
[14:31] <desrt> ie: how is it even possible that you'd get a request coming in for a key that's not in the map?
[14:31] <seb128> larsu, that's happening in system-settings on start, once every 10 run ... seems like some sort of corruption :/
[14:31] <seb128> larsu, the code doesn't do anything special, it just use a GSettings and read one key
[14:31] <larsu> desrt: there's an api settings.schema.choice(nameofkey)
[14:31] <larsu> desrt: pass the wrong nameofkey, boom.
[14:31] <desrt> ah
[14:32] <desrt> ya... you should protect against that
[14:32] <pitti> hey larsu, wie gehts?
[14:32] <desrt> this isn't C, after all :)
[14:32] <seb128> larsu, I'm hitting it in different panels
[14:32] <desrt> pitti: hey... i wanted to ask you about your jetlag system
[14:32] <larsu> desrt: ya, that's the dont-abort-like-desrt patch
[14:32] <larsu> pitti: gut danke! How was your weekend?
[14:32] <pitti> larsu: brainmelting :)
[14:33] <larsu> seb128: weird. I'll have a look.
[14:33] <pitti> larsu: we've been to Dresden, but didn't get that much done really aside from BBQ and idling at the beach :)
[14:33] <seb128> pitti, when do you start you holidays? I though you said they were conflicting with GUADEC, must be soon?
[14:33] <pitti> seb128: yes, next week
[14:34] <larsu> pitti: ya, same here :)
[14:35] <Sweetshark> seb128: soo, can we mir lp-solve quicky? it seems to have been in main at least twice (see bug 305790) and has been on upstream version 5.5.0 since at least lucid: https://launchpad.net/ubuntu/+source/lp-solve
[14:35] <ubot2`> Launchpad bug 305790 in xom (Ubuntu Jaunty) "MIR - move to main for openoffice.org 3 build-depends" [High,Fix released] https://launchpad.net/bugs/305790
[14:36] <Sweetshark> seb128: trouble is: I am using libreoffices own copy of lp-solve and its causing all kinds of stupid dependency trouble ...
[14:36] <jbicha> desrt: how do you recommend fixing bug 1195481?
[14:36] <ubot2`> Launchpad bug 1195481 in gnome-control-center (Ubuntu) "[power]: gnome-control-center crashes if indicator-power is not installed in Unity" [Medium,New] https://launchpad.net/bugs/1195481
[14:36] <seb128> Sweetshark, check with doko or mterry maybe? but it has been in main it should be fine
[14:37] <desrt> jbicha: lots of good ways to deal with that
[14:37] <desrt> jbicha: could move the custom indicator to the indicator-power package like datetime does it
[14:38] <sil2100> seb128: \o/ Tests passed \o/
[14:38] <sil2100> seb128: can I publish unity?
[14:38] <desrt> jbicha: could move the key to g-c-c and add a dep from the indicator to g-c-c
[14:38] <seb128> sil2100, excellent, please do!
[14:38] <desrt> jbicha: could add a dep from g-c-c to the indicator
[14:38] <sil2100> seb128: we'll have it in proposed and ready for the transition
[14:38] <desrt> jbicha: could move the schema to some other package like gs-d-s and make both depend on that
[14:38] <desrt> or you could do the conditional thing i mentioned above
[14:39] <jbicha> desrt: yeah the last one is the one I'm looking for
[14:39] <desrt> that's the least-good one :p
[14:39] <desrt> but ya... might make sense in this case
[14:39] <desrt> i kinda like the datetime approach, fwiw
[14:40] <jbicha> desrt: because you're hoping gnome-control-center gets forked?
[14:40] <desrt> not because of that
[14:40] <desrt> you need to think of schemas like you think of libraries....
[14:40] <sil2100> alex-abreu: ping!
[14:40] <sil2100> alex-abreu: hi!
[14:41] <desrt> so either a) they're API or b) they're private
[14:41] <alex-abreu> sil2100, hi!
[14:41] <sil2100> alex-abreu: could you add me to ~cordova-ubuntu ?
[14:41] <desrt> having all users of the schema in the same package means that you get option (b) which is all-around nicer
[14:41] <alex-abreu> sil2100, sure
[14:41] <Sweetshark> doko, mterry: see above -- do we need to do all the redtape for getting lp-solve 5.5 into main for the third time?
[14:41] <desrt> plus... why have custom code installed (even if disabled) to deal with an indicator that's not installed?
[14:41] <sil2100> alex-abreu: since I need to fix the cu2d webapps stack and need to be part of the team to do that ;)
[14:42] <sil2100> alex-abreu: thanks!
[14:42] <alex-abreu> sil2100, done .. welcome in the team ! :)
[14:42] <sil2100> ;p
[14:42] <mterry> Sweetshark, looking
[14:43] <Sweetshark> mterry: note its still supported in main in lucid anyway with that upstream version.
[14:43] <mterry> Sweetshark, yeah.  that's fine.
[14:43] <mterry> approved  :)
[14:44]  * Sweetshark gives mterry a hug.
[14:45] <jbicha> desrt: I attached a MP to the bug which is one fix (having Unity depend on indicator-power) but bschaefer wasn't so sure that was right
[14:46] <desrt> jbicha: move the panel is your best bet, imho
[14:46] <desrt> keeping patches out of the g-c-c package and shipping override panels alongside indicators is the best way
[14:47] <jbicha> desrt: that's a lot more work though and it will mean that the Ubuntu versions will likely get outdated (but at least the UI would be more stable from release to release)
[14:49] <jbicha> also there's bug 1197662
[14:49] <ubot2`> Launchpad bug 1197647 in indicator-datetime (Ubuntu) "duplicate for #1197662 Date & Time applet in control center does not start" [High,Fix released] https://launchpad.net/bugs/1197647
[14:50] <jbicha> oops I mean bug 1187981
[14:50] <ubot2`> Launchpad bug 1187981 in gnome-control-center "symbol conflicts in libtimezonemap1" [High,New] https://launchpad.net/bugs/1187981
[14:52] <desrt> fun!
[14:52] <desrt> maybe we should fork g-c-c...
[14:53] <desrt> (why didn't we do this already?!?)
[14:54] <seb128> because it's work and nobody did it (yet), and because have 2 different g-c-c on top of 1 g-s-d is impractical
[14:54] <seb128> so it requires some thinking about g-s-d, or also forking that ... but then it starts being tricky
[14:54] <jbicha> because we can *almost* make things work without forking
[14:54] <seb128> it might be easier to just 'fork' a few panels
[15:14]  * qengho had to flip to a VT, run "startx -- :4 -ac; sleep 5; DISPLAY=:4 xterm" to bootstrap a GUI this morning.  Ouch.
[15:20] <seb128> jbicha, seems like only plasma-widget-kimpanel is missing for the ibus transition ... did you talk to the kubuntu guys about it/do you plan an upload?
[15:21] <attente> seb128, can we upload a new accountsservice?
[15:22] <seb128> attente, hey, sure, what change do you need?
[15:23] <seb128> (I don't see a new upstream version nor a pending sponsoring request)
[15:23] <attente> seb128, it's for the input sources
[15:23] <attente> it's already proposed upstream
[15:23] <seb128> do you have the bug url?
[15:23] <attente> but it's still pending
[15:23] <seb128> ok
[15:23] <attente> https://bugs.freedesktop.org/show_bug.cgi?id=63086
[15:23] <ubot2`> Freedesktop bug 63086 in general "Add KeyboardLayouts property" [Enhancement,New]
[15:23] <seb128> did you talk to Stef about it?
[15:23] <attente> yes
[15:24] <attente> i should follow up again though
[15:24] <seb128> right
[15:24] <seb128> I would prefer if he could ack the name/format before we backport it
[15:25] <seb128> so we don't build on a variable type/format that might change
[15:26] <attente> seb128, ok, sounds good
[15:26] <seb128> attente, let me know when you hear back from Stef, then we can upload
[15:27] <attente> seb128, sure
[15:27] <seb128> attente, btw ibus 1.5 is in saucy-proposed, you can ping alesage about daily landing I think (that was blocked on ibus to be available iirc?)
[15:29] <alesage> seb128, ok I'll get that job going
[15:29] <seb128> alesage, thanks ;-)
[15:29] <alesage> attente ^^
[15:51] <asac> pitti: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1203655 ... is that the bug that causes my thinkpad to not go to sleep when i close the lid?
[15:51] <ubot2`> Ubuntu bug 1203655 in upower (Ubuntu) "Hangs in pthread_join in libusb_exit" [Undecided,Confirmed]
[15:52] <asac> larsu: ^
[15:52] <asac> let me know if you want me to extract something fro debugging or so
[15:52] <larsu> asac: I think it's related (I have the same issue), but I haven't had time to verify it yet
[15:52] <pitti> asac: I don't know; could be
[15:52] <pitti> asac: my laptop suspends just fine, and larsu couldn't reproduce it yet, I don't have any other data
[15:53]  * larsu had the unsuspended-laptop-in-backpack-problem because of that
[15:53] <pitti> I suspended/resumed it a lot over the weekend
[15:53] <larsu> pitti: I didn't have it in the last couple of das either. I'll keep an eye on it, though
[15:54] <asac> i can suspend through menu
[15:54] <asac> not when closing the lid
[15:55] <asac> it just goes in heat mode
[15:55] <pitti> asac: does it suspend when you Ctrl+Alt+F1 ?
[16:15] <seb128> Laney, larsu, kenvandine: hum, are the gsettings key value supposed to update on key change?
[16:16] <seb128> I'm doing
[16:16] <seb128>     GSettings {
[16:16] <seb128>         id: soundSettings
[16:16] <seb128>         schema.id: "com.ubuntu.touch.sound"
[16:16] <seb128> ...
[16:16] <seb128>             SilentModeWarning { visible: soundSettings.silentMode }
[16:16] <seb128> but the visibility doesn't toggle when the key change
[16:17] <seb128> if I do use a prop and do "onChanged: { if (key == "silentMode") silentMode = value" it works though
[16:17] <larsu> seb128: they are supposed to and there are tests that they do...
[16:17] <seb128> hum
[16:17] <seb128> I wonder what I'm doing wrong there
[16:17] <larsu> me too :)
[16:17] <larsu> it looks totally fine to me
[16:18] <larsu> any warnings when loading the script
[16:18] <larsu> ?
[16:18] <seb128> no
[16:18] <larsu> how are you changing the visibility, with gsettings set?
[16:18] <larsu> oops, silentMode of course
[16:19] <seb128> yes
[16:19] <seb128> and it works if I do "onChanged: { if (key == "silentMode") silentMode = value
[16:19] <seb128> in my GSettings {}
[16:20] <larsu> ah, right
[16:20] <kenvandine> that doesn't work
[16:20] <larsu> and you're sure the visible thing works?
[16:24] <seb128> larsu, http://paste.ubuntu.com/5925776/
[16:24] <seb128> $ gsettings set org.gnome.desktop.background show-desktop-icons false
[16:24] <seb128> $ gsettings set org.gnome.desktop.background show-desktop-icons true
[16:24] <seb128> does it change for you dynamically?
[16:26] <seb128> larsu: the previous version doesn't reflect changes for me, that one does: http://paste.ubuntu.com/5925784/
[16:26] <seb128> kenvandine, hey, "that doesn't work" ... you confirm what I'm seeing?
[16:27] <larsu> seb128: same problem here. Definitely a bug
[16:27] <seb128> larsu, ok, let me file one
[16:27] <larsu> seb128: let me finish ubiquity first please, I've had too many distractions today already :)
[16:27] <larsu> seb128: thanks!
[16:28] <xnox> larsu: yes, please, that =)
[16:29] <kenvandine> larsu, remember it doesn't automatically bind the property
[16:30] <kenvandine> at least that is what i seem to recall
[16:30] <larsu> kenvandine: well, it should in that direction
[16:30] <larsu> kenvandine: the problem was that it didn't in the other (checking a checkbox didn't update the key)
[16:30] <kenvandine> oh right
[16:30] <seb128> larsu, https://bugs.launchpad.net/ubuntu/+source/gsettings-qt/+bug/1206181
[16:30] <ubot2`> Ubuntu bug 1206181 in gsettings-qt (Ubuntu) "the properties don't get updated when the key value changes" [Undecided,New]
[16:30] <kenvandine> sorry for the confusion... :)
[16:31] <larsu> seb128: thanks
[16:31] <kenvandine> that did work :)
[16:31] <larsu> kenvandine: no worries
[16:31]  * kenvandine goes back to ofono 
[16:31] <kenvandine> :)
[16:31] <seb128> larsu, sorry for adding to your day IRC ping-o-load (welcome to most of our days :p)
[16:31]  * seb128 goes for some exercice
[16:32] <kenvandine> seb128, btw i am able to get those serviceNumbers from ofono-qt just fine
[16:32] <larsu> seb128: enjoy!
[16:32] <kenvandine> just fighting a little exposing it to qml
[16:32] <seb128> kenvandine, nice!
[16:32] <kenvandine> should have it ready today
[16:32] <larsu> seb128: usually it doesn't bother me, but otday was just crazy
[16:34] <seb128> larsu, yeah, I know how it is when pings don't stop and you can focus 15 min on code ;-) Anyway going for some exercice, maybe you manage to get an hour of quiet hacking :p
[17:34] <larsu> xnox: https://code.launchpad.net/~larsu/ubiquity/fix-indicators/+merge/177438
[17:52] <larsu> seb128: thanks for bringing this to my attention, it was a regression that I introduced with the c++ split. Fixed and MRed, would love a review ;)
[17:56] <seb128> larsu, great, thanks for fixing it!
[18:08] <robru> pitti, hi, yes, I can have a look. where are the failures?
[19:27] <ritz> hi , could someone look at https://bugs.launchpad.net/indicator-session/+bug/1206231
[19:27] <ubot2`> ritz: Error: ubuntu bug 1206231 not found
[19:27] <ritz> wrong channel
[19:28] <ritz> hmmm, ubuntu-security ^^^
[19:29] <sarnold> hrm, I can't load it either.
[19:30] <ritz> sarnold adding you
[19:30] <ritz> not a very high prio
[19:30] <ritz> but annoying
[19:32] <ritz> sarnold mark this as public ?
[19:46] <desrt> seb128: hey.   been following the conversation?
[19:47] <desrt> i think we should drop per-user layouts at the login screen.  they don't make sense.
[19:47] <seb128> desrt, hey, hum, no ... where was that? #gnome-hackers?
[19:47] <desrt> ya
[19:47] <desrt> ah.  you're not there.
[19:47] <seb128> (I'm not on there anymore most of the time)
[19:47] <desrt> i think we should just have one global system default
[19:48] <desrt> the idea that the keyboard layout changes after you type the username but before the password is _really_ weird
[19:48] <desrt> (and only slightly less weird if you pick the user by mouse)
[19:48] <seb128> we don't type the username
[19:48] <seb128> we don't have a username entry
[19:48] <seb128> we click on it
[19:48] <desrt> i know.  please read again :)
[19:48] <seb128> and it makes sense to type the password in the keyboard layout you use
[19:49] <desrt> right... but a computer has a keyboard attached to it, right?
[19:49] <seb128> was that discussion mostly between qwerty users?
[19:49] <desrt> one particular kind of keyboard
[19:49] <desrt> like... in your case, we have a setting on a harddisk that's physically bolted into a machine that has an azerty keyboard on top
[19:49] <seb128> I'm typing azerty on qwerty keyboard (ok, not the majority but still)
[19:49] <desrt> so why not always use azerty at the login screen?
[19:50] <seb128> what about university kind of setups?
[19:50] <seb128> or libraries
[19:50] <seb128> or internet cafés
[19:50] <desrt> maybe...
[19:52] <seb128> well, the feature is no expensive to support and is handy in some cases
[19:52] <seb128> I guess we can keep it as Ubuntu specific if upstream is not interested
[19:52] <desrt> i'm trying to decide if upstream should be interested
[19:52] <desrt> or if ubuntu should drop the feature :p
[19:52] <seb128> the cost is lost, do they just object on principle? even if it's useless for 90% of users, it's not cluttering UI or creating work...
[19:52] <desrt> do you have your system keyboard layout configured to azerty?
[19:53] <seb128> is *low*
[19:53] <seb128> yes
[19:53] <seb128> but let's say I do a guest account for dholbach because I stay at his place for a while and he's going to use my laptop
[19:53] <seb128> he doesn't know azerty
[19:54] <seb128> he's probably going to use qwerty
[19:54] <seb128> well, I don't get what's the cost/issue to just have one list of values by user there
[19:54] <seb128> it's not the most useful feature in the world
[19:54] <seb128> but the cost is low...
[19:54] <desrt> well
[19:54] <desrt> my issue with it is that we now have the list of keyboard layouts used by the user in two places
[19:54] <desrt> accountsservice and gsettings
[19:54] <desrt> and we have to keep them in sync
[19:55] <desrt> also: it's not clear how we should select the default
[19:55] <jbicha> why does gsettings need the keyboard layout if accountsservice can do it?
[19:55] <desrt> probably we don't want the user changing the layout in the session with a hotkey to change what is used at the login screen next time
[19:55] <desrt> jbicha: accountsservice doesn't do it yet... at least not upstream
[19:56] <seb128> desrt, does changing in the session change what you get in the session at next login?
[19:56] <jbicha> right but when it does...
[19:56] <seb128> desrt, for me it's simple, we have a ordered list configured in gnome-control-center
[19:56] <seb128> the first item is the default
[19:56] <desrt> seb128: i don't know.  should it?
[19:56] <seb128> on the login screen and in the session
[19:56] <seb128> no
[19:57] <desrt> these are the questions i am currently trying to think through :)
[19:57] <attente> i guess it's a backwards compatibility issue? do we remove the schema if accountsservice handles it, or keep it and sync..
[19:57] <seb128> I think we should respect the configuration and always apply defaults on fresh boot/login
[19:57] <desrt> that's not how the session side currently works
[19:57] <desrt> it remembers the one from last time
[19:57] <seb128> the cycling you do in a session is in session state
[19:57] <desrt> whic is arguably bogus...
[19:58] <seb128> well
[19:58] <seb128> depends
[19:58] <seb128> do you use "keymap by win" option
[19:58] <desrt> lol
[19:58] <seb128> most people don't use the same input method/keymap in their im client and text editor
[19:58] <seb128> you code in C/english
[19:58] <seb128> you chat in your language
[19:58] <seb128> "lol" but welcome to keymap fun ;-)
[19:59] <seb128> default state should really be whatever you defined the default, at every login
[19:59] <seb128> then users change the config according to the context
[19:59] <desrt> i think i agree
[20:58] <sarnold> ritz_: public makes sense to me
[21:07] <chrisccoulson> does somebody want to maintain a browser?
[21:07] <mdeslaur> lol
[21:07] <sarnold> oh no, I'm not falling for that
[21:07] <chrisccoulson> :)
[21:09] <mdeslaur> IT'S A TRAP!
[21:09] <chrisccoulson> i'm just going to pop in to random IRC channels this week and ask the same question
[21:24] <seb128> chrisccoulson, which one are you giving away? ;-)
[21:25] <chrisccoulson> seb128, i only have one to give away ;)
[21:25] <seb128> chrisccoulson, I saw you uploading chromium recently! :p
[21:25] <chrisccoulson> seb128, oh, i just sponsor stuff for qengho