[00:00] ScottK: Also, libqt4-script is seriously broken on arm64; that's why I ripped grantlee out of kde4libs on arm64. [00:00] Anything using QScriptEngine will segfault due to a buggy port [00:00] Fun. [00:00] I don't think that will affect much, though, right? [00:00] Reading state information... [00:00] E: Unable to locate package libdebconf-kde-dev [00:00] apt-get failed. [00:00] Reading state information... [00:00] E: Unable to locate package libdebconf-kde-dev [00:00] Looks good [00:00] Reading state information... [00:00] E: Unable to locate package libdebconf-kde-dev [00:01] i think my middle mouse button didn't like that tea [00:01] wgrant: You spilt tea on your mouse? [00:01] My mouse doesn't often drink tea. [00:01] Actually no, unrelated, compiz had just gone insane [00:01] I think [00:02] Not a long trip for compiz [00:03] No new feature work is being done in Qt4, so I guess people who care about arm64 need to focus on Qt5. How's it doing? [00:04] Mostly blocked on the lack of V8, I think [00:04] We would have had qttools5 if someone had fixed the symbol file early enough [00:04] Right. Like almost everything. [00:05] OK, debconf-kde building in release with kdelibs5-dev [00:05] Looks like it will work [00:05] pyqt5 only builds on 3 archs in Debian due to V8, webkit, or in the case of armel the buildd's exploading at link time. [00:05] And then update_output will look a lot less sad. [00:05] Cool. Thanks wgrant. [00:06] I might end up digging into the libqt4-script issue again at some point, but it's in JavaScriptCore so it's very much ew. [00:19] I'm a bit disappointed with KDE's lack of dep cycles. [00:19] It mostly just works :( [03:06] Bah, didn't notice it was in desktop-core. But not on any images, FTBFS fix for getting KDE built. [03:16] accepted [03:16] Thanks [04:47] infinity, ScottK: Ah, there is a cycle there involving katepart, but higher up than expected: kate b> python-kde4 -> kde-runtime -> kdelibs5-plugins -> katepart. [04:47] * wgrant builds a stage0 kate without python [05:00] cjwatson: when you have a moment, bug #1197766 could probably do with an explicit SRU test case [05:00] Launchpad bug 1197766 in partman-auto (Ubuntu Precise) "Different partition layout after recovery with keep home partition" [High,In progress] https://launchpad.net/bugs/1197766 [05:24] But kate is hopeless anyway, as it turns out, because kdepim-runtime needs libkolab, which FTBFS on all archs as it explicitly requires boost1.49 [07:01] morning - can anyone tell me when respins with the fix for bug 1220165 will be available [07:01] Launchpad bug 1220165 in parted (Ubuntu) "Error informing the kernel about modificatons" [Critical,Fix released] https://launchpad.net/bugs/1220165 [08:11] hi [08:12] i am a member of french loco [08:12] i have a problem with ubuntu-defaults-image [08:12] to generate a iso with EFI [08:15] idea, to have same behavior that official iso [08:18] kanor: best to discuss this in #ubuntu-installer. I don't think there is an easy way to customize/respin the image with uefi/secure boot on it. As far as I recall ubuntu-defaults-image doesn't have that feature that. [08:20] xnox: right, it's more or less using live-build [08:21] xnox: back when I wrote that, at least some Ubuntu images were done the same way [08:21] but I didn't keep up with the EFI/secure-boot changes there [08:22] pitti: yeap. hence e.g. ubuntu chinese images didn't get EFI/secure-boot with 12.04.2 release. But e.g. Ubuntu Kylin does have EFI/secure-boot [08:22] xnox: so these aren't built with u-d-i? or they are, and there's some extra special sauce poured onto them afterwards? [08:22] (or extra hooks?) [08:23] They aren't built with u-d-i [08:37] pitti: ubuntu kylin is just a normal flavour. [08:40] * apw wonders if we are expecting a respin for the parted issue, or should i test the current images [08:43] the procedure to generate official iso, is public ? [08:49] kanor: yeah. [08:49] kanor: lp:ubuntu-cdimage and lp:livecd-rootfs [08:52] oki thank [09:00] apw: folks were asking about that this morning already, indeed [09:07] elfy,apw: I expect infinity will be respinning when he gets in [09:12] apw: Testing in the mean time wouldn't hurt. [09:13] ScottK, heh, i only have so much energy for it, and knowing there is a new image coming ... [09:17] ScottK: libkolab (build-dep of kdepim-runtime) FTBFS on all archs because it explicitly build-deps on boost1.49, despite the packages on either side of it using 1.53. That's blocking arm64 installability of basically all of KDE; how would you feel about changing it to use the default version instead? [09:17] Two symbols of a Private class disappear, but AFAICT it's only linked by akonadi_kolabproxy_resource in kdepim-runtime, and it doesn't use them. [09:18] So it seems safe. [09:20] cjwatson: Respin for parted fix will be happening indeed. I'll be in to the office by 11 or so and make the world twirl. [09:21] wgrant: If you're sure it won't break anything, do it. [09:21] wgrant: (ScottK delegated kubuntu decision making to me while he's out) [09:24] (Also, letting that xorg CVE fix in while I wander in) [09:25] infinity: I also have a cln which builds on arm64 to unblock kde-workspace (just needed some CPU definitions), but that's a 90 minute build on armhf, though that was on a panda. [09:26] wgrant: 90m on a Panda is negligible on Highbank. [09:27] wgrant: I'll spin kubuntu last in the respin pipe to give it time. :P [09:27] And edubuntu, apparently. [09:27] edubuntu dvd [09:27] Is that still a thing? [09:28] That's the only edubuntu. [09:28] Bah [09:28] But yeah, it's respin city after I shower and come in anyway, so if it's low impact, just do it. [09:28] Yeah, both uploaded [09:31] highvoltage / stgraber: Any opinions about that xpra upload in the queue? [09:38] infinity: what's that about? [09:39] cjwatson: So in my naive view liblockfile in precise-proposed is an advantage over the non-patched package. adam_g did not reply in the channel last time you pinged him after we talked. I verified the other bug (bugs.launchpad.net/bugs/1011477) on precise the other day. But I won't go and verify on quantal. [09:40] highvoltage: It's a merge with Debian, looks like. But it's on your image. [09:56] infinity: seems benign enough [10:02] Alright, respins in progress once that xorg-server publishes. [10:47] infinity: please hold out respin, we got a kubuntu fix for muon that needs inclusion [10:48] apachelogger: Sure, you were at the end of the respin list anyway, due to a couple of other things. [10:50] hm, *confused*: http://cdimage.ubuntu.com/cdimage/daily-live/current/ ought to be from today (15-Oct-2013), but only amd64+mac updated [10:50] amd64 and i386 seem to be from yesterday, and rsync complains about "no regular file" (presumably they are symlinks?) [10:51] correct [10:51] amd64/i386 are gated on autotesting, amd64+mac isn't [10:51] ah, I see [10:51] (it should probably be slaved to amd64 for this purpose, but I haven't had time to do that) [10:51] cjwatson: thanks [10:51] ahh the 'build have been updated' is kinda a fib [10:52] pitti: See .../pending/ rather than current if you actually want most-recent-build [10:53] cjwatson: nah, I'm fine with leaving the test machines do their job first :) [10:53] I can rsync later [10:53] pitti: you also want rsync -L for cdimage in general [10:53] At least if you're grabbing individual images [10:58] mir, unity-system-compositor, platform-api, unity-mir - updated mir that gives a good performance boost to Unity8 on device. all autopilot suites run with no regressions to image #97. also smoke tested (running right here) on desktop. [11:01] cjwatson: infinity: as Mirv told: here are the mir changes that were apparently already discussed with you (with the ABI break) ^ [11:01] * didrocks just waits for unity-mir now [11:01] here we go :) [11:02] (not sure if infinity mentioned in the scrollback but): https://code.launchpad.net/~xnox/wubi/saucy-fixup/+merge/191147 wubi's bump to saucy URLs was incomplete, fallback URLs were not bumped and preseed settings. I've now bumped them and retested in windows 7 VM and it works correctly (downloads image from cdimage et, al) [11:04] don't forget about mir itself and platform-api ^ [11:06] mir> least useful changelog ever [11:07] Useless changelogs from the autolander? Say it ain't so. [11:07] + //MirNativeBuffer is type-compatible with the MirNativeBuffer [11:07] cjwatson: I don't think you should question the only guy who contributes more to Ubuntu than you do. Just sayin'. [11:08] yeah their new method does not work well with cu2d - this is the actual "should have been" changelog https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191055 [11:08] I sure hope MirNativeBuffer is type-compatible with the MirNativeBuffer [11:08] cjwatson: The first rule of tautology club... [11:09] Mirv: That changelog could have been put into debian/changelog ... [11:10] I'll accept it because we don't have time to go around much, but people need to stop regarding debian/changelog as a thing they don't have to (cause the autolander to) get right [11:10] It's valuable documentation for your fellow developers [11:10] infinity, ScottK: Uploading muon_2.0.65+git20131008-0ubuntu4_source.changes: done. [11:10] Successfully uploaded packages. [11:11] I'll have to leave now [11:11] * infinity overrides the new libmirserver to main. [11:12] infinity: oops, thanks [11:12] Laney: the Mir team apparently manually edited debian/changelog, therefore preventing cu2d from adding that actual changelog [11:12] FWIW this also means that the bugs will need to be closed manually [11:13] infinity: cjwatson: well, the changed the changelog manually and didn't follow the FAQ (so it override sthe commit) [11:13] they* [11:13] Mirv: Yes, I'm saying that instead of the useless message they put there, they could have put the useful one that went into the merge proposal. [11:13] everything is explained in the FAQ, and kept being repeated… [11:14] The message doesn't appear to have gotten through to the people approving the merges [11:14] s/the people/some of the people/ [11:14] Laney: well, want IRC logs? :) [11:15] I believe that you've explained it :P [11:15] then, I find quite ackward that cu2d is blamed for cases that both people here and I discussed some monthes ago (about changelog generation and when/when not listing commits :p) [11:15] didrocks: I don't blame cu2d, per se, but the entire process, which is mostly down to people. [11:16] didrocks: It's hard to argue that the changelogs would be better if people weren't confused by how to make them not crap. Unless, of course, the people refuse to write good changelogs at all, but that didn't seem to be the case here, they just failed to DTRT to get the good changelog into debian/changelog. [11:16] One of the problems here is that there is (AIUI) an automatic documentation generator whose output people don't really get the opportunity (or at least aren't encouraged) to review before upload. [11:16] basically, they are 2 cases: either you touch debian/changelog and so, cu2d ignore the commit because "it was filed manually", either debian/changelog was untouched and the commit message is taken [11:17] cjwatson: infinity: I'm afraid that the issue is more "upstream don't care about debian/changelog", it's something we should work on, I agree [11:17] didrocks: Note I wasn't actually blaming cu2d, although I do have a well-documented distaste for generated changelogs [11:17] didrocks: Also, can we get rid of: [11:17] [ Ubuntu daily release ] [11:17] * Automatic snapshot from revision 3554 [11:17] infinity: how would we know which rev was used as based then? [11:18] I'll write a comment on the MP. You never know, it might help. :-) [11:18] didrocks: We could alter the version spec again, and make you lose your mind. :) [11:18] infinity: you wanted shorter versions, not longer, remember? :p [11:19] Yeah, I guess it just drives me nuts when the above two lines are pretty much the entire changelog, and they're completely meaningless. [11:19] "This is an automated upload", no really? [11:19] didrocks: Aaaanyhow, totally the wrong time in the cycle to be bitching about such things or suggesting changes. [11:20] happy to change the semantic (but for people not being familiar with the process, not sure they know it's automated) [11:20] didrocks: For people unfamiliar with the process, I don't think they should care that it's automated. [11:21] I think it would be helpful not to take every criticism of a particular output of cu2d as a fundamental criticism of cu2d, though [11:22] possibly, but sarcasm on the Internet… ;) [11:24] cjwatson, this pending/ image seems to fix the parted issue on my test rig [11:25] apachelogger: \o/ [11:25] apw: \o/ [11:25] apachelogger: Ignore that. [11:32] apw: good [11:37] cjwatson, we need that combination, side by side overwritten by single install, as a test [11:39] Possibly, though only automated; this is the first time I'm aware of that it's been a problem, so let's not turn it into another thing for human testers to spend ages on since it takes a while to set up [11:44] infinity: awww, no cheering for me :P [11:54] cjwatson, it occurs to me, that an install with 'separate home' with an install over the top ought to trip it too [11:55] Yep, probably, depending on the position of the swap partition [11:55] Would no doubt trigger related-but-different bugs in slightly different ways [11:57] infinity, just saw that 'super+space is the new ...' thing on first boot of a VM install [11:59] infinity: Could you unblock lighttpd, please? [11:59] (arm64) [12:17] cjwatson: Feel free to unblock unseeded fixes, I don't think that needs an extra layer of review from someone !uploader. [12:17] ok [12:54] mozjs will probably need manual review due to being in the mozilla packageset [12:56] cjwatson: I'd have been tempted to add ppc64el by hand to that symbols file to avoid having to do it all over again. [12:57] Yeah, but I didn't have an actual build to check that against [12:57] And there were a couple of not-completely-obvious changes in there [12:57] -e 's/kfreebsd-amd64 s390x/kfreebsd-amd64 ppc64el s390x/' -e 's/!kfreebsd-amd64 !s390x/!kfreebsd-amd64 !ppc64el !s390x/' [12:57] Two symbols that were inlined/missing) [12:57] So I'd rather do it with reference to a build [12:57] Fair enough. [12:58] Not that I would object if the maintainer (hi chrisccoulson!) decided to do it anyway in advance. :-) [12:59] infinity: looking now [13:01] stgraber: I think you're a bit late. :) [13:01] ok :) [13:02] oh I see highvoltage's ack in the backlog now === psivaa is now known as psivaa-afk [14:49] infinity: thanks for landing the dpkg SRU === psivaa-afk is now known as psivaa [15:23] can horizon rc2 get approved please its got a rather nasty regresison [15:23] hope it's rc1 with the nasty regression :-) [15:23] reviewing [15:24] cjwatson: fyi https://bugs.launchpad.net/horizon/+bug/1237989 [15:24] Launchpad bug 1237989 in OpenStack Security Advisory "user can update his password without knowing the old password" [Undecided,Incomplete] [15:24] yikes, yeah, had just found that [15:26] accepted and will unblock [15:26] cool thanks [15:27] Oh, we're in block-all source? [15:27] Missed that ... [15:27] yeah [15:27] is the auto-accept script still on? [15:28] believe so [15:32] update_excuses.html is a bit of a pain to parse with all those arm64 packages :) [15:32] they'll clear soon, I believe [15:32] but grep for 'by freeze' or similar [15:32] so obvious candidates for unblocking are keystone, apparmor-easyprof-ubuntu, subversion and ubuntu-touch-meta [15:32] I already unblocked subversion I think [15:33] oh, no, infinity did [15:33] I guess we need lool or didrocks to ack/nack apparmor-easyprof-ubuntu and ubuntu-touch-meta (that one has an unblock but for the wrong version) [15:33] stgraber, yeah, we'Re waiting for another package [15:33] to then do another seed change [15:34] any chance for libopenraw? [15:34] lool: did you discuss apparmor-easyprof-ubuntu? [15:34] doko: looking [15:34] apparmor-easyprof-ubuntu is in the landing plan [15:34] landing #236 [15:35] jdstrand: yeah, not sure if you discussed it with lool, (he didn't tell me), I'm happy to unblock it [15:35] didrocks: I did. he is the one who added it to the plan [15:35] ok, hinting now [15:35] doko: accepted. Not exactly sure why it's in all those package sets when seeded-in-ubuntu says it's unseeded, anyway, accepted [15:35] Yeah, I couldn't make that out either [15:35] didrocks: thanks :) [15:35] jdstrand: yw ;) [15:36] stgraber: oh, it's in the build-depends stack for those flavours [15:36] I don't think seeded-in-ubuntu cares about that [15:36] (it arguably ought to) [15:37] cjwatson: ah, interesting, so it's a build-dep that doesn't result in a runtime dep? Probably not an issue anyway since it won't actually affect any media. [15:37] think so [15:37] didn't look too hard :) [15:37] it's a build-dep of (at least) tumbler, if you care [15:37] feel free not to :) [15:40] * stgraber quickly goes through the ~ubuntu-archive bugs to see what needs doing or postponing [15:42] We still have one outstanding MIR that makes maas uninstallable. :/ [15:52] infinity: so we are likely to have an upload of systemd for bug #1234743 sometime today. I'm assuming you don't want to respin the world for an updated udev, and we should push this to -updates? [15:52] Launchpad bug 1234743 in systemd (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,In progress] https://launchpad.net/bugs/1234743 [15:54] slangasek: We're in 'block-all source' mode right now anyway. So, push it to proposed, don't unblock it, and if we respin for $reasons, I'll unblock and pull it in. If not, you can do SRU paperwork. Deal? [15:55] infinity: we want it into the phone images on release day due to its impact on maguro, so I think we would proceed with the SRU anyway [15:55] cjwatson: so, second attempt on location-service ^ (I also changed the Breaks/Replaces order as I prefer to have that after Depends) [15:55] infinity: unless you think we should fudge the SRU process and just push it to -updates in lieu [15:55] ogra_: ^ you'll do the SRU paperwork =) [15:56] slangasek: Given history, I have a hard time believing we won't have a respin before release. But a man can dream. [15:56] ... of electronic sheep =) [15:56] infinity: we might have respins of some things, but hopefully not respinning the world? :) [15:56] * xnox goes to find ubiquity/partman bug to fix [15:56] slangasek: The most critical RC bugs at this point tend to respin the world anyway. :P [15:56] slangasek: (installer, etc) [15:56] xnox, OOOOH ! [15:57] * ogra_ hugs xnox [15:59] slangasek: Anyhow, long story short, get it fixed, upload, we can argue about where it goes after it's all built in proposed. :P [15:59] slangasek: My bet is on it making to the release pocket, but we can sort out a backup plan if I'm wrong. [15:59] infinity: yes, I wanted to give you a heads-up that it was coming in case you wanted to delay any currently-pending respins [16:00] slangasek: Current set o' spins just happened (module KDE, which is waiting on us unsnagging or forcing pykde4) [16:00] ack [16:00] if somebody wants to binary-NEW libaria, that's the last in saucy_outdate_all [16:01] cjwatson: I'm on it. [16:01] though I guess there are a few more builds to arrive [16:02] *nod* [16:02] Was waiting on all 5. [16:02] But I can quickly review the two debs here for sanity. [16:02] Err, the two uploads of MANY debs. [16:06] didrocks: *I didn't explcitely ping you on apparmor-easyprof-ubuntu since we discussed on #ubuntu-ci-eng) [16:07] s/\*/( [16:07] lool: that's fine, I was just wanted to know if it was handled and agreed (I've hinted in) [16:09] infinity: Do I need to find someone to help with getting pykde4 through? [16:10] ScottK: That's just migrated [16:11] Cool. [16:11] ScottK: bootstrapping kdepim-runtime and kate took a bit longer than expected due to builder unreliability. [16:11] But 126 bits of KDE just migrated [16:11] Just checking in for a moment. Nice. [16:13] /win 58 [16:14] didrocks: sorry, missed that, looking now [16:15] ok, dropping M-A entirely probably isn't ideal, but it's better than it being wrong :) [16:16] cjwatson: yeah, I did want to test is properly, but prefer doing this way for now [16:16] accepted [16:53] ogra@chromebook:~$ rmadison location-service [16:53] location-service | 0.0.1+13.10.20131011-0ubuntu1 | saucy | source [16:53] location-service | 0.0.2+13.10.20131015.2-0ubuntu1 | saucy-proposed | source [16:53] ogra@chromebook:~$ rmadison location-service [16:53] location-service | 0.0.2+13.10.20131015.2-0ubuntu1 | saucy | source [16:53] ogra@chromebook:~$ [16:53] * ogra_ scratches head [16:53] where are the binaries ? [16:56] didrocks, did you only copy the source ? [16:56] ogra_: you want -S [16:56] rmadison -S [16:57] jinx [16:57] oops [16:57] ogra_: it's a ubuntu-location-service-bin ;) [16:57] yeah, sorry, my fault [16:59] no worry! [16:59] ogra_: it seems to all be ready! [16:59] didrocks, yeah [16:59] funny that all but the -bin package are in main though [17:00] i wonder how they got there [17:00] they're build-deps of bits of desktop [17:00] wow [17:00] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/rdepends/location-service/libubuntu-location-service0 [17:00] so we use location service on dekstop but not on the phone ... fun [17:01] -dev and -doc will be extra-include, -bin probably isn't pulled in by anything, such is life [17:01] yeah, i dont really care for S [17:01] we don't use it on the desktop as such - as I say it's a Build-Depends [17:01] of gst-plugins-bad1.0 which IIRC you use on the phone ... [17:01] just found it curious that the only valuable package is in universe [17:01] yeah [17:03] it's actually gst-plugins-bad1.0 B-D: libplatform-api1-dev D: libubuntu-application-api-mirclient1 D: libubuntu-location-service0 [17:03] ah, yeah [17:03] that makes some sense [17:03] bad is in universe [17:04] platform=api is in main iirc [17:04] *platform-api [17:04] sorry, yeah, it's actually from libubuntu-platform-api1-dev [17:05] which is because other binaries from platform-api are in main [17:05] right [17:07] I'm actually failing to find a root cause of any of this being in main, so I hope none of you really care :) [17:07] I'm sure it must exist somewhere [17:08] well, the sdk team might care that their stuff is in main ... but apparently thats the case so we're all fine :) [17:08] It probably doesn't show up in the rdepends tree there because that's generated on i386 [17:10] hdf5 (above) isn't actually on Kubuntu images AFAICS, just in their build-dep tree [17:10] So should be able to go in [17:12] Oh, update_output is really short due to block-all source [17:12] I almost fainted and thought we'd accidentally let in a bunch of broken stuff [17:13] cjwatson: Heh. [17:14] did proposed get cleared out? [17:15] Laney: No, that won't happen until post-release, when we can copy most of it to t-proposed. [17:15] Copy-then-delete. [17:15] oh OK, was wondering why the shortness [17:15] Surely not fixing stuff :P [17:15] due to block-all source, as I said [17:15] Oh wait [17:15] since that filters at the excuses stage [17:15] that stops it from going there [17:15] I get what you mean now [18:05] \o/ [18:06] congrats [18:06] infinity, is that ... like a core image for arm64 ... like complete ? [18:06] apw: Yep. [18:06] infinity, ^5 [18:06] apw: If we had a kernel and bootloader, I could actually build server too. [18:07] And desktop, I think. [18:07] apw: So, bootloader's a harder question we need to solve, but we should make a generic kernel go this/next week for t-series opening. [18:07] tsk ... server ... desktop ... [18:08] touch is what you want ... (and some arm64 phones) [18:08] ogra_: Touch is harder, because of the lack of V8. [18:08] ogra_: basically, same reason we can't have touch on powerpc. [18:08] bah [18:09] i'm sure we'll soon see arm64 phones [18:09] You mean, other than the iPhone5s? [18:09] yeah [18:09] others will quickly follow suit [18:09] Yeah, the phone race is a numbers game, I'm sure Android vendors will squirt some out ASAP. [18:09] HTC already has its first fingerprint reader equipped phone out ... [18:09] just a matter of time [18:14] cjwatson: ^-- required for that core build that just happened. [18:14] (What, me? Cowboy? Nevar) [18:24] infinity: is tty actually guaranteed to be guid 5? [18:24] *gid [18:25] stgraber: It is on any distro that isn't full of fail. [18:25] stgraber: And where it's not, you can't run chroots that mix and match distro anyway, because devpts is a shared mount. [18:25] stgraber: ie: if you mount in a chroot with gid=6, you get that in the base system too. [18:26] infinity: except that devpts support instances which you should be using in a chroot ;) [18:26] (CONFIG_DEVPTS_MULTIPLE_INSTANCES=y + -o newinstance will give you a clean devpts) [18:26] stgraber: How clean? [18:27] anyway, accepted [18:27] infinity: http://paste.ubuntu.com/6241781/ [18:28] stgraber: Ahh, yes. Tested here, newinstance works. But how long has that been in the kernel? [18:28] 2.6.29 ... No idea how long we've carried it in our configs. [18:28] Also, not to be trusted to be there on random !Ubuntu machines, I'd guess. [18:29] stgraber: But thanks for the education. I'll add this to my arsenal while I try to figure out how to sort all the corner cases of not shooting ourselves in the foot when I remove pt_chown. :/ [18:30] any distro that vaguely cares about containers will have it at least [18:30] So, nobody who runs systemd? :P [18:31] Was it lxc or libvirt where I saw the gid=5 thing? I didn't see newinstance there. [18:32] lxc uses newinstance for sure. Also the fedora kernels actually work fine with LXC, it's just their userspace that doesn't (as is proven by the fact I use a fedora kernel on my wandboard and use that machine as an armhf LXC host) ;) [18:32] Oh, no, it has both. [18:32] stgraber: lxc uses newinstance *and* gid=5. [18:32] Which is good, cause without gid=5, it'll explode soon. [18:33] lxc also pointlessly sets ptxmode, but whatever. [18:33] ah? [18:33] stgraber@castiana:~$ grep devpts data/code/lxc/lxc/src/lxc/conf.c -A1 [18:33] if (mount("devpts", "/dev/pts", "devpts", MS_MGC_VAL, [18:33] "newinstance,ptmxmode=0666")) { [18:33] ptmxmode, even. [18:33] stgraber: Erm, you're missing a patch there... [18:34] I thought that had been applied when I went grepping. Maybe not. [18:34] stgraber: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720122 [18:34] Debian bug 720122 in lxc "lxc: Improper pty permissions - missing mode=0620,gid=5" [Important,Fixed] [18:34] ignore all Debian lxc bugs, we're not using the same packaging and don't do any non-upstream patching in Ubuntu ;) [18:34] though I do see gid=5 in /proc/mounts, trying to figure out where that's coming from [18:35] oh, the kernel apparently ;) [18:35] stgraber: It'll come from the last thing that mounted (or remounted) that instance. [18:35] stgraber: And no, not the kernel. [18:35] I wish. [18:36] yeah, that seemed weird, apparently it was just my eyes or brain (or both) malfunctioning for a minute [18:36] stgraber: So, if we're not carrying that patch, we really should be. [18:37] stgraber: And SRUed back, too. [18:37] I'm going to try to belt-and-bracers this and make util-linux (and maybe the kernel driver too) all assume that "defaults" == "gid=5,mode=620", but that's no excuse for mount calls getting it wrong. [18:43] infinity: hmm, I really don't like the idea of hardcoding a gid in LXC... though looking around the dozen or so distro we support seem to be consistent on tty=5 [18:46] infinity: so you're basically telling me I need to get that change upstream, cherry-pick it into Ubuntu and then respin Edubuntu for it (since we apparently already have the new eglibc in saucy...) [18:47] stgraber: No, I backed it out in saucy pending sorting out fixing all the gotchas. [18:47] stgraber: However, Fedora's glibc lacks pt_chown already. [18:48] stgraber: We do want to push this as a security update eventually, though, which will mean also pushing updates to a bunch of packages that might break. It'll be fun(tm). [18:50] infinity: ok, I'll send the patch to the lxc mailing list now so should be merged soonish (assuming none of the distro maintainers tell us that their distro use a different gid, in which case we'd have to make a much bigger patch and template changes...) [18:51] stgraber: In a quick bit of research, the only people I could find who were divergent were LFS, and they switched to gid=5 a while back to stop being gratuitously different. [18:55] ok, sent for review to lxc-devel. [18:55] stgraber: There's precedent in that libvirt already appears to do it this way. [18:56] please remember LXC when doing the massive set of uploads to -security. LXC is only in main since saucy so won't show up in the security team reports but we have a ton of users from precise all the way up to saucy, so we'll want all of those to get an SRU. [18:56] infinity: libvirt uses %d with a per-distro value [18:56] src/lxc/lxc_controller.c: if (virAsprintf(&opts, "newinstance,ptmxmode=0666,mode=0620,gid=5%s", [18:57] I thought they changed that to %d but maybe I was looking at some other libvirt-related patches [18:57] systemd supports compile-time changing of TTY, but defaults to 5, I believe. [18:58] Basically, if any distros aren't tty=5, they'll all switch soon. :P [19:32] can someone unblock keystone rc2 please? [19:35] infinity: hmm, so we're bumping d-i for new omap4 kernels instead of just killing those? [19:36] stgraber: Yeah. [19:36] zul: Already done. [19:36]