[03:49] Good morning [03:50] infinity: pkgbinarymangler> yeah, catching up with a recent debhelper change [03:51] TheLordOfTime, SpamapS: the apport retracer does not use -proposed for quantal; we do not expect anyone to run quantal-proposed [03:52] ev: https://bugs.launchpad.net/daisy/+bug/1052954/comments/2 - my thoughts [03:52] Launchpad bug 1052954 in Daisy "top-k for arbitrary ranges is complex" [Undecided,New] [03:52] TheLordOfTime: it cannot currently handle multiple different versions within the same distro [04:12] infinity: do you know whether our arm builders changed in any way in the last couple of weeks? running stuff in parallel, or running several builds at once, or anything which would make them have a higher load? [04:13] infinity: I'm still stunned at how many timing tests in glib's test suite suddenly fail (I'm disabling most of them now on arm, it's hopeless) [04:23] pitti: Well, they all got upgraded to precise and, perhaps that's causing issues, but it shouldn't be... [04:24] infinity: ah, so at least there was _some_ change, and it's not totally inexplicable [04:24] * pitti now watches the umpteen version build [04:24] yesterday evening's crashed with an internal compiler error, but that seemed to be spurious [04:25] and this morning's managed to fail yet another timing test which hasn't before; I wish they could all fail at the same time instead of serially :) [04:26] pitti: It could be more related to differing aggressiveness of swappiness or something mostly unrelated. Machines with low RAM and swap over USB are never going to play nicely when you're expecting to have 100% CPU to yourself. [04:27] right, but they weren't that unstable until a few weeks or so ago, and Debian's work rather fine as well; that's what made me wonder what changed [04:28] anyway, once this manages to build two or three times in a row, it should be fine again [04:28] it's enough to test the timing properties on the other arches [04:35] pitti: With any luck, we can back most/all of this mess out when we have "real server hardware". [04:35] pitti: Debian's buildds may be in better shape for two reasons: their armel buildds all have 2.5G of RAM, and their armhf ones, while only have 1G (and being slower in every other respect than the Pandas) are swapping over SATA, so don't waste a ton of CPU time on that. [04:37] ah, thanks; so yes, swapping and random I/O could indeed explain the ridiculously high times that some tests need === sgnb` is now known as sgnb [05:30] Will my upload of opus 1.0.1 turn heads due to its timing? (opus is a new package in quantal and our current synced version is prerelease. 1.0.1 has been standardized as the reference implementation by RFC) [05:32] YokoZar: It's unseeded and is bugfix? [05:32] RAOF: Yeah pretty much. [05:33] I think it's unseeded at least, it would be surprising if it were [05:33] Should be fine [05:36] opus's binaries are not seeded. [05:37] YokoZar: I concur with RAOF. sync/upload away [05:39] SpamapS: We're jumping ahead of Debian actually. I'm sending patches though :D === dendrobates is now known as dendro-afk [06:55] heya [06:55] Yo! [07:05] good morning === doko_ is now known as doko [07:15] Laney, see http://sourceware.org/bugzilla/show_bug.cgi?id=14625 [07:15] sourceware.org bug 14625 in binutils "[2.23/2.24 regression] ar: File truncated" [Normal,Resolved: invalid] [07:47] Laney, seb128: see http://sourceware.org/bugzilla/show_bug.cgi?id=14625 looks like the webkit developers need to find another solution for their mega archive, maybe splitting it into smaller ones [07:47] sourceware.org bug 14625 in binutils "[2.23/2.24 regression] ar: File truncated" [Normal,Resolved: invalid] [07:53] doko: indeed, https://bugs.webkit.org/show_bug.cgi?id=94435 [07:53] bugs.webkit.org bug 94435 in WebKit Gtk "[GTK] Split WebCore/platform into a separate library" [Normal,Reopened] [07:54] and if it did work before, it was buggy ... === henrix_ is now known as henrix [07:55] :-) [08:00] Laney, and likely you won't need the make patch either ... [08:00] yes, indeed, same cause [08:01] for bonus points, please backport to qt4-x11, so that we can get the thing built on arm too ... [08:01] when there's a working patch [08:02] ahh, there's not? [08:02] look at the linked bug, the fix they added broke some other parts of the build so it was reverted [08:03] looks like implicit template instantiations ... [08:05] Laney, maybe http://gcc.gnu.org/PR54145 [08:19] is it possible to generate input events from the command line? but without the tools from the package xautomation. I need this for an embedded system without X. I tried "echo 60 > /dev/input/event0" but that does not work [08:38] jodh, please could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843612 ? [08:38] doko: looking... [08:49] pitti, is ubuntu-drivers-common supposed to ftbfs on arm*? [08:50] doko: no, certainly not [08:50] https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3843190 [08:50] https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.69 looks fine, though [08:50] doko: ah, race condition again [08:50] utterly slow arm builders FTW [08:50] doko: looks like the failing test has hit the issue seen in the follow-on test: occasionally, the test fails to see the trailing '\n' or '\r', but only if the process is forcibly killed. Its either a very obscure Upstart logger bug or an even more obscure pty/tty layer kernel bug. In summary - I suspect re-running that build will pass, but ping me if this is repeatable as it might allow us to hone in on the root cause. [08:56] jodh, given back [09:02] when will postgresql 9.1.6 be released in -updates for ubuntu 12.04? [09:02] lifeless: thank you! [09:03] I need sponsoring here, can anybody review my branch? [09:03] when are packages moved from -proposed to -updates, does it occur on certain days? [09:06] joeljacobson, I don't think so - it rather happens when there is positive verification on the relevant bug(s). [09:10] diwic: ok, thanks, so I just have to wait [09:12] joeljacobson: is there a particular package you're interested in? [09:12] cjwatson: postgresql 9.1.6 [09:12] maintained my Martin Pitt, https://launchpad.net/~pitti [09:12] it's in -proposed now [09:13] joeljacobson: http://people.canonical.com/~ubuntu-archive/pending-sru.html shows that as still being much too recent (1 day) [09:13] joeljacobson: you can also monitor bug #1055944 [09:13] Launchpad bug 1055944 in postgresql-8.4 (Ubuntu Natty) "New bug fix releases: 9.1.6, 8.4.14, 8.3.21" [Undecided,In progress] https://launchpad.net/bugs/1055944 [09:13] joeljacobson: the usual rule is that updates age for 7 days in -proposed to allow time for people to point out regressions [09:14] occasionally we waive that, but the circumstances have to be abnormal [09:14] 7 days, didn't know that, thanks [09:16] stgraber, https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3822117 [09:16] ok, sounds like a reasonable time to wait, noone wanna be the first to upgrade :) [09:19] jodh, rebuild did succeed [09:22] seb128: it seems like it's a failed retrace, but I can't conclusively narrow it down to one in particular. I'm going to give more attention to https://bugs.launchpad.net/daisy/+bug/1044418 after (or maybe during) we sort out https://bugs.launchpad.net/daisy/+bug/1052954. There's a lot to consider though, so it wont be something that gets done this week. I will, however, keep you posted on the progress. [09:22] Launchpad bug 1044418 in Daisy "Reprocess failed retraces" [Undecided,New] [09:22] Launchpad bug 1052954 in Daisy "top-k for arbitrary ranges is complex" [Undecided,New] [09:23] ev, ok, thanks [09:23] sure thing [09:23] ev, do you know why the launchpad retracers work on that one but not the e.u.c ones? [09:23] ev, they should have access to the same binaries, [09:24] yes, but the launchpad retracers deal a bit better with transient failure at the moment. I need to balance failing hard like the launchpad retracers do when they hit a problem in apport-retrace against webops' pagers going off [09:25] I do have some improvements here that we had to back out about two weeks ago [09:25] I'll revisit them this week [09:26] ok [09:26] ev, I'm just surprised because that bug got successfull retracing on launchpad for a timeframe higher than a week [09:26] so it shouldn't be a "transient" thing [09:27] we are in a somewhat established state [09:27] ev, do we have an estimation of what % of reports fail retracing atm? [09:27] seb128: once we have a successful or failed retrace on daisy.ubuntu.com, we don't accept any more core dumps and don't do any more retracing on that particular signature [09:28] oh, ok, I see [09:28] that's unfortunate [09:28] seb128: I can run a query for the percentage, sure [09:28] seb128: yeah, it prevents us from continually asking for a core dump that will fail to retrace [09:28] like when the ddebs needed are out of date [09:29] right, ideally we would have a line on e.u.c about the issue and the associated count at least [09:29] I'm concerned that we might miss quite a lot during unstable cycle [09:30] especially due to the dbgsym server nature [09:30] it updates every few hours [09:30] we do [09:30] so the first retrace is likely to fail (and often does) because the dbgsym are not there yet [09:30] any problem that's failed to retrace shows up on the main page (if it has a high enough count) [09:30] ok [09:30] their identifiers start with "failed:" [09:30] I'm surprised that nautilus bug doesn't show there then [09:31] way way way back when the website was first launched, we hid them [09:31] it got over 60 dups on the launchpad side [09:31] but I was equally concerned about brushing the problem under the carpet [09:31] which by itself should be enough to make it one the top nautilus list of the month [09:31] one->on [09:32] right, which is why I think it might be this: [09:32] https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B424%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2 [09:32] B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec [09:32] or this: [09:32] https://errors.ubuntu.com/bucket/?id=failed%3A%2Fusr%2Fbin%2Fnautilus%3A6%3Ai686%3A%5Bvdso%5D%2B416%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B2e1ef%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B31835%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27095%3A%2Flib%2Fi386-linux-gnu%2Flibc-2.15.so%2B27147%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B3750f%3A%2Fusr%2Flib%2Fi386-linux-gnu%2FlibX11.so.6.3.0%2B14e72%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2 [09:32] B6cbc5%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e840%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B4e8eb%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibcairo.so.2.11000.2%2B16b19%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B558c0%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgdk-3.so.0.400.2%2B3252d%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgtk-3.so.0.400.2%2B2e4c61%3A%2Fusr%2Flib%2Fi386-linux-gnu%2Flibgobject-2.0.so.0.3200.3%2Bf1ec [09:32] heh, need to come up with shorter URLs [09:32] ;-) [09:33] ev, I doubt it's any of those [09:33] oh? [09:33] it should have dbusmenu-gtk4.so in the top of the stacktrace [09:33] what should I be looking for? [09:33] ah, okay [09:33] I'll see if I can dig one up that matches [09:33] mpt: when you have a moment [09:33] sorry [09:33] g_type_check_instance_cast () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 [09:33] ?? () from /usr/lib/x86_64-linux-gnu/libdbusmenu-gtk3.so.4 [09:33] g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 [09:34] unrelated :) [09:34] ev, ^ that's the top of the libs [09:34] seb128: cheers [09:34] pitti: glib on ARM really seems to dislike you. :P [09:34] * pitti pulls his hair out [09:35] * pitti retries and prepares another upload [09:37] pitti: Check both logs, they failed different tests. :/ [09:37] yes, I saw [09:37] cjwatson: postgresql 9.1.6 is a quite serious bug fix, so perhaps the 7 days could be somewhat reduced, due to the urgency of the update? [09:37] pitti: Is it all really just timing stuff? I didn't read mainloop/recursive_child_sources, but that could be a genuine bug? [09:38] it succeeded all the time since we had test failures FTBFS, and it doesn't happen every time either [09:39] Maybe I should start writing nice letters to everyone who makes ARM kit with 4G of RAM and begin begging. [09:40] Getting so very sick of all of this swap death. [09:41] glib 4 - 0 pitti [09:41] go pitti go ;-) [09:41] 4? it's 7 now! [09:41] crazy... [09:42] maybe until we have proper arm builders we should make the tests non-fatal again on arm, and keep them "on" on debian only [09:42] how come Debian's are better? [09:42] infinity, we just need a properl beowulf hack to the kernel and can then use a battery of USB hubs to build clusters with these http://store.cstick.com/business/cotton-candy.html ;) [09:43] infinity, it was better before ... and the not so nice thing is that the local builds do work [09:43] Laney: Debian's armel builders are ancient Marvell armv5 boards with 2.5G of RAM, and Debian's armhf buildds suffer similar swap pain, but swap to SATA, which might be mildly less CPU load. [09:43] Sweetshark, packaged libvigraimpex 1.8.0 in doko/toolchain. please could you test build lo against it? [09:44] doko: Yeah, it's also possible that the precise kernels swap more aggressively or something, I haven't had the time to throw much science at it yet. [09:44] do you know how to throw science? [09:44] * doko ducks [09:44] doko: Sadly, we need the precise kernels for OTHER reasons, but if they really have regressed from natty in this case, we should be able to sort it out with some fiddling. [09:46] joeljacobson: most SRUs are serious for one reason or another, but regressions are even worse [09:46] the test is "emergency" rather than "serious", really [09:46] pitti: ^- what do you think? [09:47] well, it's not emergency, they advise "REINDEX at a convenient time" [09:47] but feels a bit shaky to run a production database with potential index corruption, I would really like to upgrade yesterday [09:48] cjwatson: I do think that we shouldn't wait the full 7 days for this, but 1 day seems too rushed for me [09:48] no new features in the minor postgres releases, so regressions shouldn't be a problem [09:48] I agree that it's urgent enough to waive the 7d wait, from my examination of it, but I do want to know it's well-tested first. [09:48] while regressions are rare, they did happen [09:48] infinity: fiddling with /proc/sys/vm/swappiness should allow you to confirm if it the swapping [09:48] I have quite a lot of people who use my PPA, and I'm watching the upstream bug list [09:49] joeljacobson: we're a little more paranoid than default since at scale you get regressions from all kinds of things; we've had regressions in other packages from no-change rebuilds before [09:49] hence the testing process [09:49] amitk: Indeed, and when I find some round tuits, I'll try to do some fiddling. Sadly, reproducing the issues the buildds see isn't a particularly exact science to start with. [09:49] I would say 3 days is accetpable, but 7 days will cause people like me to start considering compiling from source or adding -proposed to the apt sources [09:49] I'm fine to defer to pitti/infinity on waiving it down a bit, but yeah, 1 day is too quick [09:49] joeljacobson, that would be one more tester ;) [09:50] joeljacobson: If you want/need it right now, please *do* install it from proposed and followup to the bug to let us know if it's working well (or not!), which helps us decide if it's ready to release to the world at large. [09:50] doko: perhaps someone else who doesn't process millions of physical bank transactions can test first? :) [09:50] grr, d-i lowmem mode gives a black screen on amd64. that's unhelpful [09:51] (in kvm) [09:51] joeljacobson: I'm going to assume that if you're in such an environment, you also perhaps have mirrors of production data that you can test with before blindly upgrading production machines? ;) [09:52] infinity: the bug in 9.1.5 caused the hot-standby machines to fail swallowing the WAL-files, so no, I don't, well actually I do now since I've made a new pg_basebackup, and yes, of course I'll upgrade the slave first, that's standard procedure [09:53] infinity: OK, I'll upgrade from -proposed, sounds good. How can I upgrade just postgresql from proposed? Adding it to apt sources will upgrade a lot of other stuff, won't it? [09:53] joeljacobson, out of curiousity, what company are you working for? [09:54] diwic: Trustly Group AB in Sweden, we handle all bank payments for almost all gambling companies in the world [09:55] joeljacobson: You can either enable proposed, apt-get update, and then selectively "apt-get install foo libfoo foo-common libfoo-bin etc" or just grab the appropriate debs from https://launchpad.net/ubuntu/+source/postgresql-9.1/9.1.6-0ubuntu12.04/+build/3852858 and "dpkg -i foo.deb libfoo.deb etc" [09:55] joeljacobson, what are the current odds for your upgrade failing, I wanna bet ;-) [09:55] joeljacobson: I already ran the upstream and the p-common test suites against it, which have a fairly good coverage [09:57] diwic: I'll give you 1000 times the money, but I would prefer to bet myself instead of laying a bet, to hedge against the consequences if something would go wrong [09:57] pitti: ok, thanks, that's good to hear [09:59] joeljacobson, just kidding. Lycka till :-) [10:01] diwic: hahah, are you Swedish? [10:36] Sweetshark, see bug #1056759 [10:36] Launchpad bug 1056759 in libvigraimpex (Ubuntu Quantal) "libvigraimpex ftbfs from source (core dump running the tests), 1.8 prepared" [High,Confirmed] https://launchpad.net/bugs/1056759 [11:00] hi [11:01] I was reading this http://benjaminkerensa.com/2012/09/25/technical-diagram-of-how-unity-shopping-lens-likely-works - do you confirm me that everything I enter in my dash is trasmitted to productsearch.ubuntu.com O_o ?! [11:02] #ubuntu-unity more likely to have accurate details === tkamppeter_ is now known as tkamppeter [11:03] cjwatson: ok thanks, I will ask there === mcclurmc_away is now known as mcclurmc [11:19] barry,doko: heh, I just noticed that python (i.e. 2) is explicitly listed in the minimal seed [11:19] do we want that to be python3 now? [11:20] sure, however I think we will still install python for a minimal/buildd install? === MacSlow is now known as MacSlow|lunch [11:24] apt-get install libpq5 postgresql-9.1 postgresql-client-9.1 postgresql-contrib-9.1 postgresql-plperl-9.1 [11:25] .... so far so good ... holding my thumbs :) [11:26] haha, is that the Swedish expression? [11:26] here we'd say "crossing my fingers" :-) [11:29] Laney: it sounds like direct translation of Polish phrase [11:29] (holding my thumbs one) [11:29] funny [11:33] doko: Well, we do right now, but should we? Anything that needs it to build should build-depend on it, surely [11:34] Likewise I wonder if we should seed python3-minimal in required, not python-minimal [11:35] the only thing I can think of are python scripts, without having a python dependency, which did escape dh_python2, or when dh_python2 wasn't used [11:35] but probably uncommon [11:36] This would shrink debootstrap output by 9%, so not to be sneezed at [11:36] I dunno, if you think it's too risky we could do it first thing in R instead [11:36] I just hadn't read germinate output in a while and it stood out immediately === Amoz_ is now known as Amoz [11:38] cjwatson, no, I think it's fine. debian needs it as a dep in any case, so for the majority of packages it's no issue === cpg is now known as cpg|away [11:41] do we have any git experts? [11:42] doko: I think I'll do it after b2 then [11:55] hi all [11:55] xnox: do you mind if I have a look at #1015567? [11:56] bug 1015567 [11:56] Launchpad bug 1015567 in dpkg (Ubuntu Quantal) "upgrade failed: mixed non-coinstallable and coinstallable package instances present" [Critical,Triaged] https://launchpad.net/bugs/1015567 [11:56] mvo: yes please. I had some pokes at it, but not much. [11:57] mvo: with recent/current dpkg I couldn't reproduce the state to trigger the bug, unless I did rm in dpkg/info. [11:57] xnox: it just happened to me on upgrade on of my boxes from precise->quanal and the system is in the broken state [11:58] mvo: nice. [11:58] xnox: and it seems like the only way to get out of this is to manually vi /var/lib/dpkg/status :) [11:58] xnox: so thats a good excuse for me to look at it a bit [11:58] doko: thanks for the bug, will switch to internal for the next upload. [11:59] mvo: the infinity's idea is to make dpkg treat RC packages as multi-arched if needed. E.g. equivalent of adding Multi-arch: same headers to status. [11:59] Sweetshark, always for the least effort, not the best solution? [11:59] mvo: except that dpkg's parsing and enumerating status is very interesting for an uninitiated developer like me. [12:01] xnox: yeah, I think that idea of infinity is a good one [12:01] xnox: *cough* s/an uninitiated/any/ ;) [12:02] * mvo makes more tea [12:03] doko: gimme a team and I will start caring for vanities. [12:03] mvo: i was not sure you can safely do such substitution, without locking-> read/rewrite/fix status -> re-read the status -> continue. Since the counts of multiarch/non-multiarch packages was order depended in the status file as far as I could read it. [12:04] xnox: right, I need to look at it a bit, I have no real idea just yet === dendro-afk is now known as dendrobates [12:48] Daviey, zul: is feedparser a server package? [12:48] Daviey: i believe so [12:48] python-feedparser? [12:49] yes [12:49] i believe so [12:49] why? [12:49] test failures, see the test rebuild [12:49] doko: cool ill have a look [12:49] same errors in 5.1.2 === MacSlow|lunch is now known as MacSlow [12:57] k3b on Quantal, Precise, Oneiric; the k3b i386 package is depending on libc6 >= 2.4 but libc6 is v2.15, so k3b cannot be installed. I've been looking at the build logs to confirm it. Am I missing something obvious here about the libc6 versions? [12:58] TJ-: yes, 15 > 4 so 2.15 > 2.4 (the . is a delimiter not a decimal point) [12:59] Might be easier to post the full error messages rather than an interpretation of them [13:00] And remember that apt often doesn't follow the full chain when something goes wrong and has to be helped to produce the real error [13:00] geser: Thanks. My brain must not have woken up yet! I totally confused myself over that :s [13:01] geser: I think I transliterated 2.4 to 2.40 [13:11] zul: found out that the tests pass with libxml 2.9 from experimental [13:12] doko: thats not good..ill see if i can find a fix === yofel_ is now known as yofel [13:19] doko: hmm, yeah, I guess I'm touched-it-last on that one, though the real fix would be to kill it completely as it shouldn't be needed anymore... [13:19] seb128, didrocks: is it still the plan to get rid of launchpad-integration completely this cycle? I see that the only rdepends remaining is quickly-ubuntu-template [13:20] then we should be able to remove it from the archive completely [13:20] stgraber, quickly was fixed yesterday [13:20] stgraber, do it! [13:20] there is also a ftbfs fixed version in the unapproved queue [13:20] of launchpad-integration [13:20] seb128: oh, cool, then I guess we can unseed it and kill it for good then [13:20] it's in universe? [13:21] what do you mean unseed? [13:21] zul: just rebuilt the libxml2 version in quantal. same errors, so it should be something in the upstream changes [13:22] doko: gotcha [13:22] seb128: seeded-in-ubuntu was telling me it was still seeded somehow, but it's just because we haven't rebuilt a dvd image in a long time, so all good to remove then [13:23] well, the reason I kept it is appdev [13:23] quickly was promoting it for a while [13:23] so I don't know if we should keep the binaries available for an extra cycle [13:23] e.g I don't know if out of the archive stuff still depends on it [13:23] hmm, yeah, I guess that'd be reasonable [13:23] there is a version which fix the ftfbs in unapproved as said [13:24] I think it doesn't cost lot to keep it in universe for quantal [13:24] right, let me accept the fixed version for now so doko is happy and I'll re-target bug 999413 to R [13:24] Launchpad bug 999413 in launchpad-integration (Ubuntu) "Remove launchpad-integration from the archive" [Medium,Triaged] https://launchpad.net/bugs/999413 [13:25] thanks [13:25] stgraber, I'm only happy when http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120922-quantal.html is empty [13:26] there is a fixed gtk2-engines as well in unapproved [13:26] doko: you must be a pretty sad man then ;) [13:26] that package is not going to get cleaned a lot until we unfreeze I guess [13:26] I just hope people check unapproved before duplicating work [13:33] * doko loves colored non-verbose build logs ... elinks === joeljacobson_ is now known as joeljacobson === joeljacobson_ is now known as joeljacobson === slank` is now known as slank [13:50] Riddell, ScottK: I'll leave the kubuntu ftbfs for you ... === slank is now known as Guest84818 [13:51] doko: What happened with https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3837464 - There's no log. === gepatino_ is now known as gepatino [13:54] probably broke the buildd [13:54] that seems to be the failure mode [13:57] Riddell or debfx: No idea how to troubleshoot that one. [13:58] doko has been complaining about that build for some time [14:01] Any ideas why sudo do-release-upgrade -d says no new release found even though /etc/update-manager/release-upgrades is set to normal? [14:01] ScottK, buildd issue. please don't give back. kills the cats [14:02] OK. [14:02] What if I don't like cats? [14:02] ScottK: no, that is unexpected, you can run "DEBUG_UPDATE_MANAGER=1 do-release-upgrade -d" to see if that outputs something useful [14:03] Sure. [14:07] didrocks, seb128: is there an easy work around for #warning "Including directly is deprecated." ? [14:08] mvo: http://paste.ubuntu.com/1228511/ [14:10] ScottK: confusing, a 404 - is there anything between you and changelogs.ubuntu.com? like a proxy (transparent) or somesuch that might cause this? [14:10] No. Let me try it in a browser [14:11] mvo: My fault. I had redirected that url to a different IP address when we were doing testing and forgotten. Sorry for the bother. [14:13] Works fine once that's removed. [14:13] * ScottK shakes fist at Riddell. [14:13] ScottK: no worries [14:13] ScottK: happy to hear that it works now [14:20] ScottK: what what? [14:21] About the fact that I couldn't upgrade because I had changelogs.ubuntu.com redirected to your server for the precise upgrade test we did ... [14:21] Not really you fault ... [14:25] ScottK: oh I see :) [14:25] doko: which kubuntu ftbfs? in the build tests? [14:26] Riddell, yes [14:26] doko: yeah those are on my radar [14:26] thanks [14:36] smoser: meh, I just ran into https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/1015692 - this is more than just priority low to me :/ [14:36] Launchpad bug 1015692 in offlineimap (Ubuntu) "offlineimap and ssl requires configuration of fingerprint" [Low,Confirmed] [14:36] mvo... [14:37] that's an xnox package :P [14:38] mvo, i dont have a really good solution. as i said in that bug. its really upstream created issue. [14:38] mvo: I was considering to make system-wide ssl certs as defautl. [14:38] but now they're just causing failure when previously they just did not check certificates. [14:38] so in some sense its a feature [14:38] cause than it just works with gmail =) [14:39] xnox: what is stopping us? that sounds like the right thing to do [14:39] and is secure, cause if the system-wise ssl certs in /etc/ are busted.... then there are bigger problems than offlineimap. [14:40] mvo: nothing. Just need to find time to change that default and push it: upstream, debian & ubuntu as I have commit access everywhere. [14:40] xnox: cool [14:41] xnox: when I find a bit of time I will give it a go too, but keep an eye on it to ensure we don't duplicate work [14:41] mvo: ok. [14:41] mvo: I like your dpkg patch by the way. I will run against my fake test cases that I have in pbuilder somewhere to trigger it. [14:42] mvo: and the upload. It just seems like we will have to keep that fix..... forever..... [14:42] xnox: cool, let me know, I got no feedback from #debian-dpkg yet [14:42] xnox: yeah, we could make the count count single, multiple, conf, total, that would be a bit less hacky [14:42] mvo: you wouldn't, because it doesn't effect debian at all. [14:43] xnox: well, sometimes I still get feedbck for ubuntu only stuff because they are nice people [14:43] hm.. [14:43] mvo: "broken multiarch was never part of debian" (tm) [14:43] are there not net-device-up events for bridge interfaces? [14:43] i configured a bridge in libvirt [14:43] and i was expecting to be able to [14:43] start on net-device-up INTERFACE=maasbr0 [14:44] but i do not have evidence that that ran [14:45] slangasek, ^ ? [14:45] xnox: while you might be right, let's not assume failure in advance :) [14:45] tjaalton: hi, bug #966744 is assigned to you and targeted to beta-2; despite being an old bug number, this has started becoming a huge problem for me just in the past couple of days. Is this in progress? [14:45] Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744 [14:46] and besides, "forever" is at most until the next LTS [14:46] *after the ... [14:46] cjwatson: ok. =) [14:47] cjwatson: as far as I understood that patch, it was changing the check to ignore rc state packages. So if there is an rc package that is not upgraded for more than one LTS, then you can still hit it. [14:47] smoser: there are net-device-up events for those devices on whose behalf /etc/network/if-up.d/upstart is called, which should be all of them managed either in /etc/network/interfaces or by NM === ogasawara_ is now known as ogasawara [14:47] mvo: or does that actually update status db? [14:47] slangasek: yes, I'm testing crack-o-day intel drm code (requested by upstream), also trying to figure out why it fails to boot [14:47] slangasek, ah. yeah. i koind of realized that. [14:48] do you have a suggestion on how i can start on that network device ? [14:48] (which is not managed by /etc/network/interfaces) [14:48] slangasek: not going to get fixed for beta2, that's for sure :/ [14:48] tjaalton: ok, thanks for the info [14:48] smoser: fix libvirt to emit the event for you? :) [14:49] smoser: or maybe it should be 'start on started libvirt-bin' or something? [14:49] i tried that, but it seemed racy. [14:49] well, sounds like a bug in libvirt-bin startup [14:49] because it shouldn't be racy [14:49] slangasek: btw, have you reviewed the acpi-support patch(es)?-) [14:49] xnox: no, just "fixes" the counting [14:50] tjaalton: got about halfway into it before vacation hit... will revisit this week [14:50] slangasek: ok, thanks [14:50] slangasek, possibly. but the daemon is sstarted, just not all networks up i think. [14:51] xnox: this is why it would be nice to "upstream" it [14:52] mvo: well the correct way is to actually rewrite the status db on lts upgrade and correct those. as the new dpkg will not generate inconsistent status db (well if it does it will be upstream bug as well). [14:52] mvo: that way it would really be just a patch to carry until lts. [14:52] mvo: I think we should apply your patch for quantal, and fix it with status db re-writing by 14.04. And then drop it after 14.04. [14:53] xnox: sounds good to me [14:55] slangasek, so you would think that 'started libvirt-bin' would mean that all of its 'auto' networks are up ? [14:57] smoser: I would think that it would mean all the setup for libvirt is done, so that other services can start using those facilities, yes [14:58] smoser: libvirt-bin even uses 'expect daemon', so there's no excuse not to - it's just a startup ordering question AFAICS [14:58] do you think the comment about 'net-device-up' is valid ? [14:58] ie, would it be reasonable for libvirt to emit those ? [15:43] Laney: Did you intend Bug #1054746 to be about excluding online results or excluding commercial results (title says one and the body says the other). I'd like to make sure we're solving the right bug. [15:43] Launchpad bug 1054746 in Google Documents Lens "[FFe] [UIFe] No easy way to disable online results in lenses" [High,In progress] https://launchpad.net/bugs/1054746 [15:44] ScottK, the bug is about stopping sending queries to Canonical servers [15:44] ScottK: I originally intended it to be a narrow fix for just that lens (and wrote a patch for that) [15:44] but then it got extended to cover all queries sent to C servers [15:45] seb128: That's what I thought, but the U/I that's proposed talks about commercial/non-commercial. [15:45] which I think is nicer. [15:46] Since there's been discussion of non-commercial online search support, I think that is not completely aligned with not doing online searches. [15:46] it's not about online services [15:46] you'll still have (for example) wikipedia and gwibber working [15:47] Is that different than what seb128 just said? [15:47] (or do those not go through Canonical servers?) [15:47] ScottK: you have the gwibber lens fetching content from tweeter [15:47] It's not, but your response came after his. [15:48] ScottK: or the excellent radio lens grabbing the available radio info from an online service ;) [15:48] Right, but those are clearly online. [15:48] indeed [15:49] This issue, AIUI was automatically going online for searches when there was no indication that was the case. [15:49] So the bug isn't about disabling all online results. Commercial suggestions from partners was the wording that design came up with to describe what we're turning off. [15:49] which is intended to be the items causing concern [15:50] I understand it's supposed to be finessed more for the next cycle [15:50] OK. You might want to retitle the bug then. [15:50] Because that's what got me started being confused. [15:51] there. how's that? [15:51] * ScottK notes for the record how much more convenient conversations like this are when they happen before feature freeze. [15:51] * ScottK looks. [15:51] Sure. Thanks. [15:51] yes, we know. We're trying to work within the constraints of our governance structure ... [15:52] Well, something seems to come up every cycle. [15:54] If someone bases their plans on "we'll get an exception", I don't think that's really working within the structure. I understand that stuff happens, but when it's consistent, that's not what FFes are for. [15:55] Strictly from a technical perspective, I think it'd be better to revert the whole thing and land it with a good design early in "R", but I get that's not going to happen. [15:58]