| micahg | stgraber: oops, I just got the blueman crash again, it seems that the update helped, but didn't fully resolve the issue | 02:20 |
|---|---|---|
| micahg | stgraber: hrm, maybe not...could be that the applet didn't restart, but the package is there | 02:22 |
| micahg | in any event, I don't think it made it any worse | 02:23 |
| stgraber | 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 | 02:39 |
| infinity | slangasek: I'd question those conflicts belonging to nspr (cause they really shouldn't), but if it works, it works. Accepting. | 03:46 |
| infinity | 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 |
| infinity | stgraber: ^ | 03:48 |
| slangasek | infinity: well, they belong there because nspr needs to win the tie in apt. In theory a Breaks would have also been sufficient. | 04:03 |
| infinity | slangasek: Would it not work for evolution(-$something) to have the conflicts, which seems like a more obvious package relationship? | 04:08 |
| slangasek | infinity: no, because apt is happy to hold back all the evolution-$somethings | 04:08 |
| infinity | 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 |
| infinity | slangasek: Sure, it's happy to hold them back, but maybe it wouldn't be with the conflict, was my point. ;) | 04:09 |
| infinity | 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:10 |
| infinity | Maybe it was intended as a video game for really, really boring people. | 04:12 |
| slangasek | heh | 04:12 |
| tjaalton | hey, I think the x stack can be moved to quantal now | 04:16 |
| infinity | tjaalton: \o/ | 04:16 |
| tjaalton | -msm got fixed yesterday, and i'm not letting -glamo block this.. | 04:17 |
| infinity | Oh, crap, I didn't get a chance to discuss the state of omap/omapfb with the various parties. | 04:18 |
| infinity | Though, I'm still not entirely convinced that omapfb can go away. | 04:18 |
| SpamapS | Ok I see nspr was accepted... | 04:18 |
| tjaalton | infinity: hmm ok | 04:18 |
| SpamapS | are there any others w/ exceptions that need reviewing? | 04:18 |
| infinity | SpamapS: Yeahp. | 04:18 |
| infinity | SpamapS: Yeahp to the accepting, not the needing. I grabbed ubiquity as well. | 04:19 |
| infinity | SpamapS: sso-client is all yours, if you want it. | 04:19 |
| infinity | 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 |
| tjaalton | infinity: heh, sounds ok | 04:20 |
| infinity | 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 |
| tjaalton | hmm, mlankhorst has one too, I could ask him what it uses | 04:21 |
| infinity | 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 |
| infinity | tjaalton: s/removetly/remotely/ ... | 04:22 |
| tjaalton | infinity: it would fall back to -fbdev if it used to use -omapfb, i think | 04:23 |
| tjaalton | but yes | 04:23 |
| tjaalton | as long as it works | 04:24 |
| infinity | 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 |
| infinity | tjaalton: But if it functions at all, that's also something of a bonus. | 04:24 |
| tjaalton | it might need tweaks to the patch for xserver that handles driver autoloading on arm | 04:25 |
| tjaalton | which is a gross hack currently, but rsalveti is on it | 04:26 |
| tjaalton | but shouldn't be too hard to add some more glue just to get -omap load | 04:26 |
| tjaalton | +ed | 04:26 |
| rsalveti | we can, I have the hack in hands | 04:26 |
| rsalveti | but I don't see it's that critical at this point | 04:26 |
| rsalveti | it'll still be using fbdev, which is the one used in the past | 04:27 |
| infinity | Alright. | 04:27 |
| tjaalton | oh? | 04:27 |
| infinity | rsalveti: I disagree on the criticality, but no, it shouldn't block the xorg ABI transition. | 04:27 |
| infinity | rsalveti: It absolutely should happen before release, though. | 04:27 |
| tjaalton | sure | 04:27 |
| rsalveti | infinity: sure, but not critical at *this* point :-) | 04:27 |
| rsalveti | the driver is needed for sgx to work properly | 04:28 |
| rsalveti | and that's my goal | 04:28 |
| infinity | Alright. | 04:28 |
| tjaalton | -omap? | 04:28 |
| rsalveti | yeah | 04:28 |
| rsalveti | omap is the open part of it, which enables exa acceleration | 04:28 |
| rsalveti | but there's also a hook for the omap_pvr proprietary module | 04:29 |
| rsalveti | which is part of the sgx package | 04:29 |
| infinity | Kay... | 04:29 |
| rsalveti | I requested a new rebuild of the sgx driver from TI, to match the latest ABI | 04:29 |
| rsalveti | after that is available, we can work on a solution to have the omap driver to work by default | 04:29 |
| rsalveti | and get sgx to work as well | 04:29 |
| infinity | 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:29 |
| infinity | (I might do it tonight, if I can't sleep, but otherwise, that maps vaguely to "when I get up") | 04:30 |
| tjaalton | infinity: yup | 04:30 |
| slangasek | rsalveti: so is there any word from TI about when the sgx rebuild will be available? | 04:39 |
| slangasek | rsalveti: is the sgx package separate from the pvr-omap4 package? | 04:39 |
| rsalveti | slangasek: it's all part of the pvr-omap4 | 04:40 |
| slangasek | ok | 04:40 |
| rsalveti | hopefully this week still | 04:40 |
| rsalveti | my goal is to get everything in place before feature freeze | 04:40 |
| slangasek | ah, wonderful :) | 04:40 |
| rsalveti | but I believe today was holiday in france | 04:40 |
| rsalveti | so that's why I should get some answer from the ti folks by tomorrow or friday | 04:40 |
| slangasek | that's very good news, given that unity2d is now gone from quantal | 04:41 |
| rsalveti | yup | 04:41 |
| rsalveti | it'll not be perfect still, due a bug at the kernel side, but it'll at least work | 04:41 |
| rsalveti | meanwhile robclark is working with the omapdss guys at TI to try to fix the kernel | 04:41 |
| tjaalton | oh unity2d gone.. means software fallback really should work then? | 04:42 |
| slangasek | tjaalton: meaning it would be nice if someone would make the software fallback work, yes... | 04:42 |
| tjaalton | duh :) | 04:42 |
| slangasek | I hear it's not working so well yet | 04:42 |
| tjaalton | well, at least we can now pull in current mesa master, and hope for the best | 04:43 |
| tjaalton | it was the plan anyway | 04:43 |
| rsalveti | yeah | 04:43 |
| tjaalton | the unity blocker bug got fixed recently | 04:43 |
| tjaalton | (no icons) | 04:44 |
| tjaalton | so I'll probably prepare the new mesa today and test it with llvmpipe | 04:44 |
| tjaalton | to see if it's as 'flashy' as before | 04:44 |
| RAOF | Probably :/ | 04:48 |
| tjaalton | oh hai | 04:50 |
| RAOF | Hullo | 04:52 |
| tjaalton | yeah could be that there will be some "issues" to overcome.. | 04:52 |
| tjaalton | gnome-shell apparently works with it, so why can't unity | 04:53 |
| tjaalton | unless it's hitting the driver in ways g-s doesn't | 04:54 |
| RAOF | 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 |
| RAOF | For hysterical raisins. | 05:15 |
| tjaalton | RAOF: are those raisins still good? | 06:20 |
| tjaalton | probably a silly question :) | 06:20 |
| RAOF | I'm not sure they were ever particularly good, actually. | 06:20 |
| tjaalton | anyway, I'll prepare mesa git now | 06:21 |
| tjaalton | -> #ubuntu-x | 06:21 |
| rsalveti | slangasek: ogra_: can any of you take a look at bug 1018907 later? | 06:29 |
| ubot2` | 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 |
| rsalveti | I included a debdiff with a patch from upstream that adds a generic drm driver | 06:29 |
| rsalveti | which is now the only one supported by upstream, and that also works at omap | 06:29 |
| rsalveti | 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:29 |
| babyface | anybody know why is there no new build for precise desktop on 2012.08.15 ? | 06:32 |
| babyface | is it becasue of the 12.04.1 release? | 06:33 |
| infinity | rsalveti: Why aren't you a core-dev yet? :P | 06:39 |
| rsalveti | infinity: yeah, was asking myself the same question today | 06:40 |
| rsalveti | need to apply asap :-) | 06:40 |
| infinity | Indeed, you do. | 06:40 |
| infinity | Also, that autotools skew is icky. Surely, you could have used the same version? :) | 06:41 |
| rsalveti | infinity: the old one was generated at natty | 06:41 |
| rsalveti | 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 |
| rsalveti | but with a newer minor version, which generally provide bugfixes | 06:42 |
| infinity | +-# Makefile.in generated by automake 1.11.3 from Makefile.am. | 06:42 |
| infinity | ++# Makefile.in generated by automake 1.11.5 from Makefile.am. | 06:42 |
| infinity | ^-- Looks like precise versions t ome. | 06:42 |
| smartboyhw | babyface: There is: http://cdimage.ubuntu.com/daily-live/20120815/ | 06:43 |
| rsalveti | could be, was using the changelog as reference | 06:43 |
| infinity | 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 |
| rsalveti | and the last one pointing out that updated the same patch, uploaded the package to natty | 06:43 |
| babyface | smartboyhw, I mean precise desktop build | 06:43 |
| infinity | (And maybe make it auditable) | 06:44 |
| babyface | smartboyhw, you know there is no precise desktop build on 2012.08.15 | 06:44 |
| rsalveti | yeah, seems to be the one at precise, way easier | 06:44 |
| smartboyhw | Ur, use the alternate one then | 06:44 |
| rsalveti | let me refresh it then | 06:44 |
| rsalveti | I just hate these kind of patches | 06:45 |
| babyface | 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 |
| smartboyhw | Hi babyface | 06:46 |
| smartboyhw | I like testing | 06:46 |
| smartboyhw | Doing a hell lot on Ubuntu Studio | 06:47 |
| babyface | smartboyhw, cool! | 06:47 |
| smartboyhw | Yeah, I'm their staff member | 06:47 |
| babyface | Anybody else know the reason why there are no new builds for precise desktop on 2012.08.15 ? | 06:48 |
| smartboyhw | Maybe they forgot | 06:49 |
| smartboyhw | :) | 06:49 |
| babyface | HAHA, NO, that's not making sense | 06:50 |
| rsalveti | infinity: yup, with automake/autoconf from precise it reduces quite a bit already | 06:50 |
| rsalveti | but, it'd probably be updated at some point anyway | 06:50 |
| rsalveti | will also attach the one generated at precise | 06:50 |
| infinity | 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:53 |
| rsalveti | infinity: https://launchpadlibrarian.net/112819168/plymouth_0.8.4-0ubuntu2-2.debdiff | 06:54 |
| rsalveti | way easier to read | 06:54 |
| infinity | 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 |
| rsalveti | infinity: don't have any nvidia-based system around to test, unfortunately | 06:55 |
| rsalveti | by upstream this is now the only supported method, and the nvidia one is still enabled, in case the generic fails | 06:56 |
| rsalveti | so it should work, but it'd be good if someone could help testing it | 06:56 |
| infinity | Mmkay. Let me give it a test build and see if it looks saneish, and I'll upload. | 06:56 |
| rsalveti | infinity: if you have a nvidia system, that would be awesome | 06:56 |
| infinity | 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 |
| rsalveti | :-) | 06:58 |
| njin | rsalvet, have you fixed something in nvidia ? | 06:58 |
| njin | rsalvetI:^^ | 06:58 |
| njin | rsalveti:^^ | 06:58 |
| rsalveti | 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 |
| rsalveti | :-) | 06:58 |
| njin | I can test it, then | 06:59 |
| rsalveti | njin: are you using the proprietary drivers? | 06:59 |
| rsalveti | or the nouveau one? | 06:59 |
| njin | actually no | 06:59 |
| njin | usually the nouveau, but not on this machine | 07:00 |
| rsalveti | I don't remember if plymouth ever worked right with the proprietary driver | 07:00 |
| njin | I'm going to install Ubuntu amd64 desk on that machine | 07:01 |
| infinity | rsalveti: Hrm, strange. After applying your debdiff and rebuilding a source package, I get a patches/debian-changes with some cruft. | 07:02 |
| rsalveti | infinity: it's probably because the previous patches are already applied | 07:03 |
| infinity | Oh, I might need to pop autoreconf and push the new one. | 07:03 |
| infinity | Unclever. | 07:03 |
| infinity | Let's see. | 07:03 |
| rsalveti | it's because it's refreshing the old patch | 07:04 |
| infinity | Yeah, that went better. autoreconf patches are messy. :/ | 07:05 |
| rsalveti | always | 07:06 |
| smartboyhw | babyface: Are you a Canonical employee or what? | 07:06 |
| babyface | smartboyhw, yes, I'm | 07:07 |
| infinity | I need to move my Ubuntu and Debian mirrors to a host with GigE. Having them on my mx53 isn't bright. | 07:07 |
| babyface | smartboyhw, are you ? | 07:07 |
| smartboyhw | babyface: So why can't I see a Canonical or ubuntu cloak on it? | 07:07 |
| smartboyhw | No! | 07:07 |
| smartboyhw | Mate, my age doesn't fit to do any work | 07:08 |
| rsalveti | infinity: well, at least you're using your imx53 for something :-) | 07:08 |
| babyface | you mean you are too young to be employed? | 07:08 |
| smartboyhw | Yep, I'm 14 | 07:08 |
| rsalveti | after I got the imx6, my imx53 is mostly doing nothing | 07:09 |
| babyface | omg! really young! | 07:09 |
| njin | rsalveti, after published I will install amd64 desktop, do you need me to report you something ? | 07:09 |
| rsalveti | njin: only in case you can't see the bootsplash while booting your system | 07:09 |
| rsalveti | which is that ubuntu symbol with the animated dots (plymoth ubuntu theme) | 07:10 |
| njin | rsalveti, ok | 07:10 |
| babyface | welcome to do more test on ubuntu, you know, young people brings fresh idea | 07:10 |
| infinity | rsalveti: Right, well, the binaries come out looking sanely linked, at any rate. That's something. :P | 07:10 |
| smartboyhw | babyface: Yeah, I would | 07:10 |
| infinity | rsalveti: Uploaded. | 07:10 |
| rsalveti | infinity: :-) that's because of the nouveau patch I also had to apply | 07:10 |
| rsalveti | due latest libdrm changes | 07:11 |
| rsalveti | otherwise you'd get a missing symbol | 07:11 |
| infinity | rsalveti: Was it linking to drm-nouveau2 without the patch? | 07:11 |
| infinity | rsalveti: Or just failing to link? | 07:11 |
| rsalveti | which also reminds me that we need to look for any software linking with the old libdrm_nouveau library | 07:11 |
| infinity | (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 |
| rsalveti | it was linking, but later it was saying that it could not find all the symbols | 07:11 |
| infinity | Fun. | 07:12 |
| rsalveti | and continuing thinking it could be a plugin | 07:12 |
| smartboyhw | babyface: Just finished testing Ubuntu Studio 12.04.1 amd64 build | 07:12 |
| infinity | rsalveti: Of course, with an entirely generic interface, one would assume plymouth should eventually stop linking intel/radeon/nouveau entirely, no? | 07:12 |
| rsalveti | otherwise it'll all break on an archive rebuild | 07:12 |
| babyface | smartboyhw, how about it? | 07:12 |
| smartboyhw | A pass given | 07:12 |
| rsalveti | infinity: yup, and that's the upstream plan as well | 07:12 |
| babyface | smartboyhw, good news! ;) | 07:12 |
| smartboyhw | Anyway, you live in China? Looks like a Chinese name | 07:12 |
| rsalveti | as it's now just using the drm ioctl | 07:13 |
| babyface | smartboyhw, yes, I do. you ? | 07:13 |
| rsalveti | infinity: and thanks for the upload | 07:13 |
| smartboyhw | Hong Kong here | 07:13 |
| babyface | smartboyhw, Chinese? | 07:14 |
| smartboyhw | Yep | 07:14 |
| babyface | smartboyhw, oh! nice to meet you here! | 07:14 |
| * rsalveti annoyed that flash-kernel is not updating the boot parameters properly yet | 07:15 | |
| infinity | 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 |
| infinity | rsalveti: So, maybe I'll sabotage you for the sake of my own sanity. | 07:15 |
| rsalveti | infinity: lol | 07:15 |
| RAOF | 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:25 |
| infinity | 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 |
| infinity | RAOF: rsalveti forced it to link to nouveau1a specifically because it seemed a bit goofy (unresolved symbols) when linking to 2. | 07:26 |
| RAOF | 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 |
| infinity | 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 |
| RAOF | That would be ideal, yes. | 07:27 |
| RAOF | It should be possible to just link to libkms. | 07:27 |
| RAOF | Touching plymouth is not one of my burning ambitions at the moment, though ☺. | 07:28 |
| infinity | 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:28 |
| infinity | 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 |
| infinity | Which will end in tears. | 07:29 |
| infinity | I assume. | 07:29 |
| RAOF | I don't suppose libdrm will drop out of the transitively-essential set? | 07:32 |
| rsalveti | guess the easiest way would be to disable nouveau then | 07:32 |
| rsalveti | and make it to use the generic driver | 07:32 |
| rsalveti | otherwise you'd need to port the plymouth nouveau plugin just to match the libdrm_nouveau 2 | 07:33 |
| rsalveti | and upstream already assumed that the way to go is with the generic driver | 07:33 |
| infinity | RAOF: As long as we insist on having plymouth in that list, no. | 07:33 |
| infinity | Also, argh. | 07:34 |
| infinity | rsalveti: Looks like plymouth-theme-kubuntu-text is now provided by something other than plymouth. | 07:34 |
| infinity | I so love when people coordinate this sort of thing.. | 07:34 |
| rsalveti | =\ | 07:34 |
| rsalveti | currently plymouth will try the generic one, radeon, nouveau and libkms | 07:35 |
| infinity | Comes from kubuntu-default-settings now. Grr. | 07:35 |
| rsalveti | so we could just disable the nouveau support, hopping the generic or libkms will work as expected | 07:36 |
| rsalveti | why would another package provide the plymouth support if it was already maintained there? | 07:37 |
| infinity | https://bugs.launchpad.net/ubuntu/+source/kubuntu-default-settings/+bug/1005512 | 07:37 |
| ubot2` | Ubuntu bug 1005512 in kubuntu-default-settings "move kubuntu-text from plymouth to kubuntu-default-setting" [Low,Fix released] | 07:37 |
| infinity | I'll fix that up now and close the bug. | 07:37 |
| rsalveti | oh, ok, it's "expected" | 07:38 |
| infinity | Yeah. Just not by you or me. ;) | 07:38 |
| rsalveti | :-) | 07:38 |
| rsalveti | setting the by as incomplete doesn't help much I guess | 07:39 |
| rsalveti | at the first moment it seems it's not really a bug | 07:39 |
| rsalveti | *bug | 07:39 |
| rsalveti | but, anyway, another bug to be fixed :-) | 07:39 |
| rsalveti | time to get some sleep, back in a few hours | 07:42 |
| infinity | 'Night. | 07:43 |
| smartboyhw | Hi babyface | 07:46 |
| babyface | smartboyhw, hi | 07:57 |
| Laney | It's likely there will be no images today, fyi. | 09:04 |
| smartboyhw | Why? | 09:04 |
| Laney | maintenance on the hardware | 09:05 |
| smartboyhw | OK | 09:05 |
| njin | infinity: ubuntu amd64 server measure only 460 MB | 09:09 |
| babyface | Laney, you mean the build server for precise desktop image are under maintaining ? | 09:10 |
| Laney | babyface: indeed | 09:10 |
| babyface | Laney, do you know when will it be ok? | 09:11 |
| Laney | Afraid not | 09:11 |
| babyface | Laney, ok, thank you for the info. | 09:12 |
| njin | infinity, I think that is not the case to open a bug report for this or I'm wrong ? | 09:13 |
| infinity | njin: All the server CDs seem to have gotten a lot lighter. Not sure why. | 09:16 |
| njin | I've run it and it retunr that cannot find live-installer | 09:17 |
| infinity | njin: Could have just been a hiccup with kernel mismatches or something, waiting on another daily might be worth the effort. | 09:17 |
| smartboyhw | Hmm, when will the server finish maintenance? | 09:17 |
| infinity | smartboyhw: "sometime"... There's a massive DC move and other pain in progress. | 09:18 |
| njin | no respin planned for today ? | 09:18 |
| infinity | Dunno. | 09:18 |
| infinity | We'll see what happens. | 09:18 |
| === yofel_ is now known as yofel | ||
| === lamont` is now known as lamont | ||
| xnox | Does anybody know fontconfig good enough to give advice on bug 1034928 ? | 13:20 |
| ubot2` | Launchpad bug 1034928 in fonts-unfonts-core "Fontconfig warning: Having multiple values in <test> isn't supported and may not works as expected" [Undecided,Confirmed] https://launchpad.net/bugs/1034928 | 13:20 |
| ara | skaet, ping | 13:24 |
| skaet | hiya ara | 13:24 |
| * smartboyhw waves at skaet too | 13:24 | |
| * skaet waves good morning to smartboyhw | 13:24 | |
| stgraber | 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:28 |
| * smartboyhw waves at stgraber for a greeting | 13:29 | |
| Laney | xnox: Is it meant to be "or"? | 14:06 |
| Laney | (I think so) | 14:07 |
| Laney | so you have to duplicate the matches | 14:07 |
| xnox | 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:07 |
| xnox | cause this bug annoys me a lot during daily cd testing! | 14:08 |
| Laney | http://freedesktop.org/software/fontconfig/fontconfig-user.html | 14:08 |
| Laney | Patterns which match all of the tests are subjected to all the edits. | 14:08 |
| xnox | Error 503 Service Unavailable | 14:08 |
| Laney | ffs, why did I refresh to check? | 14:08 |
| * xnox giggles | 14:08 | |
| xnox | Laney: stop crashing freedesktop! | 14:08 |
| Laney | I'm preparing a language-selector upload so don't bother fixing that one yet | 14:10 |
| seb128 | Laney, I've a fixed accountsservice ready to upload (or almost) btw | 14:10 |
| Laney | seb128: oh cool, what was it? | 14:10 |
| seb128 | Laney, the entry in the iface table was dropped from the patch | 14:10 |
| Laney | ah | 14:11 |
| Laney | so I think I'll upload my l-s and the georgian font probably tomorrow | 14:11 |
| Laney | it involves a preinst change though which always gives me fear | 14:11 |
| seb128 | Laney, and there are some code bugs in the patch that I fixed as well (side effect for the port to gdbus) | 14:12 |
| Laney | is gunnarhj still around? | 14:12 |
| seb128 | not that I can say | 14:12 |
| seb128 | I didn't see him for a while | 14:12 |
| Laney | yeah, me neither | 14:12 |
| stgraber | skaet: we have a problem: http://cdimage.ubuntu.com/precise/daily-live/20120814/ | 14:22 |
| stgraber | skaet: amd64 became oversized between yesterday and today... | 14:22 |
| skaet | stgraber, *sigh* :P | 14:22 |
| micahg | that might not technically be oversized... | 14:23 |
| stgraber | micahg: how so? | 14:24 |
| Laney | xnox: perhaps something like http://paste.debian.net/183910/ is what I'm getting at | 14:24 |
| micahg | CDs support 703.XXX (45?) | 14:25 |
| Laney | not sure if it's right though, and it's not the most aesthetic | 14:25 |
| stgraber | micahg: we're checking for the maximum possible size of a CD | 14:25 |
| smartboyhw | Yeah, that's my question, it isn't oversized, just fit | 14:25 |
| micahg | stgraber: ah, that was finally fixed :) | 14:25 |
| stgraber | micahg: 736665600 | 14:25 |
| ogra_ | http://en.wikipedia.org/wiki/CD-ROM#Capacity | 14:26 |
| xnox | Laney: will that make fontconfig painfully slow, by unwinding it all like this?! | 14:26 |
| stgraber | micahg: which gives you 702.5390625 | 14:26 |
| Laney | dunno | 14:26 |
| Laney | you'd hope it does some caching ... | 14:26 |
| Laney | I don't see any other way to do disjunction though | 14:26 |
| ogra_ | stgraber, according to wikipedia thats to small | 14:26 |
| Laney | so it's either have it like this or drop it; the behaviour at the minute is undefined | 14:27 |
| Laney | then again if it's never worked perhaps nobody cares that it's broken so we could drop it? | 14:27 |
| ogra_ | 703.125 and 737.280 | 14:27 |
| cjwatson | # http://en.wikipedia.org/wiki/CD-ROM#Capacity | 14:29 |
| bjf | why are there no powerpc builders? | 14:29 |
| cjwatson | # gives a maximum of 737280000; RedBook requires | 14:29 |
| cjwatson | # reserving 300 sectors, so we do the same here | 14:29 |
| cjwatson | # Just In Case. If we need to surpass this limit | 14:29 |
| cjwatson | # we should rigorously re-test and check again | 14:29 |
| cjwatson | # with ProMese, the CD pressing vendor. | 14:29 |
| cjwatson | SIZELIMIT=736665600 | 14:29 |
| cjwatson | size limit for precise with rationale. | 14:29 |
| cjwatson | bjf: there's general chaos due to datacentre move | 14:29 |
| bjf | cjwatson: thanks | 14:30 |
| cjwatson | bjf: ask on #launchpad-ops (internal) if you think it's more than that | 14:30 |
| bjf | 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 |
| Laney | bah, +t | 14:31 |
| * Laney tried to edit the topic to inform people of downtime | 14:31 | |
| cjwatson | bjf: Please don't | 14:31 |
| bjf | cjwatson: ok, won't | 14:31 |
| cjwatson | I don't want to have to deal with missing binaries | 14:31 |
| bjf | cjwatson: understand, that's why i asked | 14:32 |
| stgraber | 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 |
| skaet | stgraber, ack. | 14:43 |
| skaet | :( | 14:44 |
| stgraber | 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 |
| Laney | yeah | 14:46 |
| stgraber | 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:48 |
| ev | jibel, skaet: RT 55370 | 14:49 |
| jibel | ev, I'll try r270. ta | 14:50 |
| ev | jibel: thanks! | 14:50 |
| jibel | ev, it's a bit confusing to have the same version of wubi r270 for Quantal and Precise but different binaries. | 15:00 |
| ev | jibel: shrugs, they're different branches. There's nothing I can really do about that. | 15:01 |
| stgraber | slangasek: still on the call? | 15:02 |
| cjwatson | bjf: -ops speculates that we might get them back today, but not sure. | 15:02 |
| slangasek | stgraber: yeah | 15:02 |
| bjf | 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:02 | |
| slangasek | ev: hey, what's the per-user crash count for today? the graph *looks* like it's way down | 15:03 |
| ev | slangasek: I haven't replaced the graph with the 90 day window yet. I was just about to start doing that. | 15:04 |
| ev | 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 |
| ev | looking up the per user crash count for today | 15:04 |
| ev | slangasek: there have been 46859 error reports so far today. There were 1,669,672 unique systems in the past 90 days. | 15:06 |
| ev | You may want to factor in the percentage of the day remaining to that | 15:06 |
| ev | yesterday there were 80399 reports | 15:06 |
| stgraber | so that's 6.74% less reports today if we continue at this rate | 15:07 |
| bdmurray | but keep in mind the 11th had 73329 so it varies a fair bit | 15:08 |
| stgraber | 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 |
| ev | yeah, it tends to fluctuate between 73k and 85k | 15:10 |
| slangasek | stgraber: out of the call now | 15:12 |
| stgraber | slangasek: ok. | 15:12 |
| === mpt_ is now known as mpt | ||
| stgraber | 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:13 |
| stgraber | 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:14 |
| ev | http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-08-16%20at%2016.14.25.png - shows the aforementioned fluctuation | 15:15 |
| slangasek | stgraber: which calculation are you doing? | 15:15 |
| slangasek | hmm, yes, I'm also low by a factor of 10 | 15:17 |
| stgraber | slangasek: <crash for a full day> / <number of unique systems for past 90 days> * 7 | 15:17 |
| slangasek | 80399/1669672*7 -> .33 crashes/user/week? | 15:17 |
| stgraber | slangasek: that's getting me 0.33706 based on yesterday's number | 15:17 |
| slangasek | right | 15:17 |
| ev | 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 |
| ev | but have no way of guessing at the real number | 15:17 |
| slangasek | which would bias the per-user crash count even lower | 15:18 |
| bdmurray | should the MAC address fallback be SRUed to precise? | 15:18 |
| ev | bdmurray: yes, definitely | 15:18 |
| stgraber | 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:18 | |
| seb128 | 0.3 issue/user/week? | 15:19 |
| seb128 | I don't believe in that number | 15:19 |
| slangasek | that's the number we're seeing now | 15:19 |
| slangasek | but we came up with a number 10x bigger yesterday and don't know why | 15:19 |
| seb128 | that number doesn't seem realistic | 15:19 |
| bdmurray | crash for a full day * 90 days / number of users? | 15:20 |
| seb128 | I've more than that on any stock install test setup I did | 15:20 |
| seb128 | and that's not using the box | 15:20 |
| seb128 | just booting it and running a few apps | 15:20 |
| slangasek | seb128: well, it can only capture the crashes that users actually report | 15:21 |
| mpt | But it's dividing by only those machines that actually report, too, so that cancels out. | 15:21 |
| mpt | (Mostly.) | 15:21 |
| seb128 | sure, but that seems off by a magnitude | 15:21 |
| seb128 | we didn't explain the 90% drop in number in june though | 15:22 |
| slangasek | seb128: maybe all the crashes you've seen are one-time, first-use crashes? | 15:22 |
| seb128 | nor why some component have no bug reported where they should | 15:22 |
| slangasek | seb128: bdmurray and I believe the drop has to do with a change in apport that broke our ability to correctly bucket the reports | 15:22 |
| seb128 | so it means it put our calculation off as well? | 15:23 |
| slangasek | so many reports that actually match known reports are coming in with very partial data that doesn't match any of the *buckets* | 15:23 |
| slangasek | but the overall *count* of reports is still correct | 15:23 |
| slangasek | and we have a fix in progress; so we should see the counts bounce back up for the most-common crashes | 15:24 |
| scott-work | has anyone else noticed that status.ubuntu.com appears to be down? | 15:25 |
| ev | one possibility is that there are certain errors common to every system that get reported in large numbers early on in the installation. But the MaxReports of 3 kicks in and you're suddenly not reporting those anymore. So you could have a lot of reports initially and then very few to none as the weeks pass | 15:26 |
| seb128 | sorry, wifi disconnected | 15:27 |
| ev | just a theory though | 15:27 |
| seb128 | that would assume we don't get new install and users over time | 15:27 |
| ev | I suspect the number of new users we get is heavily weighted towards the first few days after release | 15:28 |
| slangasek | seb128: I think that's a theory for why the per-user average, over 90 days, is lower than you expect based on the new install experience | 15:28 |
| ev | yes | 15:28 |
| seb128 | ok, so it raises another issue | 15:29 |
| slangasek | seb128: did you see my last comments explaining that the per-day crash count should still be accurate, even though the individual bug lines take a dip? | 15:29 |
| seb128 | the first contact those users will have will be that first week | 15:29 |
| seb128 | where the count is much higher | 15:29 |
| seb128 | slangasek, yes I did, thanks | 15:29 |
| stgraber | scott-work: being moved to new DC | 15:30 |
| seb128 | so even if the count drop after a while we still have the issue that the first impression will be bad | 15:30 |
| ev | seb128: I suspect those issues are also the ones that have appeared at the top of the graph | 15:31 |
| ev | since they would have such a high initial frequency | 15:31 |
| scott-work | stgraber: ty :) | 15:31 |
| ev | and would thus be largely fixed for the 12.04.1 installations | 15:31 |
| ev | but this is just speculation | 15:32 |
| seb128 | yeah, we have too much guess work and speculation there, it's hard to take an informed decision :-( | 15:32 |
| slangasek | ev: do you recall how we did the calculation differently yesterday, that we came up with the bigger number? I want to make sure we're not missing something | 15:33 |
| slangasek | but, *if* we're not missing something there, our per-user average over time is clearly below the threshold seb128 and I agreed to | 15:33 |
| bdmurray | (number of crashes per day * number of days)/(number of submitters during the period) | 15:33 |
| ev | slangasek: no idea, sorry | 15:33 |
| seb128 | slangasek, well as said I don't trust that number, but that's not something we will resolve before .1 | 15:34 |
| bdmurray | ^- that gets you 4.337 vs the 0.3 which stgraber had earlier | 15:34 |
| slangasek | and while we should continue driving the crash count down, it looks to me like there's no further action we should take on whoopsie for 12.04.1 | 15:34 |
| seb128 | slangasek, there are other issues, like I asked early on #ubuntu-devel why gconf2 doesn't have any record for gsettings-data-convert issues where we know they are common and we get quite some bugs on the launchpad retracers side | 15:35 |
| slangasek | bdmurray: yeah... the number stgraber and I both came up with yesterday is 3.34/week | 15:35 |
| mpt | bdmurray, I don't understand your formula. Why are you multiplying the number of crashes per day by the number of days? | 15:35 |
| slangasek | mpt: he's trying to reverse-engineer our buggy calculation from yesterday :) | 15:35 |
| ev | lol | 15:35 |
| bdmurray | seb128: what gconf2 bug is this? | 15:36 |
| slangasek | seb128: agreed. so let's keep poking at the edges of this thing and see if there are things we can do to further improve the user experience immediately after .1? | 15:37 |
| ev | for what it's worth, I'm still planning on landing the aggregate error dialog - just obviously not by the 12.04.1 cutoff. | 15:38 |
| ev | would like pitti to be back to provide code review, for a start | 15:38 |
| seb128 | bdmurray, bugs like https://bugs.launchpad.net/ubuntu/+source/epiphany-browser/+bug/945144 | 15:39 |
| ubot2` | Ubuntu bug 945144 in epiphany-browser "gsettings-data-convert crashed with signal 5 in g_settings_set_value()" [Medium,Fix released] | 15:39 |
| seb128 | that one got reassigned, but they usually are opened against gconf2 since "gsettings-data-convert" abort on broken .convert | 15:40 |
| seb128 | we have one in quantal atm on evolution | 15:40 |
| ev | seb128: there are gconf2 problems in the database - 628 different ones. | 15:40 |
| seb128 | so I'm puzzled that doesn't show up on whoopsie | 15:40 |
| ev | but they might not hit the threshold of the most common errors table to show up (need to have 20 instances or more) | 15:40 |
| seb128 | ev, the e.u.c ui gives me 2 lines and none about "gsettings-data-convert" here, selecting all series on a year | 15:40 |
| ev | (I'm fixing that, for what it's worth) | 15:40 |
| slangasek | ok, I think the conclusion is to not disable whoopsie for .1 and we'll keep improving both the UI and the reporting | 15:42 |
| slangasek | I have to duck out now | 15:42 |
| slangasek | thanks for the discussion, guys | 15:42 |
| seb128 | thanks slangasek | 15:43 |
| seb128 | slangasek, I'm not really happy with the conclusion and how we came to it, I just feel like it's a "we know little, let's decide to not decide and keep it as it is" | 15:43 |
| seb128 | but I guess it's late to put it in front of the TB now | 15:43 |
| stgraber | bdmurray, infinity: can one of you two review xfwm4? | 15:44 |
| seb128 | so I will just move on, quite demotivating though | 15:44 |
| stgraber | slangasek: thanks | 15:44 |
| bdmurray | stgraber: I'll do it soon | 15:44 |
| stgraber | bdmurray: thanks. I'll nag the xubuntu folks as sonn as it's in -proposed as they want it for their 12.04.1 image. | 15:45 |
| bdmurray | seb128: I think I found some of the gesttings ones https://errors.ubuntu.com/bucket/?id=/usr/bin/gsettings-data-convert:5:g_settings_schema_get_value:g_settings_schema_key_init:g_settings_set_value:g_settings_set:handle_file | 15:47 |
| bdmurray | ev: that looks quite odd | 15:47 |
| seb128 | bdmurray, how,where did you find it? | 15:48 |
| bdmurray | seb128: I handcrafted the url uses the signature from http://people.canonical.com/~ubuntu-archive/apport-duplicates/sig/_usr_bin_gsettings-data-convert_5 | 15:48 |
| bdmurray | ev: there are package versions on that page | 15:48 |
| bdmurray | er are no | 15:48 |
| ev | bdmurray, seb128: http://paste.ubuntu.com/1150888/ | 15:53 |
| ev | the failed: ones are the retracer failing. It may be because we didn't have debs (as is sometimes the case with the launchpad retracers), or it could be the period when the 12.04 retracers weren't working due to broken oneiric entries in the sources.list) | 15:54 |
| ev | I'll be feeding those back through the retracer, hopefully next week | 15:54 |
| stgraber | knome: please test ^ | 16:03 |
| * stgraber locally rebuilds the chinese image to test ubiquity | 16:04 | |
| stgraber | hmm, looks like at least the livefs from yesterday didn't pull the updates from -updates... really hoping to have the builders back soon to get a clean build, hoping it was just a temporary issue caused by the DC move... | 16:08 |
| * skaet nods | 16:09 | |
| stgraber | dobey: can you get someone to test ubuntu-sso-client and ubuntuone-installer please? | 16:15 |
| micahg | bdmurray: if you have a minute, can you accept my sync for icedtea-web into -proposed? | 16:21 |
| micahg | bdmurray: for natty/oneiric | 16:21 |
| jibel | stgraber, FYI I verified FF + FIrebug crash on Precise. | 16:21 |
| jibel | (well, I verified that it didn't crash with the version from -proposed) | 16:22 |
| stgraber | jibel: thanks. I don't think this one will be copied for 12.04.1 though as it depends on having firebug installed which isn't part of the default install, so people installing firebug post-install will also get the updated firefox | 16:24 |
| jibel | stgraber, ok. I think there is nothing more I can test in the pending sru list. | 16:26 |
| jibel | for 12.04.1 | 16:26 |
| stgraber | jibel: can you maybe help with the ubuntuone-installer ones? | 16:27 |
| stgraber | ubiquity looks good on a repacked image | 16:31 |
| jibel | stgraber, I can verify #1004003 #1004524 #1015709. 1018991 is a general bugfix without specific test and 853060 has no test case. | 16:31 |
| stgraber | skaet: did you hear anything back from slangasek regarding cedarview? | 16:32 |
| skaet | stgraber, nope | 16:32 |
| stgraber | skaet: hmm, ok... I forgot to ask him while he was still around... we basically need to know whether cedarview will be in the archive by the time we release 12.04.1, if it's, then we need to get jockey copied from -proposed | 16:34 |
| skaet | stgraber, ok, I'll see if I can chase down the info from some other directions... | 16:37 |
| === cjwatson_ is now known as cjwatson | ||
| dobey | stgraber: sure | 16:58 |
| stgraber | bdmurray, infinity: considering nspr fixes a regression in -updates, can we get it copied to -updates now? | 17:02 |
| infinity | stgraber: Depends on how nicely you ask. | 17:02 |
| infinity | stgraber: (And done) | 17:04 |
| stgraber | hmm, I'm actually wondering what update-manager will do as the upgrader will require removing packages on these weird precise systems | 17:04 |
| stgraber | though at least it'll do the right thing when upgrading from oneiric, so that's already a big win | 17:04 |
| stgraber | infinity: thanks! | 17:04 |
| infinity | stgraber: update-manager pretty much flat out refuses to remove packages (same as "apt-get upgrade"), but there's not much we can do about that situation. :/ | 17:05 |
| infinity | stgraber: Thanfully, we didn't really have nearly as many "normal users" back in jaunty times, and even fewer "normal users" who've probably upgraded through all the releases since, so there's a fair chance that anyone in said predicament can hit a console and type "apt-get dist-upgrade", which should work. | 17:06 |
| bjf | infinity: have the new ppc builders been ordered? | 17:06 |
| infinity | bjf: Dunno. Ask pgraner. | 17:06 |
| infinity | bjf: Not that it would matter right now if they had, since the world is in transit. :P | 17:06 |
| bjf | infinity, yup, it just made me think of it right now | 17:07 |
| bdmurray | micahg: what is this sync? | 17:12 |
| micahg | bdmurray: it's for the chromium regression that was accepted into precise, I wanted it to bake in -proposed before it's pushed to -security as a regression update | 17:13 |
| bdmurray | micahg: I imagine there is a precedent for this and I just don't know about it... | 17:14 |
| micahg | bdmurray: well, security team can generally stage updates in -proposed that should have further testing before release | 17:15 |
| micahg | bdmurray: I'll get jdstrand to accept them, please disregard | 17:19 |
| stgraber | skaet: missing package on the chinese media is thunderbird-locale-zh-cn, checking why it's and if there's enough space for it | 17:20 |
| bdmurray | micahg: okay, I'm just not familiar with this | 17:20 |
| micahg | bdmurray: sure, no problem | 17:20 |
| skaet | stgraber, thanks! :) | 17:20 |
| micahg | (it's more an AA thing than an SRU thing) | 17:20 |
| SpamapS | Hey just checking in. Is there any need for man power today from me? | 17:21 |
| stgraber | skaet: looks like it needs an SRU of ubuntu-defaults-zh-cn to add thunderbird-locale-zh-cn, to the Depends. I'll do that now, last chinese build shows that there's enough space on the media for it | 17:21 |
| skaet | :) | 17:21 |
| bdmurray | stgraber: so should the jockey in -proposed not be released? | 17:23 |
| stgraber | bdmurray: correct, it needs to stay in -proposed until we know what's happening to cedarview | 17:23 |
| stgraber | skaet: doh... pad.ubuntu.com is also being moved to the new DC apparently... | 17:26 |
| stgraber | skaet: do you have a note of the chinese bugs somewhere? | 17:27 |
| cjwatson | hmm. I suppose it wouldn't be a good idea for me to upgrade the xorriso version in use by nusakan during .1 prep. maybe I can upgrade it just for quantal | 17:27 |
| stgraber | skaet: looks like I want bug 1036994 | 17:32 |
| ubot2` | Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Undecided,New] https://launchpad.net/bugs/1036994 | 17:32 |
| stgraber | bdmurray: ^ can you review ubuntu-defaults-zh-cn? | 17:45 |
| stgraber | only change should be the addition of thunderbird-locale-zh-cn | 17:46 |
| bdmurray | stgraber: looking | 17:55 |
| stgraber | bdmurray: thanks | 18:00 |
| sbeattie | hrm, so the libotr security update awaiting approval is on the kubuntu, xubuntu, and other images. Are we frozen for 12.04.1 yet? | 18:19 |
| sbeattie | or can libotr be accepted? | 18:21 |
| mdeslaur | stgraber: ^ | 18:21 |
| stgraber | before 21:00 UTC is fine, we're going to be in final freeze after that | 18:22 |
| skaet | stgraber, looks like we've got builders again. | 18:37 |
| Laney | still don't ping or respond to http yet | 18:39 |
| skaet | Laney, yeah you're right. | 18:39 |
| * skaet misinterpreted a message - being optimistic :( | 18:40 | |
| stgraber | skaet: yeah, I'm monitoring port 80 and 22 on kapok and cardamom, ready to respin a bunch of 12.04.1 images as soon as it's back | 18:41 |
| stgraber | oh, actually, cardamom is back | 18:41 |
| skaet | stgraber, based on the fact we still don't have all the builders up, I think we're going to need to push the image freeze out to tomorrow, doc freeze to monday. | 18:42 |
| skaet | what time tomorrow do you think we'll get all bits sorted? | 18:43 |
| stgraber | skaet: well, I expect kapok to be back online any minute now, so in theory we could make it to the 21:00 deadline for the image freeze (doc freeze should still be moved to Monday) | 18:43 |
| stgraber | depends on cedarview more than on the DC stuff I think | 18:44 |
| stgraber | because we won't be able to build real candidates until that thing is sorted | 18:44 |
| skaet | stgraber, agree. | 18:45 |
| stgraber | skaet, Laney: I'm going to turn off all the cronjobs on nusakan as they're mostly failing anyway and I want to have all of nusakan for the 12.04.1 respin | 18:45 |
| skaet | stgraber, yes. | 18:45 |
| stgraber | bdmurray: mythtv looks good to go (fully tested, targeted for 12.04 and 7 days old), can you release it? | 19:14 |
| knome | stgraber, what's the testing "deadline" ? | 19:17 |
| knome | i can do today, but if tomorrow is okay, i'll rather do that | 19:17 |
| skaet | knome, freeze was scheduled for 2100 today (which would have been the deadline), but due to the builder fun, it looks like we'll be rescheduling to a bit later. Getting it tested today would be best | 19:18 |
| knome | ok, i'll boot my machine up in the next hour | 19:19 |
| balloons | seems the ARM builds for today are kernel panicing on reboot | 19:19 |
| stgraber | knome: oh, I was just poking #xubuntu-devel about it ;) we're discussing moving the freeze a little, but consider the deadline as 21:00 UTC still | 19:19 |
| knome | sure. i'll do that | 19:19 |
| bdmurray | stgraber: okay, looking | 19:19 |
| bdmurray | stgraber: it was at 6 days when I looked earlier ;-) | 19:21 |
| knome | stgraber, let me confirm that it is today's daily we should test? :) | 19:22 |
| stgraber | bdmurray: hehe, yeah, last I looked it was 6 days and 50% tested, refreshed a few minutes ago and it's all tested and 7 days now :) | 19:22 |
| stgraber | knome: there's no build with proposed enabled, get a clean 12.04.1 system, enable -proposed and upgrade xfwm4, then test | 19:22 |
| knome | stgraber, or, that it's in today's daily where the fix is... | 19:22 |
| knome | aha! ok, thanks | 19:22 |
| knome | stgraber, i'll get it tested a few times and test myself too | 19:23 |
| bdmurray | its odd that bug 982162 has no mythtv (ubuntu) task | 19:25 |
| ubot2` | Launchpad bug 982162 in mythbuntu "keyword missingok is missing in mythtv-backend logrotate config" [High,In progress] https://launchpad.net/bugs/982162 | 19:25 |
| stgraber | superm1: ^ | 19:26 |
| bdmurray | weird in that the approver didn't notice and that it shows up on the sru reeport - I'll still release it | 19:27 |
| bdmurray | the task just won't get auto-closed | 19:27 |
| infinity | bdmurray: Or you could add the right task. :P | 19:30 |
| infinity | Oh, too late. | 19:31 |
| stgraber | skaet: hmm, actually, moving the freeze to tomorrow won't achieve much as we don't release SRUs on Fridays... | 19:42 |
| skaet | stgraber, only exception that should go in after 2100 today is likely to be cedarview. | 19:46 |
| skaet | if all the ducks line up. | 19:47 |
| knome | quack! | 19:50 |
| stgraber | skaet: ok, I'll need a bunch of copies before 21:00 then, most of them are still being tested as we speak | 19:51 |
| skaet | infinity, ^ can you help with the copies? | 19:54 |
| infinity | I'm sure I can. | 19:55 |
| stgraber | infinity: Please copy ubiquity, ubuntu-defaults-zh-cn and tzdata, these are the safe ones on my list (fully tested, diff makes sense, very low risk of regression). | 19:57 |
| stgraber | dobey: what kind of testing did you do for bug 937132? I see you changed it to verification-done but didn't leave a comment and there's no testcase in the bug description. | 19:59 |
| ubot2` | Launchpad bug 937132 in ubuntu-sso-client "ubuntu-sso-login crashed with RuntimeError in /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py: Gdk couldn't be initialized" [High,Fix committed] https://launchpad.net/bugs/937132 | 19:59 |
| infinity | stgraber: Done, done, and done. | 20:02 |
| stgraber | infinity: thanks | 20:02 |
| skaet | thanks infinity, stgraber. :) | 20:07 |
| dobey | stgraber: sorry, added a comment; verified from the diff | 20:14 |
| stgraber | skaet: we'll probably have to accept some stuff after 21:00 UTC as xfwm4 isn't built on all architectures because of missing arm and powerpc buildds :( | 20:24 |
| stgraber | I re-scored to make sure they build as soon as a buildd appears | 20:25 |
| skaet | stgraber, understood. | 20:26 |
| skaet | stgraber, I've done task 4 and part of 5 (will finish it when london's online tomorrow) on the release minus 7 day tasks | 20:31 |
| stgraber | skaet: ok | 20:34 |
| stgraber | infinity: did you make any progress on bug 1017001? | 20:36 |
| ubot2` | Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001 | 20:36 |
| infinity | stgraber: Not yesterday, it's on my list this afternoovening. | 20:37 |
| infinity | stgraber: Unless you've suddenly found yourself flush with free time, you're welcome to it. | 20:37 |
| stgraber | hehe, well, I might at least try the reproducer, kind of stuck on having the DC offline for the next things on my todo... | 20:37 |
| knome | verification-done on #1001936 ! | 20:38 |
| knome | bdmurray, stgraber, skaet ^ | 20:38 |
| stgraber | knome: thanks | 20:39 |
| knome | np, happy to do that | 20:39 |
| skaet | thanks knome | 20:41 |
| knome | :) | 20:41 |
| infinity | stgraber: Alright, in the interest of not duplicating too much effort, I'm going to attack the quantal X stack with an axe. | 20:42 |
| stgraber | infinity: at least the reproducer works as expected | 20:54 |
| stgraber | now to figure out how to fix it | 20:54 |
| infinity | stgraber: Have you got a pkgProblemResolver we can unwind? | 20:56 |
| dobey | looks like all the bugs for ubuntu-sso-client and ubuntuone-installer are verification-done now as well | 20:58 |
| stgraber | infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade/ is what do-release-upgrade left on the system after trashing it | 21:01 |
| infinity | Hrm. So ifupdown, initscripts, and upstart all correctly land in the same dpkg run. | 21:04 |
| infinity | Which means this isn't an apt issue. | 21:04 |
| infinity | If there's a loop there, dpkg should be breaking it. | 21:04 |
| infinity | But it could be a pre-depends loop, which I suspect leads to undefined and/or broken behaviour. | 21:04 |
| stgraber | I'll reinstall the system as there's essentially no easier way to recover it... before I do that, here's the output from a dpkg --configure -a: http://www.stgraber.org/download/bug1017001/dpkg-configure-a | 21:06 |
| stgraber | I believe the on screen output might actually have been better than the logs, will use tee on the next run to save it | 21:09 |
| infinity | stgraber: FYI, the jockey bug has been set back to v-needed. I'd really like to know that someone tested it against the cedarview binaries in the archive, rather than just pseudo-tested that it's executing the right codepaths. | 21:15 |
| stgraber | sounds good | 21:15 |
| stgraber | infinity: full terminal log: http://www.stgraber.org/download/bug1017001/terminal.log | 21:19 |
| infinity | I kinda wonder why udev doesn't end up in that same dpkg run. | 21:22 |
| infinity | But it probably doesn't relate. | 21:22 |
| infinity | It could, mind you... | 21:22 |
| === gallth is now known as tgall_foo | ||
| stgraber | initscripts breaks udev (<< 146-2~boot6) | 21:25 |
| stgraber | upstart depends on initscripts and libudev0 (>= 151) | 21:26 |
| infinity | Version of udev on system is 151-12. | 21:26 |
| stgraber | ifupdown depends on initscripts (>= 2.88dsf-13.3) | 21:26 |
| stgraber | right, so these aren't the problem | 21:27 |
| infinity | We could build a mess of pre-depends here to "fix" it, but that's almost never a good answer. | 21:30 |
| infinity | (Like, I bet you'd find that, maybe, a completely BS pre-dep from mountall to plymouth, or similar, might magically funroll the loop) | 21:31 |
| infinity | Oh, and indeed, there's the only Pre-Dep in the whole chain. | 21:34 |
| infinity | Package: resolvconf | 21:34 |
| infinity | Pre-Depends: initscripts (>= 2.88dsf-13.10) | 21:34 |
| infinity | I wonder if that's breaking the world. | 21:34 |
| infinity | And if it needs to. | 21:34 |
| infinity | Hrm, changelog has a viable argument for why. | 21:35 |
| infinity | Oh, and to be fair, that log never even gets around to upgrading resolvconf. | 21:35 |
| infinity | Or installing it, rather. | 21:36 |
| infinity | stgraber: Bleh. Well, to obvious loop is between ifupdown and upstart. What's not obvious is how to solve it. | 21:40 |
| stgraber | infinity: the upgrade is still running but it looks like getting rid of friendly-recovery pre-upgrade works around the problem | 21:40 |
| infinity | stgraber: That's... Curious. | 21:41 |
| stgraber | ah, blows up later apparently, checking for the reason | 21:41 |
| infinity | stgraber: And not particularly helpful, since it's in the standard task. | 21:41 |
| stgraber | ok, unrelated explosion, it blows up on libgtk/libcairo/... stuff later on | 21:42 |
| infinity | Same sort of "large unpack, then mess up the ordering" issue, or entirely unrelated? | 21:42 |
| stgraber | good old postinst failure ;) | 21:44 |
| stgraber | in fontconfig-config apparently | 21:44 |
| infinity | No dbus running? | 21:44 |
| stgraber | "failed to remove /var/lib/defoma/fontconfig.d: Directory not empty" | 21:44 |
| infinity | That shouldn't be a failure. | 21:44 |
| infinity | Anyhow. | 21:44 |
| infinity | Definitely unrelated. | 21:44 |
| stgraber | yep, that just shows me what will need fixing once the other one is fixed ;) | 21:45 |
| infinity | Have a full terminal log of that? Removing friendly-recovery isn't an option, but if doing so subtly changes the unpack/configure order, we might be able to sort out how to fake it. | 21:45 |
| stgraber | sure, let me grab a tarball of /var/log/dist-upgrade | 21:45 |
| stgraber | infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-without-friendly-recovery/ | 21:46 |
| infinity | stgraber: Hrm, that might actually tell us nothing. It never gets around to configuring any of the problem packages. | 21:49 |
| infinity | stgraber: Unless none of upstart, ifupdown, initscripts, etc have postinsts, which seems unlikely. :P | 21:50 |
| infinity | stgraber: So, that was just a wildly different configuration order that broke on something else before it got around to (potentially) breaking on configuring ifupdown. | 21:50 |
| stgraber | infinity: FWIW, after doing an rm -Rf of that directory, the upgrade happily continued without any extra error, though that's probably because it just took a different path | 22:02 |
| stgraber | infinity: well, removing friendly-recovery and wiping /var/lib/defoma/fontconfig.d before install makes the upgrade succeed | 22:24 |
| stgraber | s/install/upgrading/ | 22:24 |
| infinity | stgraber: Curious. | 22:27 |
| infinity | stgraber: So, a terminal log of that successful run might be helpful, if it shows a different config order. | 22:28 |
| stgraber | infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-success/ | 22:31 |
| infinity | Right, so that clearly shows upstart being configured earlier than everything else in the loopy mess. | 22:35 |
| infinity | The question is why, and how can we force that situation... | 22:35 |
| infinity | stgraber: I wonder if just changing the upstart-job dep to a versioned upstart (>= preciseish) would magically break the loop differently. | 22:37 |
| stgraber | I can try that. It's not likely we're going to get another package to provide usptart-job anytime soon anyway | 22:40 |
| * stgraber builds a new ifupdown and a custom upgrader to avoid wiping extra source entries | 22:41 | |
| infinity | stgraber: A less drastic but possible loop-breaker could be to Breaks: upstart (<< precise) | 22:44 |
| stgraber | infinity: not sure I can easily drop upstart-job though, it comes from dh and is added when calling dh_installinit | 22:45 |
| stgraber | infinity: I'll try the Breaks instead | 22:45 |
| * infinity decides he could use a break for breakfast. | 23:05 | |
| infinity | Or whatever you call it when you've been up for 11 hours but forgot to eat. | 23:06 |
| stgraber | infinity: looks like the Breaks made me hit the fontconfig-config bug. Will confirm once it's done upgrading and I have logs | 23:09 |
| stgraber | if that's indeed the case, then we have a workaround and I'll just SRU a fix for fontconfig-config's postinst to do an rm -Rf and be done with that one | 23:09 |
| * skaet thinks food is a good idea... | 23:26 | |
| infinity | stgraber: Is the rm really the right answer there? Doesn't something own that directory that can properly clean up if you just make the failing rm non-fatal? | 23:26 |
| infinity | stgraber: But if it's unowned, and belongs (more or less) to fontconfig-config, then yeah, that'd do. | 23:27 |
| stgraber | infinity: yeah, checking what's in there and what owns it is on my list for my next clean upgrade, for now I just wanted that problem gone to test the other fix properly ;) | 23:31 |
| RAOF | Oh, oh. Looks like cups 1.5.3-0ubuntu3 regressed a fix from 1.5.3-0ubuntu2. (See last two comments on https://bugs.launchpad.net/ubuntu/+source/cups/+bug/973270) | 23:38 |
| ubot2` | Ubuntu bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released] | 23:38 |
| RAOF | !regression-alert | 23:40 |
| ubot2` | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 23:40 |
| stgraber | infinity: so, the Breaks moved the problem away from ifupdown but the same kind of mess is now showing up with procps | 23:41 |
| stgraber | the good news is that moving the problem although it's causing a bunch of critical looking errors during the upgrade, actually leads to an almost working system that turns into a fully working system after a dpkg --configure -a + apt-get install resolvconf | 23:42 |
| stgraber | will upload the logs somewhere | 23:42 |
| stgraber | infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-with-ifupdown-and-fontconfig/ | 23:44 |
| stgraber | infinity: the file in fontconfig.d is an unowned id-cache file | 23:52 |
| stgraber | disappearing for a couple of hours | 23:57 |
| stgraber | all the logs are at http://www.stgraber.org/download/bug1017001/ | 23:57 |
| infinity | stgraber: Still looks like a case of "upstart not configured early enough"... Ugh. | 23:58 |
| stgraber | infinity: yeah, the new one is pretty much identical to the ifupdown one, just hitting procps | 23:58 |
| stgraber | so I'm suspecting we'd get that until we add a Breaks to every single package containing an upstart job | 23:58 |
| infinity | stgraber: It breaks way before procps (still an upstart-job thing, though) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
