| infinity | Officially EODs, will unofficially be around to fiddle with images and check on the queue. :P | 00:11 |
|---|---|---|
| skaet | slangasek, ugh on the eglibc. | 01:34 |
| micahg | third time's the charm for respins? | 01:35 |
| * skaet crosses fingers. | 01:38 | |
| CareBear\ | are the isos hosted somewhere? | 01:42 |
| skaet | CareBear\ path to them is on the iso tracker | 01:44 |
| skaet | basically on cdimage.ubuntu.com | 01:45 |
| CareBear\ | there are a few :) | 01:46 |
| skaet | CareBear\, yup. | 01:49 |
| skaet | :) | 01:50 |
| * skaet --> zzz | 03:57 | |
| pitti | Good morning | 04:29 |
| infinity | pitti: Can you prove that? | 04:29 |
| pitti | hm; grey and rainy outside, and still a bit tired | 04:29 |
| pitti | BUT! | 04:29 |
| pitti | http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html | 04:30 |
| pitti | beer-y! | 04:30 |
| pitti | q. e. d. | 04:30 |
| infinity | And who doesn't like beer on their cornflakes? | 04:30 |
| * pitti should update the script to add a bowl of fruit before 1200 UTC | 04:30 | |
| pitti | or a Yoghurt shake | 04:30 |
| infinity | pitti: I'm tempted to do one last mass-give-back to see if anything in universe FTBFS magically shakes out. | 04:50 |
| infinity | pitti: Any objections? | 04:50 |
| pitti | I'm all for that | 04:50 |
| pitti | otherwise all those shiny buildds will just freeze to death, give them some work out :) | 04:51 |
| infinity | ;) | 04:51 |
| pitti | infinity: how many builds are we talking about? powerpc might not be able to catch up with all of them | 04:51 |
| pitti | ah well, it's all opportunistic anyway | 04:51 |
| infinity | PPC can catch up fine. :P | 04:52 |
| infinity | 91 builds on PPC, most of which will probably fail/dep-wait in the first few minutes. | 04:52 |
| * micahg will be doing Mozilla uploads over the weekend :) | 04:52 | |
| micahg | but I think it'll be fine as well | 04:53 |
| infinity | micahg: Those will all be main, so they'll beat the universe give-backs. | 04:53 |
| micahg | infinity: oh, yeah, and in a security PPA :) | 04:54 |
| infinity | (Well, maybe not chromium, but you have friends who can fix that) | 04:54 |
| infinity | Oh, in the PPA, even better. | 04:54 |
| infinity | I'm kinda wildly shocked that i386 and amd64 FTBFS is so low (well, sorry, "not-built", not the same as FTBFS from rebuild tests, which is higher) | 04:55 |
| micahg | infinity: +1 maintenance has helped :) | 04:56 |
| ScottK | That and we really aggressively pruned old crap in Lucid. It makes it easier now. | 05:02 |
| ScottK | Everything in the archive with binaries has built at least once in the last two years. | 05:02 |
| infinity | Speaking or pruning, removing libembperl-perl. | 05:02 |
| infinity | Considering removing gnat-4.4, but it has r-bdeps. | 05:03 |
| ScottK | You've got a few days to fix that. | 05:03 |
| * micahg is wondering about ldc which is unbuildable | 05:03 | |
| micahg | has rdeps | 05:03 |
| micahg | can someone go pruning again removing stuff removed from Debian? | 05:04 |
| infinity | I'm sure we can, not sure I'm doing it at 11pm. | 05:05 |
| infinity | But we still have a week to make sure universe is perfect and shiny. | 05:05 |
| infinity | Hey look, something shook out! | 05:05 |
| infinity | Shame it failed on i386. :P | 05:06 |
| infinity | But, progress... | 05:06 |
| infinity | You know, the archive would be in much better shape if we just dropped Haskell, Ada, and D. | 05:07 |
| infinity | cnd: Upon further reflection (and reviewing the diff a few times), I accepted your xorg-server into -proposed, meaning it's a likely "respin opportunity" candidate. Given that, can you make sure it gets some solid testing once binaries poop out the other end? | 05:09 |
| micahg | fixes rebuild dep-wait ^^ | 05:13 |
| infinity | pitti: I'm thinking update-notifier wants accepting, but I'll leave it to you as a desktoppy fellow who cares. ;) | 05:13 |
| infinity | pitti: (Also, because I'm thinking you can explain why it needs to import 5GB of po files) | 05:14 |
| pitti | infinity: because LP again took the diff against the pre-last version, not against 0.119ubuntu8 | 05:17 |
| * pitti checks the real diff | 05:18 | |
| infinity | pitti: Oh. That was only the 5-line change from Brian? | 05:18 |
| infinity | pitti: That would be much more readable. :P | 05:18 |
| infinity | pitti: (We need to fix that) | 05:18 |
| pitti | I'm double-checking | 05:18 |
| pitti | yes, just the "missing gettext" part | 05:18 |
| pitti | Context not found: "ubuntu/precice-proposed" | 05:19 |
| pitti | 2012-04-20 05:19:00 ERROR Error encountered -- aborting current transaction | 05:19 |
| pitti | err, what? | 05:19 |
| pitti | $ q -Q unapproved -s precice-proposed fetch update-notifier | 05:19 |
| infinity | ...? | 05:19 |
| * pitti looks harder | 05:19 | |
| infinity | No can spell. | 05:19 |
| infinity | preciCe? | 05:19 |
| pitti | *blush* | 05:19 |
| pitti | so, the gettext fix plus autoconf noise | 05:20 |
| pitti | I'm not entirely sure whether the latter is justified | 05:20 |
| pitti | it looks like Brian didn't have gnome-common installed | 05:20 |
| infinity | There needs to be a law against using different versions of autotools in stable releases (and in the weeks leading up to). | 05:21 |
| pitti | infinity: I think I'd prefer reuploading this with gnome-common installed, and fake-sponsor it for Brian | 05:21 |
| infinity | If the noise is actually a problem in this case, go ahead and re-upload. :) | 05:21 |
| * infinity nods. | 05:21 | |
| pitti | I can't tell for sure that it is a problem, but I'd rather avoid it | 05:21 |
| infinity | Yeah, that's fair. | 05:22 |
| infinity | When I do stable updates, I actually go out of my way to make sure autojunk gets replicated the same as the previous version. | 05:22 |
| infinity | Just out of paranoia. | 05:22 |
| infinity | Or OCD. | 05:22 |
| infinity | Probably more the latter. | 05:22 |
| infinity | (This is a surprising challenge when doing stable updates of apt, as mvo seems to randomly switch autoconf versions more than most people switch their underwear) | 05:23 |
| pitti | http://paste.ubuntu.com/937864/ - now how is that | 05:23 |
| infinity | pitti: ZOMG readable. | 05:24 |
| infinity | pitti: And Brian's patch is "obviously correct". | 05:24 |
| infinity | pitti: Does u-n have arch skew? | 05:25 |
| infinity | pitti: If not, while you're sponsoring, jam it into release. :P | 05:25 |
| pitti | hardly | 05:25 |
| infinity | pitti: We already know we're rebuilding for eglibc, at least. | 05:25 |
| pitti | I can reupload | 05:25 |
| infinity | Just edit the Distribution line in .changes and reupload. | 05:25 |
| pitti | done | 05:26 |
| pitti | so you now have two, pick the one you prefer :) | 05:26 |
| infinity | Hahaha. | 05:26 |
| infinity | Brian's going to be so confused. | 05:26 |
| pitti | infinity: eglibc? nice | 05:26 |
| pitti | I left a comment for him in the bug | 05:26 |
| pitti | infinity: kernel 3.3 would be nice, too! | 05:26 |
| infinity | pitti: We (and be "we", I mean vorlon, but I'm not naming any (real) names) may have messed up the daemon restart logic, and ended up killing kdm on upgrades. | 05:27 |
| infinity | pitti: kubuntu upgrade testers are unimpressed. | 05:27 |
| * pitti does bug 985940 and gets rid of another FTBFS | 05:28 | |
| ubot2 | Launchpad bug 985940 in libpgjava "FFE exception for Precise: libpgjava" [Undecided,Triaged] https://launchpad.net/bugs/985940 | 05:28 |
| * micahg just filed bug 986017 to rid another rebuild FTBFS | 05:30 | |
| ubot2 | Launchpad bug 986017 in ruby-sequel "FFe: Sync ruby-sequel 3.33.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986017 | 05:30 |
| micahg | wait, what, are my eyes deceiving me? I see a 3rd PPC build | 05:33 |
| micahg | *buildd | 05:33 |
| infinity | micahg: You do. | 05:33 |
| micahg | \o/ | 05:34 |
| micahg | infinity: do you want to give back the rebuild as well? | 05:35 |
| infinity | Not really. | 05:35 |
| infinity | Mostly cause I don't have a script to do that, and I don't speak lplib well enough to do it by hand. | 05:35 |
| infinity | Another thing I need to fix, now that the world's moving/moved to the LP API. | 05:36 |
| pitti | 3rd buildd> ooh! | 05:36 |
| micahg | infinity: ok, maybe when cjwatson arises | 05:36 |
| infinity | Also, for parallel builds, sulfur should be about twice as fast as the others. | 05:37 |
| infinity | So, aim your compilers and web browsers and office suites there. :P | 05:37 |
| micahg | orly? so libreoffice should be down to ~10hrs | 05:37 |
| micahg | firefox won't parellelize ATM, but nice to know there's a chance for improvement | 05:37 |
| micahg | although I have 4 builds at a time for it | 05:38 |
| infinity | The other buildds are dual 2GHz G5s with 3G of RAM, sulfur's a quad 2GHz POWER5 with 4G of RAM. | 05:38 |
| infinity | So, nearly identical for serial builds. | 05:38 |
| micahg | so, if I ever get firefox to parallelize again, that means we can probably build an update in ~12 hours | 05:39 |
| infinity | (We were going to make sulfur the livefs builder, but after testing it against royal, it came out almost identical, so I figured the two more cores made more sense for package builds) | 05:39 |
| micahg | indeed | 05:39 |
| micahg | we do have a lot of packages that can parallelize and more being added all the time | 05:40 |
| infinity | *nod* | 05:40 |
| infinity | I think you can kind of blame us for that. | 05:40 |
| infinity | We forced the issue a while ago when I just 5-bladesed parallel building into the buildd network and watched the world burn. :P | 05:40 |
| infinity | Patches made it back to Debian remarkably quickly back then, as I recall. | 05:41 |
| infinity | (The number of people who thought it was appropriate to -jN debian/rules without testing it in any meaningful way was remarkable) | 05:41 |
| * micahg likes dh --parellel | 05:42 | |
| * infinity raises his brow. | 06:24 | |
| infinity | ^-- What was that about? | 06:24 |
| pitti | infinity: sorry for the spam; doing kernel SRU training with RAOF | 06:26 |
| infinity | Ahh. | 06:26 |
| pitti | I just fixed copy-proposed-kernel.py to use the async method | 06:26 |
| pitti | we did the real SRU copyign with the old script still, which uses syncPackage() and thus doesn't hit +queue | 06:26 |
| infinity | async sync just sounds odd. :P | 06:26 |
| pitti | infinity: ok to accept u-notifier? | 06:34 |
| pitti | yay, the LP diff is correct this time | 06:34 |
| infinity | pitti: What update-notifier? | 06:35 |
| pitti | that very :) | 06:35 |
| infinity | mvo: Mornin'. | 06:49 |
| infinity | mvo: Thanks for the quick apt fix. You're my hero. | 06:50 |
| mvo | infinity: your welcome, thanks for your report about it, that was right in time | 06:51 |
| infinity | I probably should have found it earlier, but who reads build logs, right? :/ | 06:51 |
| infinity | Would have been embarrassing to trip over after release, if elmo decided to upgrade cocoplum. :P | 06:51 |
| * mvo nods | 06:52 | |
| mvo | oh yes :) | 06:52 |
| infinity | (At least, I'm assuming it would die in the same way on a "real" archive) | 06:52 |
| mvo | it would, I'm pretty sure | 06:52 |
| infinity | Unless file lists take it through a safer codepath. | 06:52 |
| infinity | mvo: Do you still touch upstream apt, or have you backed away completely? | 06:53 |
| infinity | mvo: Your (fairly critical) FD fix, and my (pretty much just cosmetic) FD fix should both get into Debian. | 06:53 |
| infinity | mvo: I think I may have even linked the Debian bug in the changelog for mine. If I was awake when I did it. | 06:54 |
| infinity | Ahh, yeah, I did. | 06:54 |
| mvo | infinity: yeah, I will merge it into debian too | 06:58 |
| infinity | mvo: *hug* | 06:58 |
| mvo | infinity: well, once bzr finishes upgrading my branch to whatever is the latest format that is not compatible with the one used in my other branch :/ | 07:05 |
| infinity | mvo: Hahaha. | 07:07 |
| infinity | Waiting on gnupg (28932) to finish generating a key. | 07:15 |
| * infinity taps his foot. | 07:15 | |
| micahg | pitti: can you please promote chromium in lucid to -updates and -security? | 07:44 |
| pitti | micahg: on it | 07:47 |
| pitti | micahg: ^ looks right? | 07:47 |
| micahg | pitti: yes | 07:47 |
| micahg | pitti: thanks | 07:48 |
| micahg | pitti: chromium in natty-proposed is ready as well | 08:25 |
| pitti | micahg: done | 08:46 |
| infinity | doko_: Good morning. :P | 08:47 |
| micahg | pitti: thanks | 08:47 |
| doko_ | infinity, did I wake you up? ;P | 08:47 |
| pitti | infinity: FYI, jibel tested the python upgrade, working fine | 08:47 |
| infinity | pitti: With the above upload? | 08:47 |
| pitti | I'll review/accept into -proposed as soon as it gets diffy | 08:47 |
| doko_ | infinity, yes | 08:47 |
| pitti | and then we can see for 0-day SRU or folding it into release, depending on whether we'll respin | 08:48 |
| infinity | doko_: So, what do you (with a community hat on, I guess?) want to do about the FTBFS compilers in universe? | 08:48 |
| doko_ | infinity, which ones? | 08:48 |
| pitti | doko_: thanks for the fix! | 08:48 |
| infinity | doko_: gnat-4.6 has been FTBFS on armel since (accidentally?) turned on sf/hf multilib. | 08:49 |
| infinity | doko_: gnat-4.4 is FTBFS on all arches. I'd happily remove it, but it has reverse build-deps. | 08:49 |
| doko_ | pitti: my gdb upload is still pending? | 08:49 |
| doko_ | infinity, if gnat-4.4 has reverse-deps, then these should be removed, or built with 4.6 | 08:50 |
| pitti | doko_: someone blocked it on https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus | 08:50 |
| micahg | infinity: I'll try to poke at gnat-4.4 rdeps over the weekend if you or doko don't beat me to it | 08:50 |
| doko_ | pitti: even for -proposed? | 08:50 |
| infinity | micahg: Consider the lock yours, I'm on airplanes. | 08:50 |
| infinity | doko_: So, micahg just took 4.4 off our hands. Fixing 4.6/armel would be nice, though, since it used to work. :/ | 08:51 |
| doko_ | pitti, ahh, I think it was slangasek. but the changes are bug fixes only | 08:51 |
| infinity | doko_: I gave a quick pass at disabling sf/hf multilibs, but I clearly didn't grok the packaging well enough on the first pass. | 08:51 |
| doko_ | micahg, it doesn't make sense to "fix" 4.4, better try to remove it | 08:51 |
| micahg | infinity: I can't promise due to the large number of other things I'm balancing on my plate | 08:51 |
| micahg | doko_: yes, I plan to get the rdeps upgraded to 4.6 versions from Debian :) | 08:51 |
| pitti | less risky in an SRU, of course, but as the bug neither has a test case (or something that's actually broken), nor a regression test plan, it won't be easy to get it to -updates | 08:52 |
| stgraber | hmm, can we re-enable the upgrade entries on the tracker? | 08:56 |
| stgraber | oh, I guess it'd make sense to wait for python though | 08:57 |
| === doko_ is now known as doko | ||
| infinity | doko: My initial stab at fixing gnat-4.6 was http://paste.ubuntu.com/937997/ but it appeared to have no effect, so I suspect I'm missing a bigger picture. ;) | 09:02 |
| doko | infinity, I'll have a look | 09:03 |
| doko | micahg, libgtkada can't be built with 4.6? | 09:04 |
| micahg | doko: I already filed the removal for libgtkada2 | 09:08 |
| infinity | doko: libgtkada2 was superseded by libgtkada, just to be confusing. | 09:09 |
| doko | ahh, ok | 09:09 |
| micahg | libgtkada is already built with gnat-4.6 FWIW | 09:10 |
| infinity | micahg: Whose baby is reverse-depends(1) (or the web service it uses)? | 09:10 |
| infinity | adconrad@cthulhu:~$ reverse-depends libgtkada2 | 09:10 |
| infinity | reverse-depends: Error: Unknown package | 09:10 |
| micahg | infinity: tumbleweed wrote it I think, it's hosted on ubuntuwire | 09:11 |
| infinity | As opposed to checkrdepends, which gets it right. | 09:11 |
| micahg | infinity: you need src: | 09:11 |
| micahg | yeah, requires more flags than checkrdepends | 09:11 |
| infinity | Oh. --help doesn't say that. :P | 09:11 |
| * micahg would love a current version of that :) | 09:11 | |
| micahg | infinity: polyorb removal: http://packages.qa.debian.org/p/polyorb/news/20120305T100750Z.html | 09:12 |
| infinity | micahg: Nuked. | 09:13 |
| * infinity removes narval from that same mailing list post. | 09:15 | |
| infinity | Oh, nevermind. Already gone. | 09:15 |
| micahg | yeah, we did that a while ago | 09:15 |
| tumbleweed | infinity: patches welcome :) | 09:15 |
| infinity | tumbleweed: This is just a documentation issue, apparently. | 09:16 |
| infinity | tumbleweed: Or, it's an I can't read issue. | 09:17 |
| tumbleweed | probably needs to say "binary package" so that it's more obvious what the problem is | 09:17 |
| infinity | tumbleweed: src is there in help, just cleverly hidden in the middle of my terminal. | 09:17 |
| tumbleweed | ah | 09:17 |
| infinity | But yeah, a more informative error wouldn't hurt. | 09:18 |
| tumbleweed | source packages probably should have been the default, it's all I use it for :/ | 09:18 |
| infinity | It could also use a slightly more machine-friendly output format. | 09:18 |
| tumbleweed | there's an option for that | 09:18 |
| infinity | Oh, -l | 09:19 |
| * infinity tries. | 09:19 | |
| infinity | That's more pleasant. | 09:19 |
| micahg | infinity: ok, filed 3 FFe, ghcl I think we can just remove with gnat-4.4, all that's left is apq* which I'm testing now | 09:19 |
| infinity | tumbleweed: Okay, then once we get over my inability to read, I think my only remaining complaint is that I need to run it twice. | 09:20 |
| infinity | tumbleweed: Since I can't seem to get it to give me both rdeps and rbdeps together. | 09:21 |
| infinity | But maybe that's by design. | 09:21 |
| micahg | yeah, I wish that would be fixed as well :0 | 09:22 |
| infinity | micahg: ghdl, you mean? | 09:23 |
| micahg | yes :) | 09:23 |
| infinity | That actually sounds remotely useful. | 09:23 |
| infinity | Shame it's unmaintained. :/ | 09:23 |
| micahg | indeed, but we can backport it if it ever gets fixed and people want it | 09:23 |
| infinity | micahg: Bugs for the FFes? I'm too lazy to go hunting. | 09:24 |
| micahg | give me a minute, filing 2 more | 09:24 |
| infinity | I accept verbal FFe requests. Especially for universe. | 09:25 |
| micahg | bug #986073, #986077, #986086, #986094, #986095 | 09:27 |
| ubot2 | Launchpad bug 986073 in opentoken "FFe: Sync opentoken 4.0b-3 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986073 | 09:27 |
| ubot2 | Launchpad bug 986077 in gnade "FFe: Sync gnade 1.6.2-9 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986077 | 09:27 |
| ubot2 | Launchpad bug 986086 in libaunit "FFe: Sync libaunit 1.03-7 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986086 | 09:27 |
| ubot2 | Launchpad bug 986094 in apq "FFe: Sync apq 3.2.0-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986094 | 09:27 |
| ubot2 | Launchpad bug 986095 in apq-postgresql "FFe: Sync apq-postgresql 3.2.0-2 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986095 | 09:27 |
| micahg | and we're almost done :) | 09:27 |
| tumbleweed | infinity: that sounds pretty solvable :) | 09:27 |
| infinity | micahg: The first three didn't need exceptions. | 09:29 |
| micahg | infinity: new binaries need an FFe :) | 09:29 |
| micahg | or so I've been told | 09:29 |
| infinity | micahg: Just debian revision bumps with bugfixes (build-deps) | 09:29 |
| infinity | Oh, meh. They squirt out new binaries? | 09:30 |
| infinity | Whatever. :P | 09:30 |
| micahg | yes, hence the paperwork :) | 09:30 |
| * infinity syncs. | 09:30 | |
| * micahg could sync them :) | 09:30 | |
| infinity | True. | 09:30 |
| infinity | Do 'em all. | 09:30 |
| micahg | I'll assume you've commented appropriately | 09:31 |
| micahg | do you want any of them in -proposed? | 09:31 |
| infinity | micahg: release is fine. But if that last one doesn't have properly versioned build-deps, make sure to stagger the uploads. | 09:31 |
| micahg | ok | 09:32 |
| micahg | deps are properly versioned | 09:32 |
| infinity | Then sync away and close your bugs. ;) | 09:33 |
| micahg | done and done | 09:34 |
| infinity | Oh dear, this is unpleasant: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/985852 | 09:35 |
| ubot2 | Launchpad bug 985852 in apt "libapt-pkg regression: infinite loop on processing certain Pre-Depends" [High,In progress] | 09:35 |
| micahg | infinity: once those publish, here's the removal: Bug #986096 | 09:35 |
| ubot2 | Launchpad bug 986096 in gnat-4.4 "Please remove gnat-4.4 and its reverse dependencies from precise" [Wishlist,Confirmed] https://launchpad.net/bugs/986096 | 09:35 |
| micahg | that was a very productive half hour :) | 09:35 |
| micahg | although sleep was on the schedule :) | 09:36 |
| infinity | mvo: Do you know if that infinite loop affects us (ie: do we have an ORed Pre-deps), or is it SRUable? | 09:36 |
| infinity | micahg: Sleep's overrated. | 09:36 |
| infinity | I have a court date tomorrow, I'm trying to get as much work in as I can. :P | 09:36 |
| infinity | So I can show up wild-eyed. | 09:36 |
| infinity | It'll be great. | 09:36 |
| micahg | infinity: oops, forgot one, hold off on removal :) | 09:37 |
| infinity | micahg: I'm not removing until the rdep list is clear anyway. :P | 09:37 |
| infinity | micahg: I *do* check these things. | 09:37 |
| infinity | *blink* | 09:40 |
| infinity | You don't have enough RAM to build PyPy. | 09:40 |
| infinity | It's known to require >= 1400 MiB on 32 bit archs. | 09:40 |
| infinity | Why does it need *physical* RAM? Or is the Debian maintainer just a doofus? | 09:40 |
| Laney | Ask him. The doofus is in here. | 09:41 |
| infinity | tumbleweed: Hey, doofus. | 09:41 |
| infinity | tumbleweed: See above. ;) | 09:41 |
| tumbleweed | infinity: it'll take a week to build | 09:41 |
| tumbleweed | probably more | 09:41 |
| tumbleweed | the GC walks across all the memory quite often | 09:42 |
| micahg | infinity: bug #986105 | 09:42 |
| ubot2 | Launchpad bug 986105 in topal "FFe: Sync topal 75-1 (universe) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/986105 | 09:42 |
| mvo | infinity: I think its SRUable and also needs a release-upgrader-apt upload for the lucid->precise upgrade | 09:42 |
| mvo | infinity: I prepeared that but want to give it a testrun in jenkins first | 09:42 |
| infinity | mvo: If you think it's worth a release-upgrade-apt build, then I think it should be in release, not an SRU. :P | 09:43 |
| mvo | while the regression risk is tiny, I'm worried about $anything at this point :/ | 09:43 |
| infinity | tumbleweed: But I assume it's no that evil at runtime, right? | 09:43 |
| mvo | infinity: but let me do a quick analysis | 09:43 |
| tumbleweed | no | 09:43 |
| tumbleweed | infinity: teh build process is "import everything into memory, perform type analysis, optimise, write C". Uses an insane amount of RAM | 09:44 |
| infinity | tumbleweed: A week-long build doesn't really hurt my feelings (though, obviously a bit late for precise) unless you upload the package every 2 days.. | 09:44 |
| mvo | infinity: in the archive it seems to be pretty much only debconf, default-jre and udev | makedev | 09:45 |
| infinity | mvo: That's a longer list than 0. | 09:45 |
| infinity | mvo: That settles it for me, we want it fixed, IMO. | 09:45 |
| infinity | (And not in an SRU) | 09:45 |
| * infinity gets to reviewing. | 09:46 | |
| mvo | infinity: ok, I think I agree, probably I'm in too much of a OMG-stable mode currently | 09:47 |
| infinity | mvo: No, that's the right mode to be in. | 09:47 |
| infinity | mvo: But I don't want to take a chance on this asploding upgrades. | 09:47 |
| infinity | mvo: The MaxLoopCount guard probably could have been avoided for a targetted fix, though... | 09:48 |
| infinity | mvo: (Since I assume you also fixed the loop?) | 09:48 |
| micahg | can someone approve the last gnat-4.4 rdep FFe from me above? | 09:48 |
| infinity | micahg: Oh, looking. | 09:49 |
| infinity | micahg: Seems slightly more featureful than the other syncs, but it's for the greater good. :P | 09:49 |
| tumbleweed | infinity: I was being nice to the debian buildds. LP has less tiny-memory architectures | 09:50 |
| micahg | infinity: indeed, thanks | 09:50 |
| infinity | tumbleweed: Yeah. I should spin it up on a Panda and see how it fares. If it's alright, you can guard your guard in an lsb_release check for Ubuntu. | 09:50 |
| tumbleweed | infinity: sure | 09:51 |
| micahg | infinity: ok, going to sleep now, I'll check when I get up to make sure all the stuff that was supposed to build did, thanks for your help | 09:54 |
| infinity | micahg: Thanks for looking. ;) | 09:55 |
| mvo | infinity: right, I can do a upload to final without the MaxLoopCount, I would like to SRU it though later as its IMO useful, the unknown is how high this count needs to be | 09:55 |
| infinity | mvo: Oh, I agree that the option's useful. And the implementation even seems reasonable reviewable. I just want tiny for fixes. ;) | 09:56 |
| * micahg still can't believe we're shipping 4 versions of vala in the archive... | 09:56 | |
| infinity | micahg: How many in main? | 09:57 |
| micahg | 2 last I checked | 09:57 |
| infinity | :/ | 09:57 |
| infinity | I remember the good old days, pitti and I used to be draconian about duplication in main. | 09:57 |
| Riddell | arguably vala is a duplication in itself </controvertial> | 09:59 |
| infinity | mvo: Oh ick, and I've seen that modifier bug before. I didn't spend enough time looking at it to realise what was happening. | 09:59 |
| tumbleweed | infinity: btw, building pypy on a low-memory machine is almost certainly going to timeout sbuild. It's already timing out on a bunch of decent buildds in Debian (if sbuild was line-buffered, I think it'd be OK, but it isn't) | 09:59 |
| micahg | tumbleweed: you could always grab the change that fta added to chromium that outputs something every 5 minutes | 10:01 |
| tumbleweed | urgh :) | 10:01 |
| infinity | GCC has a similar hack. | 10:01 |
| infinity | Also, I take it back, I'm not spinning this up on my Panda, since my Panda needs to be in my suitcase in ~1.5 days. | 10:02 |
| infinity | Silly me. | 10:02 |
| infinity | tumbleweed: Remind me that I cared about this, and we'll look at it for Q? | 10:02 |
| tumbleweed | :) | 10:03 |
| infinity | tumbleweed: I'll test on a QuickStart too (which is what the Debian/armhf builders are), and if it's good on both, you can just turn it on there too. | 10:04 |
| infinity | But yeah, it might need a logping hack or something if it's going to take days to do its thing. | 10:04 |
| infinity | I believe it was GCC on m68k that drove doko to write that awful hack in the first place. :P | 10:05 |
| tumbleweed | micahg: actually, I don't think that's even an option, as it does legitimately timeout too. | 10:05 |
| pitti | infinity: https://launchpad.net/~ubuntu-cruft-busters! | 10:05 |
| * micahg applies | 10:06 | |
| infinity | Ditto. | 10:06 |
| infinity | Even if it is owned by NCommander. ;? | 10:06 |
| infinity | ;) | 10:06 |
| infinity | TYPING HARD. | 10:06 |
| micahg | infinity: if we need an approbation, we can use the yada removal :) | 10:07 |
| infinity | tumbleweed: Wait... | 10:08 |
| infinity | tumbleweed: Is the ascii art how it keeps the build alive? ;) | 10:08 |
| tumbleweed | yes. But the ascii art is based on events, not time | 10:09 |
| infinity | Oh, and those events can really be hours apart? | 10:09 |
| infinity | Shame. | 10:09 |
| tumbleweed | 4k worth of dots can be hours apart | 10:09 |
| infinity | Ahh. | 10:09 |
| infinity | That's a solvable problem. | 10:09 |
| tumbleweed | in my measuring, each line is always a lot less than that on a capable buildd | 10:10 |
| infinity | Watching this is kinda soothing. | 10:10 |
| tumbleweed | it's colour if you do it by hand :P | 10:10 |
| infinity | Oooo. | 10:10 |
| infinity | mvo: Okay, I've read this a few times, in both directions, uphill both ways, in the snow. | 10:13 |
| infinity | mvo: I'm inclined to accept it as-is. The two bugs are both worth fixing, and the MaxLoopCount looks safe and sane. | 10:13 |
| infinity | mvo: When do we get a matching release-upgrader-apt? | 10:15 |
| mvo | infinity: the release-upgrader-apt is uploaded to a PPA once the testing there is done I move that to lucid-proposed | 10:18 |
| infinity | mvo: Mmkay. | 10:18 |
| pitti | ^ your mass give back? | 11:21 |
| cjwatson | oh, yes, I was going to look at a mass give-back for the test rebuild | 11:22 |
| * cjwatson fires up lp-shell | 11:23 | |
| pitti | cjwatson: infinity did that this morning apparently | 11:23 |
| cjwatson | he did that for the main archive, not the test rebuild | 11:23 |
| cjwatson | there's stuff in scrollback abou tit | 11:23 |
| doko | pitti, cjwatson, infinity: I'd like to fix bug 981037 for precise. 0-day sru? | 11:24 |
| ubot2 | Launchpad bug 981037 in openjdk-6 "The javac executable doesn't produce full paths for files on error" [Undecided,New] https://launchpad.net/bugs/981037 | 11:24 |
| pitti | doko: yeah, normal SRU seems fine; this isn't release critical for final certainly? | 11:25 |
| doko | pitti, I'd like to build it in -proposed, so that jibel can test it. no, not for final | 11:26 |
| pitti | sure | 11:26 |
| jdstrand | cjwatson: fyi, the test-openssl.py qrt failures were because I needed to specify -tls1 to s_client. I think what is happening is s_server is defaulting to -tls1 and s_client is not | 11:30 |
| jdstrand | cjwatson: I'm going to not worry about it at this point | 11:30 |
| cjwatson | ah, that makes sense, I hadn't got round to looking at that yet | 11:31 |
| cjwatson | come on, Launchpad, I'm only asking you to load 1472 objects | 11:32 |
| cjwatson | ah, there we go | 11:32 |
| cjwatson | I guess I want to give back only source packages without newer versions in the main archive | 11:33 |
| cjwatson | >>> len(builds_not_superseded) | 11:48 |
| cjwatson | 496 | 11:48 |
| cjwatson | that looks about right | 11:48 |
| cjwatson | >>> for b in builds_not_superseded: | 11:48 |
| cjwatson | ... b.retry() | 11:48 |
| cjwatson | builders are filling up now | 11:49 |
| pitti | time for our new shiny builders to earn their money! | 11:49 |
| pitti | or electrons | 11:49 |
| * cjwatson ♥ launchpadlib | 11:50 | |
| pitti | i386 8 26 jobs (43 minutes) | 11:50 |
| pitti | buildds with go-faster stripes! | 11:50 |
| === greyback is now known as greyback|lunch | ||
| === greyback|lunch is now known as greyback | ||
| cjwatson | gah, just spotted a security flaw in apt-setup for extras.ubuntu.com handling | 13:10 |
| cjwatson | we need a new ubiquity to sync up with console-setup anyway, so can I upload this? it's just adding predownloaded Release/Release.gpg files so that the initial update is forced secure | 13:10 |
| stgraber | sounds good | 13:13 |
| infinity | cjwatson: While you're in there, add a nice comment block for security? ;) | 13:17 |
| cjwatson | too late, sorry | 13:17 |
| cjwatson | file a bug :) | 13:17 |
| infinity | Oh, indeed. | 13:17 |
| infinity | Curses, queuebot. | 13:17 |
| infinity | I don't care deeply enough to file a bug. | 13:18 |
| infinity | I always wipe my sources.list anyway. :P | 13:18 |
| doko | pitti, openjdk-6 uploaded | 13:18 |
| infinity | Just felt odd that it's the only one without comments. | 13:18 |
| stgraber | apt-setup looks good | 13:23 |
| stgraber | actually, why don't we have the .gpg too? | 13:23 |
| cjwatson | we do | 13:23 |
| cjwatson | it might not show up in the diff since it's a binary file | 13:24 |
| stgraber | oh right, diff and binary, sorry | 13:24 |
| * stgraber needs to add some visual way of spotting binary files in mc's diff viewer... | 13:24 | |
| pitti | stgraber: babeltrace has no bug refs, no open bug, and looks very intrusive; was that discussed before? | 13:45 |
| cjwatson | It would sure have been nice if GLU ES had been packaged by somebody | 13:45 |
| stgraber | pitti: we're trying to get on the full lttng 2.x stack that includes babeltrace 1.0, we were previously on a development snapshot, I now pushed the RC and we're expecting the final in the next few days | 13:46 |
| stgraber | pitti: lttng is fully self contained at this point, nothing depends on it and it's not seeded | 13:47 |
| pitti | stgraber: ok, I assume you tested with the new lttng-* packages and on precise? | 13:47 |
| stgraber | pitti: yes, upstream develops on Ubuntu and have daily builds. I built them locally on my machine and am running with them | 13:48 |
| pitti | ok, thanks | 13:48 |
| pitti | Daviey: can you please review the maas upload in -proposed? I don't feel qualified to judge the patch/impact | 13:55 |
| infinity | ^--- cjwatson is reviewing that upload for me already. | 14:01 |
| cnd | infinity, I'll ask for testers on the ubuntu-x mailing list | 14:01 |
| cnd | thanks! | 14:01 |
| cjwatson | yep, livecd-rootfs is fine | 14:02 |
| cjwatson | lots of arm preinstalled fixes | 14:02 |
| doko | third powerpc buildd \0/ ... time to start a test rebuild on powerpc ;) | 14:02 |
| infinity | doko: I'd love to after Debian imports settle down a bit, actually. | 14:03 |
| infinity | doko: I'd really like to know how healthy the port really is (I suspect it's not as bad as people think, and most of it could be fixed easily) | 14:04 |
| doko | openjdk-6 build did fail on amd64, one of the new machines ... | 14:05 |
| infinity | doko: Very thread-sad... Too many cores confusing poor java? :P | 14:06 |
| infinity | "Caused by: java.lang.IllegalMonitorStateException: current thread not owner | 14:06 |
| infinity | Etc. | 14:06 |
| cjwatson | infinity: even the normal FTBFS list is a good indication that it isn't particularly sad | 14:06 |
| stgraber | infinity: who needs smp anyway? | 14:06 |
| infinity | stgraber: Sun was pretty keen on SMP before they sold their souls to Ellison. | 14:07 |
| pgraner | infinity, https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/986203 looks like fixing lp 985737 caused a new bug: lp 986203 | 14:07 |
| ubot2 | Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,New] | 14:07 |
| ubot2 | Launchpad bug 985737 in livecd-rootfs "Tasks selected in oem-config are downloaded, but not installed, or configured ..." [High,Fix released] https://launchpad.net/bugs/985737 | 14:07 |
| ubot2 | Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,New] https://launchpad.net/bugs/986203 | 14:07 |
| infinity | pgraner: That would be a neat trick, since I only *just* fixed the bug. | 14:08 |
| pgraner | infinity, well something happened in the .2 build, I got prompted for tasksel and ticked off lamp & postfix, and it installed them | 14:09 |
| pgraner | infinity, while prompting me for the same questions 3 times | 14:09 |
| infinity | pgraner: Let's just call that build a complete wash, and you can revisit your new bug a bit later. ;) | 14:09 |
| infinity | pgraner: (The new livecd-rootfs is still building, so... It'll be hours before any images squirt out the other end) | 14:10 |
| infinity | pgraner: I'm actually mildly amused that no one filed (which means no one noticed) the most glaring bug most ARM images had for two days, which was that the armhf images were actually armel. :P | 14:13 |
| infinity | pgraner: (Fixed now, but argh) | 14:13 |
| pgraner | infinity, there are no test cases for that specifically | 14:13 |
| infinity | No, but you'd think manual testing would lead someone to notice it visually at some point. | 14:14 |
| infinity | apt-get update output, etc. | 14:14 |
| pgraner | infinity, have you seen the manual testing steps? | 14:14 |
| infinity | No. I'm guessing they're a bit light on fuzz testing? | 14:14 |
| pgraner | infinity, I've added it to the automated testing TODO list and I'm updating the manual tests now | 14:14 |
| infinity | But yeah, checking the architecture seems like a good thing for automation. | 14:15 |
| infinity | i386/amd64 could well suffer the same oops. | 14:15 |
| pgraner | infinity, for your amusement here is the test case for server http://testcases.qa.ubuntu.com/Install/ARM/Headless | 14:15 |
| infinity | Anywhere where the target hardware can support more than one arch, people wouldn't even notice... Until they did. ;) | 14:15 |
| pgraner | infinity, yep, on the list | 14:16 |
| stgraber | I guess we could do with a generic "Make sure your media matches its description (flavour, architecture)" entry in the testcase wiki pages :) | 14:16 |
| pgraner | stgraber, fixing now | 14:16 |
| infinity | pgraner: That's. Uhm. Err. I. Dude. | 14:16 |
| * cjwatson waits the requisite forever for ugene to test-build on ARM | 14:17 | |
| infinity | cjwatson: Didn't you hear? We're getting fast hardware ANY DAY NOW. | 14:18 |
| infinity | cjwatson: Obviously, yours just got delayed in the post. | 14:19 |
| cjwatson | s/mine/Canonical's/, given that this is scheat :-P | 14:19 |
| skaet | cjwatson, pitti, infinity - why did eglibc move from opportunity target to a Rebuild trigger? Thought slangasek yesterday decided it was opportuntity target. | 14:19 |
| cjwatson | Nowt to do with me. | 14:20 |
| cjwatson | But I found a security flaw in the installer anyway, so ... | 14:20 |
| skaet | infinity, not seeing livecd-rootfs on the pad.ubuntu.com/ubuntu-release as a rebuild trigger, and based on your comments in the backscroll? | 14:22 |
| cjwatson | And I think we still need this new apt. | 14:22 |
| infinity | skaet: We have other things going on, I figured it would just happen when it happened. ;) | 14:23 |
| infinity | (Like the new apt) | 14:23 |
| infinity | cjwatson: I reviewed it about 7 times before I accepted it, it seems good and pure and true. | 14:23 |
| skaet | infinity, makes it hard to pick up at start of new shift, if its not accurate. :P | 14:23 |
| infinity | cjwatson: mvo's testing the release-update-apt copy in his PPA, and should have tests some day. | 14:24 |
| cjwatson | That's the pre-dep regression, right? | 14:24 |
| infinity | Yeah. | 14:24 |
| infinity | And a modifier bug. | 14:24 |
| infinity | But the pre-dep thing is the killer. | 14:24 |
| cjwatson | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669591 - ha, right, nasty-ish in itself, but I agree | 14:24 |
| ubot2 | Debian bug 669591 in apt "apt: 'apt-get remove g++' is intrepreted as an install command (iprobably any package with a + at the end)" [Serious,Fixed] | 14:24 |
| infinity | skaet: eglibc would be a trigger for kubuntu-alternate, which means it needs to be in the release pocket, which means it now triggers the world, cause it's on every image. | 14:25 |
| cjwatson | added apt to the pad | 14:26 |
| skaet | infinity, yes, understand but rebuild triggers are forcing functions (like apt), opportunity targets are things we want to pick up if we can (kubuntu alternate could be release noted if we don't do a respin.) | 14:27 |
| skaet | thanks cjwatson. | 14:27 |
| infinity | Reading release notes are scant comfort for a completely broken upgrade. Anyway, other things were pulled in anyway, hence the opportunity was taken. | 14:27 |
| cjwatson | in this case it's moot. eglibc is already built everywhere. | 14:27 |
| cjwatson | and published. | 14:27 |
| infinity | (I'm not the one that marked it as a trigger) | 14:28 |
| infinity | Though I did copy it. | 14:28 |
| stgraber | skaet: IIRC the reason to consider it as a rebuild trigger for kubuntu alternate was that without it you couldn't upgrade to 12.04 using the alternate media. No amount of release noting would have worked around that, besides asking people to wait till the point release. | 14:28 |
| infinity | stgraber: Well, release notes can work around it by telling people to use a network. But that assumes they read the release note before they hose their system with a mid-upgrade explosion. :) | 14:29 |
| cjwatson | "Ubuntu Netboot: [3]" is that a request for me to rebuild debian-installer against the new eglibc? | 14:30 |
| stgraber | infinity: right and that someone who would have upgraded using the alternate CD (a pretty rare case) has internet connectivity ;) the only case where I use an alternate media as an upgrade source is precisely when I don't have connectivity... | 14:30 |
| infinity | cjwatson: Ask the man in baby blue... | 14:31 |
| skaet | stgraber, infinity, thanks. Since we'll be respinning for the apt and ubiquity, it will be picked up. | 14:31 |
| skaet | cjwatson, slangasek put in that indicator. | 14:31 |
| skaet | I just updated the numbering so we could keep score, best to get his input | 14:32 |
| Laney | ^ fixes ppc ftbfs, bugfix | 14:32 |
| cjwatson | it could well be that the formatting of the pad encourages just walking all the way down it blindly inserting [3]. | 14:32 |
| cjwatson | slangasek: do you really want a new debian-installer build for eglibc? I wouldn't have thought a maintainer script fix made any difference, although I suppose you might want to pull in final binary objects | 14:34 |
| * skaet nods | 14:34 | |
| infinity | cjwatson: Having the binaries match the archive is nice, ish. Though, they don't match in the d-i case anyway. | 14:34 |
| infinity | Cause mklibs does bad, bad, bad things to them. | 14:35 |
| stgraber | hmm, looking at the pad, souldn't python2.7 be considered as a rebuild trigger for the same reason as eglibc then? | 14:36 |
| stgraber | people upgrading using an alternate media will have the python upgrade failure unless the fixed python2.7 is on the media | 14:36 |
| infinity | stgraber: Opportunity knocks. | 14:38 |
| infinity | stgraber: Copy it before one of the other triggers is copied, and the debate's not worth having. | 14:38 |
| * infinity points at livecd-rootfs. | 14:38 | |
| infinity | Oh, but it's still building on arm*. :) | 14:39 |
| stgraber | yeah, ETA is less than an hour based on previous building time | 14:40 |
| infinity | Oh, I should probably note xorg somewhere. | 14:40 |
| infinity | Are we still wikiing for promotion? Or padding? I lose track. ;) | 14:41 |
| cjwatson | sorry, my network is a bit flaky this afternoon | 14:44 |
| cjwatson | 15:38 * cjwatson points at ubiquity. Please review | 14:44 |
| stgraber | cjwatson: looking | 14:44 |
| === barry` is now known as barry_ | ||
| * infinity heads out for an off day. | 14:45 | |
| stgraber | cjwatson: +1 | 14:45 |
| === barry_ is now known as barry | ||
| skaet | infinity, why can't xorg-server be handled as SRU? | 14:47 |
| cjwatson | stgraber: ok, accepted, thanks | 14:48 |
| * cjwatson copies apt | 14:49 | |
| skaet | stgraber, infinity, need MUCH more background before the xorg-server one is pulled in - not sure why it can't be considered SRU. | 14:52 |
| skaet | (a bug number would be nice too) | 14:52 |
| cjwatson | there is a bug number. | 14:53 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/pending-sru.html | 14:53 |
| infinity | skaet: It makes touchscreens pretty much unusable without also having a mouse handy to upgrade to the SRU. | 14:53 |
| cjwatson | copied to the pad now. | 14:53 |
| cjwatson | (but having to copy all this stuff around manually is really error-prone) | 14:53 |
| infinity | skaet: Not HUGELY critical, because we probably don't have many touchscreen-only users, but nice to fix. | 14:54 |
| skaet | infinity - can it cause regressions on the other parts? | 14:54 |
| highvoltage | stgraber: I just realised that the edubuntu wallpapers (the additional ones) doesn't show up in the gnome wallpaper list. is that something fixable (even if it's by SRU?)? | 14:54 |
| skaet | or localized scope only. | 14:54 |
| slangasek | doko, pitti: that gdb block is from skaet, not me | 14:54 |
| pitti | skaet: gdb> we'll do it as an SRU, no need to squeeze into release | 14:55 |
| * skaet nods | 14:55 | |
| chrisccoulson | hi. is there any chance of getting bug 985862 on the CD? | 14:55 |
| ubot2 | Launchpad bug 985862 in ubufox "Update the start page URL" [High,Triaged] https://launchpad.net/bugs/985862 | 14:55 |
| pitti | chrisccoulson: so AFAIK we'll need a respin for ubiquity and some others | 14:55 |
| stgraber | highvoltage: should be fixable as SRU yes, can be uploaded to -proposed already and used as opportunity target if we need to rebuild edubuntu for some other reason | 14:55 |
| pitti | chrisccoulson: so if you have an upload ready, please uplaod it RSN | 14:55 |
| infinity | skaet: Looked pretty localized to me, but like I noted, wait for cnd to give testing feedback. | 14:55 |
| chrisccoulson | pitti - ok, will do. do you want me to use proposed? | 14:55 |
| stgraber | highvoltage: do you now exactly what's wrong and needs fixing? if it's trivial, I'm happy to fix that quickly now as we're planning a rebuild anyway | 14:56 |
| pitti | chrisccoulson: it can never hurt, yes | 14:56 |
| * infinity really goes now. | 14:56 | |
| highvoltage | stgraber: I don't have the exact details, but I guess I'd look at the package that installs the community wallpapers and do the same | 14:57 |
| cjwatson | Laney: haskell-hashtables> nice, thanks, accepting | 14:57 |
| pitti | chrisccoulson: did something at the google side change recently which made this necessary? | 14:57 |
| cjwatson | would be nice to let the agda stack clear | 14:57 |
| highvoltage | stgraber: sorry I don't have a more useful answer at this point... maybe I can have an answer for you in a minute or two | 14:57 |
| Laney | yep. credit has to go to Joachim for investigating the fix though | 14:58 |
| stgraber | highvoltage: ok, I'm having a look now while waiting for test installs to finish running | 14:58 |
| stgraber | highvoltage: can you file a high priority bug against edubuntu-artwork for it please? | 14:58 |
| highvoltage | stgraber: ok thanks a lot | 14:58 |
| highvoltage | stgraber: yep | 14:58 |
| stgraber | highvoltage: right, I have a fix for it, testing it now | 15:00 |
| * skaet heading to weekly meeting in #ubuntu-meeting | 15:00 | |
| cjwatson | anyone know what's with libpg-java in NBS? | 15:00 |
| highvoltage | stgraber: LP: #986231 | 15:01 |
| pitti | * Change binary package name to libpostgresql-jdbc-java. | 15:02 |
| pitti | (closes: #336245) | 15:02 |
| pitti | cjwatson: ^ | 15:02 |
| cjwatson | ah; is somebody sorting out the rdeps? | 15:02 |
| pitti | cjwatson: I'll add a transitional package back | 15:02 |
| cjwatson | ok | 15:02 |
| pitti | not sure who requested that, perhaps the sync request says; looking | 15:02 |
| Laney | https://lists.ubuntu.com/archives/precise-changes/2012-April/015366.html | 15:03 |
| cjwatson | oh, yeah, I think he sent me mail about that | 15:03 |
| cjwatson | expect he cared about the new upstream ... | 15:03 |
| Daviey | pitti: I've just arrived home.. will catch up on this shortly. | 15:04 |
| pitti | Daviey: ah, you were on a conference? welcome back | 15:04 |
| Daviey | pitti: glad to be back.. :) | 15:05 |
| slangasek | skaet: I put it as 'rebuild trigger' initially, then thought out loud some more, and never changed it on the pad... stgraber makes the point that not taking it will break one of the supported upgrade paths, i.e. using the kubuntu alternate CD as an apt repository. But this is all moot now since I see eglibc 0ubuntu10 is in. :) | 15:07 |
| slangasek | cjwatson: debian-installer build> eh, no - if I put that it's because I wasn't reading closely | 15:08 |
| skaet | thanks slangasek for the clarification. | 15:08 |
| cjwatson | slangasek: trigger dropped then, thanks | 15:08 |
| kenvandine | the gwibber-service-sina and gwibber-service-sohu uploads are important for the china-images | 15:16 |
| stgraber | fix for bug 986231 uploaded. As marked on the pad, would be great if this could be in the next Edubuntu build. It's not critical as someone can certainly wait a few days to get their wallpapers but the bug was caused by an invalid .xml file, so that should be easy to review and is a quick build | 15:24 |
| ubot2 | Launchpad bug 986231 in edubuntu-artwork "Edubuntu wallpapers are not displayed in Gnome appearance properties" [High,Confirmed] https://launchpad.net/bugs/986231 | 15:24 |
| stgraber | (built and tested locally) | 15:24 |
| stgraber | highvoltage: http://paste.ubuntu.com/938407/ is the fix. Apparently gnome-background's xml parser was being really nice to us in the past as these wrong tags have been there since maverick :) | 15:26 |
| highvoltage | stgraber: ah, ok! | 15:26 |
| stgraber | (the _name was meant for translations but we don't have the translation infrastructure (and never had)) | 15:27 |
| pitti | ^ should make http://people.canonical.com/~ubuntu-archive/nbs.html happy again | 15:31 |
| pitti | review appreciated | 15:31 |
| Riddell | pitti: looking | 15:31 |
| pitti | Riddell: thanks | 15:34 |
| cjwatson | ogra_: I realise that it helps for big updates if the linaro tree is synced up, but I don't see why it has to be that way for every single patch. You could quilt push/quilt refresh and then it's just a question of conflict resolution | 15:37 |
| cjwatson | and send the linaro people the resulting delta | 15:38 |
| ogra_ | cjwatson, putting the gles patch on top again and then doing a push and refresh reverts the fix from the patch, i have to diff from scratch again | 15:38 |
| cjwatson | that's misuse of quilt somehow - this is perfectly doable | 15:38 |
| cjwatson | but it's very hard to debug at a distance | 15:38 |
| cjwatson | if this is still a problem by UDS then perhaps we should sit and walk through an example | 15:38 |
| cjwatson | FWIW I do functionally equivalent stuff *all the time* with Debian vs. Ubuntu patches to grub2 | 15:39 |
| ogra_ | well, the prob is that we have bzr trees where fixes are applied alongside with quilt patches in the compiz case | 15:39 |
| cjwatson | that may require some extra thought, but it does not require rediffing from scratch | 15:40 |
| stgraber | LP's done diffing edubuntu-artwork, would appreciate if someone could quickly review it | 15:40 |
| pitti | stgraber: looking | 15:41 |
| cjwatson | beat you | 15:41 |
| cjwatson | looks sane, accepted | 15:41 |
| stgraber | thanks | 15:41 |
| pitti | stgraber: oh, were these meant for i18n, and be .xml.in? | 15:42 |
| ogra_ | bug 770283 | 15:42 |
| ubot2 | Launchpad bug 770283 in compiz-core "[fglrx]title bar does not update on non-maximized windows" [Medium,In progress] https://launchpad.net/bugs/770283 | 15:42 |
| stgraber | pitti: yeah, I think we copy/pasted from ubuntu-wallpapers a while ago but didn't implement the translation infrastrcture :) | 15:42 |
| cjwatson | ogra_: I'm not saying this is easy to get one's head around - just that this *is* doable with these tools without the level of difficulty you've been describing, and so we ought to figure out what difficulties can be smoothed over | 15:42 |
| stgraber | pitti: for 12.10 I'll probably move that to .xml.in and add the po generation magic | 15:42 |
| cjwatson | the bit about reverting the fix from the patch is definitely not an intrinsic property of your setup | 15:43 |
| cjwatson | not saying it doesn't happen, I can see how it might, but it's a question of slightly different use of tools | 15:44 |
| ogra_ | yeah, probably | 15:44 |
| cjwatson | probably a matter of making sure you're popped down to the common base patch level before merging | 15:44 |
| Riddell | skaet: actually it might be !testers in #kubuntu-devel I forget which | 15:44 |
| cjwatson | or something along those lines | 15:44 |
| ogra_ | well, i dontn really touch quilt manually, i only copy the .patch file in place the way it is now ... | 15:45 |
| ogra_ | both trees are set up in a way to have identical content apart from the linaro gles code changes so diffing betwen them is the easiest way, but indeed that means to update every time quilt in the package is updated | 15:46 |
| NCommander | infinity: :-P | 15:48 |
| stgraber | python2.7 is done building | 15:49 |
| pitti | ogra_: you can't convince upstream to take the patch? :-) | 15:49 |
| ogra_ | pitti, not for 12.04, it will be in the 12.10 upstream tree | 15:49 |
| ogra_ | (note that this discussion is going on since two years, i'm massively happy to have *something* now, even though its horridly painful to maintain) | 15:50 |
| ogra_ | sadly it isnt just easily #ifdef'able | 15:51 |
| ogra_ | hmm, seems the ac100 .bootimg md5sums are incorrect once again | 15:53 |
| pitti | http://people.canonical.com/~ubuntu-archive/nbs.html | 15:58 |
| pitti | there, that's better | 15:58 |
| pitti | cjwatson: ^ (empty again) | 15:58 |
| cjwatson | thanks | 15:59 |
| ogra_ | skaet, so if uploading compiz today is mandatory for getting it into the images, the fix that blocks my upload is for bug 770283 ... looks like upstream is happy with it by the last comment on the bug | 16:02 |
| ubot2 | Launchpad bug 770283 in compiz-core "[fglrx]title bar does not update on non-maximized windows" [Medium,In progress] https://launchpad.net/bugs/770283 | 16:02 |
| skaet | Riddell, ok. I'll figure it out for the !testers call. | 16:02 |
| skaet | Riddell, how are ReleaseNotes looking for Kubuntu? What's left? | 16:02 |
| * skaet would like to get some docs team editors working through them, so grammar/spelling/awkwardness gets polished up. | 16:03 | |
| stgraber | infinity: could that have been caused by the switch to ext4? https://launchpadlibrarian.net/102695780/wubi-12.04-rev265.log | 16:03 |
| skaet | ogra_, looking | 16:04 |
| stgraber | (log above is from bug 986246) | 16:04 |
| ubot2 | Launchpad bug 986246 in wubi "Couldn't find valid filesystem superblock. during Wubi install" [Undecided,New] https://launchpad.net/bugs/986246 | 16:04 |
| * stgraber boots Windows | 16:05 | |
| * jibel tries wubi | 16:06 | |
| pitti | jibel: python 2.7.3-0ubuntu2 in precise-proposed was verified to work, right? and it just adds the conflicts | 16:07 |
| pitti | jibel: would moving that to precise instead of 0-day SRU fix the bug with the offline cdrom upgrade? | 16:07 |
| pitti | or is that a different cause? | 16:07 |
| pitti | doko: ^ | 16:07 |
| pitti | anyway, I think we should copy it to -release | 16:08 |
| pitti | skaet: ^ any objections? | 16:08 |
| doko | pitti, the offline upgrade is another issue | 16:09 |
| skaet | pitti, is it just adding the conflicts? nothing else? if so, no objections. If something else in there... need to understand more. | 16:09 |
| doko | which should be fixed in the release upgrader | 16:09 |
| pitti | skaet: yes, http://launchpadlibrarian.net/102670659/python2.7_2.7.3-0ubuntu1_2.7.3-0ubuntu2.diff.gz | 16:09 |
| pitti | and if it's not _that_ bug, it's still a bug you'd see when doing a cdrom upgrae | 16:09 |
| jibel | pitti, 2.7.3-0ubuntu2 fixes main all upgrade. | 16:09 |
| pitti | ok, copying | 16:09 |
| skaet | thanks pitti, no objections. | 16:09 |
| skaet | ogra_ can we line up some immediate focused testing on your fix and this specific one that will end up included as well, so we can revert if there are surprises? | 16:12 |
| ogra_ | skaet, i cant test fglrx ... | 16:13 |
| ogra_ | since i dont have the HW | 16:13 |
| skaet | what I'm worrying about is that one is pervasive to all the platforms, and yours is specific to arm... less risk. | 16:13 |
| ogra_ | my patch was heavily tested by alf and rsalveti already | 16:13 |
| ogra_ | according to https://code.launchpad.net/~sil2100/compiz/workaround_770283/+merge/102505 lukasz fix has been tested though | 16:14 |
| ogra_ | and smspillaz nodded it off as well | 16:14 |
| skaet | pitti, any thoughts here? from the changelog in the bug, and ogra_'s comments, I'm tempted to take the risk, and revert it out if problems show up over the weekend. | 16:15 |
| skaet | on the other hand, we need to keep the stability, and don't have apport on to alert us if we suddenly start seeing crashes. | 16:16 |
| pitti | well, we'll have the reports in whoopsie, but I don't think that's accessible yet | 16:16 |
| pitti | skaet: I'm afraid I don't have a qualified answer here, just gut feeling | 16:16 |
| skaet | pitti, gut feeling please | 16:17 |
| pitti | ogra_: this was tested on fglrx, was it tested on intel and nvidia, too? and arm/gles? | 16:17 |
| ogra_ | pitti, no, only the arm side has been tested | 16:17 |
| pitti | skaet: I'd take it if we have, or can get, this ^ hw coverage | 16:17 |
| ogra_ | but according to the merge request the fglrx fix has been tested separately already | 16:17 |
| pitti | right, that leaves nvidia and intel | 16:18 |
| slangasek | skaet: I've not caught the full thread and am otp, but I'm concerned about the idea of compiz changes right now for things other than ARM... what's the bug proposed for fixing here? | 16:18 |
| skaet | https://code.launchpad.net/~sil2100/compiz/workaround_770283/+merge/102505 | 16:18 |
| skaet | Its not release critical, and certainly SRU candidate | 16:18 |
| skaet | but its getting in the way of ogra_'s changes. | 16:19 |
| skaet | and untangling things in bzr is what he wants to avoid, I think. | 16:19 |
| ogra_ | right | 16:19 |
| skaet | ogra_'s fix is scope limited, and improves the situtation. | 16:19 |
| skaet | the interaction of this blocking one is risky, and has regression potential. | 16:20 |
| ogra_ | especially since untangling now doesnt get me anywhere, i will have to untagle again after the SRU | 16:20 |
| ogra_ | so for the gles fix its either go now *with* the fix ... or wait until after (or with) the SRU | 16:21 |
| jibel | I confirm bug 986246 . wubi's broken | 16:21 |
| ubot2 | Launchpad bug 986246 in wubi "Couldn't find valid filesystem superblock. during Wubi install" [Undecided,New] https://launchpad.net/bugs/986246 | 16:21 |
| stgraber | jibel: ok, I'm looking at it now | 16:22 |
| stgraber | jibel: it might be fixable by upgrading resize2fs to a newer version | 16:22 |
| pitti | skaet: it's a bit on the knee-jerk side for my taste, but I think your guess is as good as mine :/ | 16:22 |
| cjwatson | stgraber: ew | 16:23 |
| skaet | ogra_ do you know any good way of getting some testing on the combination of fixes on nvidia and intel? Yes, I agree pitti - its feeling too risky. We're going to need to play it safe and defer to SRU. | 16:23 |
| cjwatson | stgraber: let's revert to ext3 | 16:23 |
| ogra_ | well, if its really such a headdache ... we dont ship gles drivers on the images, people have to pull tem from the net post install, they would have to make sure to update to -updates them as well to have something working | 16:23 |
| cjwatson | infinity: your livecd-rootfs changes don't seem to be pushed to lp:livecd-rootf | 16:24 |
| cjwatson | s | 16:24 |
| ogra_ | while thats inconvenient it probably has less risk if i upload to proposed now and we leave it like that | 16:24 |
| skaet | ogra_, user base of this platform is more experienced than the others that could get impacted if we guess wrong. | 16:24 |
| ogra_ | thats indeed true | 16:24 |
| ogra_ | (as 0 day SRU i meant above) | 16:25 |
| stgraber | cjwatson: right, that works too. I'll do a bit of debugging here and send a merge proposal against wubi trunk so that we have that fixed for 12.10 at least | 16:25 |
| cjwatson | wait, why wubi trunk? I thought you meant resize2fs in e2fsprogs | 16:25 |
| cjwatson | oh god, it ships its own for Windows or something doesn't it | 16:26 |
| ogra_ | fun | 16:26 |
| stgraber | cjwatson: right we have resize2fs.exe in wubi.exe | 16:26 |
| stgraber | cjwatson: I'm guessing upgrading it to a newer version will fix it but I want to make sure | 16:26 |
| cjwatson | ./blobs/resize2fs.exe | 16:26 |
| cjwatson | shudder | 16:26 |
| cjwatson | how is this not a GPL violation? | 16:27 |
| skaet | ogra_, pitti - ok. get it in -proposed, and SRU will be the plan for it. Lets try to round up testers and get the combination checked out on the other hardware. | 16:27 |
| ogra_ | k | 16:27 |
| cjwatson | ev: ^- | 16:27 |
| gema | skaet: we've found a problem in the arm server install, bug 986203 | 16:31 |
| ubot2 | Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,Confirmed] https://launchpad.net/bugs/986203 | 16:31 |
| gema | skaet: the good news is that it installs in the end | 16:31 |
| skaet | gema, thats good news, so release notable then at least if we can't get a fix in time. | 16:32 |
| skaet | slangasek, is there anyone with bandwidth to look at it today? ^ | 16:34 |
| stgraber | cjwatson: I'm building a new wubi now here using what I think is a newer version of the blob that was used (basically extracted version of resize2fs.exe from the current cygwin release) | 16:35 |
| slangasek | ogra_: so what's the real impact of the gles bug? You said before "people sometimes don't get window decorations"; rickspencer3 tells me it's "compiz segfaults and that's all she wrote". Sorry if I'm making you repeat yourself, but I'd like to understand if the impact on ARM is really something you should be busting your but to fix in .0 or if an SRU of the whole thing would be better | 16:35 |
| ev | cjwatson: "An alternative method of satisfying the copyleft is to provide a written offer to provide the source code on a physical medium (such as a CD) upon request" | 16:35 |
| ev | pretty sure that's just the mingw resize2fs | 16:36 |
| cjwatson | gema: infinity wanted to wait until after his livecd-rootfs changes had landed to see what the effect of those on that bug would be | 16:36 |
| slangasek | skaet: "today"> probably not, infinity is off and stgraber has migrated east for the spring, so it's pretty much EOD for the lot | 16:36 |
| ogra_ | slangasek, the first gles fix reverted all other quilt patches (the gles branch didnt have any of them applied) the window decorator bit is only one fallout | 16:37 |
| cjwatson | ev: where's that written offer? | 16:37 |
| gema | cjwatson: ack, we'll retest on monday then? | 16:37 |
| slangasek | cjwatson: where in the pipeline are those livecd-rootfs changes now? | 16:37 |
| slangasek | I can get out and push if need be | 16:37 |
| ogra_ | slangasek, if we dont have the gles patch in the package, compiz dsegfaults and doesnt run on arm at all | 16:37 |
| cjwatson | slangasek: in precise, not in bzr | 16:37 |
| cjwatson | I'd like to copy ubiquity though | 16:38 |
| cjwatson | looks like it's built, so doing that now | 16:38 |
| ogra_ | slangasek, and as discussed above, i will now upload a 0 day SRU to -proposed so it gets testing on nvidia and intel | 16:38 |
| ogra_ | just quickly doing a testbuild on x86 before uploading to make sure everything is fine | 16:39 |
| cjwatson | ev: (also, it sucks for us anyway, because it hamstrings our agility in e.g. applying patches to it or upgrading to a new upstream version) | 16:39 |
| skaet | slangasek, ^^ SRU will be the plan for it. | 16:39 |
| slangasek | stgraber, cjwatson: FWIW I'm in favor of reverting to ext3 for wubi instead; that was the rough agreement when we flipped the switch late, I don't want us to be chasing "just one more bug" all week | 16:39 |
| cjwatson | I'm absolutely in agreement | 16:39 |
| cjwatson | I would have done it already if infinity's livecd-rootfs changes had been in bzr | 16:39 |
| slangasek | aha | 16:40 |
| cjwatson | wait, that change wasn't in l-r, was it | 16:40 |
| stgraber | slangasek: yeah, I'm fine with that. I just want to have a wubi branch ready with ext4 support for 12.10 | 16:40 |
| slangasek | stgraber: sure, that's fine | 16:40 |
| * skaet nods | 16:40 | |
| slangasek | cjwatson: bug #859552: live-build? | 16:40 |
| ubot2 | Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,Fix released] https://launchpad.net/bugs/859552 | 16:40 |
| cjwatson | Daviey: your debian-cd change for MAAS broke translations | 16:41 |
| cjwatson | Daviey: tolerate or revert? | 16:41 |
| cjwatson | Daviey: oh, meh, never mind, the MAAS version of that wasn't translated anyway : | 16:41 |
| cjwatson | :P | 16:41 |
| slangasek | ogra_: ok, if everyone's agreed that it's ok to punt compiz to SRU, I'm perfectly ok with that; otherwise I was going to offer to help untangle the merge today | 16:42 |
| cjwatson | somebody should file a gfxboot-theme-ubuntu bug for that ... | 16:42 |
| cjwatson | slangasek: yes, and cdimage I think | 16:42 |
| slangasek | yep | 16:42 |
| cjwatson | I'll deal with it then | 16:42 |
| slangasek | cheers | 16:42 |
| ogra_ | slangasek, there is nothing to untangle ... its broken by design (though cjwatson seems to have an idea how to design such stuff better) | 16:42 |
| ogra_ | (for the future) | 16:43 |
| skaet | :) | 16:43 |
| slangasek | ogra_: "untangle" meaning "allow your patch to go in cleanly, on its own, against the package already in precise" | 16:43 |
| ogra_ | slangasek, thats no prob i could do that now ... | 16:43 |
| slangasek | oh? | 16:44 |
| slangasek | clearly I've misunderstood the concern then | 16:44 |
| ogra_ | slangasek, but i have to invest another half day to do it again right after the pending fix was uploaded | 16:44 |
| ev | cjwatson: I agree that it's not ideal, but it's not like we put a GPL licensed body of work in some proprietary code. Last I checked, we didn't provide menu options for how you get the source code to all our packages. | 16:44 |
| ogra_ | the prob is that the gles patch is always the last quilt patch | 16:44 |
| * skaet goes to get the pad caught up with the discussions in the last hour.... | 16:44 | |
| ogra_ | so as soon as one quilt patch changes underneath, the gles one has to be updated | 16:45 |
| ev | I'm not trying to set up a strawman mind, I just don't see how this differs wildly from anything in the archive from a user perspective | 16:45 |
| ogra_ | (thats what i mean by broken design) | 16:45 |
| cjwatson | ev: Oh come on, menu options != written offer | 16:45 |
| slangasek | ev: everything in the archive has the source sitting alongside it in the same directory, and every binary package has a copyright file telling people the license | 16:46 |
| cjwatson | there's a minimum legal requirement here and we aren't meeting it | 16:46 |
| cjwatson | we can't excuse that using arguments about user-friendliness | 16:46 |
| ogra_ | ok, compiz uploaded | 16:46 |
| slangasek | ev: you may not have noticed how strictly we adhere to the GPL elsewhere because this is all inherited from Debian and the bugs were shaken out long ago ;) | 16:47 |
| slangasek | but it does matter... Ubuntu should not be playing fast and loose with free software licensing | 16:47 |
| ev | so the legal requirement is that the license sit in a specific directory? I'm looking for this online but have not found it thusfar. | 16:48 |
| cjwatson | No, the legal requirement is not that | 16:48 |
| cjwatson | Please show me the written offer for corresponding source to resize2fs.exe | 16:48 |
| cjwatson | (It should accompany every object-code distribution of resize2fs.exe) | 16:49 |
| ev | so the full license merely has to be installed at the same time? | 16:49 |
| cjwatson | A license isn't an offer of corresponding source | 16:50 |
| cjwatson | Certainly we should install the licence | 16:50 |
| cjwatson | But even I have no idea where to find the corresponding source for resize2fs.exe | 16:50 |
| slangasek | ev: the requirement is that, when you distribute a binary, the recipient knows it's GPL and there's some way to trace it back to the source | 16:51 |
| slangasek | like cjwatson says, if *we* can't even find the source, we're clearly not fulfilling that req ;) | 16:51 |
| phillw | such things as the license are usually placed at the bottom of the man page for things like resize2fs? | 16:51 |
| ev | I'm not arguing that we are meeting the requirement | 16:51 |
| cjwatson | phillw: no, they're in /usr/share/doc/*/copyright | 16:51 |
| ev | I am trying to get some understanding of how much flexibility we have here | 16:52 |
| pitti | FWIW, we outright reject stuff in NEW which is GPLed and has no source | 16:52 |
| cjwatson | I'm actually kind of worried by the suggestion that we need flexibility; Ubuntu should find it very easy to comply with the GPL | 16:52 |
| phillw | cjwatson: never looked in there, but am on first name terms with man :D | 16:52 |
| pitti | e. g. PDFs, and of course binary blobs | 16:52 |
| stgraber | I think we should probably use the source tarball from cygwin and build it in our build process (so we know the binary matches) and ship the resulting resize2fs.exe in its own directory with the LICENSE | 16:53 |
| stgraber | considering we already build Windows stuff in the wubi build process, it shouldn't be impossible to do that too | 16:53 |
| cjwatson | phillw: there's no legal requirement that the licence be in any particular place; the standardised positioning in /usr/share/doc/*/copyright is for the benefit of archive admins, but that doesn't apply to Wubi since it isn't built as a standard binary package | 16:53 |
| cjwatson | (well, not entirely for the benefit of archive admins, it's useful to other people too) | 16:53 |
| slangasek | cjwatson, ev: I'm not sure we should consider this a stop-ship issue for wubi since it's not a new issue, but we should certainly fix it for .1 | 16:53 |
| stgraber | (or we can assume that the .src.tar.gz and the .bin.tar.gz on the cygwin ftp mirror match and then just write a reference to that in a file) | 16:53 |
| cjwatson | I agree, it's just that I only just noticed it | 16:53 |
| cjwatson | stgraber: which is fine as long as we can argue that our redistribution is "non-commercial" | 16:54 |
| cjwatson | (GPLv2 3c) | 16:54 |
| cjwatson | we generally don't use 3c because it's more trouble than it's worth in practice | 16:55 |
| cjwatson | (for us) | 16:55 |
| pitti | have a nice weekend everyone! please call my mobile if there's something urgent | 16:55 |
| slangasek | later, pitti :) | 16:55 |
| ev | so how hasn't all of Wubi been a GPL violation if the requirement is that the recipient knows that it's GPL? It surely doesn't say that anywhere in the UI. | 16:55 |
| ev | Again, just trying to get an understanding of this. | 16:56 |
| cjwatson | that's a misstatement of the GPL | 16:56 |
| cjwatson | it doesn't require UI presentation (unless you received it that way, in which case GPLv2 does not permit you to remove it) | 16:56 |
| cjwatson | the information has to "accompany" the object code | 16:56 |
| cjwatson | you have "flexibility" in exactly where that information goes | 16:57 |
| phillw | how are the alternate respins coming along, seems like all flavours are getting one? | 16:57 |
| cjwatson | I expect a court would apply some kind of reasonableness test | 16:57 |
| cjwatson | phillw: not started yet | 16:57 |
| phillw | he he, that will explain the delay, then :) | 16:58 |
| ev | so even though Wubi is built from a bzr branch that you have to know how to get at, this aside, it's perfectly in compliance with the GPL because the source lives in that branch and has license files in it? | 16:58 |
| cjwatson | I don't recall right now whether our Wubi distributions have any kind of licence indication accompanying them | 16:58 |
| cjwatson | It may well not be in strict compliance | 16:58 |
| ev | okay | 16:59 |
| slangasek | ev: has to accompany the *object* code... if there are parts of Wubi that are compiled, we're not in compliance there either unless the pointer to the source is included somewhere with what we ship | 16:59 |
| cjwatson | slangasek: there are | 16:59 |
| cjwatson | if nothing else it includes bits of grub | 16:59 |
| slangasek | righto | 16:59 |
| ev | the whole thing is compiled, surely. I mean, if nothing else we ship python byte code. | 16:59 |
| slangasek | has anyone on the release team looked at this update-manager yet? | 16:59 |
| cjwatson | please review live-build | 17:00 |
| cjwatson | I'm pushing up the cdimage change now | 17:00 |
| slangasek | update-manager is an LTS->LTS upgrade issue only, so it could be left for .1 | 17:00 |
| slangasek | skaet: ^^ should I ask mvo to reupload to -proposed? | 17:00 |
| slangasek | cjwatson: looking | 17:00 |
| skaet | slangasek, looking | 17:01 |
| cjwatson | ev: I think that for example one way to be in compliance would be to put licensing information alongside wubi.exe on cdimage/releases and on the CD as a separate file, and for all links from our website to have a licensing link next to them | 17:04 |
| slangasek | cjwatson: rejecting, you didn't change series | 17:04 |
| slangasek | instaftbfs | 17:04 |
| cjwatson | slangasek: didn't need to, it didn't revert the whole patch | 17:04 |
| slangasek | oh | 17:04 |
| * slangasek looks harder | 17:04 | |
| slangasek | ah indeed | 17:05 |
| ev | cjwatson: okay | 17:05 |
| slangasek | cjwatson: anti-rejecting ;) | 17:05 |
| cjwatson | that is, if there isn't some other standard way to embed visible licensing information in a Windows binary | 17:05 |
| cjwatson | well, I don't know if we might need to ensure that the licensing stays on the installed system since we're copying bits of object code around | 17:06 |
| cjwatson | but that's a detail, I think | 17:06 |
| cjwatson | slangasek: it does test-build cleanly locally, though I'll admit I hadn't previously checked :) | 17:07 |
| slangasek | ubiquity sync is in the precise/unapproved queue, does that need a manual accept? | 17:07 |
| slangasek | cjwatson: ok :) | 17:07 |
| cjwatson | whoops, yes, done | 17:08 |
| cjwatson | really must arrange some kind of auto-accept scheme there | 17:08 |
| * slangasek nods | 17:08 | |
| skaet | slangasek, want to get the LTS->LTS experience as shiny as possible out of the box. Have scanned through it, and it also contains fix for kde update's if you could take a review pass, I'd rather let it in. | 17:08 |
| slangasek | skaet: even though we don't encourage LTS->LTS upgrades until .1? | 17:09 |
| slangasek | and the reason we don't is to put additional polish on that upgrade between now and then, which means anyone *actually* using the .0 alternate CD for an LTS->LTS upgrade is still going to have a poorer experience? | 17:09 |
| slangasek | skaet: the kubuntu fix is nothing more than a change to the package description - zero-risk | 17:10 |
| skaet | slangasek. ok. if kubuntu fix is zero -risk. clean there. what is the downside of accepting it now? | 17:13 |
| slangasek | a) one more thing we have to wait for before respinning, b) I have no idea what that variable we're un-setting actually does and don't have time to dig deep on it | 17:14 |
| skaet | (I am fine with it be reuploaded to -proposed, as an SRU, but fix would be nice to have if regression risk is low) | 17:14 |
| slangasek | actually, it needs reuploaded to -proposed regardless | 17:14 |
| slangasek | because it's arch: any/all skew | 17:14 |
| slangasek | well... but let me check the build times | 17:15 |
| slangasek | nah, ok, < 5 minutes to build | 17:16 |
| slangasek | so if we accept it now, they'll all be in sync | 17:16 |
| skaet | slangasek, gah, just rejected it. | 17:16 |
| slangasek | skaet: but do we want to accept it, or do we want to SRU it and put it through a longer QA? | 17:16 |
| cjwatson | that's what the rejected queue is for ;-) | 17:16 |
| slangasek | we can always unreject ;) | 17:16 |
| skaet | slangasek, if we have a set of knowledgable eyes able to look at it, I'd prefer to accept. We will revert, and I think it will get more testing if its in the candidate images for community testing this weekend. | 17:18 |
| mvo | slangasek: well, its a cdrom upgrade issue only, so it would be good to have it on the cd | 17:18 |
| skaet | s/revert/revert if any regressions/ | 17:19 |
| slangasek | mvo: again, it's a CD that we're a) not pressing, b) not going to tell people is good for LTS->LTS upgrades anyway | 17:19 |
| mvo | slangasek: ok | 17:19 |
| slangasek | but ok - at this point have spent more time discussing than the bug is worth ;) | 17:19 |
| slangasek | so I'll accept it | 17:19 |
| mvo | sorry | 17:19 |
| cjwatson | of course people are going to use it regardless of whether we recommend it | 17:19 |
| * skaet nods | 17:20 | |
| slangasek | skaet: I don't think you can count on community testing of CD-based upgrades... I don't think we even have an ISO test case for that? | 17:20 |
| mvo | fortunately the auto-upgrader-tester will tell us any issues by tomorrow | 17:20 |
| * slangasek nods | 17:20 | |
| slangasek | mvo: does the python-central fix need to be accepted at the same time? | 17:20 |
| slangasek | I haven't reviewed that one yet | 17:21 |
| mvo | slangasek: I don't know, doko will know though, my change is entirely based on what doko told me :) | 17:21 |
| slangasek | ok | 17:21 |
| slangasek | u-m accepted | 17:21 |
| * skaet --> food, biab | 17:21 | |
| slangasek | looking at p-c | 17:21 |
| * mvo -> evening | 17:21 | |
| * slangasek waves to mvo | 17:21 | |
| slangasek | thanks :) | 17:21 |
| doko | slangasek, no, if the update-manager patch is in, then the python-central change isn't really necessary, and it's universe now anyway ... | 17:22 |
| slangasek | doko: so with the u-m patch, this p-c change only touches a dead code path? | 17:23 |
| doko | slangasek, yeah, for the relevant case. but there were a fewer other unguarded ones | 17:23 |
| slangasek | safe, per-se correct, universe - accepting | 17:23 |
| doko | and away as well ... | 17:24 |
| cjwatson | python-central (from python-central) is seeded in: | 17:24 |
| cjwatson | mythbuntu: daily-live | 17:24 |
| cjwatson | but presumably we'll pick that up as a consequence of other things anyway | 17:24 |
| * slangasek nods | 17:24 | |
| cjwatson | can I accept my own unseeded (per seeded-in-ubuntu) universe uploads? | 17:28 |
| cjwatson | since those are only frozen due to LP inflexibility | 17:28 |
| slangasek | AIUI yes | 17:28 |
| cjwatson | good, that's what I thought | 17:29 |
| slangasek | ogasawara: something's gone wrong on http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html, it consistently believes the desktop CDs are up to date :) | 17:45 |
| ogasawara | slangasek: hrm, lemme investigate | 17:45 |
| Q-FUNK | infinity: is there still any outstanding issue on that estonian FF plugin that needs to be fixed? | 17:51 |
| highvoltage | stgraber: hmm, the distupgrade-fetcher seems to be failing in edubuntu atm | 17:55 |
| highvoltage | stgraber: in the command line I also see "WARNING:root:file 'precise.tar.gz.gpg' missing". networking is fine and I also tried it with google dns just to make sure it doesn't happen because we hijack archive.ubuntu.com | 17:58 |
| slangasek | fooey, update-manager managed to miss the publisher on armhf | 18:05 |
| slangasek | so looks like a half hour wait before we can respin | 18:05 |
| slangasek | skaet: other than that, AFAIK all the triggers on the pad are in - what do you want to do as far as respins today? | 18:05 |
| skaet | slangasek, based on what I'm seeing on the pad, full set (except netboot) is appropriate. | 18:07 |
| slangasek | right | 18:07 |
| slangasek | sounds like we should hold off on edubuntu for the above though | 18:08 |
| slangasek | at least until it's investigated | 18:08 |
| skaet | agreed. | 18:08 |
| slangasek | well, or at least until we know if it's getting investigated today, if stgraber is gone for the day :) | 18:09 |
| skaet | slangasek, did infinity share his timing results from last night's runs anywhere? | 18:09 |
| skaet | re: edubuntu, fine by me. :) | 18:09 |
| bdmurray | will the last update-manager upload fix bug 986201? | 18:09 |
| ubot2 | Launchpad bug 986201 in update-manager "fail to upgrade to 12.04 from 10.04" [Undecided,New] https://launchpad.net/bugs/986201 | 18:09 |
| slangasek | skaet: not to my knowledge, though AIUI that was mostly meant to be input for shuffling builders around server-side - should be invisible for us when running the pipeline | 18:09 |
| skaet | if not, I'll trigger the runs then when we're ready and pull out the timings I want. | 18:10 |
| slangasek | bdmurray: yes | 18:10 |
| skaet | ok | 18:10 |
| slangasek | bdmurray: that's a duplicate of the bug in the changelog | 18:10 |
| infinity | cjwatson: livecd-rootfs commit> left in a hurry, committed now. | 18:13 |
| infinity | cjwatson: As for the resize2fs wubi thing, ARGH. | 18:13 |
| infinity | skaet: If you don't mind, I'd like to trigger the preinstalled set on the next rebuild, but happy to cut and paste the results for you. | 18:17 |
| infinity | skaet: (I haven't had a chance to test the latest iteration to see if it needs tweaking and/or straight-up fixing; was waiting for a rebuild trigger) | 18:17 |
| slangasek | since it's only armhf that lagged behind on update-manager, and armhf is all preinstalled, I guess we could launch respins for the rest right now? | 18:19 |
| infinity | Sure could. | 18:19 |
| skaet | infinity, if you're triggering cut and paste will work for me. | 18:19 |
| infinity | slangasek: Do we have everything the other images want? | 18:21 |
| slangasek | infinity: per http://pad.ubuntu.com/ubuntu-release, yes | 18:22 |
| slangasek | (just double-checked that our "targets of opportunity" are all in -release, not -proposed) | 18:22 |
| infinity | Check. | 18:22 |
| slangasek | ok, I'll kick off the non-preinstalled run | 18:22 |
| slangasek | (non-preinstalled, non-core) | 18:23 |
| infinity | Go nuts. | 18:23 |
| infinity | It'll bugger my preinstalled timing a bit, but I'll suffer. ;) | 18:23 |
| infinity | update-manager-core | 1:0.156.14 | precise | amd64, armel, armhf, i386, powerpc | 18:26 |
| slangasek | can we drop the "or the long way" pipeline from the pad yet? :) | 18:26 |
| infinity | ^--- u-m is fine now too. | 18:26 |
| slangasek | infinity: yep - that one's all you anyway | 18:26 |
| slangasek | respinning the world minus a forelimb | 18:27 |
| * infinity looks as ps output on nusakan suspiciously. | 18:27 | |
| infinity | slangasek: You seem to have ubuntu building twice... | 18:27 |
| slangasek | yes | 18:27 |
| slangasek | know a reliable way to kill the first one? | 18:27 |
| slangasek | my cut'n'paste caught a carriage return I didn't want :P | 18:27 |
| infinity | D'oh. | 18:27 |
| infinity | And no, on the builder side, it's all far too fragile to kill remotely. | 18:28 |
| infinity | Human intevention, or wait out the ~15m. | 18:28 |
| slangasek | I was going to let the first one spin itself out... should be fast enough | 18:28 |
| Q-FUNK | gotta thank the horses for being such good sports in returning the carriage to the stables. | 18:28 |
| skaet | yeah, wait it out is best. | 18:28 |
| slangasek | utlemming: are you steering cloud image spins? | 18:29 |
| utlemming | slangasek: yes, sir | 18:29 |
| slangasek | utlemming: so we have main quiesced for the moment and there are some fixes to be picked up, if you want to respin some candidates | 18:30 |
| * skaet sees slangasek beating her to the next question on her checklist... ;) | 18:30 | |
| skaet | lol | 18:30 |
| slangasek | I'm trying to clear stuff off the pad ;) | 18:31 |
| skaet | me hugs slangasek :) | 18:31 |
| utlemming | slangasek: okay, I do a respin, although I was planning on using Tuesday for the release candidate | 18:32 |
| slangasek | utlemming: tuesday is rather late for us to fix if there are any problems | 18:33 |
| infinity | Dearest nusakan, WTF? | 18:33 |
| infinity | ubuntu preinstalled | 18:33 |
| infinity | ubuntu-amd64 on kapok.buildd starting at 2012-04-20 18:31:01 | 18:33 |
| infinity | ubuntu-i386 on cardamom.buildd starting at 2012-04-20 18:31:01 | 18:33 |
| infinity | ubuntu-powerpc on royal.buildd starting at 2012-04-20 18:31:01 | 18:33 |
| infinity | ^--- Something's dreadfully wrong with this picture. | 18:33 |
| cjwatson | haha | 18:33 |
| cjwatson | hope I didn't lose a bit somewhere ... | 18:34 |
| skaet | utlemming, getting some data now, given alot of the churn that's been going on will be beneficial. | 18:34 |
| utlemming | slangasek: right, we are doing daily builds of precise on EC2 up until the release | 18:34 |
| skaet | utlemming, anything thing significant showing up test case/bug wise on your radar? | 18:35 |
| * infinity senses there may be some by-hand recovery here in a bit. :P | 18:35 | |
| slangasek | skaet: I may have forgotten to set CDIMAGE_POST_QA in my shell - is that still needed, or do we post everything to the tracker by default now? | 18:35 |
| infinity | cjwatson: I'm failing to see how I can blame this on you. | 18:36 |
| utlemming | skaet: none, yet. My dailies have been more or less clean for the last week, except for general EC2 bugginess | 18:36 |
| skaet | slangasek, its still needed as far as I can tell. | 18:36 |
| skaet | and if you don't have it set, manual time. | 18:36 |
| infinity | slangasek: It happened automagically the last time I did builds. | 18:36 |
| infinity | slangasek: YMMV. | 18:36 |
| slangasek | skaet: ok, I checked and it is in my shell env after all | 18:36 |
| cjwatson | rargh, I test-built ugene and now it FTBFS everywhere | 18:36 |
| skaet | :) | 18:37 |
| slangasek | hurray for never logging out of my shell | 18:37 |
| cjwatson | Braces mismatch /build/buildd/ugene-1.9.8+repack/ugene.pro:37 | 18:37 |
| cjwatson | apparently I suck | 18:37 |
| utlemming | slangasek: rebuild eta is 3 hours | 18:37 |
| slangasek | utlemming: cheers :) | 18:37 |
| utlemming | slangasek: I'll post the complete testing suite against this once its done | 18:38 |
| cjwatson | obviously didn't test-build *that* one | 18:38 |
| slangasek | infinity: can I assign bug #986203 to you for follow-through once the new images are out of the oven? | 18:39 |
| ubot2 | Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [Undecided,Confirmed] https://launchpad.net/bugs/986203 | 18:39 |
| slangasek | or if you're ENOTIME I can kick it back to QA to re-test Monday | 18:40 |
| infinity | slangasek: Well, I'll be testing Monday too. | 18:52 |
| infinity | slangasek: Today, I think I might want to sort out why the heck "buildlive ubuntu daily-preinstalled" just tried to spit out all the non-preinstalled arches. :P | 18:53 |
| slangasek | infinity: 'twas really a question of if you'd be testing today, since if we confirm the bug is still there some of us still on the ground might be able to poke at it blindly over the weekend | 18:53 |
| infinity | slangasek: But after that, I might have time for testing. | 18:53 |
| slangasek | yep | 18:53 |
| slangasek | that's the priority, of course | 18:53 |
| infinity | My Panda's oddly idle for the first time in a long time, so if I can coax images out, I'll spin one up. | 18:54 |
| slangasek | oh, er, why are these powerpc builds still going to royal? | 18:54 |
| slangasek | shouldn't that have been sulfur? | 18:54 |
| infinity | You didn't get that memo? ;) | 18:54 |
| slangasek | no | 18:54 |
| infinity | sulfur's an lp-buildd now. | 18:54 |
| slangasek | or maybe I got the memo but read it backwards | 18:54 |
| infinity | I tested them against each other for live builds, and they were doing ubuntu-live within about 30s of each other. | 18:54 |
| slangasek | right | 18:54 |
| infinity | So, opted to throw the two extra cores at package builds. | 18:55 |
| slangasek | yes - I got the memo and read it backwards ;) | 18:55 |
| infinity | cdimage@nusakan:~/cdimage$ CDIMAGE_ROOT=. default-arches ubuntu daily-preinstalled precise | 19:01 |
| infinity | armhf+ac100 armhf+mx5 armhf+omap4 armhf+omap | 19:01 |
| infinity | Kay, so, I'm not insane. | 19:01 |
| infinity | Maybe my environment in that terminal just got wildly buggered somehow. | 19:02 |
| cjwatson | infinity: if you'd left ARCHES exported, that would override | 19:04 |
| infinity | cjwatson: Nope. | 19:05 |
| infinity | cjwatson: I'm pretty much just puzzled. | 19:05 |
| infinity | But I'll wait until this run is done to worry about it. | 19:06 |
| slangasek | infinity: could we at least get your extra powerpc build hard-killed, so royal isn't further bottlenecking? | 19:07 |
| slangasek | since now there are 3 serialized builds of ubuntu holding things up when we only need one | 19:07 |
| infinity | They're not even deterministically serialized. I should fix that some day. | 19:08 |
| infinity | (Just three processes spinning on a lockfile) | 19:08 |
| slangasek | well, if you were to kill the currently-running build, that would be correct | 19:08 |
| slangasek | since that's the one that my pipeline isn't going to see :P | 19:08 |
| infinity | It's got to be almost done by now. | 19:09 |
| infinity | I could kill mine from here. | 19:09 |
| infinity | Maybe. If I can sort out which ssh is me... | 19:09 |
| slangasek | but killing the ssh client doesn't kill the queued job, AFAIK? | 19:09 |
| slangasek | (remember my uncommitted changes futzing with tty passing?) | 19:10 |
| infinity | There, killed mine. | 19:10 |
| infinity | Oh, does it just disconnect and carry on its merry way? | 19:10 |
| * infinity facepalms. | 19:10 | |
| slangasek | ye | 19:11 |
| slangasek | s | 19:11 |
| * infinity sighs. | 19:11 | |
| infinity | I'll go find a webop and see if we can unmess this. | 19:11 |
| slangasek | do we need to raise SIGLAMONT? | 19:11 |
| slangasek | ok | 19:11 |
| slangasek | would love to get that fixed so we actually do have remote job control over them | 19:11 |
| slangasek | since SIGINT is much cheaper to raise | 19:12 |
| infinity | It might just be a question of changing authorized_keys to be slightly less draconian. | 19:12 |
| infinity | I don't recall the contents of said file anymore. | 19:13 |
| infinity | slangasek: I kinda want to blame the openjdk/amd64 build failure on your fontconfig changes, but I'm confused by why it didn't fail everywhere with the same errors. | 19:18 |
| infinity | slangasek: And I think the response time on royal was a bit too long, we're down to only two BuildLiveCD jobs now. Hopefully the active one is yours. :/ | 19:20 |
| === kenvandine_ is now known as kenvandine | ||
| infinity | slangasek: We could just kill the one that's still waiting on a lock; your cron.daily will pick up the latest livefs (which is obviously quite recent) | 19:23 |
| infinity | Yeah, I'm going to do that. Let's see if it's you. | 19:23 |
| slangasek | infinity: wait | 19:23 |
| infinity | ...? | 19:23 |
| slangasek | doesn't that cause buildlive to exit non-zero? | 19:24 |
| infinity | Oh, it does. :/ | 19:24 |
| slangasek | actually... that's ok | 19:24 |
| infinity | At least, I think it does. | 19:24 |
| slangasek | I can still just run cron.daily-live by hand | 19:24 |
| slangasek | yah, kill it | 19:24 |
| infinity | Did it go poof? | 19:26 |
| slangasek | job from royal is gone, buildlive returned success, cron.daily-live running | 19:26 |
| slangasek | so looks good | 19:26 |
| infinity | Shiny. | 19:26 |
| infinity | System administration via pastebin, it's all the rage. | 19:26 |
| slangasek | so what's royal doing now? | 19:27 |
| infinity | Still building the one I triggered, I believe. | 19:27 |
| slangasek | ok | 19:27 |
| slangasek | that's probably not worth futzing with further? | 19:27 |
| infinity | I guess you want it for kubuntu, you greedy man? | 19:27 |
| slangasek | I do at some point :) | 19:27 |
| stgraber | highvoltage: I'll have a look. The automated dist-upgrade succeeded though so it's likely something to do with your setup (or some other upgrade weirdness) | 19:28 |
| infinity | Well, get in line, I still have to build more ARM images on our PowerPC buildd. | 19:28 |
| slangasek | fine, I'll build the powerpc images on my alpha | 19:28 |
| infinity | You still have one that workd? | 19:28 |
| infinity | s | 19:28 |
| slangasek | <cough> no | 19:28 |
| slangasek | I'm bluffing | 19:28 |
| infinity | Hah. | 19:28 |
| highvoltage | stgraber: ok, it was with a clean 11.10 install though, but anything is possible :) | 19:28 |
| slangasek | stgraber: when you know the answer, please update the pad and ping me - I've held off respinning edubuntu in case other fixes are needed | 19:29 |
| slangasek | grr, would it actually be faster for me to use jigdo on this alternate image download? | 19:30 |
| stgraber | slangasek: I'll run another upgrade test now but in any case, our DVD only contains a livefs so can't be used for upgrades | 19:30 |
| slangasek | stgraber: oh, so this is not DVD-affecting at all? | 19:30 |
| stgraber | right | 19:30 |
| slangasek | ok, I'll add edubuntu back into the pipeline | 19:31 |
| slangasek | thanks | 19:31 |
| stgraber | highvoltage: i386 or amd64? | 19:31 |
| slangasek | stgraber: mazel tov, edubuntu gets to jump the queue for builds now because I've queued it in parallel | 19:33 |
| skaet | :) | 19:34 |
| highvoltage | stgraber: both do the same | 19:34 |
| stgraber | yay! | 19:34 |
| stgraber | highvoltage: ok | 19:34 |
| * infinity wonders when we got 70 new packages that FTBFS on armhf... | 19:38 | |
| slangasek | infinity: link? | 19:41 |
| slangasek | also, why do you think defoma is to blame for openjdk? | 19:41 |
| infinity | slangasek: Oh, just complaints about missing font aliases. | 19:41 |
| infinity | slangasek: But only on amd64, so it's hard to blame you. | 19:42 |
| slangasek | what's the link for that one? | 19:42 |
| infinity | https://launchpadlibrarian.net/102704979/buildlog_ubuntu-precise-amd64.openjdk-6_6b24-1.11.1-4ubuntu3_FAILEDTOBUILD.txt.gz | 19:42 |
| slangasek | doesn't seem to be either in-archive or in the test rebuild? | 19:42 |
| slangasek | ah, -proposed | 19:42 |
| slangasek | so what's this about 70 new FTBFS? | 19:43 |
| infinity | Maybe I snapshotted this at the wrong time, but I was pretty sure the above was before I did my mass-give-back. | 19:43 |
| slangasek | is that related to cjwatson's give-back? | 19:43 |
| infinity | And the bottom is now. | 19:43 |
| infinity | http://lucifer.0c3.net/~adconrad/omgwtflol.png | 19:43 |
| infinity | Colin's give-back was for the test rebuild, this is the archive. | 19:43 |
| slangasek | hmm | 19:43 |
| infinity | Given that ARM finished the give-back before powerpc, this can't have been mid-give-back. | 19:44 |
| infinity | Since PPC is obviously on-par here, (modulo three things moving status) | 19:44 |
| slangasek | so before these were given back, what were they? | 19:45 |
| NCommander | yay | 19:45 |
| infinity | Yeah, I have no idea. | 19:45 |
| slangasek | k | 19:45 |
| infinity | Wait, what? | 19:45 |
| infinity | Where did those desktop builds come from? | 19:45 |
| infinity | Oh. | 19:45 |
| infinity | Hahaha. | 19:45 |
| slangasek | not from me | 19:45 |
| infinity | cron.daily did the right thing, even though buildlive didn't. Of course. | 19:45 |
| slangasek | heh | 19:45 |
| slangasek | yep | 19:45 |
| infinity | So, those desktop ones are useless. | 19:46 |
| infinity | NCommander: The server ones should be okay, though. | 19:46 |
| * slangasek disables the desktop ones again on the tracker | 19:46 | |
| NCommander | infinity: I didn't test the last spin, so I'll just spotcheck, and I need to finish the workload testing | 19:46 |
| infinity | slangasek: And yeah, where those 70 builds came from, I have no idea, unless we're really synced 70 universe packages in the last 4 or 5 days that added arm to the arch list? Seems unlikely. | 19:47 |
| infinity | s/we're/we've/ | 19:48 |
| slangasek | infinity: yeah, I dunno | 19:48 |
| infinity | Aaaand, I just nervously refreshed the old page when I meant to click on it and save the HTML so I could parse it. | 19:49 |
| infinity | So, there's a mystery I'll never solve. | 19:49 |
| infinity | Stupid habits. | 19:49 |
| slangasek | stgraber: does the iso tracker no longer support declaring a default milestone? | 19:59 |
| slangasek | (for adding builds to) | 19:59 |
| NCommander | wow | 20:01 |
| NCommander | new images | 20:01 |
| stgraber | slangasek: correct, in the past it wasn't really a question of default milestone so much as the only milestone that wasn't archived | 20:04 |
| stgraber | slangasek: now that more than one milestone can be active at the same time, the xmlrpc client needs to know which one to add the build to | 20:05 |
| micahg | Daviey: skaet: I'm going to sponsor Bug #986314 and bug 986159 to -proposed, can we pick those up if there's an Ubuntu server image respin | 20:06 |
| ubot2 | Launchpad bug 986314 in squid3 "squid3 missing pie and bind-now hardening options" [Undecided,New] https://launchpad.net/bugs/986314 | 20:06 |
| ubot2 | Launchpad bug 986159 in squid3 "squid3 open file descriptors limit is set incorrectly" [Undecided,Triaged] https://launchpad.net/bugs/986159 | 20:06 |
| slangasek | stgraber: hmm, I thought there used to be an option on the milestone page to set a "default" - given that some builds are still not added with the xmlrpc client, that could still be useful I guess | 20:06 |
| slangasek | (but not a high priority) | 20:07 |
| skaet | micahg, ack. we'll add to pad as opportunity target, if server team agrees, and we need a respin. | 20:07 |
| cjwatson | infinity: I don't think ARM finished the give-back before powerpc. I'm sure I looked earlier to see powerpc done and armhf still going. And those ARM numbers look about right for pre-give-back to me. | 20:08 |
| infinity | cjwatson: Mmkay. I could just be losing my mind in my old age. | 20:09 |
| infinity | I think it's turned to jelly and migrated to my abdomen. | 20:09 |
| infinity | rsalveti: Speaking of xbmc (since the queuebot just reminded me), did you arm changes fall prey to ENOTIME? | 20:21 |
| superm1 | infinity: the changes that rsalveti did should be upstream now, and that's why i was requesting the s ync | 20:24 |
| slangasek | infinity: I disclaim responsibility for that openjdk-6 failure; the defoma integration was trivial and removing it should have no impact on fontconfig's own cache | 20:24 |
| infinity | superm1: I see no mention in the synced version of patches. | 20:24 |
| superm1 | although micahg just pointed out the builds are failing on experimental (https://buildd.debian.org/status/package.php?p=xbmc&suite=experimental) | 20:24 |
| infinity | superm1: All he did was change it back to arch:any, he didn't actually fix anything. | 20:25 |
| slangasek | the integration was for exposing fontconfig-registered fonts into defoma rather than vice-versa, so | 20:25 |
| superm1 | infinity: it's with the "new upload of eden branch" and then the separate patch to run with sytem tinyxml | 20:25 |
| infinity | Oh. | 20:25 |
| * infinity is too tired to keep track of pretty much anything at this point. | 20:27 | |
| infinity | Maybe it's time to veg out and do laundry. | 20:27 |
| highvoltage | infinity: heh, I also do that when my brain stops braining | 20:29 |
| stgraber | skaet, slangasek: Apparently something was broken on highvoltage's network when running the Edubuntu upgrades (likely that hidden transparent proxy ...). I'm not done running them here but I'm much further than where highvoltage was and didn't see any problem downloading precise.tar.gz here. | 20:30 |
| Q-FUNK | chrisccoulson: please check your e-mail. :) | 20:31 |
| stgraber | oh, more work, yay! | 20:32 |
| slangasek | stgraber: ack | 20:33 |
| skaet | stgraber, good to hear. | 20:34 |
| stgraber | slangasek: hmm, I'm wondering if the new python2.7 didn't break the upgrades... | 20:34 |
| slangasek | it did | 20:34 |
| stgraber | oh good, happy to know it's not an Edubuntu specific issue then ;) | 20:35 |
| slangasek | who accepted this? | 20:35 |
| slangasek | because there needs to be a lot careful consideration given to adding Conflicts to core packages the week before release | 20:35 |
| infinity | I can tell you who copied it... | 20:35 |
| slangasek | infinity: you, or? | 20:37 |
| infinity | [ubuntu/precise] python2.7 2.7.3-0ubuntu2 (Accepted) Martin Pitt | 20:37 |
| infinity | Handy side-effect of that awful misfeature. | 20:37 |
| * slangasek nods | 20:37 | |
| stgraber | oh, the whoever copies appears as the uploader feature :) | 20:38 |
| * infinity nods. | 20:38 | |
| slangasek | skaet: jibel has just reported that all the oneiric->precise upgrades are broken by this python2.7 update | 20:38 |
| infinity | Of course, all tests failed before this upload too.. | 20:40 |
| slangasek | no, the *other* tests failed before this upload | 20:41 |
| slangasek | it was only causing lucid->precise upgrades to fail | 20:41 |
| infinity | Oh, I missed the "oneiric" in your line there. | 20:42 |
| infinity | Right. | 20:42 |
| slangasek | the only reason lucid upgrades are faring better is because of the backported apt | 20:42 |
| slangasek | and so the respins we just did are useless | 20:42 |
| slangasek | ah no, it's not the backported apt that matters, it's that python-minimal depends on python2.7-minimal already in oneiric | 20:44 |
| slangasek | jibel: thanks for letting us know about bug #986374 | 20:44 |
| ubot2 | Launchpad bug 986374 in update-manager "oneiric->precise upgrade failed: E:Internal Error, Could not early remove python-minimal" [Undecided,Confirmed] https://launchpad.net/bugs/986374 | 20:44 |
| infinity | The real problem here is an unexpressed dependency, quite obviously. | 20:45 |
| slangasek | jibel: how much time do you have available today for retesting? | 20:46 |
| infinity | I wonder if the loop could be avoided with a gentle sprinkling of breaks. | 20:46 |
| slangasek | no | 20:46 |
| slangasek | breaks only enforces deconfiguration, not upgrade | 20:46 |
| infinity | Oh, true. | 20:46 |
| infinity | I dunno, loops aren't the root of ALL evil. And it really does appear that 2.7-minimal depends on minimal, if it's calling its contents in postinst. | 20:47 |
| slangasek | jibel: I would like us to not have useless images all weekend; if you can help with upgrade testing - of *both* lucid and oneiric paths - I would certainly appreciate it; but I understand if you're EOD | 20:47 |
| stgraber | slangasek: I'll probably be around for the next two hours, my test system is Edubuntu currently but it seems to fail just as well as Ubuntu does | 20:47 |
| slangasek | yes, I don't know why we didn't just add a circular dependency here | 20:47 |
| slangasek | I may find out soon | 20:47 |
| slangasek | stgraber: 2 hours won't be long enough; I'm going to need a full hour to get a fix in that I trust | 20:48 |
| infinity | slangasek: Does it take a fairly fat system to reproduce, or does a chroot with python-minimal in it do the trick? | 20:48 |
| slangasek | infinity: test your chroot and let me know ;) | 20:48 |
| infinity | ;) | 20:48 |
| slangasek | but we also want assurance that the full system upgrades work before we respin the planet again | 20:48 |
| * infinity spins up some oneiric chrootiness. | 20:48 | |
| infinity | At least jiggling control files and repacking debs is simple enough. | 20:50 |
| infinity | I'll just keep some pristine chroots handy. | 20:50 |
| * skaet goes and plans on marking all the images as needing rebuild as they emerge on the tracker. No point in folks using them then. | 20:50 | |
| slangasek | I'm killing the pipeline | 20:52 |
| slangasek | so there shouldn't be any more images coming to the tracker, for now | 20:52 |
| stgraber | infinity: I have one base container of every supported ubuntu release and use lxc-start-ephemeral to start one of them with an overlayfs overlay on top of the template. Boot -> upgrade -> grab the logs -> exit -> everything gets wiped. That gives you a clean test environment in a few seconds | 20:52 |
| infinity | stgraber: Well, then, I'll let you do this. :P | 20:53 |
| stgraber | infinity: do-release-upgrader is running here, just waiting for package download | 20:53 |
| stgraber | yep, it fails in the container too | 20:53 |
| * infinity goes back to playing with Pandas. | 20:53 | |
| stgraber | SystemError: E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal | 20:53 |
| stgraber | ERROR:root:SystemError from cache.commit(): installArchives() failed | 20:54 |
| stgraber | ERROR:root:found exception: 'E:This installation run will require temporarily removing the essential package python-minimal due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option., E:Internal Error, Could not early remove python-minimal' | 20:54 |
| infinity | Oh, it's Essential? No wonder it explodes. | 20:54 |
| infinity | \o/ | 20:54 |
| slangasek | Why is the conflicts on << 2.7.3 instead of << 2.7? | 20:54 |
| slangasek | yes | 20:54 |
| slangasek | which is a historical bug in its own right, but | 20:54 |
| slangasek | doko: ping | 20:54 |
| infinity | Doesn't matter where the conflict is, it's almost always a bad idea to conflict against essential packages unless you really, really have to. | 20:55 |
| infinity | And by "where", I mean "what version". | 20:55 |
| slangasek | I'm not saying it's a good idea, but I'm trying to work out all the options for fixing | 20:55 |
| infinity | The circular dep's technically more correct anyway, if B is calling A's binaries in postinst. | 20:55 |
| slangasek | one of which may be to correct the version number of the conflict | 20:55 |
| slangasek | circular deps have to be broken; the package manager may break them in the wrong place | 20:56 |
| slangasek | both packages have postinst | 20:56 |
| infinity | slangasek: If the loop involves many packages, yeah. If it's only two, it has a cute side effect of getting them in the same unpack run. | 20:56 |
| infinity | Both having postinsts makes their configure non-deterministic, but that's okay in this case, isn't it? | 20:56 |
| infinity | We just want both unpacked. | 20:57 |
| slangasek | hmm, maybe | 20:57 |
| slangasek | best way to find out is by testing | 20:57 |
| infinity | At least, that's how I read the bug. Looks like we just need a new version of a binary, not a newly-configured package. | 20:57 |
| infinity | (Not like I trust bug logs when the world explodes...) | 20:58 |
| slangasek | yes, that should be correct | 20:58 |
| ogasawara | slangasek: that was painful, but weather report should be updating properly now | 21:02 |
| slangasek | ogasawara: cheers... :) | 21:02 |
| jibel | slangasek, I'm here for the next 2 hours or so. if there's a fix during the night I can run the test first thing tomorrow morning | 21:02 |
| slangasek | jibel: ok. I'm going to leave the fix in -proposed this time until we get confirmed-good tests for all upgrades | 21:02 |
| slangasek | jibel: so if you're the first one to be able to test in the morning, you'll want to use -proposed | 21:03 |
| infinity | Can jibel's machinery test from a PPA? :P | 21:03 |
| stgraber | is there an easy way to get update-manager to take from -proposed? | 21:03 |
| stgraber | the upgrade code tends to disable everything in sources.list before the upgrade | 21:03 |
| slangasek | I'm not going to screw around with a ppa | 21:03 |
| stgraber | (sure we can simply hack that part of the code ;)) | 21:04 |
| jibel | slangasek, ok. | 21:04 |
| slangasek | the previous upload went to a ppa first, and look what good that did us | 21:04 |
| infinity | stgraber: Using the default setup, I'm pretty sure you can't. | 21:04 |
| infinity | slangasek: Oh dear. Right, nevermind. :P | 21:04 |
| jibel | infinity, yes, it can test from a ppa. | 21:04 |
| skaet | infinity, can you disable image errasing on the iso tracker please. i want to look at reverting back to prior versions, so testing can continue until this gets resolved. | 21:05 |
| jibel | but I prefer propose | 21:05 |
| jibel | d | 21:05 |
| skaet | ooops | 21:05 |
| skaet | s/iso tracker/nusakan/ | 21:05 |
| infinity | skaet: If you just want people testing images, the current ones are fine for all but being used for upgrades. | 21:05 |
| infinity | (And have all the other bits we want tested) | 21:06 |
| skaet | True | 21:06 |
| infinity | The python thing has zero impact on fresh installs, just upgrades. | 21:06 |
| skaet | ok, we'll leave the upgrade tests invalid and post a note on the top, until this is resolved. | 21:07 |
| stgraber | they are still useful to confirm the other fixes, it's just that they won't be the final images, so re-enabling everything but upgrades and adding a big warning at the top of the page should be fine | 21:07 |
| stgraber | skaet: let me know if you need help making that very visible, I know the new tracker filters some html codes ;) | 21:07 |
| infinity | Does it allow <h8>? :) | 21:08 |
| infinity | Oh, wait, it's been a while since I did HTML. Bigger is smaller, isn't it? | 21:08 |
| stgraber | <h1> is the biggest IIRC, though I don't think those are allowed, you need <strong> or something like that IIRC | 21:09 |
| * infinity goes back to playing with his "server" disguised cleverly as a cell phone reference platform. | 21:09 | |
| slangasek | why are the upgrades being disabled? | 21:11 |
| slangasek | ah, n/m, scrollback read | 21:11 |
| skaet | reenabled the 20120420.1 images. Now to figure out if there should be any of the 20120420 images enabled. | 21:13 |
| skaet | notice on status board placed. | 21:16 |
| skaet | (using <strong>. thanks stgraber ;) ) | 21:17 |
| skaet | ok, I think I've found all the 20120420 images that should have been renabled. If anyone spots some I've missed, just ping. | 21:26 |
| slangasek | infinity: ^^ please spot my bugs in python2.7 | 21:28 |
| infinity | slangasek: So, I can confirm https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/986203 on current images. I desperately need a nap, though, so I'll have to poke it later. | 21:28 |
| ubot2 | Launchpad bug 986203 in livecd-rootfs "oem-config prompts for tasksel configuration multiple times during the install" [High,Confirmed] | 21:28 |
| infinity | slangasek: And I was waiting on the queue diff, but I'll just download. :P | 21:29 |
| slangasek | infinity: ah, if it's nap time, I can get someone else to look | 21:29 |
| len | Ubuntustudio (32 and 64 bit) seem to be still disabled. | 21:29 |
| skaet | thanks len, fixing | 21:29 |
| * slangasek reenables all the flavors | 21:30 | |
| infinity | slangasek: Looks right to me. | 21:30 |
| slangasek | which is not enough to make queuebot hold its tongue ;) | 21:31 |
| infinity | slangasek: Clean revert + versioned dep. | 21:31 |
| len | Thanks. | 21:31 |
| slangasek | infinity: ok - if you're happy, please accept and we'll put it through the ringer | 21:31 |
| infinity | slangasek: Accepted. Nap time now. stgraber's container madness should be a big help here. ;) | 21:32 |
| superm1 | could someone reject the xbmc sync, it was supposed to fix ftbfs on armel, but micahg double checked and it's still failing | 21:32 |
| slangasek | infinity: nighty-night | 21:32 |
| stgraber | oh and as that's python2.7, that means we won't have it built for the next 5 hours or so | 21:32 |
| stgraber | (for armel and armhf at least) | 21:32 |
| slangasek | stgraber: hnngh. ok | 21:32 |
| slangasek | stgraber: well, it's arch-indep | 21:32 |
| skaet | len, date stamp on the current ones. 20-Apr-2012 03:16 which implies that they should stay as rebuilding (they're in progress on the builder) | 21:32 |
| slangasek | I'm more concerned about getting it tested | 21:32 |
| slangasek | which doesn't require arm | 21:33 |
| slangasek | superm1: done | 21:33 |
| stgraber | right, we can test it earlier, then wait the 5 hours for it to finish building before copying | 21:33 |
| superm1 | thanks | 21:33 |
| skaet | len, so I'll leave them disabled, since they won't have the new fixes we're trying to confirm. | 21:33 |
| infinity | Still more than 2 hours on x86. | 21:33 |
| infinity | You might want to do some by-hand deb-repacking to test. | 21:34 |
| len | skaet OK. | 21:34 |
| * infinity really naps now. | 21:34 | |
| slangasek | jibel: ^^ more than 2 hours before the python fix is available for testing, so I think you're off the hook for tonight ;) | 21:34 |
| stgraber | slangasek: I think I'll just do a local build of it with the tests disabled, that should cut down the build time | 21:35 |
| stgraber | though deb repacking would work too :) | 21:35 |
| slangasek | stgraber: I'm happy for you to do that, but I'm going to insist that we get full testing of the package that's in the archive before we do another global respin | 21:36 |
| slangasek | no reason to leave room for error here | 21:36 |
| stgraber | sure but I'll let you do that one as I'm not going to be around when that build finishes | 21:38 |
| * slangasek nods | 21:39 | |
| hggdh | slangasek: I can test the upgrade after a diner I have tonight | 21:42 |
| slangasek | hggdh: much appreciated! | 21:42 |
| hggdh | slangasek: KVM testing is OK, I hope | 21:42 |
| hggdh | jibel: ^ | 21:43 |
| slangasek | yes | 21:44 |
| hggdh | ack | 21:44 |
| jibel | hggdh, I changed the config of the upgrader to point to -proposed. You'll just have to run the jobs precise-upgrade-* and it should just work. If it doesn't I'll do it tomorrow morning. | 21:46 |
| hggdh | jibel: roger wilco | 21:47 |
| jibel | hggdh, start with server and if it passes, start the others | 21:47 |
| slangasek | yep | 21:47 |
| jibel | heading to bed then, good night every one | 21:47 |
| slangasek | night jibel | 21:48 |
| skaet | good night jibel | 21:49 |
| skaet | (and thank you!) | 21:49 |
| skaet | slangasek, I'm seeing ubuntu daily-presinstalled still active on the builders. Do you know if infinity killed off the rest of the builds (and I should just reenable all on the tracker), or if more should be emerging? | 22:05 |
| slangasek | skaet: there's still a 'buildlive' process running on nusakan, so I suppose that might still spit out an image | 22:09 |
| slangasek | only armhf preinstalled | 22:09 |
| slangasek | I already reenabled everything except for upgrades though | 22:09 |
| skaet | ok, thanks. thats probably best at this point. | 22:09 |
| cnd | slangasek, would an SRU to free a static buffer in a library at exit be allowed? | 22:47 |
| cnd | it's mostly a fix for a valgrind run | 22:47 |
| * skaet --> dinner, biab | 22:53 | |
| slangasek | cnd: I don't think that's worth an SRU on its own, no | 22:55 |
| cnd | ok | 22:56 |
| cnd | thought I'd ask instead of assume | 22:56 |
| * slangasek nods | 22:56 | |
| cjwatson | zul: I've done bug 986258, but please use syncpackage yourself in future - there's no need to go through the archive admins for this any more | 23:12 |
| ubot2 | Launchpad bug 986258 in novnc "Sync novnc 2012.1~e3+dfsg+1-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/986258 | 23:12 |
| cjwatson | (and it'll be faster for you not to) | 23:14 |
| rsalveti | infinity: yeah, in theory the support should be available at the debian package already, I'll check it again on precise to make sure | 23:16 |
| stgraber | slangasek: apt seems happy with my local build of python2.7 | 23:21 |
| slangasek | stgraber: what tests have you done? lucid,oneiric->precise? | 23:22 |
| stgraber | oneiric -> precise | 23:22 |
| slangasek | stgraber: can you test lucid->precise as well? | 23:22 |
| stgraber | yep, though sadly LXC only support upgrading without blowing up since Precise so I can make sure apt can resolve everything correctly and starts upgrading until it reaches udev or mountall, at which points it'll explode | 23:25 |
| slangasek | ah | 23:26 |
| stgraber | and I have to do it the non do-release-upgrade way because I still haven't found a way to get do-release-upgrade to keep my sources.list entries... I know what to change in the code to disable that bit, but as it's downloading a new signed copy and uses that, my local modification doesn't really help | 23:26 |
| stgraber | so currently I'm running a dist-upgrade without the new python, make sure apt fails after download, add my packages as a local repository, try again and check that it resolves fine and starts upgrading (until it reaches mountall or udev) | 23:27 |
| stgraber | hopefully the code doesn't drop -proposed in the same way, so once we have a package built we'll be able to test it | 23:28 |
| cjwatson | bug 986147 induces despair | 23:28 |
| ubot2 | Launchpad bug 986147 in openssl "openssl 1.0.1-4ubuntu2 breaks a bunch of ciphers" [High,Confirmed] https://launchpad.net/bugs/986147 | 23:28 |
| cjwatson | I can't win | 23:28 |
| cjwatson | openssl is a heap of junk, everything I backport breaks something different | 23:28 |
| slangasek | cjwatson: sorry :/ | 23:33 |
| cjwatson | the real answer is a time machine so that I can go and say no to the request to take that perf work in the first place, but it's almost certainly too tightly wound to revert now | 23:35 |
| cjwatson | so it's choice-of-bug territory until upstream get their stuff together | 23:35 |
| slangasek | yep | 23:36 |
| slangasek | can we nudge upstream to do that? | 23:36 |
| slangasek | would be a relief to have this wrapped up for .1 | 23:36 |
| slangasek | but I know that might not be possible | 23:36 |
| cjwatson | the upstream bug system already suggests a good deal of nudging | 23:36 |
| slangasek | ok :) | 23:37 |
| cjwatson | but yeah, I'll try to get things comprehensively forwarded upstream next week | 23:37 |
| stgraber | slangasek: I found an ugly way of getting do-release-upgrader to work but now it's checking that everything comes from a signed repository ... getting quite late here so I'm going to give up for today (apparently I need to be awake in 6 hours)... | 23:38 |
| slangasek | stgraber: don't sweat it - have a good night | 23:38 |
| slangasek | stgraber: hggdh should have us covered later this evening | 23:38 |
| hggdh | yes | 23:39 |
| * skaet back | 23:46 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
