[01:22] <jbicha> oops, it looks like seb128 broke gnome-control-center with his last upload, bug 1081826
[01:22] <ubot2> Launchpad bug 1081826 in gnome-control-center (Ubuntu) "gnome-control-center crashes with gtk warning" [Critical,Confirmed] https://launchpad.net/bugs/1081826
[01:23] <jbicha> I didn't care much for that navigation bar patch any way
[01:24] <desrt> jbicha: what are you plans with regards to seb's plans for the control center?
[01:25] <jbicha> well I'm annoyed that that patch came back and isn't Unity-specific
[01:25] <desrt> ready to throw in the towel yet?
[01:26] <jbicha> I'm not sure we need ibus 1.4.99 yet
[01:26] <maxiaojun> hi
[01:26] <maxiaojun> can i test your above mentioned stuff using raring daily image?
[01:27] <jbicha> maxiaojun: sure, but you'll need to grab gnome-control-center 1:3.6.3-0ubuntu2 as ubuntu3 is broken
[01:28] <maxiaojun> ok
[01:31] <jbicha> maxiaojun: but I'm sure it will be fixed tomorrow
[01:31] <maxiaojun> just for record, official ibus channel is #ibus, same net
[01:31] <maxiaojun> ok, i will try it inside VirtualBox anyway
[01:33] <jbicha> desrt: not quite yet
[01:50] <maxiaojun> btw, tomorrow in which timezone?
[01:52] <sarnold> maxiaojun: probably Europe/Paris
[01:54] <maxiaojun> ok
[02:03] <maxiaojun> concerning two keyboard indicator issue, ibus 1.4.99 may be a chance to fix it
[03:58] <cyphermox> achiang: no, it wasn't *yet*, it's on my list, but the list is huge :'(
[03:59] <achiang> cyphermox: i'm building a test package now
[03:59] <achiang> cyphermox: or at least attempting to... see my question in #u-devel?
[03:59] <achiang> cyphermox: (aka hopefully i can offload this from you)
[04:03] <cyphermox> I didn't see it, did you ping me? I didn't get a highlight :)
[04:04] <cyphermox> got it :P
[04:10] <achiang> cyphermox: backporting r364 was easy. i'm doing a test build now, and then i'll see about also importing some of the other patches related to leaks from upstream's history
[04:11] <cyphermox> sure. feel free to ask if you're unsure. but the other one you mentioned is still buggy
[04:11] <achiang> cyphermox: which other one?
[04:12] <cyphermox> g_string_append, that line 432 in src/applet-device-wifi.c
[04:12] <cyphermox> or at least, it could be better
[04:12] <achiang>         if (is_encrypted) {
[04:12] <achiang>                 icon_desc = g_string_append (icon_desc, ", ");
[04:12] <achiang>                 icon_desc = g_string_append (icon_desc, _("secure."));
[04:12] <achiang>         }
[04:12] <achiang> that bit?
[04:14] <cyphermox> yup
[04:15] <cyphermox> could just as easily be a g_string_append_printf as above rather than two calls :)
[04:17] <achiang> package built fine, so i can send up an MP soon
[04:17] <achiang> not super familiar w/SRU paperwork process though
[04:19] <cyphermox> achiang: basically, just follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[04:19] <cyphermox> updating the package description and subscribing ubuntu-sru
[04:19] <achiang> cyphermox: ok, will give it a shot
[04:19] <achiang> hopefully this makes your life easier
[04:19] <achiang> :)
[04:20] <cyphermox> ping me if you need help with nominating the package for the release
[04:20] <achiang> alrighty
[04:24] <cyphermox> achiang: I really appreciate the help
[04:24] <achiang> cyphermox: maybe one day i'll become motu. :)
[04:24] <achiang> wish i had more time to work on distro
[04:24] <cyphermox> careful what you wish for ... :)
[05:00] <achiang> cyphermox: https://code.launchpad.net/~achiang/network-manager-applet/precise-lp780602/+merge/135586
[05:37] <pitti> Good morning
[05:39] <maxiaojun> pitti is the author of jockey and u-d-c ?
[05:39] <pitti> maxiaojun: yes
[05:40] <maxiaojun> cool, two things
[05:41] <maxiaojun> 1. can ubuntu provide a graphical hardware lister instead of requiring people to use 'lspci' ? do you agree with the concept?
[05:42] <maxiaojun> 2. as i asked in previous mailing-list thread, some wifi chips still need b43, can jockey / u-d-c pull it?
[05:43] <pitti> maxiaojun: 1. the "system info" in control-center should provide this
[05:43] <pitti> 2. b43 should now work by default, as we ship the firmware; the wl driver explicitly needs to blacklist it
[05:43] <pitti> but I don't have hardware which works with b43; my dell netbook only works with wl
[05:44] <pitti> so I cannot verify on real hw
[05:44] <duflu> smspillaz: What's the main reason for separating glDraw/glPaint?
[05:44] <maxiaojun> for 2 now means raring or quantal?
[05:44] <duflu> Other than guaranteeing call order in an unknown plugin sequence...
[05:44] <pitti> maxiaojun: precise or quantal
[05:44] <pitti> maybe earlier even, not sure
[05:45] <maxiaojun> how do you ship it?
[05:46] <pitti> it's in linux-firmware, which we install by default
[05:46] <pitti> /lib/firmware/brcm/
[05:47] <maxiaojun> different from  /lib/firmware/b43/ right?
[05:48] <pitti> the path doesn't matter much
[05:48] <maxiaojun> but the content is different
[05:49] <pitti> ah, so that is not "the" b43 fw?
[05:50] <pitti> so if we still need the "other" b43 firmware, the b43-fwcutter package needs to get a Modaliases: header to identify the hardware which needs that firmware
[05:50] <pitti> but only those which don't overlap with wl
[05:50] <maxiaojun> http://paste.ubuntu.com/1376507/
[05:51] <maxiaojun> actually b43-fwcutter package itself needs some update
[05:52] <maxiaojun> i just have one laptop that only b43-fwcutter stuff work
[05:53] <pitti> what's the vendor/product ID of that card?
[05:54] <pitti> anyway, it's better to mention this ^ on a bug report
[05:54] <maxiaojun> 14e4:4331
[05:54] <maxiaojun> i linked a bug report in previous mailing list thread
[05:56] <maxiaojun> http://pad.lv/912941
[05:56] <ubot2> Launchpad bug 912941 in b43-fwcutter (Ubuntu) "Broadcom 4331 is not supported" [Undecided,Confirmed]
[05:57] <BigWhale> Good Morning.
[05:58] <maxiaojun> btw, where is "system info", is it a raring thing?
[06:06] <pitti> no, in control-center
[06:07] <maxiaojun> control-center? system settings?
[06:07] <maxiaojun> Details?
[06:11] <pitti> yeah, might be system settings, too; I'm on a German locale, so I don't know the precise English terms
[06:11] <pitti> (the program name is gnome-control-center)
[06:12] <maxiaojun> but that's far from useful i guess
[06:12] <maxiaojun> i cannot know my wifi hardware at all
[06:13] <maxiaojun> a nice related article http://www.webupd8.org/2011/07/how-to-get-hardware-information-in.html
[06:14] <maxiaojun> just check the screenshots
[06:17] <maxiaojun> both os x and redmond os can provide detailed hardware information using built-in graphical tool
[06:23] <maxiaojun> os x: http://www.askdavetaylor.com/how_big_apple_mac_macbook_hard_disk_drive.html
[06:24] <maxiaojun> redmond os: http://en.wikipedia.org/wiki/Device_Manager
[06:24] <maxiaojun> we don't have it, we use 'lspci -vvnn' probably with 'grep'
[06:25] <sarnold> maxiaojun: feel free to file a "main inclusion request" for your favorite gui hardware display tool
[06:26] <sarnold> maxiaojun: see https://wiki.ubuntu.com/MainInclusionProcess for details
[06:26] <maxiaojun> among those listed on the above mentioned blog post, HardInfo works best
[06:26] <maxiaojun> but it seems unmaintained since 2009
[06:27] <maxiaojun> i know there is MIR
[06:27] <maxiaojun> works best i mean on 12.04
[06:33] <BigWhale> I wonder when Ubuntu One will be integrated in control center :>
[06:34] <maxiaojun> it is already in it
[06:35] <RAOF> But not integrated
[06:35] <maxiaojun> though i just noted a issue that since i bought some music from Ubuntu music store, i already using Ubuntu One
[06:36] <maxiaojun> but the control-center entry still ask me to install Ubuntu One
[06:40] <didrocks> good morning
[06:41] <duflu> smspillaz: Ignore that question. I now remember glPaint is for occlusion detection. I wish it was more obvious by the name :{
[09:01] <seb128> seb128_, hey
[09:01] <seb128> larsu, ^
[09:02] <larsu> seb128, thanks :)
[09:03] <didrocks> seb128: this is the crashing seb, right? ;)
[09:03] <seb128> didrocks, I didn't restart my main client with the new lib :p
[09:03] <seb128> <- not crazy
[09:03] <Laney> hey
[09:03] <larsu> seb128 is too clever!
[09:03] <didrocks> heh
[09:03] <seb128> I hope I will not need to restart IRC or my session during the day though ;-)
[09:04] <seb128> hey Laney
[09:04] <didrocks> stop pinging people I would say |o|
[09:23] <chrisccoulson> good morning everyone
[09:34] <didrocks> hey chrisccoulson
[09:39] <seb128> chrisccoulson, hey, how are you?
[09:39] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[09:40] <seb128> chrisccoulson, I'm good thanks
[09:49] <pitti> seb128: bonjour
[09:49] <pitti> seb128: I hate users
[09:49] <pitti> seb128: when you break floppies, they don't stop complaining; then, when you fix floppies, the other half doesn't stop complaining
[09:49] <pitti> well, I don't hate the users really, I hate floppies
[09:49] <pitti> a lot!
[09:51] <seb128> pitti, hey, me too!
[09:52] <seb128> pitti, floppy and acls on filesystems, right? ;-)
[09:52] <pitti> yeah, the ACL bug is still a mystery to me :(
[09:54] <didrocks> seb128: ping!
[09:54] <didrocks> and seb128 is still up there \o/
[09:55] <seb128> didrocks, works \o/
[09:55] <didrocks> great :)
[09:55]  * didrocks waits on jenkins to merge it
[09:55] <seb128> larsu, running my real client under your new patch, working so far ;-)
[09:55] <didrocks> then, pushing the trigger
[09:56] <larsu> seb128, I feel honored! ;)  Thanks for testing it out
[09:58] <larsu> didrocks, let me know if jenkins takes too long, then I'll merge it manually
[09:59] <didrocks> larsu: I'm a little bit frightened about merging manually under jenkins' feet
[09:59] <larsu> didrocks, I've done it a couple of times, it works fine if you set the status to "merged"
[10:01] <didrocks> larsu: let me look if it runs
[10:01] <larsu> yep
[10:01] <didrocks> larsu: oh it's merged :)
[10:01] <didrocks> just having emails lagging
[10:01] <larsu> \o/
[10:01] <didrocks> let me push the trigger for an automated upload
[10:01] <larsu> thanks didrocks!
[10:05] <didrocks> larsu: it's building in the ppa now and waiting
[10:24] <didrocks> pitti: can you bump the priority of https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4004054? we need the fix ASAP on the distro
[10:24] <didrocks> the other archs are on a 3-4 minutes timerate, which means it will built in the next 30 minutes I hope :
[10:24] <didrocks> :)
[10:25] <pitti> didrocks: oui, je peux
[10:25] <didrocks> pitti: un grand merci! :)
[10:25] <didrocks> 32 minutes, way better :)
[10:25] <pitti> fini
[10:25] <didrocks> larsu: FYI ^ I guess it will be hopefully in proposed in 30 minutes
[10:25] <didrocks> (built)
[10:25] <didrocks> I meant, 60 minutes
[10:25] <pitti> didrocks: currently building ubiquity and gcc, not the smallest packages
[10:26] <pitti> hm, we used to have three ppc builders
[10:26] <didrocks> yesterday, 3 were available
[10:26]  * didrocks checks
[10:26]  * pitti asks in #devel
[10:26] <didrocks> oh, just 2 today? someone stole the copper!
[10:27] <larsu> didrocks, nice!
[10:39] <dholbach> salut mes amis
[10:39] <dholbach> seb128, didrocks: I was wondering if we should do a french^WDesktop Development hangout some time soon: https://wiki.ubuntu.com/UbuntuDevelopment/Hangouts :-)
[10:40] <seb128> dholbach, hey
[10:41] <seb128> what's the principle? hang out and chat and take questions ?
[10:41] <didrocks> morning dholbach :)
[10:41] <dholbach> seb128, yes, whatever we want to do, we do - if it's a demo or just a chat or a presentation - everything goes
[10:43] <seb128> dholbach, why not
[10:43] <didrocks> sure :)
[10:43] <dholbach> personally I think demos always work best
[10:44] <dholbach> so it could be "watch seb128 and didrocks, how they update 10 gnome packages in just 5 minutes"
[10:44] <dholbach> or whatever else you have to talk about :)
[10:44] <didrocks> we should do that when they are gnome updates to do then :)
[10:45] <seb128> which is not this cycle :p
[10:45] <dholbach> well, unity update then ;-)
[10:46] <didrocks> dholbach: it's a button to push soon
[10:46] <didrocks> or even, done daily automatically :)
[10:46] <dholbach> ok, then you can just how you slack off all day
[10:46] <didrocks> héhé :)
[10:46] <dholbach> I'll leave it up to you ;-)
[10:46] <dholbach> or we can practise your German
[10:47] <didrocks> "cracking the whip" session :)
[10:47] <dholbach> or my French
[10:47] <dholbach> whatever you feel might interest new folks is very much welcome
[10:47] <dholbach> or if you need help somewhere
[10:48] <seb128> dholbach, let's discuss it next week? this week is a bit crazy
[10:48] <seb128> dholbach, around when did you envision doing it?
[10:49] <dholbach> seb128, just grab a slot on the wiki page
[10:49] <dholbach> whenever you like
[10:50] <seb128> dholbach, ok, I will think about it ;-)
[10:50] <dholbach> great
[12:18] <bizhanMona> HI does ubuntu 12.10 supports EFISTUB bootloader?thx
[12:22] <seb128> bizhanMona, hey, try asking the question on #ubuntu-devel, bootloader is a bit lower in the stack than what desktop work on
[12:36] <bizhanMona> seb128: thx will do that.
[12:51] <didrocks> larsu: seb128: all build steps ok for indicator-messages, just need to wait in 9 minutes next copy to proposed
[12:51] <seb128> didrocks, \o/
[12:51] <larsu> \o/
[12:59] <desrt> good morning european people
[13:00] <seb128> desrt, hey
[13:01] <didrocks> hey desrt
[13:02] <didrocks> larsu: https://launchpad.net/ubuntu/raring/+source/indicator-messages/12.10.6daily12.11.22-0ubuntu1
[13:02] <didrocks> (rev 333 \o/)
[13:25] <larsu> didrocks, !!!
[13:31] <desrt> didrocks: how did that whole automated uploading thing go from a few days ago?
[13:34] <didrocks> desrt: "few" == 2 days in prod now :)
[13:34] <didrocks> desrt: seems to work well, larsu quickly broke ubuntu automatically :)
[13:35] <desrt> didrocks: i warned you :)
[13:35] <didrocks> desrt: well, we need tests
[13:35] <didrocks> dogfooding isn't the only way to rely on things to work :)
[13:36] <larsu> desrt, morning!
[13:36] <desrt> larsu: hi.
[13:36] <larsu> desrt, this crash would have gone in with a regular release as well
[13:36] <larsu> desrt, /me was too stupid for g_variant_get ;)
[13:36] <larsu> we need to test indicator-messages better
[13:36] <desrt> larsu: _everyone_ is too stupid for g_variant_get()
[13:36]  * desrt fucked it up yesterday too
[13:37] <desrt> although the compiler caught me in this case...
[13:37]  * desrt had like foo (GAction *action) { gchar *action_name; ... ... g_variant_get (blah, "(..s..)", .., &action, ...); .... use_string (action_name); ... }
 "uh... are you sure action_name is initialised?"
 @#$@#$ g_variant_get
