[00:01] kirkland: looks sensible to me. Enjoy your testing. [00:01] RAOF: cheers, thanks [00:24] Fun. So ruby2.1 downloads config.guess and config.sub from the network. [00:24] infinity: ping, have a minute? [00:25] ScottK: haha =) good that ubuntu builders don't have network, unlike debian. Sounds like an RC bug to me. [00:25] or xnox [00:25] jose: hey! what's up? [00:26] xnox: hey, someone cancelled his OpenWeek slot tomorrow at 17 UTC and I was wondering if you would like to do a session about the Ubuntu Release Team [00:26] it's basically what you do on the team and how can people contribute [00:26] all for an hour [00:27] jose: haha =) well i'm not actually in fact on the release team. [00:28] oh, I thought you were [00:28] jose: and unfortunately i have an ~ 1.5h meeting at 17 UTC. [00:28] uh, good luck with that one [00:29] well, if anyone else from the release team was reading and wants to do it I'll be happy to set it up (as long as someone else doesn't snag the slot before!) [00:29] jose: here are the members https://launchpad.net/~ubuntu-release/+members [00:29] * jose pings 100 people [00:29] thanks for the link :) [00:29] * ScottK will be in the middle of a 9 hour meeting. [00:30] jose: it's only 10 =) well 7-8 if you discard the not so active people. [00:30] * jose strikes ScottK from the list :( [00:30] ScottK: =))))) 9 hour meetings -> sounds utopic [00:30] * jose puts an ice cream cone on his head [00:34] xnox: Even better I'm the presenter for about 4 hours of it. They'd notice if I was missing. [00:34] ScottK: one would think that.... [00:36] ScottK: one of my mates in university had a slide 30/38 that said "WAKE UP B#$@#" and nothing else, he had it up for good 20 seconds and only a couple of people smirked/giggled and everyone just stared akwardly, not realising what the giggles are for. [00:36] Fun. [00:37] I once had a slide that had a nice summary box at the bottom that said (in Latin) "everything sounds better in Latin". The presentation was very close to being given before anyone asked what it meant. [00:46] xnox: It gets worse. The configure check it has to see if config.sub/guess have already been downloaded looks in the wrong place. [00:56] And now I have to update distro-info-data before I can upload... [00:56] ScottK: i think that's updated already [00:56] In trusty? [00:56] It is in Utopic [00:58] ScottK: in trusty-proposed [00:59] Faster to edit /usr/share/distro-info/ubuntu.csv than to enable proposed. [00:59] true =) [01:01] infinity: cjwatson: the three boost packages are in the unapproved queue. Would be handy to build them & promote binaries from the "main-only" boost1.55 as per: $ rmadison -S boost1.54 -s trusty | grep -v universe [01:02] i'll do transition tracker for it tomorrow. [01:10] ScottK: distro-info-data is updated in all releases now. [01:10] infinity: Thanks. [02:00] xnox: Does boost-mpi need to build-dep on boost*? [02:00] xnox: The shlibdeps seem to be unhappy. [02:03] infinity: once the 2.1 binaries are published, I'll upload defaults. [02:03] ScottK: Looks like they're all going to succeed, so go ahead and upload. [02:04] ScottK: And pick a version that will let us sync with Debian later when they switch. [02:04] 1:2.1.0.0~ubuntu1 maybe [02:04] Oddly, I have 2.1.0.0~ubuntu1 [02:04] (with the epoch) [02:04] Heh. [02:05] Uploaded. [02:05] Man, this is the worst part of a new release. It takes forever for firefox to learn that "qu" means utopic/+queue instead of trusty/+queue [02:06] I just leave the tab open. [02:08] Man, we need better tooling for reviewing SRUs-that-are-syncs-from-PPAs. [02:08] RAOF: Yeahp. Or we need to give wgrant enough breathing room to fix the queue so syncs aren't opaque blobs of awful. [02:08] I keep thinking ectopic instead of utopic. [02:08] (It's in progress, just slow going) [02:09] ScottK: Rick made that same joke. [02:09] "utopic pregnancy". [02:09] No breathing for me for a while... [02:09] wgrant: Please keep breathing. [02:10] wgrant: But, seriously, I know you're being pulled in 17 directions. If there's any way we can push the queue stuff forward by leveraging any of your minions, or hiring infinite monkeys, it's a massive pain point for AAs. [02:12] A few months ago it was second on my list of big features. Now I can't even count :/ [02:12] wgrant: So, it's third, and you need more fingers? :P [02:15] ScottK: Looks like that needs more changes than just rules/postinst [02:15] I don't think so, but I'll look again. [02:16] ScottK: debian/control points everything at ruby2.0 [02:16] ScottK: The only one that's (accidentally) correct is ruby-all-dev, since it depends on both. [02:16] Good point. Please reject. [02:18] ScottK: Lots of (currently v2.0) in there too. [02:18] Yeah. Fixing that too [02:19] ScottK: (Also, you can probably drop the versioned deps while you're switching) [02:19] Already did [02:19] Well, not the ones for ruby-all-dev, but the others. [02:19] Right, I'll stop being annoying. :) [02:20] I should probably also add 1.9 into supported. [02:20] For now. [02:20] Should you? [02:20] I imagine the intent is to drop it. [02:20] We already defaulted to 2.0 for trusty, 1.9 should die. [02:21] Oh, no we didn't. [02:21] * infinity scratches his head. [02:21] 1.9.1 was default in trusty. Curious. [02:22] We had two in main. Bleh. [02:22] Yep. [02:22] Oh, but Debian's dropping it from trusted. [02:22] I'd just follow their lead there. [02:22] So I figure at least for a transitional period it ought to be supported. [02:23] s/trusted/supported/ [02:23] Yeah, but they've had 2.0 as default for awhile already. [02:23] Well, I assume that triggers which extensions get built. [02:23] So we'd just have to transition again after dropping it out to remove them all. [02:23] Maybe as well drop it now. [02:23] Normally for python we add the new one, rebuild shit, drop the old one, and build again. [02:24] Can transition twice if you'd prefer. [02:24] I guess since we're changing the default, it doesn't matter much. [02:24] Boosts the upload stats. :P [02:24] But I imagine dropping it will work fine. [02:24] Nah. I'd rather do it once and blame you if there's trouble. [02:24] Works for me. [02:24] I'll pass the blame to doko. [02:27] OK. Let's try this .... [02:28] * infinity teaches rmadison about utopic [02:32] ScottK: You missed some descriptions. Do you care? [02:32] I don't. [02:32] Heh. [02:33] I'll fix it if you'd prefer. [02:33] Nope, don't care. [02:33] It'll sort itself out if/when Debian moves anyway. [02:43] doko_: default ruby = ruby2.1 is done. [03:51] cjwatson: Alright, I put wgrant on 8 and 16. pitti's handling the ones with his name on them (35, 36, 44, 45) [03:52] cjwatson: I did livefs chroots for arm64 and ppc64el, and filed a ticket for the other 4. [03:52] cjwatson: I think we're still stuck on 19 until doko wakes up and gives his blessing. [03:52] cjwatson: And I didn't get to mangling debian-cd/cdimage, I've had an eventful evening away from work tonight. Maybe if I fail to sleep, I can tackle more things. [08:00] RAOF, hey [08:00] RAOF, thanks for looking at that ido bug [08:00] RAOF, I just commented on it, let me know if what I wrote makes sense to you [08:02] seb128: It does; I expect to approve ido at some point next week. Unless someone else gets to it first. [08:03] RAOF, ok, thanks [08:05] RAOF, you could maybe review nautilus in the SRU queue? ;-) [08:06] would be nice to get that one rolling because we are likely to get other segfault fix rounds following [08:43] our first upload into utopic was a poporietary package ?? [08:43] oh my [08:43] :) [09:32] infinity: yeah it does, i busted it. let me fix it up. [09:32] * xnox should automate build-depends mangaling as well, too error-prone [09:54] I get 404 on http://archive.ubuntu.com/ubuntu/dists/utopic/Contents-i386.gz but i guess that might still be normal? [09:54] / expected [09:55] probably not there yet :P [10:02] xnox: It generated last night but apparently isn't actually there. I wonder if there's a race with the publisher [10:02] (e.g. if sometimes it generates but drops the result into the wrong tree so that it then gets discarded) [10:14] doko_: Are you planning to upload your toolchain bits? [10:14] At least binutils [10:57] cjwatson, when do you plan to do the first image testbuilds ? this week already ? [10:57] * ogra_ needs to update some tools [11:00] ogra_: I'd like to get there before EOW, but can't say for sure yet [11:01] ok [11:01] just want to be prepared :) [11:04] doko_: ... uploading binutils for you now with mangled series [11:11] infinity: Should we drop block-all source around now? Anything in -proposed should be OK if it's a valid candidate, I'd have thought [11:11] infinity: Also, reminder to do the big copy from trusty-proposed [12:30] could someone reject the recent ubuntu-release-upgrader upload to trusty-proposed please? I think I will include another fix there [12:32] mvo, done [12:32] thanks seb128 [12:32] yw! === jhodapp|afk is now known as jhodapp [13:08] stgraber, hmm, you didnt move the devel/devel-proposed alias to utopic yet [13:18] Riddell: trusty-proposed will be copied in bulk to utopic-proposed fairly soon, fyi [13:18] cjwatson: oh ok I didn't realise that [13:24] ogra_: considering there are no images in those channels, I thought it'd be best to wait until we have something in them and confirmed it works before changing the alises [13:25] *aliases [13:25] stgraber, ok, just wanted to know if it was intentional [13:26] (makes sense to wait ... its is just that my tools are not multi-release aware, i have to point them somewhere, but can do that manually for the fist image) [13:26] ogra_: so I think we should wait to have a good build in utopic-proposed, have this promoted to utopic and then flip the aliases [13:27] yep [13:41] NewReleaseCycleProcess step 17 done, I think [13:59] I'll do ben shortly [14:02] cjwatson: please unblock binutils, boost-mpi-source1.55, boost1.55. All built and look happy. [14:03] xnox: I was hoping to get autopkgtest results for binutils [14:03] (that aren't lies) [14:04] cjwatson: the qualifier makes the difference =) [14:05] there are some results on the private jenkins: lintian is still running, and binutils passed on amd64 but hit a testbed error on i386 [14:38] cjwatson: Yeah, block-all source is likely not needed anymore. [14:38] cjwatson: Especially now that autopkgtests are back and happy, so we don't have to pick and choose carefully. [14:39] cjwatson: Oh, unless those results are, as you said, lies. :P [14:40] doko_: [14:40] dpkg-source: info: upstream files that have been modified: [14:40] binutils-2.24.51.20140417/ld/emulparams/aarch64linux.sh.rej [14:40] doko_: Is that a sign of a broken patch, or just that you had cruft in your package when you built it? [14:44] infinity, cruft [14:47] doko_: Kay. [14:51] cjwatson: britney reporting a pass on binutils despite the apparent i386 failure is disconcerting. Or is that passed on the private instance? [14:52] infinity: yeah, not sure what's up there, pitti was working on it [14:52] doko_: Can you double-check testsuite results for binutils on all arches and sign off on it? [15:03] infinity, meh, lp doesn't reply === doko_ is now known as doko [15:20] infinity, no regressions [15:21] doko: Excellent, thanks. [15:21] infinity: cdimage/debian-cd updated for utopic [15:24] hrm, I did 3 pocket copies from trusty-security to utopic-proposed (rsync, mysql-5.5 and python-django) a while ago, but now thinking that may have been a mistake [15:24] I think that's fine [15:25] assuming you copied with binaries [15:25] I did [15:25] ah, I see them in unapproved [15:25] https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text= [15:25] ok, sorry I jumped the gun there [15:25] no it's fine [15:58] xnox: So, are you still happy with the boost-defaults in the queue? Nothing needed fixing there to match your new boost uploads? [16:00] infinity: it should be all good. [16:00] xnox: Accepting, then. [16:00] thanks! [16:23] * mdeslaur pokes infinity for EoL announcement [16:26] mdeslaur: Yes dear. [16:27] * mdeslaur gives cookie to infinity [16:28] EU legislation requires your explicit confirmation to the acceptance of any cookies [16:28] * Laney confiscates it [16:28] om nom nom [16:28] lol [16:29] Laney: Neither of us are in the EU, you just violated Canadian sovereignty. [16:29] bah MiM attacks on IRC ! [16:29] Laney: The moose of punishment is on its way. [16:30] That'll go well with my cookie, thanks [16:31] Laney: I suspect you've ever met an angry moose... [16:33] I've never knowingly met any moose :( [16:33] WCPGW [16:34] Laney: Well, as you know, Canadians are kind and welcoming people. We achieve this by chanelling all our rage and anger in two directions: the moose population, and hockey. The Moose of Punishment plays hockey. Enjoy. [16:35] (PS: Now I want a cookie) [16:35] * whiskers75 gives infinity a cookie [16:35] a moose shaped one ? [16:36] A chocolate chip one. [16:36] ogra_: Hockey-puck-shaped seems like it would be easier to achieve. [16:36] heh [16:38] moose of punishment> now I'm reminded of the two toy seals Daniel Silverstone had at one point [16:38] Club the Seal, and the Seal of Approval [16:38] Kinnison is a strange fellow. [16:45] * whiskers75 meows at infinity [16:46] * Laney plays some moose polo [16:47] Why is makedev in trusty ubuntu-minimal? [17:04] xnox, legacy of dmraid or something like that ? [17:07] xnox: Why wouldn't it be? [17:08] xnox: It's been prio:required pretty much forever. [18:11] infinity: because makedev is obsoleted in favor of udev in Debian [18:12] slangasek: Well, your package depends on it. ;) [18:12] slangasek: (mountall) [18:12] yes, that's why upstart must die, long live systemd [18:12] [18:13] Poor upstart. [18:13] I think that dep dates back to Scott, it's been a minor annoyance that I have yet to take care of [18:13] hrm, sagari already used [18:13] Anyhow, it'll be gone by the next LTS, I suppose, so I'm not sure it's worth caring deeply about removing makedev from required right now. [18:14] doko: Doing a GCC upload? We can kill it and aim it at sagari when this kernel's done. [18:15] sure, waiting for it now [18:15] * infinity puts "powerpc VM buildds" on his TODO for the next week or two, too. [18:15] I wonder if I have the time to make that happen before autosync. [18:18] I guess I'll look at that after I find some breakfast and wake up. [18:19] I need to re-do all the ppc64el VMs with trusty final too, since they're all pre-ABI-bump still, and the upgrade path there is bordering on nonexistent. [18:20] Are all the build machines on Lucid or Precise? [18:21] saiarcot895: PPAs are hardy (don't ask), ia64 and sparc are lucid, i386, amd64, armhf, and powerpc are precise, and ppc64el and arm64 are trusty. Was that a confusing enough answer? [18:22] infinity: Yes. :) What's with the disparity? [18:22] the time they were created, maybe? [18:22] saiarcot895: The PPA thing is, like I said, a don't ask. The ppc64el and arm64 ones are obvious, they didn't exist in precise. [18:23] saiarcot895: And ia64 and sparc were dropped after lucid, hence they're not getting upgraded, and will disappear when lucid EOLs. [18:25] * infinity goes to find breakfast. [18:41] infinity, I killed ross while cancelling the GCC build [18:46] doko: Did you cancel too early? :/ [18:47] maybe. shouldn't I? [18:48] doko: There's a bug where you can't cancel until it's actually into dpkg-buildpackage. [18:48] It gets a bit confused. [18:51] ok, trying to avoid that in the future [19:58] infinity: does "eglibc still looks in /dev/shm" instead of "/run/shm" ? [20:01] xnox: That question didn't seem like a complete sentence... [20:02] infinity: does eglibc now default to using "/run/shm" (for whatever it may use that for) instead of "/dev/shm"? As per commented in the mounted-dev.conf upstart job that sets up /dev/shm to be symlink to /run/shm. [20:03] infinity: or do we want /dev/shm compat symlink still... [20:03] xnox: /dev/shm should probably never go away, IMO. [20:03] xnox: Why are you trying to kill it? :P [20:03] infinity: ok. [20:03] infinity: makesense in linux style "don't break user interfaces" [20:04] xnox: A decade of docs told people to use that path, even if I change glibc in Debian/Ubuntu, there's countless other bits of software I won't get to, not to mention 3rd party stuff I can't control. [20:06] (The irony here that is moved from /var/run/shm to /dev/shm 12 years ago, and now people have decided to move it back to /run isn't lost on me) [20:06] s/that is/that it/ [20:06] Haha =) [20:06] that is funny =) [20:06] xnox: Well, it makes sense, historically. [20:06] do we require devtmpfs? [20:06] ( i thought we did, by virtue of udev requirement) [20:07] The right place for state files was /var/run, but /var wasn't guaranteed to be on /, so we started dumping early-need stuff in /dev to compensate, and then /run happened to fix the problem. [20:07] Anyhow, not everyone is on the /run bandwagon, and I see no value in dropping the symlink pretty much ever. [20:08] yeah, yeah, agreed with you, will keep that bit. [20:08] i'll test openvz and lxc container and probably drop MAKEDEV usage from that job, and thus from mountall dependencies. [20:08] (well make a merge proposal to drop that) [20:09] xnox: Fair enough. Seems like a waste of time to care, since mountall itself will be gone by the next LTS, but whatever. :P [20:20] GAH. [20:20] cjwatson: germinate is exploding in the publisher. [20:22] wgrant: ^-- You were sad that everything went smoothly? [21:42] rc/l[ [21:45] hey, would anybody here know if https://launchpad.net/xubuntu-desktop/ carries any technical merit, or would it be okay to just remove that project? [21:48] no obvious reason to keep it around if you're not using it to host code or blueprints [21:48] Edubuntu has a similiar /edubuntu but we use it for some branches [22:01] ok, good [22:01] i'll get that removed :) [23:28] infinity: Hm, yes, reproduces with just "germinate -s ubuntu.utopic -d utopic --no-rdepends" [23:29] So hopefully that's debuggable tomorrow [23:30] cjwatson: Kay. It's halting archive-reports, due to the way we check if the archive has changed, but I suspect there's no other serious fallout. [23:36] doko: gcc-4.9/amd64 unsatisfiable Depends: libgcc-4.9-dev (>= 1:4.9.0-1ubuntu2) [23:36] Alarmingly, it's not actually clear that it's infinite recursion [23:36] doko: Looks like the real package doesn't have an epoch. [23:37] cjwatson: Oh, it might just be very, very deep recursion? [23:37] Just crudely tracing in pdb, it seems to be walking through a legitimately deep dep tree [23:38] Well, autopkgtest still seems remarkably buggered, so I'm in no rush to let open the world. [23:38] Though we could probably thaw the queue and just keep britney in block-all for now. [23:38] # TODO: would be much more elegant to reduce our recursion depth! [23:38] sys.setrecursionlimit(2000) [23:38] Hah. [23:39] cranking to 3000 makes it go away, LA LA LA [23:40] Make it 9000? We have a lot more CPU and RAM than we had when that was written. [23:40] And then get someone to do a production cowboy... [23:41] I don't want to overdo it, 3000 should be fine [23:41] Heh. [23:41] Are we using the packaged germinate in production? [23:41] Yeah but a backport [23:41] If so, turning around an SRU with that 1-char fix in a few hours wouldn't hurt my feelings. [23:41] Oh. [23:41] Oh hey, it's just 2.8 [23:42] Yeah, I don't see a backport there. [23:42] Unless it's not using the package. [23:42] It should be [23:43] Could you file a bug for me? [23:43] Yup. [23:45] cjwatson: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1312478 [23:45] Launchpad bug 1312478 in germinate (Ubuntu Trusty) "germinate's recursion limit is too low for utopic" [Undecided,New] [23:46] cjwatson: targetted for trusty and precise SRUs. I doubt anyone cares about non-LTS germinate sadness. [23:47] yeah [23:47] cjwatson: I wonder if we were literally just bumping up against the limit in trusty and something tipped us over, or if this is a sign of something going more deeply wrong. [23:48] I didn't trace the whole stack, but it didn't look horrible [23:48] And it finishes very quickly after I bump the limit [23:49] Might be worth throwing a counter in and seeing if ubuntu.trusty gets us in the 1900s or something. Cause if we've gone from, say, 800 to 2500, that would perhaps point to, if not a germinate bug, us creating a Very Hard to Sort dependency tree. Which could also anger apt's resolver. [23:51] mm, not tonight though [23:51] * infinity nods. [23:53] cjwatson: In lieu of trying to SRU in a hurry tonight, I might just get a GSA to cowboy your s/2000/3000/ fix in production, under the assumption that the SRU will just overwrite that in a few days. [23:53] Yeah that should be fine [23:53] But I'll do the SRUs shortly [23:54] Though I'd like to go to bed; indeed if I can do the SRUs tomorrow morning that'd be better [23:54] http://bazaar.launchpad.net/~cjwatson/germinate/trunk/revision/552 [23:55] Ta.