[02:21] <icek> hey i have ubuntu on my macbook, it only has up to 1280X800 resolution, its too low, driving me crazy, how do i make it higher?
[02:24] <icek> ???
[02:29] <icek> ??
[02:48] <icek> ?
[03:46] <icek> hi, my resolution is 1280 - 800 how do i make it higher?
[03:47] <RAOF> icek: This channel is for development, not troubleshooting.  I suggest asking your question in #ubuntu, ubuntuforums.org, or askubuntu.com
[03:48] <RAOF> It's also entirely possible that 1280x800 is the maximum resolution of your display; for example, I have a macbook with a 1280x800 display
[03:48] <icek> i have a macbook
[03:48] <icek> 1280 800 looks smaller in ubuntu than in osx
[03:49] <bcurtiswx> mess with DPI, may help, Mac's go with like 72DPI i _think_ we go with 90DPI by default IIRC
[03:49] <icek> does anyone have a link to some really modern themes?
[03:52] <icek> bcurtiswx how do i change it to 72?
[03:53] <bcurtiswx> System --> Preferences --> Appearance | Fonts Tab | Details Button
[03:53] <bcurtiswx> if anything, whether i'm completely off or not, play around with whatever DPI you like the best
[03:54] <icek> DPI? dots per inch?
[03:55] <bcurtiswx> yup
[03:55] <icek> where do i change DPI?
[03:55] <bcurtiswx> top
[03:55] <icek> ?
[03:55] <bcurtiswx> The titlebar of the window you should be in should say "Font Rendering Details"
[03:56] <icek> System-preferences-appearance preferences?
[03:57] <bcurtiswx> System-->Preferences--Appearance
[03:57] <bcurtiswx> click the "fonts" tab on the top
[03:57] <icek> k
[03:57] <icek> there
[03:57] <bcurtiswx> ton the bottom right above "close" you should see a button that says "Details"
[03:58] <icek> hey thats pretty good
[03:58] <icek> anyone know a really good osx theme?
[03:58] <icek> :D
[03:59] <bcurtiswx> Radiance
[04:00] <bcurtiswx> Any questions past this point, you should probably go to #ubuntu , they are the genereal support channel.   have to go to bed myself, another long day tomorrow
[04:00] <bcurtiswx> nite all
[08:22] <Zdra> morning
[08:45] <rodrigo_> morning
[08:47] <didrocks> morning rodrigo_
[08:57] <rodrigo_> hmm, what's the magic in debian/rules to build a package whose upstream tarball doesn't have autogen.sh nor configure?
[08:59] <seb128> hey rodrigo_
[08:59] <rodrigo_> hi seb128
[08:59] <seb128> what do they use?
[08:59] <rodrigo_> it's got a configure.ac, just no configure/autogen.sh
[09:00] <zyga> odd, the whole point is to ship configure, well
[09:00] <rodrigo_> yeah, seems to be broken
[09:00] <zyga> rodrigo_, you can generate the appropriate stuff but I'm not dh guru to spell how to do that properly
[09:01] <rodrigo_> yeah, running autoconf/automake should do it, but no idea how to do it via dh
[09:01] <didrocks> rodrigo_: dh 7?
[09:01] <seb128> rodrigo_, use dh-autoreconf
[09:01] <rodrigo_> yes, dh 7
[09:01]  * zyga needs to learn the dh build targets/sequence eventually
[09:01] <seb128> dh_autoreconf
[09:02] <seb128> rodrigo_, install dh-autoreconf and man dh-autoreconf
[09:02] <rodrigo_> ok
[09:02] <seb128> dh --with autoreconf $@
[09:02] <seb128> basically
[09:02] <seb128> it will run autoreconf
[09:02] <seb128> which should give you a configure
[09:04] <rodrigo_> seb128, btwe, this is libsocialweb, got it from universe
[09:05] <seb128> ok
[09:12] <huats> morning
[09:12] <seb128> lut huats
[09:12] <huats> hello se
[09:12] <huats> seb128,
[09:14] <didrocks> salut huats
[09:15] <huats> o/ didrocks
[09:40] <seb128> rodrigo_, I pushed a new g-s-d to natty and the vcs btw
[09:40] <seb128> you might want to rebase your work
[09:41] <rodrigo_> seb128, oh, I'm still revieweing the patches and pushing them upstream
[09:41] <rodrigo_> seb128, a new 2.32.x?
[09:41] <seb128> rodrigo_, yes, just packaging changes
[09:41] <rodrigo_> ok
[09:41] <seb128> I updated the .install to install the datetime polkit service
[09:42] <seb128> we didn't do it last cycle because we didn't update gnome-panel
[09:42] <seb128> so we were still using the gnome-panel one
[09:42] <seb128> I cleaned the touchpad and ltmain patches while I was at it
[09:42] <seb128> it's a pretty trivial revision ;-)
[09:43] <seb128> rodrigo_, thanks for upstream those patches btw
[09:43] <rodrigo_> well, it's much more work to having to rebase them :)
[09:43] <seb128> don't tell me ;-)
[09:43] <seb128> we slacked on some of those but some were in bugzilla sitting
[09:43] <seb128> the annoying one with be the appindicator one
[09:45] <rodrigo_> yes, that part has changed a lot
[09:45] <rodrigo_> I will rebase it on Monday though, when I do a new release
[09:45] <seb128> do you know what upstream plans to do for the keyboard indicator?
[09:46] <seb128> I think g-s will not have a notification area to display that icon?
[09:46] <rodrigo_> yes, it has one
[09:46] <seb128> oh ok
[09:46] <seb128> I though they wanted to get ride of it
[09:47] <seb128> there is a GNOME wikipage about what to do about notification area icons
[09:49] <rodrigo_> well, not sure what the exact plans are, but I see a notification area in gnome-shell
[09:50] <seb128> ok
[09:53] <rodrigo_> do you know if https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/271283 has been fixed in OpenOffice?
[09:53] <ubot2> Launchpad bug 271283 in gnome-settings-daemon (Ubuntu Jaunty) (and 4 other projects) "[ooo-build] OpenOffice.org subpixel font rendering broken with new cairo (affects: 3) (dups: 2) (heat: 55)" [Medium,Fix released]
[09:53] <rodrigo_> there's a patch in the g-s-d package for working it around
[09:54] <rodrigo_> seems not, from the novell bug
[09:56] <seb128> I guess not
[09:56] <seb128> I think there was a bug upstream about this patch
[10:00] <rodrigo_> ah, it's already fixed upstream, yes
[10:02] <seb128> when,where has it been fixed? just curious
[10:02] <rodrigo_> hmm, let me check the history
[10:02] <rodrigo_> commit 6cf315249ab27d4396b0f5b5edb1e689a5cafc68
[10:02] <rodrigo_> Author: Chris Coleman <chrsclmn@gmail.com>
[10:02] <rodrigo_> Date:   Sat Oct 16 01:44:12 2010 +0100
[10:02] <rodrigo_>     xsettings: Export Xft.lcdfilter for OO.o's benefit
[10:02] <rodrigo_>     
[10:02] <rodrigo_>     Export Xft.lcdfilter legacy setting for the benefit of OpenOffice.org
[10:02] <rodrigo_>     which doesn't follow the other fontconfig settings.
[10:02] <rodrigo_>     
[10:02] <rodrigo_>     https://bugzilla.gnome.org/show_bug.cgi?id=631924
[10:02] <ubot2> Gnome bug 631924 in xsettings "patch to fix subpixel font rendering with openoffice" [Normal,Resolved: fixed]
[10:03] <seb128> ok great
[10:04] <rodrigo_> ok, only 7 patches left!
[10:12] <ricotz> seb128, hi
[10:12] <seb128> hey ricotz
[10:12] <seb128> rodrigo_, which ones?
[10:12] <ricotz> seb128, is it considered to ship develement releases of gtk+2.0 2.24 parallel to gtk+3.0?
[10:13] <seb128> ricotz, yes, we will not drop gtk2 in one cycle
[10:13] <seb128> I think gtk2 is going to be around for some years
[10:13] <ricotz> seb128, for example because of the changed location of the recent files list
[10:14] <ricotz> seb128, yeah i know, i actually meant doing these update concurrent with eachother
[10:14] <seb128> yes as time permit, you are welcome to work on that if you want
[10:14] <seb128> we are just a small team with lot of work
[10:14] <seb128> and 2.23 is not the priority right now
[10:14] <rodrigo_> seb128, 02_missing_libs.patch                   71_fix_ldsm_notification_crash.patch
[10:14] <rodrigo_> 05_disable_corner_tapping.patch         91_update_gvc_source.patch
[10:14] <rodrigo_> 06_use_application_indicator.patch      series
[10:14] <rodrigo_> 16_use_synchronous_notifications.patch
[10:15] <seb128> we will get it in the next weeks
[10:15] <rodrigo_> 02 is probably going upstream, and still looking at 71 and 91
[10:15] <seb128> rodrigo_, ok, 02, 71 and 91
[10:15] <ricotz> seb128, ok
[10:15] <seb128> should be easy to upstream
[10:15] <rodrigo_> yeah
[10:15] <seb128> rodrigo_, well 91 is basically updating the source copy from gnome-media
[10:15] <seb128> there is a bug upstream about that I think
[10:15] <seb128> let me check
[10:15] <rodrigo_> seb128, yes, which I think is already done
[10:16] <seb128> there was an issue there and I pinged bastien and commented on the bug I think
[10:16] <seb128> but he didn't reply
[10:16] <seb128> he probably missed the ping
[10:18] <rodrigo_> I'll check with him now
[10:18] <seb128> rodrigo_, I think that was https://bugzilla.gnome.org/show_bug.cgi?id=612024
[10:18] <ubot2> Gnome bug 612024 in plugins "Memory leak in gnome-setting-daemon" [Major,Resolved: fixed]
[10:19] <seb128> rodrigo_, https://bugzilla.gnome.org/show_bug.cgi?id=605694 has the patch we use
[10:19] <ubot2> Gnome bug 605694 in gnome-volume-control "gnome-volume-control-applet never frees/finalizes PA channel maps." [Normal,Resolved: fixed]
[10:19] <rodrigo_> oh, it's marked as resolved
[10:19] <seb128> well it's part of the patch on comment #3 on the g-s-d bug as well
[10:20] <seb128> dunno why it didn't made in?
[10:20] <seb128> oh, it did some weeks ago
[10:20] <seb128> could be fixed in master then
[10:20] <seb128> did you check if that's the case?
[10:20] <seb128> dunno why he let is sleep for half a year before commiting
[10:21] <rodrigo_> yes, seems it's ok in master
[10:36] <seb128> rodrigo_, the 71_fix_ldsm_notification_crash.patch one was from chrisccoulson
[10:36] <seb128> just for info
[10:36] <seb128> not sure if you want to credit patch authors in commits
[10:37] <seb128> (though you commited that one now)
[10:43] <chrisccoulson> grrrrrr, why are garages so useless!
[10:44] <rodrigo_> seb128, ah, didn't know, so no chrisccoulson on the git commit :(
[10:44] <seb128> chrisccoulson, what did they do to you car?
[10:45] <seb128> rodrigo_, right, no worry, you couldn't guess since he didn't upstream the patch not added infos in it
[10:46] <chrisccoulson> seb128 - the engine management light keeps coming on on my car, and all they seem capable of doing is guessing what the fault is or just resetting it so the light comes back on again a few days later
[10:46] <chrisccoulson> i think i'll have to just figure it out myself ;)
[10:47] <seb128> what car brand?
[10:47] <chrisccoulson> seb128 - it's a ford
[10:47]  * seb128 notes to not buy one of those ;-)
[10:47] <chrisccoulson> lol
[10:48] <chrisccoulson> we did have a french car before, but it was too small ;)
[10:48] <chrisccoulson> (although, the engine management light never came on!)
[10:49] <rodrigo_> chrisccoulson, go to another garage, usually they're very bad, so it's hard to find one with good workers
[10:50] <chrisccoulson> rodrigo_, yeah, that might be my next step
[11:04] <rodrigo_> hey pedro_!!
[11:05] <pedro_> hello rodrigo_!
[11:05] <rodrigo_> pedro_, already recovered from last week?
[11:06] <pedro_> rodrigo_, yeah almost, still feeling a bit of ubuflu though
[11:06] <rodrigo_> oh :(
[11:06] <pedro_> rodrigo_, how are you? was your trip back ok?
[11:06] <rodrigo_> you shouldn't go out at nights with danilo :)
[11:06] <rodrigo_> well, a bit long, as always, but ok
[11:07] <pedro_> haha , yeah i blame the Serbians :-P
[11:07] <rodrigo_> :)
[11:08] <didrocks> pedro_: of course, that has always been that :)
[11:08] <didrocks> hey pedro_!
[11:09]  * pedro_ hugs didrocks
[11:09] <pedro_> hello didrocks! :-)
[11:09]  * didrocks hugs pedro_ back
[11:10] <seb128> hey pedro_
[11:10] <seb128> pedro_, got the chilian flu?
[11:10] <seb128> I got it once, it's no fun indeed!
[11:10] <pedro_> salut seb128!
[11:11] <pedro_> i got the French or Serbian one
[11:11] <seb128> ;-)
[11:11]  * seb128 hugs pedro_
[11:11]  * pedro_ hugs seb128 back
[11:12] <rodrigo_> this time it was serbian, yes :)
[11:12] <rodrigo_> but not sure why, but I never get the ubuflu
[11:13] <rodrigo_> I'll shut up though, just in case for next time :)
[12:26] <TheMuso> u/c
[12:29] <pitti> Good morning
[12:29] <seb128> hey pitti
[12:29]  * pitti hugs seb128
[12:29] <pitti> TGIF! :)
[12:29]  * seb128 hugs pitti
[12:29] <seb128> TGIF?
[12:30] <seb128> pitti, how is plumbers going?
[12:30] <pitti> seb128: well, after two weeks of confs you start wearing out
[12:31] <seb128> pitti, when do you fly back?
[12:31] <pitti> seb128: talks yesterday were moderately interesting; today I'm mostly looking forward to the hardware detection BoF
[12:31] <pitti> seb128: tomorrow evening
[12:31] <seb128> ok
[12:32] <davmor2> pitti: surely UDS is more intense than a standard conf
[12:32] <pitti> yes, it is, and much more interactive
[12:34] <didrocks> Guten Morgen pitti
[12:38] <seb128> nessita, hey
[12:38] <seb128> nessita, I didn't forget about your sponsoring requests don't worry, I will get to those in a bit
[12:39] <seb128> mterry, hey
[12:40] <mterry> seb128, hello!
[12:40] <mterry> seb128, hey, so what happened with gtk3?
[12:40] <seb128> mterry, sorry I forgot to come back to you yesterday and I was away
[12:40] <seb128> when you pinged
[12:40] <seb128> mterry, I got sidetracked in other post UDS catchup things
[12:41] <seb128> mterry, go for it and upload I would say
[12:41] <seb128> mterry, https://code.launchpad.net/~bilalakhtar/gtk/gtk3-fix-611011/+merge/40164 would be nice to merge in before upload maybe
[12:41] <seb128> mterry, and -v<version> correctly to ship all changelogs entry for gtk3 on upload please
[12:42] <seb128> mterry, can you merge https://code.launchpad.net/~rodrigo-moya/ubuntu/maverick/libcanberra/ubuntugtk3/+merge/39997 as well if you think it's ready?
[12:42] <mterry> seb128, ok.  So I upload and it will go to NEW queue and all that?
[12:42] <seb128> we will follow with other uploads once pitti accepts gtk3
[12:42] <seb128> mterry, yes, but pitti will review it when he has a free slot
[12:42] <seb128> I don't think it's any hurry to get it in, but first step is to upload
[12:43] <seb128> ;-)
[12:43] <mterry> seb128, I didn't follow about -v<version>
[12:44] <seb128> mterry, bzr bd --source -- -v2.22.0
[12:44] <seb128> or whatever was the previous changelog entry to reach the archive
[12:44] <seb128> ie just make sure all the work on 3.0 is in the .changes
[12:44] <seb128> not only the current changelog entry
[12:45] <seb128> so the natty-changes email list all the work and contributors
[12:45] <mterry> seb128, ah, neat.  I don't do any cleanup on debian/changelog itself then?
[12:45] <didrocks> hey mterry
[12:45] <seb128> rather than having a entry "upload to natty"
[12:45] <seb128> mterry, your call, it's like cleaning git history before merging, some people do some don't
[12:45] <seb128> I would just include all the debian and ppa entry in the debuild -S
[12:45] <mterry> k
[12:46]  * mterry high fives didrocks
[12:46]  * mterry sits down and has a chat with gtk3
[12:46] <seb128> ;-)
[12:46] <seb128> mterry, chrisccoulson: you guys need to run for main upload rights
[12:46] <seb128> just telling
[12:47] <kenvandine> seb128, me too! :)
[12:47] <mterry> seb128, the requirements for office there are even vaguer than MOTU
[12:47] <seb128> kenvandine, hey, right, but you are on track so I didn't feel like you needed to be reminded ;-)
[12:47] <kenvandine> :-D
[12:47] <seb128> mterry, you just need enough people to vouch for you
[12:47] <seb128> mterry, which you will get for sure
[12:47]  * mterry starts handing out fivers
[12:48] <seb128> ;-)
[12:48]  * seb128 high fives mterry
[12:48] <mterry> heh
[12:48] <seb128> mterry, technically you have upload right on the desktop set already
[12:48] <seb128> mterry, since you have been added to ubuntu-desktop
[12:48] <mterry> oh yeah
[12:48] <mterry> curious
[12:49] <mterry> I should do more merges then
[12:49] <seb128> but still you can't help cleaning the sponsoring queue with that :p
[12:49] <seb128> there is lot out of desktop world
[12:49] <mterry> I was looking at the queue the other day.  It's only like 75 deep?  Doesn't seem so bad
[12:49] <seb128> it was 110 yesterday
[12:49] <seb128> and 110 over what it should be apparently ;-)
[12:50] <mterry> I just thought from the way everyone talked about it, it was at like a 1000
[12:50] <seb128> we would be in trouble if that was the case ;-)
[12:52] <seb128> mterry, the issue is not really the number but rather the delay
[12:52] <seb128> we often have things sitting for weeks or months
[12:52] <seb128> which is enough to drive contributors away
[12:52] <seb128> and we would prefer to get contributors staying and helping that running away because we ignored them ;-)
[13:04] <mterry> seb128, so only uncommitted changes we want for this gtk3 push is --enable-introspection=no for non-shared build and the merge of printing-to-Documents, right?
[13:04] <seb128> mterry, yes sir
[13:04] <seb128> ;-)
[13:05] <seb128> pitti, "(perl removal) Drop libgnome-perl recommends from gdebi/synaptics/apturl/ubuntu-desktop:"
[13:06] <seb128> pitti, did somebody agreed to use the ncurse debconf ui or what?N
[13:06] <seb128> -N
[13:06] <pitti> seb128: didn't we?
[13:06] <seb128> I don't think we did
[13:06] <pitti> seb128: anyway, I'd rather do that through seeding
[13:06] <seb128> pitti, but https://bugs.edge.launchpad.net/ubuntu/+source/debconf/+bug/415038
[13:06] <ubot2> Launchpad bug 415038 in debconf (Debian) (and 2 other projects) "port GNOME frontend to GtkAssistant (affects: 1) (heat: 13)" [Unknown,New]
[13:07] <seb128> pitti, which has a patch waiting for cjwatson to review
[13:07] <seb128> pitti, that will drop the libgnome2-perl use
[13:07] <seb128> it will still use libgtk2-perl though
[13:07] <seb128> not sure if you aimed to drop libgnome2-perl only or the whole gtk-perl stack
[13:08] <mterry> seb128, and you want the libcanberra pushed too?  (not clear if merged just meant to bzr or ubuntu + PPA)
[13:08] <pitti> well, *shrug*, it's an awful amount of packages for a tiny feature, but if people think it's more important than evo contacts sync, then let's drop the latter instead
[13:08] <pitti> seb128: my original plan was the whole perl stack
[13:08] <seb128> mterry, merge to bzr and ppa upload for now I would say
[13:08] <seb128> pitti, ok, go for it then
[13:09] <seb128> pitti, I was unsure if we agreed on the ncurse backend use
[13:09] <seb128> but I guess a normal install shouldn't see any debconf anyway
[13:09] <seb128> pitti, I still wanted to point the debconf bug to clean libgnome2-perl in case that's useful to you
[13:09] <pitti> seb128: with the recommends dropped, we can seed it back, and it's much easier to toggle on/off
[13:09] <seb128> right
[13:09] <pitti> seb128: right, it still will be if we want to bring it back
[13:09] <seb128> wfm
[13:16] <seb128> pitti, spec approved
[13:17] <pitti> thanks
[13:17] <seb128> np
[13:26] <mterry> seb128, one last question, hopefully.  I was planning to create a new ~ubuntu-desktop/libcanberra/ubuntugtk3 branch, but would you prefer to keep it in-trunk based on perception of imminent release?
[13:29] <jcastro> hey cyphermox, I filed a bunch of bugs for multimonitor stuff on unity
[13:29] <jcastro> if you want to confirm them or whatever
[13:29] <cyphermox> cool
[13:33] <komputes> hey popey ucasts.tv looks nice! Whats to become of screencasts.ubuntu.com? And more importantly, what that little thing in the corner that shows the mouse buttons and option keys?
[13:35]  * rodrigo_ -> lunch
[13:51] <popey> komputes: someone else has taken over screencasts.ubuntu.com :)
[13:51] <popey> komputes: and it's called key-mon
[13:51] <popey> http://code.google.com/p/key-mon/
[13:57] <seb128> mterry, sorry I was out for a bit
[13:57] <seb128> mterry, yeah, trunk is fine, it will go in when gtk3 is accepted
[14:07] <komputes> popey: awesome. should be in a PPA. perhaps a Screencast Team PPA.
[14:07] <popey> :)
[14:10] <thekorn> didrocks: hi, I just found out you pushed a fix for bug 659244. But I somehow can't find the package you mention in -proposed, do you have any idea what's going on there?
[14:10] <ubot2> Launchpad bug 659244 in rhythmbox (Ubuntu Maverick) (and 2 other projects) "Tracks synced to iphone won't play (affects: 22) (dups: 3) (heat: 138)" [Low,Confirmed] https://launchpad.net/bugs/659244
[14:10] <seb128> thekorn, there is a proposed freeze until next week
[14:10] <didrocks> thekorn: it's not approved yet you will get a message once approved and built
[14:10] <seb128> thekorn, cf email from a week ago on u-d, freeze for linaro
[14:11] <thekorn> okidoki, looks like I missed it
[14:11] <seb128> thekorn, the uploads also need somebody from ubuntu-sru to review and approved them
[14:11] <didrocks> (waow, it's the 3rd time today I have to explain that :))
[14:11] <seb128> so it usually takes some day
[14:11] <thekorn> thanks
[14:11] <seb128> especially during uds time when nobody is online
[14:13] <komputes> popey: whats a good tool to cut and edit ogg files without having to re-encode
[14:13] <popey> komputes: pitivi?
[14:14] <popey> oh, without encoding, pass
[14:14] <popey> I try not to edit :)
[14:14] <komputes> popey: because every time i cut, re-encode with pitivi it looks very bad
[14:14] <komputes> pixels and blur
[14:14] <popey> komputes: the defaults in pitivi are insane
[14:14] <popey> nobody would encode and watch a video using the defaults
[14:14] <popey> I should file a bug about it, it makes pitivi look pretty awful
[14:15] <komputes> popey: are you serious? you never edit your screencasts, the recording / voice track etc.
[14:15] <popey> the two that I just uploaded to ucasts.tv had zero editing
[14:15] <popey> and it shows in places :)
[14:16] <popey> that doesn't mean they worked first time! I recorded about 5 times and messed something up or fluffed what I said so I just started again.
[14:16] <komputes> I don't know if I could make screencasts that make people wait. I want the ability to make parts of the screencast fast forward, pitivi does not have this.
[14:16] <popey> with a 5 minute video it's faster to start again than it is to edit
[14:16] <popey> the screencast app has a pause button :)
[14:16] <komputes> popey: I wish avidemux worked with ogg
[14:16] <popey> I wish I had a pony :)
[14:16] <komputes> me too!
[14:17] <mterry> I suspect owning a pony is not the double-rainbow it's made out to be
[14:18] <komputes> err... the screencast app has a pause **menu**
[14:18] <popey> CTRL+ALT+P
[14:18] <komputes> nice
[14:18] <komputes> that'll help
[14:18] <popey> and yes, the menu is insane also
[14:19] <popey> the one example where having an indicator menu makes very little sense
[14:20] <komputes> mterry: i pitty da fool who don't like pony maintenance
[14:20] <komputes> popey: omg, i had such trouble with the indicator menu recently
[14:21] <mterry> komputes, at the least at this stage in our lives (post-7th-grade), we should be wishing for horses or ponies with steel-reinforced backs
[14:21] <komputes> popey: I added all the ubuntu image torrents to transmission and the program was notifying 10 seconds me for every torrent that was added.
[14:21] <mterry> komputes, or hell, just go straight for the jetpack
[14:21] <komputes> mterry: you lack vision, ponies and only ponies I say
[14:22] <komputes> mterry: ok, pony on a hovercraft
[14:23]  * mterry in a jetpack zooms by komputes pulling his hoverboard pony out of water (fool, everyone knows hoverboards don't work on water), doing loop-de-loops into the sunset
[14:23] <komputes> popey: Killed transmission, but it kept goin! ahh, child processes! it would have taken an hour to stop being notified if I didn't kill the process.
[14:24] <popey> It is very clearly friday.
[14:25]  * komputes thinks physics fail
[14:26] <mterry> popey, let us never relegate hoverboard ponies just to Friday
[14:27] <komputes> Any chance of getting notification preferences or at least a quick way to turn them off when they get anoying or when you're doing a presentation at a conference and the projector is up and your enraged ex-girlfriend feels like being a spaz ;-)
[14:51] <rodrigo_> seb128, are we creating a ~ubuntu-desktop branch for gsettings-desktop-schemas?
[14:52] <seb128> yes
[14:52] <seb128> mterry, ^
[14:52] <seb128> can you review that for rodrigo_ and sponsor if ready?
[14:52] <rodrigo_> ok, I ask because I just saw my libcanberra branch merged, thanks mterry btw :)
[14:52] <mterry> np!
[14:53] <mterry> seb128, sure.  rodrigo_, is there a merge proposal for your branch?  link me to it or your branch
[14:53] <rodrigo_> no merge proposal, since there is no ~ubuntu-desktop branch, it's a new package
[14:53] <rodrigo_> but I have a branhc
[14:53] <rodrigo_> let me find the url
[14:54] <rodrigo_> https://code.edge.launchpad.net/~rodrigo-moya/+junk/gsettings-desktop-schemas
[15:03] <rodrigo_> btw, for a package that is in universe, do we want to keep the history of that package when moving it to main?
[15:03] <rodrigo_> (librest and libsocialweb)
[15:04] <kklimonda_> rodrigo_: do you have a moment?
[15:04] <rodrigo_> kklimonda_, if you have a branch for me, yes :-)
[15:04] <mterry> rodrigo_, yeah
[15:04] <rodrigo_> mterry, ok
[15:04] <rodrigo_> kklimonda_, I do, so what's up?
[15:05] <kklimonda_> I do actually, can I send you a pm?
[15:06] <rodrigo_> kklimonda_, yes
[15:11] <seb128> mterry, when you get things uploaded to NEW please let pitti know
[15:12] <mterry> seb128, yup.  Fixed a gail-doc oddity, not figuring out the gtk-doc one
[15:12] <mterry> /not/now/
[15:12] <seb128> ok
[15:12] <seb128> btw https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-desktop-n-gnome3
[15:12] <mterry> (bad links and conflicting files with 2.0)
[15:12] <seb128> if you think of things that will need a gtk3 please add them
[15:12] <seb128> either on the alpha1 workitem list
[15:13] <seb128> if that's for the stack
[15:13] <seb128> or add bug reports about those
[15:20] <seb128> mterry, can I keep dumping tasks on you? ;-)
[15:21] <mterry> rodrigo_, gsettings-desktop-schemas looked good to me.  Pushed to lp:~ubuntu-desktop/+junk/gsettings-desktop-schemas for now.  Seemed odd to have a -dev package without a library, but makes sense.  I did fix the debian/copyright to not point to specific tarball, but rather general ftp area though
[15:21] <mterry> seb128, sure, if you have another
[15:21] <seb128> mterry, you can upload to natty ^
[15:21] <seb128> mterry, https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=gnome3-cleaning
[15:21] <rodrigo_> mterry, right, it has a .h file
[15:21] <rodrigo_> mterry, but no lib
[15:21] <seb128> mterry, the usb-create and nautilus-share bugs
[15:22] <seb128> they should be pretty trivial to fix
[15:22] <seb128> if you want to tackle them
[15:22] <seb128> usb-creator
[15:22] <hyperair> is this regarding libgnome?
[15:22] <seb128> they both have like a 1 function call from libgnome
[15:22] <seb128> hyperair, yes
[15:22] <hyperair> right
[15:23] <hyperair> well, if anyone gets around to it, please ping me with a patch
[15:23] <seb128> you read the bug emails?
[15:23] <mterry> seb128, sure I can look at them
[15:23] <seb128> mterry, thanks
[15:23] <hyperair> seb128: i'm the nautilus-share maintainer in debian, so yeah.
[15:24] <seb128> ok, so that will do, I guess patches will land on the bug
[15:24] <hyperair> okay.
[15:24] <hyperair> seb128: i'm also looking for a new sponsor to get nautilus-share into debian.
[15:24] <hyperair> seb128: until bdefreese returns
[15:24] <seb128> try Laney?
[15:24] <hyperair> Laney: oh you're a DD now?
[15:25] <hyperair> or i could poke directhex, hmm
[15:25] <seb128> sorry but I don't have a debian unstable uptodate to do bin builds and since debian doesn't accept source uploads
[15:25] <hyperair> alright.
[15:25] <seb128> pitti, I'm sending the gnome3 spec your way
[15:26] <seb128> pitti, the work items will probably not be stable for a while though
[15:26] <hyperair> i'd donate my schroot setup to you, but i imagine it'd be faster to run mk-sbuild yourself =p
[15:26] <seb128> I think we will find new libraries that need to be ported or cleaned on the way
[15:27] <mterry> seb128, rodrigo_: gsettings-desktop-schemas uploaded to natty NEW (using -v0.0, seb :))
[15:27] <rodrigo_> mterry, thanks
[15:27] <seb128> mterry, thanks ;-)
[15:27] <seb128> pitti, ^ NEW source to review for you when you have free time
[15:30] <pitti> ack
[15:33] <rodrigo_> hmm, gobject-introspection is broken in natty, or is it too new?
[15:39] <seb128> rodrigo_, how broken?
[15:40] <seb128> rodrigo_, we have the current version and it should be working
[15:40] <rodrigo_> all branches I've tried fail with:
[15:40] <rodrigo_> Namespace is empty; likely causes are:
[15:40] <rodrigo_> * Not including .h files to be scanned
[15:40] <rodrigo_> * Broken --identifier-prefix
[15:40] <seb128> what did you try to build?
[15:40] <seb128> the gtk stack built fine
[15:53] <mterry> seb128, pitti: gtk3 pushed to natty NEW
[15:54] <seb128> pitti, ^
[15:54] <pitti> rodrigo_: (currently reviewing gsettings-desktop-schemas) can you please use an ~ubuntu-desktop branch?
[15:54] <seb128> ups, you pinged pitti as well ;-)
[15:54] <rodrigo_> pitti, I can't create it
[15:54] <pitti> rodrigo_: also, any reason to not use 3.0 (quilt)?
[15:54] <seb128> pitti, can't use the product before the source is in
[15:54] <pitti> seb128: oh, we want to use an lp:ubuntu/<> thing?
[15:55] <seb128> pitti, it's in a junk for now until the product is activated
[15:55] <pitti> fine for me
[15:55] <rodrigo_> pitti, no, no reason
[15:55] <pitti> seb128: ok
[15:55] <seb128> pitti, no, just ~ubuntu-desktop/<source> won't work until the source is in
[15:55] <pitti> we could just use lp:ubuntu/ for that one, and wait for the autoimport; but then we shold just drop the vcs-bzr
[15:55] <seb128> or we need to create a product on launchpad for it
[15:55] <pitti> seb128: it'll autocreate a product?
[15:55] <seb128> you can use source package names
[15:55] <mterry> oh that was my fault for not updating the vcs-bzr after i created ubuntu-desktop branch
[15:56] <seb128> pitti, I think launchpad let you use namespace from registered product or sources
[15:56] <seb128> so it will work when we create a product or when the source is newed
[15:56] <seb128> waiting for NEW is the lazy way ;-)
[15:57] <pitti> rodrigo_: do these packages really contain arch specific files?
[15:57] <pitti> rodrigo_: I doubt that they do; if not, you should make them arch: all
[15:58] <pitti> WFM
[15:58] <rodrigo_> pitti, no, just schemas and header files
[15:58] <pitti> rodrigo_: ok, I'll reject then, please reupload with arch:all
[15:58] <pitti> rodrigo_: but let me finish the review, in case there's something else
[15:58] <mterry> rodrigo_,  also, I'm looking at that control file again and gtk.org probably isn't upstream homepage either
[15:58] <mterry> maybe gnome.org
[15:59] <pitti> rodrigo_: while you are at it, can you please use 3.0 (quilt)?
[15:59] <rodrigo_> ok
[15:59] <pitti> rodrigo_: thanks
[15:59] <mterry> I'll create a product on LP, so we can set that from the get-go
[15:59] <pitti> mterry: don't worry for now
[16:00] <Laney> hyperair: haha, noooo
[16:00] <rodrigo_> how do I make it use quilt (3.0), by adding a debian/source/format file with that in, right?
[16:00] <pitti> we could just scratch rodrigo_'s junk branch and use lp:ubuntu/gsettings-desktop-schemas once it gets created
[16:00] <Laney> soon, soon
[16:00] <pitti> rodrigo_: right
[16:00] <mterry> rodrigo_, right
[16:00] <hyperair> Laney: =)
[16:00] <rodrigo_> oh, is the ubuntu-desktop branch created?
[16:01] <mterry> pitti, well, that's if we are using lp:ubuntu/ style packages for this (vs ~ubuntu-desktop branches).  seb128?
[16:01] <pitti> rodrigo_: also, I'd like to see people use the new machine parseable copyright files, but I won't reject the package for that
[16:01] <rodrigo_> pitti, oh, where can I read about those?
[16:01] <pitti> mterry: we already do for a few (gvfs, scour, etc.)
[16:01] <mterry> rodrigo_, search for dep-
[16:01] <mterry> dep-5
[16:01] <seb128> I'm fine with use the canonical location
[16:01] <seb128> using
[16:01] <seb128> it's a small source
[16:02] <seb128> and we should start going this way
[16:02] <pitti> rodrigo_: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
[16:02] <pitti> rodrigo_: there shold be plenty of examples in existing copyright files already; e. g. udisks
[16:02] <pitti> rodrigo_: ok, otherwise the package is fine
[16:03] <seb128> pitti, gtk3 will be less easy to review but it's basically a gtk2 update
[16:03]  * mterry will be more strict in future pre-pitti-reviews
[16:03] <rodrigo_> ok, so need to add the quilt stuff, change arch to all and change the copyright file, right?
[16:03] <seb128> pitti, it's coming from debian and didrocks, mterry and me worked on it
[16:03] <seb128> so it should be ok
[16:03] <seb128> debian = pkg-gnome, it didn't go in there yet
[16:03] <mterry> rodrigo_, also extremely minor, but update the homepage
[16:03] <mterry> rodrigo_, and drop the vcs-bzr line
[16:04] <pitti> rodrigo_: right; copyright file won't block NEWing, so if you want to do that async, that's fine
[16:04] <pitti> right
[16:04] <rodrigo_> ok
[16:04]  * mterry eats Chinese food
[16:04] <pitti> rodrigo_: but it should take one minute to rewrite it, and we shouldn't proliferate the old format
[16:04] <rodrigo_> mterry, so, do I push to my branch?
[16:04] <pitti> rodrigo_: it'll be thrown away anyway after the autoimport
[16:04] <mterry> rodrigo_, sure, I can grab new stuff.  pull from mine first though, I made a small edit
[16:05] <rodrigo_> ok
[16:05] <pitti> seb128: oh, so we won't need a newer glib first?
[16:05]  * pitti reviews gtk
[16:05] <pitti> not really interesting session right now anyway
[16:07] <rodrigo_> mterry, where's yourbranch?
[16:07] <seb128> pitti, we have a new glib
[16:07] <seb128> pitti, glib doesn't break abi
[16:07] <seb128> pitti, ie no new source or soname for it
[16:08] <seb128> 2.27 is already in natty
[16:08] <pitti> I see
[16:10] <pitti> seb128: OOI, why does that ship all those .gmo files in the source?
[16:12] <pitti> seb128: is that ok for main, or does it have b-deps in universe?
[16:12] <seb128> pitti, not sure for the gmo
[16:12] <seb128> gtk2 does that as well
[16:12] <seb128> pitti, it's ok for main and would be nice to get there
[16:12] <seb128> since other things are following
[16:15] <pitti> seb128: there's a ton of copyright attributions missing in debian/copyright
[16:15] <seb128> pitti, right, which is the case for the gtk2 version as well
[16:15] <pitti> and ./tests/testnouiprint.c and ./tests/testcalendar.c are shipped under GPL, not LGPL
[16:16] <seb128> I bet all those issues are in gtk2 as well
[16:17] <seb128> nobody cares about updating the copyright in existent source
[16:17] <seb128> well not a rant for you or to have now but I just find the thing ridiculous
[16:17] <pitti> it's a lot of bureaucracy, yes
[16:17] <seb128> I understand we care about license, but the copyright infos we care about getting them right at NEW time and let them just get wrong over time
[16:18] <seb128> which means at the end we just have remotely correct infos in most sources anyway
[16:18] <pitti> seb128: can we make a deal that we open a "copyright review" bug about it, and then I'll let it in?
[16:18] <pitti> we'll need it for Debian anyway
[16:18] <seb128> ok, I will copy the copyright from debian when it gets there ;-)
[16:18] <pitti> sounds fine
[16:19] <pitti> do you know whether it'll go to experimental soon?
[16:19] <seb128> but I think we should really have a discussion about stopping listing the copyright owners
[16:19] <seb128> I think it should yes
[16:19] <seb128> the remaining point was to update the copyright IIRC
[16:19] <didrocks> +1 seb128
[16:19] <seb128> which nobody wants to do
[16:20] <pitti> grep -hir 'Copyright' .|grep -v  msgstr |sort -u
[16:20] <pitti> should go a long way already
[16:20] <seb128> is there a legal point or something which makes us list copyright holders?
[16:20] <pitti> anyway, accepted
[16:20] <seb128> thanks
[16:20] <pitti> seb128: Debian Policy
[16:21]  * pitti heads to lunch
[16:21] <seb128> well, is the policy based on legal reasons
[16:21] <seb128> not really a discussion for there
[16:21] <pitti> I don't know
[16:21] <seb128> but I would like to know what stops us to stop wasting time on that
[16:21] <seb128> pitti, enjoy lunch!
[16:21] <pitti> merci
[16:23] <mterry> rodrigo_, ubuntu-desktop/+junk/gsettings-desktop-schemas
[16:23] <seb128> pitti,
[16:23] <seb128> tests/testnouiprint.c: GPL (v2 or later) (with incorrect FSF address)
[16:23] <seb128> tests/testcalendar.c: GPL (v2 or later) (with incorrect FSF address)
[16:23] <seb128> in gtk2 as well
[16:23] <rodrigo_> mterry, yeah found out, proposing a branch in a minute
[16:29] <rodrigo_> mterry, https://code.edge.launchpad.net/~rodrigo-moya/+junk/gsettings-desktop-schemas
[16:31]  * rodrigo_ bbiab
[17:14] <mterry> seb128, how do I find out what packages are in the 'desktop' umbrella?
[17:17] <seb128> mterry, try to upload? ;-)
[17:17] <mterry> seb128, heh
[17:17] <mterry> there must be a nicer way
[17:17] <seb128> joke aside there is a query_acl or similar utility
[17:17] <seb128> cjwatson or didrocks or chrisccoulson will know about it
[17:17] <seb128> chrisccoulson, didrocks, Laney: ^
[17:17] <seb128> mterry, sorry, I got upload rights from day 1 so I never had to deal with that :p
[17:17] <mterry> seb128, hehe
[17:18] <didrocks> mterry: you will find it at lp:~ubuntu-archive/ubuntu-archive-tools/trunk
[17:18] <didrocks> then ./edit_acl.py --help
[17:18] <didrocks> it's clear enough :)
[17:18] <mterry> didrocks, thanks
[17:19] <chrisccoulson> yeah, you just do edit_acl.py -P ubuntu-desktop query -S natty
[17:19] <chrisccoulson> pretty much ;)
[17:19] <seb128> chrisccoulson, hey, run for upload main rights next week!
[17:19] <chrisccoulson> :)
[17:19] <chrisccoulson> when's the next meeting?
[17:19] <seb128> chrisccoulson, I should have kept you in hostage while I had you handy until you did it ;-)
[17:19] <seb128> I need next week
[17:19] <seb128> kenvandine said he would run next week
[17:20] <seb128> chrisccoulson, kenvandine, mterry: the last of you to apply will maintain packages you wished you would have to deal with :p
[17:20] <seb128> (let's see if that way works)
[17:20] <chrisccoulson> openoffice ;)
[17:21]  * micahg sees neither on teh DMB agenda
[17:21] <seb128> chrisccoulson, oh, you are already claiming one? ;-)
[17:21] <chrisccoulson> lol
[17:22] <mterry> huh, I *can* push to usb-creator.  Thank you edit_acl.py!
[17:23] <seb128> lol
[17:24] <seb128> mterry, I guess it's in the desktop set
[17:27] <seb128> james_w, can you decline https://code.launchpad.net/~dstansby/gnome-system-monitor/bugfix-lp-214148/+merge/26380 in some way?
[17:28] <seb128> it's a merge proposal against the upstream import
[17:30] <kenvandine> seb128, i need to wait until the following meeting, they ask for a week between notifying them and the meeting time
[17:30] <kenvandine> and i still need endorsements
[17:30] <rodrigo_> kenvandine, to ask for main upload rights?
[17:31] <kenvandine> yeha
[17:31] <seb128> kenvandine, ok, makes sense
[17:31] <kenvandine> i guess so they can review my application and all
[17:31] <seb128> chrisccoulson, mterry: ^
[17:31] <mterry> heh
[17:32] <rodrigo_> kenvandine, btw, I've been looking at the json-glib thing, and can't really find a way to make it easier, since if you want a hash table, the items would be JsonNode's still, so you'll have to check the type, etc
[17:32] <mterry> chrisccoulson, if we band together, seb128 can't stick either of us with bad packages
[17:32] <mterry> classic prisoner's dilemma
[17:32] <chrisccoulson> :)
[17:32] <kenvandine> rodrigo_, yeah... that is what i did on my send
[17:32] <kenvandine> check the type of data in each node
[17:32] <rodrigo_> kenvandine, isn't the _foreach call enough for you?
[17:33] <kenvandine> no...
[17:33] <rodrigo_> kenvandine, it doesn't reduce the code, but at least it makes it clearer
[17:33] <kenvandine> i don't want the result to be json
[17:33] <rodrigo_> so, you want GVariant's? but that would force you to still check the type
[17:34] <seb128> mterry, oh, that's how things go around there now, I see ;-)
[17:34] <kenvandine> rodrigo_, yeah... no getting out of checking the type
[17:34]  * kenvandine hugs python
[17:35] <kenvandine> but it would still be simpler than the 2 levels in json-glib
[17:35] <dobey> if you don't want to check types, don't write python.
[17:35] <rodrigo_> kenvandine, I guess the python bindings could do the conversion, so that you don't have to check the types
[17:35] <kenvandine> so JsonNode, which contains bool
[17:35] <kenvandine> for example
[17:35] <kenvandine> i would need know it is a JsonNode, and detect the type inside the node
[17:36] <kenvandine> so if i had GVarient's i would only need to check once
[17:36] <kenvandine> i understand i can't get it as simple as simple-json :)
[17:36] <rodrigo_> you are using JsonParser?
[17:36] <kenvandine> yes
[17:36] <kenvandine> is there a better way?
[17:36] <kenvandine> rodrigo_, did you look at the JsonDict thing in tracker?
[17:36] <rodrigo_> no, just thinking what could be better
[17:36] <rodrigo_> kenvandine, no, forgot that, looking
[17:37] <kenvandine> https://labs.codethink.co.uk/index.php/p/tracker-replicator/source/tree/58d6f7f40e4208f86e4edef66d71e035a34ea362/json.vala
[17:38] <kenvandine> rodrigo_, ^^
[17:38] <kenvandine> note the comment near the top
[17:38] <kenvandine> / Until i have time to look deeply into json-glib...
[17:38] <kenvandine> so he wrote his own implementation instead of figuring out json-glib :)
[17:39] <rodrigo_> :)
[17:39] <kenvandine> also note their specific use case is couchdb replication :)
[17:40] <rodrigo_> ah, it's in tracker-replicator, that's why I didn't find it in tracker sources
[17:42] <kenvandine> yeah, sorry forgot about htat
[17:42] <kenvandine> that
[17:43] <rodrigo_> kenvandine, ok, I think the sanest way would be to have a json_parser_get_dict, returning a hash table or a JsonDict object that contains JsonNode's
[17:43] <rodrigo_> would that work?
[17:43] <rodrigo_> I don't think it's good to have to convert to GVariant's, since there's no gain really
[17:43] <kenvandine> yeah, it would be a big improvement
[17:43] <rodrigo_> ok
[17:44] <kenvandine> again, what is there now works... i just think it is too complicated and want to make this easier for the next guy :)
[17:45] <rodrigo_> although that only saves one step, instead of root = json_parser_get_root(); json_array/object_foreach(), you would do a dict = json_parser_get_dict()
[17:45] <kenvandine> in fact it might be useful to talk to john about his implementation there for tracker-replicator to get suggestions from him
[17:45] <rodrigo_> the rest would be the same
[17:45] <rodrigo_> yeah
[17:49] <mterry> pitti, btw, I re-uploaded gsettings-desktop-schemas
[17:50] <mterry> pitti, I converted to DEP-5, but the copyright owners were a best-effort sort of thing.  The only documented file was the header
[17:51] <kenvandine> rodrigo_, so with Json.Dict he has implemented his own Node types and when using the data he seems to just assume the datatypes
[17:51] <kenvandine> like he knows what is a long, etc
[17:51] <james_w> seb128, I only have the same abilities as you with that merge proposal. I think you need someone from https://launchpad.net/~vcs-imports to deal with it
[17:51] <kenvandine> so not very re-usable
[17:51] <rodrigo_> kenvandine, right
[17:52] <kklimonda_> heh, the joys of parsing json in C ;)
[17:52] <kenvandine> yeah... kklimonda_ i am trying to get rodrigo_ to make it easier
[17:52] <rodrigo_> unfortunately (or fortunately, depends how you look at it), C doesn't have a generic data type
[17:53] <seb128> james_w, ok thanks
[17:53] <rodrigo_> kenvandine, at least, the dict could have a way to retrieve subchildren, like object1::prop1
[17:54] <kenvandine> rodrigo_, yeah, that would be nice
[17:54] <kenvandine> but you will see need to do type checking for each value
[17:54] <rodrigo_> if not, ebassi won't see it useful, I think
[17:54] <rodrigo_> kenvandine, yes
[17:54] <kenvandine> but we can't get away from that
[17:55] <rodrigo_> but json fields can have any char, right?
[17:56] <rodrigo_> so what to use for :: separator?
[17:57] <kklimonda_> rodrigo_: you can't use anything :)
[17:57] <rodrigo_> yeah :(
[17:58] <rodrigo_> so, the object would just be there to avoid 1 step, so hard to get it upstream :(
[17:58] <kklimonda_> what about using varargs? ("object1", "prop1", NULL) ?
[17:58] <rodrigo_> yeah
[17:58] <rodrigo_> that should work from python, right?
[17:59] <kklimonda_> it's not going to be very pythonic but it should work
[17:59] <kklimonda_> but then whole json-glib isn't really high-level language friendly anyway
[17:59]  * kklimonda_ still can't get over the fact that both JsonArray and JsonObject aren't GObjects :/
[18:00] <rodrigo_> kklimonda_, and you want to expose that in the couchdb-glib API!!! :D
[18:00] <rodrigo_> kklimonda_, yeah, they should be objects indeed
[18:00] <kklimonda_> rodrigo_: yes, but the alternative is even worse.
[18:00] <kklimonda_> rodrigo_: Couchdb is too tightly tied to json not to expose it at some point and json-glib is a de facto standard right now ;)
[18:01] <rodrigo_> kklimonda_, yeah, I know, just joking
[18:01] <kenvandine> which is why i am really hoping someone can make it simpler
[18:02] <kklimonda_> kenvandine: what is your goal right now?
[18:02] <kenvandine> kklimonda_, just to help make it better
[18:02] <kklimonda_> oh :)
[18:02] <kenvandine> i use it in libgwibber
[18:02] <kenvandine> and it was hard to figure out how to use it, and took way too much code to get anything useful
[18:02] <kklimonda_> and it way in vala ;)
[18:02] <kklimonda_> in C it's even funnier
[18:02] <kenvandine> yeah
[18:03] <kenvandine> and actually the most difficult thing to figure out was that i had to know what the node type the outter node was
[18:03] <kenvandine> like one json string gwibber returns is a JsonArray
[18:03] <and471> mpt, hey
[18:04] <mpt> hi and471, long time no see
[18:04] <kenvandine> with json-glib i have to know that and iterate over that array for the objects
[18:04] <kenvandine> but all the others are JsonObjects
[18:05] <kklimonda_> kenvandine: and you have to check it yourself? i.e. the type of response is not something you may know beforehand?
[18:05] <kenvandine> and of course the failure wasn't very obvious... like i was expect an exception that was similar to a type error
[18:05] <and471> mpt, I was looking at your Networking mockups and I got inspired to follow nzmm's custom tutorial. what I made can be seen here - http://videobin.org/+2d2/2nm.html
[18:05] <kenvandine> kklimonda_, you have to know yourself... afaict
[18:05] <and471> (ignore the jerkiness, it is smooth in reality)
[18:05] <mpt> and471, that's pretty nifty!
[18:06] <kklimonda_> kenvandine: that doesn't really sound like a good api on gwibber's side - or rather, it sounds like a very pythonic api :)
[18:06] <and471> mpt, actually wait that is an older version...
[18:06] <kenvandine> kklimonda_, it wouldn't be so bad if i could catch an type error exception and do something else
[18:06] <kenvandine> kklimonda_, why on gwibber's side?
[18:06] <and471> mpt, here with this one, the text moves as well http://videobin.org/+2d9/2nt.html
[18:06] <and471> mpt, thanks :)
[18:06] <kenvandine> the specific API always returns a json array... if that is what you mean
[18:06] <rodrigo_> kenvandine, hmm, you don't know the format of the json you get?
[18:06] <kklimonda_> ah, I see
[18:07] <rodrigo_> kenvandine, so, it's an array of what?
[18:07] <kenvandine> rodrigo_, afaict there wasn't a good way to figure it out programatically
[18:07] <kenvandine> of json objects
[18:07] <kenvandine> Json.Array containing Json.Object
[18:07] <rodrigo_> kenvandine, can you pastebin an example?
[18:07] <kenvandine> something like that
[18:07] <kenvandine> yeah, one sec
[18:08] <kklimonda_> rodrigo_: by trying to use GHashTable to describe json you are bound to hit the same problem I did - there is no way to tell what keys' types are
[18:08] <and471> mpt, I was going to ask you about that Networking stuff, it look really good, when is it going to be worked on?
[18:08] <rodrigo_> kklimonda_, no, writing a JsonDict object
[18:08] <and471> *looks
[18:08] <rodrigo_> kklimonda_, but yeah, it will return JsonNodes
[18:09] <rodrigo_> which has the same problem kenvandine was having
[18:09] <kklimonda_> rodrigo_: well, in this case why not just use GHashTable<JsonNode, JsonNode> ?
[18:09] <rodrigo_> kklimonda_, I'm writing it in C, for adding it to json-glib
[18:10] <rodrigo_> but yeah, from vala, you could something like that
[18:10] <mpt> and471, kvalo is working on it, I'm sure he'd like help though
[18:10] <kklimonda_> rodrigo_: well, it was just a shortcut for g_hash_table_new (<code to has node>, <code to compare nodes>) but it wouldn't make access to child any easier so I guess JsonDict isn't bad idea.
[18:11] <rodrigo_> kklimonda_, ah :)
[18:11] <kenvandine> rodrigo_, http://pastebin.ubuntu.com/526476/
[18:11] <rodrigo_> well, as I see it right now, JsonDict isn't a great idea, but I'm writing it so that I can find how to improve it :)
[18:11] <and471> mpt, you know what language he is writing it in (at least the settings part)
[18:12] <mpt> and471, I don't, sorry
[18:12] <and471> ?
[18:12] <and471> mpt, ah ok np
[18:12] <mpt> and471, https://code.launchpad.net/indicator-network
[18:13] <kklimonda_> rodrigo_: I'm not sure if ebassi is going to accept yet another way to read Json - there is already JsonReader in 0.12.0 (which I don't like btw ;) )
[18:13] <and471> mpt, yeah I saw that the indicator was in C, but I wondered whether the settings were going to be a separate program (like software-sources and update-notifier)
[18:13] <didrocks> ok, week-end time!
[18:13] <and471> :)
[18:13] <kenvandine> what is JsonReader
[18:13] <didrocks> enjoy everyone, see you later :)
[18:13] <kenvandine> ?
[18:13] <mpt> and471, the beginnings of the settings window already exists. I don't know how closely it's tied, ask kvalo
[18:13] <kenvandine> later didrocks
[18:13] <and471> see ya didrocks
[18:14] <kklimonda_> kenvandine: http://people.gnome.org/~ebassi/docs/json-glib/JsonReader.html
[18:14] <and471> mpt, one step ahead of you :)
[18:14] <rodrigo_> kenvandine, hmm, seems to have a specific structure, so why can't you just get each element in the array and then use json_node_get_string/boolean?
[18:14] <didrocks> see you kenvandine, and471
[18:14] <kenvandine> rodrigo_, that is what i did
[18:15] <rodrigo_> kenvandine, then why you need to check the types?
[18:15] <kenvandine> but it was hard to figure out that it was an array of json
[18:15] <rodrigo_> ah
[18:15] <kenvandine> to parse it, i have to get the root objects from each
[18:15] <kenvandine> right
[18:15] <kenvandine> so if i just to just parse it... it blew up
[18:15] <kenvandine> without any useful way to see why
[18:16] <kenvandine> it would have been fine if it was some sort of type error
[18:16] <kenvandine> but it wasn't... it like really tried to treat the array as a json object...
[18:16] <kklimonda_> It could print a more informative error indeed
[18:16] <rodrigo_> yes
[18:17] <kenvandine> yeah, or let me catch it and try to iterate over it if it isn't an object
[18:17] <mterry> hyperair, regarding nautilus-share, I think we can just replace the gnome_client_request_save call by a call to "gnome-session-save --logout", or if you want to be fancy, a dbus request to org.gnome.SessionManager
[18:17] <rodrigo_> it just returns NULL when the type doesn't match
[18:17] <kenvandine> it was just hard to find out the problem... :)
[18:17] <mterry> hyperair, I can whip up a patch and attach to the bug
[18:18] <hyperair> mterry: please do. thanks )
[18:18] <hyperair> =)
[18:18] <rodrigo_> so, this can be parsed with json_array_foreach (json_node_get_array (json_parser_get_root (parser)), callback....)
[18:21] <rodrigo_> mterry, GtkApplication will have automatic session support, afaik
[18:21] <rodrigo_> mterry, if it's for natty
[18:21] <mterry> rodrigo_, this if for triggering for a logout
[18:21] <rodrigo_> ah
[18:22] <kklimonda_> or even by using json_array_get_elements to get a GList of elements and then iterate over them. But the problem is that json-glib a) doesn't report errors in a nice way (we had this problem with couchdb-glib - _get_string_member on a non-existing member prints a non-helpful critical message) and b) doesn't let you recover from error (but that's more of a C issue - python promotes the try/catch
[18:22] <kklimonda_>  workflow and C makes you check everything beforehand)
[18:23] <rodrigo_> well, we have GError, json-glib could use that
[18:24] <rodrigo_> returning 0 on an integer member that doesn't exist is not a good way to signal errors
[18:24] <kklimonda_> right
[18:25] <kenvandine> rodrigo_, that would be good
[18:25] <kenvandine> yeah, i did the json_array_foreach
[18:25] <bilalakhtar> mterry: Thanks for that upload!
[18:25] <mterry> bilalakhtar, np!  thanks for the patch  :)
[18:26] <rodrigo_> ok, I think I'll add the GError thing, but that will be another day, now out for some beer :)
[18:26] <rodrigo_> later all
[18:26] <bilalakhtar> mterry: its my pleasure, you are welcome
[18:26] <kenvandine> rodrigo_, great :)
[18:26] <kenvandine> rodrigo_, enjoy!
[18:26] <kklimonda_> rodrigo_: have fun
[18:37] <mterry> hyperair, check out the patch in https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/664745
[18:37] <ubot2> Launchpad bug 664745 in nautilus-share (Ubuntu) "nautilus-share should stop using libgnomeui (affects: 1) (heat: 6)" [Low,In progress]
[18:40] <mterry> hyperair, shall I push it to deb bts or is this good enough?
[18:40] <hyperair> mterry: this is good enough. i'm the maintainer over there anyway.
[18:40] <hyperair> thanks
[18:40] <mterry> hyperair, cool!
[18:41] <hyperair> mterry: i probably can't get it uploaded immediately, though. debian's under freeze, and there's a crasher bug fix i want to get into squeeze.
[18:43] <mterry> hyperair, I don't think there's any particular rush.  Think it'll get uploaded before natty?  :)
[18:43] <bilalakhtar> hyperair: You are a DD?
[18:44] <hyperair> bilalakhtar: no. i need a friendly DD to upload nautilus-share for me
[18:45] <bilalakhtar> hmm
[18:49] <pitti> seb128: FYI, I exploded the pygi ports WIs on https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-gnome3, so that we get a better overview about how far we get; also, "port everything" is too big for one WI :)
[18:50] <seb128> pitti, ok, I was not sure if we wanted to list everything
[18:50] <seb128> pitti, similar for https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=gnome3-gtk3
[18:51] <pitti> seb128: we surely won't get to everything, but at least we have a more complete list
[18:51] <pitti> *nod*
[18:52] <pitti> seb128: the spec also mentions some package additions/removals, but no work items for that; are they in that other spec? or are the WIs missing?
[18:52] <pitti> oh, darn
[18:52] <seb128> ok, dinner time
[18:53] <seb128> pitti, right, it's just we can add one hundred "need to be ported to gtk3" tasks
[18:53] <seb128> I was not sure if we wanted to track all the "would be nice"
[18:53] <pitti> seb128: the spec also mentions some package additions/removals, but no work items for that; are they in that other spec? or are the WIs missing?
[18:53] <seb128> or just the one we will want to get done
[18:53] <seb128> pitti, they are in the appselection one
[18:53] <pitti> seb128: yeah, don't worry about those
[18:53] <seb128> https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-application-selection
[18:53] <pitti> seb128: I primarily added those pygi WIs since these concern "our" software, where we are upstream
[18:53] <pitti> seb128: okay
[18:53] <pitti> fine then
[18:54]  * pitti puts stamp on it
[18:54] <pitti> oh, gtk 3 in binNEW
[18:56] <seb128> ;-)
[18:57] <seb128> pitti, right, mostly the same for the gtk3 url I gave before
[18:57] <seb128> I didn't start tracking the upstream world in launchpad
[18:57] <seb128> anyway dinner
[18:57] <seb128> bbl