[00:18] <TheMuso> psusi: ah ok
[00:26] <psusi> TheMuso, so umm... what exactly does that patch fix?
[00:27] <TheMuso> psusi: I'd have to read the patch again to clearly remember... One of my first changelog entries for parted should explain it.
[00:38] <psusi> TheMuso, the description in the changelog says " dmraid.patch: Ensure that device-mapper devices for dmraid arrays do not have extra nodes created needlessly, as well as making sure that partition nodes for dmraid devices are not probed."  I can't figure that out.  What nodes were being created under what conditions?
[00:40] <TheMuso> psusi: At the time, every dmraid device node that was created that parted dealt with, had additional nodes created to represent partitions, I think. This code was written over 3 years ago, so of course things may have changed. I understood why at the time. :)
[00:40] <TheMuso> psusi: I guess the best experiment is to take out my patch, play with dmraid stuff and parted, and see what happens.
[01:16] <psusi> TheMuso, k.. guess I'll try that...
[01:18] <TheMuso> If I continued dmraid related code maintenance, I'm sure I'd still know. I think that a ${node}p1 node was being created for every dmraid related node at the time, including partitino nodes, which is why the patch also stops dmraid partition nodes from beinb probed.
[01:18] <TheMuso> Now that I think, it was to do with probing. For some reason parted thought that every dmraid node had a partition table of some kind... beats me why
[01:20] <psusi> hrm... now this is weird... gnome-power-manager is running, but doesn't seem to actually be used.. it looks like we use upowerd to suspend, so what the heck is gnome-power-manager doing?
[01:25] <RAOF> Display blanking, automated “suspend when low battery” stuff?
[01:50] <psusi> RAOF, doesn't appear to be.. looks like upower is doing that these days... which explains bug #578542
[01:51] <psusi> I sent g-p-m a SIGSTOP and clicked suspend on the menu and it worked normally
[01:53] <RAOF> psusi: That's orthogonal to what I said.  That's neither ‘suspend when battery low’ nor ‘dim screen on inactivity’. :)
[01:55] <RAOF> Those are policy decisions rather than implementation methods.
[02:05] <psusi> ahh...
[02:06] <psusi> so where is the darn screen saver being started and the screen locked?  hrm...
[02:32] <psusi> hrm.. can you use dbus-send to manually emit an org.freedesktop.UPower signal?
[02:32] <psusi> or better yet, find out what is listening for that signal?
[02:45] <RAOF> psusi: I don't think you can track what's listening to the signal.  I think dbus-send should be able to fanangle a signal for you, though.
[02:47] <psusi> RAOF, I thought so but I can't seem to figure it out... I don't quite understand the arguments it wants, specifically what the difference is between --dest=, <destination object path> and <message name>..
[02:48] <RAOF> Heh.
[02:48] <RAOF> Say hello to DBus!
[02:48] <RAOF> --dest= is the *interface* that the signal you want to send is from.
[02:49] <RAOF> Oooh, actually, no.
[02:49] <RAOF> You shouldn't need --dest, because you're not sending it anywhere specific.
[02:50] <RAOF> <destination object path> should be the object path of the object you want to raise the signal _on_
[02:51] <RAOF> <message name> should be the signal you want to raise, namely the fully-qualified signal from the interface (org.freedesktop.UPower.$INTERFACE.$SIGNAL)
[02:51] <psusi> so org/freedesktop/UPower and org.freedesktop.UPower.Sleeping?
[02:51] <psusi> err, what's $INTERFACE?
[02:52] <RAOF> Sounds like $INTERFACE is ""
[02:52] <RAOF> So you'd want to send org.freedesktop.UPower.Sleeping
[02:53] <RAOF> But if UPower had multiple interfaces (o.f.UPower.Bar.Sleeping, o.f.UPower.Baz.Sleeping, for example) you'd stick in the fully qualified thingy.
[02:53] <psusi> process 19675: arguments to dbus_message_new_signal() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1289.
[02:58] <RAOF> Sounds like you've got the wrong object path?
[02:59]  * RAOF fires up d-feet
[02:59] <psusi> d-feet?
[03:00] <RAOF> …and immediately notices he doesn't have a UPower interface.
[03:00] <RAOF> Oh, man.  You're debugging DBus issues and you don't know about d-feet?  Sorry!
[03:01] <RAOF> It's a DBus browser.  It can't raise signals, but it does enumerate the bus and such.
[03:01] <RAOF> Oh, of course.  It's on the system bus.
[03:05] <RAOF> So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me.
[03:05] <RAOF> So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me.
[03:09] <psusi> DOH!
[03:09] <psusi> I wasn't using the leading / before org
[03:12] <RAOF> It also doesn't trigger anything obvious for me :)
[03:13] <psusi> me neither... hrm...
[03:13] <psusi> so there's no way to monitor who is interested in the signal?
[03:20] <psusi> hrm... this doesn't seem to do anything either: dbus-send --type=method_call --dest=org.freedesktop.UPower --system /org/freedeskop/UPower org.freedesktop.UPower.Suspend
[03:25] <RAOF> Wheras that was very happy to suspend my system.
[03:25] <RAOF> And, of course, did not result in gnome-screensaver coming back with a screen lock.
[03:26] <psusi> hrm.. it works when I use d-feet to call it and yea, doesn't lock the screen
[03:26] <psusi> hrm...
[03:32] <RAOF> In hindsight, I knew that; I needed to fix a bug where Do wouldn't lock the screen before suspend because it was calling UPower directly.
[03:32] <psusi> so what on earth DOES lock the screen?
[03:44] <RAOF> Well, in Do we call out to gnome-screensaver ourselves.
[04:01] <psusi> bingo... indicator-session... session-service.c:machine_sleep()
[04:02] <psusi> now I wonder why the gconf key for g-p-m to lock or not is still there when it doesn't handle that function?  hrm..
[06:09] <abhinav_> is there a command to delete a branch from the repository ?
[06:09] <abhinav_> in bazaar
[06:10] <RAOF> rm -r?
[06:11] <abhinav_> so bazaar will know that the branch is gone, if I do that ?
[06:11] <RAOF> Yes.
[06:11] <abhinav_> oh ok. thanks
[06:11] <RAOF> * For some values of “yes”.
[06:12] <RAOF> What exactly do you want to do?  Free disk space?  Strip out some unwanted stuff from a repository?  Clean your source trees?
[06:13] <abhinav_> yeah. I was experimenting something in a branch. I do not want to merge those changes,
[06:14] <RAOF> Oh.  Then just don't merge those changes :)
[06:14] <nigelb> lol, rm -r
[06:15] <abhinav_> yeah, but that branch is pretty useless now. deleting it should not be any harm ?
[06:15] <RAOF> The repository is just a performance optimisation.  It doesn't actually have any semantic meaning.
[06:16] <RAOF> So, while those commits will remain in your local repository, they won't get pushed anywhere (unless you push something that refers to them, but you'd need to merge them for that to happen).
[06:16] <RAOF> Your local repository will be a couple of KB larger than it would otherwise be :)
[06:16] <abhinav_> ah ok. that's fine :)
[06:17] <RAOF> Mmmm, “About 8 hours remaining”.  dpkg really, really likes unpacking onto btrfs, doesn't it :)
[08:04] <abhinav_> why does dch -i add maverick at the top of the changelog entry, even though I am working on natty package ?
[08:04] <dholbach> good morning
[08:04] <abhinav_> good morning :)
[08:05] <micahg> abhinav_: you can pass -Dnatty to work on a natty package (I'm assuming you're on maverick)
[08:05] <abhinav_> yes, I am on maverick
[08:08] <abhinav_> I have already saved the changelog. I suppose I can edit it and write natty instead of maverick.
[08:10] <micahg> abhinav_: yeah, if you start with UNRELEASED, you can use -D to add the series later, but now you'll have to just edit it
[08:10] <abhinav_> ok thanks :-)
[08:13] <abhinav_> well actually I am working on a bug fix of tomcat6, as I see in the changelog, all the entries say "unstable" instead of maverick or natty
[08:13] <micahg> abhinav_: that's because it comes from Debian
[08:13] <abhinav_> ohsix, so I should write unstable too ?
[08:14] <abhinav_> *sorry
[08:14] <micahg> abhinav_: no
[08:14] <ohsix> tell debian about it,  no?
[08:15] <micahg> well, the patch should be upstreamed to Debian if appropriate, but that's another question :)
[08:16] <ohsix> i can never remember if unstable or testing is the one to expect breakage
[08:16] <ohsix> (lots of, not some)
[08:16] <abhinav_> hmm , I have the patch ready :-), Its my first bug-fix, so I have not much idea about the process
[08:16] <abhinav_> but the package is tomcat6-6.0.28, I believe same is available in maverick repositories
[08:17] <micahg> abhinav_: https://wiki.ubuntu.com/SponsorshipProcess
[08:37] <zanaga> what is the correct way of requesting a sync from debian that replaces a package from a different source? I just want to get this stuff filed for the next release cycle.. Regarding LP#378240
[08:56] <pitti> Good morning
[08:56] <pitti> slangasek: sure, no prob
[09:42]  * SpamapS_ gulps
[09:42] <SpamapS_> 933 upgraded, 66 newly installed, 1 to remove and 1 not upgraded.
[09:42] <SpamapS_> Need to get 977 MB/977 MB of archives.
[09:42]  * SpamapS answers yes... here we go!
[09:51] <pitti> slangasek: gtk 2 uploaded
[10:11] <abhinav_> where can I get some help on gtk# ?
[10:17] <RAOF> abhinav_: #mono on gimpnet is a reasonable place for gtk# help.
[10:18] <abhinav_> RAOF: thanks. I will ping there :)
[10:18] <RAOF> abhinav_: But mainly what I use is the python & C gtk doc; gtk# is a fairly obvious translation to C#.  Code-completion helps, too :)
[10:19] <abhinav_> yes, I don't know. I need some help with the TreeView, but the functionality that I am looking for does not seem to be available as per the documentation
[10:30] <dpm> hey mvo, good morning. A translator has found some encoding problems in apt translations in Launchpad. Before I can help him I wanted to ask you: how are apt translations handled? Are translations from LP ever exported and committed to the code, or do translations come exclusively from upstream in Debian?
[10:31] <kirkland`> didrocks: hi
[10:31] <kirkland`> didrocks: how do i make the unity search thing look for stuff in my $HOME/bin?
[10:32] <didrocks> kirkland: hey, the search is only based on desktop files
[10:32] <didrocks> so put a desktop file in your XDG path
[10:32] <kirkland> didrocks: dang
[10:32] <didrocks> we'll have an alt + F2 soon
[10:32] <kirkland> didrocks: i just want to run a wrapper script
[10:32] <soren> \o/
[10:32] <kirkland> didrocks: like i used to do with alt-F2
[10:32]  * soren misses Alt-F2
[10:33] <kirkland> didrocks: oh, okay, as long as alt-f2 comes back, that'll be fine
[10:33] <didrocks> kirkland: you'll have one if I find the time to code it :)
[10:33] <didrocks> yeah
[10:33] <kirkland> didrocks: cool, thanks
[10:33] <didrocks> yw :)
[10:33] <nigelb> bdrung_: Thought you might have liked to see http://stopabusingsiprefixes.org/stopabusing.html
[10:33] <kirkland> didrocks: if you're writing this, could you make sure that the alt-f2 path contains $HOME/bin?
[10:34] <nigelb> Ubuntu is lame.
[10:34] <nigelb> Maybe, but at least they have a sensible units policy.
[10:34] <didrocks> kirkland: it will respect the PATH
[10:34] <nigelb> bdrung_: direct quote ^^
[10:34] <didrocks> sounds less hackish :)
[10:35] <mvo> dpm: they come exclusively from upstream
[10:36] <mvo> dpm: what language(s) are affected?
[10:36] <bdrung_> nigelb: :) sadly the upstream authors with power refuse to do something regarding this bikeshed topic
[10:36] <kirkland> didrocks: okay
[10:36] <nigelb> bdrung_: oh, ouch :(
[10:37] <bdrung_> nigelb: https://bugzilla.gnome.org/show_bug.cgi?id=640432
[10:37] <dpm> mvo, thanks for confirming. Slovenian: look at the squares in the suggestions on https://translations.launchpad.net/ubuntu/natty/+source/apt/+pots/apt-all/sl/+translate (note that the translators have already corrected it in LP) - due to message sharing, I'm not sure if these translations were imported from a natty, lucid or maverick upload
[10:38] <nigelb> bdrung_: oh dear.  Its bad when someone says, "flame" in the beginning of the bug
[10:39] <mvo> dpm: thanks, I check it ou
[10:39] <mvo> t
[10:40] <dpm> thanks :)
[11:23] <dpm> mvo, it's translations questions day today! :-) Here's another one: do you happen to know who handles translations for gdebi, and how/where they are done?
[11:24] <mdz> pitti, is there a problem with the retracer? I'm seeing 16-hour-old bugs like 730243 are not retraced yet
[11:30] <mdz> dbarth, I noticed the above because I got a compiz crash and saw there were plenty of others coming in like it (unity-window-decorator crashed with SIGSEGV in g_closure_invoke())
[11:31] <dbarth> mdz: the decorator issue is on our radar
[11:32] <dbarth> mdz: smpillaz has made more fixes for it, and i'm seeing with didrocks when he can release that
[11:33] <mdz> dbarth, ok
[11:34] <seb128> mdz, let me check on the retracers
[11:39] <seb128> mdz, the amd64 had a lock set but was not running, the log had no error though so I just restarted it to see
[11:39] <mdz> seb128, ok, thanks
[11:40] <seb128> mdz, you're welcome
[11:40] <mdz> seb128, did you see the new global bugpatterns code which is now in natty? you can write bug patterns which are not specific to a package, e.g. to catch crashes from a library which bubble up to many different apps
[11:44] <seb128> mdz, no I didn't see it before and I didn't realize that matching was specific to components
[11:45] <mdz> seb128, in the past, you had to put bug patterns into a file named after the package, and we would only check for patterns which applied to the package where the bug was being reported
[11:45] <mdz> so if you had a libdbusmenu bug which caused crashes in gnome-terminal and nautilus, you would have to add separate bugpatterns for those (and any other app using libdbusmenu)
[11:46] <mdz> now you can just write one which will (e.g.) match on the stack trace, regardless of which program crashed
[11:51] <seb128> mdz, ok, I thought we had a pattern for this XAllocId ret != invalid crash for example
[11:51] <seb128> but that's might be why it didn't seem to work ;-)
[11:51] <seb128> mdz, thanks for working on that
[11:52] <seb128> mdz, btw your bug got retraced
[11:52] <mdz> seb128, in some places we suppressed the bugs in other ways, e.g. in a general hook or in apt
[11:52] <mdz> seb128, I'm not familiar with the XAllocId issue and I don't see that string in the existing bug patterns; is it an active problem?
[11:52] <mdz> maybe it would be a good test case :-)
[11:59] <seb128> mdz,
[11:59] <seb128> <!-- Converted from libxcb.xml -->
[11:59] <seb128>     <pattern url="http://launchpad.net/bugs/507062">
[11:59] <seb128>         <re key="AssertionMessage">_XAllocID:.*ret.*inval_id</re>
[11:59] <seb128> mdz, I was speaking about this one
[11:59] <cjwatson> on merges.ubuntu.com: I've tracked down what was causing the failure, prepared a backport of the relevant dpkg fix, and filed a ticket for our sysadmins to deploy that
[12:00] <cjwatson> there may still be some work needed to avoid it running out of disk during the next run
[12:00] <mdz> seb128, ah, I should have searched with -i. ;-)
[12:00] <mdz> seb128, so that pattern will only get checked for bugs which are about to be reported on libxcb
[12:00] <cjwatson> (Debian #594440 bit our eucalyptus package)
[12:01] <seb128> mdz, ok, that explains why we keep getting bugs reported against random binaries crashing this way
[12:01] <mdz> seb128, er...actually pitti converted it to be package-independent already :-)
[12:02] <pitti> mdz: retracers> checking; they crash very often these days
[12:03] <mdz> pitti, I did the bugpatterns conversion based on r178, and there was no libxcb.xml in that version. did I make a bad merge or something?
[12:03] <seb128> pitti, I sorted the retracers
[12:03] <mdz> I don't see a mention of libxcb in the commit log, other than yours...
[12:03] <pitti> mdz: I guess it was PEBCAK on my end, and I forgot to bzr add back then
[12:03] <seb128> pitti, it's weird, it had a lock from yesterday and no error in the log
[12:04] <seb128> pitti, removed the lock and it's fine
[12:04] <pitti> seb128: amd64 is running, but i386 is locked and not running
[12:04] <seb128> it's running
[12:04] <debfx> cjwatson: on the weekend I painfully noticed that all kde-l10n-* packages are also missing from the kubuntu package set
[12:04] <pitti> seb128: i386? I don't see it running
[12:04] <seb128> pitti, ok, it might have had the same issue, the log had been updated recently when I checked on i386
[12:04] <seb128> pitti, no, the timestamp was recent on i386
[12:04] <debfx> cjwatson: I'd really appreciate if you could add them and the ones I emailed you
[12:04]  * pitti starts manually and checks
[12:05] <seb128> amd64 was from yesterday and I restarted it
[12:05] <seb128> which worked
[12:05] <pitti> seb128: bah, same "huge wadl HTML output spew" issue :/
[12:06] <pitti> cache purged, restarted
[12:07] <seb128> pitti, danke
[12:11] <artfwo> seb128, I noticed you've just made bug 730528 affect libappindicator, but https://bugs.launchpad.net/libappindicator page is empty and states that libappindicator is not configured in order for Launchpad - how's that?
[12:11] <seb128> artfwo, I guess they didn't create a new component out of indicator-application when the source was splitted out
[12:12] <seb128> artfwo, I basically just said "also affect component" and used what was suggested
[12:12] <artfwo> ah, I see
[12:12] <artfwo> thanks
[12:12] <seb128> artfwo, I will check with kenvandine and ted if libappindicator should work as a project or if they want to use indicator-application
[12:13] <artfwo> seb128, until than is it okay to use "also affects libappindicator" for upstream related bugs?
[12:13] <artfwo> s/than/then
[12:13] <seb128> it's fine, either libappindicator or indicator-application
[12:13] <seb128> both will reach the same people
[12:19] <cjwatson> debfx: I've done the ones you mailed me, but hmm, making a wildcard exception isn't supported by my current code AFAIK
[12:19] <cjwatson> and there's no way I'm maintaining that package list by hand
[12:28] <cjwatson> debfx: I think this is a matter for fixing the code that generates the package sets, not for making exceptions
[12:29] <cjwatson> (it's my problem either way, but just to let you know)
[12:39] <lamont> how does one reset the password on the gnome keyring?  wifely one is annoyed at the computer today
[12:41] <debfx> cjwatson: ok
[12:43] <seb128> lamont, reset?
[12:43] <lamont> change
[12:44] <seb128> you mean the password to unlock the keyring?
[12:44] <seb128> you can do that using seahorse
[12:45] <seb128> but it's the same as your login one by default and should be updated when passdw is used to change it
[12:51] <lamont> ah, ok.
[12:51] <lamont> that now all makes sense
[12:52] <lamont> OTOH, password is coming from libnss-db, not via passwd command. so seahorse to change it is the right way, yes?
[13:01] <cjwatson> debfx: fixed now, along with everything else in your supported seed
[13:26] <cnd> do I need to request for an archive admin to review a package in the new queue, or will that be done automatically?
[13:27] <debfx> cjwatson: that was fast, thanks
[13:41] <cjwatson> cnd: you only need to request if you have a good reason to want to jump the queue
[13:41] <cnd> cjwatson, ok, I assume it will be handled in due time then
[13:41] <cnd> thanks
[14:07] <chrisccoulson> @pilot in
[14:07] <chrisccoulson> \o/
[14:10] <pitti> chrisccoulson: happy piloting
[14:13] <debfx> cjwatson: I think the kubuntu mobile seed isn't part of the package set anymore
[14:15] <c2tarun> I got this error while building a package http://paste.kde.org/6690/, when looked into file I found this line creating the problem http://paste.kde.org/6689/
[14:16] <c2tarun> I need help with the second argument passed in the function, what does it mean? is it typecasting?
[14:22] <mr_pouit> c2tarun: GTK_DISABLE_DEPRECATED is set, and GtkFunction is deprecated since gtk+ 2.24.
[14:22] <cjwatson> debfx: probably not.  should it be the same set or a new one?
[14:23] <c2tarun> mr_pouit: sorry :( what does it mean?
[14:26] <debfx> cjwatson: for example plasma-mobile was in the kubuntu set before. imho it doesn't make sense to create a new one
[14:30] <cjwatson> pitti: please note my changes to bug 723016, since it looks like it was you who turned it from a merge request into a sync request
[14:31] <pitti> cjwatson: right, sorry; comment 1 seemed to indicate a sync request; reverted my changes
[14:31] <cjwatson> yeah, I think that may have been non-jargon use of "sync"
[14:48] <ari-tczew> pitti: thank you very much for sponsoring!
[14:48] <pitti> ari-tczew: you're welcome, thanks for working on the merge!
[14:48] <ari-tczew> ;-)
[14:54] <doko> mterry: would you have time on a quick component-mismatches cleanup today? would like to do that before starting the rebuild test
[14:55] <mterry> doko, I suppose?  you mean processing MIRs or something else?
[14:57] <doko> mterry: there are no MIR's yet, I assume we could hunt down tkamppeter for the printing stuff, and maybe ScottK for the perl stuff
[14:58] <mterry> doko, but yeah, I can help
[14:58] <doko> otp now, later ...
[15:00] <cjwatson> barry: FYI, I've started looking at that Wubi bug
[15:01] <cjwatson> barry: I'm wondering if the use of grub4dos-derived code here is fundamentally misguided (it's *extremely* hard to debug) - it might be simpler to arrange to load GRUB 2 from NTLDR directly
[15:03] <ari-tczew> doko: where can I find every fresh archive rebuild?
[15:07] <barry> cjwatson: sounds good.  let me know if you have something you'd like me to test.  i'm patch piloting today
[15:21] <tkamppeter> doko, what is the problem with the printing stuff?
[15:23] <doko> tkamppeter: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt  all the cmap-* stuff
[15:23] <doko> mterry: could you address the zope.fixers MIR?
[15:24] <tkamppeter> doko, do they all need to get MIRed?
[15:26] <doko> tkamppeter: yes, unless you remove them from gs-cjk-resource b-d's. or demote gs-cjk-resource
[15:26] <tkamppeter> doko, seems that these files are fonts for Ghostscript being able to display documents in CJK languages.
[15:26] <doko> tkamppeter: then please write a short MIR, and have a look at the packages
[15:27] <tkamppeter> I have MIRed gs-cjk-resource recently as I have merged GS from Debian.
[15:28] <tkamppeter> OK, Is it OK to make one MIR for all? They are pure data, so no security problems possible.
[15:30] <tkamppeter> doko: ^^
[15:31] <doko> tkamppeter: sure, as long as you review the package
[15:31] <doko> (s)
[15:32] <mterry> doko, ack re: zope.fixers
[15:33] <doko> TheMuso: you did sync libffado.  but MIR's for libconfig and dbus-c++ are missing
[15:33] <doko> mterry: thanks
[15:34] <doko> Riddell: kdesvn: kdesvn-kio-plugins libsvnqt6
[15:34] <doko>    [Reverse-Depends: kdesdk, kdesvn-kio-plugins]
[15:34] <doko> didrocks, seb128, pitti:  o libquvi: libquvi-dev libquvi-doc libquvi0
[15:34] <doko>    [Reverse-Depends: Rescued from libquvi, libquvi-dev]
[15:34] <doko>    [Reverse-Build-Depends: totem-pl-parser]
[15:34] <doko> MIR?
[15:35] <doko> I'll look at the lintian related libperl-* stuff
[15:37] <seb128> doko, bug #722591
[15:37] <seb128> ?
[15:37] <hallyn> soren: hey, my upload rights for vmbuilder are not yet in effect - would you mind uploading people.canonical.com:~serge/vm-builder_0.12.4+bzr463.tgz  ?
[15:38] <doko> oops
[15:38] <doko> seb128: well, then fix it?
[15:39] <seb128> doko, there was no review from the mir team yet
[15:39] <doko> mterry: ^^^ please?
[15:39] <seb128> doko, what needs fixing? pitti just pointed some issues but said they were not blockers
[15:39] <seb128> doko, it's assigned to kees
[15:39] <doko> ahh, ok, anyway, it's assigned to kees
[15:44] <barry> @pilot in
[15:44] <pitti> wow, three pilots?
[15:45] <barry> sure, why not? :)
[15:45] <micahg> barry: hi, can you help me with a test case for a python exception for an SRU?
[15:46] <barry> micahg: sure
[15:46] <barry> micahg: do you have an issue #?
[15:46] <micahg> barry: bug 702990
[15:46] <psusi> pitti: oh boy, I think this was your area so maybe you can help.. I've been trying to run down a bug about why the gconf keys for g-p-m to NOT lock the screen and run the screen saver no longer work.  If I understood all the code I poured through last night, it looks like gpm has had its interface for initiating suspend removed and that is now handled by UPower now, is that correct?
[15:48] <psusi> pitti: my theory is that the correct solution is to rejigger gpm to monitor the suspending signal from UPower and lock/ss if configured to do so, and the code to lock/ss needs removed from indicator-session, does that sound reasonable?
[15:49] <cjwatson> hmm,/wg 20
[15:49] <cjwatson> oops
[15:49] <barry> micahg: i'm not sure exactly what you're looking for.  a unittest for wireshark that exposes the problem?  a recipe some human could perform to show the problem has been fixed?  something else?
[15:50] <micahg> barry: idk, I'd like to SRU this so we can continue to fakesync security updates from squeeze, is something like this fragile and likely to break anything?
[15:51] <micahg> oh, there's no debdiff, let me fix that
[15:52] <barry> micahg: changing string exceptions to class exceptions can indeed break things, or it could be perfectly safe ;).  it depends on how the code uses the exceptions.  if it's primarily just raising and catching them, you should be safe.  if it does some kinds of introspection (i.e. checking the type) then you could be broken if that code wasn't also changed
[15:52] <barry> of course, as the issue points out, string exceptions could have lots of reliability problems too, if not done right
[15:52] <barry> cool.  a debdiff will help
[15:55] <ari-tczew> micahg: did you see it? bug 730413
[15:55] <micahg> ari-tczew: yes, I chatted with udienz already, thanks
[15:56]  * micahg has a little bug cleanup work later though
[15:58] <micahg> barry: diff attached
[15:59] <barry> micahg: omg.  yeah, those old string exceptions are completely broken, even in a python that supports string exceptions. :)
[16:00] <micahg> barry: so, is it possible to safely SRU?
[16:01] <barry> micahg: it's difficult to tell without a full code review.  e.g. are those string exceptions caught anywhere?  i'd be *very* surprised if the code had an 'except' that expected to catch those, 'cause it'd essentially be impossible.  i guess what i'm saying is that i can't see how the patch could make anything worse :)
[16:01] <pitti> psusi: hm, g-p-m didn't change since maverick
[16:01] <barry> micahg: is that good enough? ;)
[16:01] <pitti> psusi: but yes, I believe the "initiate suspend" etc. stuff moved to gnome-session a while ago
[16:01] <micahg> barry: umm, let's see
[16:02] <micahg> pitti: what do you think about the above wireshark SRU bug and barry's comments?
[16:03] <barry> micahg, pitti i suppose it's also possible that some code which would not otherwise catch the string exceptions, could start catching those new class exceptions.  but it seems very weird that you'd write an except clause for which you would specifically not want to catch those string exceptions.
[16:04] <barry> micahg, pitti if that makes sense. ;)
[16:04] <pitti> yes, it does
[16:04] <barry> micahg, pitti so again, short of a full code audit, it doesn't seem like this patch can make things worse
[16:04] <pitti> string exceptions are not a thing you'd ever want to catch and handle
[16:05] <barry> most definitely not, though it *was* possible if done right
[16:05] <pitti> seems okay to me
[16:06] <pitti> and it's a standalone GUI app, i. e. not something that is used as a library and needs to maintain a stable public api
[16:06] <barry> i suppose if you wanted to be really really safe, you could definite a local exception class that inherits from BaseException.  that way 'except Exception' wouldn't catch it.
[16:06] <barry> pitti: in that case, i think the patch is fine
[16:06] <micahg> pitti: so, what's the process for SRU since I don't have a test case?  the goal is to be able to continue to fakesync security updates from squeeze
[16:08] <pitti> micahg: primarily "make sure that the program still works", by running through some standard use cases with it
[16:08] <micahg> pitti: ok, can do, thansk
[16:08] <micahg> *thanks
[16:13] <psusi> pitti: yea, this has been going on at least since lucid
[16:15] <psusi> pitti: it looks like idicator-session is what provides the menu on the pannel, and that appears to lock the screen, start the screen saver, and then send the Suspend message to UPower to actually suspend the system.  I think gpm used to be the thing that supplied the Suspend method and in response, it would lock the screen if configured to do so, but it looks like since UPower was introduced, this is no longer the case
[16:17] <ari-tczew> pitti: can we drop changes with Break: udev ?
[16:17] <pitti> ari-tczew: yes, lucid's udev is much newer already
[16:17] <ari-tczew> pitti: ok thanks
[16:33] <ScottK> doko: I'm very unlikely to have time to work on MIRs this week.
[16:34] <doko> yeah, I know, trying to keep other people busy ...
[16:35] <amitk> njpatel: do you already know of a unity bug where the app panel doesn't auto disappear?
[16:36] <amitk> njpatel: and the bug where search just doesn't work?
[16:36] <njpatel> amitk, when you fullscreen? Is this on multiple monitors?
[16:36] <njpatel> amitk, re:search, do you have unity-place-files and unity-place-applications installed?
[16:37] <amitk> njpatel: yes, 2 monitors
[16:37] <njpatel> amitk, then, yeah, it's known hopefully fixed this week
[16:38] <amitk> njpatel: for some reason those two were not installed (I've been upgrading natty since alpha 2)
[16:38] <njpatel> weird :/ You'll need to restart unity after installing them (unity --replace from a terminal should do it)
[16:42] <amitk> njpatel: much better, thx
[16:42] <abhinav-> asac: http://gwibber.com/develop/ won't open ?
[16:44] <njpatel> np :)
[16:56] <SpamapS> zul: so, you're thinking the mysql maintainer scripts / upstart job need reworking, right?
[16:56] <zul> SpamapS: thats what i was thinking
[16:56] <tseliot> cjwatson: do you know if it's ok to install 2 alternatives (as in update-alternatives) in the same package? Is the debian policy against this?
[16:58] <SpamapS> zul: so I think we should just follow dh_installinit's model and let the preinst stop, and the postinst start...
[16:58] <SpamapS> zul: on a slightly related note, did you see that mysql 5.5.10 will have a libmysqlclient.so.18 ?
[16:59] <zul> SpamapS: cool beans
[16:59] <zul> SpamapS: yeah i saw that, that....will be fun
[17:08] <SpamapS> zul: I suspect this bit is the issue...
[17:08] <SpamapS> # to be sure
[17:08] <SpamapS> stop_server
[17:09] <chrisccoulson> cjwatson, is there a reason that metacity isn't in the ubuntu-desktop package set? i seem to recall it was at some point
[17:09] <chrisccoulson> (although, i could be mistaken there) ;)
[17:09] <RoAkSoAx> hggdh: Daviey bug #711587 comment #3
[17:14] <Daviey> RoAkSoAx, looking
[17:14] <cjwatson> tseliot: I can't think of a reason not to, I suppose
[17:15] <cjwatson> chrisccoulson: probably build-dependencies from rest-of-world
[17:15] <cjwatson> or just dependencies perhaps
[17:15] <cjwatson> ubiquity depending on it might well pull it up
[17:15] <tseliot> cjwatson: ok, thanks
[17:15] <cjwatson> chrisccoulson: I can make an exception for it if you're requesting it
[17:16] <Daviey> RoAkSoAx, Reading your comment, isn't this now a powernap bug rather than euca?
[17:16] <RoAkSoAx> Daviey: is not a bug in PowerNap :)
[17:17] <RoAkSoAx> Daviey: the thing is that before, PowerNap by default always run monitoring /sbin/init which cause to never perform any action to the machine and Eucalyptus never had any "issues" because it only told powernap "sleep now"
[17:18] <chrisccoulson> cjwatson, i would like that, if you can do that
[17:18] <RoAkSoAx> Daviey: so in fact, the relationship between powernap and eucalyptus before, was that powernap did nothing than run all the time waiting for a command from eucalyptus
[17:18] <RoAkSoAx> Daviey: now, since powernap has evolved, other things need to be considered when configuring it to work with euca
[17:19] <RoAkSoAx> so this is rather "best-practices" when working together
[17:19] <kirkland> RoAkSoAx: honestly, Eucalyptus wants powernap to stay out of their way
[17:19] <cjwatson> chrisccoulson: done
[17:19] <kirkland> RoAkSoAx: all they want to do is call powernap-now
[17:19] <chrisccoulson> cjwatson, excellent, thanks :)
[17:19] <Daviey> RoAkSoAx, Yeah.... so either, powernap needs to revert to the previous behaviour ... or have a config.d/ where euca can throw in a /sbin/init as it's process... Can't think of another decent fix
[17:19] <Daviey> RoAkSoAx, Can you?
[17:19] <kirkland> RoAkSoAx: they don't want to leverage the flexibility of powernap, and that saddens me
[17:19] <kirkland> RoAkSoAx: but so be it
[17:19] <kirkland> RoAkSoAx: that's how they want to do it
[17:19] <RoAkSoAx> kirkland: ah I was planning to email you my findings in a little bit more detail
[17:20] <kirkland> RoAkSoAx: okay
[17:20] <kirkland> RoAkSoAx: you can do that
[17:20] <Daviey> RoAkSoAx, TBH... remember that this is a point release of euca... so expecting them to add new functionality is somewhat unfair
[17:20] <kirkland> RoAkSoAx: Daviey's suggestion is reasonable
[17:21] <RoAkSoAx> Daviey: I don't really want functionality added to euca just now, but it is just "recommended PowerNap config when runnning with euca"
[17:21] <hggdh> actually a bit more than that
[17:22] <hggdh> the current powernap config may cause problems with euca, so one of them should be adjusted. Given that it is just euca that gives us problems, we should adjust it there
[17:22] <Daviey> RoAkSoAx, I'd recommend adding a config.d for powernap... That seems the least intrusive, and still enables powernap to be more useful in other scenarios
[17:23] <RoAkSoAx> Daviey: yeah maybe it indeed is. Let me finish writing the email so that you can have a clearer picture of whats happening :)
[17:24] <Daviey> RoAkSoAx, coolio
[17:24]  * Daviey wonders if he /really/ just said coolio. :/
[17:25] <ogra> it had a british accent
[17:25] <ogra> so its ok :)
[17:26] <dholbach> Daviey, I think after 15 years it's OK to refer to one hit wonders again ;-)
[17:27] <Daviey> heh
[17:28] <mterry> doko, so I'm finally getting to zope.fixers, and I'm having some problems with python3 and the control file.  I fixed some low-hanging fruit like enabling the test suite, but substitution variables in debian/control are bugging me.  python3:Versions isn't being defined by dh_python3.  Do you know why that would be?   Here's the current control file I'm working with: http://pastebin.ubuntu.com/577070/
[17:28] <doko> mterry: ugh, sorry, I did interpret your ack as an ok
[17:30] <doko> mterry: please go ahead and upload if possible
[17:31] <GunnarHj> ScottK: Uploaded at last; thanks! :-)
[17:31] <GunnarHj> ScottK: Seems like those l-s and gdm changes didn't fit well either for -updates or -backports, and that I was granted an exception. Is it so, and if it is, are the related procedures optimal?
[17:32] <ScottK> I think backports was best.  It's just a difficult situation since it's such a core package.  Not sure how much better it could have been.
[17:34] <mterry> barry, hello!  Got a sec?
[17:38] <Daviey> RoAkSoAx, Thought about adding powernap support for openstack?
[17:39] <barry> mterry: sure thing
[17:39] <RoAkSoAx> Daviey: well I haven't yet seen OpenStack architecture so idk :). kirkland ideas?
[17:41] <mterry> barry, look up a bit, I was asking doko about python3:Versions issues I was having with python3-zope.fixers.  It's not being defined by dh_python3 it seems?  Nor is Suggests or Provides...
[17:41] <kirkland> Daviey: we discussed it in San Antonio
[17:41] <kirkland> Daviey: the crowd was quite keen on the idea, as i recall
[17:42] <barry> mterry: let me ask over in #debian-python
[17:43] <mterry> ooh, new channel.  I'll join too
[17:43] <barry> mterry: it's on oftc not freenode.  but if you join, do you want to just re-ask over there?
[17:43] <mterry> ok
[17:44] <barry> mterry: awesome.  i'll follow along
[17:46] <Daviey> kirkland, yeah... as RoAkSoAx is working on powernap - wondered if it was a potential upstream contribution he'd like to undertake.
[17:46] <kirkland> Daviey: RoAkSoAx: strong +1 from me
[18:11] <abhinav-> barry, thanks for the review of the Tomboy merge proposal :)
[18:11] <abhinav-> TheMuso, has communicated to the upstream about the patch https://bugzilla.gnome.org/show_bug.cgi?id=588730
[18:12] <barry> abhinav-: np!  thanks for nice improvement.  hopefully my review is helpful?
[18:12] <abhinav-> yes
[18:12] <abhinav-> that was quite detailed and I learnt to notice fine details before submitting patches :)
[18:12] <GunnarHj> ScottK: I see. Of course it would have been possible to do it the other way, i.e. starting with the latest Natty revision and revert changes that don't work in Lucid/Maverick. But since that would have involved stuff that I know almost nothing about (Python 2.7 -> 2.6, quite a few dependencies, etc.) I chose to add the changes I wanted to see backported. Maybe an experienced developer would have done it otherwise.
[18:13] <barry> abhinav-: :)  sounds like the tomboy devs are receptive to the improvement!  nicely done
[18:13] <ScottK> GunnarHj: I think it was a reasonable approach.
[18:14] <abhinav-> barry, however, I have replaced the messagebox with a message and a button inside the tomboy itself.  i am still looking on ways to improve it.
[18:14] <GunnarHj> ScottK: Ok. Anyway, glad it could be done. Thx again.
[18:15] <abhinav-> soren, I was wondering, should I submit the new changes as a new merge proposal (in a new branch) or just push through this branch only ?
[18:15] <barry> abhinav-: cool
[18:16] <barry> abhinav-: no sure that comment was directed at me, but you can always just update your current branch and push the update.  the merge proposal will adjust.  unless the change is totally different, in which case, you can push a new branch and supersede the merge proposal with the new branch
[18:18] <abhinav-> barry, ok. thanks for the help and guidance. after yours and dholbach's session, I have got a start in ubuntu development :)
[18:19] <barry> abhinav-: yay!  do feel free to ask any questions about udd
[18:19] <abhinav-> yup sure :)
[18:25] <chrisccoulson> @pilot out
[18:38] <RoAkSoAx> kirkland: Daviey email sent
[18:53] <Daviey> wow RoAkSoAx, you like the long emails :)
[18:57] <cnd> Riddell, did you know there's a *HUGE* debian-changes-4:4.7.2-0ubuntu1 file in qt4-x11?
[18:57] <cnd> 1,113,501 lines
[18:57] <cnd> seems like something is off
[19:00] <doko> cnd, Riddell: if if plan to fix that, please wait until today's gcc-4.5 is built on armel, or add a versioned b-d
[19:00] <doko> ogra: ^^^
[19:01] <cnd> doko, I'll keep that in mind
[19:01] <doko> and ogra did want to revert something ...
[19:13] <psusi> say umm... don't you have to dereference or free the connection pointer you get from dbus_g_bus_get()?
[19:16] <cjwatson> the documentation says "Returns a connection to the given bus. The connection is a global variable shared with other callers of this function."
[19:16] <psusi> so that's a no then? ;)
[19:16] <cjwatson> it's a "let Colin finish typing"
[19:17]  * psusi will get this gnome stuff figured out yet
[19:17] <janimo> cnd, that is probably because of upstream changes between 4.7.1 and 4.7.2 which are in that diff
[19:18] <cnd> janimo, shouldn't the source package have been updated with the upstream changes?
[19:18] <cjwatson> looking at the source, dbus_g_bus_get doesn't take a reference
[19:18] <cjwatson> wait, does it
[19:19] <cjwatson> dbus_g_connection_unref is a typed shim through to dbus_connection_unref
[19:20] <cjwatson> and dbus_g_bus_get calls dbus_bus_get which takes a reference to the connection
[19:21] <cjwatson> psusi: so the answer is, yes, you should dbus_g_connection_unref the return value of dbus_g_bus_get when you're finished with it
[19:21] <cjwatson> it may be a global variable but it still has a reference count
[19:21] <cjwatson> AFAICS
[19:22] <cjwatson> and it's only global in the same way that dbus_bus_get returns a global, and its documentation says "The caller of this function owns a reference to the bus."
[19:22] <debfx> doko: the new gcc upload makes virtualbox-ose ftbfs: http://paste.ubuntu.com/577138/
[19:23] <debfx> should I open a bug report?
[19:24] <doko> debfx: please do so, with the preprocessed source attached
[19:24] <psusi> cjwatson: hrm.. then it is a bug that gpm-manager.c in g-p-m doesn't do that?
[19:30] <doko> debfx: do you prepare the report?
[19:32] <debfx> doko: I'm on it, what preprocessed source should I attach?
[19:32] <doko> .i
[19:32] <doko> build it with -save-temps
[19:33] <janimo> cnd, yes. But I have the impression the diffs LP outputs are for the whole package not just debian/ diffs
[19:33] <cnd> janimo, I'm looking at one of the patches in debian/patches
[19:34] <cnd> it's an autogenerated patch from dh
[19:34] <janimo> cnd, in that case I take back what I said
[19:34] <cnd> it makes me wonder if the qt 4.7.2 merge is correct, since it often suggests that you've updated the tarball but not the package
[19:34] <cnd> so the autogenerated patch ends up undoing all the changes
[19:35] <janimo> cnd, now I see that patch too, indeed quite large
[19:37] <janimo> cnd, did you see regressions because of that patch?
[19:37] <cnd> janimo, no, I went to check the source
[19:38] <cnd> and fix an issue with the xi 2.1 multitouch patch
[19:38] <cnd> when I saw that huge thing
[19:40] <debfx> doko: bug #730860
[19:40] <janimo> cnd, the first lines in it suggest it is autogenerated as a summary of upstream changes, but I don't know why it is included there
[19:41] <doko> debfx: amd64 only?
[19:41] <janimo> one of the Kubuntu folk may know, Riddell is away this week AFAIK
[19:41] <janimo> ScottK, ^
[19:41] <debfx> doko: haven't tested i386 yet
[19:42] <cnd> janimo, the header of the patch is just autogenerated
[19:47] <cjwatson> psusi: I guess so.  it may not be serious
[19:48] <cjwatson> cnd: dpkg-source is what autogenerates the patch, not dh.
[19:48] <cjwatson> (FYI)
[19:49] <cnd> cjwatson, since you stepped into the conversation :), do you have any ideas as to how a 1+ million line patch could be generated?
[19:57] <debfx> cnd: that patch should be dropped
[19:57] <cnd> debfx, yes, but it's not as easy as just saying it should be :)
[19:57] <cnd> the question is: how did it get there in the first place
[19:58] <cnd> and is the package being built correctly
[19:59] <debfx> cnd: either it's some 4.7.1 vs 4.7.2 mixup or the build process changed some files that weren't cleaned properly
[20:00] <debfx> I've looked at the diffstat, there is nothing we want to keep
[20:00] <cnd> debfx, yeah, so I'm thinking we need to wait till Riddell can take a look, since he's the one who updated to 4.7.2
[20:00] <cnd> just to be sure
[20:02] <psusi> hrm... I think I need to add an argument to org.freedesktop.UPower.Sleeping to say whether it's hibernate or suspend... hrm... now to figure out how to extract such an argument from a GVariant...
[20:07] <bryceh_> @pilot in
[20:09] <micahg> wow, 4 patch pilots in one day :)
[20:09] <bryceh_> heh
[20:10]  * micahg guesses it makes sense
[20:10] <bryceh_> suspect a couple just forgot to log out
[20:11] <micahg> Is there an AA to apply some overrides
[20:11] <bryceh_> AA?
[20:11] <micahg> archive adin
[20:11] <micahg> *admin
[20:11] <bryceh_> not me, bug cjwatson might still be around
[20:11] <bryceh_> er, s/bug/but/
[20:14] <ScottK> janimo: debfx is probably your best bet if Riddell isn't around.
[20:14] <janimo> ScottK, ok
[20:14] <janimo> cnd, ^ :)
[20:15] <cnd> debfx, janimo: are either of you familiar with qt4-x11?
[20:15] <cnd> I really don't know the regular maintainers of the package
[20:15] <cnd> I just provided one patch
[20:15] <cnd> so if you guys are the regular maintainers, then by all means have at it :)
[20:15] <janimo> cnd, me too :)
[20:16] <micahg> ScottK: can you apply archive overrides?
[20:16] <ScottK> micahg: No.
[20:18] <debfx> cnd: yes, what needs to be done? :)
[20:20] <sbeattie> micahg: best to ask in #ubuntu-release.
[20:31] <cnd> debfx, just figure out what's up with that odd debian patch
[20:32] <cnd> make sure qt is building correctly
[20:34] <psusi> oh boy, lots of patch pilots.. I wonder if my fixes to dmraid and parted will get merged today...
[20:43] <psusi> does this look about right to register for a dbus signal? http://pastebin.ubuntu.com/577165/
[20:48] <debfx_> rsalveti: do you have patches for the packages that broke by switching to gles in qt? bug #707794
[21:12] <rsalveti> debfx: not yet
[21:13] <rsalveti> but plan to help porting all those packages
[21:26] <MeltingKeyboard> Anything I can do to help?
[21:26] <MeltingKeyboard> where would I look to find stuff to do?
[21:27] <doko> TheMuso: ping
[21:28] <doko> mterry: you accepted the wrong ones \o/ ;-P
[21:29] <mterry> doko, yeah, sorry  :)
[21:29] <mterry> those perl packages were delightfully well-maintained though
[21:30] <arand> MeltingKeyboard: Harvest might be one place to look: http://harvest.ubuntu.com/ , I'm not completely sure what you're asking about though
[21:31] <MeltingKeyboard> ok
[21:31] <MeltingKeyboard> I will look there
[21:31] <MeltingKeyboard> I was just wondering if there was something I could help with with the new release date looming
[21:31] <MeltingKeyboard> thanks
[21:32] <doko> mterry: so the missing symbols files are the only complaints?
[21:33] <mterry> doko, and dbus-c++ is orphaned in debian.  Doesn't inspire confidence
[21:34] <doko> mterry: sure, but we had it in main before
[21:34] <mterry> doko, it was in main as part of another package, whose maintainer presumably took care of it, right?
[21:34] <mterry> now no one claims to
[21:35] <doko> and makes ubuntustudio uninstallable
[21:36] <doko> or was it for mythbuntu?
[21:36] <arand> MeltingKeyboard: https://wiki.ubuntu.com/UbuntuDevelopment is a more general overview. It may be a good idea to pick a specific area and engage the relevant people with your specific ideas about what you would help with.
[21:39] <barry> @pilot out
[21:44] <soren> abhinav-: Sorry, what's the context?
[22:11] <apachelogger> cjwatson: can I somehow get the pid of a process using libpipeline?
[22:54] <doko> mterry: one is missing, which I didn't see.  please could you look at bug #729907 too?