[00:01] infinity: see, now I'm trying to decide if I think a package in the demotions list having an Ubuntu delta is an argument /for/, or /against/ keeping it in main [00:02] "someone touched it; which means it's high maintenance; let's not keep it in main where we might be expected to do more work on it than what we otherwise need to for keeping the packages we actually care about running" [00:03] vs. [00:03] "someone touched it; so we care about it; so let's promote that" [00:04] slangasek: I lean more to the latter, obviously, but... [00:05] infinity: some of these stacks I'm going to go ahead with demoting, though - java builddeps, extra copy of automake, the perl stuff. Yes perl is low-touch, but it also has high dep churn which accounts for there always being stuff in c-m for it, and we really don't promote perl [00:05] slangasek: Yeahp, all that seems fine. [00:06] slangasek: Pretty much anything that counts as language modules/extensions/bindings is fair game, IMO. [00:06] slangasek: Anything in the language list we care about should be caught by runtime deps. [00:06] If we're not using a binding, I can't see why we'd encourage users to. :P [00:06] dpatch [00:06] goodbye, dpatch [00:07] Oh, that reminds me, I can sync lintian. [00:07] What a glorious day. [00:10] I've had that stupid delta for too long now. [00:14] slangasek: Oh, before you get lost in a childlike glee, frolicking in the wonderland of demotions, care to review/accept the librtas sync? [00:14] eeeheHEEheehee [00:14] sure [00:15] libid3tag is owned by the kernel team? wut [00:15] slangasek, so if archive reorg is in, I assume there is no need for y pypy FFe? [00:16] doko: Not if it was for a build-dep. [00:16] um [00:16] FF applies to things whether or not they are seeded [00:16] this is https://bugs.launchpad.net/bugs/1564088 [00:16] Launchpad bug 1564088 in pypy (Ubuntu) "FFe: update to pypy 5" [Undecided,New] [00:16] Err, oh. FFe. I read that as MIR. [00:16] That said, pypy is on the source demotion list, so yay to that. :P [00:17] \o/ [00:20] tumbleweed, doko: Can someone give a more clear idea of what a new PyPy upstream release actually means, in terms of potential breakage, millions of lines changed upstream, whatever? [00:20] Or... Someone could accept it? [00:20] already done. I took your answer as an ok [00:21] doko: [00:21] 18:16 < infinity> doko: Not if it was for a build-dep. [00:21] 18:16 < slangasek> um [00:21] 18:16 < slangasek> FF applies to things whether or not they are seeded [00:21] 18:16 < infinity> Err, oh. FFe. I read that as MIR. [00:21] infinity: the diff is big [00:21] infinity, we don't rely on it. we just build one more python variant [00:21] infinity: http://morepypy.blogspot.com/2016/03/pypy-50-released.html http://morepypy.blogspot.com/2016/03/pypy-501-bugfix-released.html [00:22] doko: Sure, but we rely on it not breaking its r-build-deps. Can you do a quick mini-rebuild-test in a devirt PPA with the -proposed pypy and the return from $(reverse-depends -b src:pypy)? [00:22] doko: there is a feature freeze, which applies to all packages in the archive, and you are not on the release team; you should not be self-accepting from the unapproved queue [00:23] infinity, tumbleweed already did that, but I can do that again once it's built [00:25] infinity: that it is now building with itself (on archs with JIT) is probably a bigger statement of stability, than building anything else. If there are regressions in reverse-deps, they are likely on big endian platforms. Good news is right now there are still very few reverse-deps [00:27] go 1.6.1 is going to be released on april 13 apparently [00:27] does that give us enough time to get it into the archive and rebuild the things that need rebuilding before release? [00:27] seems a bit tight but... [00:27] tumbleweed: I count 21. So, yes, not a lot, but still worth making sure iz all good. [00:27] mwhudson: No. [00:28] infinity: drat [00:28] mwhudson: Anything that's on images absolutely can't be rebuilt in that window, since final images *should* be produced on the 13th or earlier, if all goes well. [00:28] infinity: ok, i'll upload the fix now then i guess [00:28] mwhudson: And half-rebuilding is likely worse, from a paperwork perspective. [00:29] slangasek: If golang-1.6 was slated for demotion until you seeded it, we have a bug. [00:29] infinity: yeah, i knew that there was a day where the images should have been made but i didn't know when it was [00:29] slangasek: (base)adconrad@nosferatu:~$ apt-cache show lxd | grep Built-Using [00:29] Built-Using: golang-1.6 (= 1.6-0ubuntu4) [00:30] infinity: do you have or know how to make a list of "go things that are on images"? i think it's just lxd but i certainly don't know [00:30] slangasek: I knew we'd fixed that on the dh-golang side (thanks, mwhudson), so I was a bit confused by your statement. [00:30] mwhudson: If you have a list of all things you need to rebuild, "seeded-in-ubuntu $thing" will give you the answers. [00:31] infinity: mdeslaur is getting me that list apparently :-) [00:32] slangasek: And, indeed, gccgo-6 also wants to demote, and it should be in the built-using for the powerpc binaries of lxd. [00:32] slangasek: So something's wrong here. [00:33] infinity: hmm. which version of lxd are you looking at? [00:33] was that fixed in -0ubuntu2 binaries or only in -0ubuntu3? [00:34] infinity: it appears to be fixed only in -0ubuntu3, so if I was looking at a !proposed report, it would still have shown [00:34] (base)adconrad@nosferatu:~$ apt-cache show lxd | egrep '^Version|^Built-Using' [00:34] Version: 2.0.0~rc9-0ubuntu2 [00:34] Built-Using: golang-1.6 (= 1.6-0ubuntu4) [00:35] Was fixed quite a while ago... [00:35] ok, I don't know *what* version I'm looking at here [00:35] apparently I have very outofdate sources [00:36] infinity: ok yes, I see it in 2.0.0~rc9-0ubuntu2 [00:37] infinity: I mean when in the release cycle as I was thinking about using that type of URL for bug 1535098. [00:37] bug 1535098 in ubuntu-release-upgrader (Ubuntu Xenial) "Uninformative link in Release Notes window" [High,Triaged] https://launchpad.net/bugs/1535098 [00:39] bdmurray: The ReleaseNotes page tends to get a skeleton put up pretty early. It could be day of opening, if you need that, though. [00:39] (It would be mostly empty, but that's fine) [00:40] infinity: however, I do *not* see gccgo-6 in the demotions list? [00:40] only gccgo-5 [00:41] infinity: were you deliberately creating a justified debian/changelog? :) [00:42] "* [Drop] liboftd1 and libofdt-dev from debian/* as upstream removed it." well since upstream removed /them/, I assume that you were doing this deliberately [00:45] infinity: is the difference between the requested librtas 1.4 and the uploaded librtas 2.0.0 the library versioning fix? [00:47] slangasek: Yeah, plus bugfixes pushed upstream by me. [00:47] slangasek: (All of which we already carried in patches) [00:47] infinity: accepted [00:48] slangasek: As for libofdt, it has/had no rdeps, so seemed sane to get the upstream dropping into the LTS, so we didn't have 5 more years of people tempted to link to it. ;) [00:48] infinity: agreed [00:48] infinity: Unfeature Freeze Exception granted [00:56] slangasek: Ta. [01:37] ^^ unblocks the oldest dep-wait in xenial-proposed, if anyone wants [09:07] Laney, superm1 - ^ [09:30] cjwatson, thanks for fixing up germinate. i now see what you meant. thanks! [10:03] sbeattie, slangasek: hey guys whose the best person to talk to about sb-setup? [10:47] stgraber, well, live-build/ubuntu-core/hooks is clearly a snappy path ... and i also mention the snappy os-snap in the changelog text ... the --initramfs-compression=none option is to work around a bug in live-build where it blindly compresses every initrd file in /boot it finds, infinity is on that one ... kind of unfortunate that you let in the initramfs-tools-ubuntu-core without the livecd-rootfs changes :/ === darkxst_ is now known as darkxst [12:04] stgraber, i'm a bit unsure what to do now, i need this change to move on with other work, do you want me to uncommit and overwrite the livecd-rootfs change for another changelog line about --initramfs-compression=none ? [12:24] Err:15 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages [12:24] Writing more data than expected (9539746 > 9539732) [12:24] Fetched 15.4 MB in 2s (6504 kB/s) [12:24] Reading package lists... [12:24] E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/universe/binary-amd64/Packages Writing more data than expected (9539746 > 9539732) [12:25] cjwatson, ^^^ any idea what that is ? i see it on the amd64 livefs builder for snappy rootfs builds [12:31] ogra_: see #ubuntu-devel [12:32] oops, i'm blind, thanks :) [12:32] should be fixed fairly permanently for xenial later today [12:32] interesting that only amd64 exposes it though [12:33] my other images built fine [12:33] shrug [12:34] I could spend hours debugging a timing issue or I could finish getting the fix rolled out [12:34] and it will almost certainly be a timing issue [12:34] yeah, i didnt mean to ask you to research it ... just a curious fact :) [12:35] the builds will have happened at slightly different times [13:29] Saviq, ^ [13:29] xnox, w00t :) [13:29] thanks a bunch [13:29] * xnox waits for next bot message [13:30] doko, ^ merged boost build, after that builds we can drop boost-mpi-source [13:31] granted that was simple s/WITHOUT_MPI=yes/WITHOUT_MPI=no/ and regenerate control [13:34] pitti: would you have time to binNEW review https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-050/+sourcepub/6280693/+listing-archive-extra still today? qtdeclarative5-ubuntu-ui-toolkit-plugin was renamed to the qml-module-* naming scheme so that transitional packages could be dropped after 16.04 LTS. the 4 QML modules inside the old package were split to separate binaries. additiona [13:34] lly libubuntutoolkit5-private-dev is new. [13:34] Mirv: err, PPAs don't have binNEW.. [13:35] and it's not in xenial's new (https://launchpad.net/ubuntu/xenial/+queue?queue_state=0) [13:35] Mirv: so what do you want me to do? [13:35] pitti: train bypasses binNEW queue, so we have a deal we must request binNEW review by an archive admin before hitting publish button. it's also mentioned at the top of the diff https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1095/2016-04-04_04:48:47/xenial/ubuntu-ui-toolkit/packaging_changes.diff [13:35] pitti: treat the new binary packages in that PPA as if they were in xenial queue. [13:38] Mirv: qml-module-ubuntu-layouts is one such package I think; it's missing a Breaks: qtdeclarative5-ubuntu-ui-toolkit-plugin (<< ${source:Version}) [13:41] pitti: right. it wouldn't be enough that the transitional package unconditionally depends on all the four qml-module-*, all four have Replaces: and one of them (qml-module-ubuntu-components) has also Breaks:? [13:41] Mirv: is it on purpose that qml-module-ubuntu-components does not depend on the new qml-module-ubuntu-layouts? [13:41] pitti: yes, the components doesn't necessarily need layouts, while it does need performancemetrics [13:42] Mirv: Breaks:+Replaces: is the standard dpkg way to declare that files have moved, yes [13:42] Breaks: is missing for the other split out qml-module-* apparenlty too [13:43] pitti: yes, as I mentioned, the rest three have only Replaces [13:43] (four) [13:43] all split out packages are missing it, only the renamed qml-module-ubuntu-components has it [13:44] pitti: the components has Breaks, the qml-module-ubuntu-test + qml-module-ubuntu-layouts + qml-module-ubuntu-performancemetrics (three) have just Replaces [13:44] * pitti wants a diff | remove-wrap-and-sort-noise [13:45] pitti: wrap-and-sort both ends of the diff? [13:45] rbasak: err, wrap-and-sort works on a diff? I thought it only works on a source tree [13:46] Ah, I see your point. I didn't connect it with queue reviewing. [13:46] Mirv: ok, the rest looks good to me [13:46] rbasak: ah, I could find and download both sources and mangle them both, but that feels a bit error prone [13:46] (and also much effort) [13:46] pitti: thank you a lot for the review. so, http://paste.ubuntu.com/15687913/ would be good enough? [13:47] Mirv: yes; in theory it should also work without the Breaks:, but I'd feel better if we play it by the book [13:48] pitti: ok, thank you! [14:21] pitti: Replaces without Breaks or Conflicrs is dangerous, because it lets you get into a situation where you can remove files entirely. So, the "book" exists for a reason. ;) [14:21] (Install A, install B (overwrite files from A), remove B, A is still configured, but missing files) [14:22] infinity: right, hence my insistance of adding it :) [14:29] davmor2: by sb-setup you mean Secure Boot? you probably want cyphermox or myself [14:29] hello? [14:31] slangasek, cyphermox: yeah so sb-setup is playing up on xenial in the end I had to do a trusty install to setup the microsoft keys. The script doesn't seem to have access to /sys/firmware/efi/efivars or something like that off the top of my head which seems to be a recurring issue looking at the 5 digit bug reports from trusty etc [14:33] slangasek, cyphermox: I'm pretty sure it did work on xenial earlier in the release though but I could be dreaming [14:33] davmor2: oh, you're talking about a script for secureboot setup of vms? I don't know about the script you're using then [14:33] ah, vm stuff [14:34] davmor2: the same from ubuntu-qa-tools? [14:34] slangasek: well I saw you and sbeattie on previous bugs hence pinging the two of you first :) [14:34] cyphermox: that is the one I'm using [14:34] let me grab the links [14:34] ok [14:35] cyphermox: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/head:/notes_testing/secure-boot following the steps for microsoft keys from here https://wiki.ubuntu.com/SecurityTeam/SecureBoot [14:37] stgraber, so is theer any chance for me to get that livecd-rootfs approved, i really need to alnd the onther changes (and get usable imaghes again now that initramfs-tools-ubuntu-core dropped the package i mention uin the livecd-rootfs changelog) [14:38] *need to land the other ... geez my typing [14:39] ok, we know it's late, but what's the release team opinion on https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1552424 being doable or not? awe got the n-m update done and it seems to work for the few of us who tested it (there was an issue when ofono was active that has a fix now) [14:39] * ogra_ really didnt üplan a fridayish nightshift :( [14:39] Launchpad bug 1552424 in network-manager-vpnc (Ubuntu) "[FFE] NetworkManager 1.2-beta" [Undecided,Confirmed] [14:39] stgraber, infinity, slangasek, pitti, ^ opinions? [14:40] cyphermox said he could sponsor/landing the update today if it's acked [14:41] ogra_: Lemme look at it. [14:42] ogra_: Can you commit your changes? [14:42] infinity, thanks ... i'm happy to add an addendum to the next upload for the --initramfs-compression=none if required (which seenms to be what stgraber complained about) [14:42] infinity, the next set you mean ? [14:42] ogra_: No, the current upload. [14:43] did i forget to push ?!?! [14:43] damn [14:46] infinity, pushed [14:47] * ogra_ hugs infinity [14:50] argh ... please reject the next one ... typo [14:58] * ogra_ has a re-upload ready [14:59] you can upload already [14:59] then the version would clash [14:59] nein [15:00] not in the queue [15:00] but someone rejected it anyway [15:00] yeah [15:02] better :) [15:02] Self-accepting d-i be, just a kernel ABI bump.[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D before I run off [15:05] infinity, ta [15:15] lolz [15:26] seb128: do we haz a go yet ? ;) [15:26] cyphermox, no, no reply from r-t :-/ [15:27] and then my question is, did anyone try running the autopkgtests yet before we upload? just in case there's an obvious failure? [15:27] I didn't [15:28] but I'll kick it off now from awe's PPA [15:30] on the bright side, I think I have a decent-ish hack to handle the swap creation [15:33] xnox: http://launchpadlibrarian.net/252853765/boost1.58_1.58.0+dfsg-5ubuntu2_1.58.0+dfsg-5ubuntu3.diff.gz [15:33] xnox: is the archive reorg in place now/ [15:33] ? [15:34] pitti: yeah, slangasek turned it on yesterday [15:34] pitti: we did the same to php7.0 yesterday [15:34] ah, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg looks quite a bit cleaner now [15:35] pitti, yes [15:38] seb128: sorry, was in long meeting (together with the rest of the foundations team); probably easy enough to test eth, some wlan, and vpn; but interaction with modemmanager and 3G sticks/cards is quite a bit more hairy, how muc testing did those get? [15:39] pitti, unsure, I've asked awe to join the channel [15:39] he started by updating to 1.2 for touch [15:39] hm, we have not one but two PPAs [15:39] yeah, it's a bit chaotic [15:40] this seems like a giant step to mission-critical infra at this point, and the doors close next week.. [15:40] it was left over for a month since cyphermox had other priorities [15:40] yeah :-/ [15:40] I though it would be done during my vac [15:40] when we discussed this a month ago, it sounded liek this was prep work for y, and not a goal for x [15:40] but didn't [15:40] well, touch team really need/want it, so they are going to get it in their overlay [15:40] pitti: I did do a quick test, and I otherwise have hardware to test it [15:41] and the ffe bug seems to have cyphermox/awe/stgraber agreeing it would be good to get in the LTS [15:41] it's indeed late at this point [15:41] I just granted the FFe btw [15:41] unsure what's best [15:41] stgraber, thanks [15:41] cyphermox, ^ go crazy ;-) [15:41] seb128: well, NM is primarily a desktop thing, so if cyphermox and you are happy about it and want it, I have no reason to veto it other than being cautious [15:41] it makes me nervous [15:41] but since the stack holders seem to agree it's a good idea I tried to help pushing it [15:41] I still find it very risky this late but I think we would come to regret not having 1.2 in the LTS just from a maintenance point of view down the line [15:42] well, NM itself doesn't appear to be that much maintenance intense really [15:42] given that it's "just" mostly glue between kernel subsystems, plugins, and drivers (which is where the hairy bits are) [15:42] but new plugins, changed plugin APIs etc. sound more risky [15:43] pitti: well, the state of VPNs pre-1.2 kinda sucks and we've had corporate users complain for quite a while, 1.2 finally fixes that API [15:43] I don't mean that there isn't a lot that can go wron wit the update, jsut that it shouldn't be very hw specific in general [15:43] stgraber: ah, that sounds like another good reason to upgrade then [15:43] anyway, I would absolutely have liked this to be done before the beta so we could have had proper user testing and think it's terrible that we have to land it so late [15:43] just don't break the Canonical VPN :) [15:44] pitti: Canonical VPN was tested :) [15:44] yeah, I tested it as well today [15:44] rolling back this entire stack would certainly be an interesting exercise :) [15:44] wow, 5 months and not much happened on the desktop, and now is when all the new shinyness comes in :-) [15:44] stgraber, agreed :-/ [15:44] so I expect everyone involved to take a very close look at bugs and IRC comments post-upload and keep on top of those issues as broken network on a release media is a major problem and would be very very bad for an LTS [15:44] (mostly kidding of course, TGIF) [15:44] +1 [15:45] call for testing/feedback on u-devel@ might also be a good idea [15:45] definietley [15:45] people with USB sticks, tethering, etc. [15:45] I'll certainly test tethering and VPN, but I figure many people can/will do that easily too [15:46] beyond that, I don't really have more exotic hw [15:46] I already used wired tethering and VPN [15:46] which VPN? [15:46] just openvpn? [15:46] openvpn and vpnc [15:46] k [15:47] cyphermox: ah; I've never tried bluetooth tethering, that sounds like a nice thing to play with too [15:47] anyway, let's keep an eye out for bugs then [15:47] I can give that a try... by default, does BT tethering use PAN or DUN now? [15:47] cyphermox, awe: thanks for your work there! [15:47] np [15:47] I'll test weird OpenVPN when this lands, since I'm on an IPv6-only network with IPv6-only VPNs :) [15:48] I figure that FFE also applies with tracking the next snapshots up to 1.2 final [15:48] (which we certainly should do too then, as SRU for the remaining ones) [15:48] we *really* need this to land on the phone, and I wasn't looking forward to having a non-ubuntu version land there [15:48] pitti: yeah, it does and I certainly expect any upstream change to be uploaded immediately so we can keep the final delta as small as possible [15:48] k [15:48] we're at rc1 [15:49] I expect final within the next few days [15:49] ( if not today ) [15:49] I need to test hotspot on the phones again this afternoon [15:49] well, we're going to upload pre-final, and worst case SRU futher bug fixes later [15:49] I'll do that right after lunch [15:50] yeah, 1.1.93 -> 1.20 seems like a reasonable SRU [15:50] (if it doesn't get released by next Tuesday or so) [15:50] ok, sounds ok to me too [15:50] 1.0.4 -> 1.2 would not be an SRU OTOH [15:51] so if I won't get any network on Monday morning, you'll find me at a beach with a basketball court [15:51] ;)- [15:51] * pitti waves good bye, time for meeting some friends and have dinner [16:45] slangasek: poke about juju uploads. there's a fresh 1.X in the NEW queue and I don't think you need any more answers on 2.0? [16:45] mgz: hi - sorry, I didn't get very far with it yesterday. It's front and center for me today [17:40] slangasek, awesome. BTW, in response to those build depends not needing to be in main -- are we ok with leaving them in universe? And thus, per your concern around https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913/comments/20, we don't even need to pursue including those golang depends in main right? [17:40] Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] [17:45] infinity: when you're back; roaksoax would probably need a respin of the server image so sabdfl can test the two new MaaS options added to the boot menu [17:45] we just added maas-*-udeb that was missing in server-ship [17:46] was there some other thing to update from the updated seed? [17:47] or slangasek: ^ [17:52] balloons: they can't remain in universe; we don't put build-deps in main anymore, but we do pull built-using into main, which covers the golang-embedded-code case. However, I saw rick_h_'s reply on the bug saying that he thought these were covered by the split out of bundled code into separate source packages so they may not need an MIR but I need to confirm from the source that these were pre-e [17:52] xisting bundled code as opposed to newly-introduced deps [17:53] slangasek, so should we give teams time to choose what do explicitly seed before we remote the packages? [17:54] cyphermox: not sure what you're asking re: seeds, sorry; are you just asking if there are other pending seed changes that would be pulled into a respin? I don't know if there are or not, but that shouldn't impact whether you respin AFAIK [17:55] doko: the suggestion from infinity yesterday was that we get two sets of eyeballs to sanity check the things we're demoting, for anything that we might know we want to keep. I'm ok with that for the hard cases, and have been gleefully demoting for the easy cases (i.e.: tex, python2, perl, java, and extra C libraries). [17:55] slangasek, yes they are pre-existing, and it's what we worked out with Jamie so as to not introduce a bunch of new packages this late in the cycle. However, I'm confused. Reading the annouce from earlier, my assumption is our golang depends can now go into universe next cycle, and we can add them as build-depends then for juju. This will make development much easier. Correct? [17:56] So I'm confused when you say "they can't remain in universe" [17:56] doko: beyond that, I don't think we need to give teams a set time [17:56] ok [17:57] slangasek: sorry no, I'm asking if there's any other thing (like a metapackage update) that needs doing for server-ship to apply to a respin [17:57] balloons: ok, so what was just announced is a change so that packages *only* used at build-time for other packages in main do not need to be in main. However, this doesn't apply to any golang build-dependencies, ever, because the code is statically linked at build time [17:57] balloons: which means that those packages need to be part of what the security team supports (== in main) [17:57] cyphermox: ah, no - server-ship is taken "directly" from seeds [17:58] ok, I thought so, I just got afraid I was forgetting something [17:58] slangasek, :-( You got me super excitied by the annoucement. Hmm [17:58] I'll merge roaksoax's seed change now, and we can respin shortly [17:59] balloons: all your build-deps still result in code running on end users' systems when they install packages from main, no free pass for you ;) [18:00] slangasek, yes, you are technically correct. But in theory, the resulting codebase could be blessed by security, removing the need to pull all those golang depends into main eh? That's a bigger discussion, and I won't sidetrack the work now [18:01] balloons: ok, in theory the Security Team could completely reverse their position on golang code bundling, but I don't think that would have anything to do with the archive reorg change, either way ;) [18:01] slangasek, anyways, thanks for the explanation. Still, the announce is good news for many folks [18:01] :-) [18:03] hello! sorry for nagging but I'd like to request a set of eyes on FFe bug #1561762 again [18:03] bug 1561762 in apparmor (Ubuntu) "[FFe] AppArmor 2.11 Beta 1 for policy namespace stacking and bug fixes" [Critical,New] https://launchpad.net/bugs/1561762 [18:03] tyhicks: I can have a look just as soon as I complete a feedback cycle for juju 2.0 [18:03] thanks slangasek [18:04] tyhicks: (which is measured in hours, not minutes or days) [18:04] slangasek: ack - not a problem [18:22] why does ubuntu think it is 18:21 in london and not 19:21? [18:22] * xnox is being trolled by indicator-datetime [19:31] balloons, rick_h_: MIRs for universe build-deps: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1545913/comments/23 [19:31] Launchpad bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] [19:41] slangasek, thank you. I will file the MIR's; as Jamie notes, it sounds like they can be given a less time consuming review, so presumably this doesn't extend the time required for juju to get in by much [19:41] balloons: as I said in the comment, the MIR can happen in parallel, but should be done ASAP so that we can promote the deps to main prior to release [19:41] slangasek, ahh, so you won't hold juju itself being accepted into main atm? [19:42] balloons: I will not, there's no need to [19:42] still reviewing the rest of the packaging (which I should be done with imminently), but the build-deps don't block the FFe [19:43] slangasek, that's very gracious, thank you. I'll make sure the MIR's get reviewed asap [20:04] infinity: you around? [20:08] awe: seb128: ^ [20:15] balloons: ./usr/bin/juju-upgrade-mondo [20:16] balloons: we should probably upgrade that by 3 to mongo instead? [20:16] lamont: Yeah. [20:16] slangasek, yea, mongodb is a sore spot for debian/ubuntu as a whole, and juju is wrapped up in that [20:17] balloons: I'm pointing out the spelling error in the symlink which will probably cause the command to not be found ;) [20:17] slangasek, ohh, heh [20:17] :-) [20:17] "upgrade that by 3" --> d,e,f,g [20:19] infinity: thoughts on my distro-info? you gonna track me down and hurt me if I upload it? [20:25] interestingly enough, grep shows that's not the only place someone has made that mistake [20:26] outside of that repo / package though [20:26] lamont: Maybe. :) [20:26] infinity: ack [20:26] I'll get back to you on that pain vs reward thing [20:28] juju-upgrade-mambo [20:43] slangasek: ARGH. [20:43] infinity: ? [20:43] slangasek: I now have "juju loves mambo" stuck in my head. [20:43] hahahaha [20:45] * knome facepalms [20:51] can anyone take a look at my lxd upload, pretty trivial packaging fix/improvement [20:52] stgraber: Yep. [20:53] * stgraber looks at NM [20:58] oh, crap I hadn't thought of this [20:59] cyphermox: "this"? [20:59] ^ n-m-*vpn* will ftbfs for now, until NM lands [20:59] ie. that openvpn that was accepted [20:59] Oh. Yeah, I took it as a given that they should have happened together. [20:59] cyphermox: well, you know the penalty for causing a FTBFS in launchpad [21:00] Does it involve wet noodles? [21:00] I get to fix it? ;) [21:00] oh, maybe you don't know [21:00] topic then? [21:00] cyphermox: you get email every time doko hits the retry button, obviously ;P [21:00] haha [21:00] That only happens about 30 times before doko switching to bugging you on IRC. [21:01] :) [21:02] hmm, I think that's the first time I see this, what does "" mean in debian/control? [21:02] google is being pretty unhelpful [21:02] xnox: is there a removal bug for boost-mpi-source1.58 ? [21:02] stgraber: if building with DEB_BUILD_PROFILE=nocheck, this build-dep should be omitted [21:02] or is it DEB_BUILD_PROFILES? [21:03] stgraber: anyway. it's build profiles. Wanted for archive bootstrapping, and has been generalized [21:03] Built-Using header[5]. (This is an uncommon case; the vast majority of [21:03] the affected packages are written in go [21:03] slangasek: Hahahhaa. [21:03] slangasek: interesting, thanks [21:03] slangasek: No, the vast majority of those cases (not including static inclusion from gcc itself) would be boost. :P [21:04] slangasek: And I don't think anyone's ever proposed properly caring about that. [21:04] cyphermox: I would just like to point out that this diff is absolutely insane :) [21:04] infinity: ah, well. boost is in main (now completely), so [21:04] stgraber: upstream diff? [21:04] infinity: but I do see libiberty on the demotions list right now, somebody should fix some packaging somewhere [21:04] cyphermox: the diff from current nm to new nm, 6MB large when compressed :) [21:04] yeah :/ [21:05] anyway, packaging changes look plausible and the upstream code was tested, so I'll let that stuff in :) [21:08] stgraber: again, I am sorry you had to see this [21:09] cyphermox: well, the debian/* diff was actually okay, just took a while to filter things, then look at upstream changelog and assume that it's not lying because reading through the actual upstream diff would have taken ages [21:09] yep [21:11] balloons: so, why does this juju-core 2.0 not build-depend on golang-github-lxc-lxd-dev ? [21:12] slangasek, when we first made this package, it didn't exist in the archive. I have the initial list I shared with Jamie about what depends we have and where they are. Some for instance, do exist upstream, others were in the xenial proposed queue at the time. [21:13] upstream, as in debian [21:13] balloons: ok, so that package does exist now, is in main, and is there expressly for juju's consumption (per stgraber). I won't block the FFe on this but this should definitely get fixed for release [21:13] balloons: that -dev package has been in the archive for the past 4 months :) [21:14] (added on December 10th) [21:14] slangasek, absolutely. I intend to depend on whatever we possibly can for release [21:14] stgraber, ohh, it must have been another package I'm thinking of then. Let's check my notes [21:15] balloons: how do we track this to make sure it gets done? Do you want me to open a critical bug against juju-core? [21:15] I know some of your packages you did for lxd that were in the queue we needed [21:15] yeah, those were only recently processed, LXD is now building entirely from archive packages (as of last week) [21:15] slangasek, we have https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1508120, but it covers everything [21:16] Launchpad bug 1508120 in juju-core (Ubuntu) "please break out embedded code copies into archive packages" [Undecided,New] [21:16] balloons: yeah, let's please have something we can track against release [21:16] right, so security's permission is based on the same; we need to depend on everything we can in the archive. I'm happy to track it in a bug targeted against release. [21:17] balloons: if you open that bug, I can in the meantime finish this review ;) [21:17] and stgraber, indeed, http://paste.ubuntu.com/15569917/. I noted it was in the archive.. Whoops! [21:18] but slangasek ^^ that's the initial assesment I did [21:18] slangasek, ack, on it [21:18] so it was golang-gopkg-lxc-go-lxc.v2 I was thinking of [21:23] taking this one ^ [21:31] slangasek, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1568148. [21:31] Launchpad bug 1568148 in juju-core (Ubuntu) "Juju packaging for xenial must depend on everything in the archive" [Undecided,New] [21:31] balloons: thanks [21:33] balloons: why does nothing from juju-core 2.0 depend on juju-mongodb? [21:33] slangasek: because the client doesn't use mongodb [21:34] stgraber: the juju-2.0 package also ships jujud, which isn't "client" AIUI [21:34] slangasek: it's the juju daemon/server which does and that part of juju is distributed as binary outside of the archive [21:34] and it ships /usr/bin/juju-upgrade-mondo; does that work remotely? [21:34] oh, fun [21:35] slangasek, also https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1557852 [21:35]