[00:00] I would love to see some stats on exactly what percentage of users have -backports enabled [00:00] LaserJock: I'm not sure if rushing -updates helps right now, as we'd break anyone using unison as part of their migration effort to hardy. [00:00] (unless we rushed -updates of a new upstream to all supported releases, but that's tricky) [00:00] it just seems like a big issue to leave to -updates [00:01] -backports rather [00:01] mkrufky: the bug is currently marked as 'verification-needed'; a proposed fix is available but no one has confirmed that it works, could you please do this following the process on https://wiki.ubuntu.com/StableReleaseUpdates? [00:01] LaserJock: Yeah, well, exactly two developers (jdong and I) were paying attention to it at all, and neither of us noticed when Debian uploaded to request a sync. [00:01] but as you say, we could maybe copy from -backports to -updates [00:01] argh [00:02] mkrufky: since it's hardware-specific, we're more dependent than usual on users for the verification of the fix [00:02] slangasek: *I* proposed the fix [00:02] Anyone willing to review a merge proposal for ksimus - bug 225499? Thanks :). [00:02] Launchpad bug 225499 in ksimus "Please merge ksimus from Debian unstable to intrepid" [Undecided,Confirmed] https://launchpad.net/bugs/225499 [00:02] slangasek: i can propose it AND confirm it? [00:03] LaserJock: My thought was to get Unison into -backports and then copy into -updates from there. [00:03] mkrufky: yes - AFAICS there are currently /no/ confirmations that the package that was uploaded to -proposed correctly fixes the issue :/ [00:03] ScottK: why are we copying backwards-incompatible things into updates again? [00:03] mkrufky: so having your confirmation would put us well ahead of where we are now [00:03] that sucks, slangasek -- i cannot roll back to gutsy -- i am on hardy now [00:03] ScottK: that does have some good reasoning to it I guess, although ideally -proposed would be just as good [00:03] Jazzva: At this point in the cycle I'd be a lot more impressed with you getting the changed incorporated into the Debian package so we can sync it next month. [00:03] slangasek: im a kernel developer -- i have to stay current [00:04] mkrufky: ah :/ [00:04] ScottK: but my guess is that -backports has a lot more users than -proposed ;-) [00:04] LaserJock: Ideally, but the threshold to get into backports is lower and we can at least point people there if they have problems while we sort it out. [00:04] slangasek: i am one of the maintainers of v4l-dvb kernel subsystem, *and* I work for the hardware manufacturer of these boards [00:04] slangasek: is that enough? [00:05] mkrufky: well, what we're looking for is confirmation that the package that the kernel team uploaded really fixes the issue - that no mistakes were made integrating the updated firmware [00:05] slangasek: Would you be willing to please accept the unison source backport for hardy-backports? [00:05] can we really not find 3 people with said hardware to confirm the SRU? [00:05] ScottK: can it wait to Monday? [00:05] slangasek: in my experience, people report bugs when things are broken, and they keep quiet when things work. in the bug report, it was explained where to find the new firmware, and where to put it. i would assume that users simply installed the new firmware and decided to not care to report the success [00:05] slangasek: Yes. [00:05] IMO *wave business cards* ==> instant fasttracked updates out of standard procedures == wrong... [00:06] slangasek: :-( all i can say is that the 262144 firmware will no longer work -- we disabled it in the upstream kernel [00:06] jdong: Was that aimed at me or mkrufky? [00:06] and i cant roll back to gutsy ... [00:06] ScottK: not you [00:06] K [00:07] mkrufky: quite plausible, but then that leaves us stalled with regard to the SRU process; we don't push updates out to all our users, including the many users without this hardware (== bandwidth + download time), without at least getting some confirmation that it's a valid fix [00:07] jdong: im not trying to fastrack this -- i reported this over a year ago [00:07] ScottK: Ok, I'll try. Thanks :) [00:07] mkrufky: understood, but there is an established verification procedure [00:07] too bad nobody gave the attention while gutsy still was current [00:07] mkrufky: and I'm trying to understand if it's truly prohibitively difficult to find 3 people to test/verify the fix? [00:08] ScottK: then wait to Monday it shall; I'm quite thoroughly occupied with SRU triaging at the moment :) [00:08] No problem. [00:08] i gave my knowledge to the bug tracker, i gave the bug and i gave the solution. i am not offended if nobody wants to test it. it sucks for the users that dont know how to google for answers [00:09] slangasek: thanks for explaining [00:09] sure [00:09] * mkrufky goes home ... ttyl [00:09] oops [00:09] no.. [00:10] slangasek: another tidbit of info just crossed my desk [00:10] Hauppauge licensed these firmware imaged to canonical [00:11] Hauppauge gave canonical the correct firmware image, ubuntu found their own and shipped something other than what was agreed on the license [00:11] anyway, it doesnt matter -- hardy and intrepid have the correct images [00:12] hrm, does that imply there's no license to distribute this older firmware version? [00:12] ScottK: ping [00:12] ScottK: i see that vim as already been merged from sid [00:12] ScottK: and the change i wanted to add has ben already added [00:12] ScottK: so now i just need to ask for a backport? [00:12] also, if there's not a general license to /re/distribute the current firmware, then we may have a problem vis-a-vis the firmware's location in the archive... [00:13] a license + correct firmware was provided. ubuntu shipped other firmware. i filed bug 99107 immediately. saw no action. users send bug reports to v4l / dvb mailing lists, instead of launchpad // users get new firmware, everybody is happy [00:13] Launchpad bug 99107 in linux-ubuntu-modules-2.6.22 "Feisty ships with OLD cx2341x mpeg encoder firmware" [Undecided,Fix committed] https://launchpad.net/bugs/99107 [00:13] would have been nice to remove the intermediate step [00:13] for the future all is well [00:13] mkrufky: If you really want to verify, you might try installing it from a liveCD (doesn't affect the installed system) and reporting the success. [00:14] persia: good idea -- i'll do so over the weekend [00:14] anyway, we need not waste any more time on this today -- thanks for the info [00:15] gotta run... [00:34] What's the first entry of a ubuntu changelog? [00:34] (for a new package) [00:36] something like " * Initial packaging" [00:36] I think [00:37] * persia prefers " * Initial Packaging (LP: #nnnnnn)" [00:44] Although that doesn't actually close the bug when uploaded. [00:44] nxvl: Sounds right. [00:46] ScottK: No, but it provides a reference. The bit about not closing the bug is a bug, as I see it. [00:46] (plus it's good practice for looking at preparing a -1 for upload to Debian, where the bug does get closed) [00:47] Right. Wasn't suggesting it shouldn't be there, just that people should be aware that it didn't follow the principle of least suprise very well. [00:48] good evening folks [00:48] Principle of least surprise? Launchpad? [00:49] * persia likes launchpad, really, and is happy to use it, but finds it a constant source of surprise. In humans, this is a good thing, so with appropriate anthropomistion, LP must be good. [00:50] lol [00:50] jdong: nixternal successfully uploaded source backports today, so you may want to see if you have the powah too. [00:52] persia: I'll just say that my opinion of launchpad's design seems to be pretty consistent no matter which part of it I'm looking at. [00:52] ScottK: Ah. Then you're not surprised. [00:53] Some of the special ways tend to suprise me, but the overall tenor of the design is not suprising. [00:55] ScottK: oooh! [00:55] I'm not sure what to think about LP [00:56] I expect it's just for Universe packages jdong. [00:56] I've used bugzill a tad with Gnome and Fedora [00:56] ScottK: ok [00:56] and it seems ok, but not really spectacular [00:56] I'm used to RT [00:57] trac ftw [00:57] I suspect that the database engine part of it is really good. Keeping so much data synchronized with pretty low latency is a tough thing. [00:57] still finding out which buttons to push in LP :) [00:57] I just find the user facing part of it really hard to deal with. [00:57] I don't mind it too much [00:58] I could forgive a lot more if the U/I were just faster. [00:58] sometimes it's "nifty", sometimes it's "bummer", but in general it gets the job done [00:58] I don't seem to have any problems with UI speed [00:58] maybe it's the connection I'm on [00:59] I'm sitting on a 10mb internet pipe. I don't think it's that. [01:00] LaserJock: it's launchpad's fault [01:00] I'm on a 100mbit connection with a 78ms latency to their server [01:00] they take roughly 3-5s to answer any given bug tracker query for me [01:01] hmm [01:01] * cody-somerville blames python. [01:01] cody-somerville: I don't think that's it. [01:02] ScottK: There's no data to synchronise - it's all on one Postgres server. [01:02] I think with the amount of data some queries have to handle, it'd be hard to make it a whole lot faster. [01:02] I think it's excessive interest in a whizbang pretty web u/i and little interest in usability [01:02] cody-somerville: heh I doubt it's python, google seems to make it work just fine :) [01:03] jdong: 3-5s for searches? [01:03] jdong: Almost no user-facing code is Python, apparently. [01:03] Mainly internal development tools. [01:03] LaserJock: yeah [01:03] LaserJock: the minimum search time [01:03] hmm, I don't do many of those, let me try it [01:03] LaserJock: more complex queries take bloody longer [01:03] I just go to individual pages [01:04] Even with those. [01:04] Hey, how do I create a REVU account? [01:04] I look at a PTS package page and how fast that loads and an LP package page and the wait difference is substantial. [01:04] ffm: Join ~revu-uploaders, and upload something. [01:04] wgrant, I joined, but my auth is not accepted. [01:04] !revu | ffm [01:04] ffm: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU [01:05] ok, I guess I just did a search and it took 12s [01:05] ScottK: They're completely different. One has to perform DB queries, and one is static pages. [01:05] wgrant: That's an implementation detail. As a developer the perform similar functions for me. [01:05] the/they [01:05] One with waiting, one without. [01:06] True. [01:06] I guess speed just doesn't matter for me too much [01:06] Note that you can tell if it's LP or you by looking at the end of the HTML for any edge page. [01:07] "at least 59 queries issued in 12.04 seconds" [01:07] wgrant, the wiki page isn't too clear. [01:07] LaserJock: Ow. [01:07] Nice quick queries. [01:07] it's a bit of a slow day [01:07] ffm: You need to upload something before you get an account. [01:07] oh.... [01:08] wgrant: haha [01:08] that's a GREAT response time :) [01:08] I really like PTS [01:08] but overall Launchpad does quite a bit more [01:08] wgrant, is "Not running dinstall." a normal output message for dput? [01:09] though i'm not sure if all of it's needed [01:09] yes, that's normal [01:09] ffm: Correct. [01:09] LaserJock: It does do quite a bit more and it is also much better integrated. [01:10] I don't find BTS to be as easy to look at [01:10] But, at what cost. I mostly end up typing urls/tab completing to navigate, so all the whiz bang navigation features don't actually manage to help me much. [01:10] but it's got some good features [01:10] do the whiz bang navigation features get in the way? [01:11] IMO Malone is better than BTS, except for the slowness and lack of version tracking. [01:11] I think they're a big part of the page renderin gtime. [01:11] I tend to type out a full URL, like a source package, and then navigating from there. [01:11] wgrant: the version tracking was what I was thinking of [01:11] StevenK: me as well [01:11] StevenK: I think that's normal use. [01:11] Does anybody know how to get to a sourcepackage page otherwise? [01:11] ScottK: you think? I have no idea [01:11] wgrant: yes [01:11] Oh! How? [01:12] From the Launchpad front page [01:12] you go to the Ubuntu page [01:12] LaserJock: Mostly I know it seemed much slower after they rolled out the beta css based pages. [01:12] then search for the package [01:12] then find the right one in the search results [01:12] Ah, so that searches sources? [01:12] and binary I believe [01:12] Wow. [01:12] it can get really messy [01:12] does packages.u.c have a link to the launchpad page? [01:13] That's one fugly list. [01:13] Yes. It does although there's no guarantee that an exact match will even be in the first 100 results. [01:13] does anyone have any apps they used to query and interact with the LP platform? [01:13] azeem: No. P.U.C is not done by Canonical. [01:13] ScottK: Some of the time has to be attributed to Firefox's rendering, since it doesn't actually begin rendering until it has the full source in a parse tree [01:13] It also seems to think that it should put inexact matches first. [01:13] seems like there is at least two I saw for debian tracker [01:13] ScottK: but sponsored by it I thought [01:13] something, gui [01:13] azeem: no [01:13] azeem: no, djpig runs it up until now [01:13] (and he wants out :) [01:14] slangasek: he can do whatever he wants with a .u.c site? [01:14] well, ok [01:14] tbielawa: python-launchpad-bugs works sort of, but a proper Launchpad API is coming RSN® [01:14] And has been for ages. [01:14] azeem: he hosted it personally [01:14] azeem: I assume packages.u.c was a redirct [01:14] StevenK: True, but Firefox's ideas about rendering aren't new. They are an aspect of the system in which LP lives and should properly be considered in the design. [01:15] wgrant: I think it actually may be RSN :-) [01:15] Firefox's rendering isn't *that* sluggish. [01:15] LaserJock: It has been deferred repeatedly. [01:15] But we might see it for 1.2.5, I guess. [01:15] wgrant: I know, but I have semi-reliable sources [01:15] Konqueror wants all the images downloaded before it will show you anything (just to increase the fun factor). [01:16] ScottK: Even if you specify the size? [01:16] I haven't actually investigated it much. [01:16] I just watch the number of images increase in the lower left corner until it says x of x images downloaded and then the page appears. [01:17] wgrant: it's a library, that makes me sad. no app yet [01:17] jdong: btw, thanks for the HandBrake suggestion, today I got Bourne Supremacy and Pirates of the Caribbean on my iPod :-) [01:18] tbielawa: Correct. It's too slow. [01:18] LaserJock: fantastic to hear :) [01:18] LaserJock: now let's pounce on lucidfox the next time he comes in :) [01:18] LaserJock: he was the last person to attempt packaging it IIRC :) [01:19] oh, that would be nice [01:19] I went the route of least resistance and got the OS X version [01:20] lets hear some good stories. does anyone have any bug trackers they are quite fond of? [01:20] LaserJock: ah :) that's nice too [01:20] tbielawa: as a developer I enjoy /dev/null [01:20] it makes my life happier [01:20] :-| [01:20] I like gmail+tomboy :-) [01:21] * slangasek runs away [01:21] rofl [01:21] there are no boogs. [01:21] To put the speed/convenience question in perspective, yesterday I was checking Ubuntu diffs to see if I could request syncs and I just started looking at the Ubuntu patch in PTS rather than try to find anything out about the package from LP. [01:21] I like using OpenOffice Base [01:21] it's faster than launchpad [01:21] It was easy/faster. [01:21] (sadly that's probably true... too...) [01:21] oh this is neat, OOB [01:22] ScottK: it really bugs you that much? [01:22] I actually like bugzilla. [01:22] bugzilla isn't too bad [01:22] I can pull up the Ubuntu patch and review it faster than I can find the debian/changelog info in LP. [01:23] but to be honest I'm more confused by bugzilla's ui than I am with LP's [01:23] Yes. As U/I's go, the current LP U/I isn't extremely confusing. I just think it's more confusing than that pre-beta U/I. [01:24] So it's on a down hill slide. [01:24] anything Sourceforge is rough for me [01:24] There trackers aren't so great. [01:24] their email archives and bug tracking are uggg [01:24] SF is rough [01:24] Yeah. [01:24] admining a project there is sick nasty weird the first time [01:24] I've done a little with savannah, it's not too bad [01:26] nxvl: I don't understand your last follow-up to bug #189616 [01:26] Launchpad bug 189616 in dovecot "connection problems under load with hardy dovecot" [Medium,In progress] https://launchpad.net/bugs/189616 [01:32] Hey, my package hasn't appeared on REVU, and its been 30 mins. [01:37] Hello... [01:37] ffm: has it appeared now. You spoke just after an xx:30 [01:37] ffm: Hello... [01:37] sladen, No. [01:39] ffm: what was your upload? [01:39] last it there is kgrubeditor [01:39] sladen, "thinkcspy" was the package name. [01:39] what was your dput command to upload it? [01:40] sladen, [01:40] sladen, dput revu thinkcspy2_2.0.0alpha1-1_source.changes [01:41] ffm: Have you had the keyring synced since you joined the team? [01:41] slangasek: Surely s/i be/it be/, no? [01:41] wgrant, no, would that be an issue? [01:42] ffm: It would. [01:42] persia: tried that already, it doesn't clarify it for me :) [01:42] I'll sync it, then you'll need to try again. [01:43] slangasek: Ah. I read it as a request for the upload to the PPA to be reviewed and processed as a possible SRU. I may be mistaken, but it somehow seems wrong that if the software isn't working as shipped for that bug reporter that a custom fix is applied. [01:44] persia: oh, well, it certainly is in line for SRUhood, but turnaround on testing (since we're not to the bottom of the bug yet) is probably faster using a PPA for now [01:45] slangasek: Makes sense: I'm just trying to interpret the comment :) [01:45] persia: you may be right, thanks :) [01:51] wgrant, still no dice [01:51] but I'll wait a while. [01:52] ffm: The sync just finished. [01:53] 'da SRUhood :) [01:53] * jdong likes that [01:55] ffm: gpg: Can't check signature: public key not found [01:55] ffm: What's your Launchpad username? [02:02] wgrant, ~ffm [02:03] ffm: The key you used is not associated with your Launchpad account. [02:03] oops. [02:05] wgrant, fixed. [02:06] ffm: The keyring is resyncing. I'll advise you when to upload again. [02:07] slangasek: as i understand it, mathiaz fix it, and upload it on his ppa [02:08] slangasek: but i don't understand if he's going to include it on hardy or just publish the patch inthere [02:09] nxvl: he's provided a test package that will allow us to /verify/ whether we've identified the problem; we haven't gotten to the root of the problem yet [02:09] slangasek: oh! ok ok [02:09] slangasek: but did you know if mathiaz reproduced the problem? [02:09] wgrant, I don't have to resync my keys, do I? [02:09] slangasek: cause i can't [02:09] persia: I believe all MDT stuff is up and running on Intrepid now. [02:09] ffm: No. [02:10] nxvl: we think the problem is one of hitting a login limit, that wasn't enforced in the dapper version of dovecot [02:10] wgrant: Excellent. If you don't mind, I'll remove the "currently offline" :) How about UEHS? [02:10] nxvl: so mathiaz can reproduce hitting the limit, yes [02:10] ScottK: mm, i think i better wait until ibex+1 is announced and fix this "issue" on ibex [02:11] persia: I've already removed that. [02:11] slangasek: so, the problem is that the default value of the limit is rejecting connections? [02:11] persia: UEHS will take some time longer. It needs various extra bits and pieces like PostgreSQL. [02:11] * nxvl downloads the package [02:11] wgrant: Heh. I guess I hit cache. [02:12] nxvl: the problem is that a) there's no logging to let you know you've hit the limit, b) the enforcement of the limit is an upstream "bugfix" post-dapper that has effects that were surprising, c) login processes may or may not be reaping properly, we don't know yet [02:13] ffm: Try to upload again, please. Tell me when it's done, so I can process it immediately. [02:13] Ah, done already, I see. [02:13] slangasek: that's what i thougt [02:13] Regarding UEHS, not such a hurry: according to https://wiki.ubuntu.com/IntrepidReleaseSchedule we've about 9 weeks for open clears, and another 9 for reviewed clears. [02:13] wgrant, I just tried and got a 553 error [02:14] Gah, it just hit another indentation issue. [02:14] * wgrant fixes. [02:15] wgrant, done. [02:16] ffm: Yay, it didn't crash this time. [02:17] wgrant, woot [02:17] ffm: It's on revu.ubuntuwire.com now. [02:17] wgrant, I see. Thanks muchly. [02:17] * wgrant throws some whitespace at RainCT. [02:17] slangasek: so the fix for now is to warn the user about this issue but not to "fix" it? [02:18] nxvl: potentially so, yes [02:18] well - dovecot should log something when it hits the limit [02:18] so that it's easier to troubleshoot [02:19] slangasek: yes, but if i want a limit (i.e. 50 connection) i want that there is 50 conections, not less [02:20] slangasek: but that's an issue in dovecot, not ours [02:20] wgrant, so, how do I ask nicely for my revu to be revu'ed? [02:21] ffm: I don't deal with that side of things much, so I'm not sure. [02:21] Anyone else? [02:22] btw [02:22] ffm: No information has yet been announced for REVUing for intrepid. For hardy, there was a special day once a week (Mondays) during which there was a commitment to review packages, and some packages were reviewed more often. You might paste the REVU URL here, but I doubt many developers will be reviewing before UDS. [02:22] does anyone knows what was about the tread of splitting mentors in 2 groups? [02:22] persia: sis you remember this? [02:23] s/sis/did [02:24] nxvl: I think that our indomitable Mentoring Facilitator became swamped with the discrepancy between mentoring requests and mentoring offers, and hasn't had time to follow-up. [02:24] nxvl: currently, there's no evidence that the connection limit is lower than what is documented; part of the problem is that there are some perverse IMAP clients in existence that make multiple connections [02:25] slangasek: that's what i'm talking about [02:25] slangasek: i know the issue is on the clients [02:25] slangasek: but there must be any way to make it work as it is [02:25] s/is/should/ [02:26] persia: mm, that's bad [02:26] persia: it would be really nice to have pre-motu mentors [02:26] nxvl: if you mean associating multiple client connections with one another so that they don't count against the login limit, then I don't think that's either practical or reasonable [02:26] nxvl: Write up a plan and check with the Mentoring facilitator. There's a decent chance that you could be part of getting it implemented. [02:26] slangasek: mm, yes, you are right [02:27] slangasek: well, a warning should fix the problem, now the sysadmins know whats going on [02:27] persia: i will talk to norsetto tomorrow or in the worst case at UDS [02:28] * ScottK is still looking for some evidence that the mentoring program is helping. [02:28] persia: because i plan to become a MOTU this release cycle, and there are lots of things i must learn about being a motu [02:28] ScottK: don't [02:28] ScottK: there isn't any :D [02:28] ScottK: at least the way it is now [02:29] That's my expectation. I didn't think it was a great idea to start with and haven't seen anything to change my mind. [02:29] ScottK: as you said before, ubuntu-classroom should't exist as well as the motu-mentors list [02:29] ubuntu-classroom is different as that's for all kinds of things. [02:30] it only splits the community in contributors and developers [02:30] which shouldnt't happend [02:30] I'm not sure I'm opposed to the motu-mentors mailing list, but it's purpose has become confused with the MOTU Mentoring program. [02:30] persia: and what was about this 3th team you were proposing [02:30] persia: I don't see the need. [02:30] persia: the monkeys of the universe or something like this [02:30] I don't know what need motu-mentoring list provides that the regular motu-ml can't cover just fine. [02:31] ScottK: I believe the idea was to support assistance outside of IRC, so that if nobody here could answer the question, it could be asked somewhere. It's not used that way. [02:31] Right. I think that's on topic for the regular list. [02:31] I don't see a need to segregate such mails. [02:32] Back in a bit. [02:33] ScottK: Makes sense. Like I said, I'm not sure I'm opposed, whereas I was certainly opposed to how the MOTU Mentoring program started (although I can imagine there existing a solution) [02:35] nxvl: That was an available identity for Prospective Decelopers are listed on https;//wiki.ubuntu.com/UbuntuDevelopers, and might have carried some set of permissions to reduce the number of things a prospective developer need do to "sign up". I've been convinced that it's not that useful until LP-based mailing lists are more central, and the LP entitlements matrix is less opaque. [02:36] whoa [02:36] s/are/as/ [02:40] mm [02:41] that makes sense [02:41] well, i will wait until i feel ready to become a motu to start thinking in those things [02:44] * jdong grumbles about firefox mouse gesture usability [02:45] they implemented 8-way directions [02:45] nxvl: You might consider joining the new universe-contributors team. I think you've certainly got a good record of sustained contribution. [02:45] such that if you drag left and in the process go down 10 pixels, it registers as south-west-ish [02:45] is there a tolerance setting? [02:46] tbielawa: looking now, but settings are no excuse for poor defaults [02:46] jdong: I find that most of my Firefox usability issues are solved by using Konqueror. [02:46] ScottK: i was asking about it, it is already implemented? cause daniel was looking for a name for it [02:46] * nxvl opens LP [02:46] nxvl: Look at the archive for the motu council mail list. There are already several applications being processed. [02:46] diagonal tolerance: 60% [02:46] so if you're within 60% of what's considered a "diagonal" then it registers a diagonal. [02:46] jdong: Firefox is an example, IMO, that didn't know when they were done. [02:46] lovely. [02:47] ...dpkg was cool, simple -- effective... pdebuild is frustrating [02:47] *dpkg-buildpackage [02:47] tbielawa: pdebuild is more advanced though [02:47] Ya [02:47] tbielawa: it has to set up an entire virtual ubuntu install [02:47] I am forcing my7self to use it so I can make this intrepid build [02:47] tbielawa: and for that, it's MUCH better at testing [02:47] FF was supposed to be a simple/lightweight alternative to the Mozilla suite, but it hasn't been that for a long time. [02:47] tbielawa: from personal experience I've screwed up test build results before because my host system has a few 3rd party packages [02:48] using pdebuild/pbuilder is very important to proper development :) [02:48] jdong: so you figured out your pbuild pretty quick then huh [02:48] ScottK: firefox3 fixes most of their resource usage issues, but the hardy version shiped with some nasty bugs [02:48] such as the urlclassifier sync lag [02:48] ScottK: I do love konqueror. its UI is truly non-blocking threaded [02:49] tbielawa: There's a script in ubuntu-dev-tools called pbuilder-dist that assists in automating a lot of the pbuilder setup. You might look at that. [02:49] tbielawa: well it took me a while to get started with it but afterwards it becomes second nature [02:49] ScottK: ohhhhhhm I'll check that out right niow [02:49] FF 1.0 was great. The ones since then, not so much. [02:49] ScottK: mm, i will search documentation about the process :S === tbielawa is now known as tbielawa_smk_brk [02:51] damn i need to prepare my list of contributions and find some sponsors again [02:51] i will hit the motu council at UDS [02:51] :D [02:51] * nxvl loves prague [02:53] nxvl: UDS is precisely the wrong time to formally apply to the MC for anything. Best times are end-UDS through about BetaRelease. [02:54] persia: but at prague i can cry in front of you :D [02:55] nxvl: Well, if you really, really, really have a desire to do so. [02:56] persia: i'm just joking [02:56] at pregue i will present peruvian LoCo team to the LoCo Council, 2 presentations are quite to much for a week [02:57] * nxvl writes his applications for -contributors [02:57] nxvl: What's your LP ID? [02:58] persia: nvalcarcel [02:58] * persia can never remember how to spell valcarcel [02:59] persia: i have problem with your lastname too, so we are ok :D [02:59] nxvl: You already have all the rights and priveleges appertaining unto the -contributors team. Unless something changes, no point applying. [02:59] i do? [03:00] how? [03:01] oh! [03:01]