=== Seeker`_ is now known as Seeker` [00:18] psusi: ah ok [00:26] TheMuso, so umm... what exactly does that patch fix? [00:27] 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] 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] 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] psusi: I guess the best experiment is to take out my patch, play with dmraid stuff and parted, and see what happens. [01:16] TheMuso, k.. guess I'll try that... [01:18] 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] 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] 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] Display blanking, automated “suspend when low battery” stuff? [01:50] RAOF, doesn't appear to be.. looks like upower is doing that these days... which explains bug #578542 [01:50] Launchpad bug 578542 in gnome-power-manager (Ubuntu) "resuming from S3 wrongly prompts for password" [Low,Confirmed] https://launchpad.net/bugs/578542 [01:51] I sent g-p-m a SIGSTOP and clicked suspend on the menu and it worked normally [01:53] psusi: That's orthogonal to what I said. That's neither ‘suspend when battery low’ nor ‘dim screen on inactivity’. :) [01:55] Those are policy decisions rather than implementation methods. === kklimonda1 is now known as kklimonda [02:05] ahh... [02:06] so where is the darn screen saver being started and the screen locked? hrm... === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === Pici` is now known as Pici [02:32] hrm.. can you use dbus-send to manually emit an org.freedesktop.UPower signal? [02:32] or better yet, find out what is listening for that signal? [02:45] 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] 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=, and .. [02:48] Heh. [02:48] Say hello to DBus! [02:48] --dest= is the *interface* that the signal you want to send is from. [02:49] Oooh, actually, no. [02:49] You shouldn't need --dest, because you're not sending it anywhere specific. [02:50] should be the object path of the object you want to raise the signal _on_ [02:51] should be the signal you want to raise, namely the fully-qualified signal from the interface (org.freedesktop.UPower.$INTERFACE.$SIGNAL) [02:51] so org/freedesktop/UPower and org.freedesktop.UPower.Sleeping? [02:51] err, what's $INTERFACE? [02:52] Sounds like $INTERFACE is "" [02:52] So you'd want to send org.freedesktop.UPower.Sleeping [02:53] 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] 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] Sounds like you've got the wrong object path? [02:59] * RAOF fires up d-feet [02:59] d-feet? [03:00] …and immediately notices he doesn't have a UPower interface. [03:00] Oh, man. You're debugging DBus issues and you don't know about d-feet? Sorry! [03:01] It's a DBus browser. It can't raise signals, but it does enumerate the bus and such. [03:01] Oh, of course. It's on the system bus. [03:05] So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me. [03:05] So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me. [03:09] DOH! [03:09] I wasn't using the leading / before org [03:12] It also doesn't trigger anything obvious for me :) [03:13] me neither... hrm... [03:13] so there's no way to monitor who is interested in the signal? [03:20] 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] Wheras that was very happy to suspend my system. [03:25] And, of course, did not result in gnome-screensaver coming back with a screen lock. [03:26] hrm.. it works when I use d-feet to call it and yea, doesn't lock the screen [03:26] hrm... [03:32] 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] so what on earth DOES lock the screen? [03:44] Well, in Do we call out to gnome-screensaver ourselves. [04:01] bingo... indicator-session... session-service.c:machine_sleep() [04:02] 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.. === _LibertyZero is now known as LibertyZero [06:09] is there a command to delete a branch from the repository ? [06:09] in bazaar [06:10] rm -r? [06:11] so bazaar will know that the branch is gone, if I do that ? [06:11] Yes. [06:11] oh ok. thanks [06:11] * For some values of “yes”. [06:12] What exactly do you want to do? Free disk space? Strip out some unwanted stuff from a repository? Clean your source trees? [06:13] yeah. I was experimenting something in a branch. I do not want to merge those changes, [06:14] Oh. Then just don't merge those changes :) [06:14] lol, rm -r [06:15] yeah, but that branch is pretty useless now. deleting it should not be any harm ? [06:15] The repository is just a performance optimisation. It doesn't actually have any semantic meaning. [06:16] 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] Your local repository will be a couple of KB larger than it would otherwise be :) [06:16] ah ok. that's fine :) [06:17] Mmmm, “About 8 hours remaining”. dpkg really, really likes unpacking onto btrfs, doesn't it :) === Tm_T_ is now known as Tm_Tr === ubott2 is now known as ubottu === vila_ is now known as vila [08:04] why does dch -i add maverick at the top of the changelog entry, even though I am working on natty package ? [08:04] good morning [08:04] good morning :) [08:05] abhinav_: you can pass -Dnatty to work on a natty package (I'm assuming you're on maverick) [08:05] yes, I am on maverick [08:08] I have already saved the changelog. I suppose I can edit it and write natty instead of maverick. [08:10] 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] ok thanks :-) === tumbleweed_ is now known as tumbleweed [08:13] 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] abhinav_: that's because it comes from Debian [08:13] ohsix, so I should write unstable too ? [08:14] *sorry [08:14] abhinav_: no [08:14] tell debian about it, no? [08:15] well, the patch should be upstreamed to Debian if appropriate, but that's another question :) [08:16] i can never remember if unstable or testing is the one to expect breakage [08:16] (lots of, not some) [08:16] hmm , I have the patch ready :-), Its my first bug-fix, so I have not much idea about the process [08:16] but the package is tomcat6-6.0.28, I believe same is available in maverick repositories [08:17] abhinav_: https://wiki.ubuntu.com/SponsorshipProcess [08:37] 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 === smb` is now known as smb [08:56] Good morning [08:56] slangasek: sure, no prob === soren_ is now known as soren [09:42] * SpamapS_ gulps [09:42] 933 upgraded, 66 newly installed, 1 to remove and 1 not upgraded. [09:42] Need to get 977 MB/977 MB of archives. === SpamapS_ is now known as SpamapS [09:42] * SpamapS answers yes... here we go! [09:51] slangasek: gtk 2 uploaded [10:11] where can I get some help on gtk# ? [10:17] abhinav_: #mono on gimpnet is a reasonable place for gtk# help. [10:18] RAOF: thanks. I will ping there :) [10:18] 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] 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] 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] didrocks: hi [10:31] didrocks: how do i make the unity search thing look for stuff in my $HOME/bin? === kirkland` is now known as kirkland [10:32] kirkland: hey, the search is only based on desktop files [10:32] so put a desktop file in your XDG path [10:32] didrocks: dang [10:32] we'll have an alt + F2 soon [10:32] didrocks: i just want to run a wrapper script [10:32] \o/ [10:32] didrocks: like i used to do with alt-F2 [10:32] * soren misses Alt-F2 [10:33] didrocks: oh, okay, as long as alt-f2 comes back, that'll be fine [10:33] kirkland: you'll have one if I find the time to code it :) [10:33] yeah [10:33] didrocks: cool, thanks [10:33] yw :) [10:33] bdrung_: Thought you might have liked to see http://stopabusingsiprefixes.org/stopabusing.html [10:33] didrocks: if you're writing this, could you make sure that the alt-f2 path contains $HOME/bin? [10:34] Ubuntu is lame. [10:34] Maybe, but at least they have a sensible units policy. [10:34] kirkland: it will respect the PATH [10:34] bdrung_: direct quote ^^ [10:34] sounds less hackish :) [10:35] dpm: they come exclusively from upstream [10:36] dpm: what language(s) are affected? [10:36] nigelb: :) sadly the upstream authors with power refuse to do something regarding this bikeshed topic [10:36] didrocks: okay [10:36] bdrung_: oh, ouch :( [10:37] nigelb: https://bugzilla.gnome.org/show_bug.cgi?id=640432 [10:37] 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 === JamieBen1ett is now known as JamieBennett [10:38] bdrung_: oh dear. Its bad when someone says, "flame" in the beginning of the bug [10:39] dpm: thanks, I check it ou [10:39] t [10:40] thanks :) === abhinav_ is now known as abhinav- [11:23] 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] pitti, is there a problem with the retracer? I'm seeing 16-hour-old bugs like 730243 are not retraced yet [11:30] 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] mdz: the decorator issue is on our radar [11:32] mdz: smpillaz has made more fixes for it, and i'm seeing with didrocks when he can release that [11:33] dbarth, ok [11:34] mdz, let me check on the retracers === MacSlow is now known as MacSlow|lunch [11:39] 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] seb128, ok, thanks [11:40] mdz, you're welcome [11:40] 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 === MacSlow is now known as MacSlow|lunch [11:44] mdz, no I didn't see it before and I didn't realize that matching was specific to components [11:45] 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] 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] now you can just write one which will (e.g.) match on the stack trace, regardless of which program crashed [11:51] mdz, ok, I thought we had a pattern for this XAllocId ret != invalid crash for example [11:51] but that's might be why it didn't seem to work ;-) [11:51] mdz, thanks for working on that [11:52] mdz, btw your bug got retraced [11:52] seb128, in some places we suppressed the bugs in other ways, e.g. in a general hook or in apt [11:52] 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] maybe it would be a good test case :-) [11:59] mdz, [11:59] [11:59] [11:59] _XAllocID:.*ret.*inval_id [11:59] Ubuntu bug 507062 in libx11 (Ubuntu Lucid) "synaptic assert failure: synaptic: ../../src/xcb_io.c:385: _XAllocID: Assertion `ret != inval_id' failed." [High,Triaged] [11:59] mdz, I was speaking about this one [11:59] 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] there may still be some work needed to avoid it running out of disk during the next run [12:00] seb128, ah, I should have searched with -i. ;-) [12:00] seb128, so that pattern will only get checked for bugs which are about to be reported on libxcb [12:00] (Debian #594440 bit our eucalyptus package) [12:00] Debian bug 594440 in dpkg-dev "debian/source/include-binaries doesn't allow for inclusion of modified binaries" [Important,Fixed] http://bugs.debian.org/594440 [12:01] mdz, ok, that explains why we keep getting bugs reported against random binaries crashing this way [12:01] seb128, er...actually pitti converted it to be package-independent already :-) [12:02] mdz: retracers> checking; they crash very often these days [12:03] 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] pitti, I sorted the retracers [12:03] I don't see a mention of libxcb in the commit log, other than yours... [12:03] mdz: I guess it was PEBCAK on my end, and I forgot to bzr add back then [12:03] pitti, it's weird, it had a lock from yesterday and no error in the log [12:04] pitti, removed the lock and it's fine [12:04] seb128: amd64 is running, but i386 is locked and not running [12:04] it's running [12:04] cjwatson: on the weekend I painfully noticed that all kde-l10n-* packages are also missing from the kubuntu package set [12:04] seb128: i386? I don't see it running [12:04] pitti, ok, it might have had the same issue, the log had been updated recently when I checked on i386 [12:04] pitti, no, the timestamp was recent on i386 [12:04] 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] amd64 was from yesterday and I restarted it [12:05] which worked [12:05] seb128: bah, same "huge wadl HTML output spew" issue :/ [12:06] cache purged, restarted [12:07] pitti, danke [12:11] 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] Launchpad bug 730528 in libappindicator (Ubuntu) "Impossible to inherit a class from AppIndicator*.Indicator in Python (gir)" [Undecided,New] https://launchpad.net/bugs/730528 [12:11] artfwo, I guess they didn't create a new component out of indicator-application when the source was splitted out [12:12] artfwo, I basically just said "also affect component" and used what was suggested [12:12] ah, I see [12:12] thanks [12:12] 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] seb128, until than is it okay to use "also affects libappindicator" for upstream related bugs? [12:13] s/than/then [12:13] it's fine, either libappindicator or indicator-application [12:13] both will reach the same people [12:19] 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] and there's no way I'm maintaining that package list by hand [12:28] debfx: I think this is a matter for fixing the code that generates the package sets, not for making exceptions [12:29] (it's my problem either way, but just to let you know) [12:39] how does one reset the password on the gnome keyring? wifely one is annoyed at the computer today [12:41] cjwatson: ok [12:43] lamont, reset? [12:43] change [12:44] you mean the password to unlock the keyring? [12:44] you can do that using seahorse [12:45] but it's the same as your login one by default and should be updated when passdw is used to change it [12:51] ah, ok. [12:51] that now all makes sense [12:52] OTOH, password is coming from libnss-db, not via passwd command. so seahorse to change it is the right way, yes? [13:01] debfx: fixed now, along with everything else in your supported seed === MacSlow|lunch is now known as MacSlow [13:26] 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] cjwatson: that was fast, thanks [13:41] cnd: you only need to request if you have a good reason to want to jump the queue [13:41] cjwatson, ok, I assume it will be handled in due time then [13:41] thanks === zul_ is now known as zul [14:07] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: bdmurray, chrisccoulson [14:07] \o/ [14:10] chrisccoulson: happy piloting === doko_ is now known as doko [14:13] cjwatson: I think the kubuntu mobile seed isn't part of the package set anymore [14:15] 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] I need help with the second argument passed in the function, what does it mean? is it typecasting? [14:22] c2tarun: GTK_DISABLE_DEPRECATED is set, and GtkFunction is deprecated since gtk+ 2.24. [14:22] debfx: probably not. should it be the same set or a new one? [14:23] mr_pouit: sorry :( what does it mean? [14:26] cjwatson: for example plasma-mobile was in the kubuntu set before. imho it doesn't make sense to create a new one === cjwatson_ is now known as cjwatson [14:30] 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:30] Launchpad bug 723016 in pcsc-lite (Ubuntu) "[FFe] Please sync new upstream release 1.6.7-1 from Debian Unstable" [Undecided,Confirmed] https://launchpad.net/bugs/723016 [14:31] cjwatson: right, sorry; comment 1 seemed to indicate a sync request; reverted my changes [14:31] yeah, I think that may have been non-jargon use of "sync" [14:48] pitti: thank you very much for sponsoring! [14:48] ari-tczew: you're welcome, thanks for working on the merge! [14:48] ;-) [14:54] mterry: would you have time on a quick component-mismatches cleanup today? would like to do that before starting the rebuild test [14:55] doko, I suppose? you mean processing MIRs or something else? [14:57] 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] doko, but yeah, I can help [14:58] otp now, later ... [15:00] barry: FYI, I've started looking at that Wubi bug [15:01] 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] doko: where can I find every fresh archive rebuild? [15:07] cjwatson: sounds good. let me know if you have something you'd like me to test. i'm patch piloting today === tkamppeter_ is now known as tkamppeter [15:21] doko, what is the problem with the printing stuff? [15:23] tkamppeter: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt all the cmap-* stuff [15:23] mterry: could you address the zope.fixers MIR? [15:24] doko, do they all need to get MIRed? [15:26] tkamppeter: yes, unless you remove them from gs-cjk-resource b-d's. or demote gs-cjk-resource [15:26] doko, seems that these files are fonts for Ghostscript being able to display documents in CJK languages. [15:26] tkamppeter: then please write a short MIR, and have a look at the packages [15:27] I have MIRed gs-cjk-resource recently as I have merged GS from Debian. [15:28] OK, Is it OK to make one MIR for all? They are pure data, so no security problems possible. [15:30] doko: ^^ [15:31] tkamppeter: sure, as long as you review the package [15:31] (s) [15:32] doko, ack re: zope.fixers [15:33] TheMuso: you did sync libffado. but MIR's for libconfig and dbus-c++ are missing [15:33] mterry: thanks [15:34] Riddell: kdesvn: kdesvn-kio-plugins libsvnqt6 [15:34] [Reverse-Depends: kdesdk, kdesvn-kio-plugins] [15:34] didrocks, seb128, pitti: o libquvi: libquvi-dev libquvi-doc libquvi0 [15:34] [Reverse-Depends: Rescued from libquvi, libquvi-dev] [15:34] [Reverse-Build-Depends: totem-pl-parser] [15:34] MIR? [15:35] I'll look at the lintian related libperl-* stuff === dendrobates is now known as dendro-afk [15:37] doko, bug #722591 [15:37] ? [15:37] Launchpad bug 722591 in libquvi (Ubuntu) "[MIR] libquvi" [High,New] https://launchpad.net/bugs/722591 [15:37] 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] oops [15:38] seb128: well, then fix it? [15:39] doko, there was no review from the mir team yet [15:39] mterry: ^^^ please? [15:39] doko, what needs fixing? pitti just pointed some issues but said they were not blockers [15:39] doko, it's assigned to kees [15:39] ahh, ok, anyway, it's assigned to kees [15:44] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: barry, bdmurray, chrisccoulson [15:44] wow, three pilots? [15:45] sure, why not? :) [15:45] barry: hi, can you help me with a test case for a python exception for an SRU? [15:46] micahg: sure [15:46] micahg: do you have an issue #? [15:46] barry: bug 702990 [15:46] 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:46] Launchpad bug 702990 in wireshark (Ubuntu Maverick) "raise Python 2.6 compatible exceptions" [Low,In progress] https://launchpad.net/bugs/702990 [15:48] 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] hmm,/wg 20 [15:49] oops [15:49] 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] 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] oh, there's no debdiff, let me fix that [15:52] 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] of course, as the issue points out, string exceptions could have lots of reliability problems too, if not done right [15:52] cool. a debdiff will help [15:55] micahg: did you see it? bug 730413 [15:55] Launchpad bug 730413 in wireshark (Ubuntu) "CVE-2011-0538 Wireshark: memory corruption when reading a malformed pcap file" [Medium,New] https://launchpad.net/bugs/730413 [15:55] ari-tczew: yes, I chatted with udienz already, thanks [15:56] * micahg has a little bug cleanup work later though [15:58] barry: diff attached [15:59] micahg: omg. yeah, those old string exceptions are completely broken, even in a python that supports string exceptions. :) [16:00] barry: so, is it possible to safely SRU? [16:01] 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 :) === diwic is now known as diwic_afk [16:01] psusi: hm, g-p-m didn't change since maverick [16:01] micahg: is that good enough? ;) [16:01] psusi: but yes, I believe the "initiate suspend" etc. stuff moved to gnome-session a while ago [16:01] barry: umm, let's see [16:02] pitti: what do you think about the above wireshark SRU bug and barry's comments? [16:03] 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] micahg, pitti if that makes sense. ;) [16:04] yes, it does [16:04] micahg, pitti so again, short of a full code audit, it doesn't seem like this patch can make things worse [16:04] string exceptions are not a thing you'd ever want to catch and handle [16:05] most definitely not, though it *was* possible if done right [16:05] seems okay to me [16:06] 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] 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] pitti: in that case, i think the patch is fine [16:06] 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] micahg: primarily "make sure that the program still works", by running through some standard use cases with it [16:08] pitti: ok, can do, thansk [16:08] *thanks === maco2 is now known as maco === smoser` is now known as smoser === ivoks_ is now known as ivoks === seiflotfy__ is now known as seiflotfy [16:13] pitti: yea, this has been going on at least since lucid [16:15] 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] pitti: can we drop changes with Break: udev ? [16:17] ari-tczew: yes, lucid's udev is much newer already [16:17] pitti: ok thanks === sebner_ is now known as sebner === dendro-afk is now known as dendrobates [16:33] doko: I'm very unlikely to have time to work on MIRs this week. [16:34] yeah, I know, trying to keep other people busy ... [16:35] njpatel: do you already know of a unity bug where the app panel doesn't auto disappear? [16:36] njpatel: and the bug where search just doesn't work? [16:36] amitk, when you fullscreen? Is this on multiple monitors? [16:36] amitk, re:search, do you have unity-place-files and unity-place-applications installed? [16:37] njpatel: yes, 2 monitors [16:37] amitk, then, yeah, it's known hopefully fixed this week [16:38] njpatel: for some reason those two were not installed (I've been upgrading natty since alpha 2) [16:38] weird :/ You'll need to restart unity after installing them (unity --replace from a terminal should do it) [16:42] njpatel: much better, thx [16:42] asac: http://gwibber.com/develop/ won't open ? [16:44] np :) [16:56] zul: so, you're thinking the mysql maintainer scripts / upstart job need reworking, right? [16:56] SpamapS: thats what i was thinking [16:56] 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] zul: so I think we should just follow dh_installinit's model and let the preinst stop, and the postinst start... [16:58] zul: on a slightly related note, did you see that mysql 5.5.10 will have a libmysqlclient.so.18 ? [16:59] SpamapS: cool beans [16:59] SpamapS: yeah i saw that, that....will be fun [17:08] zul: I suspect this bit is the issue... [17:08] # to be sure [17:08] stop_server [17:09] 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] (although, i could be mistaken there) ;) [17:09] hggdh: Daviey bug #711587 comment #3 [17:09] Launchpad bug 711587 in eucalyptus (Ubuntu Natty) "powernap and Eucalyptus seem unable to reach an understanding" [High,New] https://launchpad.net/bugs/711587 === dholbach_ is now known as dholbach [17:14] RoAkSoAx, looking [17:14] tseliot: I can't think of a reason not to, I suppose [17:15] chrisccoulson: probably build-dependencies from rest-of-world [17:15] or just dependencies perhaps [17:15] ubiquity depending on it might well pull it up [17:15] cjwatson: ok, thanks [17:15] chrisccoulson: I can make an exception for it if you're requesting it [17:16] RoAkSoAx, Reading your comment, isn't this now a powernap bug rather than euca? [17:16] Daviey: is not a bug in PowerNap :) [17:17] 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] cjwatson, i would like that, if you can do that [17:18] 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] Daviey: now, since powernap has evolved, other things need to be considered when configuring it to work with euca [17:19] so this is rather "best-practices" when working together [17:19] RoAkSoAx: honestly, Eucalyptus wants powernap to stay out of their way [17:19] chrisccoulson: done [17:19] RoAkSoAx: all they want to do is call powernap-now [17:19] cjwatson, excellent, thanks :) [17:19] 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] RoAkSoAx, Can you? [17:19] RoAkSoAx: they don't want to leverage the flexibility of powernap, and that saddens me [17:19] RoAkSoAx: but so be it [17:19] RoAkSoAx: that's how they want to do it [17:19] kirkland: ah I was planning to email you my findings in a little bit more detail [17:20] RoAkSoAx: okay [17:20] RoAkSoAx: you can do that [17:20] RoAkSoAx, TBH... remember that this is a point release of euca... so expecting them to add new functionality is somewhat unfair [17:20] RoAkSoAx: Daviey's suggestion is reasonable [17:21] 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] actually a bit more than that [17:22] 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] 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 === Seeker`_ is now known as Seeker [17:23] 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] RoAkSoAx, coolio [17:24] * Daviey wonders if he /really/ just said coolio. :/ [17:25] it had a british accent [17:25]