[00:00] there will be others now who aren't included in that 158, but are in kubuntu-dev or similar [00:00] ahh, true [00:01] well, the reson for my asking, I'm planning on becomming a developer [00:02] ajmitch: actually no, 158 includes those [00:02] ajmitch: they are a member of ~ubuntu-dev I see [00:02] Active developers are going to be well under 100. [00:03] true [00:03] I was once going to take a stab on figuring that out [00:03] I'm actually shocked that ubuntu is developed by so many different people and can still run like it does [00:04] something like, all the developers who've uploaded more than 1 time in the last release [00:04] last time I looked at that it weeded out probably 2/3 [00:04] hmm [00:04] LaserJock: What about people who only do security or SRU? [00:05] I guess it'd be the same [00:05] Daviey: what about them? [00:05] LaserJock: Would they be included in your "uploaded more than 1 time in the last release" [00:05] <--from south, has not perfect english btw [00:05] kenvandine, ping [00:05] oh, I don't know, probably [00:06] last time I wrote a script it crawled through -changes [00:06] ahh [00:06] which would include post-release uploads [00:06] do security uploads end up on -changes? [00:07] I'm new to c++ language, and I've yet to find something that will help me make a gtk program from it [00:07] ajmitch: not sure about that one [00:07] ajmitch: Yes, but not with a correctly signed changes file. [00:07] right, that was the problem last time I did this, syncs, etc. were not counted right [00:08] but that was a long time ago, I think the -changes format has changed since then [00:08] lee_: if you're looking at making an application, I think #ubuntu-app-devel may have people who can help [00:08] It's also reasonably easily doable with launchpadlib. [00:08] LaserJock: syncs have got attribution of who requested it in the mail [00:08] ajmitch: not with C++ ;-) [00:09] LaserJock: I don't know, I haven't been there :) [00:09] ajmitch: WRT #ubuntu-app-devel [00:09] most of #ubuntu-app-devel folks are heavy python users ;) [00:09] python lovers [00:09] heh [00:09] figures [00:09] maybe some variety could be good then [00:09] JavaScript? [00:09] please, don't [00:09] true, I've already made a game using just a terminal app [00:09] you may as well next suggest php-gtk [00:10] well, JavaScript is the new python, right? [00:10] gnome-shell is written in it [00:10] as are a few of the Gnome games now [00:10] LaserJock: Only if you are GNOME. [00:10] this joke wasn't funny when gnome devs told it and it isn't funny now LaserJock ;) [00:11] wgrant: as goes GNOME so goes ... um, GNOME? [00:11] hmm, actually, from all the sources that I learned c++ from (still a beginner at it) python is a rising programming language and is already the most used [00:11] introducing JS as a part of core GNOME platform is the weirdest decision i've seen in some time :/ [00:11] and the whole, ubuntu developers using python thing, confirms it... [00:11] eh, people are weird [00:12] kklimonda|G1: well, they could have picked C# ... [00:12] c++, and this is just my opinion, is better then c# language [00:12] much like ubuntu, being derived from debian, is better then debian... [00:13] lee_: well, there are ubuntu developers and developers who writr apps for ubuntu - first are writing lots of glue code to make working on distribution faster and python is great for that. [00:14] ok, I may be a beginner at c++, but I already figured that out [00:14] well, I'd better go learn python... [00:15] It'll be a good investment of time. [00:15] yup [00:15] cya [00:15] ajmitch: they do end up on -changes (it was broken for a long while, but is fixed now) === sconklin is now known as sconklin-gone [00:27] ok, I ran across a problem... [00:28] how do you open python after you've installed the compressed file? [00:43] is there any way of getting results that are uploaded by people using checkbox? where are they stored? === Matt_ is now known as Guest6565 [00:45] Hi. I would like to get involved in development. Can anyone give me any pointers on where to start?? [00:45] !development [00:45] Interested in becoming an Ubuntu Developer? Get started here: https://wiki.ubuntu.com/UbuntuDevelopment [00:45] Guest6565: ^ [00:46] Thanks for the Link :-D [00:46] no problem === dendro-afk is now known as dendrobates [01:33] I need some help with something === dendrobates is now known as dendro-afk [01:44] where can I find irc logs of channel #ubuntu-hardened ? [01:47] irclogs.ubuntu.com probably [01:52] zul: not found this channel :/ [01:56] crimsun: ping - in response to your comment on bug 528524, no change means that pulse is not being bypassed, and sudo speaker-test is still running through pulseaudio with the user as the owner of the device open handle. [01:56] Launchpad bug 528524 in speex "Sound not working in all apps through pulse on arm" [High,Confirmed] https://launchpad.net/bugs/528524 === dendro-afk is now known as dendrobates [02:05] GrueMaster: PULSE_NO_SIMD=1 does however make it work properly, where sudo speaker-test actually grabs the pcm device as root. === dendrobates is now known as dendro-afk [03:12] lifeless: I am available at your convenience for the next while. [03:16] persia: ok cool [03:17] persia: in an empty dir do [03:17] lmirror init test [03:17] lmirror serve test [03:17] start up a tshark or similar session logging traffic on localhost port 8080 [03:17] we want full frame captures, not truncated [03:18] then run lmirror mirror http://127.0.0.1:8080/test /tmp/test3 [03:19] * persia starts reading tshark documentation === dendro-afk is now known as dendrobates [03:24] jpds: around? [03:24] He's not. [03:25] bad timeofday + easter [03:25] I know both of those things. Sometimes however, people surprise us :) [03:27] lifeless: Have you put any thought into how we are going to mirror the actual archive with lmirror? [03:27] With the split and all that. [03:28] It could be done by maintaining a separate journal for each, but it seems like things could be much more efficient than that. [03:29] * persia would like to re-un-split later to save disk space [03:33] lifeless: So, tshark documentation follows current practice of not including any examples, and being written without the clarity and concision of the SYSV manpages. Any pointers as to how to capture? [03:34] GrueMaster: I was afraid of that being the case. I guess it's time to debug the arm asm. [03:40] wgrant: yes, I have [03:40] persia: -i lo host 127.0.0.1 and port 8080 -X [03:40] persia: at a guess, offhand [03:41] wgrant: I suspect many journals, perhaps as many as one per dr-arch [03:41] I finally found an example almost the same time you posted, and `tshark -f "tcp port 8080" -i lo0` seems to do the right thing. [03:41] wgrant: into the same dir structure [03:41] persia: ok, grab a capture of it hanging [03:41] and show me [03:42] back shortly [03:44] lifeless: http://paste.ubuntu.com/409814/ [04:09] persia: uhm [04:09] persia: that pastebin is garbage [04:09] lifeless: You have to "download as text". [04:09] * persia puts the file somewhere else [04:10] persia: 'download as text' gives me garbage too [04:10] persia: did you use -s 0 ? [04:11] lifeless: http://people.ubuntu.com/~persia/tshark.out and no. [04:12] Does that seem less like garbage? [04:13] persia: 403 [04:14] * persia fights with sftp [04:14] Try again. [04:19] I have it, am looking [04:20] * persia 404s it to save precious disk space [04:21] Err, 410! [04:22] hmm [04:22] the trace is noisy or something [04:23] persia: please redo it with -s 0 [04:23] Well, it's the output of `sudo tshark -f "tcp port 8080" -i lo -w /tmp/tshark.out` [04:23] OK. [04:27] lifeless: http://people.ubuntu.com/~persia/tshark.out updated [04:32] wow [04:32] I think I need to tune the tcp interactions a bit [04:33] nevertheless [04:34] odd [04:34] its asking for /1/1 [04:34] did you reuse the target mirror directory ? [04:34] persia: ^ [04:34] persia: also, is it still hanging ? [04:35] I used a new target directory. I stopped the hang with Ctrl-C [04:35] ok [04:35] uhm [04:35] please repeat, new target dir [04:35] don't ctrl-C the hung process [04:36] stop the tshark first [04:38] OK. [04:39] actually [04:39] nevermind [04:39] I think I should have enough here, I can see where you waited [04:43] lifeless: uploaded new tshark.out for new directory stopping before stopping lmirror. [04:55] its not seeing the content for the last file [04:55] The directory is empty. [04:56] wireshark shows it being transmitted [05:00] Odd. On the server side, the sequence was `mkdir empty; cd empty; lmirror init test; lmirror serve test` [05:00] indeed [05:00] I'm tracking the bug down [05:01] ok, the content is being seen [05:01] client side I think [05:03] data is seen in the client socket [05:07] ah, found it [05:08] fixed [05:08] Should my symlink still work with a fresh bzr pull? [05:08] yes, though I haven't committed yet. [05:09] OK. Just let me know when :) [05:10] ok [05:16] persia: it should work now [05:19] lifeless: Indeed. empty mirror completed successfully. [05:19] persia: cool [05:19] Now that it runs, did you want me to actually test anything? [05:20] not especially. I mean if you wanted to init somewhere with a few 10's or 100's of GB's and mirror it around, that would be sweet. [05:20] but I wouldn't expect much insight from such local ops [05:20] I'd expect the behaviour to match what you can do locally. [05:21] So I suppose we need jpds, so I can pull against something sensibly large. [05:21] I don't have the disk space to do tests on that scale locally ;) [05:21] but i've tested with ~ 4GB datasets [05:21] found an issue in squid 3.0.8/32bit builds [05:21] but nothing in lmirror that was an issue [05:22] doko_: any recommendations for dealing with #554149? Supporting 8.04 LTS -> 10.04 LTS seems thorny. [05:25] 0_o quite some activity in here [05:26] may i ask why the cryptsetup package in Lucid is *still* a release candidate (rc2) when the stable release was released in Jan ? [05:28] I don't think anyone will know the answer [05:28] IIRC a lot of bugs were fixed, and the version packaged is no longer mirrored. cryptsetup-1.1.0-rc2 is in the repos between 2 and 4 there were substantial bugfixes and then the final non-rc cryptsetup-1.1.0 [05:28] crypt-0: 1.1.0-2 migrated to debian testing on Sunday, and lucid is pulling from testing. Given the volume of ubuntu-specific patches, it may be that this will not be upgraded for release. [05:28] we're in deep freeze [05:28] so any change is going to be reviewed rather closely [05:29] Given that lots of folks took Monday off for Easter, I don't think we're even behind, even if we weren't in freeze. Given the freeze, nothing is likely to happen prior to beta2, and may well only involve cherrypicks prior to release. [05:29] i mentioned it late jan on a mailing list [05:30] thats not an effective way to get things done [05:30] well will it *eventually* be upgraded like within the first month of the stable release? [05:30] Unlikely. [05:30] unless someone does the work to merge the debian and Ubuntu packages [05:30] and QA the result [05:30] It's more likely that some bits of it will be cherrypicked to address bugs. [05:30] and ask for a FFe for it, no. [05:30] *you* can do some / all of that work, if you like. [05:31] well where can i start? [05:31] Look at what's in 1.1.0-2 and what we have in Ubuntu and see if there are Ubuntu changes that need to be preserved. [05:32] ok [05:33] ScottK: hey [05:33] Hello lifeless. [05:33] ScottK: can you have a look at https://bugs.edge.launchpad.net/ubuntu/+bug/538946 [05:33] Ubuntu bug 538946 in ubuntu "FFe: Sync testrepository 0.0.3-1 (universe) from Debian unstable (main)" [Wishlist,New] [05:34] * ScottK looks [05:35] ScottK, nothing besides the shell scripts [05:35] Right, so the question is, are the changes needed. [05:35] Likely they are. [05:35] ill work on getting out 23/64 bit packages built soon after that where should i submit them for review? [05:36] ScottK, yes they are but the changes wont effect going from 1.1.0-rc2 to 1.1.0 [05:37] ScottK, so the scripts already in place will work like they do with rc-2 [05:37] will just need to be extracted and added to my package [05:37] crypt-0: Ideally you'd make a debdiff and attach it to a bug asking for the upgrade. [05:37] lifeless: minus points for edge urls, but approved anyway. [05:38] ScottK: thanks [05:38] ScottK: are you also an archive admin, to do the sync, or do I need to hunt someone else down ? [05:39] I'm an archive admin, but you need the "employed by Canonical and has shell access" kind for a sync. [05:40] lifeless: Alternately, you need about 6 weeks of code reviews to fix the bug in launchpad that makes that true, but you may not want to wait that long... [05:40] ScottK: ok [05:40] StevenK: ping; I wants a sync done :) [05:41] crypt-0: so, have you done a merge of the packages yet ? [05:41] crypt-0: if not, the wiki has good docs on merges - you need to do a merge. [05:43] ok [05:43] i will get to it [05:43] if you need pointers just shout === almaisan-away is now known as al-maisan [05:50] ScottK: yes, I'm planning to do a rebuild before the week-end, possibly earlier [05:51] lucas: Excellent. [05:51] lucas: I don't think I managed to reply to your mail for feedback, but I've found your rebuilds very useful. [05:52] lucas: Most particularly one case where I fixed a FTBFS that was caused by a problem in a library the package used and I was ably to use the symptom information you provide to find all the other affected packages. [06:49] Good morning [06:50] * mneptok hugs pitti [06:51] kirkland: I'm around now [06:51] * pitti hugs back mneptok; how are you? found some Easter eggs? [06:51] pitti: i tried looking for them, but the wife said a scalpel near her abdomen made her nervous, and said to stop. :( [06:52] that sounds a bit early in the processing chain indeed! [06:52] oh SURE! take HER side! [06:52] * mneptok pouts [06:52] mneptok: you forgot the ether [06:54] lifeless: we're in a recession. times are tough. i had to stop the ether and switch to "mallet." [06:54] brb ... police coming through the windows. [08:17] good morning [08:19] jpds: lifeless indicated you had some interesting data sets available to test lmirror. Please let me know what I might pull that would provide useful information. [08:26] persia: we're not quite ready for that; pending some machine setup [08:27] Oh well. rsync is is then. [08:30] hello, anyone affiliated with couchdb around? === zyga-nc10 is now known as zyga [08:34] mvo: hello [08:34] mvo: anything I can help you with today? [08:39] oh I fucking hate quilt [08:40] sladen: pssst language [08:40] zyga: hello! bug #549011 (probably pretty trivial, but it would be nice to refactor a little bit around it if needed) [08:40] Launchpad bug 549011 in software-center ""Canonical does not provide updates for ."" [High,Confirmed] https://launchpad.net/bugs/549011 [08:40] sladen: also, hello :) [08:40] sladen: try edit-patch instead [08:40] hey sladen and maco [08:40] hi mvo [08:40] sladen: ubuntu-dev-tools package [08:41] zyga: bug #437709 is fixed I think, but confirmation would be cool [08:41] Launchpad bug 437709 in aptdaemon "race in lock checking code" [Medium,Fix released] https://launchpad.net/bugs/437709 [08:43] zyga: and bug #540790 not sure what the best way forward is here, probably to offer a "reload" or "ignore" [08:43] Launchpad bug 540790 in software-center "handling of untrusted sources is suboptimal" [Medium,Confirmed] https://launchpad.net/bugs/540790 [08:44] mvo: could you please assign those bugs to me, it'd be easier to track if that's okay with yu [08:44] zyga: sure, thanks! [08:45] mvo: are you aware of the bug that software-center is not usable via keyboard (it's doing synchronous ops on keyboard up-down nav) [08:45] mvo: thanks, I'm checking my bugs now [08:46] zyga: what bit in particular does not work with keyboard? [08:46] mvo: try it, the app quickly hangs (turns gray on compiz) [08:46] mvo: it's probably doing something synchronously and it takes ages [08:47] mvo: just try moving down the list with keyboard [08:47] zyga: ok, so in the software-list? [08:47] zyga: the long listview? [08:47] mmm, yes I think so (if I understand you correctly) [08:48] I can reproduce this each time [08:48] from the initial screen, just scroll down with the arrow key [08:49] zyga: into any paricular category? or just scrolling around in the welcome screen? [08:49] mvo: this is reproducible in each screen, the welcome screen will do === steveire_ is now known as steveire [08:50] mvo: I didn't dig through the code yet, I could be wrong on the cause [08:50] mvo: maybe it's the resize of each list item that occurs [08:51] zyga: hm, I can reproduce it when going into "System", not not otherwise [08:52] mvo: my system is slower probably [08:52] mvo: I could record a video and show it to you if you'd like [08:53] zyga: that would be nice [08:53] mvo: in progress, just a moment [08:54] mvo: if you are aware of this problem and know LP # then I'll attach the video there [08:55] pitti, hi [09:02] mvo: I have the video, any place to upload this? [09:03] zyga: I don't have a open bug for this yet, please just open one :) [09:04] ok, moment please [09:08] hi tkamppeter, how are you? [09:11] mvo: #556290 [09:11] mvo: istanbul sucks, the video stopped after 20 seconds or so [09:22] mvo: got it [09:22] mvo: uploading [09:24] mvo: video attached, http://launchpadlibrarian.net/43226843/software-center-unresponsive-with-keyboard-navigation.ogg [09:25] zyga: thanks, its a wee bit small, but I can see the problem I think [09:26] mvo: in the future I think I will be able to capture video off-system [09:26] mvo: but for the moment in-system solution will have to do [09:27] mvo: basically I think the list should be smooth no matter how you navigate - can we make the buttons and other stuff overlay the list item without reflowing/resizing all other items? [09:28] zyga: its not trivial, the gtktreeview does not work well with non-fixed heights like this [09:29] zyga: we had a apply some trickery to make it somewhat fast (a special property) [09:29] zyga: see bug #514879 [09:29] Launchpad bug 514879 in software-center "details update very very slow" [High,Fix released] https://launchpad.net/bugs/514879 [09:30] mvo: how about we make the view fixed height [09:30] mvo: and then show a overlay window that has the details when you navigate or click [09:30] (focus) [09:32] zyga: interessting idea! if it overlays part of the row below you need to discuss that with mpt if that is ok with him, we have almost fixed-height performance, I wonder if the freeze bug comes from something else, some missing optimization in the way we use the treeview [09:32] mvo: I'll try to poke around, you are right - the first thing is to understand what's slow [09:33] pitti, fine [09:33] mvo: is it possible that there is something downloaded/read from file/ in a non-async way when you focus? [09:33] mpt: what do you think about this? [09:34] pitti, there are still complaints going around that CUPS does not start on boot/stop on shutdown. [09:34] tkamppeter: start on boot, too? that's totally independent from stopping on shutdown [09:35] mvo: what's the proper branch for hacking lp:software-center? [09:35] or some lucid-specific branch? === azeem_ is now known as azeem [09:38] pitti, no I have found the bug where there appeared a comment on the weekend: bug 497299, but now I see that the complaint is about Karmic, not Lucid. [09:38] Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299 [09:38] right, that's not cups specific [09:38] pitti, and it is CUPS startup. [09:40] zyga: lp:software-center is the right one [09:41] zyga: if you run it with --debug you should get a lot of info [09:41] zyga: its doing a lot of stuff async :/ [09:41] mvo: thanks [09:41] zyga: biggest is probably apt cache reading [09:41] mvo: python softwarecenter/view/appview.py [09:41] pitti, CUPS not shutting down I do not find in the moment, there was a bug report, but I do not know what got down about it. [09:41] if you run that [09:42] and move around [09:42] tkamppeter: I have a list of them, I'll triage them soon [09:42] tkamppeter: we can ignore those for now, I think [09:42] you can see that item view is changed slightly even though nothing visible is changed [09:43] zyga: good idea to test it in isolation - is that freezing for you as well? [09:44] mvo: yes, search for 'x' and scroll away [09:44] mvo: that's good actually :-) [09:45] ExecutionTime, neat [09:46] yeah, I use that all the time :) [09:49] geser: do you plan other ubuntu-dev-tools upload after beta-2 ? I just applied a fix for the bug that sladen had with edit-patch [09:50] pitti, I have also committed a small (trivial) fix to the CUPS BZR repo, to eliminate a warning in error_log. Can you upload CUPS before release? Thanks. [09:50] tkamppeter: yes, of course; I also committed an updated security fix, I'll do an upload right after beta-2 [09:50] it'll be well in time for final [09:50] pitti, and also what about taking in the 1.4.3 bug fix release of CUPS? [09:51] tkamppeter: if you can test it, please feel free to commit [09:51] mvo: There is almost always a last-possible-moment upload of u-d-t for changing defaults lucid/maverick, but upload earlier if you ave good bugfixes. [09:52] pitti, I do not have much time for testing, the OpenPrinting Summit is next week. [09:53] mvo: strange, if I scroll around I get http://pastebin.ubuntu.com/409920/ [09:53] persia: cool, thanks [09:53] zyga: its probably a artifact of it running in isolation, I can have a look [09:54] mvo: it doesn't happen all the time, just if you move around fast [09:54] mvo: yes, I plan to do at least one upload. [09:54] timing? [09:54] zyga: I guess [09:54] geser: cool, thanks [10:00] mvo: I added a logger to CellRendererAppView.draw and it keeps logging activity when I drag the window [10:00] mvo: maybe we can save some time with double-buffering? [10:03] zyga: good idea [10:03] mvo: do you know how to enable this on a widget tree? === radoe_ is now known as radoe [10:06] zyga: there is a gtk.Widget.set_double_buffered() call [10:06] zyga: but it should be default already [10:06] zyga: but maybe its not for some reason [10:08] mvo: I'll check this in a second, I found something strange with that Cache.ready and None on pango [10:08] mvo: I was moving up and down like crazy and I managed to make a ghost entry without any data inside, I have video [10:10] mvo: http://launchpadlibrarian.net/43229601/ghost-entry.ogg [10:12] hello, has anyone here worked on iptables? id like some feedback for an idea i had. you can view the idea here at https://wiki.ubuntu.com/GoogleSoC2010/ZubinMithra. Thankx in advance. [10:19] mvo: setting double buffered view on AppView doesn't help [10:20] mvo: either the view always draws cells for some strange reason (on purpose) or it's another bug that prevents this from working [10:21] zyga: I would not be suprised if its a issue with gtktreeview, I saw a lot of drawing in my custom models. I don't know if its a bug in the treeview or in the custom models, but I suspect the former [10:22] mvo: do we have gtk hackers to give us a hand in this? [10:22] mvo: the UI is really slow because of this [10:22] even on core i7 which is insane IMO [10:24] zyga: bratsche is the first who comes into my mind, gimpnet and #gtk+ is probably a good place [10:36] does anyone know if 'acpid' is still used for handling events like opening/closing a notebook lid? [10:38] TrueTom: only if gnome-power-manager/the KDE pendant aren't running [10:39] TrueTom: but not for lid closing, only for the power button [10:41] mvo: I managed to remove the slowdown by dropping other columns [10:41] mvo: interesting thing is that the Cache.ready issue is clearly reproducible so it's a separate problem [10:41] pitti: so is gnome-power-manager responsible for disabling the backlight of the screen when I close the lid? [10:42] TrueTom: no, it just tells the kernel to suspend, and the kernel does the rest [10:43] TrueTom: oh, if you disabled suspend-on-lid-close, it's gnome-power-manager, yes [10:47] mvo: can you please try to do one thing for me: run python softwarecenter/view/appview.py [10:47] pitti: how does gnome-power-manager know the lid is closed? its homepage states that it doesn't use pmud/acpid/apmd anymore but HAL (which isn't used in Ubuntu anymore!?) [10:47] mvo: and attempt to write "nethack", quickly [10:48] TrueTom: closing/opening the lid produces an input event now (SW_LID) [10:48] mvo: do you get "ehakctn" too? [10:48] TrueTom: so it just needs to listen to that X event [10:51] pitti: ah, didn't know that, thanks... i will test if that works... also, acpi_listen shows that there is no event generated when I close my lid but two when i open it... this seems broken but that isn't a problem since nothing is still using acpi anymore? [10:52] TrueTom: that sounds broken, indeed, hm; is the first event after lid opening the "close" event? [10:52] TrueTom: does the machine suspend in between? [10:52] zyga: yes [10:52] zyga: but only in that mode [10:52] zyga: no in s-c itself [10:55] pitti: i don't know... i couldn't find out how to parse the output from acpi_listen, however the output is the same for both events (minus the event counter) [10:55] pitti: the machine doesn't suspend (which works fine though) [10:56] pitti: the problem is that closing the lid doesn't disable the backlight but opening the lid again does [10:56] TrueTom: these effects sound related [10:56] pitti: then the backlight stays off and i have to reboot [10:56] pitti: yes, hence my question [10:57] I suppose it gets the "lid close" event only after opening [11:00] pitti: i agree... but eventually this is a problem with ACPI in the kernel? [11:04] TrueTom: right [11:06] pitti: ok, thanks... then i'm going to have to compile a kernel with acpi_debug=y... see you all in a few hours... ;) [11:28] mvo: I have some improved monitoring [11:29] mvo: it shows where execution time of nested ExecutionTime object exceeds given threshold, by default 1.0/24 seconds [11:29] mvo: it's quite easy to spot the slow part now === DrPepperKid is now known as MacSlow [11:48] mvo: hey! just wanted to let you know that the hardy->lucid upgrade problem the other day was a transient one [11:48] crimsun: just make it a depends. ubuntu always did ship the files in /usr/lib32, not in /emul [11:48] mvo: I tried the day after and it worked [11:50] mvo: now I have another problem though, dapper->hardy using the official Dapper AMI, https://pastebin.canonical.com/30087/ (seems a dependency issue as well) === MacSlow is now known as MacSlow|lunch [12:07] interesting mail from sg [12:07] oops wrong channel :) [12:13] seb128: https://bugs.launchpad.net/ubuntu/+bug/554652/+subscribe [12:14] Ubuntu bug 554652 in tracker "Panel menus/applets should present consistent behaviour" [Wishlist,Confirmed] [12:14] seb128: bug trackers are for tracking, bugs... [12:26] sladen, right, but opening lot of tasks on one bug does spam everybody [12:26] the people subscribed to any of the component get emailed for change to any of the components they don't care about in those cases [12:26] which still happens when the task you care about is closed [12:27]