[00:02] <bdrung> cjwatson: you are fast!
[00:04] <cjwatson> eh, you got lucky :)
[00:05] <cjwatson> it'd be a bad idea to release binfmt-support 2.0.0 while slightly drunk, right?
[00:05] <directhex> cjwatson: depends, do you like living dangerously?
[00:06] <cjwatson> ish
[00:06] <cjwatson> I think on balance perhaps not tonight
[00:07] <sebner> cjwatson: pre-alpha is perfectly fine for drunk uploads! :P
[00:09] <cjwatson> maybe not so much for uploads that involve complete rewrites
[00:10] <sebner> heh
[00:11] <cjwatson> directhex: do you use binfmt-support very much, or do you just basically assume it works?
[00:11] <cjwatson> (out of interest)
[00:12] <jono> which package do I file bugs against for the installer?
[00:12] <jono> for the GTK UI
[00:12] <cjwatson> ubiquity
[00:12] <jono> thanks cjwatson
[00:12] <directhex> cjwatson: i ignore its existence, and just run ./foo.exe without thinking about the back-end
[00:12] <cjwatson> fair enough
[00:12] <cjwatson> that's the way it should be really, just curious
[00:13] <directhex> cjwatson: we don't use it at all as a matter of policy for packaging (iirc not all arches support it), but i use it for testing etc
[00:13] <cjwatson> all Linux architectures support it, and therefore all Ubuntu architectures, but it's true that not all Debian architectures due
[00:13] <cjwatson> s/due$/do/
[00:16] <cjwatson> it ought to be trivial on the Hurd.  no idea about kFreebSD
[00:18] <directhex> cjwatson: well, kfreebsd is a mono arch, so we can't assumebinfmt works
[00:18] <cjwatson> yeah
[00:18] <cjwatson> your policy makes sense
[02:33] <superm1> cjwatson, okay i didn't dig much into it, but thats at least what it appears on the surface (unable to ls into partitions)
[02:34] <superm1> and yes i was aware /boot/grub/efi.img was assigned as the content of the efi boot catalog entry
[06:47] <kees> siretart: mplayer ping... libavformat52 has Breaks: mplayer (<< 2:1.0~rc4) but the latest mplayer is 2:1.0~rc4~try1.dsfg1-1ubuntu1. I was going to just do a version bump to 2:1.0~rc4+try1.dsfg1-0ubuntu1 so that it would be installable again. How's that sound to you?
[07:25] <siretart> kees: argl. no, let's please update the breaks to mplayer (<< 2:1.0~rc4~~) instead
[07:25] <siretart> kees: rc4 is not released yet
[07:25] <siretart> I need to do that in experimental as well
[07:26] <kees> siretart: okay, cool; will you take care of that, or should I?
[07:32] <siretart> kees: I can do so this afternoon. if you think its urgent, then go ahead
[07:32] <siretart> need to rush to work now
[07:35] <kees> siretart: no rush, just wanted to get mplayer installed again. :)
[07:36] <pitti> Good morning
[07:54] <TheSarge> So are we supposed to use the kernel patch that Linus put out? Or the bashrc route?
[07:54] <TheSarge> For the kernel patch that improves response times under high cpu strain?
[07:57] <TheSarge> Lol anyone?
[07:58] <amitk> TheSarge: better asked on #ubuntu-kernel
[07:58] <TheSarge> K thx
[08:20] <geser> good morning pitti
[08:20] <pitti> hello geser, how are you?
[08:22] <geser> I'm fine, and you?
[08:23] <doko> gahh, gnome's circular dependencies ...
[08:24] <TheSarge> In my linux class based on students complaints of the labs not working with ubuntu we all have to learn on a 5 year old version of fedora..
[08:24] <TheSarge> Ooops wc sorry.
[08:27] <raphink> TheSarge: ah, I would have said your nickname suggested you were on a 5-year-old version of Debian
[08:28] <raphink> ;)
[08:39] <TheSarge> raphink: ?
[08:39] <TheSarge> Oh the RC
[08:39] <TheSarge> That is where the name came from.
[08:39] <raphink> sarge is the codename of Debian 3.1, released in 2005
[08:40] <TheSarge> I made it when I was using that version lol.
[08:40] <raphink> hehe ;-)
[08:40] <TheSarge> I also have this one
[08:40] <TheSarge> err cant change cause I am in ##linux
[08:40] <TheSarge> But it is Gentoon
[08:40] <raphink> what about being in ##linux?
[08:42] <dholbach> good morning
[08:43] <TheSarge> Won't let me change nicks when I am in there
[08:43] <TheSarge> Or maybe it is #Ubuntu
[09:28] <azul_> cjwatson: hi - I've got a slew of odd mails about dpkg indonesian translations. Does this relate to the dpkg-patch-which-is-completely-unrelated-to-indonesia patch I sent you per chance?
[09:45] <doko> didrocks: ping
[09:46] <didrocks> doko: pong
[09:46] <doko> didrocks: gnome has not so nice dependency cycles ... canberra can not be available when libgnome is built
[09:46] <doko> only if you have it before
[09:47] <doko> didrocks: plus: gstreamer build-depends on the *whole* gnome stack ...
[09:47] <doko> (gir-repository-dev)
[09:48] <doko> slomo: ^^^ can this be made simpler?
[09:48] <didrocks> doko: can you open a bug report about those deps? I really won't have the time to look at it right now and before alpha week release I'm afraid…
[09:57] <slomo> doko: yes, should be possible without gir-repository-dev nowadays
[09:58] <slomo> doko: thanks for noticing, i'll fix it later
[09:59] <Daviey> Hi, should the natty-security pocket be used yet - or should it just go to main?  (for a security bug that exists in natty and maverick)
[10:05] <Laney> just to release
[10:07] <Daviey> Laney: thought so, thanks
[10:07] <Laney> nps
[10:29] <slomo> didrocks: i'm fixing it in debian (the gir-repository-dev build dependency problem)
[10:29] <didrocks> slomo: thanks :)
[10:46] <cjwatson> azul_: wouldn't worry about it, there's a minor flaw in id.po but it's not a big deal
[10:46] <cjwatson> azul_: launchpad complains about it on each upload
[10:47] <azul_> cjwatson: right - filing to dev/null... :)
[10:47] <cjwatson> azul_: I thought I remembered passing it up as a Debian bug a while back, but maybe that was a different package
[10:47] <cjwatson> for things where I have Debian commit access I just fix them
[10:59] <\sh> hmmm..there is something really nasty inside /etc/cron.daily/apt .. apt-key net-update won't work when there are machines which don't have direct internet connections...and it doesn't timeout somehow
[11:27] <slomo> didrocks: fixed versions are gstreamer/gst-plugins-base are in experimental now
[11:28] <didrocks> slomo: thanks, I'll pend merges on my TODO :)
[11:55] <late> s
[12:13] <ari-tczew> could someone sponsor this one? bug 663343
[12:15] <spaetz> Any plan on when LibreOffice will enter natty repositories?
[12:54] <mdeslaur> does anyone know what bug 647404 could be?
[13:21] <ogra> can some archive admin accept qt4-x11 4.7.0-0ubuntu4.2 into maverick-proposed please
[13:25] <pitti> ogra: I'm currently doing SRU reviews, I'll get to it
[13:25] <ogra> pitti, mreci
[13:25] <ogra> or merci :)
[13:25] <pitti> ogra: de rnie! :)
[13:25] <ogra> lol
[13:28] <pitti> ogra: there are two uploads
[13:28] <pitti> ogra: should I reject 4.2 and keep 4.1? or did you actually change something in 4.2, and I should reject 4.1?
[13:28] <ogra> pitti, 4.1 was already uploaded before and removed from -proposed
[13:29] <pitti> ah
[13:29] <pitti> it was reuplaoded 15 mins ago, so I'll reject it
[13:29] <ogra> ScottK, just told me that the source package persists even if the binary is removed
[13:29] <ogra> so i just bumped to 4.2
[13:29] <ogra> without further changes
[13:30] <ScottK> ogra: It's a little more subtle.  Soyuz marks the version has having been seen, so it can't be reused even though source and binary have been removed.
[13:30] <ogra> ah
[13:34] <pitti> sconklin: do you know who uploaded linux-mvl-dove lucid-proposed? I reject it, as there is no bug reference at all
[13:35] <ogra> pitti, tim did
[13:37] <ogra> pitti, https://lists.ubuntu.com/archives/kernel-team/2010-November/013532.html
[13:37] <ogra> looks like a general BSP update
[13:41] <tgardner> how can I find out why a package was rejected, e.g., linux-mvl-dove for Lucid
[13:41] <pitti> tgardner: see three lines above ^ :)
[13:42] <ogra> tgardner, see PM, i pasted them for you
[13:43] <tgardner> pitti, linux-mvl-dove is not subject to SRU, so I see no reason to have a tracking bug. Eric has about the only HW in existence, so I assume he knows what he's doing.
[13:44] <pitti> tgardner: really? I have two dove boards :)
[13:45] <pitti> tgardner: anyway, it was uploaded as an SRU, so perhaps it should go into -backports then or so?
[13:45]  * ogra knows GrueMaster and NCommander have them too 
[13:45] <pitti> we at least need a tracking but for the testing
[13:45] <pitti> I mean, if you say "we don't care", ok for me, but it'll just bitrot in -proposed then
[13:47] <tgardner> pitti, ok, I'll add a tracking bug. Does anyone actually ever use them? Usually the developers just fire up a  new bug and report their specific symptoms.
[13:47] <pitti> tgardner: those are a much preferable indeed
[13:47] <pitti> tgardner: if this upload closes any "real" bug report, please use that
[13:47] <testi__> How do you get blueprints discussed? What if you have a feature idea that doesn't need to be in the next release? Where do you start, other than placing a blueprint or brainstorm idea?
[13:48] <tgardner> pitti, I'll have to ask Eric about that. I'm just doing the packaging for him.
[13:48] <testi__> How that workflow works
[13:49] <testi__> *I wonder
[13:50] <siretart> kees: ffmpeg uploaded
[14:20] <apw> pitti, how often is the work-items tracker running now that maverick is gone ?
[14:20] <apw> are we back to hourly ?
[14:21] <apw> pitti, ignore me, i can tell for myself now :)
[14:22] <pitti> apw: we aren't; I'm not sure how long the tracker needs these days, we might be able to switch back to hourly
[14:22] <pitti> but now it has the maximum number of charts it needs to generate
[14:22] <apw> pitti, i'll find out how long it takes
[14:23] <apw> i suspect what we should do is make it trigger hourly with a lockout, so that it doesn't step on itself
[14:33] <jdstrand> Daviey: hey. did you get an answer for natty-security/
[14:33] <jdstrand> ?
[14:34] <Daviey> jdstrand: i did, thanks!
[14:34] <jdstrand> cool
[14:34] <jdstrand> I thought I saw it, but then couldn't find it, and then wasn't sure if I imagined it :)
[14:51] <jdstrand> pitti: hi! what is the process for resetting the work items tracker for our team? we didn't get all our blueprints done until the 17th
[14:51] <jdstrand> pitti: it is no biggie, but would be nice to have fixed (eg http://people.canonical.com/~platform/workitems/natty/canonical-security.html)
[14:51] <pitti> jdstrand: just change it yourself, "sudo -u platform -i" on lillypilly
[14:51] <pitti> I sent that around to platform some weeks ago
[14:52] <jdstrand> pitti: k, thanks
[14:54] <pitti> jdstrand: is the sudo thing working for you?
[14:55] <jdstrand> pitti: I am in as 'platform', yes. I am just trying to figure out what to do (I don't see a README or similar, but I only just started looking)
[14:56]  * jdstrand wonders if it is 'trend_start'
[14:57] <pitti> jdstrand: it's in work-items-tracker/config/natty.cfg
[14:57] <jdstrand> yeah, that is what I am looking at
[14:57] <pitti> jdstrand: you need to change the "trend_start" map
[14:58] <jdstrand> pitti: so trend_start will override whatever is already in there?
[14:58] <pitti> there are some examples already
[14:58] <pitti> jdstrand: right; by default it uses "#open WIs" from the first day
[14:58] <jdstrand> pitti: cool. ok, then it is pretty self-explanatory. I got there pretty quickly :)
[14:58] <jdstrand> pitti: thanks!
[14:58] <pitti> great! you're welcome
[14:59] <pitti> jdstrand: there you can also check if it's currently running, or run it manually once for an urgent update, etc.
[14:59] <sladen> vish: so what's the difference between papercutters and papercut-ninja
[15:00] <vish> sladen: the papercut ninja is more for fixing the bugs , the papercutters is for triaging the bugs..
[15:00] <vish> sladen: kinda like MOTU and BC
[15:01] <sladen> vish: k, *nods*
[15:03] <vish> sladen: and the papercut-ninja will hopefully have the upstreams joining in as well, so that they can help the new folk..
[15:23] <cyphermox> hey, I'm considering getting wpasupplicant 0.7.3 from Debian SVN uploaded to natty -- I've been testing it on my system for a few days now with no issues -- 0.7.3-1 is marked as UNRELEASED though, is there any issue with leaving that as is in changelog for an upload, with a further 0.7.3-0ubuntu1 on top, and then strip that one out later once 0.7.3-1 gets released (assuming it gets sync'ed)?
[15:26] <sladen> cyphermox: no, you can leave the "UNRELEASED" entries in
[15:26] <sladen> cyphermox: see  http://changelogs.ubuntu.com/changelogs/pool/universe/o/openbve/openbve_1.2.7.3-0ubuntu1/changelog
[15:28] <sladen> but somebody might suggest using a ~somewhere in the version as that 0.7.3-1 is still in flux and hasn't actually been released yet
[15:29] <cyphermox> right, but that's why I set my revision as 0.7.3-0ubuntu1
[15:30] <cyphermox> I was mostly curious to see if there was an established better way to do this, afaik the only side effect is a lintian warning ;)
[15:31] <cjwatson> UNRELEASED is basically a safety catch
[15:31] <cjwatson> only the top entry actually matters though
[15:31] <cyphermox> yeah, and that gets rejected
[15:32] <cyphermox> thanks.
[15:41] <tgardner> pitti, linux-mvl-dove re-uploaded for Lucid/Maverick with tracking bug in the changelog
[15:41] <pitti> thanks
[16:46] <pitti> marjo: can I just add something to "new features" on https://wiki.ubuntu.com/QATeam/NattyTestPlan, or should this be coordinated?
[16:47] <marjo> pitti: if you don't mind, please tell jibel before adding?
[16:47] <pitti> marjo: ah, will do that; thanks!
[16:47] <marjo> just so he's not surprised?
[16:47] <pitti> jibel: does it sound ok to you if I add the applications that we ported to Gtk 3.0/gobject-introspection to "New features" in https://wiki.ubuntu.com/QATeam/NattyTestPlan ?
[16:48] <pitti> jibel: the introspection stuff is still in heavy flux, and thus prone to break
[16:50] <pitti> jibel: I'd like to add things like "apport - try "ubuntu-bug audio" and select the "record" case, then follow the steps, and finally check if you get a reasonable output and behaviour of the details window"
[16:50] <jibel> pitti, yes please go ahead, this is a live document. I'm subscribed to it so we can always talk about the changes later.
[16:50] <pitti> that will exercise various dialog types, the details view, and thus cover quite a bit
[16:54] <apw> pitti, fyi i've just worked out why the graphs don't seem to have enough items.  the counts are being made on the DISTINCT descriptions so if you have two items with the same text anywhere they are collapsed
[16:55] <pitti> aah
[16:55] <apw> pitti, my graphs just jumped about 20 itemes, you don't want to know about foundations
[16:55] <apw> i'll push the change shortly :)
[16:55] <pitti> apw: but the by-user view lists them all?
[16:55] <pitti> apw: odd, why do we have so many identical WIs?
[16:55] <apw> yeah the db and the views are all right, its just the graphs
[16:55] <apw> some wording is common, i have a lot which are 'review personal patches and upstream'
[16:56] <apw> one for each person with patches
[16:56] <pitti> apw: it needs to take care of not counting the WIs from other days, though
[16:56] <apw> pitti, its doing the loop by day though
[16:56] <pitti> I'm not quite sure why I added the distinct back then
[16:56] <pitti> apw: right
[16:56] <pitti> apw: if it's "more" correct without, just kill it :)
[16:56] <apw> will do
[16:57] <pitti> thanks
[17:01] <jdstrand> pitti, didrocks: hey. so it only just now dawned on my that the security team won't be able to test security updates in VMs for natty with a representative install. aiui, unity won't run in kvm or other virtualized systems
[17:02] <pitti> jdstrand: it should automatically fall back to gnome/2d, though
[17:02] <jdstrand> pitti: right, but we like to test on a default install with a representative desktop
[17:02] <didrocks> jdstrand: yeah, that will be an issue (I don't now the support on virtualbox + acceleration works there)
[17:02] <jdstrand> pitti: to try to cover as many bases as possible
[17:03] <didrocks> know*
[17:03] <jdstrand> pitti, didrocks: I know that the desktop will be downgraded if the unity experience is not deemed "great", but what does that mean exactly?
[17:03] <jdstrand> ie, is "great" just performant?
[17:04] <didrocks> jdstrand: there are four "layer"
[17:04] <didrocks> jdstrand: first one is software rendered -> metacity + gnome-panel
[17:04] <didrocks> second one is compiz can run, but not unity at all -> compiz + gnome-panel
[17:05] <didrocks> the third is compiz and unity can run, but unity will do some GL check for tooltips and places at startup, there will be unity in a degraded mode with less beautiful GL effects
[17:05] <didrocks> and the fourth layout is  compiz with unity and full gl effects
[17:05] <ion> cyphermox: Hi. Regarding packageselection-n-network-stack, has Teredo been considered? For instance, Windows™ uses an implementation of Teredo by default, resulting in IPv6 connectivity even behind IPv4-only NATs. Miredo seems to be a fire-and-forget-type implementation, one only needs to install the package and it Just Works™.
[17:06] <jdstrand> didrocks: I see. the 3rd would be acceptable for the security team, but that sounds infeasible with curent technologies
[17:07] <jdstrand> didrocks: since so much of the platform team's work is done in virtualized environments, is work being done to get unity to work ok in a VM?
[17:07] <didrocks> jdstrand: let's see, I know that hw acceleration doesn't work at all on kvm, I really don't know about virtualbox + accel support
[17:07]  * jdstrand would *love* it to work in kvm
[17:07] <didrocks> jdstrand: well, I guess most of the desktop team is working directly on a natty install
[17:08] <jdstrand> didrocks: sure, but maintenance is an issue. SRUs, security updates, the next devel release before you upgrade...
[17:08] <didrocks> it's better to test what you deliver directly, that's why we are on installed version and don't rely on vm
[17:09] <didrocks> jdstrand: I personnaly get separated installation on spare box for SRU (and I upgrade very early in the process), not sure about others
[17:09] <jdstrand> didrocks: well, it sounds like our team is going to get provisioned new machines and just figure out how to deal with it... :/
[17:10] <didrocks> jdstrand: yeah, I'm afraid hard install will be needed…
[17:10] <cyphermox> ion, I didn't know about it. Please, tell me more, but maybe we can do that in pm.
[17:12] <ion> cyphermox: I added the comment to https://blueprints.launchpad.net/ubuntu/+spec/packageselection-n-network-stack along with a link to more info.
[17:13] <cyphermox> ion, awesome, thanks
[17:18] <cyphermox> ion, I see. we haven't exactly talked about this kind of stuff in the UDS session, but miredo is available in universe, have you used it?
[17:20] <ion> Yes, i’ve verified it to provide working IPv6 connectivity both behind an IPv4-only NAT and with a public IPv4 address.
[17:35] <apw> pitti, ok the issue comes down to that the lists are distinct in (description milestone assignee) in most places, but this one only in (description).  i assume you were trying to avoid the 'postponed' in previous milestone and 'done' in this one thing, to try and get only one ... except it 1) doens't do that, and 2) is inconsistant
[17:36] <apw> (in implementation)
[17:37] <apw> i suspect they are all 'wrong' but there are such a lot of them i am a little wary
[17:37] <pitti> apw: ah, perhaps; it's been a while :)
[17:38] <apw> will do a bit more validation
[17:38] <cjwatson> BlackZ: your dropping of upgrade handling in rsyslog has meant that a freshly-installed natty system (e.g. a live CD) has no /etc/rsyslog.d/50-default.conf
[17:38] <cjwatson> BlackZ: can you please put back the ucf bits of that?
[17:39] <cjwatson> BlackZ: this means that e.g. there's no /var/log/syslog, which makes the installer something of a pain to debug!
[17:41] <cjwatson> BlackZ: you also removed the code to create the syslog user, so the whole thing is probably pretty broken.  do you want me to fix it up?
[17:42] <cjwatson> I think you just nuked a bit too much from the maintainer scripts
[17:43] <BlackZ> cjwatson: please do as I can't right now :)
[17:47] <cjwatson> BlackZ: ok, will do, thanks
[17:49] <BlackZ> cjwatson: I thought all the upgrade handling were unnecessary as sysklogd → rsyslog upgrade was done pre-lucid
[17:54] <cjwatson> BlackZ: but lots of the code you deleted wasn't upgrade handling
[17:54] <hallyn> cjwatson: so... is debian-live@ the right mailing list to send proposed casper patches?
[17:55] <cjwatson> hallyn: casper patches should go to Ubuntu - Debian uses live-initramfs, which is a descendant of it but different.  It's worth sending patches to debian-live, but they should be based on live-initramfs not on casper
[17:55] <hallyn> feh
[17:56] <hallyn> idon't quite understand - so is casper occasionally re-based on top of live-initramfs?
[17:56] <cjwatson> it ought to be, but isn't
[17:56] <cjwatson> they're divergent
[17:57] <cjwatson> at some point I plan to throw away casper and use live-initramfs, but the divergence is substantial so I need a spare week for it
[17:57] <cjwatson> it's a historical mess
[17:57]  * hallyn goes to look at the live-initramfs git tree
[17:58] <BlackZ> cjwatson: ok, so if I removed what you said not related to the upgrade handling I did that accidentally :) thanks for noting this
[18:00] <hallyn> cjwatson: ok, so i guessi'll consider whether i dare just 'port' the patches to live-boot.  kinda scary, though, as that'll be far less tested.
[18:00] <hallyn> cjwatson: thanks
[18:33] <cjwatson> BlackZ: ok, fixed now, thanks
[19:19] <statik> aloha micahg! do you know if a separate package of spidermonkey is still out of the question for Ubuntu even though debian is still shipping libmozjs? I'm still hearing complaints about couchdb depending on xulrunner, and trying to figure out if any improvement is possible
[19:20] <micahg> statik: we're considering it again actually
[19:21] <statik> micahg: orly? cool. this is kind of relevant, looks like debian is versioning libmozjs: http://packages.debian.org/search?suite=all&searchon=names&keywords=libmozjs I haven't looked to see where they are pulling the "releases" from though
[19:22] <statik> oh, source package is iceweasel and they build a libmozjs binary package
[19:23] <micahg> statik: the problem is upstream isn't versioning
[19:23] <statik> yeah, it's so odd
[19:24] <statik> micahg: i guess the thing to do would be to use the xulrunner versions since those are the tarballs that include the spidermonkey source? Mozilla has all these articles that are in favor of people embedding spidermonkey so it's kinda odd that they stopped releasing spidermonkey tarballs
[19:27] <micahg> statik: nope, that's not the issue, its the ABI version that's the issue
[19:27] <micahg> statik: the 1.9.2.11 release might not be compatible with the 1.9.2.12 release
[19:28] <statik> micahg: so does that mean that couchdb should not be using spidermonkey?
[19:29] <micahg> statik: well, idk of another library that's as convenient
[19:30] <micahg> statik: another problem is we can't just follow Debian's lead since we'll have 2.0 in natty and experimental has 1.9.2, also we push out the releases as soon as mozilla does and there's no guarantee Debian will do the same
[19:31] <statik> micahg: the thing that is tough for me is it's harder to use spidermonkey on ubuntu than it is on debian, and I don't understand the benefits of that decision well enough to defend it.
[19:31] <statik> couchdb also can't embed their own copy of spidermonkey because of mpl and apache license incompatibilities
[19:31] <micahg> statik: have you seen the bug?
[19:32] <statik> micahg: I was searching in bugzilla but have not found anything yet, if you have a pointer to the past discussions that would be awesome! I'm not meaning to complain at you, just got the energy to try and understand the issue better :)
[19:32] <micahg> statik: bug 286906
[19:32] <statik> thx
[19:33] <micahg> statik: np, it's a problem for Ubuntu in general since xulrunner isn't needed on the CD anymore except for mozjs
[19:33] <statik> v8 doesn't seem to have any of these problems, I'm so curious whether switching to v8 is an option for couchdb
[19:34] <statik> it's bsd license so embedding into an apache project is possible, and it seems to have nice clean simple packaging and releases
[19:34]  * jpds thought we were talking about IP versions for a moment there.
[19:35] <micahg> statik: well, that will mean more regression testing for chromium then upgrades then
[19:36] <micahg> statik: actually not, nm
[19:40] <statik> micahg: thanks for the help, this bug history was quite helpful
[19:41] <micahg> statik: np, let me know if you need anything else
[21:11]  * cody-somerville isn't sure how distributing the debian changelog satisfies the "You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change." section of the gplV2. :S
[22:06] <smoser> cjwatson, are you around ?
[22:25] <smoser> cjwatson, i tried to verify the fix for bug 581760 but apparently missed something. see my comments there.
[23:57] <SpamapS> hrm.. I'm debugging some issues with /lib/init/upstart-job .. seems like there's a giant race condition there where it runs 'status $JOB' and then acts based on that response later.. but status may change
[23:57] <SpamapS> its a pretty tiny window...
[23:58] <SpamapS> seems like it should check the return code of the action instead of using status