[00:00] "I've stopped using it, once it started to perpetually FTBFS with new monos" [00:00] Of course, some of this was because the 0.95.1-1 upload which fixed this sat in pkg-cli-apps git for 6 months waiting to be uploaded. [00:01] I probably responded that I'd fixed that. [00:01] Just hadn't shepherded it through to the distro :( [00:04] =((((((((( [00:05] * RAOF wonders what others think about a 0.95.1 “SRU” :) [00:06] RAOF: sorry, your project begins with "g" and "o", but there are too many letters in the middle for us to sign off on this SRU exception [00:06] and ends with "o", I mean [00:07] * xnox thinks of no SRUs for odoo -> yes! === doko_ is now known as doko [06:20] slangasek: ^ [06:55] cjwatson: ^--- And this one's for you. [07:04] infinity: there ya go [09:01] arges, RAOF: nvidia-graphics-drivers-* have been sitting in Trusty unapproved queue for some time now, would someone take a look, please? [09:52] soyuz rejected https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/1:3.5~svn213451-1ubuntu1/+build/6211716 and i don't understand why =( [09:53] https://launchpad.net/ubuntu/utopic/i386/clang-3.5 [09:53] oh. [09:53] right. [09:53] Yeah, that. [09:54] looks like doko synced over the top of your change [09:54] so then retrying wouldn't have worked [09:56] i think llvm-toolchain-snapshot should be removed then, no? [09:56] (until at least a 3.6 snapshot is available) [09:58] oh a different source is it [09:58] dunno [10:07] i guess it will just end up in nbs, cause llvm-toolchain-3.5 package version are >> llvm-toolchain-snapshot. [10:14] here it comes! [10:27] xnox, are you working on llvm-toolchain-3.5? [10:27] doko: yes, i'm compiling one on porter now. [10:28] xnox, please disable lldb on ppc64el [10:28] enabled gold, disabled lldb since clearly broken. [10:28] doko: yes =) [10:45] built, tests running & docs building === pete-woods is now known as pete-woods|lunch === pete-woods|lunch is now known as pete-woods [12:34] ^^^ please could somebody review this? [13:54] ginggs: i can take a look [13:58] infinity: ^- [13:59] Ta. [14:20] arges: thanks! [14:21] ginggs: so i actually started taking a look at it, I'm not much of an expert on nvidia packaging etc. Reading up there was some concern about multi-arch aware issues, is that still a problem? [14:22] ginggs: and also should bug 1317528 be a duplicate of 1247736 ? [14:22] bug 1317528 in nvidia-graphics-drivers-331-updates "Packages nvidia-libopencl1-... don't provide libopencl-1.1-1 and libopencl-1.2-1, making some packages uninstallable" [Undecided,Confirmed] https://launchpad.net/bugs/1317528 [14:24] arges: no, we need to add libopencl1-1.1-1 at some point, but right now there is nothing in the archive that needs libopencl-1.1-1 to be installable [14:26] arges, ginggs: while you are at it ... there is acomponent mismatch in this package, bumblebee [14:30] doku: i don't follow [14:36] doko: i wish i knew more about nvidia/bumblebee stuff, but I was merely reviewing the nvidia-graphics-drivers-* update in the SRU queue : ) [15:18] can someone explain to me why the mongodb upload I did for utopic is still in proposed? it looks OK from the migration_excuses report... [15:18] excuses is just stage one [15:18] update_output.txt says: [15:18] trying: mongodb [15:18] skipped: mongodb (30 <- 34) [15:18] got: 39+0: i-39 [15:18] * i386: mongodb, python-loofah [15:19] meaning "the new version is uninstallable" (and so is python-loofah, but that's probably just because it Depends: mongodb) [15:20] Quite why that is I'm not completely certain [15:22] cjwatson, ah [15:26] jamespage: mongodb 1:2.6.3-0ubuntu3 depends on mongodb-dev, which was built by mongodb but is no longer, and doesn't exist in utopic-proposed. I'm not sure if that's intended; could that be your problem? [15:27] Or would mongodb-dev end up NBS but still in Utopic? [15:28] Oh, mongodb-dev went away? Right, that would explain it [15:28] While a migration would cause NBS to remain until manually cleared, proposed-migration defaults to assuming that all NBS are cleared when calculating its answers [15:29] Useful to know - thanks [15:29] Occasionally we'd override that. Generally I prefer not to === charles_ is now known as charles [16:02] cjwatson: hey, how does the urgency field affect uploads in Ubuntu? i'm reviewing a package (nova) where the patch modifies the urgency from medium to high... should i reject and ask for it to remain the same? [16:06] arges: negligible [16:06] arges: it gives a tiny build score bump. Each urgency is per upload, so only the top one matters. The default these days is medium. [16:06] it makes like a tiny difference to the build priority [16:06] I don't see why you'd patch this, though [16:07] The urgency is per-changelog-entry [16:07] You wouldn't patch an old one [16:07] i guess from an SRU perspective should I ask that it be changed back to 'medium' before accepting? [16:07] no [16:07] as long as it's an entirely new changelog with urgency=high, who cares [16:07] I might whinge about patching an existing changelog entry [16:07] yea, its only in the new entry [16:07] I've uploaded SRUs with urgency=critical [16:08] arges: So, if it's in the new entry, it's not being "changed", that's just the urgency set for that specific upload. [16:08] arges: Nothing wrong with that, even if it's a feature LP users almost never use. [16:08] Ok [16:08] thanks! === psivaa is now known as psivaa-bbl [16:35] I'm pushing the freeze block a bit earlier than I said because I'm going out for dinner here at GUADEC [16:35] no skin off my nose, we got libav in ;-) [16:36] I got the migration emails - good work :-) [16:38] update_output is in danger of making sense again [16:40] respins going [16:40] stgraber: I forgot if I have to update the manifest or not [16:40] looks like rebuild-requests does everything in parallel - good [16:42] stgraber: Would you be able to do that for me if so? Nobody replied so assuming the same as A1 [16:42] * Laney is off, ttyl [16:57] Laney: if it's the same as a1, no changes are needed to the manifest === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [17:44] that's some rapid-fire NEWing [17:44] is that intentional? [17:45] I don't know about qtmir/qtmir-gles. For binaries I routinely wave through new binaries from Debian syncs [17:45] With basically just a cursory override check and a bit of automation to ensure they're really from Debian [17:45] right [17:46] baloo-kf5, python-idna, qtmir were accepted near-simultaneously though [17:46] and were not Debian syncs [18:31] Any idea why http://changelogs.ubuntu.com/meta-release-lts hasn't been updated with 14.04.1? [18:33] Prolly everyone's asleep, hoping someone will pick the message. [18:37] teward, mhall119: Pinging you to make sure someone gets the message, you're one of the few faces familiar to me here. Please look at it when you guys wake up. === Ursinha-afk is now known as Ursinha === psivaa-bbl is now known as psivaa [19:07] thanks phanimahesh, I'll poke somebody about it [19:10] is anybody around to force unity-system-settings through despite the arch regression? [19:14] ubuntu-system-settings [19:14] FWIW ↑ this only worked before because there was a missing Depends that would have caused this to happen some time ago already [19:15] and the reason is it depends (indirectly) on Mir, which is not available on the other arches [19:15] mhall119: nm, was doing routine sysadm tasks planning to upgrade and found that my servers aren't detecting new lts release. That led me there. [19:15] Thanks. :) [19:19] kgunn, our hands are tied, we need someone here to pick this up, /me logs off for dinner, back later to a hopefully resolved situation [19:22] Saviq: ta [19:22] and thanks for pointing out === Logan__ is now known as Logan_ [19:30] stgraber, slangasek: anybody around? ^^ [19:36] phanimahesh, mhall119: http://changelogs.ubuntu.com/meta-release-lts hasn't been updated because we're awaiting infinity's confirmation that we're ready to enable the upgrades === Guest83948 is now known as Adri2000