[13:42]  * desrt wonders why he types 'make -j 16' for webkit and sees 0.39 load average
[13:44] <larsu> desrt, lol. Mine was g_variant_get (v, "(uxsb)", &one, &two, &three) -- crashed when unpacking the 4th value
[13:44] <larsu> interestingly only on x86
[13:44] <desrt> probably what was happening on amd64 was worse...
[13:44] <desrt> either that or it happened to have a NULL at the end
[13:44] <desrt> in which case the unpack is skipped
[13:47] <larsu> desrt, we really need a gcc extension for it. Like the printf one
[13:47] <desrt> larsu: i tried writing one.  it's exceptionally non-trivial.
[13:48] <desrt> i wasted a good 3 days on it at one point
[13:48] <larsu> really?
[13:48] <larsu> holy ****
[13:48] <desrt> ya.  gcc extentions are a mess
[13:48] <desrt> there is hope, however
[13:48] <desrt> since then a few people (including mozilla?) have written frameworks for writing gcc extentions in python
[13:48] <desrt> and also: clang
[13:49] <xnox> didrocks: the unity upload you did, only has one of the changes you claim to include =)
[13:49] <xnox> https://launchpadlibrarian.net/123689550/unity_6.12.0-0ubuntu2_6.12.0-0ubuntu3.diff.gz
[13:49] <didrocks> xnox: urgh, but wth?
[13:49] <didrocks> I applied the two diffs :/
[13:50] <didrocks> grrrr, uploading the new one
[13:50] <desrt> larsu: https://gcc-python-plugin.readthedocs.org/en/latest/working-with-c.html#spell-checking-string-constants-within-source-code
[13:50] <desrt> larsu: this looks like it would be exceptionally easy to deal with
[13:50] <xnox> didrocks: happens, if you use a VCS for debian source packages =/
[13:51] <larsu> desrt, nice!
[13:51] <larsu> desrt, we could do lots of warnings for glib and glib-object
[13:51] <desrt> larsu: ya...
[13:51] <didrocks> xnox: uploaded, thanks :)
[13:51] <xnox> ;-)
[13:52] <xnox> desrt: wow, that is so cooL!
[13:52] <desrt> my favourite would be "you called G_DEFINE_INTERFACE on a vtable struct that doesn't have GInterface as its first member"
[13:52]  * xnox slowly backs away
[13:53] <larsu> desrt, that happens to people?
[13:53] <desrt> ya
[13:53] <desrt> i do it about once a year
[13:53]  * larsu apparently writes too few interfaces
[13:53] <desrt> fortunately i'm getting better at recognising the symptoms
[13:53] <desrt> which is approximately
[13:53] <desrt> (1) i've been writing a new interface
[13:53] <desrt> and
[13:53] <desrt> (2) WEIRD things are happening
[13:54] <larsu> haha
[14:03] <mhr3> mvo, you need to ping someone if you need a review ;)
[14:03] <larsu> mhr3, doesn't launchpad send you emails?
[14:04] <mvo> mhr3: oh? I was not aare of this
[14:04] <mvo> mhr3: like anyone? or specific people?
[14:04] <mhr3> larsu, it does, and there are hundreds of them :P
[14:04] <larsu> mhr3, I was expecting exactly that answer :)
[14:04] <mhr3> mvo, probably someone from unity team? :)
[14:05] <mhr3> if you don't ping the right person, they'll probably forward it
[14:05] <mvo> mhr3: haha, ok
[14:05] <mhr3> mvo, for the stuff you're working on, i'd start with Trevinho or andyrock
[14:06] <larsu> mvo, general rule of thumb: whoever's listed as "author" in the file you patched
[14:06] <Trevinho> mhr3: yeah, I alredy gave him a review
[14:06] <Trevinho> mhr3: I didn't write on MR, but I contacted him for few changes
[14:07] <mhr3> Trevinho, ah, cool :)
[14:08] <mhr3> larsu, hah, i usually just copy those and leave anyone in "Authored by" for double fun :P
[14:08] <larsu> mhr3, haha that sounds like ...... fun?!
[14:09] <mhr3> larsu, it's called "make someone suffer" :P
[14:10] <larsu> lol
[14:19] <desrt> larsu: btw: 90% chance i won't be in bremen
[14:21] <larsu> desrt, well, there's always a next time :)
[14:23] <mvo> thanks larsu
[14:24] <mvo> Trevinho: I did address the points I think :) or did I miss something?
[14:25] <mvo> Trevinho: aha, ok, got the updated MP now
[14:25] <Trevinho> :)
[14:26] <mvo> Trevinho: will work on that next, it means I need to implement the desktop-id algorithm in software-center now which looks like a bit of duplication, but maybe there is a implementation of this already (and if not it looks easy enough :)
[14:26] <mlankhorst> mvo: I'm probably hitting another apt bug on switching back now
[14:26] <mlankhorst> :P
[14:26] <mvo> mlankhorst: *nooooo* ;)
[14:26] <Trevinho> mvo: probably there's something around to compute it...
[14:26] <mvo> mlankhorst: looks like you should consider a career in QA ;)
[14:27] <Trevinho> mvo: unfortunately gio doesn't provide it, if you load an app via .desktop file it can't compute it's id -_-
[14:27] <mlankhorst> I was trying to force all lts-quantal packages to be unremoved with apt-get install xserver-xorg
[14:27] <Trevinho> it gives it to you only if you already open an app via its id
[14:27] <mvo> Trevinho: heh :) thats funny, so if you have it already it gives it to you? crazy ;)
[14:28] <mlankhorst> mvo: xserver-xorg has a break and conflicts on xorg-renamed-package http://paste.ubuntu.com/1377183/
[14:29] <mlankhorst> all of the packages with -lts-quantal in the name provide xorg-renamed-package
[14:29] <Trevinho> mvo: yeah, exactly :)
[14:29] <mlankhorst> hence none of the packages with lts-quantal in the name should be considered for keeping..
[14:29] <Trevinho> mvo: don't know if it's not implemented by purpose or if it's still missing, but that's a fact :/
[14:33] <mvo> mlankhorst: hmm, yeah, looks like the problem resolver is failing badly, at leat this time its not happening when dpkg is already called
[14:36] <mlankhorst> yeah it's a hairy situation though
[14:37] <mlankhorst> I want the problem resolver to come up with 'hey none of the lts-quantal packages work any more, see what else can satisfy it'
[14:47] <mlankhorst> woops
[14:48] <mlankhorst> would probably have helped if I depended on the physical packages there
[15:23] <robru> seb128, ping
[15:23] <seb128> robru, hey
[15:23] <robru> hey ;-)
[15:23] <robru> seb128, ken told me to pester you about some SRUs that he needs to get done, can you help/guide me with that? I know nothing of the SRU process.
[15:23] <seb128> sure
[15:24] <seb128> robru, the documentation is on https://wiki.ubuntu.com/StableReleaseUpdates
[15:24] <robru> seb128, ken says he "need needs" unity-chromium-extension gnome-control-center-signon libsignon-glib
[15:24] <seb128> robru, you basically need to have a minimal diff which includes only the changes to fix the issue you want to fix
[15:24] <robru> seb128, I think ken was saying that they're done, they just need to get approved?
[15:26] <seb128> robru, ok, so basically Ken needs me to find somebody to get those accepted is what you say ;-)
[15:26] <robru> seb128, yes ;-)
[15:28] <ricotz> cyphermox, hi :)
[15:28] <ricotz> seb128, hi
[15:29] <seb128> robru, thanks ... pinged the SRU guys
[15:29] <seb128> ricotz, hey
[15:29] <ricotz> seb128, there is a rhythmbox gst1.0 build available in my ppa
[15:29] <ricotz> the packaging isnt cleaned though, just a "prove of concept" and it works with disabled visualizer-plugin
[15:30] <seb128> ricotz, laney has one as well in https://launchpad.net/~ubuntu-desktop/+archive/gstreamer1.0
[15:30] <Laney> hey
[15:30] <seb128> Laney, btw we should start uploading that stack soon I think ;-)
[15:30] <Laney> ricotz: what did you do? just build the branch?
[15:30] <ricotz> seb128, ah i see ;)
[15:30] <Laney> seb128: yeah, there are still some possibly worrying mixed stack cases that dont have any work in progress
[15:30] <ricotz> Laney, yes, just the gstreamer-1.0 branch
[15:31] <Laney> ricotz: right, I merged it into the 2.98 tag and applied that diff
[15:31] <ricotz> ok, good
[15:31] <Laney> do you know if upstream plans to merge it any time soon?
[15:31] <ricotz> sorry, idk
[15:31] <Laney> want to ask?
[15:32] <robru> seb128, thanks
[15:32] <seb128> hum, I'm out for ~45min trying to debug my aunt machine having email issues, bbiab
[15:32] <seb128> robru, yw!
[15:32] <ricotz> cyphermox, jfyi the networkmanager package should be called 0.9.7.0~ since that is what it contains ;)
[15:33] <Laney> miro gtkpod goobox gnomeradio
[15:33] <Laney> those may be broken if we upload the new stack
[15:33] <Laney> also libu1ui
[15:33] <Laney> which AFAICS uses gstreamer just to install fluendo
[15:34] <ricotz> Laney, i guess while the visualizer plugins isnt ported it won't get merged
[15:34] <robru> didrocks, ken and I fixed your concerns here: https://code.launchpad.net/~robru/unity-firefox-extension/inline-packaging/+merge/135237 can you approve now? ;-)
[15:34] <Laney> ricotz: maybe
[15:34] <Laney> didn't the branch have daap disabled too?
[15:34] <Laney> ISTR it being two plugins
[15:34] <ricotz> yes
[15:35] <didrocks> ricotz: looking!
[15:35] <Laney> mmm
[15:35] <Laney> not sure about uploading to ubuntu with it in that state
[15:35] <ricotz> libclutter-gst-dev (>= 1.4) should be libclutter-gst-2.0-dev (>= 1.4),
[15:35] <robru> didrocks, I have a couple others for review too ;-)
[15:35] <Laney> uh huh
[15:35] <Laney> the version is redundant in that case
[15:36] <ricotz> Laney, the clutter-gst api didnt really changed, just bumped for gst1.0
[15:37] <ricotz> hmm, debian/*.prs usr/share/gstreamer-0.10/presets?
[15:37] <ricotz> in -data.install
[15:37] <Laney> i already got fixed locally
[15:37] <ricotz> not sure if this simply should go in 1.0
[15:37] <ricotz> ok
[15:39] <ricotz> Laney, could you push the totem package to gnome3-ppa quantal?
[15:39] <didrocks> robru: approved, you can ping your prefered jenkins master to get it merged :)
[15:39] <Laney> ricotz: you should be able to copy it
[15:39] <Laney> if you view the ppa in the web interface
[15:40] <robru> didrocks, oh, is there more than one? I've been working with vrruiz the last couple days, but he suddenly got busy...
[15:40] <ricotz> Laney, not a copy a rebuild with ~ubuntu12.10.1
[15:40] <didrocks> robru: vvruiz, fghinter, alesage or mmrazik :)
[15:40] <didrocks> 2 of them are on vacations though
[15:40] <robru> didrocks, cool thanks
[15:40] <didrocks> yw!
[15:40] <mlankhorst> mvo: I'll just open another bug for apt then :)
[15:40] <ricotz> Laney, i can grab it too later
[15:41] <robru> didrocks, hey, you forgot to mark 'approved', you just made a comment ;-)
[15:41] <Laney> might do it after finishing the ubiquity port
[15:41] <ricotz> thanks
[15:41] <didrocks> ricotz: greenified :)
[15:42] <robru> didrocks, thanks. and I'm not ricotz  ;-)
[15:42] <didrocks> robru: speak more! s<tab> + smart completion is a general failure :)
[15:42] <didrocks> in fact, I should probably remove this weechat "smart completion"
[15:42] <ricotz> didrocks, robru, hi, yeah i got a bit confused ;)
[15:43] <robru> didrocks, so just type 'ro' before hitting tab ;-)
[15:43] <mlankhorst> I use first 2 letters most of the time..
[15:43] <didrocks> robru: yeah, but the thing is supposed to complete by the latest speaking on a channel matching the letters you type
[15:43] <didrocks> so one letter + tab is generally enough
[15:43] <didrocks> we have too many r and s here :)
[15:44] <robru> didrocks, ah, well you should file a bug so that you can hit 'tab' multiple times until it gets it right ;-)
[15:44] <didrocks> robru: yeah, or just fix it TBH :p
[15:44] <robru> didrocks, aaaaaannnnnnyyyyyways.... can you review this one too? https://code.launchpad.net/~robru/signon-keyring-extension/inline-packaging/+merge/135496 ;-)
[15:45] <didrocks> sure sure :)
[15:46] <didrocks> before building, I like it :)
[15:46] <didrocks> now, let's see…
[15:51] <didrocks> robru: approved! good work :)
[15:51] <robru> didrocks, thanks ;-)
[15:51] <robru> didrocks, got time for one more? ;-)
[15:51] <didrocks> thanks to you :)
[15:51] <didrocks> robru: how could I refuse? :)
[15:51] <robru> didrocks, https://code.launchpad.net/~robru/webaccounts-browser-extension/inline-packaging/+merge/135463 ;-)
[15:52] <didrocks> robru: not ignoring the .pem is on purpose?
[15:52] <didrocks> ah yeah
[15:52] <didrocks> as we store the key
[15:52] <robru> didrocks, yeah, build fails without the .pem
[15:53] <robru> didrocks, I was considering just 'add -f' the one .pem and leaving other .pems ignored, but ken told me to unignore .pems in general
[15:54] <didrocks> robru: yeah, that's fine IMHO
[15:55] <didrocks> robru: small comment though
[15:55] <didrocks> see MP
[15:55] <robru> didrocks, of course
[15:55] <robru> didrocks, this is why I ask for reviews ;-)
[15:56] <didrocks> robru: yeah, always better to double check! :)
[15:58]  * desrt looks out over a sea of green
[16:01] <robru> desrt, you high? I doubt there's any green in Toronto at the moment...
[16:01] <robru> ;-)
[16:01] <didrocks> desrt: is that the pond near the airport? :p
[16:01] <desrt> robru: jhbuild results page
[16:01] <robru> ahhhhh
[16:01] <desrt> things are going *very* nicely lately
[16:01] <didrocks> desrt: daily upload then! :)
[16:01] <robru> I built jhbuild once. once. ;-)
[16:02] <desrt> meta-gnome-core-shell builds with 100% success at this point
[16:02] <desrt> extras as well
[16:02] <desrt> (after applying my gnome-control-center patch, of course)
[16:02] <desrt> disk-utility is failing due to too high udisks dependency
[16:02] <robru> didrocks, ok, fix pushed, please approve ;-)
[16:02] <mlankhorst> mvo: woops, might have helped it conflict more by having some old package installed accidentally
[16:02] <desrt> and there's some stupid issues with graphviz and libmusicbrainz
[16:03] <desrt> but everything else is perfect
[16:05] <mvo> mlankhorst: oh, does it still fail?
[16:06] <mlankhorst> not sure yet
[16:07] <mlankhorst> but it probably didn't help
[16:09] <robru> didrocks?
[16:09] <didrocks> robru: building fine, files installed at the right place. perfect and approved:)
[16:09] <robru> didrocks, thanks!
[16:10] <robru> didrocks, ok, one last one I swear ;-)
[16:10] <robru> didrocks, https://code.launchpad.net/~robru/webapps-applications/inline-packaging/+merge/135247 ;-)
[16:10] <didrocks> robru: heh, keep them coming :)
[16:10] <mlankhorst> got a stale xserver-common in my ppa somehow..
[16:11] <robru> didrocks, actually ken said there were none left to do after this... I pestered him to give me a list of packages to do but he wouldn't ;-)
[16:11] <didrocks> robru: oh? maybe cyphermox can use some help then! :)
[16:11] <didrocks> robru: there are still some on the indicator/notify-osd stack
[16:11] <didrocks> as it seems you love that… ;)
[16:11] <didrocks> (oh also oif)
[16:12] <robru> didrocks, yeah actually... the only thing on my plate for today is to hassle people until these land.
[16:12] <robru> didrocks, so I could definitely do more if there are some available
[16:12] <didrocks> excellent, please cyphermox ^
[16:12] <didrocks> let me review first
[16:12] <robru> cyphermox, yeah, if you want to assign me to inline 3-4 packages today that would be cool
[16:14] <didrocks> robru: debian/copyright -> I guess TBH it should be all canonical :)
[16:14] <didrocks> just a minor thing, but simplifying the license and all the work we do in ubuntu for packaging is copyright canonical
[16:14] <didrocks> I don't think ken will object :)
[16:15] <robru> didrocks, so just drop the whole last paragraph there?
[16:15] <cyphermox> robru: didrocks: what's left by my count is appmenu-gtk, globalmenu-extension, indicator-applet, appmenu-qt, libappindicator, sni-qt ; picking any in the list is fine, just tell me which :)
[16:15] <didrocks> robru: yeah
[16:15] <didrocks> cyphermox: you have notify-osd and the oif stack as well, right?
[16:16] <cyphermox> ah, yes
[16:16] <cyphermox> there are those too
[16:16] <didrocks> robru: so start with indicators one first I would say ^
[16:16] <robru> cyphermox, ok, that's 6. I'll take the last three, so appmenu-qt, libappindicator, and sni-qt
[16:16] <didrocks> see, there are a lot of fun here :)
[16:16] <robru> cyphermox, oh, ok
[16:16] <robru> ok wait
[16:17] <robru> didrocks, you want me to do indicator-applet?
[16:17] <didrocks> robru: the first line is all indicators, so your plan works :)
[16:17] <robru> didrocks, cyphermox, ok, the three I originally said stand. ;-)
[16:17] <didrocks> thanks robru, cyphermox :)
[16:19] <robru> didrocks, ok, pushed that copyright fix, please approve ;-)
[16:19] <didrocks> it's building building building…
[16:19] <cyphermox> didrocks: how did libindicate look after all, anything jumping out? was I too tired when I did it ? :)
[16:21] <didrocks> robru: and approved :)
[16:21] <didrocks> cyphermox: hum, did I miss this review?
[16:21] <didrocks> let me look again :)
[16:21] <cyphermox> there isn't a MR, it's one I told you about early this morning
[16:21] <cyphermox> or do you rather just review it later? :P
[16:22] <didrocks> cyphermox: oh right, yeah, I didn't get time, TBH, I planned to go outside running for some hours ago and still didn't get to it :)
[16:22] <didrocks> cyphermox: so no, didn't review that one, just finish what you wanted and I'll review :)
[16:23] <didrocks> that one and libindicator (which I reviewed I guess)
[16:24]  * didrocks refreshes the stack of indicator deployed by jenkins
[16:32]  * didrocks goes out to do some exercice, back in an hour
[16:34]  * xnox unity takes a while to compile
[16:41] <didrocks> xnox: welcome to my world :)
[16:42] <mlankhorst> mvo: ok false alarm it seems, it seems to have gone insane for having the xserver-common weirdness..
[16:42] <xnox> didrocks: and I have i7 and doing a parallel build =)
[16:42] <xnox> sorry, i5, not i7.
[16:43] <mlankhorst> still seems to need some help to switch forward though on multiarch
[16:45] <xnox> mlankhorst: yeah, with multiarch it's a pain to dist-downgrade and dist-upgrade unless all enabled arches are insync.
[16:46] <xnox> didrocks: now that I have built it, why are there so many lintian tags, including warnings & errors.
[16:47] <mlankhorst> xnox: not that, getting E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
[16:47] <mlankhorst> I can help it out with apt-get install xserver-xorg-lts-quantal  libgl1-mesa-glx-lts-quantal:i386, though..
[16:47] <xnox> never saw that before.
[16:48]  * mlankhorst stresses apt's limits a bit more than usual..
[16:51] <xnox> mlankhorst: since you get an error message instead of a coredump, it may mean that you are not first one to actually do this =)))))
[16:51] <xnox> there is hope =)
[17:12] <robru> didrocks, back yet?
[17:28] <cyphermox> robru: can I help?
[17:28] <robru> cyphermox, probably ;-)
[17:28] <robru> cyphermox, I was just curious about appmenu-qt, because it's not owned by a team. It's the first one I've seen owned by an individual.
[17:29] <robru> didrocks, cyphermox: so the comment looks weird here: http://bazaar.launchpad.net/~robru/appmenu-qt/inline-packaging/view/head:/debian/control
[17:30] <robru> cyphermox, like, who is this person? are they active? is it ok for me to say that this one guy is going to handle the packaging for us once it's inlined?
[17:32] <cyphermox> ah, no it's pretty much because it wasn't moved, I think this branch should belong to ~indicator-applet-developers too
[17:36] <Laney> argh
[17:36] <Laney> I can't get my laptop or my desktop to boot into a live env due to a multitude of failures
[17:36] <Laney> anyone ever used vbox USB passthrough?
[17:37] <cyphermox> heh. I get crazy lag
[17:37] <robru> cyphermox, so how would I go about fixing that?
[17:37] <Laney> It "sees" the webcam but cheese shows a-nothing
[17:42] <cyphermox> robru: pushign the branch to the new location once it's all merged
[17:43] <cyphermox> gah, the lag is painful
[17:43] <xnox> Laney: right, is the webcam enabled via Fn-hotkey?
[17:43] <cyphermox> why is everything so slow
[17:43] <xnox> Laney: or give me the branch & I can test this on my netbook.
[17:44]  * xnox had zero luck doing webcam over usb-passthrough
[17:44] <robru> cyphermox, but I mean... do I have permission to fix that? or are we waiting for agateau to merge my branch and then push it somewhere else?
[17:44]  * Laney hides under xnox
[17:44] <cyphermox> robru: let's check that out with mmrasik
[17:44] <Laney> I'll push it but it could be a pile of failure
[17:47] <didrocks> xnox: most of them are false positives
[17:47] <didrocks> xnox: and due to compiz
[17:48] <xnox> didrocks: hm?
[17:50] <didrocks> xnox: the hardening-no-fortify-functions is a false positive one, as steve looked at it
[17:50] <didrocks> the executable-not-elf-or-script or generate by dh_migrations
[17:50] <didrocks> W: unity source: quilt-build-dep-but-no-series-file
[17:50] <didrocks> W: unity source: patch-system-but-no-source-readme
[17:51] <xnox> ember: unity-common: python-script-but-no-python-dep usr/lib/unity/makebootchart.py
[17:51] <didrocks> -> quilt was added by someone else
[17:51] <didrocks> xnox: yeah, we don't want to add the python dep on purpose
[17:51] <didrocks> it's used by autopilot only
[17:51] <didrocks> and that's all of them
[17:51] <xnox> didrocks: that's wrong. that file should then be shepped in the unity-autopilot package.
[17:51] <xnox> didrocks: and the python dependency should be there.
[17:52] <xnox> didrocks: or port to python3 =)
[17:52] <didrocks> xnox: the unity-autopilot didn't exist at the time, it can be moved
[17:52] <xnox> didrocks: yes, please.
[17:52] <didrocks> xnox: "please"?
[17:52] <didrocks> xnox: TBH, I don't really like this ton
[17:52] <didrocks> we can see how you will deal once you will have more than 40 packages under your responsability
[17:53] <didrocks> especially for things where the quality of the package is not directly impacted
[17:53] <xnox> didrocks: i can do merge proposals if you like.
[17:54] <didrocks> xnox: yes please
[17:55] <xnox> didrocks: and sorry about the tone. it was not meant like that. I am not sure, how I was suppose to say "oh, since unity-autopilot didn't exist at the time, I see why the python dep was not explicitely added at the time. But now that autopilot package exists, moving that file there is a good idea. I agree with you, can this be a wishlist packaging bug/task?"
[17:56] <didrocks> xnox: it's more on the "17:46:25          xnox | didrocks: now that I have built it, why are there so many lintian tags, including warnings & errors." which I find pedantic and accusive
[17:56] <didrocks> accusative*
[17:56] <xnox> didrocks: I do understand that maintaining a large stack of packages is hard and in no way trying to point it out.
[17:56] <didrocks> thanks :)
[17:57] <xnox> didrocks: it's the first time I built unity myself, and I wondered if there was a good reason for it to be in a state like it is or I should fix it.
[17:57] <didrocks> xnox: apart from the python one, I think you can remove quilt now that we have inline branch
[17:57] <xnox> usually large amont of lintian can be very much intentional.
[17:58] <xnox> didrocks: well, I recognise the quilt one, as some of my packages have it - if you built it as both 1.0 or 3.0 source package depending on the target release.
[17:58] <didrocks> then we have the executable-not-elf-or-script and hardening-no-fortify-functions which are wanted
[17:58] <xnox> so I don't actually mind that one.
[17:58] <didrocks> the only "error" is a false positive
[17:59] <didrocks> I meant:
[17:59] <didrocks> patch-system-but-direct-changes-in-diff
[17:59] <didrocks> but this is due to merge-upstream
[18:00] <didrocks> xnox: btw, the MP should be done for lp:unity now
[18:01] <didrocks> xnox: as we are moving all packaging inline
[18:01] <xnox> didrocks: that was going to be my next question =)
[18:01] <xnox> ack.
[18:03] <chrisccoulson> hmmm, our street is rapidly turning in to a river
[18:04] <didrocks> chrisccoulson: running that much?
[18:04] <didrocks> raining*
[18:04] <desrt> our street has a rather ironic habit of turning into a lake...
[18:04]  * didrocks has a broken head after today :)
[18:04] <chrisccoulson> didrocks, yeah, it's been raining pretty heavy for the last half an hour
[18:05] <didrocks> here, the weather is cold, but not rainy
[18:07] <robru> didrocks, chrisccoulson: we have a foot of snow in Winnipeg!
[18:07] <didrocks> robru: waow! what's the temperature?
[18:07] <desrt> robru: pfft.  'real canada'
[18:07] <desrt> enjoy your snow, eh?
[18:08] <didrocks> desrt: you definitively don't live in canada :p
[18:08] <desrt> didrocks: ask robru.  he'll tell you :p
[18:08] <didrocks> heh ;)
[18:08] <robru> I am getting on a plane in a week... ;-)
[18:08] <robru> and I'm never coming back to this town!
[18:08] <didrocks> seems like a relief :)
[18:08] <didrocks> where are you moving btw?
[18:08] <desrt> robru hates winnipeg
[18:09] <robru> I am moving to Victoria, BC. it's a cute little coastal town... they only get snow for a few days per year.
[18:09] <robru> and also they're a cycling haven... they're like Canada's copenhagen ;-)
[18:09] <chrisccoulson> robru, lucky you! i love snow :(
[18:10] <didrocks> oh, sounds lovely :)
[18:10] <chrisccoulson> robru, want to swap for a few months?
[18:10] <chrisccoulson> birmingham is lovely at this time of year
[18:10] <chrisccoulson> honest ;)
[18:10] <desrt> chrisccoulson: you should know better than to believe any of us would believe the words 'birmingham is lovely' coming from your mouth :)
[18:10] <robru> chrisccoulson, if you love snow so much, you should strongly consider moving to Winnipeg. ;-)
[18:11] <chrisccoulson> desrt, heh ;)
[18:11] <desrt> chrisccoulson: but only if you also love having bricks thrown at you
[18:11] <didrocks> robru: is the weather better than Seattle? I hear that it was already raining around there
[18:11] <didrocks> seems like 150kms away
[18:11] <robru> didrocks, yeah, it's actually quite sunny in Victoria. I don't know how to explain it, but there's this one mountain that shaped just right to deflect all of the rain clouds over into Vancouver instead.... ;-)
[18:12] <didrocks> robru: "let's have the USA keep their weather" :p
[18:12] <cyphermox> didrocks: having some issues with actually testing reverse-depends of libindicator for now; for some reason my internet is really slow this afternoon
[18:13] <cyphermox> but I updated to fix the issues mentioned on the MR
[18:13] <cyphermox> (about to push now)
[18:13] <didrocks> cyphermox: no worry, I think I'll review tomorrow right now.
[18:13] <cyphermox> ok
[18:14] <didrocks> robru: cyphermox: just keep them coming as you can, I'll review that in my inbox :)
[18:14] <cyphermox> I'm going to stay up until I finish at least ubuntu-menu-bar; and perhaps oif and notify-osd too
[18:14] <cyphermox> ok
[18:14] <didrocks> cyphermox: sweet!
[18:15] <didrocks> cyphermox: I'll do the part 2 of the bootstrap
[18:15] <didrocks> meaning the message and commits
[18:15] <cyphermox> any bootstraps missing?
[18:15] <cyphermox> I can do them too
[18:15] <robru> didrocks, I have a good 6 hours left on my shift, you probably dont want to stay up that late.... but you can get more reviews tomorrow ;-)
[18:15] <didrocks> cyphermox: I think I ended up what is merged
[18:15] <cyphermox> ok
[18:15] <didrocks> robru: I would love them \o/
[18:15] <didrocks> robru: then, tomorrow, we can talk together (I think we didn't) about the step 2 of the boostrap
[18:16] <didrocks> which is really simple :)
[18:16] <cyphermox> yup
[18:16] <cyphermox> for the indicator packages my script works well :D
[18:16] <didrocks> heh :)
[18:16] <robru> didrocks, yep, I know very little about this process, i just do what I am told so far ;-)
[18:16] <cyphermox> didrocks: you just don't trust my work  ;)
[18:16] <didrocks> robru: well, you know, the process is new to everyone, we just shape it as it goes :)
[18:17] <didrocks> cyphermox: not that, it's just that I wanted for tomorrow to have more things running
[18:17] <didrocks> cyphermox: oh btw, you did notice the 3rd merge I'm doing?
[18:17] <cyphermox> 3rd merge?
[18:17] <didrocks> it's when there is something to release, to have at least one additional commit to release
[18:17] <robru> didrocks, ok, you have a new one in the email ;-)
[18:17] <cyphermox> oh, right ok
[18:17] <didrocks> robru: too late, just closed thunderbird (lucky? ;))
[18:17] <cyphermox> just for changing thing to check that it works
[18:17] <didrocks> cyphermox: right
[18:18] <didrocks> cyphermox: I'm only doing those for projects that have something not in distro
[18:18] <didrocks> like a commit not backported already and so on
[18:18] <didrocks> that's why all projects don't necesserally have it
[18:19] <didrocks> waow 14s of lag, I guess it shows I should EOD :)
[18:20]  * didrocks waves good evening
[18:20] <didrocks> and enjoy inlining :)
[18:22] <notgary> Hey, would anyone have a problem with the paper cuts team having a brief meeting here in about 40 minutes, or would you prefer us to do it somewhere else?
[18:24] <desrt> notgary: looks like nobody minds :)
[18:25] <notgary> desrt: I guess I can take the silence as implicit consent :)
[18:26] <robru> notgary, I don't mind...
[18:27] <notgary> robru: explicit consent is of course always preferred :)
[18:28] <xnox> notgary: is ubuntu-meeting booked? Cause if not, you can highjack it & use the meeting notes bot with #startmeeting title
[18:32] <notgary> I wasn't sure if our thing would be big enough for Ubuntu meeting. I was thinking of holding it here and seeing what kind of turnout we got before moving onto that.
[18:32] <xnox> notgary: asked on #ubuntu-irc and was pointed to http://fridge.ubuntu.com/calendars/ looks like #ubuntu-meeting is free.
[18:32] <xnox> http://fridge.ubuntu.com/calendars/
[18:33] <notgary> Heh, free all day
[18:33] <notgary> Thanks for the heads up
[18:33] <xnox> notgary: meh, I think the _whole_ ubuntu-motu meetings sometimes have like 3 people in it. But the onlookers are great =)
[18:34] <notgary> Heh, fair enough :)
[18:34] <xnox> notgary: ask for a meeting to be put on the fridge on #ubuntu-irc. #ubuntu-meeting is always a good place to hold meeting, as there won't be accidental interruptions to the conversations.
[18:34] <xnox> notgary: plus fridge is an advertisement platform for meetings ;-)
[18:35] <notgary> xnox: thanks for the advice :)
[18:36] <xnox> np
[18:36] <notgary> I think it's too late to change it now as people will probably miss it, but next time I'll set that up.
[18:55] <MCR1> notgary: Hi :) I heard a meeting is about to happen ?
[18:55] <radu> hey everyone
[18:56] <notgary> MRC1: You heard right. Hold on a few more minutes.
[18:56] <MCR1> :)
[19:04] <cyphermox> notgary: ok so you're having the meeting here instead of #ubuntu-meeting after all?
[19:05] <cyphermox> ignore me
[19:06] <notgary> cyphermox: you must have missed my last message about it being too late to change it this time, but next time we'll do that
[19:06] <cyphermox> yeah yeah, no problem :)
[19:06] <notgary> right
[19:06] <notgary> Who's all here for the paper cuts meeting? Say hello if you ar.
[19:07] <chilicuil> hi =)
[19:07] <radu> hey
[19:07] <_Psy_> Hi
[19:08] <notgary> Anyone else? MCR1, I'm looking at you :)
[19:08] <notgary> Ah well, he'll be back
[19:08] <notgary> Anyway
[19:09] <notgary> Thanks a lot for coming along. I appreciate you taking the time to attend
[19:09] <notgary> If anyone's not familiar with the agenda, you should quickly check it out here https://wiki.ubuntu.com/PaperCutsRaring/Meeting1
[19:09] <notgary> The first item:
[19:10] <notgary> how are we doing?
[19:10] <notgary> So far we have...
[19:10] <notgary> fixed 8 bugs
[19:10] <MCR1> notgary: Sry, I am here now :)
[19:10] <notgary> No probs
[19:10] <notgary> :)
[19:10] <MCR1> @all: Hi
[19:11] <notgary> 8 paper cuts fixed: 6 committed upstream and 2 already released
[19:11] <notgary> For a project that was on it's last legs this time last month, I'd say we've gotten off to a greta start
[19:12] <notgary> So far we've been focusing mostly on Rhythmbox bugs
[19:12] <notgary> and 4 of the fixes are in there
[19:12] <notgary> Anyone got any thoughts or comments on our progress so far?
[19:12] <notgary> Hoe are we doing?
[19:12] <notgary> What could we be doing better?
[19:13] <notgary> A specific point was raised on the mailing list
[19:13] <notgary> about the role of GTK in the project
[19:13] <radu> i'd say we're doing good
[19:14] <notgary> It was pointed out that a lot of the bugs fixed so far have been issues in GTK, rather than the app they were reported in
[19:14] <notgary> radu: excellent. Nice to know it's not just my warped outlook on life :)
[19:14] <_Psy_> Well, I can say that I was not sure about the "app focusing" plan, but I'm very surprised about the results and I must give congratulations for the idea
[19:15] <radu> yeah, for that. Since GTK+ touches a lot of projects, I'd say if we want to target it specifically, we should give it a larger time period than the rest
[19:15] <_Psy_> Its really making sense, focusing the project
[19:15] <MCR1> I'd say a good idea with GTK, a good idea to work on problems near the foundation of things...
[19:15] <notgary> I was sceptical about the potential success of it too
[19:15] <notgary> but it seems to have worked out well :)
[19:16] <notgary> As for GTK, I was thinking maybe we could give it some kind of preferential treatment, maybe targeting more bugs to it than we would on anything else.
[19:16] <notgary> What do people think about that?
[19:17] <radu> that would be my idea too. Maybe treat it like three-four normal applications
[19:17] <_Psy_> Yep, I really believe that can be the foundation on where the papercut project gravitates, because many bugs found and reported are foundational ones: GTK+, Unity, Compiz.
[19:17] <_Psy_> And thouse papercuts are usually difficult to report if you don't have a good test case on one app
[19:17] <MCR1> Yeah, I hoped I would not have to say that - _Psy_ I agree 100%
[19:18] <radu> personally, I think targetting Unity is not such a bad thing. Some Unity bugs should be easy to fix (typos, descriptions etc), and this has a direct impact on all Ubuntu users
[19:18] <MCR1> Compiz as foundation of Unity is even more important IMHO
[19:18] <notgary> Unity has it's own foundational technology, called Nux, which is an interface widget library developed specifically or Unity
[19:19] <notgary> I'm not sure how it all works, but perhaps we could know out some bugs in Nux that manifest as paper cuts in Unity
[19:19] <MCR1> notgary: I have contributed a lot to both projects (Compiz/Unity) already, so I can help with this
[19:20] <BigWhale> who's the goto guy for Launcher API?
[19:20] <notgary> Not sure. We can ask on the Unity dev and design mailing lists
[19:20] <MCR1> Unity devs hang around in #ubuntu-unity
[19:20] <notgary> Or we could ask there :P
[19:21] <BigWhale> MCR1, notgary yeah... I just joined. Thanks.
[19:21] <notgary> Anyway
[19:21] <notgary> we should probably wrap up this item and conclude that we're going to look closer at the foundational technologies in Ubuntu
[19:22] <MCR1> It would be important to have some scripts, setting up build and testing environment for Compiz/Unity as those are not easy to set up
[19:22] <radu> ok, that would be a good summary
[19:22] <_Psy_> My feeling is that Unity/Compiz/GTK+ must have a permanent "focusing" week every month
[19:22] <MCR1> I saw the idea of Papercutters PPA
[19:22] <radu> MCR1, I agree with the scripts idea
[19:23] <notgary> Which is a perfect segway into that item
[19:23] <notgary> A pity we don't have a seaway sound effect for that :P
[19:23] <notgary> The paper cutters PPA would just be a catchall holding area for any scripts and apps that are developed for helping out the paper cuts proejct
[19:24] <notgary> So far we've got a single script for reporting the current progress of the project for the current cycle https://wiki.ubuntu.com/PaperCutsProgressReporter
[19:25] <notgary> and I was hoping to iteratively expand it as we go on, turing it into a very comprehensive guide to how we're doing
[19:25] <notgary> This would be the first one to go in
[19:25] <notgary> and I was wondering if anyone had any ideas for anything else we could stick in our toolbelt.
[19:25] <notgary> There was mention of setup scripts for Compiz/Unity and friends
[19:26] <MCR1> I could try to build some basic scripts that help to set up Compiz/Unity, but that is not so easy as it sounds...
[19:27] <notgary> Yeah, those ones are quite nasty
[19:27] <MCR1> but otherwise it is important for a contributor to be able to test his fixes, without having to set up everything from scratch
[19:27] <notgary> So how would you think these scripts should work?
[19:28] <notgary> in terms of workflow for the user/contributor
[19:28] <MCR1> Every info regarding building Unity from source is heavily outdated
[19:29] <MCR1> So I suggest adding scripts like "branch_and_build_compiz_and_unity_from_source.sh" would be helpful
[19:29] <notgary> That would indeed be helpful
[19:29] <notgary> to Ubuntu at large as well as the paper cut project
[19:30] <MCR1> They should pull in all build-deps, pull/update bamf/nux/libunity/compiz/unity and install the builds to the home dir for testing
[19:30] <notgary> How difficult do you think it would be to keep them unto date?
[19:30] <notgary> *upto
[19:30] <MCR1> So people can start hacking on it more easily
[19:31] <MCR1> well, there are many unannounced changes all the time, soooo - rather hard...
[19:31] <notgary> Maybe we could enlist the help of the Unity devs for this
[19:32] <notgary> We'd also need to make sure we tested it regularly, to make sure it worked
[19:32] <notgary> probably daily
[19:32] <MCR1> that would be great
[19:32] <notgary> and any build failures should be reported as bugs
[19:33] <notgary> This sounds like a great idea because of the benefit it will have for Ubuntu as a whole.
[19:33] <MCR1> we could start with hacks on Compiz though, as those would be much easier to test...
[19:33] <notgary> Do you know of any small ones that we can get started on?
[19:33] <MCR1> I have developed a way of testing Compiz plug-ins and fixes, that is quite simple and efficient
[19:33] <MCR1> yes, I got a ton of them ;)
[19:34] <notgary> Awesome
[19:34] <_Psy_> notgary: So far we saw many bugs that goy stuck just because we needed the input from design or UX team to clarify a possible "good" behave of the UI
[19:34] <notgary> _Psy_
[19:34] <notgary> Yeah
[19:34] <MCR1> _Psy_: Yes, design is not very responsive, I agree...
[19:34] <_Psy_> So, I think to have them roaming makes a lot of sense
[19:34] <notgary> that's something I've been working on trying to fix
[19:34] <MCR1> See also the ayatana list
[19:35] <MCR1> a ton of great ideas without any response whatsoever
[19:35] <notgary> I've spoken with mpt about how to get more response from design
[19:36] <notgary> He said that if we assign the bug to jnick_tait, a project manager on the design team, then he'd get it delegated to another memebr
[19:36] <notgary> hopefully leading to more members of the design team working with community members
[19:37] <MCR1> that would be something appreciated from the community I think
[19:37] <notgary> He also said it was ok to ping jnick_tait on #ubuntu-design if we wanted to get his attention
[19:37] <notgary> Though I would suggest letting a little time go by before doing that :P
[19:37] <_Psy_> Oh, thats great
[19:38] <MCR1> many bugs are just bugs and do not really need design input, so there is enough to do
[19:38] <notgary> I think this is another bit we can wrap up now
[19:38] <notgary> In summary...
[19:39] <notgary> Start working on build scripts to get the foundation packages up and running more easily
[19:39] <notgary> and pester design to provide input
[19:39] <notgary> Next...
[19:39] <notgary> Another idea was suggested for the reporting of paper cuts
[19:39] <notgary> instead of asking people to report them on pre-release CD, where the code was likely to change anyway
[19:40] <_Psy_> MCR1: yes, but sometimes just with a little input you can quicly dismiss a bug and avoid to wate resources.
[19:40] <notgary> we should be soliciting paper cuts from stable releases
[19:40] <_Psy_> (sorry if I'm a bit slow, english is not my first language)
[19:40] <MCR1> yes and there are other great ideas, which would not need much work to get implemented (ideal for papercutters), but need-design
[19:40] <notgary> Where the code is frozen and much less likely to be broken
[19:40] <MCR1> I agree, _Psy_
[19:41] <notgary> In the past, a lot of bugs that are a natural part of pre-release software have been sent as paper cuts
[19:41] <notgary> clocking up the system and making it tougher to spot genuine ones
[19:41] <radu> Well, currently, only a handful of people are marking papercuts in the bug tracker, so this is not such a big problem
[19:42] <notgary> At the moment yes, but it would be great for it to be a big problem, if you see what I mean :)
[19:42] <notgary> You're right that a lot of paper cuts aren't being reported right now
[19:42] <notgary> but that's something I'd like to change
[19:43] <notgary> If we ask people to sit down for an hour or two with their favourite app
[19:43] <radu> heh, yeah I understand what you're saying
[19:43] <notgary> and just tell us everything they find annoying about it
[19:43] <notgary> then we'll never be short of paper cuts to fix
[19:43] <notgary> If we can get them doing that ...
[19:44] <druellan> Well, if you want more "average user" contributions, you must target what people already have installed.
[19:44] <notgary> Then we need to make sure they know to do it on stable releases, and not betas
[19:44] <MCR1> it is important to get high-quality bug reports, which are easily reproducable then - that is a half-fix already
[19:44] <notgary> druellan, MCR1: exactly
[19:44] <notgary> pre-release software is a moving target in terms of fixing bugs
[19:45] <notgary> at least if you not a Canonical developer
[19:45] <notgary> so we should focus our attention on stable code
[19:45] <notgary> in the case right now, 12.10 and 12.04 LTS
[19:45] <MCR1> in the case of Compiz/Unity you will always hack on latest trunk, no ?
[19:45] <notgary> Yes
[19:46] <notgary> The bug is reported in stable code
[19:46] <notgary> and tested/fixed on development
[19:46] <seb128> notgary, the stable release have limited scope for updates though
[19:47] <seb128> you also need to get the issues fixed in the current serie before doing an SRU
[19:47] <radu> yeah, the issue will be fixed for the next release anyway
[19:47] <MCR1> yes, that is what I mean
[19:47] <notgary> Hmm, goods points.
[19:48] <MCR1> you fix stuff in trunk, then you backport it
[19:48] <notgary> OK, that's a good point.
[19:48] <radu> backporting might be difficult, especially for the LTS
[19:49] <druellan> Even worse if you are trying to fix an upstream bug, like GTK+, thouse are unlikely to be backported to a LTS
[19:49] <MCR1> it gets harder once the code diverges too much, because you have to fix conflicts
[19:49] <notgary> radu: which is why they should be reported and fixed in pre-reales. Now I'm getting you
[19:50] <notgary> Ok, focus on the current trunk sound like the best way to go about it.
[19:50] <MCR1> but generally most bugfixes will apply cleanly to LTS (old) versions of the code also
[19:51] <radu> well, you could restrict the bug reporting to the stable version. This is not a problem. But the fixes will probably be available with the next release and might not be backported
[19:51] <notgary> If we summarise that it's best to focus on pre-release and not current stable, and that I'm talking nonsense, will everyone be cool: :P
[19:52] <MCR1> bug reports can and should also focus on current stable if they are still valid for trunk
[19:52] <seb128> it's usually better to fix trunk
[19:52] <seb128> so you know the bug is fixed for the futur versions
[19:53] <seb128> you need that anyway if you want to SRU a fix because the stable update will not be accepted if the bug is not fixed in the current serie
[19:53] <radu> MCR1,  that's my opinion also
[19:53] <MCR1> but fixes should be done in trunk versions and later backported
[19:54] <radu> ok, so focus on bug reports from stable version. Fix in trunk, if still present. And backport if possible
[19:54] <radu> does that sound resonable?
[19:54] <MCR1> yep
[19:55] <notgary> yep
[19:55] <notgary> Right...
[19:55] <notgary> Last item from the agenda is the future of #ubuntu-papercuts
[19:56] <notgary> Since I set it up, I've noticed there's been net to no traffic in there. It's also been suggested that the paper cutters hang about here in #ubuntu-desktop so the work we do has greater exposure to the rest of the development community, since this is the hub of that.
[19:57] <notgary> I also think it's useful to have the desktop team generally aware of what we're doing since our focus on the CD effectively makes us s sub team of them
[19:57] <MCR1> I have no problem with that and think we do not need a new channel, there are really enough #ubuntu-* channels already
[19:57] <seb128> it makes sense to have discussions about usability issues on the channel that's on topic of the component which has the issue
[19:57] <seb128> e.g here for desktop stuff
[19:58] <seb128> #ubuntu-unity maybe for compiz/unity
[19:58] <notgary> seb128 chiming in here is evidence enough of the usefulness of that :)
[19:58] <seb128> ;-)
[19:58] <druellan> I think it makes sense. Papercuts will always gravitate towards UX
[19:59] <notgary> So maybe we could use #ubuntu-desktop as out main channel, and move into the relevant channels as and when we need to, such as #ubuntu-unity for talk about Unity
[19:59] <MCR1> +1
[20:00] <notgary> MCR1 's vote is enough to decide :)
[20:00] <seb128> +1 as well
[20:00]  * druellan rises a +1
[20:00] <notgary> I'll closed down #ubuntu-papercuts in a couple of days
[20:00] <radu> ok
[20:00] <notgary> I'll change the entry message to point people here
[20:01] <notgary> so anyone that doesn't here about this won;t try to join a non-existent channel
[20:01] <notgary> So, that's the agenda out the way.
[20:01] <notgary> Anyone got anything else that's like to add
[20:01] <notgary> ?
[20:01] <druellan> Ejem
[20:02] <druellan> About Unity
[20:02] <notgary> Go ahead
[20:02] <druellan> Its not better to call it Unity/Compiz and to focus the raring cycle to both?
[20:02] <druellan> I've found several reports that turned to be about Compiz more than Unity
[20:03] <notgary> I think that's what we're going to do
[20:04] <notgary> Compiz, GTK and Nux are the three primary foundation technologies in the Ubuntu GUI
[20:04] <notgary> and so we're going to look closely at all three of them
[20:04] <notgary> both in Raring, and in the future
[20:04] <cyphermox> stuff there is unlikely to be papercut though
[20:05] <MCR1> a very good decision IMHO
[20:05] <druellan> cyphermox: good point
[20:05] <cyphermox> (or at least feel to me like)
[20:05] <notgary> The bugs themselves may not be paper cuts, but they can manifest as such
[20:05] <notgary> I've closed plenty of bug reports that sounded like they were simply paper cuts in this app or that
[20:05] <druellan> But, from the user point of view, Unity and Compiz are almost the same, they both shape the desktop
[20:05] <seb128> often when bugs exist for a long time there is a reason
[20:05] <cyphermox> right, but the whole idea of papercut projet initially was to be small annoying bugs that can be easily fixed ;P
[20:05] <seb128> or said different: they are not trivial to fix
[20:05] <MCR1> cyphermox: I can not confirm that. Although people think that everything in Compiz/Unity has to be very complicated it often is not...
[20:06] <cyphermox> MCR1: you're right, but it also has a high chance to be
[20:06] <MCR1> sure, some are also hardcore ;)
[20:06] <cyphermox> as opposed to elements closer to the user, like a specific application
[20:07] <MCR1> if you build a house, you gotta take care to build a good fundament
[20:07] <cyphermox> yes
[20:07] <druellan> The point here is not to dismiss unity reports just because for a dev are different beast. If they fall from Papercut's scope, then, be it.
[20:07] <cyphermox> right
[20:08] <notgary> I think it would be good to at least spend a cycle looking at these sort of bugs
[20:08] <cyphermox> shouldn't be dismissed, but taken care of carefully.
[20:08] <radu> It's a good idea to get some feedback from the main developers, like on the Rhythmbox bugs. They can tell us if it's easy to fix or not :)
[20:08] <cyphermox> I didn't follow everything, but did you engage with unity devs for getting papercut reports?
[20:09] <desrt> seb128: time to stop working :)
[20:09] <MCR1> developers will test and proofread every merge-request anyway
[20:09] <seb128> desrt, oh?
[20:09] <desrt> unless you're in north america today?
[20:09] <cyphermox> MCR1: yes, but the papercut idea is to identify low-hanging fruit, that's before the merge request point
[20:09] <notgary> cyphermox: we haven't yet, only because we haven't gotten round to looking at Unity yet
[20:09] <seb128> desrt, I started at 10 and I've been away from 16 to 21
[20:09] <cyphermox> notgary: ok
[20:09] <seb128> desrt, with lunch in the middle of 10-16
[20:09] <desrt> seb128: lazy, then :)
[20:09] <seb128> desrt, ;-)
[20:10] <notgary> We've already seen that plenty of paper cuts can be fixed in GTK, so we're just extending that to the other foundation graphical technologies, though we may draw the line at X.Org :)
[20:10] <notgary> We'll take a cycle to see how it goes
[20:10] <notgary> And regular meetings like this one will stop us going too long down the wrong path
[20:10] <radu> MCR1, I was thinking of getting feedback when marking the bug as a papercut, if it's tricky or not
[20:11] <seb128> you guys can probably talk to attente about GTK things you hack on
[20:11] <notgary> We're just trying new things right now and seeing what happens
[20:11] <seb128> he joined recently and he's working on GTK
[20:11] <attente> o/
[20:12] <seb128> attente, hey, I guess you would be fine helping the papercut guys to get their usability fixes in shape to land in GTK?
[20:12] <seb128> attente, or working with them trying to see what makes sense at least ;-)
[20:13] <attente> seb128: sure thing, as long as i understand what's happening
[20:13] <desrt> attente: how are the menus?
[20:13] <attente> desrt: still working on the action group export
[20:14] <attente> but we now ignore tearoff menu items properly at least
[20:14] <desrt> nice
[20:14] <desrt> is the menu syncing itself fully completed and no longer crashing?
[20:15] <attente> there's still the one case that crashes, removing a separator from the end of a menu
[20:15] <attente> i want to get the action group working before looking at that
[20:15] <desrt> maybe we should work together tomorrow.  i wouldn't mind looking at that.
[20:15] <attente> ok
[20:15] <attente> also
[20:15] <desrt> how are you handling the actiongroup API?
[20:15] <attente> if the menu is build using GtkUIManager, the menus don't appear at all
[20:15] <desrt> implementing the interface on the GMenuModel of the parser itself or as an auxilliary object?
[20:16] <attente> auxilliary object
[20:16] <desrt> good enough
[20:16] <MCR1> radu: Well, if you make a comprehensive bug report with exact information on how-to-reproduce the bug it *could* be determined from there, but what is easy and what is hard ? - for a foreign coder a English tooltip might be hard to fix, while for a native English-speaker code might be hard to fix, so...
[20:16] <attente> desrt: i thought this was the better way of doing it
[20:16] <desrt> attente: possibly
[20:17] <desrt> considering the menumodel tree is recursive in nature and you want them all to share a single actiongroup...
[20:17] <seb128> attente, don't worry, the papercut are usually about small usability issues and there is no requirement to get things fixed, it's mostly a matter to try to help the contributors to get their patch in bugzilla up for review or comments ... even if the fix is not right it might be a good step to help getting the issues resolved ;-)
[20:17] <desrt> it makes the API slightly less awesome, but you don't really have to care about that since it's internal anyway
[20:17] <notgary> attente: thanks a lot for offering to help. How would you like us to bring you in on the GTK bugs we look at?
[20:18] <notgary> Also, I think we can consider the official part of the meeting over :)
[20:18] <notgary> I'll grab the logs later and pick out the things we need to work on and stick them on a wiki page somewhere
[20:18] <seb128> notgary, attente: I would suggest you just use launchpad bugs for tracking (and maybe open a bugzilla ticket as well) and subscribe attente when there is a patch up for review
[20:18] <radu> notgary, thanks for hosting this
[20:19] <notgary> Next time, we'll do this in #ubuntu-meeting, so I don't have to do that :)
[20:19] <druellan> notgary: thanks a lot
[20:19] <attente> notgary: are there already bugzilla tickets written up?
[20:19] <MCR1> notgary: Great Job ! Respect 8-)
[20:19] <seb128> notgary, attente: I do watch GTK bugs as well so I will make sure we find a way that works for everyone
[20:19] <attente> seb128: thanks!
[20:19] <notgary> no problem. Thanks a lot for coming along :)
[20:21] <seb128> yw ;-)
[20:44] <seb128> 'night
[20:44] <notgary> good night
[20:44] <notgary> and thanks for your input earlier
[21:40] <rigved> hello everyone
[21:40] <rigved> is the papercuts ninja meeting over?
[22:01] <Sweetshark> there is a special place in hell for people who think they should barf their random pet bug behaviour into some other unrelated bug because that one has more 'bug heat' and the party looks more fun there as there are lots of inconsistent comments already.
[22:03] <MCR1> rigved: yep, over.