[01:41] <jbicha> RAOF: howdy, would you mind looking at libosinfo which has been stuck in the new queue for a while?
[02:12] <RAOF> jbicha: I'd love to, but I'm not an archive admin.  I've just got the powers for SRU work :)
[02:17]  * RAOF should perhaps start working towards actual AA status.
[02:18] <jbicha> oh, tricky, I'll try pitti then
[02:59] <desrt> kenvandine: good evening
[02:59] <kenvandine> hey desrt
[02:59] <desrt> what brings you here at this time of night?
[02:59] <kenvandine> notta, just doing some hacking
[02:59] <desrt> ditto
[03:00] <kenvandine> i usually avoid irc in the evenings, less distractions
[03:00] <kenvandine> but not tonight... very distractable :)
[03:03] <desrt> wanna help rewrite the hud? :)
[03:24] <desrt> RAOF: so i just made an interesting discovery
[03:25] <RAOF> Indeed?
[03:25] <desrt> RAOF: i'm under unity right now and i can overcome the barriers effortlessly if i aim for the corners
[03:25] <desrt> but they're still there in the middle of the screen
[03:25] <RAOF> That's because there's no barrier on the corner.
[03:25] <desrt> oh.
[03:25] <desrt> i don't think that's true...
[03:25] <RAOF> Well, there's no barrier up the top, on the panel.
[03:25] <desrt> there's something here
[03:25] <desrt> it's just not very strong
[03:25] <RAOF> But there is a barrier on the bottom, and you can go under it.
[03:26] <RAOF> Which is a known bug :)
[03:26] <RAOF> Actually... didn't I fix that?
[03:29]  * RAOF is currently in the process of writing tests for that functionality.
[03:30] <RAOF> Whereupon he shall fix up all the stupid.
[03:34] <jbicha> all? ;-)
[03:36] <RAOF> *ALL*
[03:39] <jbicha> cool
[04:43] <pitti> Good morning
[04:44] <pitti> jbicha: can have a look
[05:49] <smspillaz> RAOF: around ?
[05:49] <RAOF> smspillaz: Shoot.
[05:49] <smspillaz> RAOF: do you know what the acceptable ranges of values are for XConfigureWindow ?
[05:50] <smspillaz> eg for
[05:50] <smspillaz> xwc.x,y,width,height,border_width
[05:51] <smspillaz> I know width and height need to be > 1
[05:51] <RAOF> I don't know offhand.
[05:53]  * smspillaz has a look at the X sources
[05:53] <RAOF> smspillaz: Already there :)
[05:53] <RAOF> smspillaz: You're after dix/window.c:ConfigureWindow :)
[05:58] <smspillaz> RAOF: yeah, :P
[05:58] <smspillaz> RAOF: goto ActuallyDoSomething;
[05:58] <smspillaz> return Success;
[05:58] <smspillaz> SUCCESS
[05:59] <RAOF> Heh.
[05:59] <RAOF> Mmm.  I particularly like the way the code inconsistently uses return(Success); and return Success;
[06:11] <smspillaz> indeed
[06:58] <didrocks> good morning
[06:59] <pitti> hey didrocks
[06:59] <didrocks> guten morgen pitti, how are you?
[07:00] <pitti> quite fine, thanks! how about you?
[07:00] <didrocks> I'm fine, thanks!
[07:22] <rickspencer3> good morning all, what's the word on the street about beta 1?
[07:22] <pitti> hey rickspencer3
[07:22] <rickspencer3> hey pitti
[07:23] <pitti> rickspencer3: respinning now for some issues, but nothing out of the ordinary so far
[07:23] <didrocks> bonjour rickspencer3
[07:23] <rickspencer3> bonjour didrocks
[08:27] <Sweetshark> g'morning.
[08:28] <pitti> hey Sweetshark
[08:48] <seb128> hey
[08:53] <pitti> bonjour seb128
[08:54] <seb128> pitti, hey, how are you? happy meeting reminder day!
[08:54] <pitti> seb128: oh, thanks
[08:58] <seb128> re
[08:58] <seb128> hum, dsl ip change
[08:58] <seb128> pitti, I was saying
[08:58] <seb128> pitti, hey, how are you? happy meeting reminder day!
[08:58] <seb128> (dunno if that went through before the ip change)
[08:58] <pitti> seb128: still got that
[08:59] <seb128> ok
[09:08] <pitti> Sweetshark: do you have some time to work on the openoffice.org-report-builder package today, to fix upgrades?
[09:18] <Sweetshark> pitti: yes, that should work.
[09:37] <yawstick_1> I deleted the status bar at the bottom where minimized programs usually show
[09:37] <yawstick_1> using ubuntu 10.04 on a laptop
[09:37] <yawstick_1> now if i minimize a program cant get it back
[09:38] <pitti> yawstick_1: get it back with alt+tab
[09:38] <pitti> yawstick_1: and/or re-add the task bar widget to a different panel
[09:39] <yawstick_1> Ive added another bar but how do I get the minimized programs to show on it
[09:40] <pitti> yawstick_1: please continue in #ubuntu
[09:41] <yawstick_1> i was there and got no response... thanks anyway
[09:45] <ricotz> good morning
[09:45] <pitti> hey ricotz
[09:45] <ricotz> pitti, hi, thanks for sponsoring libpst
[09:45] <seb128> hey ricotz, seems pitti beat me to it, he sponsored before I had to look at it today ;-)
[09:46] <seb128> pitti, thanks for the sponsoring btw ;-)
[09:46] <ricotz> seb128, hi
[09:46] <pitti> the early bird catches the upload :)
[09:46] <ricotz> seb128, i guess there is still vala 0.15.2 and folks 0.6.7 ;)
[09:46] <seb128> ricotz, I can do vala, the other one will be for kenvandine
[09:47] <seb128> ricotz, but feel free to work on that and ask for sponsoring ;-)
[09:47] <ricotz> seb128, i am currently doing 0.15.2 and pushed 0.6.7 to gnome3 ppa
[09:47] <seb128> ok, thanks
[09:47] <ricotz> https://launchpad.net/~gnome3-team/+archive/gnome3/+sourcepub/2278624/+listing-archive-extra
[09:48]  * seb128 shakes fist at pitti
[09:48] <pitti> seb128: wh..what did I break?
[09:48] <seb128> pitti, would you stop closing bugs, you are still a bug ahead of me!
[09:48]  * pitti hurries to send the report reminder
[09:48] <pitti> oh, that :)
[09:48] <seb128> one little bug
[09:48] <seb128> I will get you, oh yes, I will ;-)
[09:48]  * seb128 hugs pitti
[09:48] <pitti> seb128: and I fixed your .xsession-errors bug in trunk, too!
[09:48] <seb128> pitti, I saw, thanks a lot!
[09:52] <ricotz> seb128, https://launchpad.net/~gnome3-team/+archive/gnome3/+sourcepub/2278642/+listing-archive-extra
[09:53] <ricotz> might be good to have vala done before uploading folks to have it build against the newer one
[09:53] <seb128> right
[09:53] <seb128> well I will do vala first anyway since that's not on the CD
[09:54] <seb128> the other one will be blocked by the freeze in any case
[09:54] <ricotz> ok
[09:54] <ricotz> pitti, could you bump the vala builds please? -- https://launchpad.net/~gnome3-team/+archive/gnome3/+sourcepub/2278642/+listing-archive-extra
[10:06] <pitti> ricotz: done
[10:10] <ricotz> pitti, thanks
[10:33] <seb128> grrr, hate libxcb
[10:34] <seb128> why do we keep getting issues on random components due to it
[10:34] <seb128> ie bug #924612
[10:34] <ubot2`> Launchpad bug 924612 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGABRT in __GI___assert_fail()" [High,Confirmed] https://launchpad.net/bugs/924612
[10:51] <chrisccoulson> the gmail interface sucks. it doesn't let you do "Reply to list"!
[11:04] <seb128> chrisccoulson, please tell me it doesn't default to reply to all!
[11:04]  * seb128 hates people replying to the list and to you directly as well
[11:07] <didrocks> well, thundebird defaulted to reply to all until very recently :)
[11:16] <chrisccoulson> huh, X just crashed, and after i restarted, my launcher is set to not auto-hide
[11:16] <chrisccoulson> how annoying :/
[11:17] <seb128> pitti, bah, those no change rebuild are not fair :p
[11:17]  * seb128 gives up on catching with pitti
[11:17] <pitti> seb128: I didn't add tasks
[11:18] <pitti> to the bugs
[11:18] <seb128> pitti, yeah, I was speaking about bugs closing count ;-)
[11:18] <pitti> so I'd hope they wouldn't count?
[11:18] <pitti> yes, it's rather pointless
[11:18] <seb128> not sure
[11:18] <pitti> seb128: if they do, for the huge set of rebuilds (after b1), I'll use LP #12345 then
[11:18] <ubot2`> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
[11:19] <seb128> pitti, no, don't worry about count, it was a side comment ;-)
[11:19] <seb128> you can maybe catch up with didrocks though :p
[11:19] <pitti> seb128: nah, competitions should be fair :) so sorry for these extra 5
[11:19] <seb128> pitti, btw does it make sense to do rebuilds rather than wait another few weeks for stuff to clear by themself on normal uploads and then rebuild what wasn't?
[11:19] <pitti> seb128: want to upload 5 yourself to catch up?
[11:20] <seb128> pitti, no that's fine, I will get you even with those 5 :p
[11:20] <pitti> seb128: well, I already waited for the whole precise cycle until now
[11:20] <pitti> seb128: these are all packages which haven't built a single time  in precise
[11:20] <seb128> oh ok, I guess those are sources which don't get a lot of activity
[11:20] <didrocks> well, depending if you are lucky or not, but you can get a gnome tarball with a lot of upstream fixes:)
[11:21] <pitti> seb128: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/875466/comments/9 is the list, FYI
[11:21] <ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress]
[11:21] <pitti> seb128: i. e. mostly stuff that nobody cares about; except perl, I need to have a closer look there
[11:21] <pitti> I believe it's fixed with most recent mangler, though
[11:22] <seb128> pitti, oh, I'm supprise that stuff like libxdamage and libxcomposite are on there
[11:22] <seb128> I though those were actively maintained with X, I guess they are mature and don't get lot of upstream work ;-)
[11:22] <pitti> right
[11:32] <Sweetshark> pitti: do we want the libreoffice metapackage depend on libreoffice-gtk btw?
[12:02] <GunnarHj> micahg: Hi Micah, did you forget https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210 ?
[12:02] <seb128> pitti, can you build bump https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3246056 and https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3246057 for me?
[12:02] <seb128> thanks
[12:02] <seb128> lunch, bbiab
[12:14] <pitti> Sweetshark: we currently seed -gnome, which pulls in -gtk
[12:14] <pitti> seb128: done
[12:14]  * pitti utters a loud sigh for the first non-oversized image in months
[12:14] <pitti> http://cdimage.ubuntu.com/daily-live/20120228.1/
[12:14] <pitti> took some squeezing for sure
[12:15] <Sweetshark> yes, but if somebody manually reinstalls libreoffice he only gets the fugly generic UI.
[12:15] <didrocks> pitti: nice!
[12:19] <nessita> hello everyone! I can no longer swicth workspaces with CTRL+ALT+<direction>... any idea what happened?
[12:27] <seb128> nessita, hey
[12:27] <seb128> nessita, upgrade, it's fixed with today updates
[12:27] <seb128> nessita, it was a design decision reverted
[12:28] <seb128> nessita, or use super-shift-direction (was the new keybindings)
[12:28] <nessita> seb128: thanks god it was reverted!
[12:28] <nessita> :-)
[12:28]  * nessita updates again
[12:28] <nessita> seb128: hola, btw :-)
[12:28] <seb128> nessita, the intend was to have both old and new bindings but it's technically challenging so got postponed to next cycle
[12:29] <seb128> nessita, hey ;-)
[12:29] <seb128> nessita, how are you?
[12:29] <nessita> pretty good! and you?
[12:32] <seb128> nessita, I'm good thanks!
[12:36] <seb128> pitti, same on https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3246089 and https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3246090 please? ;-) I did a stupid error in the previous version
[12:42] <pitti> seb128: bumped
[12:43] <seb128> pitti, danke
[12:47] <tkamppeter_> pitti, hi
[12:49] <pitti> tkamppeter: hallo Till, wie gehts?
[12:50] <tkamppeter> pitt, gut, it is about PPD updating via CUPS trigger, bug 932882.
[12:50] <ubot2`> Launchpad bug 932882 in gutenprint "The PPD version (5.2.7) is not compatible with Gutenprint 5.2.8-pre1." [High,Confirmed] https://launchpad.net/bugs/932882
[12:51] <tkamppeter> pitti, problem is that the updating is not reliable. If in one update run (for example an update to a new distro release) a printer driver package is updated along with cups, the PPD update does not happen.
[12:53] <tkamppeter> pitti, this is because cups get shut down and the old version stopped making it unconfigured and cups gets only configured again much later in the update process. This makes the printer driver packages not executing the cups trigger as when it is trigger time, between unpacking of all packages and setting up all packages, cups is not configured.
[12:54] <tkamppeter> pitti, how can I change the dependencies of printer driver packages to assure that the triggers get always executed, for example putting the trigger execution somehow after CUPS being configured?
[12:55] <pitti> tkamppeter: perhaps you could change the trigger itself
[12:55] <pitti> tkamppeter: i. e. if the trigger gets called, but cups is not running, you leave a stamp file in /var/run/cups/update-ppd instead
[12:55] <pitti> tkamppeter: and cups' postinst would then run update-ppd during configure if it finds that stamp file?
[12:59] <tkamppeter> pitti, the "Processing triggers for cups ..." does not even appear onnn the screen. This is a message of dpkg, telling that the trigger of CUPS will get executed. So the postinst script of CUPS does not get executed at all when it is supposed to do the triggers.
[13:01] <pitti> tkamppeter: hm, that sounds weird; are you sure? perhaps you could add a touch /tmp/trigger-called or so to the postinst to check this?
[13:04] <nessita> seb128: so, I'm fully up to date, I rebooted, and I still don't have the proper keybindings for switching workspaces... shall I report this?
[13:06] <seb128> nessita, dpkg -l | grep compiz-plugins-main
[13:06] <seb128> nessita, what version did you get?
[13:06] <tkamppeter> pitti, I will try that.
[13:08] <nessita> seb128: compiz-plugins-main-default            1:0.9.7.0~bzr19-0ubuntu5                     Compiz plugins - main default collection
[13:08] <seb128> didrocks, ^ help! ;-)
[13:08] <didrocks> interesting
[13:08] <didrocks> so nessita, if you open gnome-control-center
[13:09] <didrocks> in the keyboard panel, shortcut tab
[13:09] <desrt> good morning didrocks, seb128, pitti, nessita, tkamppeter
[13:09] <didrocks> navigation
[13:09] <pitti> hey desrt, how are you?
[13:09] <seb128> desrt, hey, how are you?
[13:09] <didrocks> what do you have for ws switching?
[13:09] <didrocks> hey desrt :)
[13:09] <desrt> good.  today is the day the hud work gets finished!
[13:09] <nessita> didrocks: looking!
[13:09] <nessita> hola desrt!
[13:09] <seb128> desrt, \o/
[13:09] <seb128> desrt, I'm reading for testing ;-)
[13:09] <desrt> seb128: maybe in a few hours i have dbusmenu stuff working again in a preliminary state
[13:09] <didrocks> oh
[13:09] <didrocks> oh oh
[13:10] <nessita> didrocks: boo, why I can't resize that window?
[13:10] <didrocks> pitti: you are going to hate me
[13:10] <seb128> desrt, ok, let me know
[13:10] <tkamppeter> desrt, hi
[13:10] <pitti> didrocks: 'nother respin?
[13:10] <didrocks> pitti: yeah, there is the case where compiz has a race
[13:10] <desrt> pitti: it's not didrocks's fault.  it's bzr.
[13:10] <didrocks> and sometimes it take the compiz bindings
[13:10] <didrocks> pitti: should be fine on new install
[13:10] <nessita> didrocks: looks the shortcut is 'shift+ctrl+alt+left'
[13:10] <desrt> (this game is getting less and less plausible....)
[13:10] <didrocks> pitti: but on upgrade, they will take the metacity one
[13:11] <didrocks> nessita: yeah, I know what you get
[13:11] <didrocks> pitti: even sam isn't really aware of all the magic integration happening in compiz for that, as the keys are duplicated
[13:11] <didrocks> pitti: the fact is that unity-2d has different keybindings anyway because of metacity
[13:14] <desrt> did compiz finally stop using the metacity gconf namespace?
[13:14] <didrocks> desrt: it still does, but continue copying the same
[13:14] <didrocks> which makes horrible things like above ^
[13:15] <didrocks> nessita: you are running 2d or 3d?
[13:15]  * desrt wonders why they even bothered with only one cycle left to what is seemingly like an increasingly likely switch to gsettings
[13:16] <didrocks> desrt: well, we want to ship a working LTS :)
[13:16] <desrt> didrocks: ya.  that's why you don't mess with things and leave them as they are :p
[13:16] <nessita> didrocks: 2d
[13:16] <didrocks> pitti: so basically, 3d as the previous ws switching, not 2d
[13:17] <didrocks> which makes sense, but we can still have a racy upgrade for some
[13:19] <didrocks> pitti: if we accept that some people still get the old keybinding until beta1, that's fine, I can just stage the upload
[13:19] <pitti> didrocks: sure, that's fine
[13:19] <didrocks> ok, uploading then, and let's see how it goes
[13:20] <pitti> didrocks: would you mind adding a quick sentence about this to https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview , so that we have something to point to when users ask?
[13:20] <didrocks> pitti: sure, doing :)
[13:20] <pitti> meh, can this silly HUD please stop appearing all the time
[13:20] <pitti> I'm just switching desktops or do other stuff, I don't just press and release Alt by itself
[13:21] <didrocks> pitti: there is a compiz version under testing that get the support for it
[13:21] <didrocks> pitti: however, the unity branch is still not merged
[13:21] <pitti> didrocks: for better alt key handling you mean?
[13:21] <didrocks> yeah
[13:21] <pitti> e. g. if I press ctrl+alt and release it, it appears
[13:21] <desrt> pitti: but... don't you love the hud?
[13:21] <didrocks> we will have the fundation for it
[13:21] <pitti> desrt: well, it doesn't to much for me yet, and I don't really use menus much
[13:21] <didrocks> but not the fix, I set it as unity 5.6 goal
[13:21] <pitti> didrocks: good to hear
[13:21] <pitti> I'll just suffer quietly until then :)
[13:22] <didrocks> pitti: well, HUD is taking 4s blocking everything here
[13:22] <didrocks> pitti: so, speaking on suffering on false positive… :p
[13:27] <pitti> desrt: I actually had expected hud to search in bookmarks etc., but it doesn't seem to do any of that
[13:27] <pitti> that would be convenient in firefox IMHO
[13:27] <seb128> pitti, it does
[13:27] <pitti> not here
[13:27] <desrt> pitti: searching bookmarks is more of a shell thing, imho
[13:27] <desrt> i wonder if anyone wrote a gnome-shell extension to do that yet
[13:27] <seb128> pitti, it's supposed I though
[13:28] <desrt> (or a lense?)
[13:28] <pitti> oh, it takes a while to find it
[13:28] <seb128> desrt, hum, it should list anything which is in the menu of the focused app no?
[13:28] <seb128> desrt, bookmarks are in firefox menus, why shouldn't it work?
[13:29] <desrt> seb128: because firefox appmenu integration is presently broken? :)
[13:29] <seb128> desrt, well, then bug, not "it's a shell thing"
[13:29] <seb128> ;-)
[13:29] <desrt> seb128: i'm saying that i'd expect it to be a shell thing
[13:30] <desrt> so i can go straight to my bank or the CBC without first going through the "open a web browser" step
[13:30] <seb128> right
[13:31] <rye> seb128, i suppose that hud does not have the menu entries until that menu is opened, as if firefox creates the menus only after click. listening on "before-selected" or something signal
[13:31] <seb128> rye, oh, right
[13:31] <seb128> it's chrisccoulson's fault!
[13:32] <rye> which is why i don't use hud - both firefox and thunderbird, my default apps don't have menus available to hud. And xchat/terminal are perfect with current keybinding.
[13:33] <rye> btw, while I am still at this - my ubuntuone-indicator is displayed as "Untitled indicator" - what piece of info and how should I supply to unity for it to become titled?
[13:34] <rye> argh, this is still a unity question, sorry, /me goes to #ubuntu-unity
[13:48] <Sweetshark> ricotz: "The new ppa update for LibreOffice for Ubuntu Lucid is broken: the 'print file directly' toolbar icon points to 'pdf' rather than to the default printer."
[13:49] <Sweetshark> ricotz: Could you check that? Its a (unpublished) comment on the TDF blog.
[14:02] <ricotz> Sweetshark, works as expected here
[14:03] <ricotz> Sweetshark, "direct printing" uses the default printer, and pdf export works too
[14:09] <desrt> tedg: hey
[14:09] <desrt> tedg: can i grab a slice of your time?
[14:09] <desrt> tedg: the appmenu registrar sends WindowRegistered signals, but never WindowUnregistered
[14:10] <tedg> desrt, Hmm, I thought it did on shutdown...
[14:10] <desrt> erm.  maybe.
[14:10] <tedg> desrt, Perhaps the object isn't getting unref'd
[14:10] <desrt> but i'd expect it to do so when the window closes
[14:10] <desrt> (unless that's what you meant...)
[14:10] <tedg> Yeah, it seems that it should.
[14:11] <desrt> so
[14:11] <desrt> gdbus monitor --session --dest com.canonical.AppMenu.Registrar --object-path /com/canonical/AppMenu/Registrar
[14:11] <desrt> open a window, close it, open a window, close it
[14:11] <desrt> you see only WindowRegistered signals
[14:11] <tedg> But, I guess there's not a *huge* worry there in that the amount of memory is tiny if there's no items.
[14:12] <desrt> tedg: well, as you mention, it probably indicates some sort of leak or other memory problem within the appmenu registrar
[14:12] <desrt> and it's also raining on my parade :)
[14:12] <tedg> It would be a slight leak for applications that stayed open for a very long time and opened and closed lots of windows.
[14:12] <desrt> i disagree with that...
[14:12] <desrt> the unregister doesn't even get sent when the entire app is closed
[14:13] <tedg> Oh,  you're saying the registrar doesn't send it... I thought you were saying the application.
[14:13] <tedg> Hmm, okay.
[14:13] <desrt> so being logged in and opening/closing apps for a few weeks results in more and more leaks
[14:13] <desrt> (probably small leaks, but still...)
[14:13] <tedg> I bet it's just not sending that signal.  I mean, I only had it there to play with, I don't think anyone uses it :-)
[14:14]  * desrt uses it now :)
[14:14] <desrt> i wrote a rather complete client for the registrar yesterday
[14:14] <tedg> Okay, fine, edit: "anyone important"  ;-)
[14:14] <desrt> which was probably a waste of my time
[14:14] <desrt> since afaik, the hud service will soon be in the same process as the registrar
[14:15] <desrt> but it's useful code anyway :)
[14:15] <tedg> Heh, good for testing I'd imagine.
[14:15] <desrt> it already found a bug!
[14:36] <pitti> seb128: there's not much on https://wiki.ubuntu.com/DesktopTeam/Meeting/2012-02-28, so I don't expect that we have a meeting today
[14:36] <pitti> seb128: but if something turns up, would you be able to run it? I have an appointment this evening
[14:36] <seb128> pitti, sure, no problem
[14:42] <kenvandine> hello everyone!
[14:42] <kenvandine> i need to run out for an hour or so
[14:43] <kenvandine> bbl
[14:43] <pitti> hey kenvandine
[14:43] <seb128> hey kenvandine, bye kenvandine ;-)
[14:43] <kenvandine> pitti, i guess i'll miss you, so good night :)
[14:43] <pitti> kenvandine: o/
[14:43] <jbicha> man, trying to package boxes is frustrating, now I need a new libvirt, libvirt-glib, & tracker
[14:43] <kenvandine> jbicha, fun stuff!
[14:44]  * kenvandine heads out
[14:44] <pitti> jbicha: urgh -- tracker for boxes!?
[14:44] <pitti> jbicha: I thought boxes was a VM host, not an entire OS
[14:44] <jbicha> pitti: yeah, so you don't have to remember where you stuck your iso's?
[14:44] <jbicha> lol
[14:44] <pitti> jbicha: does it have a mail client yet?
[14:46] <seb128> does it make coffee?
[14:46] <pitti> Sweetshark, didrocks: not sure whether Trevinho already talked to you, seems the current oneiric-proposed libreoffice changes -tool to --tool in a .desktop file which breaks bamf
[14:47] <didrocks> pitti: yeah, and I asked him to check with Sweetshark ;)
[14:47] <pitti> Sweetshark, didrocks: in the interest of also supporting backports (which have -tool) and avoid another huge download, it seems to me that it's easier to backport the bamf fix than reverting this in LibO?
[14:47] <didrocks> (and you to ensure you are aware on the SRU side)
[14:47] <pitti> err, the backports have --tool, I mean
[14:48] <didrocks> hum, yeah, but that would mean that the libroffice and bamf should be released at the same time?
[14:48] <didrocks> not sure about the policy of a SRU breaking another SRU
[14:48] <pitti> didrocks: yes, they would; that's why I'm asking, it's not a normal situation
[14:48] <pitti> for a "normal" package we'd just revert that bit
[14:49] <didrocks> we can backport bamf I guess, Trevinho, thoughts?
[14:49] <pitti> and I'm not against reverting it in the LibO SRU, but according to ricotz there's a magnitude of 10.000 users running his PPA backports alone
[14:49] <Sweetshark> pitti: backports was my argument too.
[14:49] <Trevinho> didrocks: yes it's basically a copy&paste
[14:49] <pitti> so it seems to make more sense to SRU this to lucid and oneiric
[14:49] <Trevinho> to the oneiric branch
[14:49] <Trevinho> I can prepare it if you want
[14:49] <didrocks> Sweetshark: would be nice to have that checked on libroffice upload btw :)
[14:50] <pitti> didrocks: well, not strictly "at the same time"; it's rather "no later than LibO", moving it to -updates before is no problem
[14:50] <pitti> Trevinho: would it be easy to backport to lucid, too? that has the same problem
[14:50] <pitti> (with newer LibO versions, I mean)
[14:50] <Sweetshark> pitti, didrocks: bug 873702 and bug 919659 are blockers anyway
[14:50] <didrocks> pitti: well, it will break as well the matching on -tool, isn't it? if it's released before
[14:50] <ubot2`> Launchpad bug 873702 in libreoffice "some function names in Calc appear in english others in local language (mixed up) " [High,Fix committed] https://launchpad.net/bugs/873702
[14:50] <ubot2`> Launchpad bug 919659 in libreoffice "Can't open/save document or spreadsheet with password" [Unknown,Confirmed] https://launchpad.net/bugs/919659
[14:50] <Trevinho> pitti: I'm not sure what version of bamf is using lucid
[14:50] <didrocks> Sweetshark: right, I'm just telling it would be nice to have that tested when you upload a new libroffice :)
[14:51] <Sweetshark> didrocks: ah, yes. willdo.
[14:51] <didrocks> I guess we don't really care about lucid?
[14:51] <pitti> Trevinho: ah, it still had the old name back then, what was it again?
[14:51] <didrocks> unity is not installed
[14:51] <pitti> didrocks: ah, right
[14:51] <didrocks> pitti: I know, it feels like ages, isn't it? ;)
[14:51] <pitti> ricotz was telling me about his LibO 3.5 lucid PPA
[14:51] <pitti> so I guess it doesn't matter any more
[14:52] <pitti> s/any more/for lucid/
[14:52] <didrocks> yep
[14:52] <pitti> didrocks: yeah..
[14:52] <didrocks> so Trevinho, we can backport that for oneiric
[14:52] <didrocks> Trevinho: tomorrow is my sponsoring shift, nice timing!
[14:52] <didrocks> :)
[14:52] <Trevinho> :)
[14:52]  * Trevinho backporting
[14:52] <didrocks> Trevinho: just ping me or send the merge proposal my way
[14:53] <mterry> seb128, heyo.  Just FYI so we don't tromp each other's changes again, the nautilus you based your ubuntu-desktop PPA version on hasn't been accepted into the archive yet.  So when you push yours, just check for that and use -v if necessary
[14:53] <pitti> back in the days, when computers were still real computers, and men still real men, and green furry animals from Alpha Centaury were still real green furry animals
[14:53] <Sweetshark> LO 3.5.0/3.5.1 still has a few issues, but in my guess is still better/stable in general than some 3.4.3/4 already anyway ...
[14:53] <pitti> and ubuntu was brown! http://www.tuxtree.com/wp-content/uploads/2011/12/Ubuntu-desktop-2-410-20080706.png
[14:54] <seb128> mterry, hey, I noticed but thanks for the warning, I plan to stack nautilus and gnome-control-center change and not upload before thursday, no need to queue uploads during freeze
[14:54] <Daviey> pitti: is that screenshot a mockup for 12.10? :)
[14:54] <seb128> mterry, good to see you on bug fixing btw ;-)
[14:54] <Sweetshark> pitti: back in those days I had a customized gentoo desktop with -funroll-loops ...
[14:54] <pitti> Daviey: radical desktop simplification
[14:54] <mterry> seb128, heh :)  my fav thing to do
[14:54] <Daviey> pitti: seems to have a global desktop menu? :)
[14:55] <didrocks> pitti: I remember in 2007, for various reason, I had no network connexion anymore and in the research center I was, I needed to reinstall my computer and upgraded. I found a warty CD image to boot from. It was already a shock like "did I really used that at some point?" :) I can't imagine if I have to do the same experiment today
[14:55] <Sweetshark> Daviey: trollbaiting much arent you?
[14:55] <Sweetshark> ;)
[14:55] <Trevinho> pitti, Sweetshark can you take care of opening a bug and of the SRU testcases?
[14:55] <Daviey> Sweetshark: I try.
[14:55] <desrt> Trevinho: seems the bamf changes have not all landed yet?
[14:56] <desrt> two outta three ain't bad, of course
[14:56] <ricotz> Trevinho, hi, thanks for backporting it
[14:56] <desrt> but the one left is the serious one :)
[14:57] <Trevinho> ricotz: yw
[14:57] <Trevinho> desrt: did you propose a merge for your fixes?
[14:57] <seb128> desrt, you will need to talk to didrocks I guess ;-) he frozen the unity trunks earlier
[14:57] <Trevinho> I saw only the patch
[14:57] <desrt> Trevinho: i opened a bug and did a patch
[14:57] <desrt> i was expecting someone with launchpad-fu to do all the other stuff
[14:57] <Trevinho> desrt: can you please do the MR as well, it would be faster to get included
[14:57] <didrocks> it's a cold day :)
[14:58] <seb128> desrt, you refuse to use lp on principle right? ;-)
[14:58] <desrt> seb128: i've used it soem times before
[14:58] <ricotz> pitti, 3.5 is actually in the official libreoffice ppa now for lucid and oneiric
[14:58] <seb128> desrt, how hard can it be, bzr commit, bzr push, bzr lp-submit
[14:58] <desrt> but it seems that every time i do, something is screwed up
[14:58] <ricotz> pitti, just building it in my ppa
[14:58] <desrt> like i pushed a branch before... a *branch*
[14:58] <desrt> then did a merge proposal
[14:58] <seb128> desrt, I admit, commit and push are hard to use commands new in vcs worlds :p
[14:58] <desrt> and somehow the result was a conflicted diff
[14:59] <desrt> i'm not really sure how a branch, that i push as a whole entity, can be conflicted
[14:59] <seb128> desrt, well maybe the vcs you branched off changed while you were doing your change
[14:59] <mterry> desrt, trunk probably changed since you made your branch?
[14:59] <desrt> actually... ted did the merge proposal, i think
[14:59] <desrt> maybe?
[14:59] <desrt> either way, my MR got rejected
[14:59] <desrt> so i'm bitter :p
[14:59] <seb128> desrt, honestly it's trivial, bzr branch lp:something, hack, bzr commit, bzr push lp:~desrt/something/fix; bzr lp-submit
[15:00] <mterry> famously thin-skinned desrt
[15:00] <desrt> seb128: i'll try again :D
[15:00] <seb128> ;-)
[15:00] <desrt> bzr: ERROR: Conflicts detected in working tree.  Use "bzr conflicts" to list, "bzr resolve FILE" to resolve.
[15:00] <seb128> desrt, let me know if that doesn't work for some reason
[15:00] <desrt> argghghg
[15:01] <desrt> Text conflict in lib/libbamf/bamf-window.c
[15:01] <seb128> mterry, btw I will put a bunch of extra stuff on the milestones bugs list so you and others don't get short of bugs to pick on ;-)
[15:01] <desrt> lulz.  no changes in this file at all.
[15:01]  * desrt resolves it, i guess?
[15:01] <seb128> desrt, bzr diff it or lock for >>>
[15:01] <seb128> desrt, don't, you will have conflict markers in there
[15:01] <desrt> seb128: ya.  there's absolutely nothing there at al.
[15:02] <seb128> desrt, if you are sure you have no change just bzr revert lib/libbamf/bamf-window.c && bzr resolve lib/libbamf/bamf-window.c
[15:02] <seb128> desrt, you can cp the file before
[15:02] <seb128> just to diff it later and see what was the diff ;-)
[15:02] <desrt> there is no change at all
[15:02] <desrt> not sure what happened
[15:02] <seb128> weird
[15:02] <seb128> well bzr revert && bzr resolve
[15:02] <seb128> the revert to be sure
[15:03] <seb128> well, revert just the file
[15:03] <desrt> erm
[15:03] <seb128> not the whole tree
[15:03] <desrt> did that just blow away all my changes?
[15:03] <desrt> arghghgh
[15:03] <seb128> desrt, you have .~1~ with the version before revert
[15:03] <desrt> it was a small change. i'll just make it again
[15:04]  * desrt decides to stop typing 'bzr' things he doesn't fully understand
[15:04] <seb128> desrt, you should have your file.~1~ which was the pre revert
[15:04] <desrt> oh.  handy.
[15:04] <desrt> i understand that :)
[15:04] <seb128> I'm sure there is a command to restore those, or undo the revert, I don't know it though
[15:05] <seb128> desrt, bzr revert is basically "undo any local change" you can use it on the tree or on a file
[15:05] <seb128> desrt, i.e bzr revert lib/libbamf/bamf-window.c && bzr resolve lib/libbamf/bamf-window.c
[15:05] <desrt> sounds like git reset --hard
[15:05] <seb128> desrt, is "go back to the vcs version and declare the conflict resolved"
[15:05] <desrt> btw: is there some preferred notation for bug numbers?
[15:05]  * desrt has seen (lp: #234234) in places
[15:05] <didrocks> --fixes lp:234234
[15:05] <didrocks> when you commit
[15:05] <desrt> thanks
[15:06] <didrocks> it links your branch to the bug :)
[15:07] <seb128> desrt, in changelogs what matters is "lp: #nnn"
[15:07] <seb128> desrt, you can put in between parenthesis or not doesn't matter
[15:07] <desrt> The Ubuntu computer called moonpix now has access to your Launchpad account
[15:07] <desrt> scary :)
[15:07] <Trevinho> I do prefer to do that via web interface btw
[15:07] <seb128> desrt, but yeah, for commit what didrocks said
[15:07] <seb128> Trevinho, the lp-submit?
[15:07] <desrt> https://code.launchpad.net/~desrt/bamf/refcount-fix/+merge/94978
[15:07] <desrt> is this good?
[15:08] <Trevinho> seb128: no, the fixes ...
[15:08] <seb128> desrt, will tell you in a sec, lp is computing the diff...
[15:08] <Trevinho> desrt: I'll look
[15:08] <seb128> desrt, but the url, target branch, etc seems good
[15:08] <Trevinho> desrt: yes, it's fine
[15:09]  * Trevinho looks at the revisions
[15:09] <seb128> desrt, did you put --fixes in the commit message?
[15:09] <desrt> yup
[15:09] <seb128> desrt, it's bzr commit --fixes lp:...
[15:09] <desrt> oh.
[15:09] <desrt> hahahah
[15:09] <seb128> desrt, but it's a detail
[15:09]  * didrocks thinks that now desrt need to load the "achievement soft" to get a trophee :)
[15:09] <Trevinho> didrocks: I've backported that bamf LO fix at http://bazaar.launchpad.net/~unity-team/bamf/oneiric/revision/428
[15:10]  * desrt is used to writing bug annotations directly into the commit
[15:10] <didrocks> Trevinho: excellent, will sponsor with the rest in my shift tomorrow :)
[15:10] <seb128> Trevinho, desrt: ok, diff generated on https://code.launchpad.net/~desrt/bamf/refcount-fix/+merge/94978
[15:10] <Trevinho> nice didrocks , do I need to do something else
[15:11] <didrocks> Trevinho: is there a bug with the incoming issue to track it?
[15:11] <didrocks> will be nice to have it with a test case
[15:11] <Trevinho> desrt: branch approved... ;)
[15:11] <desrt> nice!
[15:11] <desrt> so... autolanding or something will happen now?
[15:11] <Trevinho> didrocks: well... can we get the LO guys to do that :P
[15:12] <didrocks> Sweetshark: please ^
[15:12] <Trevinho> ?
[15:12] <desrt> is didrocks going to yell at me because i didn't write a test?
[15:12] <didrocks> yeah, he breaks, he fixes :p
[15:12] <didrocks> desrt: someone need to ensure it get tests or that it's covered by existing tests
[15:12] <didrocks> desrt: need to approve it
[15:12] <didrocks> desrt: if it's approved, it's normally build, tested, merged automagically
[15:13] <desrt> didrocks: i have a test here: my hud rewrite crashes without the patch :)
[15:13] <didrocks> desrt: but we are in a freeze period :)
[15:13] <Trevinho> desrt: well... the tests in bamf are something bad right now...
[15:13] <didrocks> desrt: is the older "hud" working with it?
[15:13] <desrt> yes
[15:13] <didrocks> desrt: ok, but the new "hud" rewrite won't land in 5.6
[15:13] <desrt> although i suspect valgrind would still have some bad things to say there
[15:13] <didrocks> so it can wait for the freeze to end :)
[15:13] <Trevinho> desrt: see if you can include your testcase in http://bazaar.launchpad.net/~unity-team/bamf/trunk/view/head:/tests/libbamf/test-matcher.c
[15:14] <didrocks> (and there are some huds tests)
[15:14] <didrocks> desrt: can you please comment on the merge req with what you just told? that otherwise, the HUD crashes
[15:14] <didrocks> and so running the HUD tests is enough
[15:14] <desrt> didrocks: i actually have a self-contained testcase in the bug that's probably more suitable
[15:14] <seb128> didrocks, desrt: only issue if the fix doesn't land this week we will need to maintain a bamf ppa build with the patch to be able to test desrt's code
[15:14] <desrt> but it needs to be run manually
[15:15] <dpm> tedg, thanks for your reply on ubuntu-app-devel - quick question, though, should it not be 'from gi.repository import AppIndicator3', instead of AppIndicator?
[15:15] <didrocks> desrt: that would be great
[15:15]  * desrt comments on the MR about the testcase in the bug
[15:16] <didrocks> seb128: it would be in the unity-team/staging
[15:16] <seb128> didrocks, ok
[15:16] <didrocks> seb128: so no need to maintain a ppa
[15:16] <desrt> basically, you just do this:
[15:16] <desrt> 1) open some random window
[15:16] <desrt> 2) run the testcase
[15:16] <desrt> 3) close the window from #1
[15:16] <desrt> 4) observe criticals
[15:16] <seb128> didrocks, still, it couple the new hud-service to staging, but I guess we can deal with that
[15:16] <desrt> 5) patch bamf, repeat, observe no criticals
[15:16] <didrocks> seb128: right, I think with the other changes in lim, it's not a biggie :)
[15:17] <seb128> didrocks, is gmenu support linked to lim?
[15:17] <didrocks> desrt: please, post, it would be merged once approved after the freeze period
[15:17] <seb128> didrocks, what desrt work on is gmenus support
[15:17] <desrt> didrocks: i did post
[15:17] <didrocks> seb128: no, I meant that we already have other dependant ppa between them
[15:17] <seb128> ok
[15:18] <desrt> seb128: is didrocks going to panic when he finds out what "adding gmenu support" means? ;)
[15:18] <didrocks> desrt: sweet, now, the magic will hopefully happen on Thursday after beta1 freeze :)
[15:18] <didrocks> desrt: I already knew it! :)
[15:18] <desrt> oh.  good.  no surprises, then :)
[15:18] <didrocks> so already had some nightmares if that was the question :p
[15:18]  * desrt is currently writing gtk-doc to make the bitter pill a bit easier to swallow
[15:20] <tedg> dpm, Uhm, I'm not sure.  I'd think you're probably right though.
[15:20] <tedg> dpm, I've not played with all the GIR stuff to see what it assumes there.
[15:21] <nessita> didrocks: so, I got lost regarding the workspace switching shortcuts... shall I expect an update that will fix it, or shall I just edit them by hand?
[15:22] <dpm> tedg, yeah, it seems AppIndicator does not work, but AppIndicator3 does, just tested it on a small script
[15:22] <dpm> I just wanted to make sure, thanks!
[15:22] <didrocks> nessita: not before thursday
[15:23] <didrocks> nessita: so change back them yourself in gnome-control-center until then
[15:24] <nessita> didrocks: thanks!
[15:24] <pitti> good night everyone! need to run a bit earlier today
[15:24] <desrt> to anyone who is interested: i just pushed my WIP
[15:24] <nessita> bye pitti
[15:24] <desrt> https://code.launchpad.net/~desrt/indicator-appmenu/hud-rewrite-wip
[15:24] <desrt> pitti: g'night
[15:24] <didrocks> nessita: yw! ;)
[15:25] <didrocks> have a good night pitti
[15:27] <Sweetshark> ricotz: do you build 3.5.0 on lucid with -kde?
[15:28] <didrocks> Trevinho: please UNBLOCK desrt's branch if you are happy about it (but edit the comment so that it makes sense and ensure the attached bug is set to fix committed, has an unity task, targetted to 5.6…)
[15:29] <tedg> desrt, You didn't seriously do the whole thing in one revision?
[15:29] <desrt> tedg: i can split it up better later
[15:29] <seb128> 'night pitti
[15:29] <desrt> tedg: but it's a pretty substantial rewrite....
[15:29] <tedg> desrt, Yes, which is why I'd expect you to have used more than one revision :-)
[15:29] <desrt> so my abilit to split it up is pretty limited
[15:30] <tedg> I forgot, you're a git user, you like to write the history after doing the work :-)
[15:30] <desrt> tedg: you know dave parnas?
[15:30] <desrt> he wrote this great paper....
[15:31] <desrt> http://web.cs.wpi.edu/~gpollice/cs3733-b05/Readings/FAKE-IT.pdf
[15:31] <desrt> one of the pioneers of software engineering.  who am i to argue?
[15:33] <tedg> desrt, "even faking it is quite difficult" -- I like to just keep a semi-rational process along the way and avoid making thing up in the end :-)
[15:33] <tedg> But, it's true, git doesn't really allow for that as you screw up the trunk's history.
[15:34]  * desrt had never considered using parnas's "how and why to fake it" as a justification for git-rebase until now, but it actually fits very well
[15:35] <desrt> tedg: anyway... it's sort of interesting because there are competing ideals here
[15:35] <desrt> on one hand is the ideal of "small commits"
[15:35] <desrt> on the other hand is the ideal of "don't break the tree"
[15:35] <desrt> and right now, my code is in a state of introducing some rather serious regressions to the hud as it worked before
[15:36] <tedg> desrt, You don't break the tree using small commits.  You only break a branch of the tree.  I haven't found anyone that can give a reason to use bisect on anything other than trunk.
[15:36] <desrt> tedg: either way, you end up with the same result: something used to work and now it doesn't and the one commit between now and then is this monster branch-land
[15:37] <tedg> desrt, Yes, and no.  If you only look at trunk, that's the perspective.  But when I look in annotate for instance I see the commit message you made when changing that line.
[15:37] <desrt> true...
[15:38] <desrt> in any case, i really enjoy subscribing to the "i'm a superhero who gets it right the first time" school of thought :)
[15:38] <tedg> I'd argue that the biggest advantage of small commits is that frequently I wake up and realize I need to back out what I did before falling asleep :-)
[15:38]  * seb128 hugs mterry
[15:39] <seb128> mterry, thanks for looking at this g_object_get() nautilus segfault, it's collecting quite some dups
[15:39] <tedg> I view it more as "check points" rather than "commits" :-)
[15:39] <ricotz> Sweetshark, yes
[15:39] <desrt> anyway... a couple of things to note, in case it's not obvious
[15:39] <desrt> my changes are strictly limited to the hud-service
[15:39] <desrt> no external interfaces were harmed
[15:39] <tedg> Heh, that's a T-shirt ;-)
[15:40] <desrt> i think the dbus protocol could use some tweaks, but strictly speaking, it's fine as-is
[15:40] <desrt> and i've kept to it
[15:40] <tedg> Good, I'm sure that seb128 would love Unity changes :-)
[15:40] <desrt> in fact.. i think gmenumodel + gactiongroup would make a great replacement for the bus protocol :)
[15:40] <desrt> but that's for another day...
[15:41] <desrt> (there's only so many ways to carry an array of dictionary entries to the other side of the bus... we may as well use one we already have)
[15:41] <dobey> the code i write is always perfect; gcc often turns it into invalid instructions though.
[15:42]  * desrt would not describe his encounters with gcc bugs with the word 'often'
[15:42] <tedg> desrt, Eh, but then you loose specification for generic transport.  I don't think that being generic there provides too much value.  But, yes, a debate for another time.
[15:43] <desrt> tedg: ya.. certainly off the table for now
[15:43] <Sweetshark> ricotz: congratulations, bug 696299 is yours (and fixed).
[15:43] <ubot2`> Launchpad bug 696299 in libreoffice "LibreOffice ftbfs with KDE on lucid" [Undecided,Fix released] https://launchpad.net/bugs/696299
[15:43] <didrocks> desrt: you won't get it in the new and great unity 5.6 release if Trevinho doesn't unblock your branch with the instructions above for the notice :p
[15:44] <didrocks> Sweetshark: speaking about bugs, did you see my request before? :)
[15:44] <desrt> didrocks: the bamf changes or hud changes?
[15:44] <ricotz> Sweetshark, oh, this already worked for my 3.3.3 backport
[15:44] <didrocks> desrt: bamf ;)
[15:44] <desrt> didrocks: how about the hud changes?  can i push those now?
[15:44] <mterry> seb128, :)
[15:44] <desrt> they're really minor...
[15:44] <didrocks> desrt: in unity itself?
[15:44] <didrocks> or in the backend? :)
[15:44] <desrt> backend only, fortunately :)
[15:45] <didrocks> desrt: sorry, you can bother me then! :-) get into troubles with seb128 ;)
[15:45] <desrt> ah
[15:45] <desrt> you're only concerned with unity and things-with-which-unity-links?
[15:46] <didrocks> desrt: not "links", but direct project to unity yeah, still more than 20 sources though :)
[15:46] <didrocks> so it's already way enough ;)
[15:46] <Trevinho> didrocks: I'll do it soon
[15:47] <Trevinho> I was fixing something :)
[15:47] <didrocks> Trevinho: I mean, if it's not merge in 20 minutes, I can't copy it to the other ppa and it's delaying the call for testing to the community :)
[15:47] <desrt> didrocks: how about panel service stuff?
[15:47] <didrocks> desrt: ah, you start to freak me out now! :)
[15:47] <desrt> good.  that's what i'm aiming for :)
[15:48] <didrocks> heh, seeing that ;)
[15:48] <Trevinho> didrocks: I'll unblock it in few seconds
[15:48] <Trevinho> didrocks: also we'd need a milestone for 5.8.0 ;)
[15:48] <Trevinho> ah, it'st here now
[15:48] <Trevinho> sorry
[15:48] <didrocks> Trevinho: I'm way faster than you! \o/
[15:48] <desrt> so does this mean we're getting the bamf changes in during the freeze?
[15:49] <didrocks> Trevinho: yeah, see my comments above, milestoning it to 5.6, adding unity task if not there, fix committed, sensible description :p
[15:49]  * desrt is lost in all of the process
[15:49] <Sweetshark> didrocks: I never see requests. This quite an convenient thing actually.
[15:49] <didrocks> desrt: it's not ubuntu freeze, it's unity one :)
[15:49] <Sweetshark> didrocks: what request?
[15:49] <didrocks> Sweetshark: heh! please backlog for the last ping ;)
[15:49] <didrocks> Sweetshark: so, as you are breaking us, you won the right to:
[15:49] <didrocks> 1. open a bug stating that bamf is broken
[15:49] <didrocks> 2. test case
[15:49] <didrocks> 3. add the SRU team :)
[15:50] <Trevinho> didrocks: yes, you are... Even if I just didn't ask that before when it come up on my mind not to load you too much of stuff :)
[15:50] <Sweetshark> didrocks: meh.
[15:50] <didrocks> Trevinho: shhhhhh, don't tell me that :-) /me will start opening milestones until 2050 now :)
[15:51] <Sweetshark> didrocks: Breaking other peoples software was more fun in the old days.
[15:51] <didrocks> Sweetshark: oh, with a smile please! ;)
[15:51] <didrocks> heh, indeed!
[15:51] <didrocks> desrt: so, FYI, the merge description is used as the commit message
[15:51] <didrocks> desrt: by the bot
[15:51] <didrocks> which, in this particular case will end up with:
[15:51] <Trevinho> desrt: didrocks desc updated: https://code.launchpad.net/~desrt/bamf/refcount-fix/+merge/94978
[15:51] <didrocks> "plz merge this?"
[15:52] <didrocks> thanks Trevinho ;)
[15:52] <desrt> didrocks: excellent :)
[15:52] <didrocks> desrt: Trevinho put a boring message now, no fun! :-)
[15:52] <desrt> Trevinho: good description
[15:52] <desrt> less fun, but quite accurate.
[15:52] <desrt> would buy again
[15:52] <Trevinho> desrt: please take care of setting the bug as fix commited once you receive the notification of merge from the glorious unity-merger
[15:53] <didrocks> Trevinho: everything looks excellent, thanks!
[15:53] <dobey> Trevinho: it doesn't automatically mark bugs as fix-committed?
[15:54] <didrocks> dobey: seems there is a bug, not everytime, quite weird, couldn't reproduce exactly
[15:55] <dobey> didrocks: it will only mark the bug fixed if it affects the correct project/series for the target branch, and if the bug is linked by bzr commit --fixes=lp:foo; manually linked bugs on launchpad get ignored
[15:56] <didrocks> dobey: I know, but even in some cases like that, it happens it didn't
[15:56] <didrocks> it's like on pre-requisite branch, we had the issue as well (and they had in unity-2d when they only used upstream tarmac)
[15:56]  * didrocks needs to find time to really debug it
[15:57] <didrocks> didn't happen enough to investigate it without delaying the other tasks
[15:57] <dobey> didrocks: hrmm. if you can log a few branches that it fails for sometime, and give me the list, maybe i can find some time to take a quick look at it
[15:58] <didrocks> dobey: will do then! :)
[15:58] <didrocks> btw, it will be good at UDS to restart the discussion about the tweaks that we need for our use case
[15:58] <didrocks> but not now, too busy :)
[16:01] <BigWhale> Hmm, why is lock screen again all ugly? :'(
[16:01] <seb128> BigWhale, was it different before?
[16:01] <Trevinho> desrt: merged and marked as fix committed (manually, btw)
[16:02] <BigWhale> seb128, I vaguely remember it being the same as greeter screen
[16:02] <BigWhale> am I mistaken? :)
[16:02] <seb128> BigWhale, we tried that for a few days, using the greeter as lock screen, it has issues
[16:02] <BigWhale> oh
[16:03] <BigWhale> I knew it! :)
[16:03] <tkamppeter> pitti, I have tested the postinst scripts calls of CUPS now (for bug 932882), by adding "touch /tmp/X; echo $* >> /tmp/X" to the beginning of the postinst. After "sudo dpkg -i <cups package> <printer-driver-gutenprint package>", /tmp/X contains "configure 1.5.2-5" twice and no "triggered" line. So the trigger is never executed.
[16:03] <ubot2`> Launchpad bug 932882 in gutenprint "Update of a printer driver package does not update the PPD files of the existing queues for this driver" [High,Confirmed] https://launchpad.net/bugs/932882
[16:03] <seb128> tkamppeter, he left for today
[16:04] <tkamppeter> seb128, thanks, so I mail it to him so that he gets it in his morning mail.
[16:04] <didrocks> desrt: https://code.launchpad.net/~unity-team/bamf/trunk for your information :)
[16:04] <didrocks> thanks Trevinho for approving
[16:08] <Trevinho> yw
[16:09] <seb128> cyphermox, hey
[16:42] <mterry> No meeting/agenda, eh?
[16:44] <seb128> ups
[16:44] <seb128> pitti is out, I was supposed to ask around and lead the meeting if there is any topic
[16:44] <didrocks> seems the topic is empty :)
[16:45] <seb128> didrocks, kenvandine, mterry, tkamppeter, cyphermox, Sweetshark, agateau, Riddell, others: hey, meeting time (slightly after meeting time) if somebody has a topic
[16:45] <Riddell> seb128: a topic but I think it's for jason, can I expense the bits I need to get this pandaboard working?
[16:46] <Riddell> HDMI monitor is the most princey one
[16:46] <seb128> jasoncwarner_, ^
[16:46] <seb128> Riddell, yeah, question for jason ;-)
[16:46] <mterry> Best way to help beta?  Test ISOs?
[16:46] <desrt> seb128: jason is very sick (and on vacation)
[16:46] <mterry> Or is beta past the point of being helpful?
[16:46] <Riddell> mterry: test ISOs yes
[16:47] <Riddell> test upgrades too, from oneiric and lucid
[16:47] <seb128> desrt, well hoppefully he will better and back one day and read scrollback
[16:47] <Riddell> seb128: I think I'll just e-mail him :)
[16:48] <seb128> mterry, I'm sure some people would appreciate testing, my personal opinion is that we have enough testers and your time is more valuable fixing bugs but that's my personal opinion
[16:48] <seb128> mterry, maybe fire some vm installs while hacking ;-)
[16:49] <mterry> can do
[16:49]  * seb128 checks http://status.qa.ubuntu.com/reports/ubuntu-desktop/precise.html
[16:49] <seb128> it's a bit short on bugs, I will put a few extra ones there
[16:50] <seb128> well it's not "short" but it could use some extra diversity ;-)
[16:50] <Riddell> "Ubuntu Desktop i386 2/6" plenty of room for more testers!
[16:50] <Riddell> and no mercy, I won't be releasing the images unless they are tested :)
[16:50] <seb128> mterry, btw about your nautilus bug comment, feel free to just stack patches in the vcs
[16:51] <seb128> mterry, we will do an upload after the freeze ends with everything there
[16:51] <seb128> mterry, if you want testing on some changes also just upload to the team ppa as well
[16:51]  * kenvandine is fixing gwibber account migration from lucid to precise
[16:51] <seb128> mterry, btw bug #929064 I wonder if that's the same issue than the one you debugged earlier
[16:51] <ubot2`> Launchpad bug 929064 in nautilus "nautilus crashed with SIGSEGV in set_floating_bar_status()" [High,Triaged] https://launchpad.net/bugs/929064
[16:55] <mterry> seb128, yeah I looked at both, but I think it might be different.  Same overall code path, but I think different cause
[16:56] <seb128> mterry, ok
[17:15] <cyphermox> seb128: sry, debugging this weird 10hz poll bug
[17:15] <seb128> cyphermox, hey
[17:15] <seb128> cyphermox, no worry
[17:15] <cyphermox> seb128: how are you
[17:15] <seb128> cyphermox, I'm good thanks, how are you?
[17:16] <seb128> cyphermox, did you ever get anywhere with the webkit ld optimizations tests?
[17:18] <cyphermox> seb128: ah, not much farther
[17:18] <cyphermox> it does seem to help
[17:18] <cyphermox> seb128: maybe ask if micahg got anywhere too
[17:18] <seb128> cyphermox, what did you change?
[17:18] <cyphermox> he was trying the same ld options as well
[17:18] <seb128> cyphermox, was there in the packaging?
[17:18] <seb128> micahg, ^
[17:18] <cyphermox> yeah, it's just in packaging
[17:19] <seb128> cyphermox, can you give me the magic? ;-)
[17:19] <cyphermox> something like CFLAGS += -Wl,--no-keep-memory
[17:19] <seb128> cyphermox, I plan to throw .90 to the ubuntu-desktop ppa
[17:19] <cyphermox> let me double check :)
[17:19] <seb128> cyphermox, thanks
[17:20] <cyphermox> seb128: here's how I was doing the testing: http://paste.ubuntu.com/860779/
[17:21] <cyphermox> if you give me ~30 min I can hook up a good rig for more of this testing, on real 32 bit, rather than running sbuild on my laptop with a ulimit :)
[17:22] <seb128> cyphermox, don't bother, keep debugging what you were on
[17:22] <seb128> cyphermox, I do plan to throw it at the ppa anyway, let's see how it goes
[17:22] <cyphermox> sure
[17:23] <seb128> cyphermox, thanks
[17:23] <cyphermox> I can do this in parallel though, I was going to install a virtual machine on another box
[17:23] <seb128> cyphermox, well if you want to play with it feel free
[17:23] <seb128> just don't feel like you have to do it ;-)
[17:23] <cyphermox> building webkit tends to be a little cpu intensive ;)
[17:23] <seb128> just to a tide
[17:23] <seb128> ;-)
[17:23] <cyphermox> I like the linking part, where my mouse starts going slowly
[17:36] <seb128> is there an equivalent of "bzr uncommit" to git? ;-)
[17:38] <bryceh> seb128, yes
[17:39] <seb128> bryceh, hey, which one? ;-)
[17:39] <bryceh> git revert and then git reset if you want to chuck the commits
[17:40] <bryceh> so usually something like, 'git revert HEAD; git reset --hard HEAD'
[17:41] <seb128> thanks
[17:45] <seb128> bryceh, that doesn't do it
[17:46] <seb128> hate git hate
[17:46] <seb128> I've not a "revert" commit added on top of the one I wanted to revert
[17:46] <seb128> I guess I will just rm -r and checkout again
[17:48] <seb128> I knew I should have cp-ed the directory after checkout :p
[17:50] <ricotz> seb128, git checkout .
[17:50] <ricotz> will reset your changes
[17:50] <seb128> ricotz, what does that do?
[17:50] <seb128> I already commited my change locally
[17:51] <seb128> I want to undo it
[17:51] <ricotz> you can use git reset HEAD^
[17:51] <seb128> I don't want to switch branches...
[17:51] <ricotz> this doesnt switch branches
[17:51] <seb128> why is git so hard ;-)
[17:51] <seb128> can't they just have a "uncommit"? ;-)
[17:52] <ricotz> ;)
[17:52] <seb128> ricotz, thanks, I've deleted the dir and I'm redoing a new checkout (started before you replied)
[17:52] <seb128> hate git hate
[17:52] <ricotz> hehe
[17:52] <seb128> but next time I will try that
[17:52] <ricotz> i like it more than bzr ;)
[17:53] <bryceh> seb128, git doesn't have an uncommit because that would be too easy, which is un-gitlike
[17:53] <seb128> well you probably spent enough effort learning it that you feel like it would we wasted time if you didn't like it now :p
[17:54] <bryceh> seb128, but yeah git checkout -f . ; git reset --hard HEAD would do what you want.  See I've been using it years and I still get it wrong.
[17:55] <ricotz> bryceh, he already committed ;) so HEAD^ will go back one commit
[17:56] <seb128> it's over me how people can like git ;-)
[17:56] <seb128> should be easy, the opposite of commit is uncommit :p
[17:56] <seb128> not checkout and reset and then add some --hard or no wait a ^ is missing ;-)
[17:57] <bryceh> seb128, yeah it's definitely a learning curve thing; I spent years hating it passionately because it always screwed my stuff up.   I'm still not good at it, but I know enough to do more than I can do in bzr, so can't say I hate it anymore.  I'm not quite to 'like', but am not far off.
[17:58] <seb128> is that like "I like writing my debian rules with an hundred lines of makefile rather than using dh because I learnt the difficult way and I want to show off I can do it" sort of things? ;-)
[17:59] <bryceh> of course, after all this _is_ linux we're talking about
[17:59] <bryceh> seb128, your git will work better after you've rebuilt your kernel
[18:00]  * didrocks waves good evening :)
[18:00] <seb128> didrocks, 'night
[18:00] <didrocks> seb128: merci, à demain! :)
[18:00] <seb128> waouh, got it
[18:01] <seb128> 5 minutes writing the patch and opening a bug, 15 minutes dealing with git to just edit my commit message
[18:01] <seb128> thanks guys ;-)
[18:01] <jbicha> and the opposite of git add is git subtract?
[18:02] <bryceh> jbicha, hehe
[18:05] <ricotz> git remove ;)
[18:08] <chrisccoulson> mvo, is there anything i can do about bug 942778? (ie, is there a way to detect that i need to update the package cache?)
[18:08] <ubot2`> Launchpad bug 942778 in ubufox "Gnash plugin is not installable from precise livecd" [Low,Triaged] https://launchpad.net/bugs/942778
[18:11] <seb128> cyphermox, your patch seems weird btw
[18:11] <cyphermox> my patch seems weird?
[18:11] <seb128> cyphermox, shouldn't you add the --no-keep-memory to LDFLAGS rather than CFLAGS?
[18:12] <cyphermox> IIRC it didn't work
[18:12] <cyphermox> --no-keep-memory alone to LDFLAGS probably should have been fine yeah
[18:12] <seb128> cyphermox, it didn't work or would be fine?
[18:13] <cyphermox> seb128: IIRC it didn't work when I tried it; I think gcc would complain and die
[18:13] <cyphermox> seb128: but I also expected that was the right way to do it
[18:13] <seb128> hum
[18:13] <cyphermox> maybe I hallucinated things
[18:13] <seb128> cyphermox, LDFLAGS +="-Wl,--as-needed"
[18:13] <seb128> I wanted to try that
[18:13] <cyphermox> well, maybe that ;)
[18:13] <seb128> I will try that
[18:13] <seb128> it sounds about right to me :p
[18:14] <cyphermox> yeah, to me too
[18:14] <cyphermox> seb128: btw, reading back on a ping I missed; so the g-c-c checkbox shouldn't have been removed ? :D
[18:14] <seb128> cyphermox, designers fights, I'm out of it
[18:14] <cyphermox> heheh
[18:33] <desrt> 100% symbol docs coverage.
[18:33] <desrt> woot
[18:34] <seb128> desrt, congrats
[18:35] <desrt> tedg: you should be able to build complete gtk-doc for the hud service off my branch now
[18:35] <seb128> desrt, you missed my git ranting but at least you got work done  ;-)
[18:35] <desrt> if you want to get an overview of what i'm up to
[18:35] <mterry> cjwatson, is ubiquity's keyboard layout widgets being insensitive a known bug?
[18:36] <desrt> seb128: felt the need to balance off my bzr-ranting? :)
[18:36] <seb128> desrt, no, just wasted 15 minutes to try to "uncommit" to rm and checkout again
[18:37] <seb128> git makes me want to kick in stuff around me ;-)
[18:39] <dobey> git the-hell-outta-my-way
[18:39] <dobey> :)
[18:40] <dobey> git always makes me feel like i'm a scot, trying to use voice recognition
[18:41] <desrt> funny.  that's how bzr makes everyone-who-doesn't-work-for-canonical feel :)
[18:41] <dobey> i doubt that
[18:41] <BigWhale> I hope someone soon does something about fglrx drivers and constant crashing if using Xvideo
[18:41] <BigWhale> :/
[18:42] <seb128> BigWhale, like "use ati"? ;-)
[18:42] <desrt> dobey: i was trying to figure out how the heck to use it yesterday and i found quite a lot of people doing hg/git/bzr comparisons
[18:42] <desrt> just googling around
[18:42] <dobey> desrt: yeah, i'm sure people who are used to the insanity of hg/git probably have issues with bzr
[18:42] <seb128> desrt, well at least simple things are simple in bzr, commit, push, uncommit, revert
[18:42] <desrt> the conclusion i found is that people are not generally happy with the fact that bzr exists
[18:43] <BigWhale> seb128, radeon drivers are slow :/
[18:43] <desrt> dobey: that's just the point, though
[18:43] <dobey> yes, well; people are not generally happy
[18:43] <BigWhale> and last time I checked, the support for multiple screens was poor
[18:43] <desrt> bzr and git/hg are complicated and similar systems with different ways of communicating with them
[18:43] <desrt> the entire world is familiar with git (or hg to a somewhat lesser extent)
[18:43] <dobey> desrt: no. the point was that people used to cvs/svn/etc wouldn't have to do some insane crack to use a dvcs
[18:43] <desrt> bzr is a distance third also-ran
[18:43] <desrt> *distant third
[18:44] <desrt> dobey: this reminds me of linus's comments on svn :)
[18:44] <dobey> "the whole world" is also a very generalized opinion, of a very small subset of the whole actual world
[18:44] <seb128> desrt, not true, git (dunno about hg) is complicated, bzr is much simpler (at least for easy stuff)
[18:44] <dobey> desrt: yes, well, it's linus.
[18:44] <desrt> dobey: fine.  developers (open source and otherwise), generally use git
[18:45] <desrt> seb128: that myth is simply a myth
[18:45] <seb128> desrt, well, I'm too stupid to use git if you prefer
[18:45] <seb128> which is fine
[18:45] <desrt> and it's one that i found getting called out rather regularly as i was searching about yesterday
[18:45] <dobey> desrt: more people probably still use svn.
[18:45] <desrt> seb128: and i'm too stupid to use bzr, apparently
[18:45] <desrt> but that's just my point
[18:45] <dobey> git people are just loud about anyone who doesn't use git
[18:45] <seb128> desrt, that's not true
[18:45] <desrt> i'm also too stupid to speak french
[18:45] <desrt> that doesn't mean that french is insanely complicated
[18:46] <desrt> well... bad example
[18:46] <seb128> desrt, no, you miss the point
[18:46] <desrt> but you know what i mean
[18:46] <bryceh> BigWhale, only AMD can fix the Xv issue in fglrx.  When you choose to use proprietary software, dem's the breaks.  But I'd think we should get a fixed driver any day now.
[18:46] <seb128> desrt, bzr basic command are bzr <command>, where command is a logical word, commit, push, uncommit, revert
[18:46] <desrt> dobey: we don't have to be loud.  everyone is using git.
[18:46] <dobey> no everyone is not
[18:46] <desrt> seb128: git commit, push, reset, revert
[18:47] <desrt> dobey: right.  there are hg users and canonical employees :)
[18:47] <seb128> desrt, git is weird, like git commit doesn't commit anything, git uncommit doesn't exist, git revert doesn't do what I want
[18:47] <seb128> desrt, I needed to use --hard and some ^ after HEAD
[18:47] <seb128> like stuff I don't even get
[18:47] <desrt> git reset resets the current state of the branch to the specified commit
[18:47] <seb128> why do I need to specify HEAD at all to revert a commit
[18:47] <desrt> you give a commit ID there
[18:47] <dobey> desrt: no; there are git people who are loud and annoying; and then there's everyone else who just doesn't really give a damn so much, and use what they feel is the best tool for the job, or what they have to use
[18:48] <desrt> HEAD^ is just shortest way to say "the commit that came one commit before HEAD"
[18:48] <desrt> where HEAD is the shortest way to say "where i am now"
[18:48] <seb128> desrt, why do I need to specify HEAD and a commit
[18:48] <seb128> I just want to "pop"
[18:48] <seb128> that should be no argument
[18:48] <seb128> that's my point, git is making it hard
[18:48] <seb128> same for commit
[18:48] <desrt> seb128: pop is a complicated question
[18:48] <seb128> git commit should just commit what I've as a diff
[18:48] <desrt> do you want to keep your changes?  have them blown away
[18:48] <desrt> ?
[18:49] <desrt> seb128: ah.  i really have to disagree with that
[18:49] <seb128> bzr uncommit put you back where you were before "commit"
[18:49] <desrt> i really really miss 'add -p' in bzr...
[18:49] <seb128> it's just like "undo" in a file manager
[18:49] <desrt> seb128: people who use git generally don't uncommit things
[18:49] <seb128> undo should be easy
[18:49] <desrt> rather there's a more powerful tool 'git commit --amend'
[18:49] <desrt> that's how you fixup
[18:49] <seb128> desrt, I wanted to edit my commit message before pushing
[18:49] <desrt> right
[18:49] <desrt> so 'git commit --amend'
[18:49] <desrt> edit, save
[18:49] <desrt> push
[18:50] <seb128> what commit does that edit?
[18:50] <desrt> the last one
[18:50] <seb128> ok, thanks ;-)
[18:50] <desrt> THIS is my point
[18:50] <desrt> they're both good systems
[18:50] <desrt> and they both have a learning curve
[18:50] <seb128> desrt, what if I wanted to drop a printf and don't want to edit the patch by hand?
[18:50] <desrt> i'm annoyed by bzr mostly because it's differnet from what i'm familiar with (just as you are by git)
[18:50] <seb128> desrt, my point is that the bzr learning curve is much easier
[18:50] <seb128> desrt, not only
[18:51] <desrt> seb128: then drop the printf and say 'git commit --amend -a'
[18:51] <desrt> or drop it, manually add the change then 'git commit --amend'
[18:51] <seb128> really bzr is easier, it's "bzr <command>" no parameters, no --
[18:51] <seb128> no --hard
[18:51] <desrt> seb128: how would i edit a commit message in bzr?
[18:51] <seb128> no HEAD or HEAD^
[18:51] <desrt> seb128: and how would i totally delete the effect of the last commit (ie: throw away the changes)?
[18:51] <seb128> desrt, I usually uncommit and commit again with the new message ;-)
[18:51] <seb128> desrt, uncommit && revert
[18:51] <desrt> seb128: sounds harder....
[18:52] <desrt> seb128: so that's the difference between reset --soft and reset --hard
[18:52] <desrt> soft ->you keep your changes, but they are not committed anymore
[18:52] <desrt> hard -> your changes are gone
[18:52] <seb128> so reset --soft revert one commit?
[18:52] <seb128> if I want to undo 2 commits I use it twice?
[18:53] <desrt> 'git reset HEAD^'
[18:53] <desrt> for 2 commits:
[18:53] <desrt> 'git reset HEAD^^'
[18:53] <dobey> git is so incredibly usable; that's why nobody complains about its usability. ever.
[18:54] <desrt> dobey: plenty of people do.  but what i'm trying to say is that i found plenty of similar complaints for bzr yesterday
[18:54] <desrt> this idea that bzr is somehow the most intuitive thing in the world is really a canonical myth
[18:54] <seb128> desrt, well, thanks for teaching me a few stuff, but honestly, both have learning curves but the bzr model is easier to understand, it's mostly simple commands and no tag and arguments you need to remember
[18:54] <dobey> desrt: no it's not. we don't have any sort of myth
[18:54] <dobey> desrt: the myth is that people outside canonical seem to think it is a canonical thing
[18:54] <desrt> dobey: okay.  i guess you're right.
[18:55] <seb128> desrt, like it still doesn't make any sense to me that I've to use HEAD rather than nothing in git commands ;-)
[18:55] <seb128> desrt, I know I do, but still doesn't make sense
[18:55] <dobey> nobody thinks bzr is infallibly perfect with usability. but it is generally better than that of git
[18:56] <desrt> seb128: i'm not going to make claims that 'git reset' is a particular great example of good UI
[18:56] <desrt> seb128: honestly, you don't even know half of what that tool can do
[18:56] <desrt> hell... i don't know half.  you probably know 1/10
[18:56] <desrt> generally there are too many things overloaded there
[18:56] <desrt> but i'd say it's the worst example
[18:57] <seb128> desrt, but I guess it has to do with the fact that branches in git and magic part of the same tree which doesn't really work with my mental model either, having to checkout in the same dir to change trees confuses me
[18:57] <seb128> I like the good old "I've separates dir for separate tree and my path tell me where I am"
[18:57] <desrt> ah ya.  that's a good old argument :)
[18:57] <seb128> desrt, well, true, I don't unsually do a lot from a vcs and I don't need to git power, I need something simple when I can commit, diff and push basically and uncommit,revert,resolve when I screw something
[18:58] <desrt> seb128: there exist some 'nice' frontends to git
[18:58] <seb128> desrt, I guess different people have different needs and different tools fit them better ;-)
[18:58] <desrt> seb128: although they've grown less popular as the git core tools UI has improved
[18:58] <desrt> hum
[18:58] <desrt> seb128: are you still using that emacs crap?
[18:59] <seb128> desrt, lol
[18:59] <desrt> time for lunch :D
[18:59] <seb128> what that comes out you know there was enough trolling :p
[18:59] <seb128> desrt, enjoy ;-)
[18:59] <dobey> i use an etch-a-sketch pen on my hard drive.
[19:19] <seb128> ricotz, there?
[19:32] <BigWhale> bryceh, yeah, I know that only AMD can fix that. I was just whining in general. :/
[19:34] <BigWhale> There's always a thin line with proprietary drivers ... can't decide if I should be glad because they actually did some work or if I should bitchslap them for the crappy work they did... :>
[19:35] <ricotz> seb128, barely
[19:36] <seb128> ricotz, I was wondering if you had a vcs for the vala update and I figured that not so I took the changelog from your ppa (seems it was the only change) and sponsored that
[19:36] <ricotz> seb128, yeah, the gnome3 ppa package is a plain uupdate
[19:37] <ricotz> seb128, not the testing ppa one!
[19:37] <seb128> ricotz, well I just copied the changelog over that's fine ;-)
[19:37] <ricotz> ok ;)
[19:38] <seb128> too many ppas, I got confused :p
[19:38] <ricotz> exactly ;) -- when i copy packages from one to another it is pain to find the right one
[19:39] <ricotz> and the folks package is documented
[19:39] <seb128> kenvandine, ^
[19:40] <seb128> kenvandine, if you want to sponsor that after beta, ricotz has the update in the gnome3 ppa
[19:41] <seb128> jbicha, hey, there?
[19:41] <seb128> jbicha, where was the gnome-bluetooth update you worked on again?
[19:41] <jbicha> seb128: aloha, I emailed it to you, do you want me to send it again?
[19:41] <kenvandine> will do
[19:41] <seb128> jbicha, in my inbox, ok, no that's fine ;-)
[19:42] <seb128> jbicha, I knew it was on my todo but I was not sure where :p
[19:47] <bryceh> BigWhale, the only thing they care about is if the system and card integrators are happy.  So if you don't like what AMD is doing, complain to whomever you bought your hardware from that you want better linux support.
[19:48] <bryceh> well, let's say s/only/main/.  AMD cares in the direction their $$ comes from.
[19:58] <ricotz> kenvandine, thanks
[20:02] <BigWhale> bryceh, unfortunately OEM's/vendors around here are so small, that AMD probably doesn't even know they exist. So, I mostly complain to AMD. :)
[20:10] <micahg> seb128: I was trying webkit on oneiric, but it --no-keep-memory and --reduce-memory-overhead, I still had issues with it building (but that might just be a build failure), it still takes a long time to build though, what I don't understand is how I can build chromium with the same basic webkit tree in ~25 minutes or 45 on a builder
[20:41] <seb128> micahg, did it failed on resources issues or ld being stopped?
[20:45] <seb128> micahg, one thing is that webkit is building twice (gtk2 then gtk3)
[20:45] <seb128> micahg, it takes 2 hours on the powerful buildds so it's about an hour a build
[20:48] <micahg> seb128: it seemed to be spurious build failures, I'm going to retry with .90 after I finish with this Firefox/icedtea regression, I'll let you know if I find any improvements
[20:48] <seb128> micahg, thanks
[22:41] <seb128> robert_ancell, hey
[22:41] <robert_ancell> seb128, yo
[22:41] <seb128> robert_ancell, how are you?
[22:42] <robert_ancell> good
[22:42] <seb128> robert_ancell, how is the pam refactoring stuff going? still no testing needed?
[22:43] <robert_ancell> seb128, the branch works, except for a small logging fix.  So you can play with it tomorrow
[22:43] <seb128> ok, good
[22:43] <robert_ancell> desrt ruined my day and I had to go back to the drawing board a bit
[22:44] <seb128> robert_ancell, somebody wanted to upload http://bazaar.launchpad.net/~siretart/lightdm/fix.877766/revision/57 today
[22:44] <seb128> robert_ancell, I said him I would ping you for comments and to hold off the upload until you upload
[22:45] <robert_ancell> seb128, ok, will take that upstream if it's still applicable.  Otherwise it seems fine
[22:45] <seb128> robert_ancell, that's the nfs permission issue bug we discussed at UDS, it got somewhat stalled, siretart said the change was working fine for him so he wanted to upload it
[22:45] <seb128> robert_ancell, ok, I was unsure if you had an issue with it or not so I told him to wait for your comment
[22:45] <seb128> robert_ancell, thanks ;-)
[22:45] <robert_ancell> seb128, has that been sitting there a while?
[22:47] <seb128> robert_ancell, the actual vcs and patch no, but the bug is the once we discussed at UDS
[22:47] <seb128> robert_ancell, it's just swapping lines
[22:47] <seb128> robert_ancell, you were unsure about it by then and you said you preferred to not include it in the first SRU by then
[22:48] <seb128> robert_ancell, and I guess it got dropped on the way
[22:48] <robert_ancell> yeah
[22:48] <robert_ancell> I'll add a regression test for that
[22:48] <seb128> robert_ancell, next time I will make sure we put a merge request up so it stays visible
[22:48] <seb128> it's easy to loose track of bugs reports...
[22:49] <seb128>  
[22:50] <seb128> RAOF, hey
[22:50] <desrt> robert_ancell: sorry :/
[22:50] <RAOF> seb128: Yo!
[22:50] <seb128> bryceh, RAOF: do you have any clue if bugs like bug #924612 are client issues or xcb issues?
[22:50] <ubot2`> Launchpad bug 924612 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGABRT in __GI___assert_fail()" [High,Confirmed] https://launchpad.net/bugs/924612
[22:50] <seb128> https://launchpadlibrarian.net/91580042/Stacktrace.txt
[22:50] <seb128> "gnome-settings-daemon: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.\n"
[22:50] <seb128>  
[22:50] <seb128> we seem to get quite some similar bugs on different components
[22:51] <seb128> I wonder if that could be a gtk or an xcb one
[22:51] <robert_ancell> desrt, :P
[22:51] <seb128> or if that's an issue in each source
[22:51] <seb128> like that stacktrace doesn't say a lot
[22:51] <seb128> gdk_event_source_check -> XPending -> _XEventsQueued
[22:52] <RAOF> seb128: I'd guess that it's a client bug.
[22:52] <seb128> "great"
[22:53] <seb128> RAOF, do you have any clue of client "typical" errors?
[22:53] <RAOF> https://bugzilla.gnome.org/show_bug.cgi?id=657255#c8 seems like one candidate.
[22:53] <ubot2`> Gnome bug 657255 in gsettings "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Resolved: fixed]
[22:54] <seb128> RAOF, several users on that mentioned hitting it on multiscreen when crossing screen or similar, I was wondering if that could have to do with barriers and I could blame you ;-)
[22:54] <seb128> yeah
[22:54] <seb128> that one was a desrt's bug
[22:54] <seb128> but it's fixed in precise
[22:55] <seb128> but maybe something similar...
[22:55] <RAOF> Yeah, I saw that barrier comment.
[22:56] <RAOF> I'm not convinced that's the same bug, though; gsd crashing shouldn't kill unity, or prevent ctrl-alt-f1
[22:56] <seb128> those bugs are no fun to debug, they happen randomnly to random users, i.e we neither get people who get it often and can help debugging nor steps to trigger them
[22:56] <seb128> RAOF, right
[22:57] <desrt> RAOF: shouldn't, or doesn't? :)
[22:57] <bryceh> seb128, generally if you see "assertion failed" in XCB (as opposed to segfault), it tends to mean XCB noticed a bug in the client's X requests.  (E.g. bad client threading implementation appears to be common)
[22:57] <seb128> desrt, I blame you, maybe your fix for gsettings was not enough ;-)
[22:57] <seb128> bryceh, yeah
[22:57] <RAOF> desrt: I guess it could *concievably* do funky keymapping madness in a crash path, but that would seem excessively perverse, even for gsd :P
[22:57]  * desrt doesn't remember a gsettings fix
[22:57] <seb128> threading bugs are no fun
[22:57] <bryceh> seb128, threading problems are never fun
[22:58] <seb128> desrt, https://bugzilla.gnome.org/show_bug.cgi?id=657255#c8
[22:58] <ubot2`> Gnome bug 657255 in gsettings "gnome-settings-daemon assert failure: gnome-settings-daemon: ../../src/xcb_io.c:575: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed." [Critical,Resolved: fixed]
[22:58] <bryceh> and these sound like they're maybe race conditions
[22:58] <desrt> oh.  that.
[22:58] <desrt> is gsettings in the backtrace anywhere on this one?
[22:58] <seb128> desrt, no
[22:58] <desrt> what is?
[22:58] <seb128> it's not the same error either
[22:58] <desrt> ah.  okay.
[22:59] <desrt> you just wanted an excuse to tease me :)
[22:59] <seb128> desrt, https://launchpadlibrarian.net/91580044/ThreadStacktrace.txt
[22:59] <bryceh> seb128, I got one of those myself on one of my machines, but only one time and only right after rebooting from having done an upgrade
[22:59] <seb128> desrt, well rather than "tease you" trying my luck in case you had an idea about what could be the issue
[22:59] <seb128> desrt, I'm quite clueless about how to debug those
[23:00] <desrt> seb128: i'd use valgrind in this case
[23:00] <seb128> bryceh, yeah, seems like the "standard" description from users for those ;-)
[23:00] <desrt> do you have someone able to reproduce it?
[23:00] <bryceh> seb128, for that one, I sort of wonder if perhaps something during the upgrade (mismatched libraries?) was the cause
[23:00] <seb128> desrt, oh, that stacktrace has dconf in it!
[23:00] <seb128> desrt, I do blame you again!
[23:00] <desrt> seb128: no it doesn't :p
[23:00] <seb128> #5  0x00007f3fb121a78b in dconf_context_thread (data=<optimized out>) at dconfcontext.c:11
[23:00] <desrt> dconf is sitting, idle, in its own private worker thread
[23:00] <desrt> as is gdbus
[23:00] <seb128> nothing seems "busy"
[23:01] <bryceh> I wonder if reinstalling oneiric and then upgrading that to precise might be one way to try and trigger it?
[23:02] <seb128> bryceh, no, I just read the most recent duplicates
[23:03] <seb128> RAOF, several of those mention interacting with the unity launcher or multi screen or barrier btw
[23:03] <seb128> RAOF, like https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/939246
[23:03] <ubot2`> Launchpad bug 939246 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGABRT in raise() (dup-of: 924612)" [Undecided,New]
[23:03] <ubot2`> Launchpad bug 924612 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGABRT in __GI___assert_fail()" [High,Confirmed]
[23:03] <seb128> "X crashed and restarted leaving me on the lightdm launcher page. I believe this issue is being triggered by me having a multi monitor unity setup. Occasionally when I scroll between the two screens, an xcrash occurs"
[23:03] <seb128> well
[23:04] <seb128> that description suggests that users mix issues as well
[23:04] <RAOF> Right, that probably is a bug in the barrier stuff.
[23:04] <RAOF> Just an *entirely* different bug :)
[23:04] <desrt> is the distro in some sort of freeze right now?
[23:04] <seb128> desrt, yes, beta freeze
[23:04] <seb128> hard freeze
[23:04] <seb128> desrt, until thursday (if everything goes ok)
[23:04] <desrt> ah.  in other words, i won't be seeing my bamf patch any time soon
[23:05] <desrt> by nook neither crook
[23:05] <desrt> reminds me.  fedora alpha is out, i think
[23:05] <desrt> time for a reinstall
[23:06] <desrt> my system didn't quite survive the /usr thing unscathed
[23:06] <bryceh> desrt, not unless you sweet talk a release manager, or unless the patch fixes a release critical bug
[23:06] <desrt> bryceh: it's not that important
[23:06] <seb128> desrt, it's in there: https://launchpad.net/~unity-team/+archive/staging
[23:06] <seb128> desrt, bamf
[23:06] <desrt> yup
[23:07] <seb128> desrt, those are the candidate packages for thursday post freeze upload
[23:07] <desrt> 7 hours ago.  hrmph.
[23:07] <seb128> desrt, so "any time soon" is an ok delay
[23:07] <desrt> have i really been awake that long?  madness
[23:07] <seb128> desrt, ;-)
[23:07] <robert_ancell> desrt, ha! serious face http://www.flickr.com/photos/kitty-kat/6775758128/
[23:07] <seb128> lol
[23:07] <desrt> i had a stupid face for the photo before
[23:08] <desrt> so kat told me "look normal!"
[23:08] <desrt> that's the best i could do
[23:08] <robert_ancell> I am serious desrt, and this is serious patch
[23:08] <jbicha> desrt: my Fedora needed a reinstall too :(
[23:08] <desrt> robert_ancell: i don't really care that much since i have a local install anyway
[23:09] <desrt> i'm just trying to get a better handle on how this new DX->Ubuntu process stuff works
[23:09] <desrt> it sounds very red-tapey
[23:10] <desrt> before it was insane chaos
[23:10] <desrt> now we have red tape
[23:10] <desrt> next cycle i bet DX pushes back again and it gets a bit more chaotic
[23:11] <desrt> maybe the cycle after that we'll have it finally figured out
[23:11] <robert_ancell> there's always another cycle
[23:11] <RAOF> By then DX will have ALL THE TESTS and so the chaos will be tamed, and everything will land perfectly in the distro.
[23:12] <seb128> desrt, well, it's not that red tapey, you just caught Didier on a freeze day after he has been dealing for a few hours with late "can we get that in requests"
[23:12] <desrt> seb128: meh.  i've heard a lot of complaints about the new process
[23:12] <desrt> from both sides of the fence, actually
[23:13] <seb128> it's for their good ;-)
[23:14] <seb128> I'm having the opposite issue with robert_ancell :p
[23:14] <desrt> too many tests? :p
[23:14] <seb128> he keeps writting tests and there is no way to get updates out from him:
[23:14] <seb128> !
[23:14] <robert_ancell> seb128, heh, I'm too careful :)
[23:14] <robert_ancell> 101 tests now \o/
[23:14] <seb128> maybe we should send robert_ancell to dx for a cycle ;-)
[23:15] <robert_ancell> noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
[23:15] <seb128> lol
[23:15] <desrt> robert_ancell: it's not that bad
[23:15] <desrt> you get to drink with david barth
[23:15] <robert_ancell> I guess I am physically a long way away
[23:25] <RAOF> Argh!  Why do these tests not reliably pass or fail? http://paste.ubuntu.com/861236/
[23:27] <RAOF> robert_ancell: You've got X testing experience, any guesses? ^^^
[23:28] <robert_ancell> RAOF, which ones? all of them?
[23:29] <RAOF> robert_ancell: Anything involving moving the pointer against a barrier.
[23:30] <robert_ancell> RAOF, does MovePointerTo call WarpPointer?
[23:30] <RAOF> It calls XTestFakeMotionEvent, which generates an absolute motion event.
[23:31] <robert_ancell> RAOF, add a test that moves by one pixel in a loop and see if it smashes into the barrier
[23:32] <robert_ancell> (wondering if the large movements could be causing a problem)
[23:32] <RAOF> Hm, maybe.
[23:32] <RAOF> At the moment these tests are expected to fail...
[23:33] <RAOF> Hm.  I'll give that a try.
[23:33] <RAOF> (And I can *fix* them, I'd just be more confident in the tests themselves if they dependably failed!)
[23:34] <robert_ancell> aside from that the testing looks fine
[23:34] <robert_ancell> RAOF, oh, it's unreliable?
[23:34] <RAOF> Yeah, it's unreliable.
[23:35] <robert_ancell> that's odd.  XLib is synchronous, so everything should be done by the time XQueryPointer is called
[23:36] <jbicha> webkit2 for GNOME 3.6? that'll be fun
[23:37] <RAOF> robert_ancell: Well, not all xlib calls are synchronous.
[23:37] <RAOF> But I should be synchronising appropriately.
[23:38] <robert_ancell> RAOF, Do you even need the WaitForMotion?
[23:40] <robert_ancell> RAOF, yeah, "synchronous when the X protocol expects an immediate response" I guess
[23:42] <RAOF> Oh, urgh.
[23:43] <RAOF> The fixed server was dependably passing these tests last night; now it does not.