[00:10] hey chrisccoulson , achiang was wondering if we have a Firefox ESR PPA? I wasn't sure. Last I checked we didn't. [00:12] surely chrisccoulson isn't awake atm? [01:31] hi jbicha, did you ever get gnome-boxes working on precise? deb or git, it always segfaults. [01:35] LLStarks: do you have hardware virtualization [01:39] because yes, it does work with the Debian packaging on amd64 with hw virtualization, there's some rough edges but that's to be expected for the first release after a few months development [02:28] jbicha, i have vt-x [02:28] no vt-d [02:29] i can also do a bt if you want [02:30] seems to fail because of sparql [02:44] LLStarks: sparql? do you have tracker-0.14 installed? & have you rebooted after installing all that? [02:45] LLStarks: Boxes doesn't actually work for me on my usual computers, no hw-virt :( [02:52] LLStarks: oh, and you'll need qemu-kvm-spice on Ubuntu [02:53] lemme check [02:54] i do have tracker installed [02:55] i'll brb with a reboot. if you want a trace, i'll paste it [02:55] not sure what symbols i need though [03:05] jbicha, http://pastebin.com/Qs5pHLEB [03:24] LLStarks: perhaps tracker needs to be compiled with iso support [03:24] like I said, the app doesn't really work for me [03:25] and because it requires the libvirt from Debian experimental, it's not going to land in Precise [04:59] Good morning [05:00] Morning pitti. [05:00] pitti: re bug 966845 any suggestions? [05:00] Launchpad bug 966845 in pyatspi "lucid->precise upgrade wants to remove ubuntu-desktop" [High,Triaged] https://launchpad.net/bugs/966845 [05:01] TheMuso: there might be more subtle ways to fix this, but for now the only alternative I know of is to drop the Conflicts:, and have them both installed side by side [05:01] TheMuso: err, I mean [05:01] urm.... I don't think they can be installed side by side. [05:01] TheMuso: make the conflicts versioned [05:02] TheMuso: and have transitional at-spi and python-pyatspi packages which depend on their newer counterparts [05:02] TheMuso: when we drop the last "real" reverse depends on the old stack, they can become transitional [05:04] Ok, I'll file a removal request for gok. [05:04] * TheMuso meant to do that yesterday, but got sidetracked. [05:04] TheMuso: I'll do that immediately then [05:05] Ok. [05:05] TheMuso: then the transitional approach seems best to me [05:05] yes ok. [05:09] pitti: bug 972101 [05:09] Launchpad bug 972101 in gok "Please remove gok from precise." [Undecided,New] https://launchpad.net/bugs/972101 [05:15] good morning [05:28] bonjour didrocks [05:29] guten morgen pitti :) [05:30] TheMuso: removed and blacklisted from syncing [05:40] pitti: So, if I am understanding your suggestion correctly, we also need to remove at-spi package. [05:40] TheMuso: less urgent, but eventually yes [05:40] TheMuso: at-spi2 should build a transitional at-spi package, and similar for pyatspi [05:41] But wouldn't that mean we have one binary package from 2 sources? I thought that wasn't possible... [05:43] Good Morning. [05:44] pitti: Do you know of any bug in 12.04 that would prevent a BT device from showing up in Sound Settings as a profile? [05:44] pitti: I tried getting this resolve and slangasek helped some but it ended up just having to be reported as a bug here: https://bugs.launchpad.net/bugs/972063 [05:44] Launchpad bug 972063 in pulseaudio "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Undecided,New] [05:45] didrocks: so, HUD madness is finally gone for me, yay :) [05:45] TheMuso: we still need to remove the old sources afterwards, of cours [05:45] pitti: *phew*, awesome! :) [05:45] TheMuso: but you can have two binaries from two sources, apt will just install the one with the higher version number [05:45] TheMuso: so we don't need to remove the old sources prior to uploading the new ones [05:46] bkerensa: not off-hand; cyphermox might know [05:46] bkerensa: I have about three BT devices here, and they all show up [05:47] pitti: ok yeah its really weird that its not showing up even though it pairs fine [05:48] pitti: ah ok. [05:49] cyphermox: if you get a chance can you perhaps have a look at that bug ^ and if you have any troubleshooting tips or debugging ideas can you share them? thx [05:53] morning pitti and didrocks :) [05:57] hey jasoncwarner_, how are you? :) [05:58] hey jasoncwarner_ [05:59] didrocks, good, thanks, just getting 12.10 stuff ramping up! [05:59] jasoncwarner_: living on really edge! ;) [06:02] didrocks: what time is it for you? 7am or 6am? (daylight savings is messing me up again). Pitti, same? 7am? [06:03] 8am now :) [06:03] jasoncwarner_: 8 AM [06:04] * jasoncwarner_ thinks the world should adopt a standard clock so I don't melt my brain twice a year ;) [06:06] didrocks: are you ok if we just distro patch seahorse to fix https://bugs.launchpad.net/seahorse/+bug/931958 ? [06:06] Launchpad bug 931958 in unity-distro-priority "0.9.7: impossible to click on keyring dialog since the upgrade" [Medium,Fix committed] [06:07] I've looked into it for quite some time now and I just don't see a plausible way for compiz to work around this stupid behaviour [06:07] smspilla1: well, seb128 knows more upstream than I, but they are friendly to us. I think it's doable if it's reasonable [06:07] okay, I'll see what I can do [06:08] "he fact that is works on metacity is a fluke because seahorse is deciding not to take a grab in the particular focus path that metacity uses." [06:08] smspilla1: you mean that seahose is detecting metacity? [06:08] no its just [06:08] I'm not really sure what its doing [06:08] but it seems to release its grabs somewhat [06:08] arbitrarily [06:09] the whole fact that its retaining a grab even when the window loses focus makes no sense IMO [06:10] could also be a server bug too ... this is hard to track down because I've tried setting breakpoints on XIDeviceGrab and XIDeviceUngrab and it didn't indicate that seahorse is explicitly taking or releasing any grabs here, even though a simple test application shows that something has a grab [06:10] maybe its an external process that is taking the grab ? [06:10] I'm not sure how well seahorse works ... [06:10] well, I'm not entirely sure how seahorse works in that regard, rather [06:14] didrocks: ah I see what its doing [06:14] it ungrabs the device, pops up a new window [06:14] and then if the focus moves away from that window it grabs the device again [06:15] but if you give focus to the dialog, it won't release that grab again [06:15] at least as far as I can tell [06:15] so I think what is happening is that [06:15] it ungrabs the device [06:15] compiz change sthe focus to something else and then to that window [06:16] and then seahorse gets confused [06:16] although considering that other wms are also doing this, I think their heurestic is probably broken, and we should just make it ungrab whenever the dialog gets the focus [06:16] didrocks: wdyt ? [06:16] (its a separate pid too, clever) [06:17] smspilla1: I have no strong opinion, I would first want upstream to comment on why they are doing it this way [06:17] smspilla1: maybe it's related to some security concerns [06:17] smspilla1: so let's wait seb, he knows upstream very well for seahorse [06:17] smspilla1: thanks for looking into it :) [06:17] well like [06:18] it would seem to me that it would make sense to release the grab [06:18] after the dialog gets focus again [06:18] since I'm now pretty sure that [06:18] if you open seahorse, pop up the keyring input, cause the modal dialog to open [06:18] and then switch focus to something else [06:18] and then BACK to seahorse [06:18] will break [06:18] (or at least, it does on g-s [06:18] lets try metacity ... [06:19] oh huh [06:20] interesting it doesn't re-grab if you move focus away with metacity [06:20] interesting :) [06:36] hey smspilla1 given we are so close to final freeze, we kind of need a fix for this. Maybe not ideal, but something. What would be possible to make it work even if the app is "being stupid" [06:36] ? [06:37] jasoncwarner_: I am looking into that now [06:37] jasoncwarner_: you can't forcibly release grabs, so we need to patch the application [06:37] smspilla1: ok...and I assume you are looking at how to patch the application (when you say you are "looking into it")? :) [06:38] yes === smspilla1 is now known as smspillaz [06:38] smspillaz: sweet!, thanks dude ! [06:38] np [06:38] PERTH FTW! [06:38] not really [06:38] perth is a pretty miserable city [06:38] better than adelaide though [06:39] whatever, everyone I know from perth is like "perth is awesome" and "adelaide is stupid" and "math is hard, let's go shopping". [06:39] hmm [06:39] there are three parts to that statement which are true [06:40] wait a minute ;) [07:05] The last post on ubuntu-devel-discuss is funny.. The funniest part? I pressed Super-R and I can't unzoom. ;> [07:09] BigWhale: hm, I think there was a trick with Super+Scrollwheel or so [07:09] but indeed that doesn't work now [07:10] a second super+r works, though [07:10] not very reliably so, though [07:18] didrocks: ok, I can see whats going on now [07:18] (which explains why it is broken under g-s too) [07:18] BigWhale: pitti: I removed Super-R anyway in the incoming upload :) [07:18] pitti, I disabled the Enhanced zoom plugin in CCSM ... [07:19] (I often use 16 ton hammers to kill mosquitoes ...) [07:19] didrocks: aka the "trap" key? :-) [07:19] it checks when the window state changes and regrabs the keyboard based on that. And because we added _NET_WM_STATE_FOCUSED it will re-grab the keyboard when NET_WM_STATE_FOCUSED is added to _NET_WM_STATE and the window is not Withdrawn, Iconified or _NET_WM_STATE_FULLSCREEN or _NET_WM_STATE_MAXIMIZED [07:19] didrocks: oh, new compiz coming today? [07:19] pitti: indeed :-) was removed as a distro patch in the past, but well, as all our patches were removed by upstream when they bundled it… [07:19] so I think I just need to patch it to store when it was maximized or withdrawn / iconified / whatever [07:19] pitti: yeah, the one from the ppa [07:20] didrocks: nice [07:20] pitti: + the keybinding changes [07:20] that's running nicely here [07:20] smspillaz: ok ;) [07:20] didrocks: ah, I lost track of all the FFEs; I'll just let myself surprise which keys break this time :) [07:21] heh ;) [07:36] didrocks: fixed [07:36] didrocks: do you want me to just submit the patch upstream ? [07:36] smspillaz: nice! yes please ;) [07:36] and give your the b.g.o link ? [07:37] right ;) [07:37] smspillaz: I guess we'll chceck with him before pushing that to the distro :) [07:37] yeah the patch is a bit ugly but I can't think of a "proper" way to do it that doesn't involve subclassing GtkWindow really [07:38] let's see with upstream ;) [07:41] hey [07:42] hey seb128 [07:42] seb128: I've fixed the gnome-keyring issue you had [07:42] seb128: its a bug in gnome-keyring, so I am making a distro patch as the relevant code no longer exists upstream [07:42] smspillaz, hey, you rock, thanks a lot for taking some time to look at it [07:42] anything to avoid white windows [07:42] I mean [07:42] what ? [07:42] smspillaz, ok, just give me the diff and I will handle the packaging [07:42] okay [07:43] seb128: I can make an mp into it, its cool [07:43] smspillaz, your call, I'm happy to take it from there but I'm happy to review a merge request as well [07:48] salut seb128 ;) [07:49] bonjour seb128 [07:49] hey didrocks, pitti [07:49] how are you? [07:49] I'm fine, thanks. Yourself? [07:50] I'm good thanks [07:50] robert_ancell, hey! [07:50] seb128: for bug 969569, I agree with chrisccoulson that we should not migrate theme settings from gconf; themes completely changed, we don't have clearlooks etc. any more. WDYT? [07:50] Launchpad bug 969569 in gsettings-desktop-schemas "lucid to precise: Ugly desktop after upgrade" [Critical,Triaged] https://launchpad.net/bugs/969569 [07:50] hello [07:50] seb128: https://code.launchpad.net/~smspillaz/gnome-keyring/gnome-keyring.fix_931958/+merge/100563 [07:50] hey robert_ancell, howdy? [07:50] robert_ancell, how are you? if the european start talking it's time to call it a day? ;-) [07:50] I reckon! [07:50] robert_ancell, do you have a minute to talk lightdm, bugs, release and precise? ;-) [07:50] smspillaz, thanks, on it [07:51] I had to head out this afternoon so staying a little later. [07:51] yes [07:51] robert_ancell, what bugs do you have still on your list for precise? [07:52] robert_ancell, I've those on my list [07:52] bug #951597 [07:52] Launchpad bug 951597 in lightdm "1.1.7 : breaks xsession-errors, no more rotated" [High,Triaged] https://launchpad.net/bugs/951597 [07:52] bug #952185 [07:52] Launchpad bug 952185 in lightdm "~/.pam_environment not parsed when HOME is encrypted" [High,Triaged] https://launchpad.net/bugs/952185 [07:52] bug #956848 [07:52] Launchpad bug 956848 in lightdm "pam_mkhomedir.so fails to create homedir in precise" [High,In progress] https://launchpad.net/bugs/956848 [07:52] [07:52] seb128, bug 956848 and bug 951597 but I also need to have a look at bug 952185 [07:52] robert_ancell, does that seems right? [07:52] ok, good [07:52] we are in sync it seems ;-) [07:53] robert_ancell, did you make any progress on the .xsession-errors rotation one? it's impacting on debugging of other bugs so I'm eager to see it resolved ... anything I can do to help? [07:53] seb128, provide a patch ;) [07:53] seb128, no, still working on it [07:53] robert_ancell, lol, rrrrright ;-) [07:54] robert_ancell: bug 878184 as well? that looks like it's got a branch ready for merging? [07:54] Launchpad bug 878184 in unity-greeter "Onscreen Keyboard cannot be used to input password in unity-greeter" [High,In progress] https://launchpad.net/bugs/878184 [07:54] hey guys, what do you think might be responsible for reintroducing bug 878492 ? [07:54] Launchpad bug 878492 in unity-2d "Keyboard shortcut - F10 shortcut is used to show menu and this is wrong" [High,Confirmed] https://launchpad.net/bugs/878492 [07:54] * smspillaz starts sending email to himself [07:55] pitti, that's commit to unity-greeter trunk for some weeks [07:55] commited [07:55] ah, good [07:55] we can confirm gtk apps are affected (but also in gnome-shell, so...) [07:55] pitti, as seb said [07:55] Saviq, try asking on #ubuntu-unity [07:56] robert_ancell, pitti: speaking of unity-greeter I was waiting on an extra fix to land and I wanted to ping mterry about doing a release for it [07:56] seb128, have you happened to hear from mterry about the much duplicated u-g crash? [07:56] robert_ancell, which one? speaking of segfault, bug #902698 still gets duplicates [07:56] Launchpad bug 902698 in lightdm "lightdm crashed with SIGSEGV in check_stopped()" [High,Triaged] https://launchpad.net/bugs/902698 [07:56] bug #946674 [07:56] Launchpad bug 946674 in unity-greeter "unity-greeter crashed with SIGSEGV in background_loader_ready_cb()" [Medium,Confirmed] https://launchpad.net/bugs/946674 [07:57] I'll assign it to him [07:57] I saw an indication it might have been due to the glib upgrade [07:57] robert_ancell, I didn't have it on my list but I will check with him today [07:57] have been uncovered that is [07:59] seb128, btw, do you have any opinion on the libgnomekbd/accountsservice we are running? I had a look at merges for them but they were non-trivial. Don't know if we're missing out on any important bug fixes though [07:59] robert_ancell, they are good, I think we can sync libgnomekbd from Debian, I meant to ask pitti about that since he's the one who worked on that package the most recently [08:00] robert_ancell, accountsservice, upstream went crazy, we should stay on our version [08:00] oh and libpeas was the same [08:00] we can probably just get the new version of this one [08:00] it has quite some changes, and some important apps depend on it so I wasn't sure [08:00] well if we have no issue with the current version we can as well being conservative [08:00] robert_ancell, btw thanks for breaking shotwell yesterday :p [08:00] seb128, also, I looked at aisleriot - it seems to build fine in precise, not sure why we never took it [08:01] seb128, say what? [08:01] seb128, well that's ok then - you broke webkit :) [08:01] robert_ancell, gexiv 0.4.1 changed soname, you overlooked it seems, you didn't rename the binary and shotwell was bailing out on a missing lib [08:01] ech [08:01] like ld missing [08:01] robert_ancell, well at least mine didn't break users :p [08:02] robert_ancell, but thanks for catching that ;-) [08:02] seb128, whoops. We really need to automate that better... [08:02] robert_ancell, aisleriot -> jbicha has been looking at it [08:02] I will check with him [08:02] robert_ancell, well lintian warns you, we need to print lintian warnings in red ;-) [08:03] robert_ancell, pitti: ok, btw something that might make you happy, mpt suggested we should drop lpi [08:03] discussion for UDS [08:03] seb128, it would save us a lot of time [08:03] seb128, do we have any metrics on how useful it is? [08:03] robert_ancell, right, and it's limited to some apps and a bit geeky [08:04] robert_ancell, mpt seems to think it's a geek stuff, the answer tracker got superseeded by askubuntu, we hid the bug stuff in release and access to translations are not stuff normal users are interested in finding in their apps [08:05] robert_ancell, not sure we have any metrics, that's why I still want a discussion at UDS [08:05] but yeah, I doubt it's very useful for users [08:05] seb128, I'd be happy to just notify the list, drop it and then see what happens [08:06] we can put the patches back quickly if there is a problem [08:07] robert_ancell, right, I might just mention put a "review delta with upstream and Debian" session for UDS to go through stuff like lpi and control center crazyness and see what we do [08:07] yeah [08:07] it's not worth a whole session [08:07] well, one hour to cover the different topics and maybe worflow etc [08:07] desktop status update or something [08:07] or checkpoint [08:08] seb128, I'd like to tackle UDD again - we need to get to one method of updating packages [08:08] right, I've the feeling it's not getting any better [08:08] not sure how much UDD is being worked on [08:09] like the gvfs import is always outdated and broken and doing those updates a pain still [08:09] seb128, yeah, if we go full UDD it has to be foolproof [08:09] seb128, the packaging branches work really well, but they have permission issues and issues with people uploading without updating [08:10] the full branches have the easily broken issue as you point out [08:10] no branches is a huge waste of time [08:10] seb128: ooh [08:10] seb128: I'll look at libgnomekbd (remaining delta/sync) [08:10] pitti, thanks [08:11] seb128: sorry, was stuck in mutt for a bit [08:11] robert_ancell, my gut feeling is that debian only dirs are still the less painfull for what we do [08:11] jasoncwarner_, ^ perhaps this is something you can negotiate with the LP people. Packaging is a big timesink for us, and if they can get UDD in an awesome state we would save a lot of time (=$) [08:11] but yeah [08:11] jasoncwarner_, ^ that would be great ;-) [08:12] I have an idea [08:12] how about we invent a command that directly fetches the source from the archive? [08:12] that will _always_ give us the correct version! [08:12] * pitti ducks [08:13] pitti, the problem is not getting the correct version - the problem is how to update it in an easy manner that provides good visibility of the changes and a better way of annotating what has changed [08:13] robert_ancell: yes, I know [08:14] robert_ancell: from my POV, people keep screwing up the pre-applied patches [08:14] including me [08:14] this is the single biggest itch I have with those [08:14] I already set [08:14] quilt-commit-policy = applied [08:14] quilt-tree-policy = unapplied [08:14] but that doesn't help [08:15] my other itch is that UDD fixes the exactly wrong problem [08:15] we don't need the upstream bits in bzr, we need our changes in bzr [08:15] then you get the branches that always get outdated for some reason [08:15] but our changes are precisely the ones which are not covered by real revision control, but are stuck in quilt patches [08:15] i.e gvfs currently [08:16] that too, but that only affects some packages [08:16] a lot got broken with the .xz switch, I think [08:16] I'm probably not lucky, I've that every second time I try to deal with a GNOME update in UDD [08:16] could be [08:16] I had used UDD for gvfs until it broke [08:16] since then, classic apt-get soruce and uupdate.. [08:17] yeah [08:18] yep, libgnomekbd is syncable, doing [08:18] ok, later guys [08:18] robert_ancell: good night! [08:19] seb128: for bug 969569, I agree with chrisccoulson that we should not migrate theme settings from gconf; themes completely changed, we don't have clearlooks etc. any more. WDYT? [08:19] Launchpad bug 969569 in gsettings-desktop-schemas "lucid to precise: Ugly desktop after upgrade" [Critical,Triaged] https://launchpad.net/bugs/969569 [08:19] pitti, oh sorry forgot to reply to that while catching up with robert ;-) [08:19] seb128: that's fine; I figured you'd rather use the time to talk to Robert [08:19] I can annoy you all day :) [08:19] pitti, I'm fine not migrating the theme, wasn't that distro patch we added? I think upstream doesn't migrate theme, not even the background image [08:20] but +1 from we for the reasons you listed [08:20] we->me [08:21] seb128: ok, so we all agree; I'll have a look at this then [08:21] seb128: migrating bg image is still fine IMHO [08:21] pitti, the main reason I wanted the migration is that users running the light theme would still get it after upgrade [08:22] seb128: yeah, I know, but I don't think we can do a conditional migration that way :/ [08:22] pitti, http://launchpadlibrarian.net/80328425/gsettings-desktop-schemas_3.1.91-0ubuntu1_3.1.92-0ubuntu1.diff.gz [08:22] we could add some additional code [08:22] yeah, too late for conditional migration :/ [08:22] pitti, just drop dont_reset_themes.patch [08:22] pitti, not sure if we want to keep the colors and fonts though [08:23] I'll be conservative and only drop themes [08:23] fonts are fine [08:23] ok [08:23] colors also didn't disappear [08:23] seb128: I'll merge with Debian while I'm at it [08:23] pitti, thanks [08:24] pitti, btw you reintroduce the glib patch for non multiarch gio dir compat when you merged, was that wanted? [08:24] seb128: it seemed harmless, and not a bad idea for third-party apps, and reduced the delta [08:24] seb128: do you see a reason to not have it? [08:24] does it cause error messages or something/ [08:25] ? [08:25] pitti, it breaks multiarch, image you have an amd64 install and a leftover x86 binary in the non multiarch dir [08:25] pitti, also it creates confusing leading people to think they can,should use that dir [08:25] pitti, no big deal but desrt pushed for having it dropped before the lts [08:26] how would you have a i386 binary in the non-multiarch path of an amd64 system? [08:26] seb128: ok, I'm fine with dropping it again; I did not have a strong reason for keeping it [08:26] pitti, because you pull in an i386 binary still installing a .so there? [08:26] pitti, but yeah maybe in practice that doesn't happen [08:26] it's just that it's a bit less "clean" and it might lead to confusion to still have that dir listed [08:27] seb128: ah -- if we have such packages still, then the amd64 package would not work any more if we drop it [08:27] ("not a bad idea for third-party apps") [08:27] pitti, no need of an upload for that, I just wanted to check before dropping it, I will drop it again in the next upload then [08:27] seb128: ok; I have no objections to dropping it again [08:27] pitti, we have nothing in the archive still using the compat dir no [08:27] so it's all theoritically and third party discussion ;-) [08:27] pitti, thanks [08:28] (I would argue that Debian should drop it as well btw) [08:33] zgrep usr/lib/gio /tmp/Contents-i386.gz [08:33] seb128: indeed, Debian doesn't have the old paths any more either; I'll commit that [08:33] pitti, thanks [08:33] so we are still at "no ubuntu diff after LTS" :) [08:33] ;-) [08:35] seb128: done [08:35] pitti, danke [08:37] does anyone know if there is a "reverse that diff" utility? [08:39] good morning everyone [08:40] seb128: I looked for such one the other day, didn't really find after 5 minutes of looking around [08:40] chrisccoulson: hey, how are you? [08:40] hey chrisccoulson, how are you? [08:40] didrocks, ok, me neither [08:41] hi seb128, didrocks. i'm good thanks, how are you? [08:41] interdiff can do it [08:41] chrisccoulson, I'm good thanks [08:41] chrisccoulson: I'm fine, thanks :) [08:41] Laney, " To reverse a patch, use /dev/null for diff2." [08:41] oh, nice [08:41] seb128: interdiff foo. [08:41] yes [08:41] Laney, thanks! [08:41] :P === BruceBanner is now known as seif [09:33] seb128: so, I guess we can just as well keep the patch [09:33] as it behaves well if the .so is of the wrong arch [09:33] but not very important either way then [09:34] pitti, right, I might still drop it from precise let's see, I read the discussion on #debian-gnome [09:34] it just feels wrong keeping compat for an old dir we don't use which can create confusion [09:35] I would prefer the lts to clearly have one clear dir to use and message it correctly [09:35] though it's a detail at the end [09:39] I think it's taking me longer to port photobomb to using gir than it took me to write it in the first place :/ [09:45] nobody reminded me about the meeting reminder! [09:45] oh! [09:45] pitti, remember the meeting reminder! [09:45] pitti: I do not see anything obviously wrong on bug #970939, seems pygi or python though? [09:45] and don't do anything like script a cron job, or put an alert in a calendar! [09:45] [09:46] * rickspencer3 is desperate for a break from gi.repository tedium [09:46] rickspencer3: nah, that'd take all the fun out of it [09:46] didrocks: will look in a sec [09:47] hmm, after reading last week's gtimelog I did nothing but bug fixing [09:47] seems for the first time in years I have nothing interesting to put on the weekly report.. [09:48] pitti, doh, meeting reminder! [09:48] pitti: don't read the meeting reminer btw, you will get spoiled with the new key changes :) [09:49] (once I would write it) [09:49] didrocks: you mean the new report? [09:49] yeah, the incoming report :) [09:53] didrocks: yeah, not a very useful stack trace; that needs a reproducer [09:54] pitti: ok, affecting python-gobject + incomplete? [09:54] I can't tell from the trace [09:54] could be a wrong annotation in a library [09:54] that's the most likely reason [09:55] just putting it as incomplete for now then, sticking in oneconf if you want even if that's not the real component [09:56]