[00:00] <bryceh> hmm, mipmap.c is rather dense
[00:01] <RAOF> Yes, it is.
[00:01] <bryceh> aha
[00:01] <bryceh>         rowA = 0x0
[00:01] <RAOF> I went hunting through there earlier.  Although the crash is triggered in the mipmap generation code I think the bug is earlier.
[00:02] <bryceh> that's probably true
[00:02] <RAOF> Ok, so it looks like it still is fdo #32246 :)
[00:02] <bryceh> no, this is me looking at your crash report ;-)
[00:02] <RAOF> Oh :)
[00:04] <bryceh> RAOF, try DEB_BUILD_OPTIONS=noopt to build packages without optimizing out variables, that may help you trace down where the null pointer is coming in
[00:04] <bryceh> RAOF, did you mention you'd tried the newer upstream mesa code?  if not, think it's worth thumbing through recent commits?
[00:05] <RAOF> I'd tried master at the time of filing that bug; it may have been fixed since, I guess.
[00:07] <bryceh> well, to start with it looks like do_row() ought to have an ASSERT(srcRowA);
[00:07] <bryceh> although that won't fix the crash
[00:08] <bryceh> maybe it should just return srcRowB in that case?
[00:09] <RAOF> From memory the underlying problem is that the texture that it's trying to mipmap isn't quite properly set up.
[00:09]  * RAOF hugs sbuild passing through DEB_BUILD_OPTIONS
[00:10] <bryceh> yeah in this case looks like srcB would be invalid anyway (it's just srcA + an offset)
[00:13] <bryceh> ok, mipmap.c:1817 is as far as I can trace the null pointer by eye
[00:13] <bryceh> looks like it verifies the format is not compressed and then gets the null pointer from srcImage->Data
[00:14] <RAOF> Yeah.
[00:14] <bryceh> somehow no asserts for those pointers along this path
[00:14] <bryceh> intriguing
[00:14] <RAOF> I hadn't got as far as working out where srcImage->Data was expected to be set, and why it wasn't.
[00:26]  * RAOF watches as a mesa build races against a dist-upgrade on a 3-drive btfrs system.
[00:27] <TheMuso> lol
[00:27] <bryceh> boy, yeah srcImage->Data gets lost quick in the tangle of calls
[00:30] <TheMuso> bug 719710 likely a dup of others there, but may have a usable backtrace.
[00:30] <ubot2> TheMuso: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/719710)
[00:30] <bryceh> maybe add some debug code to _mesa_GenerateMipmapEXT to display contents of texObj
[00:31] <bryceh> that's the highest point in mesa; above that it's compiz code
[00:31] <RAOF> My thinking was that the problem was actually *before* generateMipmapEXT; that the texture being passed in there hadn't been properly initialised.
[00:32] <RAOF> But I couldn't manage to get a test-case smaller than compiz to exhibit the problem.
[00:32] <bryceh> yeah I think that's the case too
[00:34] <RAOF> I tried to coerce some of the mipmapping piglit tests into crashing in the same way, but couldn't.
[01:05] <TheMuso> Seems apport failed to retrace as well, re my bug mentioned above.
[01:11] <RAOF> It's easily reproducible here, and still occurs with 7.10.1~git
[01:12] <RAOF> So, to master!
[01:13] <TheMuso> Sorry if I have derailed your day of other things...
[01:14] <RAOF> There are few things more important than making sure Unity works on the free drivers ;){
[01:20] <TheMuso> Fair enough.
[01:24] <RAOF> And I've already got it working for nv5x, so radeon's the last holdout :)
[01:26] <TheMuso> Right.
[01:26] <TheMuso> RAOF: Thanks, let me know if I can test anything.
[01:27] <RAOF> Yup, still applies to master.
[01:29] <TheMuso> damn
[01:29]  * TheMuso -> lunch.
[01:41] <bryceh> alrighty
[01:50] <bryceh> RAOF, http://paste.ubuntu.com/567529/
[01:50] <bryceh> haven't tested it, but that should force mesa to kick out early instead of crashing
[01:51] <RAOF> Fair call.
[01:51] <bryceh> justify fixing it here in that due to fdo #32096 this situation has come up  beyond just compiz
[01:52] <bryceh> RAOF, also I found something which is mighty interesting...
[01:52] <bryceh> http://www.opengl.org/wiki/Common_Mistakes
[01:52] <bryceh> scroll down to 'Automatic mipmap generation' and check the Warning
[01:53] <TheMuso> Wow, a can of worms is being opened...
[01:53] <bryceh> I know next to nothing about GL programming, but that sounds awfully similar to what compiz is doing leading up to this crash
[01:54] <bryceh> Warning: It has been reported that on some ATI drivers, glGenerateMipmap(GL_TEXTURE_2D) has no effect unless you precede it with a call to glEnable(GL_TEXTURE_2D) in this particular case. Once again, to be clear, bind the texture, glEnable, then glGenerateMipmap. This is a bug and has been in the ATI drivers for a while. Perhaps by the time you read this, it will have been corrected.
[01:54] <bryceh> it looks like the code is calling glEnable, then binding the texture (I guess?), and then doing the equivalent of glGenerateMipmap
[01:54] <bryceh> I don't know if the order matters though
[01:55] <bryceh> so it looks to my untrained eyes like compiz is doing the right thing, but it seems suspicious.  Someone more knowledgeable in compiz could take a gander
[02:06] <RAOF> I remember having a look; I don't think it calls glGenerateMipmap, because that's a GL 3 call.
[02:14] <TheMuso> I just discovered that nautilus creates an indicator when you copy files, allowing you to close the file copy window and bring it back with the indicator if you want. :)
[02:14] <TheMuso> Cool feature.
[02:25] <RAOF> I obviously do more file copying than you; that's been there pretty much since the advent of indicators ;)
[02:26] <TheMuso> Right./
[02:26] <TheMuso> Or probably because I didn't notice it, I just left the copy windows open int he background.
[02:27] <TheMuso> I only noticed it now because I am going through libappindicator's rdepends.
[02:29] <RAOF> My you can get a lot of debug spew with RADEON_DEBUG=tex :)
[03:07] <RAOF> Hm.  Ok, so the other option would be to ship r600g by default, as Debian and fedora do.
[03:08] <RAOF> #dri-devel is very much of the “why are you trying to fix r600c” frame of mind…
[03:10] <TheMuso> heh so why don't we?
[03:14] <RAOF> Indeed.
[06:54] <pitti> Good morning
[06:54] <pitti> Sweetshark: ah, do you have a shared repo now with an ubuntu branch
[06:54] <pitti> ?
[07:39]  * pitti -> off to an appointment, bbl
[08:00] <didrocks> good morning
[08:04] <mvo> good morning didrocks
[08:04] <didrocks> hey mvo :)
[08:34] <Sweetshark> pitti: yes
[08:34] <Sweetshark> Morning, btw
[08:35] <Sweetshark> I tried to create an export to launchpad, but bzr fast-import fails on it.
[08:36] <didrocks> hey Sweetshark
[08:38]  * Sweetshark waves back at didrocks.
[08:41] <Sweetshark> Another build finished tonight, but failed in the smoketest. The funny thing is: The test itself completes successfully, but JVM dies a horrible dead after that. I am still wondering if it would be better with the Sun JVM instead of OpenJDK ...
[08:41] <Sweetshark> s/dead/death/
[08:47] <chrisccoulson> good morning everyone
[08:54] <didrocks> hey chrisccoulson
[08:54] <chrisccoulson> hi didrocks, how are you?
[08:55] <didrocks> chrisccoulson: I'm fine thanks, you?
[08:55] <chrisccoulson> yeah, not too bad thanks.
[08:59] <seb128> hey chrisccoulson didrocks
[09:06] <didrocks> hey seb128!
[09:08] <seb128> lut didrocks ;-)
[09:12] <huats> morning
[09:12] <huats> hello seb128 and didrocks
[09:13] <didrocks> bonjour huats
[09:13] <seb128> salut huats
[10:19] <pitti> Sweetshark: don't worry about git->bzr; I think it'll cause more trouble than it's worth
[10:20] <pitti> Sweetshark: and you'd break the ability to cherrypick back into debian
[10:29] <lool> Oy
[10:30] <lool> Last time I came to visit here, I reported all the stuff which was broken on the desktop for me  :-)   today, I'd like to note that things have greatly improved in the last weeks, almost all my issues are gone
[10:30] <lool> I also very much like the wiki applet integration, it's looking great
[10:34] <seb128> hey lool \o/
[10:34] <seb128> glad that things work better for you ;-)
[10:35] <seb128> lool, what wiki applet?
[10:39] <lool> err wifi
[10:39] <Sweetshark> pitti: do we have some way to host git too? I have a copy of the repo on UbuntuOne, but still something directly hosted on Ubuntu would ease my mind ...
[10:40] <pitti> Sweetshark: as kernel.ubuntu.com does it, we can do it somehow, but I don't know the details
[10:40] <pitti> Sweetshark: but I thought you'd just commit to the debian repo into the ubuntu branch?
[10:40] <Sweetshark> pitti: I do.
[10:40] <seb128> lool, oh ok
[10:41] <seb128> lool, running unity or classic GNOME btw?
[10:41] <lool> I need to try unity again; last time I tried it was too broken for me
[10:41] <pitti> Sweetshark: you mean backup if alioth goes down?
[10:41] <Sweetshark> pitti: sortof ...
[10:41] <pitti> Sweetshark: I guess alioth + your local copy + ubuntuone should be reliable enough..
[10:41] <Sweetshark> k
[10:42] <pitti> Sweetshark: and then you can of course always put it on people.canonical.com
[10:42] <pitti> Sweetshark: we just don't have gitweb installed there (or maybe we do, and I don't know about it), but that doesn't stop you from pushing a repo there
[10:42] <Sweetshark> ah ok, cool
[10:42] <pitti> Sweetshark: ah, http://packages.qa.debian.org/libr/libreoffice.html still points to bzr
[10:43] <Sweetshark> pitti: not on my local copy ;)
[10:43] <pitti> http://git.debian.org/?p=pkg-openoffice/libreoffice.git;a=shortlog;h=refs/heads/ubuntu-natty-3.3.1
[10:43] <pitti> ah, nice
[10:44] <lool> seb128: Just switched to unity, works fine!
[10:44] <seb128> ;-)
[10:44] <lool> Is there a "launch command" shortcut?  alt-f2 doesn't appear to work
[10:44] <seb128> no...
[10:45] <seb128> in fact I run a classic GNOME session with a gnome-panel in autohiden at the bottem and unity enabled in ccsm there
[10:45] <lool> The number of workspaces is reset to a different value for some reason; perhaps some session switching magic
[10:45] <seb128> so I've unity and working alt-f2
[10:45] <lool> seb128: Eh good trick
[10:45] <seb128> lool, how did you start it? if you run "unity" or the unity session it uses a different compiz profile where unity is enabled by default
[10:45] <lool> I have a xorg bug, but that's unrelated to unity
[10:46] <seb128> but it means you have a stock compiz config
[10:46] <lool> seb128: I'm selecting unity from gdm
[10:46] <seb128> ok
[10:46] <Sweetshark> pitti: 3.3.1~rc2 has been tagged upstream, but I will finish this one as 3.3.1~rc1-2ubuntu1. rc2 will follow later ...
[10:46] <seb128> lool, it might be easier to keep using GNOME but enable unity in cssm
[10:46] <seb128> you would keep your compiz config and have a gnome-panel
[10:46] <seb128> that's what I'm doing ;-)
[10:47] <lool> Is there a way to display other workspaces in unity?
[10:47] <lool> I mean, workspace switcher applet
[10:47] <seb128> no
[10:47]  * lool tries unity 2d to see the difference
[10:47] <seb128> there is the workspace button on the launcher
[10:48] <seb128> which triggers the compiz workspace expose
[10:49] <lool> unity 2d is working quite well too now
[10:51] <lool> seb128: Thanks for the tricks
[10:53] <seb128> lool, you're welcome
[11:03] <didrocks> lool: the default in unity is a 2x2 layout. there is no more "binding magic" with the metacity one and the compiz profiles are separated beetween the unity and the classic session.
[11:03] <didrocks> though, IIRC, I set the metacity to be 2x2 as well by default
[11:03] <didrocks> lool: if you want to change the number of ws in unity, you can use ccsm for that
[11:10] <Sweetshark> pitti: sooo ... should I dput libreoffice_3.3.1~rc1-2ubuntu1 to the libreoffice ppa?
[11:11] <pitti> Sweetshark: you figured out the smoketest failure? if so, go! go! go! :-)
[11:15]  * Sweetshark has been way too long in OOo to not know how to trick the smoketest.
[11:21] <Sweetshark> pitti: when there is a unrelease debian upstream version 3.3.1~rc1-3 and I am basing on it should I can mine 3.3.1~rc1-3unbuntu1 or 3.3.1~rc1-2unbuntu1 (which was released)
[11:22] <pitti> Sweetshark: not "unbuntu" please :) Personally I'd use -3~ubuntu1
[11:22] <pitti> (if -3 is about to be uploaded)
[11:22] <pitti> or if it's still going to get a lot of changes before upload, use -2ubuntu1
[11:23] <Sweetshark> -3 wont be uploaded as debian went on directly to rc2
[11:23] <pitti> Sweetshark: which one doesn't matter much; just don't call it -3ubuntu1 before -3 actually hits debian
[11:23] <pitti> Sweetshark: ah; use -2ubuntu1 then
[11:23] <Sweetshark> k
[11:24] <pitti> and just in case it fails to build in the PPA, -2ubuntu1~ppa1 :)
[11:24] <pitti> then you can do some followup fixes until it builds in the PPA, and upload the final thing as -2ubuntu1
[11:24] <pitti> Sweetshark: do you know ~ ?
[11:24] <Sweetshark> no
[11:25] <pitti> Sweetshark: X~Y is smaller than X
[11:25] <pitti> so ~ is appropriate for backports,
[11:25] <pitti> e. g. if you have 1-2ubuntu3 in natty, the maverick backport would be 1-2ubuntu3~maverick1
[11:25] <Sweetshark> distro is still UNRELEASED until is will hit the natty repos, right?
[11:26] <pitti> so that if you upgrade from maverick plus that backport to natty, the version number will be higher
[11:26] <pitti> Sweetshark: in the changelog? yes, that's a good and common practice to have; you commit stuff with UNRELEASED
[11:26] <pitti> and once you are ready to upload, you do "dch -r" and then "debcommit -r"
[11:27] <Sweetshark> so, I have breoffice (1:3.3.1~rc1-2ubuntu1~ppa1) UNRELEASED; urgency=low
[11:27] <pitti> Sweetshark: so ~ is usually used for kinds of "prereleases"
[11:27] <pitti> Sweetshark: another common use case is 1.0~beta1
[11:27] <pitti> 0.9 < 1.0~beta < 1.0
[11:30] <Sweetshark> pitti: well, debian makes a _lot_ more sense than gentoo there ...
[11:33] <seb128> (gdb) p priv->appinfo
[11:33] <seb128> $2 = (GAppInfo *) 0x92705e8
[11:33] <seb128> (gdb) p *(priv->appinfo)
[11:33] <seb128> $3 = <incomplete type>
[11:33] <seb128> (gdb) p *(GAppInfo*)(priv->appinfo)
[11:33] <seb128> $1 = <incomplete type>
[11:33] <seb128> hates gdb!!!
[11:34] <seb128> does anybody know why it refuses to print it? I've the glib dbg symbols installed
[11:35] <pitti> seb128: I don't know why, I'm afraid; you might be able to use call() with some accessor methods, perhaps?
[11:35] <seb128> pitti, let me try
[11:35] <pitti> seb128: does this work? call g_app_info_get_commandline(priv->appinfo)
[11:36] <pitti> seb128: I guess the reason is that it's a private struct that is only defined within the .c file?
[11:37] <Sweetshark> seb128: does "p *$2" work maybe?
[11:38] <seb128> Sweetshark, no, it's equivalent to " p *(priv->appinfo)" I think
[11:38] <seb128> it gives a " <incomplete type>" as well
[11:39] <seb128> pitti, not really, GAppInfo is a gio structure
[11:39] <seb128> pitti, using the g_app_info_get_... work yes
[11:39] <pitti> cool
[11:39] <seb128> still I would like to figure why I can't print the structure ;-)
[11:40]  * Sweetshark had gdb sometimes be more generous when using the shortcut ...
[11:41] <Sweetshark> apropos crashes: it there a oracle JVM available around natty somewhere?
[11:42]  * Sweetshark wants to test his smoketest with that, suspecting OpenJDK ...
[11:43] <pitti> Sweetshark: you can install it from lucid or maverick partner repository
[11:43] <pitti> (sun-java6)
[11:43] <Sweetshark> pitti: k
[11:52] <didrocks> tseliot: about bug #710762, we have the "open a new instance" feature relying on middle click…
[11:52] <ubot2> Launchpad bug 710762 in xserver-xorg-input-evdev "Middle mouse button no longer works" [Undecided,Won't fix] https://launchpad.net/bugs/710762
[11:56]  * tseliot has a look at the bug report
[12:02] <tseliot> didrocks: what do you mean by "we"? Unity?
[12:03] <didrocks> tseliot: right
[12:03] <didrocks> tseliot: it's a backup key as we won't have time to distro-patch every .desktop file to add the "Add a new instance" entry
[12:05] <tseliot> didrocks: ok, so you need to have middle button emulation back on by default, right? I guess it would take just a simple configuration file to do it
[12:05] <tseliot> I need to talk to the rest of the X team about it first though
[12:06] <didrocks> tseliot: right, just to hilight that case ;) thanks for discussing it at least :)
[12:07] <tseliot> didrocks: so, can you explain a little bit how this works (as I can't use Unity with the radeon driver), please?
[12:07] <didrocks> tseliot: so, by default, when you click on a launcher icon, you open an application
[12:07] <tseliot> right
[12:08] <didrocks> tseliot: it you reclick on it then and that the application is already opened, it focuses it
[12:08] <didrocks> so you can't open multiple instance
[12:08] <didrocks> instances
[12:08] <tseliot> oh, I see the problem now
[12:08] <didrocks> for that, there is two ways:
[12:08] <didrocks> - distro-patching the .desktop for applications we know multiple-instances are working
[12:08] <didrocks> this is the right way to do it, it will be shown by a right click on the launcher icon
[12:09] <didrocks> but obviously, we won't be able to patch every .desktop file we have in the repo where it's needed
[12:09] <tseliot> right
[12:09] <didrocks> so, the backup plan is the second solution:
[12:09] <didrocks> - middle click on the launcher icon
[12:09] <didrocks> that "tries" to open a new instance in every case
[12:10] <didrocks> (with some weird behavior on application focusing as they don't support multiple instances)
[12:10] <didrocks> the fallback with the keyboard is alt + F1 and then space (from next release though)
[12:10] <tseliot> ok
[12:11] <tseliot> didrocks: ok, so I'll send them an email and subscribe you to the discussion
[12:11] <didrocks> tseliot: thanks :)
[14:15] <mterry_> pitti, are you fixing PyGI to work with gtk+2.0 or are we backing out the ports we did already?
[14:15] <pitti> mterry_: uh, what's broken?
[14:15] <pitti> it is supposed to work, I'm not planning to back out the ports
[14:15] <mterry_> pitti, nothing.  I just remember the conversation about PyGI and 2.0 not getting along
[14:15] <pitti> mterry_: I'm happy to backport annotation fixes to gtk2
[14:15] <seb128> works fine here for apport, jockey, etc
[14:16] <mterry_> seb128, oh.  I remember a desktop meeting where we agreed to back out the ports because we didn't want to ship 3.0 and pygi and 2.0 didn't play nice
[14:16] <mterry_> maybe I misremembered that
[14:16] <pitti> mterry_: 3.0 has pretty much perfect annotations now; 2.0 ones are still a bit buggy, but I fixed them up to the point where they work with the stuff that we ported
[14:16] <mterry_> pitti, i see.  so 2.0 mostly works
[14:16] <pitti> mterry_: yeah, it took me some effort to get 2.0 working :)
[14:16] <mterry_> pitti, awesome  :)
[14:17] <seb128> mterry_, right, but since pitti decided to fix gi on gtk2
[14:17] <pitti> mterry_: if you stumble over something that doesn't, I'm happy to fix it up further
[14:17] <pitti> it's usually easy
[14:17] <mterry_> pitti, nope, not yet.  Just got confused
[14:17] <pitti> seb128: (actually it was the other way round -- fix gtk2 for gi :) )
[14:17] <seb128> mterry_, current natty should work fine, he backported the annotations fixes needed for the ports he did
[14:17] <mterry_> cool
[14:17] <pitti> seb128: btw, I'll take off tomorrow and Friday; would you be able to sit in the release meeting?
[14:17] <seb128> mterry_, btw while you are here, please don't use obsolete libs to set the tz
[14:18] <seb128> mterry_, dpkg -L gnome-settings-daemon | grep date
[14:18] <seb128> mterry_, the polkit helper there is what gnome-panel, GNOME3 are using and what the indicator should do
[14:19] <mterry_> seb128, you mean liboobs, yeah, the indicator is using that
[14:19] <seb128> mterry_, well please don't ;-)
[14:19] <mterry_> seb128, or is liboobs considered obsolete?  really?  oh  :(
[14:19] <seb128> mterry_, it's the gnome-system-tools lib
[14:19] <mterry_> right
[14:19] <mterry_> ok, didn't know that was going away
[14:19] <seb128> mterry_, using the gnome-settings-daemon polkit helper should be easy and better
[14:20] <seb128> mterry_, yeah, I assumed so, that's why I'm pointing it now ;-)
[14:21] <mterry_> cool, I think the plan from mpt is to not have the indicator set the timezone directly, but I'll pass along to klattimer too
[14:21] <seb128> mterry_, what would set the tz?
[14:22] <mterry_> seb128, the preference dialog that you can launch from the indicator
[14:22] <mterry_> seb128, which we should make sure does the new thing if we end up writing bunches of it
[14:24] <seb128> hum, seems part of the blame belongs to kenvandine and tedg there
[14:24] <kenvandine> ?
[14:24]  * kenvandine reads back
[14:25] <kenvandine> liboobs is obsolete?
[14:25] <kenvandine> ugh
[14:25] <seb128> right, it's ted who added the depends on the lib
[14:25] <seb128> kenvandine, you will get some slapping for not describing your depends changes in the changelog
[14:25] <seb128> or in the control
[14:26] <seb128> it's mentioned nowehre you started using that lib
[14:26] <seb128> or I would have told you when it was added
[14:26] <kenvandine> :)
[14:26] <seb128> kenvandine, well in any case yes, please use the gnome-settings-daemon polkit helper
[14:26] <kenvandine> tedg, ^^
[14:26] <seb128> that's what GNOME is doing nowadays
[14:27] <kenvandine> that should make the opensuse guys happier too
[14:27] <tedg> Ah, fun.  Hopefully not too big a deal.
[14:28] <kenvandine> they don
[14:28] <seb128> tedg, you can copy set-timezone.c from gcc3
[14:28] <kenvandine> 't have liboobs
[14:28] <seb128> gint     can_set_system_timezone (void);
[14:28] <seb128> void     set_system_time_async   (gint64         time,
[14:28] <seb128> void     set_system_timezone_async   (const gchar    *filename,
[14:29] <seb128> that's basically what is in set-timezone from gcc
[14:29] <seb128> with a get_ as well
[14:29] <tedg> seb128, gcc?  glib?
[14:29] <seb128> tedg, gnome-control-center
[14:29] <tedg> Ah, okay.
[14:29]  * tedg was trying to figure out why the compiler had timezone support
[14:29] <seb128> tedg, take the current git code it's in panels datetime
[14:31] <jibel> seb128, I confirm that the workaround fixes bug 719861 and that it also fix the nautilus crash.
[14:31] <ubot2> Launchpad bug 719861 in gdk-pixbuf "After installation icon theme default to gnome-icon-theme and cannot be changed" [High,Confirmed] https://launchpad.net/bugs/719861
[14:31] <seb128> jibel, right, I figured so for the nautilus crash
[14:31] <seb128> jibel, thanks
[14:32] <seb128> session restart brb
[14:45] <bigon> will you compile empathy with geoclue support now that geoclue is in main?
[14:48] <fta> kenvandine, any update on the fast-respawn dance of indicator-datetime & geoclue-master?
[14:49] <kenvandine> fta, not that i know of, fta is it still happening to you?
[14:49] <bcurtiswx> after installing indicator-weather shouldn't I see it on my top panel?
[14:49] <kenvandine> bcurtiswx, you need to run it
[14:49] <Sweetshark> pitti: Ok, libreoffice_3.3.1~rc1-2ubuntu1~ppa1.dsc finished to build without a smoketest failure this time. I am just unsure, if that is plain luck ... and making ten tries to find out would take some time ...
[14:49] <kenvandine> bigon, not sure, we are easing into geoclue
[14:49] <fta> kenvandine, yep. on my x64 desktop at work. but not at home
[14:49] <kenvandine> interesting
[14:50] <kenvandine> tedg, did you look at that at all yet?
[14:50] <bcurtiswx> kenvandine, "Another instance of this program is already running".  I don't see the numbers on the launcher, which makes me think there's some config file on my comp keeping unity from truly resetting after a computer reboot
[14:51] <bcurtiswx> because I _should_ see indicator-weather
[14:51] <kenvandine> no config file
[14:51] <kenvandine> unless indicator-weather does something like that itself
[14:51] <kenvandine> which i doubt
[14:52] <bcurtiswx> what could possibly cause me not to see the launcher numbers after a reboot ?
[14:52] <kenvandine> well, is it running after a reboot?
[14:52] <bigon> kenvandine: ok
[14:52] <kenvandine> it would have to start itself with the session
[14:53] <tedg> kenvandine, No I haven't.
[14:53] <bcurtiswx> i just rebooted and indicator-weather in terminal says it's already running.. and on reboot the numbers for the launcher (after starting empathy) don't show :-\
[14:59] <fta> tedg, kenvandine: it's bug 718911
[14:59] <ubot2> fta: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/718911)
[14:59] <fta> grrr
[15:00] <fta> oh, i don't use the network-manager on that desktop, that may be the reason
[15:03] <kenvandine> fta,  i was just noticing that
[15:03] <kenvandine> sucky way to fail though
[15:04]  * kenvandine is looking at it
[15:06] <fta> kenvandine, thanks
[15:08] <aquarius> having a weird dconf experience. dconf-editor says "dconf-editor: error while loading shared libraries: libgtk-3.0.so.0: cannot open shared object file: No such file or directory", but dconf-tools depends on libgtk3.0-0. Not sure what might have gone wrong so I can file a bug...
[15:08] <fta> is there a way to tell compiz that i don't want windows overlapping two workspaces?
[15:09] <fta> aquarius, bug 719528
[15:09] <ubot2> Launchpad bug 719528 in d-conf "rebuild against sonamed gtk3" [Undecided,New] https://launchpad.net/bugs/719528
[15:09] <aquarius> fta, cor, that was quick. Thanks :)
[15:09] <dobey> ah, so you are
[15:09] <seb128> aquarius, gtk soname changed
[15:10] <seb128> aquarius, we will do rebuilds but the gtk3 binaries will change so I'm waiting for that to not have to rebuild things twice
[15:10] <seb128> aquarius, you can use "gsettings" on a command line instead as a workaround
[15:11] <aquarius> seb128, yeah, it's not a big problem :)
[15:12] <aquarius> bah, I was looking for a "don't use autohide" key for the unity launcher and there isn't one :)
[15:12] <seb128> aquarius, try ccsm, it's in compiz
[15:13] <aquarius> aha, it is, cheers seb128! although it doesn't do what I want anyway, so never mind :)
[15:13] <seb128> aquarius, what do you want?
[15:14] <aquarius> seb128, I want maximised windows to maximise to the space *other* than the launcher, like they do with the top panel. I'm sure it's being worked on, it just doesn't work yet :)
[15:15] <bcurtiswx> kenvandine, just a suggestion for a future gwibber.  Make it so I can see notifications for all messages for a specific protocol instead of right now where I'll have to see all facebook/twitter/identi.ca messages and I on'y want to see twitter/identi.ca
[15:15] <seb128> ups
[15:16] <seb128> not sure the launcher does that indeed, didrocks knows better about it though
[15:16] <didrocks> hum? backloogging
[15:17] <didrocks> aquarius: you mean, you want the launcher not in autohide mode though?
[15:17] <seb128> didrocks, aquarius's question
[15:17] <didrocks> like, launcher always visible?
[15:18] <didrocks> (in that case, it's Hide launcher -> never)
[15:18] <aquarius> didrocks, yep. Now that I can see progress and alerts for things *on* the launcher (xchat-indicator, U1, that sort of thing) I'm more inclined to look at the launcher itself. I can currently have the launcher show always, but maximised windows appear behind it if I do that, so it's not useful right now.
[15:19] <didrocks> aquarius: hum, maximized or fullscreen?
[15:19] <didrocks> aquarius: for maximize window, if you set the launcher to never hide, it sets the STRUT that the window manager respects
[15:20] <aquarius> didrocks, maximized. The window manager doesn't seem to respect it for me; if I never-hide the launcher, maximized windows appear behind the launcher (both windows that were maximized before I set never-hide, and windows that i maximize after I set never-hide). I have multi-monitor, though, which might be confusing it.
[15:22] <pitti> mterry_: what is https://launchpad.net/ubuntu/+spec/appdevs-desktop-n-quickly blocking on right now?
[15:22] <didrocks> aquarius: for those before you set never-hide, that's normal,
[15:22] <didrocks> aquarius: but maybe the mutlimonitor is confusing it, right
[15:23] <aquarius> didrocks, grr! it's working now! how very annoying. So, ignore me for now and I'll try and reproduce it :)
[15:23] <mterry_> pitti, LP API additions
[15:23] <didrocks> aquarius: sure, do not hesitate to open a bug if you can get a reproducible test case
[15:23] <pitti> mterry_: ah, thanks
[15:23] <kenvandine> fta, geoclue upstream has fixed that bug in git as well as made tons of changes in regard to network manager
[15:24] <kenvandine> now to decide on taking a snapshot, convincing upstream to do a release, or fixing this specific crasher without all the other NM enhancements
[15:25] <mterry_> pitti, not clear it will happen in time for me to also add support to quickly.  So high chance of being postponed
[15:25] <mterry_> especially with FF so close
[15:38] <kenvandine> fta, fix uploaded :)
[15:39] <fta> kenvandine, excellent \o/ thanks
[15:39] <kenvandine> anytime!
[16:08] <kklimonda> mvo: are reviews from software-center going to be marked as "outdated" after some time, when the new version of reviewed application has been made available?
[16:08] <mvo> kklimonda: yeah it already adds a little line about this
[16:24] <jmscone> Is anyone around that's using Natty?
[16:28] <jmscone> I have a semi-major bug I need to see if anyone else is experiencing
[16:31] <devin> hello
[16:31] <devin> i need to talk to a dev
[16:32] <devin> hello?
[16:32] <kenvandine> devin, best to just ask
[16:32] <devin> Could I please talk to a dev? Is anyone available?
[16:33] <devin> I have a gnome/ubuntu bug to report
[16:33] <kenvandine> pretty much everyone in this channel are devs
[16:33] <devin> can I talk to you?
[16:33] <kenvandine> sure
[16:33] <devin> I'd like to report a gnome bug involving the menus
[16:34] <devin> I have a laptop with sound and other action buttons on the front, as well as button with extra functions
[16:34] <devin> such as Fn+F2 turns off the wifi
[16:34] <jmscone> Is anyone else experiencing an issue wherein "linux-generic" is not installed? I am in this installation from A2 and thus my computer isn't updating to the latest kernel
[16:35] <devin> the bug I have noticed is if I'm using currently in ANY menu in ubuntu, and hit any of these function buttons, they do not work
[16:35] <kenvandine> jmscone, i haven't seen a problem with that
[16:35] <devin> if I open the application menu and hit, the increas eor decrease audio button, nothing happens
[16:36] <jmscone> kenvandine, Should I not report it then? Or see if I can get someone else to repro it?
[16:36] <chrisccoulson> devin - that's a well known long standing issue
[16:36] <devin> ok
[16:36] <devin> atleast I'm not crazy and thinking that shouldn't be the behavior
[16:37] <chrisccoulson> the menus have an active grab on the keyboard when they are open
[16:37] <kenvandine> jmscone, prehaps you had a dist-upgrade at a weird time?
[16:37] <chrisccoulson> devin - there's a bug open on launchpad somewhere from years ago
[16:37] <jmscone> I did a fresh install on a separate partition with the A2 ISO
[16:37] <devin> can you put a link? I'm not "savy" on how to find and report bugs
[16:38] <kenvandine> jmscone, not sure then...
[16:38] <jmscone> Alright, I'll check to see if it can be reproduced and then go from there, thanks for the help kenvandine
[16:39] <kenvandine> jmscone, sorry i wasn't more help :)
[16:39] <jmscone> It's okay, any idea of where I should go for an Ubuntu One dashboard issue?
[16:41] <devin> chrisccoulson, could you submit a fresh hit on the bug report for me?   I'm a user, not a dev, got no idea how to go bug reports
[16:41] <chrisccoulson> devin - sorry, i don't really have time to search for bug reports right now
[16:41] <chrisccoulson> devin, https://launchpad.net/
[16:42] <pitti> good bye everyone! I'll be on a long weekend, back on Monday
[16:43] <jmscone> Or about the fact that Banshee looses it's menu if you close it to the sound menu and then re-open it....
[16:44] <chrisccoulson> jmscone, it's best just to report issues you're having to launchpad
[16:44] <jmscone> Alright, I will the appmenu since I can do it consistently.
[16:44] <jmscone> Thank-you
[16:45] <chrisccoulson> jmscone, i'd imagine that's already been reported tbh
[16:45] <chrisccoulson> it's the same with empathy too
[16:46] <jmscone> OK, nevermind, down to just U1 and the kernel thing. Thanks again
[16:47] <chrisccoulson> jmscone, bug
[16:47] <chrisccoulson> 718926
[16:47] <chrisccoulson> bug 718926
[16:47] <ubot2> Launchpad bug 718926 in appmenu-gtk "Some apps don't integrate to appmenu after having their windows closed" [High,Triaged] https://launchpad.net/bugs/718926
[16:47] <chrisccoulson> oops ;)
[16:49] <jmscone> :P
[16:53] <jmscone> What should I file that kernel issue against?
[17:02] <pitti> tedg, kenvandine: FYI, I'm currently fixing the GI annotations for dbusmenu
[17:02] <pitti> (kamstrup mentioned that in bug 709240)
[17:02] <ubot2> Launchpad bug 709240 in libunity "libunity support gobject-introspected languages" [High,Triaged] https://launchpad.net/bugs/709240
[17:03] <kenvandine> pitti, missing annotations?
[17:03] <pitti> kenvandine: that, misformatted annotations, and bug in build system
[17:03] <kenvandine> ok
[17:03] <kenvandine> thx
[17:04] <tedg> pitti, Cool, thanks!
[17:06] <didrocks> pitti: nice! kamstrup will do the release tomorrow and I'll upload it then :)
[17:07] <pitti> didrocks: I guess I won't be done by then
[17:07] <pitti> didrocks: I'll take off tomorrow and Friday, and won't have much time any more today
[17:07] <pitti> but I'll get it ready by next Monday
[17:07] <didrocks> pitti: oh ok, sure then, that can wait and being distro-patch if needed :)
[17:35] <dobey> can i get some sponsor love? https://code.launchpad.net/~dobey/ubuntu/natty/libubuntuone/release-0_3_11/+merge/50019
[17:46] <micahg> didrocks: hi, got a minute?
[17:46] <htorque> hello everyone! which component is responsible for the window decoration in a classic session with compiz?
[17:46] <seb128> pitti, still there?
[17:47] <didrocks> micahg: sure
[17:47] <seb128> htorque, yes
[17:48] <micahg> didrocks: so, I was wondering about gjs in natty, if we don't have gnome-shell, is there any reason to keep it?  (it's staged in the GNOME3 PPA with the rest of the stack)
[17:48] <htorque> seb128, yes what? ;-)
[17:48] <seb128> htorque, it's compiz
[17:48] <seb128> htorque, sorry I misread your question
[17:48] <seb128> it's compiz
[17:48] <didrocks> micahg: because GNOME people asked for it, to be able to develop against ubuntu without adding a ppa. There was no real reason on the removal as well (just "not needed")
[17:49] <htorque> seb128, ah! :) so a bugs go to compiz then, thanks!
[17:49] <seb128> htorque, you're welcome
[17:49] <seb128> micahg, the-board is using it as well for example
[17:49] <micahg> didrocks: ah, it's for the GNOME devs, ok
[17:49] <micahg> seb128: is the board going in natty?
[17:49] <seb128> micahg, it's a way to use gi in javascript which people start doing
[17:50] <seb128> micahg, not sure
[17:50] <seb128> micahg, but still it seems we want the framework to be available because people start shipping code using it
[17:51] <seb128> micahg, it's likely users will want to play with gtk or gnome libs in javascripts, even if they don't use g-s
[17:51] <seb128> micahg, or the-board
[17:52] <micahg> seb128: ok, but it's hard to support security wise, let
[17:52] <seb128> micahg, do we care if it's in universe and not used by anything which users can run in the archive?
[17:52] <micahg> seb128: well, -security updates ideally shouldn't break things in universe
[17:53] <seb128> seems it's something our upstream and users really want and where maintainance should be easy enough
[17:53] <micahg> and either way, if we update xulrunner or switch back to mozjs and update that, if Mozilla breaks the compatibility with the update, that needs porting
[17:54] <seb128> since g-s is going to depends on it it's likely that upstream code and debian will be updated on xulrunner updates
[17:54] <chrisccoulson> tbh, it's quite likely we're going to get a separate libmozjs source package soon which won't be coupled to firefox releases
[17:54] <chrisccoulson> the current situation is too much of a pain ;)
[17:54] <micahg> chrisccoulson: we still need security support for those :)
[17:54] <micahg> and decoupling may or may not make it harder
[17:55] <seb128> micahg, well if we break gjs for a few when xulrunner get security updates it's not end of the world if nothing use it
[17:55] <chrisccoulson> well, the gnome guys are arguing that the only content gjs is exposed to is secure
[17:55] <chrisccoulson> so, it doesn't need the same level of maintenance security-wise
[17:55] <micahg> chrisccoulson: if that's the case, then we can just lock it into the release version of xulrunner
[17:56] <chrisccoulson> if we don't have a separate libmozjs source package that is decoupled from firefox releases, then we should just drop all of these things from the archive (as being unsupportable) IMO ;)
[17:56] <chrisccoulson> permanently :)
[17:57] <chrisccoulson> the JS engine is something that's likely to keep breaking frequently over the next few releases
[17:57] <micahg> chrisccoulson: even with mozjs, unless upstream makes separate releases, it seems fragile and prone to error
[17:57] <chrisccoulson> i've seen the sort of things they're discussing for ff5.0 already, and that's going to happen next cycle according to the schedule ;)
[17:58] <chrisccoulson> micahg - the idea is that we can pick a JS version, and stick with it for a while until we're ready to do a transition
[17:58] <chrisccoulson> rather than having to do a majot transition every 3-6 months
[17:58] <chrisccoulson> **major
[17:58] <micahg> chrisccoulson: we still needs security updates for it though, if they abandon the branch, it's still an issue as most of the CVEs are JS vulns
[17:58] <micahg> s/most/a lot/
[17:59] <chrisccoulson> right, but that defeats the purpose of having a separate source package
[17:59] <chrisccoulson> like i said, if we can't do that, then i think we should just drop all of this stuff from the archive ;)
[17:59] <micahg> chrisccoulson: which is why I'm torn on the subject :)
[18:00]  * micahg wishes seed could do the same stuff gjs does
[18:02]  * dobey wishes people weren't trying to write local applications in javascript
[18:02] <chrisccoulson> heh :)
[18:03] <chrisccoulson> and talking of javascript, i'm still trying to get google-gadgets working with the latest mozjs
[18:03] <chrisccoulson> it's taken a 70kB patch just to make it build
[18:03] <chrisccoulson> and it still doesn't work
[18:03] <chrisccoulson> grrrr
[18:04] <chrisccoulson> this is why these things are unsupportable ;)
[18:15] <seb128> kenvandine, do you think you could try to figure why gdk-pixbuf doesn't build?
[18:15] <seb128> it's something gir-ish
[18:16] <seb128> I've to run in 15 minutes, my upload just failed but I don't think I will have time to debug it before dinner
[18:18] <rodrigo_> hello?
[18:18] <dobey> hi
[18:18] <rodrigo_> ok, it works now!
[18:18] <rodrigo_> hi dobey
[18:18] <dobey> your opensuse hostmask? :P
[18:19] <rodrigo_> dobey, no, my router
[18:20] <rodrigo_> it broke last night, and I've been the whole day waiting for a new one
[18:21] <dobey> ah
[18:24] <seb128> hey rodrigo_
[18:25] <seb128> rodrigo_, I sorted the g-s-d issue jibel was having today
[18:25] <rodrigo_> seb128, oh, cool, what was it?
[18:25] <seb128> rodrigo_, the nautilus crash is a side effect of it
[18:25] <rodrigo_> oh, cool :)
[18:25] <seb128> rodrigo_, https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/719861 for details
[18:25] <ubot2> Ubuntu bug 719861 in gdk-pixbuf "After installation icon theme default to gnome-icon-theme and cannot be changed" [High,Fix released]
[18:26] <seb128> rodrigo_, basically the librsvg gdk-pixbuf loader was not registered because at the registration time libgl1 is not in the ldconfig path which breaks it
[18:26] <seb128> rodrigo_, so they don't have svg support, which means svg themes seem to not apply
[18:27] <seb128> rodrigo_, the nautilus crash is due to it as well, it shouldn't crash though so might still be something to work on but lower importance
[18:27] <rodrigo_> seb128, crashing because of the missing lib?
[18:27] <seb128> rodrigo_, no, it probably fails to do something
[18:27] <Sarvatt> didrocks: here's a very basic list of what needs to be done to downgrade X and not screw up the package manager royally on i386 at least http://sarvatt.com/downloads/downgrade.txt
[18:28] <Sarvatt> (for proprietary blob users)
[18:28] <rodrigo_> ok, will look at it, on a virtual machine, since my current desktop is mostly gtk3-based stuff
[18:28] <seb128> rodrigo_, well, remove the svg loader and try to run nautilus
[18:28] <rodrigo_> seb128, ok
[18:28] <seb128> rodrigo_, or just edit the cache in /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders to remove the svg loader
[18:28] <seb128> rodrigo_, you will get a crash with a stacktrace similar to the launchpad one
[18:28] <didrocks> Sarvatt: oh nice, I'll redirect people to that one. I've done it by hand yesterday, just took 1h30 but worked well
[18:30] <rodrigo_> seb128, ok, added your comments to the nautilus bug, so that I don't forget (getting up-to-date with everything now that I have inet back)
[18:30] <Sarvatt> didrocks: sorry again for the trouble yesterday, even nvidia thought that blob was *supposed* to work on natty :D
[18:30] <seb128> rodrigo_, ok
[18:30] <dobey> seb128: can you sponsor https://code.launchpad.net/~dobey/ubuntu/natty/libubuntuone/release-0_3_11/+merge/50019 pleae?
[18:30] <seb128> dobey, ok
[18:31] <didrocks> Sarvatt: no worry, as long as I have been able to downgrade… ;-)
[18:31] <rodrigo_> dobey, I have ppu permissions for that package, if in the future you don't find seb128 (he's still better than me sponsoring things anyway :)
[18:31] <Sarvatt> I'm just hoping that doesn't mean another 1 month wait just so they can recompile it against the correct version, haven't heard anything back yet
[18:32] <seb128> rodrigo_, do you think your push to launchpad issues were due to the broken router?
[18:33] <rodrigo_> seb128, no, I don't think so
[18:33] <dobey> rodrigo_: yeah, i just need to get around to applying for motu and more ppu :)
[18:33] <rodrigo_> dobey, yeah, better
[18:33] <rodrigo_> seb128, the router just stopped working at all last night, but before that, everything else was working great, except the push
[18:34] <seb128> rodrigo_, weird
[18:35] <rodrigo_> seb128, yeah, next time I need to push some stuff (probably tomorrow, as I have some 2.91 packages in progress), I'll try doing some debugging
[18:47] <didrocks> good evening
[18:59] <lamlex> bryceh: is it possible to run a user run a specific apport hook and have it automatically attach to a bug report? like apport-collect but for a specific hook
[19:01] <bryceh> lamlex, hmm, seems like that should be possible, although I don't know the syntax
[19:01] <bryceh> lamlex, I know the hooks can be run independently (which I do frequently for testing), but they generate new bug reports
[19:02] <bryceh> lamlex, apport-cli has a --update-report <num> option
[19:03] <bryceh> lamlex, and it has a --package <pkg> option
[19:03] <bryceh> presumably using both those together should trigger (only) the respective hook, and attach to the given bug
[19:03] <lamlex> bryceh: rad thanks
[19:04] <lamlex> i will poke around
[19:04] <lamlex> i figured you might know before i spend a bunch of time trying to figure it out
[19:04] <bryceh> cool, yeah lemme know what you find, I'm curious now myself :-)
[19:12] <Sweetshark> https://launchpad.net/~libreoffice/+archive/ppa/+buildjob/2266942 <- and there was much rejoicing!
[19:23] <pitti> Sweetshark: congrats!
[19:25] <seb128> pitti, unping btw
[19:26] <seb128> pitti, it was to know if you still have your gdk-pixbuf merge in a vcs ready to push locally but I merged, added my patch and uploaded since
[19:26] <pitti> seb128: apparently I don't
[19:26] <pitti> sorry if I forgot to push
[19:26] <seb128> no worry
[19:27] <seb128> but now I need someone with gir clue to figure why it fails to build
[19:27] <pitti> output?
[19:27] <seb128> the source didn't change so it's like due to the gir stack updates
[19:27] <seb128> pitti, http://launchpadlibrarian.net/64467165/buildlog_ubuntu-natty-i386.gdk-pixbuf_2.23.0-1ubuntu2_FAILEDTOBUILD.txt.gz
[19:28] <pitti> /usr/bin/ld: /build/buildd/gdk-pixbuf-2.23.0/gdk-pixbuf/tmp-introspectzTObRP/GdkPixbuf-2.0.o: undefined reference to symbol 'g_input_stream_get_type'
[19:28] <pitti> /usr/bin/ld: note: 'g_input_stream_get_type' is defined in DSO /usr/lib/libgio-2.0.so.0 so try adding it to the linker command line
[19:28] <pitti> seb128: it's not GIR, it's the linking; probably looks a bit weird due to parallel build
[19:29] <pitti> oh, sorry, gir scanner link
[19:29] <seb128> no, I think it's due to the warning before it
[19:29] <pitti> why is gdk-pixbuf looking for gdk-pixbuf.pc?
[19:30] <seb128> dunno
[19:32] <seb128> it built before that's weird, I just changed a script, nothing to the code
[19:37] <cyphermox> huh, is there a way to get left+right click to emulate middle-click again?
[19:44]  * pitti waves good night for real
[19:44] <bryceh> cyphermox, yes
[19:44] <bryceh> /usr/share/X11/xorg.conf.d/ :
[19:44] <bryceh> Section "InputClass"
[19:44] <bryceh>     Identifier "middle button emulation"
[19:44] <bryceh>     MatchIsPointer "on"
[19:44] <bryceh>     Option "Emulate3Buttons" "on"
[19:44] <bryceh> EndSection
[19:45] <bryceh> add that to your xorg.conf
[19:45] <cyphermox> ah, thanks bryceh
[19:45] <cyphermox> so this was turned off on purpose or something?
[19:45] <kklimonda> yes
[19:45] <bryceh> cyphermox, it's an upstream change - https://launchpad.net/bugs/710762
[19:45] <ubot2> Ubuntu bug 710762 in xserver-xorg-input-evdev "Middle mouse button no longer works" [Undecided,Won't fix]
[19:45] <cyphermox> ah, cool
[19:45] <kklimonda> it's unfortunate, as unity relies on the middle-click
[19:45] <mvo> it seem s to be no longer work after resume, that used to be the case
[19:45] <bryceh> yeah
[19:46] <bryceh> we're mulling over the pros and cons
[19:47] <cyphermox> it's not so bad once I stopped being an idiot and used the scrolling wheel to click... but I order the ubuntu travel mouse and its wheel doesn't click ;)
[19:48] <bryceh> "ubuntu travel mouse"?  what is that?
[19:48] <cyphermox> a tiny usb mouse: http://shop.canonical.com/product_info.php?products_id=643
[19:48] <bryceh> mm, thanks for the link
[19:50] <kklimonda> wow. it's tiny :)
[20:06] <mvo> Sweetshark: hello, just a quick ping if you are aware of bug #715075
[20:06] <ubot2> Launchpad bug 715075 in openoffice.org "file overwrite error maverick->natty" [Undecided,New] https://launchpad.net/bugs/715075
[20:09] <Sweetshark> mvo: have not been yet aware of it. is reaasigned to me.
[20:11] <Sweetshark> mvo: there is a libreoffice-3.3.1~rc1-2ubuntu1~ppa1 building in the libreoffice ppa btw (amd64 is done, i386 is still building)
[20:12] <mvo> Sweetshark: nice
[20:13] <mvo> Sweetshark: thanks, its not a huge deal, by default we run the upgrade with --force-overwrite, but still worth fixing
[20:19] <Sweetshark> ivanka: hi!
[20:19] <ivanka> Sweetshark: hi!
[20:20] <Sweetshark> ivanka-train: Do you have a minute for talking about the human iconset for Libreoffice?
[20:21] <ivanka-train> Sweetshark: I am on the train so could cut out but apart from that, sure
[20:21] <ivanka-train> Sweetshark: what about it?
[20:23] <Sweetshark> I enabled the code upstream to handle the additional iconset. So all that need to be done to get the itemset on the system is dropping a images_human.zip at the right location in the filesystem.
[20:27] <Sweetshark> packing that zip is contains no further magic, so I would propose to make a simple package with just creates the zip from a set of icons. I would setup a bzr branch for it on launchpad and populate it with the (default) tango iconset. Icons could then simply be replaced/updated on that branch.
[20:29] <Sweetshark> This would allow us to make modifications to the icon set without the need to juggle around with the huge and complex Libreoffice package, also it would allow fixes independant of Libreoffice builds.
[20:31] <Sweetshark> I have no idea where the human icons themselves are stored currently, somebody who does will have to put them in the bzr repository then. Does that sound ok for you?
[20:35] <Sweetshark> ivanka-train: Still there?
[20:37] <ivanka-train> Sweetshark: yup, everything just coming through. I suggest you find DanRabbit on irc tomorrow - he knows much more about the ins and outs than I do. In principle your suggestion sounds grand!
[20:38] <Sweetshark> ivanka-train: great, will do!
[20:39] <Sweetshark> ivanka-train: which timezone is DanRabbit in?
[20:40] <ivanka-train> Sweetshark: london this week but normally california
[20:40] <Sweetshark> ivanka-train: great, I am in Hamburg, Germany, so that will work out.
[20:42] <ivanka-train> Sweetshark: splendid!
[21:00] <ricotz> Sweetshark, i think vish is maintaining the human icons
[21:01] <ricotz> Sweetshark, look in #elementary
[21:03] <vish> Sweetshark: the human icons for OOo are in a separate package  "openoffice.org-style-human"
[21:07] <DanRabbit> Sweetshark: hey I'm here but I'll be right back :p
[21:07] <Sweetshark> heh
[21:08] <Sweetshark> vish: So is there any version control for the human icons?
[21:09] <vish> Sweetshark: nope.. they are not updated from anywhere.. initially when Ubuntu used Human the packaged was named -human , then when we switched to humanity , someone from the community updated the human icons to humanity .
[21:09] <vish> there was a bug somewhere for that
[21:09] <vish> s/packaged/package
[21:10] <Sweetshark> k
[21:10] <Sweetshark> I would like to setup a bzr branch on launchpad for it.
[21:11] <Sweetshark> for example here: https://code.launchpad.net/~libreoffice
[21:11] <Sweetshark> it would make it much easier to track changes
[21:11] <vish> https://code.launchpad.net/~10068660/openoffice.org-human-icons/tango+human
[21:11] <vish> thats the branch^
[21:12] <Sweetshark> ah, cool
[21:14] <Sweetshark> so, is that human atop of tango?
[21:14] <vish> actually "humanity", the 'human' icons were replaced, but no one renamed the branch :)
[21:15] <Sweetshark> aka tango icons as a base and some modified humanity icons ontop of it?
[21:15] <Sweetshark> k
[21:15] <vish> yup..
[21:17] <Sweetshark> Is that stuff complete? Tango itself fallbacks on Galaxy(?) IIRC. Upstream icons are packed completely now (copying missing icon in from the fallback).
[21:18] <Sweetshark> If not we would need to "fill up" the missing ones from a (newly generated) tango.
[21:18] <Sweetshark> (which itself now might include some galaxy)
[21:19] <vish> not really sure.. but i tried to do that update (human -> humanity) but my brain turned to goo.. ;p  too many icons needed to be updated and the names were all messy
[21:21] <vish> Sweetshark: but as you mention, not all the icons replace Galaxy
[21:22] <vish> last time i checked, the copyright is also a bit mixed there.. each groups of icons get their own copyright holder
[21:23] <Sweetshark> vish: so it would probably make sense to take a new tango set (which includes Galaxy fallbacks) and then copy the current repostate over it and see what changes remain.
[21:23] <patrickmw> Anyone here running Natty that uses Evolution for email?  Curious if anyone has had issues sending messages.  Either getting error referencing a lock in Outbox or referencing "Appending to local 'Sent' folder instead"
[21:24] <vish> Sweetshark: hmm, actually the current one should be a complete set of icons.. just not complete set of similar style
[21:25] <vish> so if you use a new tango set and replace , you'd basically replace everything..
[21:27] <vish> Sweetshark:  why not just clone the branch and use for LibO ?
[21:27] <vish> (not sure why you think that wont work..)
[21:27] <vish> this is the main branch : https://code.launchpad.net/~openoffice.org-human-icons/openoffice.org-human-icons/tango+human
[21:30] <vish> Sweetshark: basically why the "openoffice.org-style-human" package exists is to rebrand OOo to fit the Ubuntu theming
[21:30] <vish> so that the folders/arrows/etc all look the same as other windows
[21:32] <Sweetshark> vish: what do you mean with "use for LibO"?
[21:32] <vish> Sweetshark: well, if the icon names have not changed that package should work for LibreOffice(LibO)
[21:33] <Sweetshark> vish: you mean putting the icons upsteam to the libreoffice repos?
[21:34] <vish> Sweetshark: either that, or use it the sameway OOo was using the -human package
[21:36] <Sweetshark> vish: That would mean to do a "clean" update of the icons one would have to do a full LO rebuild => Bad
[21:37] <vish> Sweetshark: oh! right.. i just read the whole backlog.. so you want to package these icons as "humanity.zip" and use it that way?
[21:37] <Sweetshark> vish: yes
[21:37] <Sweetshark> and we could make icon updates idependant of LO builds.
[21:38] <vish> Sweetshark: well, there is no easy way to do this; one has to manually check the icons and replace them :)
[21:38] <vish>  there are like literally 1000+ icons there.. ;p
[21:41] <Sweetshark> vish: why? because they are in a different sorting in the zip as opposed from the current repo structure?
[21:43]  * Sweetshark is amazed that the libreoffice_3.3.1~rc1-2ubuntu1~ppa1 package actually seems to work ....
[21:43] <vish> Sweetshark: yea, not sure what the new sorting order in the .zip is now.. so I'm not sure if it would work if icons are in different folders.. and there was no sane naming of the icons, it is literally not an easy task to check those icons
[21:45] <vish> Sweetshark: ^thats from what i noticed with the OOo icons.. i havent tried to look at the LibO package ;)
[21:47] <Sweetshark> vish: then I would do _one_ build with the humanity icon from the repo and get a totally zip file that is ordered (or mixed) totally different. Then you unpack that, put it that order in a repo (a new one would make sense, I guess) and continue to work directly on that.
[21:48] <Sweetshark> argh - remove the first "totally" in that sentence
[21:48] <vish> Sweetshark: no one is working on those icons.. :)  (or going to afaik) ,mainly cause there is no need there..  so if you package it once it should be good for a while..
[21:53] <Sweetshark> well, with no fallback in LO (thus requiring each iconset to be complete), there might be some work needed on them between releases. One could check that by comparing the unpacked images_tango.zip between releases though and do similiar changes for humanity.
[21:54] <Sweetshark> DanRabbit: Any comments from your side?
[21:57] <Sweetshark> Does not seem so. ;)
[21:57] <Sweetshark> DanRabbit, vish: Thanks a lot, you helped me along quite a bit!
[21:57] <vish> np.. :)
[21:57] <DanRabbit> Sweetshark: don't thank me I didn't do anything :p
[21:58] <DanRabbit> sorry I went to have a shower, I thought vish had it sorted pretty well haha
[21:59] <vish> DanRabbit: pff, shower!  you always hated OOo and preferred Gnome Office ;p
[21:59] <DanRabbit> vish: yea that too
[22:00] <dobey> gnome office?
[22:03] <DanRabbit> dobey: I think it's an unofficial title, but Abiword + Gnumeric + Ease
[22:03] <dobey> what is ease?
[22:05] <dobey> oh
[22:06] <dobey> looks complicated
[22:24] <rickspencer3> crikey
[22:24] <rickspencer3> I accidentally the whole side pane in LO, and I cannot figure out how to get it to redock :(
[22:24] <broder> the current state of sandybridge is that maverick supports the cpu and natty's kernel+X stack support the integrated gpu, right?
[22:30] <RAOF> broder: Maverick supports 2D on the GPU, Natty supports 3D.
[22:30] <broder> ah, cool
[22:30] <broder> and it is both kernel and X changes?
[22:33] <Sweetshark> re after the usual nouveau reboot :(