[01:59] <micahg> ScottK: (moving to a more OT channel), do you think it would make sense for a release exception, or should I try to push through backports?
[02:00] <micahg> SRU exception I mean
[02:01] <ScottK> I don't know the package well enough to have an opinion on if it should get an SRU exception.
[02:02] <Crak> what is a SRU exception?
[02:02] <micahg> ScottK: but I should try to go that route rather than backports first if it's totally broken, right?
[02:02] <ScottK> If it's totally broken, yes.
[02:02] <micahg> Crak: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[02:03]  * micahg wonders if youtube failures qualify as totally broken
[02:06] <Crak> and for this https://launchpad.net/bugs/739791 what would be the right way to update?
[02:12] <broder> micahg: what's the context here? i know i saw a comment from cjwatson recently that TB intended to establish a precedent that a more-invasive-than-normal SRU might be ok if it was needed to respond to external changes (i.e. youtube changing)
[02:12] <micahg> broder: gnash doesn't work with youtube since the API keeps changing
[02:13] <broder> yeah, that sounds like the sort of thing he was talking about.
[02:13] <broder> let me look briefly and see if i can find that comment
[02:15] <broder> micahg: http://irclogs.ubuntu.com/2011/03/10/%23ubuntu-meeting.html#t18:35
[02:15] <broder> (and a little above that)
[02:18] <micahg> broder: hmm, maybe this should be case by case rather than a MRE
[02:19] <broder> micahg: i can imagine a process parallel to MRE for "packages which rely on externalities and might change"
[02:19] <broder> but realistically i think that as long as ~ubuntu-sru agrees that that sort of thing is appropriate, you don't really need a special process for it
[02:21] <ScottK> You can shove almost anything in under the provision for SRU due to regressions.
[03:54] <MTecknology> so... what is the right way to send a sync request?
[03:55] <RAOF> requestsync ?
[03:56] <MTecknology> oooh... that's just too easy
[03:56] <MTecknology> This program only functions in a UTF-8 locale. Aborting.
[03:56] <MTecknology> :S
[03:56] <ScottK> Sure. IIRC we just did an SRU for ubuntu-dev-tools because requestsync quit working.
[03:57] <MTecknology> oh
[03:58] <MTecknology> ScottK: any chance you could make this easy for me and let me know what the title should look like so the release team can catch it?
[04:06] <micahg> MTecknology: does LC_ALL=en_US.UTF-8 requestync work?
[04:07] <MTecknology> nope
[04:08] <MTecknology> ubuntu_component, is that like universe?
[04:08] <RAOF> MTecknology: The way to get the release team to catch it is to subscribe ubuntu-release.  The title of the bug isn't particularly important; “Please sync $BAR from Debian $SERIES” is pretty common, though.
[04:09] <MTecknology> RAOF: they are subscribed but missed it
[04:09] <RAOF> For how long?
[04:09] <MTecknology> bug 729691
[04:12] <MTecknology> Sync nginx 0.8.54-4 (universe) from Debian unstable <-- close?
[04:12] <micahg> MTecknology: yep
[04:12] <micahg> put FFe: in front of it, so they know that there was one
[04:13] <micahg> MTecknology: do you have PPU for it?
[04:13] <MTecknology> PPU?
[04:14] <micahg> MTecknology: per package upload rights
[04:14] <MTecknology> oh, nope
[04:14] <micahg> MTecknology: otherewise, you need a MOTU ACK before the archive team will sync
[04:14] <MTecknology> I thought that's what Iulian Udrea (last comment) did
[04:15] <micahg> MTecknology: no, that's the FFe ACK
[04:15] <MTecknology> oh..
[04:15] <micahg> MTecknology: I assume you've done install tests?
[04:16] <MTecknology> heh... and that person just had a ping timeout :P
[04:16]  * micahg can do a quick build test and ACK it
[04:16] <MTecknology> micahg: yup, same version is in a ppa; there's been a few itty bitty bug fixes since then but nothing very note worthy
[04:16] <MTecknology> I'd really appreciate it
[04:18] <MTecknology> micahg: http://ftp.de.debian.org/debian/pool/main/n/nginx/nginx_0.8.54-4.dsc <-- if it helps
[04:19] <micahg> MTecknology: thanks, but pull-debian-source, FTW!
[04:19] <MTecknology> ooh... more dev tools I have yet to learn
[04:45] <micahg> MTecknology: just gave you a MOTU ACK :)
[04:45] <MTecknology> micahg: woohoo :D
[04:46] <MTecknology> micahg: thanks much
[04:47] <MTecknology> So all of a sudden in natty I'm getting this in failed build logs - checking for PCRE library location... configure: error: Could not find libpcre.(a|so) in /usr
[04:49] <MTecknology> same thing still builds perfect in lucid and maverick, but not natty :S
[04:51] <micahg> MTecknology: multiarch?
[04:51] <MTecknology> ya
[04:51] <micahg> MTecknology: the check is probably bad
[04:52] <MTecknology> oh...
[04:52] <MTecknology> I'll try it with pbuilder... maybe an update broke something
[04:53] <jmarsden> MTecknology: Apparently some folks invent their own check functions in configure.ac/configure.in, instead of using AC_CHECK_LIB ... I'm dealing with that in a package I am playing with (hoping to update) myself...
[04:54] <MTecknology> jmarsden: I'm playing with php
[04:54] <jmarsden> Hmmm.  PHP had better be buildable on Natty :)
[04:55] <MTecknology> i tried to grab the same package (dget) that's already used in natty, made one itty bitty non-source change, and that's happening
[04:55] <MTecknology> http://launchpadlibrarian.net/66946405/buildlog_ubuntu-natty-amd64.php5_5.3.5-1ubuntu4ppa1~natty_FAILEDTOBUILD.txt.gz
[04:57] <MTecknology> micahg: hm... I never knew your last name before..
[04:58] <jmarsden> MTecknology: If you grab the package and *don't* make your "one itty bitty" change, does it build OK?
[05:02] <jmarsden> MTecknology: I think that either (1) libpcre just went multiarch and that broke php's autoconf stuff (which is looking for /usr/lib/libpcre.{a,so} which won't work any more), or (2) your change broke it.  So the first step is deciding which of those is the issue you are facing :)
[05:03] <MTecknology> jmarsden: it'd be 1, if 2 broke it that wouldn't come until way way later
[05:03] <RAOF> Unless it did so accidentally.
[05:04] <MTecknology> my change was to package.dirs
[05:04] <MTecknology> I'd rather not check in pbuilder because that's about a 4hr build on my system
[05:05] <jmarsden> MTecknology: If it really is (1), then you are faced with digging into the autotools stuff used to build php and fixing it for multiarch.
[05:05] <MTecknology> zul: you around? :)
[05:05] <jmarsden> Unless you are an autotools expert, I'd guess that could also take you 4 hours :)
[05:05] <MTecknology> I'll start up my pbuilder and figure it out
[05:06] <MTecknology> jmarsden: someday I might know enough to pretend to be an expert about something good; but it sure as heck isn't today
[05:09] <jmarsden> :)  OK.  I've just done apt-get source php5 in a Natty VM, it grabbed 5.3.5-1ubuntu4 .  Let's see if it builds for me.
[05:12] <jmarsden> Eeek... it has a lot of build-deps!
[05:12] <MTecknology> that /etc/sudoers issue isn't fixed yet from maverick->natty..
[05:12] <MTecknology> jmarsden: yuppers....
[05:16] <jmarsden> MTecknology: issue is on line 23497 of the configure script of php5 where they implement their own test for whether libpcre is around... sigh... more multiarch breakage.
[05:17] <jmarsden> BTW, that's *quite* a configure script... 116K lines of it :)
[05:19] <RAOF> MTecknology: It's gone mad and duplicated autotools functionality in a way that's broken by multiarch.  See ext/pcre/config0.m4
[05:19] <MTecknology> jmarsden: is it just my view, or are the first few hundred lines empty...
[05:20] <MTecknology> and like a million other excessively empty lines..
[05:20] <jmarsden> They are indeed.  Some wierd artifact of how autotools generated it, I expect.
[05:20] <RAOF> MTecknology: A quick & simple solution would be to change the pcre path in debian/rules.
[05:21] <MTecknology> RAOF: for a quick dirty fix... I was just commenting out the test :P
[05:22] <RAOF> That's... actually quite likely to work :)
[05:22] <MTecknology> i need to lay off the beer...i'
[05:22] <MTecknology> ll be finishing a 24pk in 2 days...
[05:23] <MTecknology> RAOF: not lintian clean; lintian dirty :P
[05:33] <jmarsden> MTecknology: 24 beers in 2 days... I'm surprised lintian doesn't output  W: Excessive beer consumption :)
[05:34] <MTecknology> i'm not drinking anything heavy thouhg; just budweiser; not too horribly much tequila, rum, mojito on the side
[05:35] <RAOF> Less, better quality beer.  It's the way of the future!
[05:36] <MTecknology> there's a 'Broad Axe Stout' from a microbrewery/diner near here that's absolutely amazing; but $5 each is beyond what I can afford right now
[05:37] <MTecknology> and that doesn't let me keep myself nearly tipsy for the part of the day i'm awake
[05:39] <MTecknology> wow... ubiquity and i do not get along
[05:53] <jmarsden> MTecknology: Are you going to file an FTBFS bug about php5 and the libpcre test?  (Also, do you expect to create a "not-all-that-dirty" fix for it yourself?)
[05:53] <MTecknology> jmarsden: I can surely file the bug; but the not-dirty fix might be a bit beyond what I'm capable of tonight
[05:54] <MTecknology> not the beer, the whole crying thing, I can't concentrate on teh screen long enough to think something trhough fully
[05:54] <jmarsden> OK, that works.  You create the bug.  If I have time tomorrow night and there's not a fix attached to the bug, I might have a go at it.
[06:01] <MTecknology> jmarsden: I'm assuming bug 739977is detailed enough.
[06:02] <MTecknology> mostly summarizing what you said :P
[06:03] <jmarsden> Looks fine to me.  I have a script from debuild run on the unmodified source package I'll attach to it too.
[06:15] <RAOF> I think I know how to fix it.
[06:16] <MTecknology> RAOF: fixitfixitfixitfixitfixit
[06:17] <jmarsden> If there is a way to generate the "tuple" for the currently running system, I have an idea too... but will happily let RAOF fix it :)
[06:18] <RAOF> Say hello to DEB_BUILD_HOST_ARCH :)
[06:18] <jmarsden> Ah!  I was playing with archdetect but not getting what I wanted out of it :)
[06:19] <MTecknology> hm?
[06:19] <MTecknology> something else to learn
[06:20] <RAOF> Actually, that's probably a bit wrong, but it'll be something like that.
[06:21] <jmarsden> MTecknology: The multiarch stuff puts libraries under /usr/lib/i386-linux-gnu or similar... we need a way to generate the right "i386-linux-gnu" tuple for the current build system, so we can test the right place for the library...
[06:21] <RAOF> Oh sweet lord, evolution.  Do you *really* need 2.1GiB resident?
[06:21] <lifeless> RAOF: yes
[06:22] <RAOF> It's only 2.1 because a substantial part /has been swapped out/
[06:25] <jmarsden> RAOF: $DEB_HOST_MULTIARCH :)
[06:25] <RAOF> $DEB_HOST_MULTIARCH?  Win.
[06:26]  * RAOF leaves it for jmarsden 
[06:26] <jmarsden> OK, can do.
[06:28] <jmarsden> Hmm, there is also $DEB_BUILD_MULTIARCH -- do I care which one I use?
[07:32] <jmarsden> MTecknology: OK... got it fixed... and now it fails a little later with: checking for DB4 major version... configure: error: Header contains different version
[07:33] <MTecknology> jmarsden: php is such a lovely package, huh?
[07:33] <jmarsden> Really!
[07:34] <MTecknology> :P
[07:34] <MTecknology> mediawiki is a huge pita....
[07:51] <jmarsden> MTecknology: I've used it, but not had to package it.  The DB4 thing in php5 is another "multiarch breaks their funky configure script" issue... working on a fix now...
[07:53] <MTecknology> jmarsden: glad you know; i'd fumble cluelessly and break something else
[07:53] <jmarsden> Grin... doing this makes me think I should apply for MOTU one of these days :)
[07:53] <MTecknology> I'm not trying to package mediawiki; i'm trying to make it not break; the source is uses is ugly as heck
[07:54] <MTecknology> every half second it hits a php error or notice or something
[07:55] <jmarsden> MTecknology: That kind of think I have seen in addon modules for Mediawiki, but not so much in the Mediawiki code itself.
[07:55] <jmarsden> s/think/thing/
[07:56] <MTecknology> I suppose I didn't look where specifically they're coming from; that could be the case
[07:59] <jmarsden> On one server I help admin we accidentally filled up /var/log because of that -- apache log rotation wasn't turned on, or wasn't rotating daily, or something...
[07:59] <MTecknology> nginx logs aren't rotating correctly on this system; not completely sure why
[08:00] <MTecknology> cron is running, but logrotate doesn't seem to run
[08:01] <Rhonda> hmm
[08:01] <jmarsden> You can do  logrotate -d /etc/logrotate.conf    or similar, to see if you have logrotate itself configured the way you want...
[08:01] <MTecknology> I just an hour ago forced logrotate to run and some of the log files were a few GB
[08:02] <MTecknology> looks like that was just fine
[08:02] <jmarsden> Hmmm.   Permissions on /etc/cron.daily/logrotate ?
[08:03] <MTecknology> -rwxr-xr-x 1 root root 89 2010-07-08 12:13 /etc/cron.daily/logrotate
[08:03] <MTecknology> root     17927  0.0  0.1   2304   896 ?        Ss    2010   0:23 cron
[08:04] <jmarsden> Looks sane to me.  Do other scripts in /etc/cron.daily/  run as expected?
[08:04] <MTecknology> oh.....
[08:05] <MTecknology> old bug...
[08:05] <MTecknology> jmarsden: thanks! :D
[08:05] <jmarsden> :)
[08:06] <MTecknology> a simple little rm, all better
[08:07] <jmarsden> Wow, this php5 thing is getting annoying... fixed DB4, now libpng has what will presumably turn out to be a similar multiarch problem!!
[08:07] <MTecknology> all that gets to be turned into a patch?
[08:16] <jmarsden> Looks like it, yes.  well, a set of patches.  But I'm stopping for the night, it is  01:15am here... I'll attach my two patches so far to the bug.
[08:21] <dholbach> good morning
[08:27] <MTecknology> jmarsden: alrighty, g'night
[08:27] <MTecknology> dholbach: g'morning
[08:27] <jmarsden> MTecknology: goodnight
[08:28] <dholbach> hi MTecknology
[08:29] <MTecknology> I should stop drinking for the day and go to sleep....
[08:32] <MTecknology> dholbach: what ya been up to?
[08:33] <dholbach> MTecknology, I'm waking up :)
[08:34] <MTecknology> but it's 03:34; it's go to nap time
[08:38] <MTecknology> jmarsden: wow... that looks like some ugly stuff :P
[08:39] <dholbach> hey mok0
[08:39] <dholbach> how are you doing?
[08:40] <jmarsden> MTecknology: Well, sort of.  Just one line patches to (m4 templates for) shell scripts.  It could be a lot worse :)
[08:42] <MTecknology> dholbach: me?
[08:43] <dholbach> I was saying hi to mok0 and seeing how he was doing - but how about you?
[08:43] <MTecknology> jmarsden: I wonder how much of that configure script could be taken out; something like 40k blank lines and a bunch of ugly stuff going on in there; I didn't actually look at your fixes yet
[08:43] <mok0> dholbach: hi :)
[08:44] <mok0> I've started using the evolution chat client, but it doesn't beep me
[08:44] <dholbach> how's life apart from that?
[08:44] <jmarsden> MTecknology: That configure script is generated at build time, so to do it right you'd need to rework the entire thing... I don't think anyone is going to step forward to do that :)
[08:45] <mok0> dholbach: busy
[08:46] <mok0> dholbach: We should meet and discuss the documentation stuff
[08:46] <dholbach> yeah - sounds like a good idea
[08:47] <mok0> dholbach: I'm getting these merge requests but I'm not sure if I'm supposed to do anything
[08:47] <dholbach> mok0, checking and commenting on them would be a good start ;-)
[08:48] <mok0> dholbach: right, but some of the fixes are trivial...
[08:48] <dholbach> in my mind that should even make things easier :)
[08:48] <mok0> dholbach: there's not much point in a comment: "yes, it's a very good idea with a comma there" :-)
[08:48] <dholbach> but you're right - we should definitely have a meeting and talk about it
[08:48] <dholbach> we obviously don't have enough folks reviewing stuff yet ;-)
[08:49] <dholbach> "Vote: approve" :)
[08:49] <mok0> dholbach: ok :-)
[08:49] <dholbach> ok, maybe not for obvious typos - but generally I like us peer-reviewing stuff
[08:49] <mok0> dholbach: absolutely
[08:50] <mok0> dholbach: what about the css? The HTML looks dreadful
[08:50] <TeTeT> hi, a question on install in cdbs, I need to ship a file that is rw by root only. When I just add it to the install file, it gets rw-r--r-- permissions. How to change that? Using post install looks unclean to me
[08:50] <dholbach> mok0, yes, let me file a bug about that
[08:51] <mok0> TeTeT: post install is ok
[08:52] <dholbach> done
[08:52] <mok0> TeTeT: cdbs has hooks you can use
[08:53] <cdbs> TeTeT: I'd recommend postinst
[08:53] <mok0> dholbach: great. In the meantime, I approved your --gen-key fix
[08:53] <dholbach> pushed
[08:53] <cdbs> TeTeT: atleast that's what I have seen in other packages
[08:54] <TeTeT> cdbs + mok0 : thanks!
[08:54] <mok0> TeTeT: see? cdbs is very advanced, even has IRC capabilities :-)
[08:54] <TeTeT> he he
[08:54] <cdbs> yes
[08:54] <cdbs> but DH is even more advanced!
[08:54] <mok0> cdbs: huh?
[08:55] <cdbs> mok0: cdbs sucks, dh is way better
[08:55] <cdbs> at times
[08:55]  * mok0 has gone back to hand-crafted rules files
[08:56]  * mok0 is also staying away from sucky-sucky 3.0 (quilt)
[08:56] <cdbs> mok0: That's actually quite good
[08:56] <mok0> cdbs: no it's not
[08:56]  * cdbs prefers 3.0 (quilt) over all others
[08:57] <mok0> I like some of the ideas, but splashing debian/patches with automated diffs is a TERRIBLE idea
[08:58] <mok0> You get a whole bunch of crap in there that you don't want
[08:58] <mok0> autogenerated files and what have you
[08:59] <mok0> I also hate the fact that patches are applied when you unpack the source package
[09:00] <mok0> cdbs: I see you've laid down arms :-)
[09:00] <cdbs> mok0: That's actually good
[09:00]  * cdbs was busy on other things
[09:00] <mok0> cdbs: what's good
[09:00] <cdbs> mok0: Its way better than simple-patchsys or dpatch
[09:01] <cdbs> mok0: And, having patches applied is nice, you get  a fully functional package
[09:01] <cdbs> it automates many things whne you work with large packages
[09:01] <cdbs> with some 15-20 patches
[09:01] <mok0> cdbs: I prefer going quilt push -a myself
[09:02] <mok0> and I hate .pc being part of the package
[09:02] <cdbs> mok0: It gets properly cleaned
[09:02] <cdbs> when you run debuild -S
[09:02] <cdbs> and stuff...
[09:03] <mok0> cdbs: I still think the design is flawed
[09:03] <mok0> to put it nicely
[09:06] <mok0> cdbs: It'd be much better to put the diff as a separate file in the source package
[09:06] <cdbs> that would be ugly and wierd.
[09:07] <mok0> cdbs: yes, because you don't want those diffs anyway
[09:08] <mok0> cdbs: so whenever I'm working on a package, I need to unpack the debian tarball somewhere, cd into the patches directory to figure out what junk is in the autogenerated diff, so I can get rid of it.
[09:08]  * cdbs g2g
[09:10] <mok0> dholbach: re merge/54161
[09:10] <dholbach> mok0, yep, what about it?
[09:10] <mok0> dholbach: the error Jim points out has been fixed?
[09:11] <mok0> oh yes it has
[09:11] <dholbach> yeah
[09:11] <mok0> dholbach: never done a review before, figuring out how it works
[09:12] <dholbach> you're doing great :)
[09:12] <mok0> dholbach: what is "review type" ?
[09:12] <dholbach> I think you can just ignore it
[09:12] <mok0> dholbach: ok
[09:12] <dholbach> it's if you want a special "ui review" or something
[09:12] <mok0> I see
[09:13] <mok0> dholbach: so now what? Is the approved merge performed by LP?
[09:14] <dholbach> no, I just pushed the change to LP
[09:14] <dholbach> it should be in trunk now
[09:14] <mok0> dholbach: ah, so _you_ have to do something
[09:14] <mok0> dholbach: can't you push before it's approved?
[09:16] <dholbach> sure I could
[09:17] <dholbach> it's up to teams to set up their own review policy
[09:17] <mok0> dholbach: I see
[09:17] <dholbach> but I like reviewing everything
[09:17] <mok0> dholbach: what about the review I requested. How do I fix your comments? Request another review?
[09:17] <dholbach> it's not only about making sure that we don't have typos and bugs, but also about learning more
[09:17] <mok0> dholbach: I agree
[09:18] <mok0> (trying to learn how the review system works)
[09:18] <dholbach> mok0, push fixes to your branch, and request another review
[09:18] <dholbach> ("resubmit proposal" the link is called I think)
[09:18] <mok0> dholbach: ah ok
[09:18] <mok0> dholbach: I'll try that today
[09:18] <dholbach> I liked peer reviews a lot when I worked on harvest and loco-directory
[09:19] <dholbach> I learned loads :)
[09:19] <cjwatson> broder,micahg: that kind of thing was indeed one of the things that we were aiming at
[09:19] <mok0> dholbach: I'm looking forward to it
[09:19] <cjwatson> there's no point in an ivory tower of perfect stable software that no longer works because the world has moved on
[09:20] <dholbach> and I like lp merge proposals a lot too - much better than sending patches over and over again :)
[09:20] <mok0> dholbach: absolutely... it was just not clear to me how it works
[09:20] <dholbach> yeah, it takes a bit to get the hang of it
[09:21] <mok0> LP's interface is sometimes difficult... you have to search for a tiny little link somewhere.
[09:22] <dholbach> if you have your local branch and pushed it, you can use "bzr lp-open" to open it in a browser (not sure if you knew already)
[09:22] <mok0> dholbach: I didn't :-)
[09:22] <mok0> cool
[12:54] <equalizer> Hi, I've uploaded my package to revu ten days ago: http://revu.ubuntuwire.com/p/equalizer
[12:54] <equalizer> I understand this is the place to ask for reviews - so can somebody please have a look or tell me what else I have to do?
[13:39] <JackyAlcine> Is it a good idea to package an Java application?
[13:52] <JackyAlcine> I guess no.
[14:25] <Bachstelze> JackyAlcine: why not? It'a good idea to package any application that is not packaged yet :)
[15:31] <CarlFK> This is about 3 years old: http://packages.ubuntu.com/natty/libtheora0  1.1.1+dfsg.1-3 "...merging of code from the Thusnelda branch."
[15:31] <CarlFK> current is:  libtheora 1.2.0alpha 20100924 (Ptalarbvorm)
[15:32] <CarlFK> hmm, I am guessing 'alpha' is keeping this from being used..
[15:32] <CarlFK>  back to #theora
[16:07] <Hans-Bit> hi
[16:59] <c2tarun> is there any tutorial available for packaging from scratch? I mean adding documentation and everything?'
[16:59] <micahg> c2tarun: https://wiki.ubuntu.com/PackagingGuide/Complete
[17:58] <smallfoot-> i want firefox 4!!! ITS OUT RELEASE FINAL TODAY!!! PUT IN REPO NOW!!
[18:00] <ari-tczew> smallfoot-: calm down. developers will publish firefox 4 when it's ready with packaging.
[18:00] <smallfoot-> ok
[18:00] <smallfoot-> when is ready with packaging?
[18:00] <Rhonda> when it's ready
[18:00] <ari-tczew> smallfoot-: then it's ready.
[18:00] <ari-tczew> Rhonda: hehe ;)
[18:01] <smallfoot-> it will come for ubuntu 10.10 too?
[18:01] <ari-tczew> perhaps
[18:01] <smallfoot-> or i must wait for 11.04 while everyone else is having fun with the new ff4?
[18:01] <ari-tczew> but not sure
[18:02] <Rhonda> There is always the possibility of a backport
[18:02] <smallfoot-> cool, i hope so
[18:02] <smallfoot-> i dont want be stuck with old ff3 while everyone else is enjoying the new ff4
[18:03] <Rhonda> including the all new bugs, right :)
[18:03] <ari-tczew> smallfoot-: IMO ff4 is not that cool as you think.
[18:03] <ari-tczew> 3 cards with basic pages and it takes ~90 MB of memory.
[18:03] <ari-tczew> rofl
[18:03] <smallfoot-> it has html5
[18:04] <ari-tczew> "wow"
[18:04] <Rhonda> Well, html5 actually is nothing to belittle, ari
[18:04] <smallfoot-> it has WebGL
[18:04] <chrisccoulson> smallfoot-, ari-tczew, Rhonda - firefox 4 final is already in the archive for natty (since yesterday) ;)
[18:04] <ari-tczew> as I use ff4 myself, I encourage to _try_ to use google chrome
[18:05] <ari-tczew> but I was wondering - is google chrome a path to be tracked? ;)
[18:05] <smallfoot-> chrisccoulson, cool, i didnt know ff4 was out yesterday
[18:05] <chrisccoulson> smallfoot-, it wasn't
[18:05] <chrisccoulson> but the final RC was built on friday
[18:05] <chrisccoulson> and that became the final release today
[18:06] <smallfoot-> oh
[18:06] <ari-tczew> chrisccoulson: smallfoot- asked whether ff4 will be in maverick.
[18:06] <smallfoot-> no change from final rc to final release?
[18:06] <smallfoot-> yes, i want in maverick
[18:06] <chrisccoulson> smallfoot-, no, the RC is the build they fully intend to release, once it's had some testing
[18:06] <smallfoot-> oh
[18:06] <smallfoot-> okie
[18:07] <micahg> smallfoot-: https://launchpad.net/~mozillateam/+archive/firefox-stable
[18:07] <chrisccoulson> so, there is no change between rc2 and final (it's exactly the same build)
[18:07] <smallfoot-> it has same build id, rev id, major, minor, rev version number, build number?
[18:07] <smallfoot-> oh
[18:07] <chrisccoulson> smallfoot-, yes. it's identical in every way
[18:08] <smallfoot-> okie
[18:08] <smallfoot-> i have 10.10 maverick, i will get ff4 too?
[18:08] <micahg> smallfoot-: I just gave you a PPA link to get it in maverick
[18:10] <smallfoot-> micahg, thanks
[18:10] <smallfoot-> will it be in official repo?
[18:11] <micahg> smallfoot-: we'll do some type of update eventually, not sure which version or when yet
[18:11] <micahg> any further questions should probably be in #ubuntu-mozillateam as this is way OT for this channel
[18:12] <smallfoot-> ah okay thanks
[18:49] <lfaraone> chrisccoulson: wow, thanks for the fast response+fix on bug 739416!
[18:50] <chrisccoulson> lfaraone, yw. although, it's something i've been thinking about for several weeks already (because of bug 709216)
[18:51] <lfaraone> ubottu: so I assume we can now mark that bug as fixed?
[18:51] <lfaraone> chrisccoulson: * so I assume we can now mark that bug as fixed?
[18:51] <chrisccoulson> lfaraone, it's still open with a tbird task, as the long term fix is to not use gnome-vfs at all
[18:51] <lfaraone> hm, mk.
[21:35] <ari-tczew> micahg: does this page work for you? http://reports.qa.ubuntu.com/reports/bug-fixing/community-natty-fixes-report.html
[21:36] <micahg> ari-tczew: yes
[21:36] <ari-tczew> micahg: does it load full context?
[21:37] <micahg> ari-tczew: no, I'd suggest filing a bug against the ubuntu-qa-website project
[21:37] <ari-tczew> micahg: that's right.
[22:10] <ari-tczew> bdrung, geser, persia, Laney, maco: if on next meeting Sylvestre will be absent, please investigate in my comment in his application.
[22:12] <maco> ari-tczew: an email to the dmb list may ....wait no, because Laney and i still aren't on it -_-
[22:12] <Laney> I imagine all DMB members take account of comments written on application pages
[22:13] <ari-tczew> Laney: even if person is absent?
[22:13] <Laney> what do you mean?
[22:13] <Laney> If the applicant is absent then the application won't be heard
[22:13] <bdrung> ari-tczew: we normally defer an application if the applicant isn't there
[22:15] <ari-tczew> Laney: I mean that I want to get my comment reviewed, whatever he is present or not
[22:15] <ari-tczew> because I think it's important
[22:17] <cody-somerville> ari-tczew, Then I recommend sending an e-mail to the DMB list (and CCing maco and Laney since they're not yet a member of the mailing list).
[22:17] <Laney> I'm not sure what we can do besides address it when the application comes up
[22:18] <Laney> it would be rather unfair to discuss a specific case in public without giving the applicant a chance to speak
[22:18]  * Laney prods the sysadmins about the dmb list
[22:18] <cody-somerville> Laney, Do you know if an RT ticket was opened for that? If so, whats the ticket number? I can probably get it moved along.
[22:18] <ari-tczew> Laney: omg, I just want to know that DMB members know about this case...
[22:18] <ari-tczew> but I will send list to dmb
[22:19] <Laney> ari-tczew: We do. Members read all applications.
[22:19] <Laney> cody-somerville: It's rt#16775; just pinged the 'vanguard'
[22:22] <AlanBell> debfx: seen bug 738330
[22:22] <Laney> cody-somerville: Apparently it requires managerial approval, so ... if you know a friendly manager with some time to spare ;-)
[22:24] <debfx> AlanBell: yes, see comment #8 on that bug report
[22:25] <cody-somerville> Laney, Is that the reply you just got from the vanguard?
[22:26] <Laney> yeah
[22:26] <Laney> because it's a 'sensitive list'
[22:27] <cody-somerville> Laney, I see the ticket is to add new administrators to the list. Have you asked the TB to add you and maco since they appear to manage the list?
[22:27] <Laney> only persia has admin privileges
[22:27] <Laney> apart from, I assume, the global listadmins
[22:28] <Laney> arguably the TB should already have the administrative password, but... that's another matter
[22:28] <Laney> s/already//
[22:28] <micahg> Laney: if you ask the TB, someone should be able to manually add you to the list
[22:28] <micahg> worst case
[22:29] <Laney> that's what I'm saying — I don't think they can
[22:29] <AlanBell> debfx: ah yes so you did :)
[22:29] <micahg> did mailman stop using flat files?
[22:29] <Laney> cjwatson can correct me here, but I believe that he previously held the list admin password and has since handed it over to persia
[22:29] <Laney> I don't think TB members have access to hack the configuration
[22:30] <AlanBell> debfx: should the ose-guest-x11 include 3d support?
[22:32] <debfx> AlanBell: yep, there is no difference feature-wise
[22:32] <maco> Laney: i think micahg's referring to filesystem level hackery instead of logging in through the mailman ui
[22:33] <maco> i just pinged mdz asking whether he could. we'll see
[22:33] <Laney> maco: I know, but I doubt TB membership confers that kind of shell access
[22:33] <micahg> maco: :D
[22:33] <Laney> they can probably approve the request though.
[22:34]  * cody-somerville is working on this.
[22:35] <Laney> cool
[22:41] <AlanBell> debfx: yay, I have unity in 3d again, thanks!
[22:53] <cody-somerville> Laney, Okay. I believe you should be approved now (or will be very shortly). Can you confirm?
[23:29] <Laney> cody-somerville: yeah, worked. Thanks!
[23:29] <cody-somerville> You're most welcome. :)
[23:29] <Laney> We should still get a second moderator for dmb and devel-permissions though, and my offer to do it still stands
[23:30] <Laney> it's especially important for devel-permissions as it moderates mail from non subscribers, and I understand that sometimes applications get held up due to that
[23:36]  * cody-somerville nods.
[23:36] <cody-somerville> Laney, I suggest bringing that up on the ML/next meeting.
[23:37] <cody-somerville> Okay, weird. Vanguard just said he hasn't actually got around to approving you yet. Are you sure you're approved Laney? :P Can you double check?
[23:59] <cody-somerville> Laney, maco: Okay, you should both now be subscribed to the dmb and devel-permissions mailing lists. You're also both moderators though I think you'll need to get the password from persia.