[00:00] <Sweetshark> mterry: I wont comment on that one ;)
[00:03] <Sweetshark> any gnome guys around?
[00:05] <Sweetshark> if so, please consider consider sponsoring the fix for bug 1056378, see also https://plus.google.com/101094190333184858950/posts/cDpZDRpzJUF
[00:05] <ubot2> Launchpad bug 1056378 in gitg (Ubuntu) "gitg crashed with SIGSEGV in collapse_lane()" [Medium,Confirmed] https://launchpad.net/bugs/1056378
[00:07] <Sweetshark> if you are using git/gitg (as gnome does) you might actually personally profit from such a move.
[06:22] <mlankhorst> morningg
[06:31] <duflu> mlankhorst: Morning
[07:15] <BigWhale> Bloody skype is segfaulting on raring
[07:17] <duflu> BigWhale: What a coincidence. It does the same on iOS too
[07:19] <sarnold> feature parity!
[07:19] <BigWhale> Gotta give them some credit for that. ;)
[07:21] <BigWhale> I wish skype would die in favor of some open standard.
[07:25] <duflu> Maybe that's what it's trying to do
[07:38] <jibel> good morning
[07:38] <didrocks> salut jibel
[07:38] <jibel> salut didrocks ça va ?
[07:38] <didrocks> jibel: ça va, pas encore terminé mes emails d'hier par contre
[07:57] <robert_ancell> Sweetshark, I think that German sense of humour has failed you :) (G+ post on Mir/gource)
[08:01] <Sweetshark> robert_ancell: how so?
[08:01]  * Sweetshark looks for someone to wave a sheldon-cooper-'sarcasm'-sign.
[08:13] <mlankhorst> heheheh
[08:14] <mlankhorst> Germans have humor, it's just different from most other forms of humor. :-)
[08:14] <mlankhorst> It's more sophisticated than fart jokes!
[08:43] <robert_ancell> Sweetshark, Andrew in the previous comment got the reference..
[08:46] <seb128> hey desktopers
[09:00] <czajkowski> aloha
[09:00] <Sweetshark> robert_ancell: be careful then, next we talk about dongles on a pycon conference and then we are all fired.
[09:00] <Sweetshark> ;)
[09:00] <robert_ancell> Sweetshark, hah!
[09:53] <seb128> hum
[09:53] <seb128> tkamppeter_, hey$
[09:53] <seb128>   822 ?        Ss     0:00 /usr/sbin/cupsd -F
[09:53] <seb128>  4171 ?        S      0:00  \_ /usr/lib/cups/notifier/dbus dbus://
[09:53] <seb128>  4172 ?        S      0:00  \_ /usr/lib/cups/notifier/dbus dbus://
[09:53] <seb128>  4173 ?        S      0:00  \_ /usr/lib/cups/notifier/dbus dbus://
[09:53] <seb128> ...
[09:54] <ogra_> woah
[09:54] <seb128> $ ps aux | grep "cups/notifier" | wc -l
[09:54] <seb128> 101
[09:54] <seb128>  
[09:54] <seb128> is that a known issue?
[09:54] <seb128> is somebody else seing that?
[09:54]  * ogra_ just wanted to adjust the gigantic fonts on a new raring install ....
[09:54] <seb128> I don't even use a printer... (I've a network one configured)
[09:54] <ogra_> so i can nowe only make them more gigantic ?
[09:56] <seb128> ogra_, text should not be "gigantic" by default, but otherwise, yes, that's the GNOME design team for you
[09:57] <ogra_> text has always been way to large for  me on 1024x600 devices ... it steals a lot of screen space
[09:57] <ogra_> it was fine with the three options, "small" did about match what i would have selected ....
[09:58] <ogra_> but thats just hilarious ....
[09:58] <didrocks> sil2100: Mirv: hey, should we look at this Qt-appmenu-theme-thing now?
[09:58] <ogra_> err ridiculus
[10:00]  * ogra_ starts to look forward to the time where we ship our own setting tools with the Qt desktop  .... this is seriously getting bad
[10:00] <ogra_> (i would never have thought i'd say something like this ... )
[10:02] <seb128> hum
[10:15] <sil2100> didrocks: I need to reboot for a moment, but once I'm back, let's work on that
[10:15] <Mirv> didrocks: fine for me, sil2100 can fill in the details. I'm using the new packages without a hitch myself. qtbase is ready at  lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src and the Qt Creator is ready at     lp:~kubuntu-packagers/kubuntu-packaging/qtcreator
[10:23] <Mirv> PPA wise it's ppa:canonical-qt5-edgers/qt5-staging (qtbase, qtcreator) + ppa:sil2100/qt (libdbusmenu, appmenu)
[10:27] <didrocks> Mirv: this is having the theme fix as well, right?
[10:27] <didrocks> Mirv: you got the FFe for the plugin, is it another bug (and if so, we should treat it at the same time)
[10:29] <Mirv> didrocks: yes. and the plugin is bug #1135418
[10:29] <ubot2> Launchpad bug 1135418 in qtcreator (Ubuntu) "[FFe] Integrate Ubuntu plugin and update to 2.7 RC" [Wishlist,Triaged] https://launchpad.net/bugs/1135418
[10:30] <didrocks> Mirv: should I just take straight away your qt-creator branch and upload it?
[10:31] <sil2100> Wait wait
[10:31] <Mirv> didrocks: yes
[10:31] <sil2100> didrocks: did you get my e-mail?
[10:31] <sil2100> The one I CCd to cyphermox ?
[10:31] <didrocks> sil2100: right, I got it and read the FFe email as well
[10:31] <sil2100> I mean
[10:31] <Mirv> (for qtcreator, it's also independent from the rest)
[10:31] <didrocks> sil2100: so we need to have a look
[10:31] <didrocks> sil2100: but I'm doing the base layer testing first
[10:31] <didrocks> Mirv's qt gtk theming
[10:31] <didrocks> and qtcreator
[10:31] <didrocks> that shouldn't change, right, sil2100, Mirv?
[10:32] <sil2100> didrocks: since the double-build packages of appmenu-qt and libdbusmenu-qt have some existing small packaging bugs fixxed
[10:32] <didrocks> sil2100: yeah, do you mind having lp:~sil2100/ubuntu/raring/qtbase-opensource-src/enable-appmenu
[10:32] <didrocks> merge into the kubunut-pakcaging?
[10:32] <didrocks> lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src
[10:32] <sil2100> didrocks: no problem with that, this one seems to be the definite thing - after you confirm all is working as well ;p
[10:33] <sil2100> https://launchpad.net/~sil2100/+archive/qt <- I uploaded yesterday the new appmenu-qt and libdbusmenu-qt packages here if anyone would like to test those
[10:33] <Mirv> didrocks: I took sil2100's patch there already
[10:33] <Mirv> but sil2100 could still do a merge
[10:34] <didrocks> Mirv: oh, so the branch has sil2100's work?
[10:34] <didrocks> https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src
[10:34] <didrocks> seems so
[10:34] <Mirv> yes, because I wanted to build it myself together with the latest changes to qt5-staging
[10:34] <didrocks> excellent
[10:35] <didrocks> Mirv: sil2100: so, I'm building those 2 things first
[10:35] <didrocks> then, let's wait for cyphermox to have a look at the packaging part for appmenu-qt and libdbusmenu-qt
[10:35] <didrocks> and we can handle that
[10:35] <didrocks> sil2100: did you try as scott asked with kubuntu?
[10:35] <didrocks> to ensure we don't regress?
[10:36] <didrocks> (I don't think we will as we didn't touch the qt4 code, but better to test ;))
[10:38] <didrocks> Mirv: there is a missing changelog in your branch
[10:38] <didrocks> Mirv: 5.0.1+dfsg-0ubuntu3b1
[10:38] <didrocks> Mirv: it's a non change rebuild, if you think we should drop it, I'm fine
[10:39] <Mirv> didrocks: I can pick that up, just a moment
[10:39] <didrocks> Mirv: not mandatory, it's really as you wish :)
[10:39] <didrocks> Mirv: are you sure about the recommends?
[10:40] <didrocks> that would pull it in kubuntu if they start installing qt5
[10:40] <didrocks> let me check how we did for qt4
[10:40] <didrocks> Mirv: better to have indicator-appmenu pulling it
[10:40] <didrocks> hum
[10:40] <didrocks> yes we can :)
[10:41] <didrocks> sil2100: appmenu-qt5 doesn't dep on qt5, right?
[10:41] <didrocks> it's like appmenu-qt which doesn't dep on qt4?
[10:41] <didrocks> it's just a hook?
[10:42] <Mirv> didrocks: done.
[10:42] <Mirv> didrocks: ok, I can drop the recommends, it was directed to PPA use case where we don't have updated indicator-appmenu yet
[10:43] <didrocks> Mirv: yeah, I think we should do it that way, let me dig in for libdbusmenus-qt though
[10:45] <sil2100> didrocks: I will test with the new appmenu and libdbusmenu packages today
[10:46] <sil2100> Since I'm basically re-building the qt4 versions, so I need to check if all is ok - but on my system all Qt4 apps and qt5 apps work correctly
[10:46] <didrocks> sil2100: ok, and on the recommends thing?
[10:46] <Mirv> sil2100: I've so far been running spotify, quassel and Qt5 apps without problems. scott listed stuff that essentially means installing KDE to test as well
[10:47] <didrocks> sil2100: is libdbusmenu-qt5 dep on qt5? if so, we can make it a suggests?
[10:47] <didrocks> so that it's just a "hook" ready to be activated
[10:48] <sil2100> didrocks: well, appmenu requires Qt, but hm, libdbusmenu requires dbus qt4/qt5
[10:48] <sil2100> So in my opinion they dep on Qt, but not sure what you have in mind
[10:49] <didrocks> sil2100: we don't want to install qt5 by default
[10:49] <didrocks> sil2100: but we need to have appmenu-qt5 and libdbumenus-qt5 installed once we got a qt5 application installed
[10:49] <didrocks> (and only installing them on unity)
[10:50] <sil2100> Ah, hm, ok, makes sense
[10:50] <didrocks> I think we can install appmenu-qt5 and libdbumenus-qt5 by default
[10:50] <didrocks> recommended by indicator-appmenu
[10:50] <didrocks> but they shouldn't pull qt5
[10:50] <didrocks> do you think that's possible?
[10:51] <sil2100> I think it would be possible - how could I move the binary dependencies from Depends: to Recommends: ?
[10:52] <sil2100> Since those are automatically added by shlib deps
[10:52] <didrocks> sil2100: shouldn't be a reocmmends
[10:52] <didrocks> a recommends is installed by default
[10:52] <didrocks> ah, so they are pulled by the shlib indeed
[10:53] <Mirv> (pushed the remove of qtbase's recommends)
[10:53] <didrocks> Mirv: thanks!
[10:53] <didrocks> sil2100: I can think of a ugly hack (until we install qt5 by default)
[10:54] <didrocks> sil2100: overriding dh_gencontrol
[10:54] <didrocks> sil2100: in rules
[10:54] <didrocks> and removing it
[10:54] <didrocks> (after the call from dh_gencontrol)
[10:55] <Mirv> I think I'll close my eyes for a short while on this channel ;)
[10:55] <didrocks> :p
[10:55] <didrocks> Mirv: do you have any other idea?
[10:55] <Mirv> no, not really, sounds like it'd work
[10:55] <didrocks> we can well dh_shlibs to ignore all deps, but that's not good either :/
[10:57] <popey> hmm, software updater appears to have frozen while installing linux-image-3.8.0-15-generic:amd64 - been sat there for ~20 mins doing nothing
[10:57] <popey> nothing in /var/log/dpkg.log for 20 mins either
[10:58] <sil2100> didrocks: and then simply add the Qt5 recommends manually in control, right? Ok, will do that ;)
[10:58] <didrocks> sil2100: not a recommends again, a suggests :p
[10:59] <didrocks> 11:52:03      didrocks | sil2100: shouldn't be a reocmmends
[10:59] <didrocks> 11:52:08      didrocks | a recommends is installed by default
[10:59] <didrocks> sil2100: but yeah, tell me if you have any pb :)
[10:59] <didrocks> sil2100: also, document on debian/rules why this hack ;)
[10:59] <didrocks> sil2100: and so a branch on indicator-appmenu recommending appmenu-qt5 (which in turns, recommends/deps on libdbumenus-qt5) is needed
[11:02] <sil2100> Yea, I confuse those two ;p
[11:02] <didrocks> thanks sil2100, do not hesitate if you need any help
[11:02] <didrocks> I'm continuing on qtbase/qtcreator
[11:03] <sil2100> Will start packaging in a moment
[11:06] <didrocks> Mirv: do you mind adding some description from DEP3 to debian/patches/enable_appmenu_support.diff?
[11:06] <Mirv> didrocks: ok, will add
[11:09] <didrocks> Mirv: is 2.7RC a bug-fix only release?
[11:09] <didrocks> I would guess so
[11:11] <Mirv> didrocks: yes, beta was feature complete
[11:11] <didrocks> excellent :)
[11:11] <didrocks> building qtcreator as well
[12:19] <didrocks> Mirv: the ubuntu-sdk is depending on the the new ubuntu plugin for qtcreator?
[12:20] <didrocks> +Section: devel
[12:20] <didrocks> +Priority: optional
[12:20] <didrocks> +Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
[12:20] <didrocks> -> those are not needed, it should be in the main one (or following the rule)
[12:20] <didrocks> same for standards-version and so on
[12:20] <didrocks> we generally don't set those on a binary packge
[12:20] <didrocks> with homapages and so on
[12:21] <didrocks> Mirv: ls debian/qtcreator-plugin-ubuntu-images.tar.gz
[12:22] <didrocks> this is weird
[12:22] <didrocks> why shipping the tarball, it seems to me you applied it as a distro-patch
[12:22] <didrocks> oh, you untar te file
[12:22] <didrocks> the*
[12:23] <didrocks> Mirv: and last thing: the patches can follow DEP3 as well :)
[12:25] <didrocks> Mirv: other than that, testing it, it's cool :)
[12:25] <didrocks> Mirv: and qt is fine, thanks for the fix ;)
[12:30] <cyphermox> good morning
[12:30] <didrocks> hey cyphermox
[12:35] <Mirv> didrocks: it was depending on the plugin in the PPAs, although now temporarily removed in raring when loic moved the package to a real meta package
[12:35] <didrocks> Mirv: it should be seeded then in raring?
[12:36] <didrocks> oh, it would be
[12:36] <didrocks> Mirv: do you mind checking/tracking that?
[12:36] <didrocks> Mirv: then tell me when the rest is up
[12:36] <didrocks> I'll upload the plugin
[12:45] <Mirv> didrocks: ok, will track adding it to the seed
[12:45] <Mirv> didrocks: changes pushed
[12:46] <didrocks> Mirv: thanks!
[12:47] <Mirv> the same to you
[13:03] <desrt> g'morning, all
[13:05] <larsu> desrt: morning, how are you today?
[13:05] <didrocks> Mirv: forgot to push?
[13:05] <didrocks> hey desrt, larsu
[13:05] <larsu> hi didrocks!
[13:06] <desrt> larsu: feeling better
[13:06] <desrt> didrocks: good afternoon
[13:06] <larsu> desrt: nice :)
[13:07] <seb128> hey desrt larsu
[13:08] <desrt> i'm pretty deep into the g_object_new() rewrite, btw
[13:08] <desrt> got a couple more hours done last night
[13:09] <desrt> it's looking _very_ nice
[13:12] <desrt> not having constructor() means you can make some very nice simplifying assumptions
[13:15] <larsu> you're getting rid of constructor?
[13:15] <larsu> seb128: good afternoon :)
[13:16] <desrt> larsu: i want everyone to
[13:16] <desrt> larsu: it's a stupid function that causes a lot of wasted resources
[13:17] <Mirv> didrocks: no,  lp:~kubuntu-packagers/kubuntu-packaging/qtcreator ?
[13:20] <didrocks> Mirv: the FFe is pointing to ~timo-jyrinki/qt-creator/2.7.0rc1
[13:22] <Mirv> didrocks: ah :( I pushed to the common kubuntu-packagers - so it got updated to the final version from rc as well. updated the bug.
[13:22] <didrocks> Mirv: thanks!
[13:22] <didrocks> Mirv: ok, the changes are looking good
[13:22] <didrocks> Mirv: pushing qtcreator for now
[13:22] <Mirv> didrocks: ok, great
[13:22] <didrocks> waiting on sil2100 for the rest (installed the new qt5)
[13:23] <Mirv> awesomeness.
[13:28] <larsu> desrt: right. So now you can tell people to not use it because it'll make their code faster?
[13:31] <desrt> yes
[13:31] <desrt> as it is, very few people use it
[13:32] <desrt> and the ones that use it use it mostly for two reasons
[13:32] <desrt> well, three reasons
[13:32] <desrt> 1) because they didn't know about ->constructed() or wrote their code before it existed
[13:32] <desrt> 2) because of default value handling (fixed soon)
[13:33] <desrt> 3) [and this is a big case] because alex used it when writing the inotify file monitoring backend and the various solaris/bsd/etc. hackers that wrote backends for kqueue/fen/etc. copy/pasted his code
[13:36] <larsu> (3) is in gio though, right? (i.e. fixable)
[13:37] <desrt> yes
[13:38] <desrt> my findings of 1/2 were mostly in gtk
[13:38] <desrt> there are also some in testcases to make sure it works properly... for obvious reasons, those should stay
[13:40] <larsu> the obvious reasons being you not wanting to be blamed for breaking other people's code again? :P
[13:46] <sil2100> didrocks: pushed some changes, doing test builds to see if all is ok
[13:46] <sil2100> But having lunch now as well
[13:47] <didrocks> sil2100: enjoy :)
[13:47] <didrocks> let's see once cyphermox have the time to have a look at it
[13:50] <cyphermox> Look at what?
[13:51] <didrocks> cyphermox: appmenu-qt5 and dbusmenu-qt5 sil2100's branches
[13:51] <didrocks> (see emails)
[13:51] <cyphermox> Oh okay, still the same thing, that's what I was wondering about :-)
[13:52] <cyphermox> Will look in 5 minutes
[13:52] <didrocks> thanks :)
[14:03] <desrt> larsu: indeed i'm taking the safe path here
[14:03] <desrt> if you use constructor() then i assume that you could be doing _anything_ in there
[14:03] <desrt> so i cover my ass and performance goes down
[14:03] <desrt> (ie: lots of copies)
[14:03] <desrt> if you don't, then it's fast.
[14:04] <desrt> it basically turns into g_type_instance_create() followed by iterating a linked list doing set_property() calls for each item in the list, followed by ->constructed(), followed by iterating the passed-in parameters
[14:05] <larsu> this is the fast case??
[14:06] <larsu> I thought you were getting rid of the linked list...
[14:06] <desrt> that comes later to make the fast case even faster
[14:07] <desrt> i think it won't actually make that big of a different though, fwiw
[14:07] <desrt> it will let me avoid doing the qdata lookup for the default value on the gparamspec
[14:07] <desrt> and it will avoid all the wasted time jumping all over the heap dereferencing gslist nodes
[14:08] <desrt> but that's it
[14:08] <larsu> well, this code does get executed fairly often during program startup...
[14:08] <desrt> in the case where i actually do have a constructor it will be nicer since i actually need an array to pass in to constructor() and i will already have it in that form
[14:09] <desrt> but when there is no constructor() i just have to iterate [something] and call set_property()... may as well be an array or linked list
[14:09] <desrt> ya
[14:09] <desrt> i will probably still make the change
[14:09] <desrt> but i bet the 'big money' comes from the changes i already did
[14:09] <desrt> plus, the more important part: we're in a much better place now to start implementing default property values
[14:10] <larsu> yay \o/
[14:12] <desrt> g_object_new() was hilariously bad before... it was making copies of linked lists and crap like that
[14:15] <sil2100> didrocks: do you know maybe why even though I added a Suggests: field to debian/control, the generated packages don't have it in their control files? It seems to be removed by dh_gencontrol (or dpkg-gencontrol)
[14:15] <sil2100> Ah, I think I know
[14:16] <sil2100> Since gencontrol probably sees that the same packages are auto-generated by shlibs in Depends ;/
[14:16] <sil2100> And removes the Suggests as it's redundant
[14:16] <didrocks> sil2100: hum
[14:16] <didrocks> sil2100: no, I don't think so
[14:17] <didrocks> sil2100: did you sed for removing it from shlibs removed it from the suggests as well?
[14:17] <sil2100> Ah, wait, I know now how to do it better, thanks for the pointer ;)
[14:20] <Mirv> didrocks: ok, qtcreator has now built for amd64 and i386 and in NEW. you perhaps don't approve your own uploads from the queue, or how's the process?
[14:21] <didrocks> Mirv: no, I'll let seb128 doing so, if he has time ^
[14:21] <didrocks> binNEW FYI
[14:21] <seb128> looking
[14:21] <Mirv> alright, I was thinking about seb as well
[14:24] <qengho> kenvandine: yo.  What do you make of Bug#1153137?
[14:25] <seb128> Mirv, didrocks: done
[14:25] <didrocks> thanks seb128
[14:26] <Mirv> thanks seb128
[14:27] <qengho> seb128: I need your advice too.  Bug 1153137.  We want Unity and Chromium users to get webaccounts-chromium-extension and unity-chromium-extension, so I was told to Recommends them.  The problem is that they have Depends that pull in all sorts of things that users without unity do not want.
[14:27] <ubot2`> Launchpad bug 1153137 in webaccounts-browser-extension (Ubuntu Raring) "Please remove recommends on webaccounts-chromium-extension and unity-chromium-extension" [Wishlist,Triaged] https://launchpad.net/bugs/1153137
[14:28] <seb128> qengho, hum
[14:28] <seb128> I would revert micahg's change as a first offhand suggestion
[14:29] <seb128> but let me think about it
[14:29] <qengho> I think I could use alternation to satisfy it logically, but that is UGLY.  Recommends: unity-extension|somethinginlubuntuonly
[14:29] <qengho> Terrible.
[14:29] <seb128> it's not a problem for lubuntu since they don't install recommends
[14:29] <qengho> Right.
[14:30] <qengho> foobuntu whatever will.
[14:30] <seb128> well, you will never cover all the !unity cases like that
[14:30] <qengho> Agreed.
[14:32] <seb128> I don't have a good idea
[14:32] <seb128> imho we should optimize for the most common case and revert micahg's upload for raring
[14:32] <seb128> nobody is forced to install recommends
[14:33] <qengho> "Enhances" does nothing in our favor here, does it?
[14:33] <seb128> no
[14:34] <kenvandine> qengho, yeah, that is a tricky kind of issue to deal with
[14:35] <sil2100> didrocks, Mirv: I pushed the new packages to build on ppa:sil2100/qt
[14:35] <didrocks> ok
[14:35] <didrocks> sil2100: indicator-appmenu is changed as well?
[14:37] <sil2100> didrocks: now it is ;p
[14:38] <sil2100> Should I push it to that PPA as well?
[14:38] <sil2100> https://code.launchpad.net/~sil2100/indicator-appmenu/indicator-appmenu-qt5
[14:38] <didrocks> sil2100: as you wish, I won't test it TBH, but let cyphermox making all those reviews :)
[14:38] <didrocks> cyphermox: if we can get it before the freeze today, that would be awesome ^
[14:39] <didrocks> sil2100: so appmenu-qt5 is depending on libdbusmenu-qt5, right?
[14:39] <didrocks> which itself is hacked to not dep on qt5
[14:39] <didrocks> am I right?
[14:40] <sil2100> didrocks: right!
[14:40] <didrocks> excellent! :)
[14:40] <didrocks> thanks a lot sil2100
[14:41] <sil2100> didrocks: both libdbusmenu-qt5 and appmenu-qt5 suggest qt5, since both theoretically need it, while appmenu-qt5 depends on libdbusmenu-qt5
[14:41] <Mirv> sil2100: thanks, the diff:s look good
[14:41] <didrocks> sil2100: excellent!
[14:41] <sil2100> didrocks: np. ;p Hope cyphermox won't laugh on my kiddy regexp's ;<
[14:41] <didrocks> ;)
[14:41]  * sil2100 sucks at regular expressions
[14:41] <didrocks> sil2100: hum
[14:41] <didrocks> sil2100: on the MP
[14:42] <didrocks> please add the bug #
[14:42] <didrocks> for the FFe
[14:42] <didrocks> and add the component as well
[14:55] <sil2100> didrocks: you mean, the MP to respective trunks?
[14:55] <didrocks> sil2100: I mean in the indicator-appmenu MP you did
[14:55] <sil2100> ACK
[15:01] <cyphermox> sil2100: wanna propose merges now for your branches?
[15:02] <cyphermox> sil2100: with the exception of your removal of the comments for Vcs-Bzr in debian/control, and the weird makeshlibs override things look good
[15:02] <cyphermox> and I already looked at dbusmenu-qt before for you :)
[15:11] <sil2100> ;)
[15:12] <sil2100> cyphermox: how should I handle dbusmenu-qt btw.? Since I made the packaging inline... should I simply divide it and do one merge request for trunk and one for the packaging branch?
[15:12] <sil2100> Since right now it's still not inline
[15:20] <sil2100> cyphermox: I'll re-add the Vcs-Bzr then ;p I removed it when I was doing a seperate package it seems
[15:21] <cyphermox> sil2100: yeah, just readd the comment above Vcs-Bzr and Vcs-Browser
[15:22] <cyphermox> if you want to make it just a merge straight with inline, assuming you have mostly changes for the packaging and not too many direct other changes
[15:22] <cyphermox> otherwise, two merges -- one for the trunk stuff, and one that adds debian/ and includes your packaging
[15:22] <cyphermox> I'll review it all :)
[15:22] <sil2100> ACK ;)
[15:35] <jasoncwarner_> hey cyphermox kenvandine, didrocks tells me we are "this close" to having the qt stuff in....just needs to get good reviews from you guys today (freeze is after today)...can you guys make sure you get him your reviews of that stuff today?
[15:37] <ogra_> jasoncwarner_, s/after today/today at 21:00 UTC/
[15:37] <ogra_> (but they know that :) )
[15:40] <mlankhorst> \o/  nouveau doesn't have the msot bugs in the workqueue
[15:41] <seb128> xnox, that indicator-datetime merge request sounds like a feature ... do you have a ffe and a description of why it's needed?
[15:43] <xnox> seb128: it adds more clickable/pinnable dots on the map. No other changes. No I do not have FFe for it, nor description. Only the OEM priority bug meaning that apart from 418 blessed locations, nobody can click any other place on the map.
[15:43] <seb128> xnox, seems like a feature to me ;-)
[15:44] <seb128> code wise at least
[15:44] <xnox> the zonetab info for any location with population >15000 & and an extra api call to store the location name got added in the libtimezonemap (in raring now)
[15:45] <seb128> it's going to be fun to "pick" between 2 close > 15000 cities by clicking on that map without zoom
[15:46] <xnox> seb128: at the moment it is "funny" as we do not sort and pick the largest one in 10x10px area.
[15:46] <xnox> hmm.... the cd will get 4MB of bloat.... but it should compress well.
[15:47] <xnox> (4mb of plain txt)
[15:47] <xnox> let me poke mpt about zoom.
[15:47] <seb128> xnox, france is like 15x15 on that map, the mouse pointer is as big as the country
[15:48] <seb128> xnox, I'm not sure how the finer granularity will "help"
[15:49] <xnox> seb128: it actually works nice for china =)))) but again china is huge ;-)
[15:49] <seb128> xnox, yeah, so maybe you should pick town > 1M people
[15:49] <seb128> not 15000
[15:49] <xnox> seb128: the current behaviour in the installer is to cycle trhough "timezone" cities in the 10x10px proximity.
[15:50] <xnox> seb128: I think the rationale behind 15000 was that this is what Mac OS X has.
[15:51] <xnox> but that makes sense for text-entry search, but not point and click interface.
[15:52] <cyphermox> jasoncwarner_: yes
[15:52] <xnox> jmleddy doesn't seem to be in this channel....
[15:53] <xnox> Hmm that info has translated names as well.
[16:03] <sil2100> cyphermox: in the appmenu-qt and libdbusmenu-qt changes in the changelog... should I also add there the bug number of the appmenu-qt5 bug?
[16:03] <sil2100> Or is it not necessary to have that in the changelogs of those two?
[16:07] <xnox> seb128: can you reject for 13.04 for now, but somehow merge it into trunk and we will interate about it in the beginning of the S-cycle?
[16:07] <xnox> seb128: also I noticed trunk & 13.04 are diverging at the moment?
[16:08] <qengho> seb128, kenvandine, someone suggested Depending on those cr-b--specific packages in unity package (if they're not very large).
[16:09] <seb128> qengho, that's buggy, that would had them to the CD where we don't have chromium
[16:11] <seb128> xnox, how diverging? you mean some commits are missing in trunk?
[16:11] <seb128> xnox, I can reject for 13.04, your call, I'm not maintaining indicator-datetime, mostly watching
[16:11] <qengho> seb128: Yeah.  They're 47kB and 146kB.
[16:12] <seb128> qengho, they don't depends/recommends on chromium?
[16:13] <qengho> seb128: they do for now, but that can be changed.
[16:13] <qengho> Enhances.
[16:13] <seb128> that seems buggy
[16:13] <seb128> micahg, there?
[16:13] <qengho> xnox: you too^
[16:13] <xnox> seb128: for example systemd stuff is missing in trunk.
[16:14] <seb128> xnox, right, will merge propose it there
[16:14] <seb128> not sure why they branched yet since there is no feature work
[16:15] <xnox> seb128: there is no way to define in apt: if these two packages are installed, install this one as well. And to have it by default when unity+chromium is installed, it's best to make unity depend on the chromium-extenstions (which will do nothing if chromium is not installed). And make chromium-extenstions "enhance" chromium.
[16:15] <seb128> xnox, that will make the chromium extension be installed for all firefox users...
[16:15] <xnox> seb128: i guess unity should "recommend" unity-chroium-extenstions, or simply seed the unity-chromium-extensions into ubuntu-desktop.
[16:16] <xnox> seb128: yes, hence the they "will do nothing if chromium is not installed"
[16:16] <infinity> They should just be seeded in a () seed for desktop.
[16:16] <seb128> xnox, well, you can also keep the recommends and say they will do nothing for non unity users
[16:16] <xnox> seb128: there is no other way to guarantte that they will be installed when both chromium & unity are present.
[16:16] <infinity> seb128: No, they pull in a ton of cruft that other DEs don't want.
[16:17] <qengho> webaccounts ext 47kB and unity ext 146kB.
[16:17] <seb128> infinity, we could fix that
[16:17] <seb128> infinity, just make them pull nothing and no work if unity is not installed
[16:17] <infinity> seb128: So, because you want to force them to be installed for a unity+chromium case, you'll force all non-unity users to install it?  That's backward.
[16:18] <infinity> seb128: The onus is on the people who want this to take the burden, not to force it on others.
[16:18] <sil2100> cyphermox: merge requests submitted \o/
[16:18] <sil2100> cyphermox: could you take a look at those?
[16:18] <cyphermox> sil2100: awesome, I was just refreshing to see :)
[16:18] <infinity> seb128: And for 200kB, I'm not sure why it's a big deal to just have ubuntu-desktop recommend them.
[16:18] <sil2100> cyphermox: https://bugs.launchpad.net/libdbusmenu-qt/+bug/1126205 <- you have all the links here
[16:18] <ubot2`> Launchpad bug 1126205 in indicator-appmenu "[FFe] Bring Unity appmenu / HUD integration to Qt5" [Undecided,In progress]
[16:18] <sil2100> Phew
[16:19] <seb128> infinity, is there more non-unity users to force that on or more non-chromium users
[16:19] <seb128> infinity, by putting them on the CD you force all defaults install to have extensions for browser we don't ship by default
[16:19] <seb128> that doesn't make sense either
[16:19] <infinity> seb128: There are desktops that ship chromium as their default browser.
[16:19] <cyphermox> sil2100: thanks
[16:19] <seb128> infinity, not ubuntu-desktop
[16:19] <infinity> seb128: Yes, and?
[16:19] <seb128> infinity, so chromium extensions don't make sense there, since we ship firefox
[16:20] <sil2100> cyphermox: thank you!
[16:20] <infinity> seb128: And unity extensions don't make sense for other people. :P
[16:20] <infinity> seb128: You want this.  You don't get to tell them to "just deal with it".
[16:20] <seb128> right
[16:20] <seb128> we should optimize for the default case though
[16:20] <seb128> e.g what's best for the higher number of users
[16:20] <seb128> and afaik the default install is that
[16:21] <infinity> And the "default" case is how all those desktops ship out of the box.  Forcing others to have unity stuff installed on their non-unity desktops isn't optimised.
[16:21] <seb128> I don't want to force anything on others
[16:21] <infinity> Asking you to install 200k of dormant code isn't world-ending, if you feel users MUST have it when chromium is installed.
[16:21] <seb128> but I don't want those extensions to be forced on firefox users either
[16:21] <xnox> qengho: do these extensions for with google chrome?
[16:21] <xnox> s/for/work for/
[16:22] <xnox> Cause google chrome is outside of ubuntu archive and unity users ideally should get webapps support with google chrome.
[16:22] <xnox> Same for chromium from daily ppa (if that is still running)
[16:23] <xnox> seb128: those extenstions are not forced on firefox users, but proposed to be forced on unity users. Please use the right subsets =) cause firefox users is an odd way to define as well, since many kubuntu installs use firefox.
[16:23] <xnox> seb128: you really mean forcing chromium extension for all unity users.
[16:24] <seb128> right
[16:24] <qengho> Geez, I'm sorry guys.  I didn't think this was pandora
[16:24] <qengho> s box.
[16:24] <infinity> Which is probably not a big deal.
[16:24] <seb128> well, first it's not "forcing", it's a recommends
[16:24] <xnox> as I said, there is no way to define "if X and Y are installed, pull in Z" hence either X or Y will loose in this situation.
[16:24] <seb128> infinity, it's not a big deal either to make chromium ship those and do nothing out of unity
[16:25] <seb128> xnox, right, and I argue that we should base the choice on what's best for the default install
[16:25] <infinity> seb128: Except that they're for unity integration.  And depend on some common framework stuff from unity webapps.
[16:25] <xnox> seb128: apart from unity / webapps folks should be maintining them =)
[16:25] <seb128> because that's the most likely configuration
[16:26] <infinity> seb128: If you honestly think having them on other flavour's CDs (or even shipped directly with chromium!) is no big deal, why is it a big deal to just have them on the ubuntu-desktop install?
[16:26] <xnox> seb128: if chromium depends on the extensions, those extensions will have drop depends on unity-*, as we don't want unity to be pulled in when chromium is installed.
[16:26] <seb128> infinity, I think it's an equal issue both way and that we should take the decision that's best for the majority of users
[16:26] <seb128> which is probably "stock ubuntu"
[16:26] <infinity> seb128: And "optimising for the default install" is a hard pill to swallow when it's coming from someone who defines the default install.
[16:27] <infinity> seb128: Maybe if the other flavours agreed with your view. :P
[16:27] <seb128> well
[16:27] <infinity> seb128: And no, it's not an equal issue either way, as this is a *change* being imposed by ubuntu-desktop/unity-webapps on others.
[16:27] <seb128> we can't undermine the experience for 90% of users just because there are 10% of users that might not like it
[16:27] <xnox> seb128: it's not equal. The extenstions in question depend on unity-webapps-service & libaccounts-glib, gnome-control-center-signon. None of which should become a dependancy of chromium.
[16:28] <seb128> xnox, I said "if we drop those depends and make the extension do nothing when they are not installed" if you read correctly
[16:28] <seb128> I didn't suggest to make chromium pull in g-c-c-signon
[16:29] <xnox> seb128: ok.
[16:29] <seb128> infinity, xnox: by the logic of "let's install <foo>-unity on the CD so unity integration work for foo if somebody ever goes to install foo" we could justify pulling hundred of random binaries on the CD
[16:29] <infinity> I still think "we don't think asking all chromium users to install 200k they don't need is a big deal, but we absolutely can't have that 200k in our precious desktop, despite the fact that we're the ones dictating this" is a ridiculous justification.
[16:30] <seb128> I don't think the default install should ship all the possible integration with unity bits
[16:30] <seb128> just in case they might be useful to somebody one day
[16:30] <seb128> infinity, it's only 200k, but you can make the same argument for another 15 sources
[16:30] <infinity> seb128: No, but we don't have a good solution for random integration bits in general, and the answer has never been "just install them all and see what happens".
[16:30] <xnox> seb128: from my point of view we have N amount of dependencies, and we are going to make some of them "implicit"/weak, ideally I'd want the minimal amount of package become weak dependencies. As undeclared dependenices are not considered by api/abi transitions and britney and installability tests.
[16:30] <seb128> infinity, it has never been, yet it's the path you are taking there
[16:31]  * xnox should not bring up 100 scopes right....
[16:31] <infinity> seb128: In this case, it looks like ubuntu-desktop is demanding those bits be there in the unity/chromium case, so how is that up to anyone but ubuntu-desktop to get them there?
[16:31] <infinity> seb128: No, it's not the path I'm taking, it's the path you're taking.  We don't normally force integration plugins on anyone for this very reason.
[16:31] <seb128> infinity, I didn't say it's fine, but the reverse proposal is equally not fine
[16:32] <infinity> seb128: But you want to have your cake and eat it to.  You want to force them with no burden on the ubuntu desktop, but burden on others.
[16:32] <xnox> seb128: reverse proposal is status quo => people must manually install the integration plugin.
[16:32] <seb128> ok
[16:32] <seb128> let's go with that then
[16:32] <infinity> seb128: Neither is fine, but the only proposal that's not distasteful is the one that doesn't force it on non-ubuntu desktops.  (or, yes, not installing it by default at all)
[16:32] <seb128> it's just a shame that we compromise on our default desktop integration like that
[16:33] <seb128> infinity, you proposed change will "force those binaries" on more users than the one that "force it on non-ubuntu desktops"
[16:34] <seb128> assuming that we have more people running our default desktop (and firefox with it)
[16:34] <xnox> seb128: to me firefox is a compromise on the default desktop. chromium should have been the default browser long time ago.....
[16:34] <xnox> but I am biased.
[16:34] <infinity> xnox: You'll start a holy war with that one. ;)
[16:34] <infinity> xnox: Besides, you're an emacs user, your opinions don't count.
[16:34]  * xnox emacs rocks as well!
[16:34] <xnox> snap
[16:35] <seb128> we should install emacs-unity on the CD
[16:35] <seb128> :p
[16:35] <seb128> just in case our users install emacs, so they can get unity integration ;-)
[16:36] <infinity> *shrug*... I'd be just as happy tearing out all the webapps stuff completely.  I always click the little X and opt out anyway. :P
[16:37] <seb128> I wish we still had the CD limit
[16:37] <seb128> people wouldn't come arguing that it's fine to just start adding crap to the image
[16:37] <chrisccoulson> infinity ;)
[16:37] <infinity> (Or anyone else's image)
[16:37] <infinity> (snap)
[16:37] <qengho> seb128: have we any consensus?  I need to decide in the next hour.
[16:37] <seb128> that's the reason we fought to keep the CD limit all that time :-(
[16:38] <infinity> chrisccoulson: Hey.  Did you get anywhere with chromium/armhf?  We're nearing a zero hour here.
[16:38] <seb128> infinity, is there any flavor using chromium and installing recommends on their CD?
[16:38] <infinity> chrisccoulson: I'm going to have to just remove it from the archive soon.  Which is pretty suboptimal. :/
[16:38] <chrisccoulson> infinity, it's built in the canonical-arm-dev PPA (well, for 12.04)
[16:38] <infinity> seb128: Yes.
[16:38] <seb128> infinity, which one?
[16:38] <infinity> chrisccoulson: I can haz for raring?
[16:39] <mlankhorst> seb128: well i still have to worry about the limit for x :/
[16:39] <chrisccoulson> infinity, sure. please check with qengho too :)
[16:39] <infinity> seb128: lubuntu and mythbuntu.
[16:39] <infinity> chrisccoulson: I'm less picky about who uploads it, but I want it before beta...
[16:39] <infinity> chrisccoulson: So, like... Nowish, ideally. :P
[16:40] <chrisccoulson> infinity, well, qengho is working on the next chromium version ;)
[16:40] <chrisccoulson> (26)
[16:40] <infinity> I'm not against it being uploaded twice.  Just sayin'.
[16:41] <xnox> seb128: actually emacs is blacklisted in the global-menu code as it doesn't work.
[16:41] <xnox> seb128: we have ~800MB limit on the phone.
[16:44] <seb128> infinity, micahg stated on this bug that lubuntu doesn't install recommends by default
[16:44] <seb128> but anyway
[16:45] <infinity> Fair enough.  mythbuntu does.
[16:45] <seb128> they are GNOME based and have g-c-c etc though :p
[16:46]  * infinity suspects he should go back to his vacation before this gets circular.
[16:46] <seb128> but, let's take the hint on ubuntu-desktop since people seems to prefer to optimize the experience for the non default case
[16:46] <seb128> it's a bit annoying that we keep undermining our main "product" this way
[16:46] <infinity> I'm not sure why you're being so bitterly sarcastic about a change that ubuntu-desktop wants to impose on others.
[16:47] <infinity> That's not "taking the hit", it's "not forcing a hit on others".
[16:47] <seb128> infinity, I don't care about others, I want a great Ubuntu Desktop
[16:47] <infinity> Well, the default Ubuntu Desktop is Firefox.
[16:47] <infinity> So, it's a bit of a moot point, isn't it?
[16:48] <seb128> well, you make me add chromium extension to a product that ships firefox
[16:48] <seb128> see the flaw :p
[16:48] <infinity> I'm not making you do anything.  You could just not ship them at all.
[16:48] <infinity> Which was what the bug initially proposed.
[16:48] <seb128> I'm pondering it
[16:48] <seb128> but it sucks that in any case it's a loose-loose for our default desktop
[16:49] <seb128> both options are the non-ideal for ubuntu-desktop
[16:49] <seb128> either we install something we don't need, in case people opt for an alternative browser
[16:49] <seb128> or we make people who opt for chromium not get integration
[16:50] <seb128> qengho, we agreed to keep the recommends out of chromium-browser if that's the decision you needed btw ;-)
[16:50] <seb128> qengho, I'm not sure if we should add the recommends to ubuntu-desktop though :-(
[16:56] <xnox> bug 1085536
[16:56] <ubot2`> Launchpad bug 1085536 in firefox (Ubuntu) "Xubuntu has firefox-globalmenu package witch it cant use" [Low,Won't fix] https://launchpad.net/bugs/1085536
[16:57] <xnox> bug 1085535
[16:57] <ubot2`> Launchpad bug 1085535 in thunderbird (Ubuntu) "Xubuntu has thunderbird-globalmenu package witch it cant use" [Undecided,Invalid] https://launchpad.net/bugs/1085535
[16:58] <xnox> merged in the default packages firefox/thunderbird, so a bit moot and doesn't help with chromium case either.
[16:58] <chrisccoulson> those 2 bugs were ridiculous. as i said in my first comment, if the functionality had been implemented where it belonged in the first place (inside firefox rather than a separate addon), people wouldn't be wasting time talking about 50kB
[16:59] <chrisccoulson> so that's what i've done
[16:59] <seb128> chrisccoulson, who implemented the first menu integration? ;-)
[16:59]  * chrisccoulson hides
[16:59] <seb128> :-p
[17:00] <chrisccoulson> the addon was actually a good idea at the time, as it was a lot easier to work on ;)
[17:00] <chrisccoulson> but it's not a good idea now, and we ship far too many addons by default in firefox
[17:00] <chrisccoulson> kill them all :)
[17:01] <seb128> chrisccoulson, speaking of which, we should enable the unity integration by default
[17:15] <chrisccoulson> jibel, any idea what happened here? https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/ARCH=i386,label=adt/
[17:15] <chrisccoulson> it almost looks firefox isn't installed during the tests
[17:25] <jibel> chrisccoulson, that's what I thought too but from the logs it has been unpacked and configured
[17:25] <jibel> "Setting up firefox-trunk (22.0~a1~hg20130328r126467-0ubuntu1~umd1) ..."
[17:29] <chrisccoulson> jibel, oh, i wonder if this has anything to do with it? https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+build/4406493
[17:29] <chrisccoulson> no log though ;)
[17:32] <chrisccoulson> ok, i've retried that build. no idea why just that one failed, and not having a log doesn't help much :/
[17:39] <jibel> chrisccoulson,  okay, we'll see with next build. If it occurs again I'll save the VM to check what's in there
[17:56] <Sweetshark> seb128: around?
[17:57] <seb128> Sweetshark, yes
[17:59] <Sweetshark> seb128: LO4.0.2~rc2 is currently building in my ppa, do you see any chance to make it into raring still? It would be worthwhile, but seems to be really tricky to me ...
[17:59] <seb128> Sweetshark, you suggest shipping raring with rc2?
[17:59] <seb128> Sweetshark, does "rc2" mean "will be flagged 4.0.2 if no issue found"?
[18:00] <Sweetshark> yes
[18:00] <Sweetshark> week 14 -- that is next week
[18:02] <seb128> 4.0.2 is only bugfix over what we have right?
[18:02] <Sweetshark> I will put the version in the ppa for testing, when it finishes and shows no obvious errors on installing from the ppa (tomorrow, I guess).
[18:02] <Sweetshark> yes, 4.0.2 is only bugfixes.
[18:03] <Sweetshark> (policy is: commit to master, get one review for backport to 4.0 branch pre-rc1 and two review for backports after ~rc1)
[18:05] <Sweetshark> if we try this, I would like to ask bdrung to start reviewing it now, as it is tight already.
[18:07] <Sweetshark> fwiw I am less concerned about upstream changes at this point -- they are very conservative, but _rene_ changes can be more of an risky: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=shortlog;h=refs/heads/debian-experimental-4.0
[18:12] <Sweetshark> luckily me and ricotz had a look at that too already and 4.0.2~rc1 is in the ppa for raring, quantal, precise, lucid. There was one packaging regression caused by http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commit;h=403a11e07e693a0d0f8143cd16f8022b72cec127 and that was found quick and is fixed now.
[18:14] <sarnold> Sweetshark: is that "meil" typo in control.transitionals.in also removed?
[18:14] <sarnold> .. and also the "now.You" typo?
[18:15] <seb128> Sweetshark, beta2 freeze is in some hours, I can still upload today if you want
[18:16] <seb128> Sweetshark, if bdrung is not around
[18:17] <Sweetshark> sarnold: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=control.transitionals.in;h=39924fd641d283780a632f8e9803669ba87d298d;hb=084972c11adbe34703d01539db40ced7eaa0770b <- "meil", yes it seems. "now.You", no.
[18:18] <sarnold> Sweetshark: d'oh :) you win some, you lose some. hehe.
[18:19] <Sweetshark> seb128: nope, uploading it now is too early. Lets ship 4.0.1 then and possibly do a SRU later.
[18:20] <seb128> Sweetshark, well, we might still have a shoot next week
[18:20] <seb128> Sweetshark, let's try to put it in a ppa for the easter w.e and see next week
[18:21] <didrocks> seb128: it's a Friday upload!
[18:21] <Sweetshark> seb128: I usually dont feel comfortable if a version did not sit in the ppa for one week, and this didnt yet. http://people.ubuntu.com/~ricotz/libreoffice/libreoffice-ppa-stats.pdf shows a week gives you ~50.000 test installs, which should be good.
[18:21] <seb128> didrocks, that's fine, some people work on saturday and can fix stuff :p
[18:22] <Sweetshark> didrocks: I heard you work on Saturdays?
[18:22] <didrocks> seb128: well, some people have to make France having less debt you know :p
[18:22] <didrocks> because of all those germans! :-)
[18:22] <didrocks> … who are taking Friday off!
[18:22] <Sweetshark> seb128: yes, next week feeks a lot better to make the call.
[18:24] <Sweetshark> didrocks: we germans need friday to spend the money we ripped off the cypriots, you know ...
[18:25] <didrocks> Sweetshark: oh right! :-)
[18:25] <didrocks> Sweetshark: see how you are, it's because of this pression that we have to ship horse as beef!
[18:25]  * mlankhorst is taking friday off
[18:28] <Sweetshark> sarnold: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=298e260e5e0a6a40e010efe904a4abe2c1778e3e;hp=084972c11adbe34703d01539db40ced7eaa0770b <- here is your vanity commit ;)
[18:29] <mlankhorst> but I have monday off as a national holiday too, so long weekend for me \o/
[18:39] <mterry> No one is going to be around this weekend?
[18:39]  * mterry will sit here all alone
[18:42] <seb128> mterry, you will have didrocks tomorrow and monday
[18:42] <didrocks> mterry: \o/
[18:42] <mterry> yay
[18:43] <Sweetshark> mterry: that will give you time to ponder the liblangtag MIR ;)
[18:43] <mterry> Sweetshark, I commented!
[18:44]  * didrocks waves good evening (and good week-end for **some**)
[18:44] <mterry> Sweetshark, don't you be bringing ftbfs MIRs in *my* house ::thumps chest::
[18:44] <didrocks> (shame on them!)
[18:44] <mterry> didrocks, see ya
[18:44] <didrocks> mterry: see you tomorrow :)
[18:44] <Sweetshark> mterry: lol
[18:45] <Sweetshark> mterry: will fix that. its for raring+1 anyway.
[18:45] <mterry> Sweetshark, oh, cool
[18:46] <mterry> Sweetshark, I like how libreoffice is a vector for new packages in main.  Like, if I wanted to MIR random-package, I just have to get you to upload it as part of libreoffice first, then the mir is trivial
[18:46] <mterry> tsk tsk
[18:47] <Sweetshark> mterry: yeah, I should just build-dep on all the stuff I like and then make you guys support it for me.
[18:47] <mterry> :)
[18:49] <Sweetshark> .oO(LibreOffice surely needs to depend on vim. and on mutt -- just to satisfy zawinskis law. it doesnt matter that these are in main, I just want to make sure they _stay_ there.)
[18:52] <mterry> :)
[19:04] <tkamppeter> seb128, hi
[19:06] <seb128> tkamppeter, hey
[19:17] <Sweetshark> seb128: who can take care of my pet bug 1056378 btw? ;)
[19:17] <ubot2`> Launchpad bug 1056378 in gitg (Ubuntu) "gitg crashed with SIGSEGV in collapse_lane()" [Medium,Confirmed] https://launchpad.net/bugs/1056378
[19:17] <Sweetshark> it has a nice little bzr branch with the fix attached.
[19:24] <Trevinho> seb128: lool was proposing to rename bamf.index with something like bamf-format-version.index, are you ok and can we do this without touching other things?
[20:01] <seb128> Trevinho, that would make sense if anything else was using the index, but I don't think that's the case
[20:01] <seb128> Trevinho, don't bother for raring, we can think about it over time if needed
[20:02] <seb128> Sweetshark, why not doing it yourself? could be a first step to motu for you ;-)
[20:03] <seb128> or try chrisccoulson, so we can push him to apply for upload rights ;-)
[20:03] <seb128> but I could on mdeslaur and the security team to hint him to get there ;-)
[20:05] <mdeslaur> chrisccoulson: a nice juicy steak and a pint for you if you apply for core dev.
[20:05] <mdeslaur> seb128: done
[20:05] <seb128> mdeslaur, \o/, you just won a pint ;-)
[20:06] <mdeslaur> hehe
[20:28] <cyphermox> seb128: poke
[20:28] <cyphermox> still around?
[20:30] <seb128> cyphermox, hey
[20:33] <cyphermox> seb128: uploading the stuff for qt
[20:33] <cyphermox> I did qt already, finishing up with appemnu-qt and libdbusmenu-qt
[20:33] <seb128> cyphermox, oh, nice
[20:33] <cyphermox> will need help for binnew
[20:33] <cyphermox> yeah but there's delay
[20:34] <cyphermox> can you do magic build prodding? https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3052394/+listing-archive-extra
[20:38] <seb128> cyphermox, sorry but I can't :-(
[20:39] <seb128> try asking on #ubuntu-devel
[20:39] <cyphermox> I'll just wait
[20:39] <cyphermox> heh
[20:39] <seb128> doko, infinity and others can
[20:39] <cyphermox> people should have been done with their stuff before
[20:39] <seb128> I'm "just" archive admin
[20:39] <seb128> no buildd admin
[20:40] <cyphermox> ok
[20:56] <desrt> seb128: begin your long weekend already :)
[20:57] <seb128> desrt, "soon" ;-)
[21:45] <robru> TheMuso, ping
[22:10] <xnox> seb128: mhr3: so where do you want the .scope files be located in the app-install-data package?
[22:11] <xnox> or rather where does the software center expects them to be?
[22:11] <xnox> /usr/share/app-install/scopes/ ?
[22:11] <seb128> xnox, no idea
[22:12] <xnox> I don't see any code / branches related to software-center about it....
[22:12] <xnox> to check.
[22:12] <seb128> xnox, it's thurday 11pm for europe, I guess that can wait next week, you should call it a week as well ;-)
[22:12] <seb128> xnox, the new scope stuff got postponed to after raring, so no hurry
[22:12] <xnox> I'll throw a package together into a ppa and then people can twiddle with it.
[22:13] <seb128> ok