[02:20] stgraber: oops, I just got the blueman crash again, it seems that the update helped, but didn't fully resolve the issue [02:22] stgraber: hrm, maybe not...could be that the applet didn't restart, but the package is there [02:23] in any event, I don't think it made it any worse [02:39] micahg: will check https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fblueman-applet%3AKeyError%3Afunction%27%3A__list_callback%3Ahandler%3Acard_cb tomorrow, but so far it seems to be improving anyway [03:46] slangasek: I'd question those conflicts belonging to nspr (cause they really shouldn't), but if it works, it works. Accepting. [03:48] micahg: It's quite likely the applet doesn't restart, which will cause a bit of confusion until reboot (including for errors.u.c, I bet) [03:48] stgraber: ^ [04:03] infinity: well, they belong there because nspr needs to win the tie in apt. In theory a Breaks would have also been sufficient. [04:08] slangasek: Would it not work for evolution(-$something) to have the conflicts, which seems like a more obvious package relationship? [04:08] infinity: no, because apt is happy to hold back all the evolution-$somethings [04:09] slangasek: (Again, just nitpicking, cause a bit of cruft in two packages that don't really relate on a massive LTS->LTS upgrade path doesn't really annoy me, especially as we're not carrying the delta forward) [04:09] slangasek: Sure, it's happy to hold them back, but maybe it wouldn't be with the conflict, was my point. ;) [04:10] I really need to try to understand that part of the resolver some day, cause my only "understanding" of it tends to be "add/remove conflicts in curious orders until I beat its internal scoring engine, but without actually knowing why it worked". [04:12] Maybe it was intended as a video game for really, really boring people. [04:12] heh [04:16] hey, I think the x stack can be moved to quantal now [04:16] tjaalton: \o/ [04:17] -msm got fixed yesterday, and i'm not letting -glamo block this.. [04:18] Oh, crap, I didn't get a chance to discuss the state of omap/omapfb with the various parties. [04:18] Though, I'm still not entirely convinced that omapfb can go away. [04:18] Ok I see nspr was accepted... [04:18] infinity: hmm ok [04:18] are there any others w/ exceptions that need reviewing? [04:18] SpamapS: Yeahp. [04:19] SpamapS: Yeahp to the accepting, not the needing. I grabbed ubiquity as well. [04:19] SpamapS: sso-client is all yours, if you want it. [04:20] tjaalton: Give me a 12/24h window to get some round-trips on some pings between people, and I'll either release the X stack as is, or come back with a "wait, no, we need to fix omapfb, not remove it". [04:20] infinity: heh, sounds ok [04:21] Or I'll test it all myself, instead of relying on third parties, but I don't feel like reinstalling my Panda at 10:21pm. [04:21] hmm, mlankhorst has one too, I could ask him what it uses [04:22] tjaalton: Upgrading to quantal-proposed, making sure that -omapfb isn't even removetly installed on disk, rebooting, and seeing if he has a workable X, would probably be enough. [04:22] tjaalton: s/removetly/remotely/ ... [04:23] infinity: it would fall back to -fbdev if it used to use -omapfb, i think [04:23] but yes [04:24] as long as it works [04:24] tjaalton: Well, sure. Doing the above, and then seeing if it's using a driver that's not fbdev would be nice. :P [04:24] tjaalton: But if it functions at all, that's also something of a bonus. [04:25] it might need tweaks to the patch for xserver that handles driver autoloading on arm [04:26] which is a gross hack currently, but rsalveti is on it [04:26] but shouldn't be too hard to add some more glue just to get -omap load [04:26] +ed [04:26] we can, I have the hack in hands [04:26] but I don't see it's that critical at this point [04:27] it'll still be using fbdev, which is the one used in the past [04:27] Alright. [04:27] oh? [04:27] rsalveti: I disagree on the criticality, but no, it shouldn't block the xorg ABI transition. [04:27] rsalveti: It absolutely should happen before release, though. [04:27] sure [04:27] infinity: sure, but not critical at *this* point :-) [04:28] the driver is needed for sgx to work properly [04:28] and that's my goal [04:28] Alright. [04:28] -omap? [04:28] yeah [04:28] omap is the open part of it, which enables exa acceleration [04:29] but there's also a hook for the omap_pvr proprietary module [04:29] which is part of the sgx package [04:29] Kay... [04:29] I requested a new rebuild of the sgx driver from TI, to match the latest ABI [04:29] after that is available, we can work on a solution to have the omap driver to work by default [04:29] and get sgx to work as well [04:29] tjaalton: In light of the above, can you poke me in ~9h and I'll start processing all your removals, and then jam the transition in? [04:30] (I might do it tonight, if I can't sleep, but otherwise, that maps vaguely to "when I get up") [04:30] infinity: yup [04:39] rsalveti: so is there any word from TI about when the sgx rebuild will be available? [04:39] rsalveti: is the sgx package separate from the pvr-omap4 package? [04:40] slangasek: it's all part of the pvr-omap4 [04:40] ok [04:40] hopefully this week still [04:40] my goal is to get everything in place before feature freeze [04:40] ah, wonderful :) [04:40] but I believe today was holiday in france [04:40] so that's why I should get some answer from the ti folks by tomorrow or friday [04:41] that's very good news, given that unity2d is now gone from quantal [04:41] yup [04:41] it'll not be perfect still, due a bug at the kernel side, but it'll at least work [04:41] meanwhile robclark is working with the omapdss guys at TI to try to fix the kernel [04:42] oh unity2d gone.. means software fallback really should work then? [04:42] tjaalton: meaning it would be nice if someone would make the software fallback work, yes... [04:42] duh :) [04:42] I hear it's not working so well yet [04:43] well, at least we can now pull in current mesa master, and hope for the best [04:43] it was the plan anyway [04:43] yeah [04:43] the unity blocker bug got fixed recently [04:44] (no icons) [04:44] so I'll probably prepare the new mesa today and test it with llvmpipe [04:44] to see if it's as 'flashy' as before [04:48] Probably :/ [04:50] oh hai [04:52] Hullo [04:52] yeah could be that there will be some "issues" to overcome.. [04:53] gnome-shell apparently works with it, so why can't unity [04:54] unless it's hitting the driver in ways g-s doesn't [05:15] tjaalton: We know what unity's doing that g-s doesn't: unity does partial back-to-front copies, rather than buffer swaps. [05:15] For hysterical raisins. [06:20] RAOF: are those raisins still good? [06:20] probably a silly question :) [06:20] I'm not sure they were ever particularly good, actually. [06:21] anyway, I'll prepare mesa git now [06:21] -> #ubuntu-x [06:29] slangasek: ogra_: can any of you take a look at bug 1018907 later? [06:29] Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,In progress] https://launchpad.net/bugs/1018907 [06:29] I included a debdiff with a patch from upstream that adds a generic drm driver [06:29] which is now the only one supported by upstream, and that also works at omap [06:29] didn't decide to update the package as it could break other use cases at this point (due the large diff we have for ubuntu) [06:32] anybody know why is there no new build for precise desktop on 2012.08.15 ? [06:33] is it becasue of the 12.04.1 release? [06:39] rsalveti: Why aren't you a core-dev yet? :P [06:40] infinity: yeah, was asking myself the same question today [06:40] need to apply asap :-) [06:40] Indeed, you do. [06:41] Also, that autotools skew is icky. Surely, you could have used the same version? :) [06:41] infinity: the old one was generated at natty [06:42] don't even know if it'd be safe to use the old version here, as I'm already using the same major version [06:42] but with a newer minor version, which generally provide bugfixes [06:42] +-# Makefile.in generated by automake 1.11.3 from Makefile.am. [06:42] ++# Makefile.in generated by automake 1.11.5 from Makefile.am. [06:42] ^-- Looks like precise versions t ome. [06:43] babyface: There is: http://cdimage.ubuntu.com/daily-live/20120815/ [06:43] could be, was using the changelog as reference [06:43] rsalveti: Yeah, it was precise's autoconf/automake. So, refreshing the autoreconf patch in a precise chroot would cut down the diff a lot. [06:43] and the last one pointing out that updated the same patch, uploaded the package to natty [06:43] smartboyhw, I mean precise desktop build [06:44] (And maybe make it auditable) [06:44] smartboyhw, you know there is no precise desktop build on 2012.08.15 [06:44] yeah, seems to be the one at precise, way easier [06:44] Ur, use the alternate one then [06:44] let me refresh it then [06:45] I just hate these kind of patches [06:46] smartboyhw, no, I can't , I'm responsible for the watching all the automated testing on quantal & precise in Jenkins, you know we perform automated test on daily precise desktop build everyday, so I can not use alternate instead [06:46] Hi babyface [06:46] I like testing [06:47] Doing a hell lot on Ubuntu Studio [06:47] smartboyhw, cool! [06:47] Yeah, I'm their staff member [06:48] Anybody else know the reason why there are no new builds for precise desktop on 2012.08.15 ? [06:49] Maybe they forgot [06:49] :) [06:50] HAHA, NO, that's not making sense [06:50] infinity: yup, with automake/autoconf from precise it reduces quite a bit already [06:50] but, it'd probably be updated at some point anyway [06:50] will also attach the one generated at precise [06:53] rsalveti: Oh, indeed, it'll be regenerated by someone else, and that's no big deal, but I'm sponsoring the upload, so I want to audit the macro expansions sanely. :) [06:54] infinity: https://launchpadlibrarian.net/112819168/plymouth_0.8.4-0ubuntu2-2.debdiff [06:54] way easier to read [06:55] rsalveti: I don't suppose you had a chance to test it on an nvidia system to make sure it's still happy? [06:55] infinity: don't have any nvidia-based system around to test, unfortunately [06:56] by upstream this is now the only supported method, and the nvidia one is still enabled, in case the generic fails [06:56] so it should work, but it'd be good if someone could help testing it [06:56] Mmkay. Let me give it a test build and see if it looks saneish, and I'll upload. [06:56] infinity: if you have a nvidia system, that would be awesome [06:58] I have a silly hybrid intel/nvidia thing. Not sure it actually ever worked right, so it might not be the best test. :P [06:58] :-) [06:58] rsalvet, have you fixed something in nvidia ? [06:58] rsalvetI:^^ [06:58] rsalveti:^^ [06:58] no, I fixed at the generic use case (using a valid drm driver), we're just wondering if this didn't break anything at the nvidia side [06:58] :-) [06:59] I can test it, then [06:59] njin: are you using the proprietary drivers? [06:59] or the nouveau one? [06:59] actually no [07:00] usually the nouveau, but not on this machine [07:00] I don't remember if plymouth ever worked right with the proprietary driver [07:01] I'm going to install Ubuntu amd64 desk on that machine [07:02] rsalveti: Hrm, strange. After applying your debdiff and rebuilding a source package, I get a patches/debian-changes with some cruft. [07:03] infinity: it's probably because the previous patches are already applied [07:03] Oh, I might need to pop autoreconf and push the new one. [07:03] Unclever. [07:03] Let's see. [07:04] it's because it's refreshing the old patch [07:05] Yeah, that went better. autoreconf patches are messy. :/ [07:06] always [07:06] babyface: Are you a Canonical employee or what? [07:07] smartboyhw, yes, I'm [07:07] I need to move my Ubuntu and Debian mirrors to a host with GigE. Having them on my mx53 isn't bright. [07:07] smartboyhw, are you ? [07:07] babyface: So why can't I see a Canonical or ubuntu cloak on it? [07:07] No! [07:08] Mate, my age doesn't fit to do any work [07:08] infinity: well, at least you're using your imx53 for something :-) [07:08] you mean you are too young to be employed? [07:08] Yep, I'm 14 [07:09] after I got the imx6, my imx53 is mostly doing nothing [07:09] omg! really young! [07:09] rsalveti, after published I will install amd64 desktop, do you need me to report you something ? [07:09] njin: only in case you can't see the bootsplash while booting your system [07:10] which is that ubuntu symbol with the animated dots (plymoth ubuntu theme) [07:10] rsalveti, ok [07:10] welcome to do more test on ubuntu, you know, young people brings fresh idea [07:10] rsalveti: Right, well, the binaries come out looking sanely linked, at any rate. That's something. :P [07:10] babyface: Yeah, I would [07:10] rsalveti: Uploaded. [07:10] infinity: :-) that's because of the nouveau patch I also had to apply [07:11] due latest libdrm changes [07:11] otherwise you'd get a missing symbol [07:11] rsalveti: Was it linking to drm-nouveau2 without the patch? [07:11] rsalveti: Or just failing to link? [07:11] which also reminds me that we need to look for any software linking with the old libdrm_nouveau library [07:11] (My assumption is that we want to switch to -nouveau2 at some point, but I really don't know what the master plan is there) [07:11] it was linking, but later it was saying that it could not find all the symbols [07:12] Fun. [07:12] and continuing thinking it could be a plugin [07:12] babyface: Just finished testing Ubuntu Studio 12.04.1 amd64 build [07:12] rsalveti: Of course, with an entirely generic interface, one would assume plymouth should eventually stop linking intel/radeon/nouveau entirely, no? [07:12] otherwise it'll all break on an archive rebuild [07:12] smartboyhw, how about it? [07:12] A pass given [07:12] infinity: yup, and that's the upstream plan as well [07:12] smartboyhw, good news! ;) [07:12] Anyway, you live in China? Looks like a Chinese name [07:13] as it's now just using the drm ioctl [07:13] smartboyhw, yes, I do. you ? [07:13] infinity: and thanks for the upload [07:13] Hong Kong here [07:14] smartboyhw, Chinese? [07:14] Yep [07:14] smartboyhw, oh! nice to meet you here! [07:15] * rsalveti annoyed that flash-kernel is not updating the boot parameters properly yet [07:15] rsalveti: No problem. On the one hand, I want to get you and apw core-dev, so you can stop being blocked on sponsorship, on the other hand, if I stop sponsoring for you two, the quality of code I get to review will go way down. [07:15] rsalveti: So, maybe I'll sabotage you for the sake of my own sanity. [07:15] infinity: lol [07:25] infinity: libdrm-nouveau1 will drop out once the new mesa is uploaded; it's the final piece (assuming that plymouth now links to libdrm-nouveau2) that wasn't transitioned to the new API. [07:26] RAOF: plymouth currently links to nouveau1a. If you'd like to take the version just uploaded and mangle it for nouveau2 (and test that it works) to go with the new mesa and such, please do. [07:26] RAOF: rsalveti forced it to link to nouveau1a specifically because it seemed a bit goofy (unresolved symbols) when linking to 2. [07:27] I believe the API is different; it's not just an ABI bump, so I'm not surprised that linking against nouveau2 fails. [07:27] RAOF: Though, as dicussed, the ultimate goal should be plymouth not linking to any drm-* modules, so maybe that's the way forward. [07:27] That would be ideal, yes. [07:27] It should be possible to just link to libkms. [07:28] Touching plymouth is not one of my burning ambitions at the moment, though ☺. [07:28] With his backport of the generic interface, I assume it's just a matter of tearing out some intel/radeon/nouveu-specific bits and it would all Just Work. [07:29] And then we'd need to adjust some seeds or other fiddly things, since plymouth will suddenly stop pulling drm-* libs into images. [07:29] Which will end in tears. [07:29] I assume. [07:32] I don't suppose libdrm will drop out of the transitively-essential set? [07:32] guess the easiest way would be to disable nouveau then [07:32] and make it to use the generic driver [07:33] otherwise you'd need to port the plymouth nouveau plugin just to match the libdrm_nouveau 2 [07:33] and upstream already assumed that the way to go is with the generic driver [07:33] RAOF: As long as we insist on having plymouth in that list, no. [07:34] Also, argh. [07:34] rsalveti: Looks like plymouth-theme-kubuntu-text is now provided by something other than plymouth. [07:34] I so love when people coordinate this sort of thing.. [07:34] =\ [07:35] currently plymouth will try the generic one, radeon, nouveau and libkms [07:35] Comes from kubuntu-default-settings now. Grr. [07:36] so we could just disable the nouveau support, hopping the generic or libkms will work as expected [07:37] why would another package provide the plymouth support if it was already maintained there? [07:37] https://bugs.launchpad.net/ubuntu/+source/kubuntu-default-settings/+bug/1005512 [07:37] Ubuntu bug 1005512 in kubuntu-default-settings "move kubuntu-text from plymouth to kubuntu-default-setting" [Low,Fix released] [07:37] I'll fix that up now and close the bug. [07:38] oh, ok, it's "expected" [07:38] Yeah. Just not by you or me. ;) [07:38] :-) [07:39] setting the by as incomplete doesn't help much I guess [07:39] at the first moment it seems it's not really a bug [07:39] *bug [07:39] but, anyway, another bug to be fixed :-) [07:42] time to get some sleep, back in a few hours [07:43] 'Night. [07:46] Hi babyface [07:57] smartboyhw, hi [09:04] It's likely there will be no images today, fyi. [09:04] Why? [09:05] maintenance on the hardware [09:05] OK [09:09] infinity: ubuntu amd64 server measure only 460 MB [09:10] Laney, you mean the build server for precise desktop image are under maintaining ? [09:10] babyface: indeed [09:11] Laney, do you know when will it be ok? [09:11] Afraid not [09:12] Laney, ok, thank you for the info. [09:13] infinity, I think that is not the case to open a bug report for this or I'm wrong ? [09:16] njin: All the server CDs seem to have gotten a lot lighter. Not sure why. [09:17] I've run it and it retunr that cannot find live-installer [09:17] njin: Could have just been a hiccup with kernel mismatches or something, waiting on another daily might be worth the effort. [09:17] Hmm, when will the server finish maintenance? [09:18] smartboyhw: "sometime"... There's a massive DC move and other pain in progress. [09:18] no respin planned for today ? [09:18] Dunno. [09:18] We'll see what happens. === yofel_ is now known as yofel === lamont` is now known as lamont [13:20] Does anybody know fontconfig good enough to give advice on bug 1034928 ? [13:20] Launchpad bug 1034928 in fonts-unfonts-core "Fontconfig warning: Having multiple values in isn't supported and may not works as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1034928 [13:24] skaet, ping [13:24] hiya ara [13:24] * smartboyhw waves at skaet too [13:24] * skaet waves good morning to smartboyhw [13:28] bdmurray (or any other SRU team member around): xfwm4 is the last package in the Unapproved queue to be targeted for 12.04.1 would be great to have it reviewed ASAP as we're going to start spinning candidates in 8 hours [13:29] * smartboyhw waves at stgraber for a greeting [14:06] xnox: Is it meant to be "or"? [14:07] (I think so) [14:07] so you have to duplicate the matches [14:07] Laney: the hints are vague as to how it is currently implemented. ok. thanks. I will also check how it was fixed in the one font package it was fixed in. [14:08] cause this bug annoys me a lot during daily cd testing! [14:08] http://freedesktop.org/software/fontconfig/fontconfig-user.html [14:08] Patterns which match all of the tests are subjected to all the edits. [14:08] Error 503 Service Unavailable [14:08] ffs, why did I refresh to check? [14:08] * xnox giggles [14:08] Laney: stop crashing freedesktop! [14:10] I'm preparing a language-selector upload so don't bother fixing that one yet [14:10] Laney, I've a fixed accountsservice ready to upload (or almost) btw [14:10] seb128: oh cool, what was it? [14:10] Laney, the entry in the iface table was dropped from the patch [14:11] ah [14:11] so I think I'll upload my l-s and the georgian font probably tomorrow [14:11] it involves a preinst change though which always gives me fear [14:12] Laney, and there are some code bugs in the patch that I fixed as well (side effect for the port to gdbus) [14:12] is gunnarhj still around? [14:12] not that I can say [14:12] I didn't see him for a while [14:12] yeah, me neither [14:22] skaet: we have a problem: http://cdimage.ubuntu.com/precise/daily-live/20120814/ [14:22] skaet: amd64 became oversized between yesterday and today... [14:22] stgraber, *sigh* :P [14:23] that might not technically be oversized... [14:24] micahg: how so? [14:24] xnox: perhaps something like http://paste.debian.net/183910/ is what I'm getting at [14:25] CDs support 703.XXX (45?) [14:25] not sure if it's right though, and it's not the most aesthetic [14:25] micahg: we're checking for the maximum possible size of a CD [14:25] Yeah, that's my question, it isn't oversized, just fit [14:25] stgraber: ah, that was finally fixed :) [14:25] micahg: 736665600 [14:26] http://en.wikipedia.org/wiki/CD-ROM#Capacity [14:26] Laney: will that make fontconfig painfully slow, by unwinding it all like this?! [14:26] micahg: which gives you 702.5390625 [14:26] dunno [14:26] you'd hope it does some caching ... [14:26] I don't see any other way to do disjunction though [14:26] stgraber, according to wikipedia thats to small [14:27] so it's either have it like this or drop it; the behaviour at the minute is undefined [14:27] then again if it's never worked perhaps nobody cares that it's broken so we could drop it? [14:27] 703.125 and 737.280 [14:29] # http://en.wikipedia.org/wiki/CD-ROM#Capacity [14:29] why are there no powerpc builders? [14:29] # gives a maximum of 737280000; RedBook requires [14:29] # reserving 300 sectors, so we do the same here [14:29] # Just In Case. If we need to surpass this limit [14:29] # we should rigorously re-test and check again [14:29] # with ProMese, the CD pressing vendor. [14:29] SIZELIMIT=736665600 [14:29] size limit for precise with rationale. [14:29] bjf: there's general chaos due to datacentre move [14:30] cjwatson: thanks [14:30] bjf: ask on #launchpad-ops (internal) if you think it's more than that [14:31] cjwatson: we have kernels building in our ppa for the current sru cycle. should we go ahead and copy them without ppc builds? [14:31] bah, +t [14:31] * Laney tried to edit the topic to inform people of downtime [14:31] bjf: Please don't [14:31] cjwatson: ok, won't [14:31] I don't want to have to deal with missing binaries [14:32] cjwatson: understand, that's why i asked [14:43] skaet: well, looks like we no longer have our livefs builders so will have to wait a bit more to figure out what's going with the images being oversized... [14:43] stgraber, ack. [14:44] :( [14:46] doing a manifest diff, it looks like a rebuild with the SRUs that were copied yesterday may be enough to get us back to a reasonable size, will check as soon as the machines are back online (probably being moved to the new DC) [14:46] yeah [14:48] skaet: poked IS to confirm these are indeed being moved and that it's not an unrelated failure as I didn't see any email about downtime for these [14:49] jibel, skaet: RT 55370 [14:50] ev, I'll try r270. ta [14:50] jibel: thanks! [15:00] ev, it's a bit confusing to have the same version of wubi r270 for Quantal and Precise but different binaries. [15:01] jibel: shrugs, they're different branches. There's nothing I can really do about that. [15:02] slangasek: still on the call? [15:02] bjf: -ops speculates that we might get them back today, but not sure. [15:02] stgraber: yeah [15:02] cjwatson: thanks for letting me know [15:02] * cjwatson spies his home account auto-logging-on, and returns home on the offchance that it'll stay that way [15:03] ev: hey, what's the per-user crash count for today? the graph *looks* like it's way down [15:04] slangasek: I haven't replaced the graph with the 90 day window yet. I was just about to start doing that. [15:04] because the current calculation goes up to today, it's showing a dip because we haven't had a full days set of reports yet [15:04] looking up the per user crash count for today [15:06] slangasek: there have been 46859 error reports so far today. There were 1,669,672 unique systems in the past 90 days. [15:06] You may want to factor in the percentage of the day remaining to that [15:06] yesterday there were 80399 reports [15:07] so that's 6.74% less reports today if we continue at this rate [15:08] but keep in mind the 11th had 73329 so it varies a fair bit [15:10] ev: hmm, how did we get the 3.3/user/week number again, checking again now, I seem to be off by a factor of 10 when checking again today... (0.314/user/week with the numbers above) [15:10] yeah, it tends to fluctuate between 73k and 85k [15:12] stgraber: out of the call now [15:12] slangasek: ok. === mpt_ is now known as mpt [15:13] slangasek, seb128, ev: so I think the first thing to check is what the actual number of crash/user/week is as past discussion said that we were fine with < 3 to keep whoopsie on [15:14] for some reason I'm not getting a number anywhere close to what we had yesterday, so I certainly did something wrong, either yesterday or today in figuring out the magic number (though I remember slangasek getting to the same result yesterday...) [15:15] http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-08-16%20at%2016.14.25.png - shows the aforementioned fluctuation [15:15] stgraber: which calculation are you doing? [15:17] hmm, yes, I'm also low by a factor of 10 [15:17] slangasek: / * 7 [15:17] 80399/1669672*7 -> .33 crashes/user/week? [15:17] slangasek: that's getting me 0.33706 based on yesterday's number [15:17] right [15:17] It might be worth noting that the number of unique users is lower than it should be as not every system has a system UUID, and the code to fall back to the MAC address only landed in quantal [15:17] but have no way of guessing at the real number [15:18] which would bias the per-user crash count even lower [15:18] should the MAC address fallback be SRUed to precise? [15:18] bdmurray: yes, definitely [15:18] ok, so I like that number a lot more than what we came up with yesterday [15:18] * ev opens a bug task for that [15:19] 0.3 issue/user/week? [15:19] I don't believe in that number [15:19] that's the number we're seeing now [15:19] but we came up with a number 10x bigger yesterday and don't know why [15:19] that number doesn't seem realistic [15:20]