[00:00] <bryceh> RAOF, well maybe, but I think we'd also need the trigger fired from the kernel like Intel does
[00:00] <RAOF> Yeah.
[00:00] <bryceh> certainly it gets us closer
[00:00] <RAOF> That bit probably wouldn't be *terribly* hard; nouveau will normally spit some errors already when that happens.
[00:01] <bryceh> at the least now we seem to have toolage for doing manual debugging, which is solid step forward if true
[00:18] <RAOF> micahg, bratsche: You've added interfaces to gtk# in that branch; you therefore need to bump the clilibs version.  The simplest way to do this would be to change API_VERSION up the top of debian/rules.
[00:18] <micahg> bratsche: as long as you're making changes, make sure to change the version to 1ubuntu1 instead of 1build2
[05:36] <kklimonda> micahg: any chance you could switch daily mozilla builds to the new p.. pri.. par... argh.. need more sleep.. recipes :)
[05:37] <kklimonda> micahg: *you* being the ubuntu mozilla team, not you in particular.
[05:53] <jon8_> Does laptop battery management still work without Gnome running?? Is there a command line, command, that i can use to check battery usage?
[05:54] <kklimonda> see what you have in /proc/acpi/battery/
[05:55] <jon8_> i have BAT0
[05:55] <jon8_> [ ken: /proc/acpi/battery ]$ ls
[05:55] <jon8_> BAT0
[05:56] <jon8_> is the file, /proc/acpi/battery/BAT0/state, accurate and current information?
[05:56] <kklimonda> you should have two files in the BAT0 folder, info and state (plus alarm). You can get most info out of those files
[05:56] <jon8_> yeah.. i just did 'cat' on all of them..
[05:57] <jon8_> what about powermanagement things, will those still operate correctly?
[05:57] <jon8_> i set it within GNOME when plugged into AC power not to hibernate or goto sleep or anything..
[05:57] <RAOF> By and large, yes.
[05:57] <jon8_> http://pastebin.com/zZRuvFFA
[05:58] <jon8_> none of those files say that its detected as being plugged into AC power .. and not actually using the battery.
[05:58] <broder> doesn't gnome-power-manager coordinate actually doing things anyway? (i.e. hibernating based on timeout, sleeping when you close the lid, etc)
[05:58] <jon8_> Where in GNOME there was an indicator
[05:58] <pitti_> Good morning
[05:58] <broder> jon8_: the upower command may be an easier interface to that stuff
[05:59] <jon8_> hmm
[05:59] <jon8_> never used that before
[05:59]  * jon8_ googles
[05:59] <RAOF> pitti_: Good morning.
[06:00] <jon8_> yeah.. see
[06:00] <jon8_> sigh
[06:00] <pitti_> hey RAOF, how are you?
[06:00] <jon8_> my screen just went dark
[06:00] <RAOF> jon8_: If you don't have gnome-power-manager running then there's nothing that'll make the system suspend, hibernate, etc.  Oh, except for the VT blanker.
[06:00] <kklimonda> jon8_: "charging state:          charged" means that the battery is charged (as opposed to charging, or discharging)
[06:00] <jon8_> kklimonda ah, ok
[06:01] <RAOF> pitti_: Pretty much recovered from Dallas :)  Last week was an exercise in progressive increases in the proportion of the work day not spent being sleepy :)
[06:01] <jon8_> [ ken: /proc/acpi/battery/BAT0 ]$ ps aux|grep gnome-power-manager
[06:01] <jon8_> ken       2137  0.0  0.0  11332   880 pts/1    S+   01:00   0:00 grep --color=auto gnome-power-manager
[06:01] <jon8_> so this means no power management is being ran..
[06:01] <kklimonda> morning pitti
[06:01] <jon8_> whether it be sleep, hibernate .. or not to do either of those two
[06:01] <pitti_> RAOF: weekends help hopefully?
[06:01] <pitti_> hey kklimonda
[06:01] <RAOF> pitti_: Yes they do!
[06:02] <jon8_> sorry for the rather noobish questions guys.. i've got some things running on my laptop that i dont need gnome running for
[06:02] <RAOF> jon8_: Right.  You won't get any of the “suspend after X” type of power management things.  You'll still get cpufrequency and such hardware things.
[06:02] <jon8_> and i just want to make sure that everything is going to stay on/awake/etc
[06:03] <RAOF> It will.  It won't even sleep when you close the lid :)
[06:03] <jon8_> well, can you explain to me then, why just sitting at the terminal login prompt, with the lid open.. my screen went black after say, 5 or 10 minutes..
[06:03] <jon8_> nothing stopped running.. I have an ssh connection open from my desktop to my laptop using openssh-server and that stayed active
[06:04] <jon8_> there are no factory settings in bios that would do this, i've double checked.
[06:04] <jon8_> kklimonda thank you for that 'charged' 'charging' and 'discharging' tid bit btw. ;)
[06:05] <RAOF> jon8_: that's the VT blanker.  Pressing any key will re-light it.  I've never cared enough to hunt down whethere or not it's controllable.
[06:05] <jon8_> RAOF ah ok.. i was wondenig what you meant by that VT blanker earlier. :)
[06:05] <jon8_> i'm really loving this ubuntu community. you guys no matter what the question you guys are always super helpful!
[06:07] <jon8_> RAOF, http://ubuntuforums.org/showthread.php?t=1600699 :)
[06:09] <jon8_> RAOF and http://ubuntuforums.org/showthread.php?t=778296
[06:10] <kklimonda> morning pitti
[06:10] <kklimonda> ups
[06:16] <pitti_> seiflotfy_: good morning!
[06:16] <pitti_> seiflotfy_: libzeitgeist and zeitgeist-extensions currently want to go to universe; is that intended?
[06:17] <pitti_> (I thought unity etc. would use it)
[06:24] <micahg> kklimonda: no, there's currently an hg bug
[06:24] <micahg> err, bzr-hg bgu
[06:25] <kklimonda> damn :/
[06:25] <pitti_> argh! I accidentally pressed ctrl-e in ffox, that "grouped my tabs" and messed up everything
[06:27] <micahg> pitti_: that'll change to SHIFT+CTRL+E in beta 10
[06:28] <pitti_> ah, I think I finally found out how to restore things again
[06:29] <pitti_> hey micahg, had a nice weekend?
[06:29] <pitti_> oh no, now if I press ctrl+t for a new tab, it lands in a new window
[06:29] <micahg> pitti_: yeah, still a little behind as usual :)
[06:29] <kklimonda> pitti_: it sounds like a bug I hit yesterday
[06:29] <micahg> pitti_: how was your weekend?
[06:29] <kklimonda> it has to be a bug, because this behaviour makes absolutely no sense ;)
[06:30] <kklimonda> (restarting Fx "fixed" that for me)
[06:31] <pitti_> micahg: pretty nice, went from the Prague hackfest to Munich, and we spent some time outside
[06:31] <pitti_> kklimonda: phew, yes
[06:31] <micahg> pitti_: I've been hibernating in Chicago with it being 20F or less outside
[06:32] <TheMuso> Hey folks.
[06:32] <pitti_> hey TheMuso
[06:33] <kklimonda> o/
[06:33]  * TheMuso notes it got to 32 degrees C here today.
[06:33] <TheMuso> With more to come this week.
[06:33] <RAOF> Come down to Hobart.  It's a very reasonable mid-20s kinda place ☺
[06:34] <broder> psh. it was a gorgeous 70 degrees F here today, and it's still supposed to be winter for me :-P
[06:35]  * micahg thinks broder needs to visit Chicago for some real winter
[06:35] <pitti_> feh - /me shivers and cranks up the heating a notch
[06:35]  * kklimonda mutters about snow being everywhere..
[06:35] <broder> micahg: i just moved out of boston. i've done my time
[06:36] <micahg> broder: fair enough
[06:36] <TheMuso> RAOF: Yeah I'll bet, thats what I call nice summer weather. Even 30 degrees would be ok here without the humidity.
[06:47] <desrt> i wonder if someone can help me deduce why the PPA server is rejecting my uploads?
[06:48] <desrt> the only thing error-looking in the rejection email is the following:
[06:48] <desrt> Rejected:
[06:48] <desrt> Further error processing not possible because of a critical previous error.
[06:48] <RAOF> desrt: Can you pastebin the whole email?  I vaguely remember getting something similar in the past, and maybe the full context will shake something loose.
[06:49] <desrt> sure
[06:49] <desrt> http://fpaste.org/6xdR/
[06:50] <desrt> maybe it doesn't like that i'm trying to upload version '0' of something :p
[06:50] <micahg> desrt: that sounds like a possibility
[06:50] <desrt> could also be that the PPA service doesn't know how to deal with native releases out of git
[06:50] <RAOF> desrt: Oh, you can't upload binaries to the PPA.  Or anywhere on launchpad.
[06:51] <micahg> ah, that would probably be it :)
[06:51] <desrt> ah.  i thought i was doing a source upload
[06:51]  * desrt tries again...
[06:51] <RAOF> debuild -S is your friend :)
[06:52] <desrt> ah ya.  the amd64 thing might have tipped me off :)
[06:52] <desrt> thanks for the obvious.  it's 2am her e:)
[06:56] <desrt> sigh.  rejected again.
[06:57]  * desrt will try to figure it out later...
[06:57] <desrt> nite everyone
[07:15] <broder> by the way, for anyone that was involved in the multimonitor discussion at UDS, i'd appreciate feedback on how well http://mail.gnome.org/archives/gnomecc-list/2011-January/msg00007.html addresses the concerns people had
[08:14] <didrocks> good morning
[08:16] <pitti_> bonjour didrocks
[08:17] <didrocks> hey pitti_, how was you week-end?
[08:22] <pitti_> didrocks: quite nice indeed, a much-needed relaxation after not having had "real" weekends for the past three weeks due to travelling :)
[08:23] <pitti_> didrocks: went from Prague to Munich on Friday night, and we spent a long time walking
[08:23] <pitti_> didrocks: how was your's?
[08:24] <didrocks> pitti_: was fine, thanks. A little bit cold, but a lot of walking in Lyon center city as well + shopping and such :)
[08:25] <geser> good morning
[08:25] <geser> can someone review/sponsor https://code.launchpad.net/~geser/evince/fix_linking_for_gir/+merge/47158 ? it fixes the current evince FTBFS in natty
[08:26] <didrocks> hey geser, will have a look today. Thanks :)
[08:55] <chrisccoulson> good morning everyone
[08:56] <pitti_> hey chrisccoulson, how are you?
[08:56] <chrisccoulson> hi pitti_ - i'm good thanks, how are you?
[08:56] <chrisccoulson> you're back from the hackfest now?
[08:58] <didrocks> good morning chrisccoulson!
[09:00] <chrisccoulson> hi didrocks, how are you?
[09:01] <rodrigo_> morning
[09:01] <didrocks> chrisccoulson: I'm fine, thanks, and you?
[09:01] <didrocks> hey rodrigo_
[09:01] <chrisccoulson> didrocks - yeah, not too bad thanks
[09:01] <rodrigo_> hi didrocks
[09:01] <rodrigo_> and chrisccoulson
[09:01] <chrisccoulson> hi rodrigo_ !
[09:05] <chrisccoulson> i'm glad my laptop is still working today, i took the display off it yesterday
[09:06] <chrisccoulson> i thought it might not work again once i put it back together again ;)
[09:16] <pitti_> chrisccoulson: yes, I am, just writing my report
[09:16] <pitti_> chrisccoulson: ugh, why disassembling your laptop?
[09:16] <pitti_> "Engineer's motto: If it ain't broken, take it apart and fix it"
[09:16] <chrisccoulson> pitti - the hinges were coming loose on my lid again
[09:17] <chrisccoulson> in fact, when i got the bezel off the display, one of the screws fell out ;)
[09:17] <pitti_> ugh
[09:17] <pitti_> that seems to be a laptop's weakest spot
[09:17] <pitti_> well, that and the inability to deal with a full cup of coffee :)
[09:17] <chrisccoulson> yeah, thats the second time i've had to tighten up the screws now
[09:18] <chrisccoulson> although, the first time it was the screws that hold the hinge on to the base, which are much easier to access ;)
[09:27] <seb128> hey
[09:29] <didrocks> salut seb128, ça va?
[09:29] <seb128> lut didrocks, ca va bien!
[09:29] <seb128> et toi ?
[09:30] <didrocks> ça roule :)
[09:50] <chrisccoulson> hey seb128, how are you?
[09:51] <seb128> hey chrisccoulson, I'm quite well, what about you?
[09:51] <seb128> chrisccoulson, did you have a nice we?
[09:51] <chrisccoulson> seb128 - yeah, not too bad thanks. i didn't do much over the weekend ;)
[09:52] <seb128> which is what weekends are for right? ;-)
[09:52] <chrisccoulson> i planned to wash our car, but i never got round to it in the end ;)
[09:52] <chrisccoulson> heh :)
[10:03] <pitti_> hey seb128, bonjour!
[10:03] <seb128> hey pitti_
[10:03] <seb128> back in Germany ?
[10:03] <seb128> how are you?  had a nice we?
[10:03] <rodrigo_> salut seb128
[10:04] <seb128> hey rodrigo_, how are you?
[10:04] <pitti_> seb128: yes, went to Munich Friday night, and finally enjoyed a weekend after 2 weeks :) we went for some nice long hikes
[10:04] <rodrigo_> seb128, fine, and you?
[10:05] <seb128> pitti_, great ;-)
[10:05] <seb128> rodrigo_, I'm fine thanks
[10:05] <seb128> still catching up on emails after the we!
[10:06] <rodrigo_> heh, that's the Monday top task, yeah :D
[10:07] <seb128> rodrigo_, did you have any chance to work on this g-s-d gdm issue?
[10:08] <rodrigo_> seb128, I had a quick look at gdm code, but couldn't find where to kill the gdm's g-s-d, so pinged upstream
[10:08]  * pitti_ waits for his server to come back to read mails and post week report
[10:12] <chrisccoulson_> rodrigo_, doesn't g-s-d normally just die when it loses the X connection?
[10:12] <chrisccoulson_> perhaps that's the real problem
[10:13] <chrisccoulson_> i don't think it registers with the session manager at all
[10:13] <rodrigo_> chrisccoulson_, : about that bug, it's not, it's the user's g-s-d starting when gdm's g-s-d hasn't died yet
[10:13] <rodrigo_> so the user's g-s-d dies
[10:13] <seb128> chrisccoulson_, well the issue there is that some people get the session one starting before the gdm one exit-ed
[10:13] <seb128> the session one bails out on "there is already a settings daemon running on this display"
[10:14] <rodrigo_> yeah, only one xsettings process can be running at a time
[10:14] <chrisccoulson_> i get that bit :)
[10:15] <chrisccoulson_> but if g-s-d doesn't register with the session manager, then that's probably the real bug isn't it?
[10:16] <chrisccoulson_> i think it normally just sits around until X dies
[10:16] <chrisccoulson_> i might be wrong though
[10:18] <seb128> chrisccoulson_, having it to register with the session would also give respawning on crash
[10:18] <seb128> which would be a nice to get ;-)
[10:19] <seb128> especially since the gtk theme is resetted when it crashes
[10:19] <chrisccoulson_> yeah :)
[10:24] <iansmith> pitti_, seb128: I have a question regarding Bluetooth and a fax-modem which requires a long PIN, and I was pointed in your directions by asac - might you be able to help?
[10:25] <seb128> iansmith, hey, I doubt I will be useful, I've little clue about bluetooth and no clue about fax modem or pin numbers
[10:26] <iansmith> seb128: Do you know anyone who may be able to help?
[10:26] <pitti_> iansmith: inability to enter a long pin? I think that'd be best handled in an upsream bug report, as nobody on the desktop team is particularly working on bluetooth
[10:26] <seb128> iansmith, what pitti said
[10:26] <iansmith> pitti_, seb128: Many thanks - I did log a bug, but nothing has happened in a couple of months :-(
[10:27] <seb128> iansmith, what is the bug number?
[10:27] <iansmith> seb128: Just let me find it... It may take a while...
[10:28] <iansmith> seb128: #669471 isthe bug number.
[10:29] <seb128> gnome bug #669471
[10:29] <seb128> no bot today?
[10:29] <didrocks> seems it took a long week-end :)
[10:29] <iansmith> seb128: Sorry, but I don't understand :-(
[10:30] <seb128> iansmith, oh, is that a launchpad bug?
[10:30] <seb128> https://bugs.launchpad.net/blueman/+bug/669471?
[10:30] <ubot2> Launchpad bug 669471 in blueman "Blueman fails to register long PIN" [Undecided,New]
[10:30] <iansmith> seb128: Yes - that's it - did I log it incorrectly?
[10:31] <seb128> iansmith, do you use blueman?
[10:31] <seb128> it's an universe software and you opened an upstream bug task on launchpad
[10:31] <seb128> not a surprise that nobody replied
[10:31] <iansmith> seb128: I do, but it doesn't mean I have to - as long as it works...
[10:31] <seb128> iansmith, I've no clue about blueman we don't install that in Ubuntu standard
[10:32] <seb128> it's coming from universe, not even sure if it's maintained by anyone
[10:32] <iansmith> seb128: Could you point me in the direction of the "right" way :-)
[10:32] <seb128> what are you trying to do?
[10:33] <seb128> why not trying with gnome-bluetooth with is what we use by default?
[10:33] <iansmith> seb128: I just want connectivity between my Bluetooth dongle and my PDA/ Phone & fax modem - the PHone & PDA work fine  - it's just getting so I can now use the fax modem.
[10:34] <iansmith> seb128: I thought I had tried all combinations - but I will check what is installed,and ensure that it is Gnome that is installed, not Blueman
[10:36] <seb128> well on a standard ubuntu installation you get a bluetooth icon with the indicators
[10:36] <seb128> it's gnome-bluetooth
[10:45] <iansmith> seb128: I've removed Blueman, and ensured gnome bluetooth is enabled (it wasn't removed), and I can see the modem, but I can't seem to test it is working. With Blueman it would communicate, and then tell me it couldn't establish a connection. Sorry for being such a clueless fool!
[10:46] <seb128> iansmith, I've no clue about bluetooth modem but wouldn't that require to use connman or nm rather?
[10:52] <iansmith> seb128: As far as I understand it, there are two ways to communicate - one is using a serial terminal emulator, and the other is with fax software e.g. efax of gfax  (but I don't have experience of either working due to no communication with the device!). I haven't seen anything crop up for BT in NM/ connman.
[11:36] <didrocks> fta: any idea why when I try to open anything from chromium, it keeps telling me "can't open <tar/pdf…>: it's not a folder"
[11:37] <fta> didrocks, ?? never got that. is that the exact error message?
[11:37] <fta> screenshot?
[11:37] <fta> which version is that? latest stable?
[11:38] <didrocks> fta: the version in natty, making a screenshot, one sec
[11:41] <didrocks> fta: http://people.canonical.com/~didrocks/chromium-open-file.png
[11:42] <didrocks> (confirmed it's working in double-clicking from nautilus or in firefox)
[12:03] <fta> didrocks, that error message doesn't seem to be coming from chromium. when you click on something in the dl bar, it uses xdg-open
[12:05] <didrocks> fta: right, confirmed directly with xdg-open which is broken then. Not sure what firefox is using then, but it should be something else (gio?)
[12:07] <fta> didrocks, xdg-open seems to be using gvfs-open by default (in natty), or fallback to gnome-open
[12:07] <fta> for gnome
[12:08] <fta> (unless the DE detection is broken)
[12:09] <didrocks> I guess it's trying to use gnome-open looking at it, but this one doesn't work either
[12:11] <seb128> didrocks, gnome-open doesn't work on what urls?
[12:11] <didrocks> seb128: like, download a tar.gz, then try to gnome-open <path/tar.gz> (same with pdf too)
[12:12] <seb128> didrocks, wfm
[12:12] <fta> didrocks, wfm too
[12:13] <didrocks> hum, what can be wrong in my config then? :/
[12:13] <didrocks> it tries to open it as if it was a directory…
[12:13] <seb128> didrocks, do you get the issue on any format? ie images or txt as well?
[12:13] <seb128> do you get the issue if you "gnome-open example.pdf"
[12:13] <seb128> ie without a directory name?
[12:14] <didrocks> seb128: yeah, seems to be on everything (with or without a directory in the path, every file format)
[12:14] <seb128> weird
[12:15] <seb128> is gvfs-open doing the same thing?
[12:15] <didrocks> gvfs-open isn't installed
[12:15] <didrocks> let me do it
[12:15] <seb128> ok, for me neither
[12:16] <seb128> it's not required, that's just to check if gvfs has the same issue
[12:16] <didrocks> ok, was wondering if it was related :)
[12:16] <didrocks> trying
[12:16] <didrocks> same
[12:17] <fta> didrocks, can you check the url xdg-open receives from chromium? (maybe add "echo $@ >> /tmp/xdg.txt" at the top of the script)
[12:17] <didrocks> fta: sure, one sec
[12:17] <seb128> didrocks, can you gvfs-info on the file and pastebiny it?
[12:17] <didrocks> seb128: http://paste.ubuntu.com/557616/ on a text file
[12:19] <seb128> didrocks, does it work in a guest session?
[12:20] <didrocks> fta: it receives an absolute path, nothing fancy
[12:20] <didrocks> seb128: good idea, trying
[12:21] <fta> didrocks, maybe a problem with the space and/or parentheses in your filenames (not unusual in shell scripts)
[12:26] <didrocks> fta: no, I tried with an unicode only path
[12:26] <fta> ok
[12:26] <didrocks> ok, so chromium doesn't seem to work in the guest session
[12:26] <didrocks> however, I tried xdg-open directly
[12:27] <didrocks> it prompts a gnome dialogbox asking which is my prefered file manager (and proposing nautilus)
[12:27] <didrocks> so, it definitively wants to bind that to a file manager
[12:27] <fta> bug 577919?
[12:27] <ubot2> Launchpad bug 577919 in gdm-guest-session "chromium-browser fails to start (guest account, OpenVZ): "Failed to move to new PID namespace: Operation not permitted"" [Low,Confirmed] https://launchpad.net/bugs/577919
[12:28] <didrocks> fta: same, right
[12:28] <didrocks> I guess it's an apparmor thing, should strace it
[12:28] <fta> try with --no-sandbox
[12:28] <fta> but it's not recommended to keep it
[12:29] <fta> + disabled
[12:29] <didrocks> fta: ok, will give it a try, thanks
[12:46] <seb128> pitti, will you do a gdm update today?
[12:46] <pitti> seb128: for the focus fix?
[12:46] <pitti> thought about it
[12:47] <pitti> our CDs are back in reasonable shape; still need to do a smoketest
[12:47] <seb128> pitti, ok, I've other changes I want to get in, please ping me before doing an upload if you do one
[12:47] <pitti> seb128: ah, ok
[12:47] <seb128> pitti, you will just use vuntz's patch for it?
[12:47] <pitti> seb128: yes, if it works (we have tons of patches, after all)
[12:47] <seb128> ok
[12:48] <seb128> chrisccoulson_, is firefox listing a week worth in history under "Today" a known issue?
[12:49] <chrisccoulson_> seb128 - i don't think so
[12:49] <seb128> like it's listing launchpad bugs and components pages I didn't access today for sure, likely last week
[12:49] <seb128> Today
[12:49] <seb128> > launchpad.net
[12:49] <seb128> the history is sorted by "date and site"
[12:50] <chrisccoulson_> hmmmm :/
[12:50] <seb128> chrisccoulson_, do you get the same issue?
[12:50] <chrisccoulson_> it doesn't seem like it. i just had a look, and it seems to be only sites i've visited today
[12:51] <seb128> ok, weird
[12:51] <seb128> usually it's fine I think, not sure what's going on today
[12:51] <ari-tczew> didrocks: could you delete Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/hamster-applet/ubuntu ?
[12:51] <ari-tczew> it's in universe
[12:52] <seb128> chrisccoulson_, ok, it's not only last week, it seems it lists the fd.o history of things it knows about and quite some launchpad ones as well
[12:55] <ari-tczew> kklimonda: delete Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/hamster-applet/ubuntu from d/controls. branches for universe are deprecated and going to remove.
[12:55] <didrocks> someone just did it
[12:55] <seiflotfy_> pitti, sup
[12:56] <kklimonda> ari-tczew: sure, done
[12:56] <virtuald> *****
[12:56] <seb128> ari-tczew, could you try to not ping several people just because one didn't reply immediatly? you just lead to work duplication
[12:57] <ari-tczew> seb128: ?
[12:57] <czajkowski> heh
[12:57] <seb128> ari-tczew, well you pinged didrocks then kklimonda, by the time didrocks read your request kklimonda had it done and didrocks wasted time
[12:57] <ari-tczew> seb128: I don't understand
[12:57] <ari-tczew> seb128: no
[12:57] <ari-tczew> seb128: calm down and listen
[12:58] <seb128> don't tell me to calm down when I'm not angry to start ;-)
[12:58] <ari-tczew> seb128: didrocks has got access to ~ubuntu-desktop, so I pinged him to check branch - my bad that it was deleted in the past
[12:58] <ari-tczew> but kklimonda want to be sponsored for universe and I pinged him to fix his branch
[12:58] <ari-tczew> I don't see a duplication
[12:59] <seb128> k
[12:59] <ari-tczew> maybe I am wrong?
[12:59] <seb128> dunno, I just saw that by the time didrocks checked there was no vcs to clean
[12:59] <seb128> seems that was a mistake so let's forget about it and move on ;-)
[12:59] <ari-tczew> yes my bad
[12:59] <seb128> no worry
[13:00] <ari-tczew> ok
[13:27] <fta> was the last gdm supposed to fix the keyboard layout issue?
[13:29] <seb128> what gdm keyboard layout issues?
[13:29] <seb128> there is no gdm keyboard layout issues known
[13:32] <desrt> seb128: hey.  can you help me with an upload issue?
[13:32] <seb128> desrt, hey, depends of the issue, tell us
[13:33] <seb128> grr, can't figure what is bring python-gnome2 on the livecd images
[13:33] <desrt> http://fpaste.org/CO63/
[13:34] <seb128> desrt, you uploaded a .dsc and a .git?
[13:34] <desrt> i did dput on a .changes
[13:34] <desrt> it did what it did :)
[13:34] <desrt> but my source/format is 3.0 (git)
[13:34] <geser> does LP perhaps not like 0 as version?
[13:34] <seb128> desrt, shouldn't you have an upstream tarball as well?
[13:34] <seb128> desrt, that and the 0 version can't be causing issues
[13:34] <desrt> native package straight out of git (i have debian packaging on a branch)
[13:34] <seb128> can't -> can
[13:35] <seb128> desrt, try with a non 0 version
[13:35] <desrt> hmm
[13:36] <desrt> do you have a particular method of packaging unreleased software?
[13:36]  * desrt wonders if it will complain about a missing tarball due to a debian revision version even with git format...
[13:36] <seb128> not really, I would take the configure version and add a ~git something
[13:36] <desrt> makes sense
[13:37] <desrt> have you seen this git-describe thing?
[13:37] <seb128> no, we don't use git a lot around
[13:37] <desrt> juergbi is using it in vala.  i'm thinking about it.  it's pretty awesome.
[13:37] <seb128> try asking on #launchpad maybe
[13:37] <seb128> I would not be surprised if soyuz didn't handle the 3.0 (git) format
[13:37] <desrt> it takes the last tag on the current branch and appends the number of commits that have happened since then to it, plus the abbreviated git commit tag
[13:38] <desrt> so you get a version like 0.7.1-5-abcdef
[13:38] <desrt> and you can setup autotools to use that (for pkgconfig files, even).  pretty neat.
[13:38] <seb128> nice
[13:38] <desrt> cdbs for qmake, btw, is pretty interesting :)
[13:39] <desrt> i was swearing at it a lot when it wouldn't take the files from my debian/tmp/ directory for the separate binary packages
[13:39] <fta> seb128, when i type my login, i have an unexpected qwerty layout, the password is in azerty (expected)
[13:39] <desrt> until i realised that the cdbs rules assume that qmake is broken (which it is) and try to take the files directly out of the source tree :)
[13:39] <seb128> fta, is the layout wrong on vts as well?
[13:39] <fta> vts?
[13:40] <fta> vtys?
[13:40] <fta> no
[13:40] <seb128> VTs
[13:40] <seb128> ie vt1
[13:40] <fta> yes, it is
[13:40] <seb128> seems rather that console-setup issue
[13:40] <fta> i regressed ~2 weeks ago
[13:40] <fta> it
[13:40] <seb128> right, there is a console-setup issue
[13:56] <desrt> seb128: you were right.  changed to 3.0(native) and everything is peachy
[13:56] <desrt> not really sure with the '(git)' gets me, to be honest
[13:58] <seb128> desrt, http://wiki.debian.org/GitSrc
[13:59] <seb128> or rather http://wiki.debian.org/Projects/DebSrc3.0
[14:00] <Laney> I always found the dpkg-source manpage to explain source formats well
[14:00] <seb128> desrt, the debian dir is maintained with git if you use that
[14:04] <ari-tczew> kklimonda: why we should bump debhelper, upgrade to 3.0 source format? this is a place for Debian
[14:06] <seb128> pitti, was there any decision about the at-spi version to use this cycle?
[14:06] <seb128> rodrigo_, ^
[14:07] <pitti> seb128: deferring to TheMuso
[14:08] <seb128> pitti, what was the conclusion when you discussed it in Dallas?
[14:08] <pitti> seb128: that TheMuso needed to look into a problem with bonobo, and once that's fixed, we can switch over
[14:09] <desrt> seb128: i have the debian/ directory in upstream git on a branch
[14:09] <seb128> desrt, well, the format is different from the storage
[14:10] <desrt> i noticed that i get some extra checks
[14:10] <seb128> desrt, sourve v3 (git) would mean you have your upstream tarball and a diff.gz where the diff.gz is a git repository
[14:10] <desrt> with 3.0(git), for example, it makes sure all my changes are committed before i try to roll the release
[14:10] <desrt> hm.  it seemed just to make a .git and a .dsc/changes
[14:10] <seb128> desrt, so you maintain your debian dir in a git, not your source in git
[14:10] <desrt> oh.  i see.
[14:11] <desrt> ya.  not what i'm doing here.
[14:11] <seb128> what you do is usual source v3 quilt
[14:11] <desrt> i was reading some stuff last night about releasing out of upstream git too
[14:11] <desrt> shallow clones and stuff...
[14:11] <seb128> like you have upstream and debian dir in git and you use debian/patches in quilt format to add patches
[14:12] <desrt> i guess quilt with 0 patches is pretty much like native?
[14:12] <desrt> ...assuming the debian/ directory is in the 'upstream' tarball
[14:12] <desrt> eh.  this will be something to worry about after i actually release
[14:12] <desrt> (which at this point i see no real benefit in doing)
[14:13] <seb128> right
[14:13] <desrt> i have to admit... git direct to PPA is a pretty nice system :)
[14:13] <desrt> tarballs are so 2010
[14:15] <desrt> sort of works nicely with qmake too (since there is no 'make install' or 'make dist')
[14:15] <seb128> rodrigo_, Laney: would it be any way to drop the tomboy depends on libgnome24-cil?
[14:16] <seb128> libgnome2.24-cil
[14:16] <desrt> dbarth: awake?
[14:16] <seb128> it's using the gconfpeditor bindings from there
[14:16] <seb128> but that brings in the gnomevfs-cil and gnomevfs C stack
[14:17] <seb128> could we port that code away from gconfpeditor or copy that binding to tomboy?
[14:22] <bcurtiswx_> good day all
[14:23] <seb128> hey bcurtiswx_
[14:23] <bcurtiswx_> hi seb128 :)
[14:23] <seb128> bcurtiswx_, great work getting empathy updated ;-)
[14:23] <bcurtiswx_> seb128, well it was a successful failure..
[14:24] <dbarth> desrt: sure
[14:24] <dbarth> desrt: hi Ryan
[14:24] <bcurtiswx_> seb128, got it to build OK with the patches, but found out in the end due to indicate getting as much attention and upgrades as it is, that the patches were pretty bad now.. so for now it's just a source build with no indicator support ATM
[14:24] <dbarth> desrt: aren't you in holidays today?
[14:24] <bcurtiswx_> seb128, kenvandine has it on his long term list of fixes to make.. so the ball is out of my court so to speak
[14:25] <desrt> dbarth: ya
[14:25] <desrt> dbarth: so don't expect to see me around much
[14:25] <Laney> seb128: maybe it could be ported, could you ask sandy?
[14:26] <desrt> but i wanted you to know that the PPA is up now
[14:26] <bcurtiswx_> seb128, but thx though.. it was a pain and in the end I learned a TON :)
[14:26] <desrt> dbarth; https://launchpad.net/~desrt/+archive/dconf-qt
[14:26] <kenvandine> bcurtiswx_, great, so got it in the ppa?
[14:26] <seb128> bcurtiswx_, great, should be easier from now on
[14:26] <seb128> hey kenvandine
[14:26] <kenvandine> hey seb128
[14:26] <bcurtiswx_> kenvandine, its in the gnome3 PPA yes, with the series file full of comments ;)
[14:26] <seb128> Laney, well I guess upstream will want to port to gsettings rather
[14:26] <seb128> Laney, the question is mostly one specific for us while we stay on gconf this cycle
[14:27] <bcurtiswx_> well actually i may need to push
[14:27]  * bcurtiswx_ checks
[14:28] <bcurtiswx_> kenvandine, OK, it's all pushed and up to date in the gnome3 code and PPA
[14:28] <Laney> yeah well that might be some way off, so he might accept a patch to port to gconf-sharp
[14:29] <seb128> rodrigo_, ^
[14:29] <seb128> do you think that's a task you can take on?
[14:30] <Laney> the API is pretty easy, http://www.go-mono.com/docs/monodoc.ashx?link=N%3aGConf
[14:48] <bdrung> hi, libkibi was promoted to main. now i will start patching applications to use libkibi. is there anything that i should know that is gnome packaging specific?
[14:48] <chrisccoulson_> which applications? was that discussed with anybody?
[14:49] <seb128> bdrung, what is libkibi?
[14:49] <chrisccoulson_> that's what i was wondering ;)
[14:50] <seb128> bdrung, GNOME -> open bugs with the patches upstream if you can
[14:50] <seb128> we are not likely to distro patch specific changes which have not been discussed upstream if we don't have to
[14:50] <bdrung> seb128: https://launchpad.net/libkibi and http://overbenny.wordpress.com/2011/01/08/nautilus-with-libkibi/
[14:50] <bdrung> seb128: i opened upstream bugs
[14:50] <seb128> what was upstream responses?
[14:51] <milanbv> I really don't see GNOME adding an external dep just to show file sizes when GLib has functions for it :-/
[14:51] <bdrung> seb128: one reject, transmission is working on adoption.
[14:52] <seb128> bdrung, which one refused it? we are not likely to take it for things which upstream refused
[14:52] <bdrung> milanbv: that function should be deprecated. i am going to discuss if glib wants to adopt the ~10 functions needed.
[14:52] <bdrung> seb128: they want to have the functions in glib.
[14:52] <chrisccoulson_> getting the functionality in to glib would be better
[14:52] <seb128> right, getting it in glib would be better
[14:52] <chrisccoulson_> having a separate library just for displaying units seems overkill
[14:53] <seb128> doesn't seem worth the work and the extra lib
[14:53] <seb128> we are not likely to use this new lib in GNOME
[14:53] <bdrung> chrisccoulson_: i want to use this library in non-glib C programs too
[14:53] <milanbv> I think the conclusion last time was that GLib wouldn't add customizable functions?
[14:54] <bdrung> milanbv: then we are back at the no-progress situation. some want base10, some want base2, but no decision is taken.
[14:55] <bdrung> some applications use their own implementation for size conversion.
[14:58] <milanbv> yeah, but a separate lib for that is really overkill
[15:00] <bdrung> milanbv: better solution what a non-glib C program should use for size conversion? pull the complete glib?
[15:02] <seb128> bdrung, the "complete glib" is part of standard linux systems nowaday
[15:03] <seb128> bdrung, the "complete glib" is part of standard linux systems nowaday
[15:03] <seb128> ups
[15:03] <seb128> bdrung, like used in any gtk or qt application, so it shouldn't be an issue to depends on it
[15:04] <seb128> you can still provide a standalone libraries for things which don't use those but we will not add an extra library to the depends
[15:04] <bdrung> seb128: there are command line tools outside gtk and qt
[15:04] <seb128> we try to reduce the number of libraries
[15:04] <seb128> bdrung, cf what I just wrote
[15:04] <seb128> it's fine for them to use it
[15:04] <seb128> we will not make GNOME use an extra library
[15:04] <seb128> it adds clutter and start time
[15:04] <seb128> it's also the wrong way to deal with that issue
[15:05] <bdrung> seb128: what's the correct way?
[15:05] <seb128> get glib to do the right thing
[15:06] <seb128> the right thing could be to respect a gsettings key which define the format the user want to use
[15:12] <rodrigo_> seb128, what task?
[15:12] <seb128> rodrigo_, tomboy porting from gconfpeditor to gconf#
[15:12] <seb128> rodrigo_, so we can drop the depends on libgnomeui2.24-cil
[15:13] <seb128> which is bringing libgnomevfs-cil on the CD
[15:14] <rodrigo_> seb128, ugh, it uses gconf_peditor?
[15:16] <rodrigo_> seb128, but yes, sure, I can take it
[15:16] <rodrigo_> is there a bug #?
[15:17] <seb128> rodrigo_, it seems to, at least the configure checks for it and it depends on it
[15:17] <seb128> rodrigo_, no, but I will open one and assign it to you if that's fine
[15:17] <seb128> rodrigo_, you might want to check with sandy what are upstream plans or if they would welcome a patch?
[15:19] <rodrigo_> seb128, yes, assign it to me
[15:19] <rodrigo_> and yes, will talk with sandy
[15:19] <seb128> rodrigo_, thanks, no hurry it's a cleaning task, it can land in some weeks or next cycle
[15:19] <seb128> rodrigo_, so don't stress over it if you have other things on your list
[15:19] <rodrigo_> seb128, ok :)
[15:20] <seb128> thanks ;-)
[15:20] <rodrigo_> although it shouldn't be hard to replace, afaik, if it's the same gconf_peditor there was on g-c-c
[15:20] <seb128> rodrigo_, btw do you know if there was a decision on at-spi against at-spi2 for this cycle?
[15:20] <rodrigo_> seb128, for natty? at-spi
[15:20] <rodrigo_> seb128, we just needed a patch from at-spi2, so that's in our packages now, afaik
[15:21] <seb128> rodrigo_, why not at-spi2?
[15:21] <seb128> rodrigo_, it's the only things keeping bonoboui in the default installation
[15:21] <seb128> rodrigo_, well I guess that's a question for TheMuso rather than you?
[15:22] <seb128> but cleaning libbonoboui would be nice
[15:22] <rodrigo_> seb128, hmm, I think it introduces some regressions, but not sure
[15:22] <rodrigo_> yes, TheMuso should know better
[15:22] <seb128> ok
[15:24] <bdrung> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=640432
[15:24] <ubot2> Gnome bug 640432 in general "integrating libkibi into glib?" [Enhancement,Unconfirmed]
[15:24] <seb128> bdrung, thanks
[15:25] <seb128> bdrung, your bug might lack a rational or argument for that library
[15:25] <seb128> or those functions
[15:25] <bdrung> seb128: discussing this with the glib developers was on my todo list.
[15:27] <seb128> bdrung, ok, let's see what they say, could well be one of those "GNOME should just do the right thing and enforce one format rather than letting that be an option" though
[15:27] <bdrung> seb128: yes. but then the bikeshed discussion start, what's the "right" thing is.
[15:28] <chrisccoulson_> woah, compiz is using 500MB of RAM on my laptop
[15:28] <bdrung> seb128: would pointing to http://bazaar.launchpad.net/~libkibi-dev/libkibi/trunk/view/head:/doc/byteprefix.5.in help?
[15:28] <chrisccoulson_> and unity-panel-service using 300MB
[15:28] <chrisccoulson_> unity is heavy ;)
[15:28] <seb128> chrisccoulson_, there is a leak when you open the dash if you played with that a bit
[15:28] <bdrung> unity is behaving wrong all the time on my system.
[15:29] <seb128> bdrung, can't hurt to give some pointer to documentation
[15:29] <chrisccoulson_> seb128 - oh, yeah, i just opened it a few times here, and it went up by another 150MB
[15:29] <seb128> chrisccoulson_, blame njpatel
[15:29] <seb128> ;-)
[15:29] <chrisccoulson_> njpatel, is that your fault? ;)
[15:30] <chrisccoulson_> all your RAM are belong to us
[15:31]  * micahg feels like that about Firefox  3886 micah     20   0 4154m 1.7g  18m S  100 45.7 945:41.92 firefox-4.0-bin
[15:31] <njpatel> chrisccoulson_, waagwan?
[15:33] <seb128> njpatel, the unity dash and firefox try to compete in ram usage contest
[15:33] <seb128> njpatel, seems you are winning this week ;-)
[15:33] <njpatel> seb128, interesting...seriously?
[15:34] <seb128> njpatel, read the few lines before the highlight
[15:34] <njpatel> wow fudge
[15:34] <seb128> njpatel, bug #705705
[15:34] <ubot2> Launchpad bug 705705 in unity "unity 3.2.14 is causing memory leak in compiz when opening places" [Undecided,New] https://launchpad.net/bugs/705705
[15:34] <seb128> njpatel, on launchpad
[15:35] <njpatel> well, that's not good, is it?
[15:36] <seb128> njpatel, not really, you might want to target the bug for this week round
[15:36] <njpatel> wow
[15:36] <seb128> njpatel, well it's not likely people use the dash much yet since it doesn't do a lot
[15:36] <njpatel> 100MB a time
[15:36]  * njpatel rocks at mem leaks
[15:36] <seb128> ;-)
[15:37] <seb128> let's blame kamstrup to not spotting it in code review!
[15:37] <kenvandine> hehe
[15:37] <njpatel> that works for me
[15:38] <njpatel> compiz is using 2.2GB here
[15:38] <njpatel> though that's on 4096x1152, so it does have more to show etc
[15:39] <seb128> 270m there but I opened the dash only once that was to workaround the events issue
[15:41] <bdrung> seb128: quote from #gtk+: <mclasen> we deprecate the glib api and agree that it was a mistake to ever go there
[15:42] <seb128> bdrung, so what applications supposed to use or do?
[15:44] <bdrung> seb128: libkibi. ;) it's the easiest way for the glib developers to say that this functionality doesn't belong to glib and throw it out.
[15:44] <seb128> well seems to be bouncing the issue
[15:44] <seb128> i.e rather than having a glib function which gives some consistency it let the softwares writters on their own to use libkibi or do their own thing
[15:45] <seb128> seems rather a step backward
[15:45] <seb128> no?
[15:47] <bdrung> seb128: somehow, yes.
[15:48] <seb128> bdrung, *great* :-(
[15:48] <bdrung> seb128: i don't know how long it will take to get a proper solution into gnome.
[15:49] <seb128> bdrung, just by curiosity what are other systems doing about units? do they let pick the format to use?
[15:49] <bdrung> seb128: KDE does.
[15:50] <seb128> bdrung, well I mean real systems
[15:51] <bdrung> seb128: what is a real system for you?
[15:51] <evilvish> do we patch nautilus regarding the filesizes?
[15:52] <evilvish> also..  <andre_> FYI, libkibi maintainer provided a patch for nautilus upstream. Cosimo closed it as WONTFIX
[15:52] <seb128> bdrung, not wanting to troll KDE but them having an option for something is not really a surprise
[15:52] <seb128> they tend to not be short on options
[15:53] <seb128> bdrung, but things like win XP or newers, macOS, android, etc
[15:53] <bdrung> seb128: Windows - historic base2, Mac - base10
[15:54] <bdrung> but they are probably not configurable
[15:56] <seb128> bdrung, so it seems users don't care so much about having it configurable
[15:56] <seb128> not sure why we can't just pick a default and deal with it
[15:57] <bdrung> seb128: we could pick what the units policy demands.
[15:57] <bdrung> base10 + si prefixes
[16:04] <seb128> bdrung, would work for me but well it will likely be that nobody cares enough to do the changes and we will stay on what we have now
[16:06] <bdrung> seb128: there are some people caring about it (including me).
[16:07] <seb128> right, that's not what I meant, I know you are quite interested by it
[16:07] <bdrung> seb128: that's why we have https://wiki.ubuntu.com/UnitsPolicy and brainstorm ideas like http://brainstorm.ubuntu.com/idea/21184/
[16:07] <seb128> the thing is that we on the GNOME packaging side are not interested in doing patching for it or having to deal with bugs or discussions that will go with it
[16:08] <bdrung> seb128: even if i am offering my help?
[16:08] <seb128> or rather not "not interested" but it seems work over what's it's worth, we have other things to work on
[16:08] <seb128> bdrung, yes, the issue is not to have the initial patches, it's to have to carry the diff over upstream and Debian and deal with the user complains, issue, etc
[16:09] <pitti> seb128: I'm done with gdm commits; the focus fix works fine \o/
[16:09] <seb128> pitti, excellent ;-)
[16:09] <seb128> pitti, I didn't have time to merge the change from my inbox
[16:09] <seb128> pitti, https://bugs.launchpad.net/bugs/706842
[16:09] <ubot2> Launchpad bug 706842 in gdm "gdm upstart config file lists incorrect events" [Undecided,New]
[16:10] <seb128> pitti, there is a patch from james here if you want to merge it
[16:10] <seb128> pitti, i.e if you want to get an upload, I don't want to block you
[16:10] <pitti> seb128: can do (the MP is invalid, wrong branch), but I can sort that out
[16:10] <seb128> well it's a 2 liners
[16:10] <pitti> seb128: no, I don't think it's that urgent to upload, if you want to work on other things
[16:10] <seb128> pitti, no, I just wanted to get that fix in
[16:11] <pitti> seb128: ah, ok; IDTT
[16:11] <seb128> so either do it and upload or let it for me later
[16:11] <seb128> pitti, thanks
[16:15] <kenvandine> bratsche, i have a fix for libgrip
[16:22] <seb128> mterry, hey
[16:22] <mterry> seb128, hello
[16:22] <seb128> mterry, was there anything stopping getting the new gdl in natty?
[16:22] <mterry> seb128, no...?  I'd have to look at it again.  I can push if so.  I was also going to try to answer the question about gsettings & anjuta today or tomorrow
[16:23] <seb128> mterry, ok, no hurry, I was just trying to please upstream on this one
[16:23] <seb128> it seems we could just update gdl and anjuta
[16:23] <mterry> seb128, as long as the new gdl is parallel installable of course.  There were rdepends that would need to be ported if not
[16:23] <seb128> especially if the new glade can be installed next to the current one
[16:23] <mterry> right...
[16:23] <seb128> mterry, the only rdepends I see out of anjuta is gtranslator
[16:23] <seb128> which has been ported upstream
[16:24] <seb128> that an python-gdl
[16:24] <seb128> which nothing is using
[16:24] <seb128> mterry, well check for the gsettings thing when you have time, no hurry
[16:25] <seb128> with some luck we can maybe get the new glade from debian at some point, they are active on GNOME3 in experimental now
[16:27] <didrocks> session restart, bbiab
[16:30] <bratsche> kenvandine: Really?  Awesome!
[16:30] <kenvandine> yeah... :)
[16:30] <kenvandine> i'll propose a merge soon
[16:31] <bratsche> kenvandine: Awesome, thanks!
[16:31] <kenvandine> not much of a fix though...  just need to move the instantiation of the GestureManager operation to init
[16:32] <kenvandine> seems touchy for threading
[16:32] <bratsche> Okay cool
[16:32] <kenvandine> i also cleaned up the overrides file
[16:34] <bratsche> Cool
[16:41] <Amaranth> weird, evolution doesn't seem to be making my mail icon go green :/
[16:45] <seb128> pitti, dropping the libproxy0 recommends on webkit seems buggy
[16:46] <seb128> pitti, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597864
[16:46] <ubot2> Debian bug 597864 in libproxy0 "libproxy0 not functional without libmozjs2d" [Important,Fixed]
[16:46] <seb128> pitti, why is libproxy0 on the kubuntu image to start?
[16:46] <seb128> is that because of the gvfs being pulled in issue?
[16:49] <pitti> seb128: through gstreamer
[16:49] <seb128> pitti, right
[16:49] <seb128> pitti, still it seems your libproxy change is wrong
[16:49] <seb128> libproxy0 should recommends libwebkit and not be on kubuntu
[16:51] <pitti> phonon-backend-gstreamer recommends gstreamer0.10-plugins-good depends libsoup-gnome2.4-1 depends libproxy0 recommends libwebkitgtk-1.0-0
[16:52] <pitti> Richie: I guess you do want gst-good, so you need to live with libsoup-gnome2.4-1 and thus libproxy0?
[16:52] <pitti> I don't see a better way to break it up
[16:53] <pitti> seb128: would you prefer libwebkitgtk | mozjs | <insert Kubuntu browser here>?
[16:53] <pitti> ah, libproxy FTBFSed anyway due to uninstallable kdelibs5-dev
[16:54] <seb128> pitti, let me think, I guess it doesn't matter much for Ubuntu since we will have webkit installed anyway
[16:54] <pitti> right
[16:54] <seb128> but it seems wrong to revert a debian change which added the recommends on purpose
[16:56] <pitti> I just don't think that adding a | kubuntu-browser alternative would be any better
[16:59] <seb128> pitti, right, I don't like that much either, I guess let it this way
[16:59] <seb128> it's still buggy but I've no good idea and it will not impact GNOME users
[16:59] <seb128> well it means that people getting libproxy used on kubuntu will run into non working proxy issues
[16:59] <seb128> since it really requires libmozjs or webkit for some features to work
[17:10] <bdrung> seb128: last comment in https://bugzilla.gnome.org/show_bug.cgi?id=640432
[17:10] <ubot2> Gnome bug 640432 in general "integrating libkibi into glib?" [Enhancement,Unconfirmed]
[17:13] <seb128> bdrung, nice comment, thanks for the summary
[17:13] <seb128> bdrung, I'm not sure why "do nothing" won't solve the problems?
[17:13] <seb128> we have an api working in a consistent way
[17:13] <seb128> we just need to patch applications to use it correctly no?
[17:14] <bdrung> seb128: because the unit used by g_format_size_for_display violates all norms.
[17:15] <bdrung> seb128: some GNOME applications uses own functions.
[17:15] <seb128> why do they do this?
[17:16] <bdrung> seb128: because they prefer IEC prefixes.
[17:16] <bdrung> IIRC, e.g. gnome-system-monitor
[17:16] <seb128> well so none of the solution you list will solve the fact that appwriters have their own idea of what prefix is the right to use
[17:17] <seb128> so they will not use whatever standard api which give them something else
[17:19] <bdrung> seb128: unless it can be configured to what they want.
[17:23] <seb128> bdrung, having a way to configure units doesn't seem to be a win for users
[17:32] <kklimonda> ari-tczew: it was debian who has updated to 3.0
[17:37] <rodrigo_> hey kklimonda
[17:37] <kklimonda> hey rodrigo_ :)
[17:37] <kklimonda> rodrigo_: how was your day?
[17:38] <rodrigo_> kklimonda, quite productive, finally could run unity and debug it :-D
[17:39] <kklimonda> brr, unity.. ;)
[17:39] <rodrigo_> kklimonda, I'm about to leave in a minute or 15, but ping me tomorrow and we talk about the CouchdbDocument removal, ok?
[17:39] <kklimonda> rodrigo_: sure
[17:39] <rodrigo_> kklimonda, doesn't work for you neither?
[17:39] <kklimonda> rodrigo_: it's slow :/
[17:39] <rodrigo_> yes, it is, when it runs (for me) :-)
[17:40] <kklimonda> rodrigo_: I'm not even sure anymore, if that's unity being slow, or if there is a problem with compiz - when I keep terminals open in the full screen, I can barely use them..
[17:40] <chrisccoulson_> lol, my daughter is very vocal tonight
[17:41] <rodrigo_> full screen? you can maximize windows?
[17:41] <rodrigo_> they all show up without a border, badly placed
[17:41] <kklimonda> and, because most of my "desktop" usage consists of opening bunch of terminals, I've returned to the gnome+metacity.
[17:41] <pitti> good night everyone!
[17:41] <kklimonda> night pitti
[17:41] <chrisccoulson_> good night pitti!
[17:41] <rodrigo_> bye pitti
[17:42] <pitti> have to get used to early day cycles again..
[17:42] <kklimonda> rodrigo_: yeah, it works pretty well if a bit slow :/
[17:42] <seb128> 'night pitti
[17:42] <rodrigo_> kklimonda, heh, you remind me of a guy that worked on the ximian desktop, and his desktop was an emacs session :-)
[17:42] <kklimonda> rodrigo_: lately that's how my desktop looks like.
[17:43] <kklimonda> rodrigo_: that, or the windows xp session in virtualbox.. and full screen emacs inside of it.
[17:43] <kklimonda> rodrigo_: that's you fault btw.
[17:43] <kklimonda> rodrigo_: I've been happy using vim, and saying that emacs sucks
[17:44] <rodrigo_> kklimonda, heh, I thought I convinced you emacs was better
[17:44] <kklimonda> and then I saw you using it, and you have mentioned using both, and said that emacs is so much better for longer sessions.. so I had to actually try it, as opposed to just bashing without actually using it. And now I can't go back to vim ;)
[17:45] <Laney> but :wq!
[17:45] <rodrigo_> kklimonda, ah, cool!!
[17:45] <rodrigo_> kklimonda, vim is great for quickly editing files from the terminal
[17:45] <kklimonda> yeah, that it is
[17:45] <rodrigo_> but emacs has everything you need :-D
[17:46] <bcurtiswx_> seb128, the gnome-icon-theme package is failing on configure for a  gtk-update-icon-cache which is in libgtk3.0-0.  I've set it as a dep and it still fails there.  What reason might this be?  Could that be deprecated in gtk3?
[17:47] <bcurtiswx_> seb128, i've put libgtk3.0-dev as well same result
[17:48] <seb128> bcurtiswx_, it's in the -bin
[17:48] <rodrigo_> ok, time to get some fresh air, bye all
[17:49] <seb128> bye rodrigo_
[17:50] <bcurtiswx_> seb128, yup tried that too
[17:50] <seb128> bcurtiswx_, do you have a gtk-update-icon-cache on disk?
[17:57] <bcurtiswx_> seb128, yes i believe so
[17:57] <seb128> bcurtiswx_, dunno then, check the config.log
[17:58] <bcurtiswx_> seb128, OK
[18:09] <bcurtiswx_> I get a lot of /usr/share/cdbs/1/rules/simple-patchsys.mk:31: WARNING:  simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead  but the watch file is 3 not 2
[18:10] <bcurtiswx_> dang-it here i go again
[18:54] <bdmurray> Could somebody review and merge this - https://code.launchpad.net/~brian-murray/launchpad-integration/stream/+merge/47291
[19:13] <kenvandine> bratsche, https://code.edge.launchpad.net/~ken-vandine/libgrip/python_gi_override/+merge/47294
[19:16]  * bratsche clicks
[19:20] <bratsche> kenvandine: Merged it, thanks very much!
[19:33] <kenvandine> bratsche, np
[19:33] <kenvandine> doing the packaging branch now
[19:33] <kenvandine> i assume we need to add a python-grip :/
[19:33] <bratsche> brb, restarting.
[19:52] <kenvandine> bratsche, ok i proposed the packaging branch too... but i made it prereq your python-fixup-wip branch
[19:53] <bratsche> Awesome
[19:53] <bratsche> So should I submit a merge request for that one?
[19:54] <kenvandine> well merge your branch in trunk and merge my packaging in the ~utouch-team packaging branch
[19:55] <kenvandine> then when there is another release the overrides file will get installed
[19:55] <kenvandine> as well as the gir stuff
[19:55] <kenvandine> bratsche, also, you should make sure you delete your locally created Grip.py file and any pyc files created
[19:56] <bratsche> Okay.
[19:57]  * kenvandine now does the same for libdee
[19:57] <kenvandine> spreading the love for gi :)
[19:57] <bratsche> kenvandine, https://code.launchpad.net/~bratsche/libgrip/python-fixage-wip/+merge/47301
[19:58] <kenvandine> ok, i can't review that though :)
[20:00] <bratsche> Oh okay.. let me try to get someone in utouch to review it.
[20:08] <bratsche> bryceh: Do you happen to know if Natty already supports Sandy Bridge graphics?  And if not, do you know if xorg-edgers supports it already?
[20:11] <bryceh> bratsche, I think there's some limited support in natty now.  But I'd focus on what's in xorg-edgers, that should provide better support
[20:12] <bryceh> bratsche, also note that you may need a .38-ish kernel to get the best support
[20:12] <bryceh> some of the sandybridge support was added for .38 but not .37
[20:14] <bratsche> bryceh: Are we planning to use that in Natty?
[20:14] <bryceh> bratsche, yes
[20:14] <bratsche> Awesome.
[20:15] <bratsche> Awesome to the max!
[20:15] <bratsche> :)
[23:49]  * bdrung pokes dobey (and poolie in #launchpad) to look at bug #524680
[23:49] <ubot2> Launchpad bug 524680 in ubuntu-dev-tools "[lp-project-upload] not really ubuntu specific" [Wishlist,Triaged] https://launchpad.net/bugs/524680