[02:20] <TheClitCommander> rww, whats up
[02:20] <TheClitCommander> rww, hi
[10:40] <pitti> Good morning
[10:56] <pitti> wgrant: would you be able to kick off a full utopic langpack export now, for the final release? (full export requested in LP already)
[10:56] <pitti> wgrant: wednesday will be too old
[10:56] <pitti> wgrant: sorry for missing that, all the traveling since Friday made me forget
[10:57] <pitti> infinity, stgraber ^ FTR (otherwise I'll invent something)
[12:05] <wgrant> pitti: Sure, let me see.
[12:39] <pitti> infinity, jdstrand: bug 1382524 should be almost a no-brainer (splitting out existing code to a new package), and it's one of the release blockers; do you have a minute to review that MIR?
[12:40] <roaksoax> win 13
[12:43] <infinity> pitti: Lemme look.
[12:44] <infinity> pitti: No-brainer indeed.  Approving and promoting.
[12:57] <pitti> infinity: ack, thanks
[13:49] <cjwatson> rbasak: maas-cluster-controller is uninstallable on current server powerpc images and making my daily-checks output sad.  Does it need something like https://code.launchpad.net/~racb/maas/arm-syslinux again?
[13:50] <cjwatson> well except that there's no syslinux-common on anything other than amd64/i386 nowadays
[13:53]  * rbasak looks
[13:53] <cjwatson> mvo: has anyone brought https://launchpad.net/bugs/1347834 to your attention yet?
[13:53] <mvo> cjwatson: no, sorry, I have a look right now
[13:59] <cjwatson> mvo: ta
[14:03] <rbasak>   * For the time being, Marking all packages as amd64 and i386 only
[14:03] <rbasak>     instead of any.
[14:04] <rbasak> syslinux (3:6.03~pre18+dfsg-1)
[14:04] <rbasak> Some multiarch magic might be needed here.
[14:05] <lutostag> rbasak: I think we need syslinux for maas server side specifically -- ie running maas-cluster on arm64 or the like
[14:05] <lutostag> rbasak: so if you need some help... :)
[14:05] <Wizard> Hi
[14:05] <rbasak> lutostag: right. A MAAS server installed on arm64 should still be able to manage amd64 nodes, for example.
[14:05] <rbasak> So it should be able to get chain.c32 and the other pieces it needs installed from syslinux packaging.
[14:06] <rbasak> It seems pretty late to be making drastic changes to syslinux packaging though.
[14:06] <rbasak> lutostag: do we have any CI on this use case? Or do we not actually care about it?
[14:08] <lutostag> rbasak: I dont think we do, it seems like something we do one-offs for due to lack of machines
[14:11] <rbasak> lutostag: do you know how much we care about this problem?
[14:12] <lutostag> rbasak: not sure how much of an impact it has...
[14:13] <rbasak> lutostag: AIUI, it means it's impossible for a non-Intel arch machine to be a cluster controller right now.
[14:14] <rbasak> lutostag: if we drop the dependency for non-Intel architectures, then that would mean that MAAS running on non-Intel will not be able to bootstrap Intel nodes.
[14:14] <lutostag> roaksoax: ^^ moving syslinux from all -> x86,amd64 -- how important is it?
[14:15] <cjwatson> lutostag: uninstallable packages on our released images is generally a sadness-making thing, aside from anything else
[14:15] <roaksoax> lutostag: huh?
[14:15] <cjwatson> bdrung,tumbleweed: want to check/upload the change I just committed to collab-maint/distro-info-data, following http://www.markshuttleworth.com/archives/1425 ?
[14:16] <lutostag> roaksoax: "rbasak> lutostag: if we drop the dependency for non-Intel architectures, then that would mean that MAAS running on non-Intel will not be able to bootstrap Intel nodes."
[14:16] <rbasak> roaksoax: maas-cluster-controller on non-Intel is uninstallable due to syslinux-common (supplying chain.c32, etc) no longer being available on non-Intel archs.
[14:16] <rbasak> If we make it an arch-specific dep, then that'll make it installable but presumably leave it a little broken.
[14:16] <rbasak> So I'm asking how important this use case is for us.
[14:17] <rbasak> We could fix by dropping the dependency (but will affect functionality), reverting syslinux-common somehow to be available on the other archs, or declaring the appropriate multiarch bits so that the i386 or amd64 build can be installed on the non-Intel arch.
[14:17] <rbasak> To me, the multiarch solution seems the best, and maybe least regression risk for this point in the cycle I guess.
[14:18] <rbasak> Assuming that change would be acceptable to the release team.
[14:18] <cjwatson> I'm afraid not
[14:18] <rbasak> But do we actually need this functionality? Can we fix it by dropping the dependency on non-Intel maas-cluster-controller, losing that functionality, but not having to touch the syslinux pacakge?
[14:19] <cjwatson> It would be non-trivially complex, potentially affect a bunch of other stuff, and it would be a lot of work to make our checks understand multiarch.
[14:19] <cjwatson> rbasak: That sounds least invasive, albeit perhaps not globally ideal
[14:19] <rbasak> Yeah it does seem to be far too late in the cycle to be discovering this. If it's a use case that really matters, that's a big QA failure.
[14:20] <rbasak> roaksoax: what's your opinion on this?
[14:21] <roaksoax> rbasak: otp
[14:21] <rbasak> ok
[14:21] <rbasak> cjwatson: understood, thanks.
[14:23] <roaksoax> rbasak: so you are saying maas does not install on arm?
[14:23] <roaksoax> rbasak: due to recent changes in syslinux packaging?
[14:24] <rbasak> roaksoax: maas-cluster-controller does not install on powerpc, which is what I tested. But it looks like it applies to all that isn't i386 or amd64 too.
[14:25] <rbasak> roaksoax: due to a syslinux change in packaging that landed on 1 July.
[14:25] <rbasak> (AFAICT)
[14:25] <cjwatson> I noticed it on powerpc but that may just be whatever happens to be on images.
[14:26] <roaksoax> rbasak: well, I've seen it running on arm without an issue
[14:26] <cjwatson> http://people.canonical.com/~ubuntu-archive/testing/utopic_probs.html and http://people.canonical.com/~ubuntu-archive/testing-ports/utopic_probs.html say that it affects arm64 and armhf too, between them
[14:26] <cjwatson> roaksoax: it won't install on arm, today
[14:26] <roaksoax> rbasak: but yeah, maas should be able to deploy i386/amd64 nodes even if it is runnong on ppc64el
[14:26] <cjwatson> unless you go to some non-default lengths to sort out multiarch
[14:27] <rbasak> roaksoax: should be able to yes. But how important is this use case? Because it appears to be broken, and at this time in the cycle our options are limited.
[14:28] <roaksoax> rbasak: I would say it is important provided that we support running those arches
[14:28] <rbasak> We support running arm64, yes?
[14:28] <bdrung_work> cjwatson, how did you get the release date of vivid? just guessing or is there a release schedule proposal?
[14:28] <rbasak> I'll file a bug then, thanks.
[14:29] <lutostag> rbasak: thanks!
[14:29] <cjwatson> bdrung_work: infinity and I agreed that it was better to guess (and thus have *something* in utopic that we can adjust later) than have nothing at all
[14:29] <cjwatson> so that's the last Thursday in April
[14:37] <infinity> doko: That python2.7 upload looks like a no-op to me, since ^gcc always matched regardless?
[14:38] <bdrung_work> cjwatson, thanks and yes, guessing is better than nothing.
[14:38] <bdrung_work> i uploaded 0.23 to unstable
[14:38] <cjwatson> bdrung_work: great, thanks
[14:38] <bdrung_work> you're welcome
[14:39] <rbasak> Filed bug 1383332
[14:41] <infinity> rbasak: We could look at just flipping syslinux-common to arch:all.
[14:41] <infinity> rbasak: If the 32-bit and 64-bit builds are the same.
[14:41] <rbasak> infinity: yeah. I wondered why he changed it in the first place.
[14:42] <rbasak> I think the builds are the same. For the bits that MAAS needs, anyway.
[14:42] <rbasak> (I think those bits run in real mode)
[14:42] <doko> infinity, no, it's set to <triplet>-gcc
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/bios/hdt.c32 and i386/usr/lib/syslinux/modules/bios/hdt.c32 differ
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/bios/sysdump.c32 and i386/usr/lib/syslinux/modules/bios/sysdump.c32 differ
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi32/hdt.c32 and i386/usr/lib/syslinux/modules/efi32/hdt.c32 differ
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi32/sysdump.c32 and i386/usr/lib/syslinux/modules/efi32/sysdump.c32 differ
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi64/hdt.c32 and i386/usr/lib/syslinux/modules/efi64/hdt.c32 differ
[14:44] <cjwatson> Binary files amd64/usr/lib/syslinux/modules/efi64/sysdump.c32 and i386/usr/lib/syslinux/modules/efi64/sysdump.c32 differ
[14:44] <cjwatson> that's the complete diff -ru
[14:44] <cjwatson> that might just be non-reproducibility
[14:44] <infinity> doko: Ahh, didn't think the triplet case.  Check.  Thanks.
[14:46] <cjwatson> it's probably OK
[14:46] <cjwatson> and it was arch all until recently
[14:47] <cjwatson> indeed it's arch all again in unstable now
[14:52] <infinity> rbasak: Right, Colin's cherry-picking that change from Debian, so that solves that.
[14:52] <cjwatson> ok, yeah.  I'll take that bug then
[14:52] <rbasak> Oh, OK. Thanks!
[14:53] <rbasak> I will follow up on the QA side of this though. If it's important, it should have been flagged months ago.
[15:14] <xnox> darkxst: i haven't checked. I believe there will be another slideshow release, but I cannot confirm yet. I was going to look into it tonight.
[15:15] <xnox> infinity: i'm barely around. What's up?
[15:15]  * xnox should stop idling on irc when i'm not available.
[15:15] <infinity> xnox: I don't remember, so it can't have been important.
[15:15] <infinity> xnox: But I bet slangasek would like to yell at^W^Wtalk to you.
[15:16] <xnox> infinity: are you on the right side of the pond to meet up and have dinner this week?
[15:16] <infinity> xnox: On the left side.
[15:16] <slangasek> xnox: he's on the left side of the pond
[15:16] <slangasek> xnox: also, please to be fixing plymouth
[15:16] <xnox> slangasek: i've noticed that you push overwrote plymouth branches. I haven't checked yet, what happen there.
[15:17] <xnox> slangasek: i'm using 14.04 LTS and plymouth works great there =)))))
[15:17] <slangasek> "push overwrote"?
[15:17] <slangasek> xnox: yes, plymouth works great in 14.04, which is the release you didn't break it in :-P
[15:17] <xnox> slangasek: was bad or really bad?
[15:18] <infinity> xnox: A little from column A, a little from column B.
[15:18] <slangasek> xnox: we're currently looking at bug #1362333, which is reproducible in a VM install - plymouth is doing something very broken with the passphrase input
[15:19] <slangasek> xnox: I have not seen this bug on my existing continuously-upgraded host install, but in a freshly-installed VM I will repeatedly type the passphrase at boot post-install and it won't work.  Then I'll use my backspace key, and things magically work
[15:19] <xnox> slangasek: with upstart or systemd.
[15:19] <infinity> xnox: upstart.
[15:19] <slangasek> xnox: upstart, unless someone snuck in a change to the default init that I didn't notice ;)
[15:19] <xnox> slangasek: i see a useful upload from andy. Did apw upstream that?
[15:20] <xnox> ah, it's a cherry-pick, so yes.
[15:22] <apw> xnox, ahh that one, yes it was upstream fixy fun
[15:24] <xnox> slangasek: yeah, that bug is not funny. I'll be busy in a few, but will do ubuntu/debian work tonight, cause this bug sound like fun to work on.
[15:25] <infinity> xnox: PS, there's a release in 3 days.
[15:42] <ppisati> doko: FYI, perhaps you already saw that - https://www.mail-archive.com/linaro-toolchain@lists.linaro.org/msg04529.html
[15:59] <apw> ppisati, are we expecting to see that "limit" come down through stable into older releases ?
[16:05] <ppisati> apw: the gcc limit? it should
[16:05] <apw> ugg
[16:05] <ppisati> apw: and it seems T is affected - http://pastebin.ubuntu.com/8603452/
[16:06] <apw> ppisati, yeah we need to know whether our compiler is patched for the issue on trusty, and then decide whether we should apply or not when it appears
[16:06] <apw> doko, i hope you will know ;)
[18:14] <sergiusens> pitti: hey, can we discuss adt with device constraints?
[19:25] <voldyman> hey guys, i am making some changes in ubiquity, how do you test it?
[19:42] <TheMuso> voldyman: You might have more luck getting an answer in #ubuntu-installer.
[20:41] <slangasek> xnox: so I'm getting some interesting test results out of a hand-hacked cryptsetup initramfs script... such as 'plymouth ask-for-password' returning non-zero
[20:41] <slangasek> xnox: and apparently I don't understand the semantics of POSIX shell 'read'
[20:52] <brendand> stgraber, can i get added to https://launchpad.net/~ubuntu-qa-website-devel/+members?
[20:52] <doko> tedg: ping on https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1382020
[20:53] <tedg> redirect ping bregma ^
[20:53] <tedg> Oh, he's not online. That's a good trick.
[20:53]  * tedg 's IRC Kung-Fu is weak
[20:54] <tedg> doko, bregma was going to look into the xorg-gtest because it seems to not compile.
[21:04] <stgraber> brendand: why?
[21:05] <stgraber> (that's a privileged team with admin access over iso.qa.ubuntu.com, so I need a good reason :))
[21:05] <stgraber> or we need to decouple the team from admin privileges over the production tracker, then I'd care a bit less about whose on it
[21:05] <brendand> stgraber, i'm re-evaluating the qa tracker to be used again by QA
[21:06] <brendand> stgraber, i'd like to play around with the dev instance - http://iso.qa.dev.stgraber.org/
[21:06] <brendand> stgraber, i won't touch production - balloons will back me up
[21:21] <brendand> stgraber, ?
[21:24] <stgraber> brendand: try logging in again now
[21:24] <stgraber> brendand: in theory I've given admin access to canonical-platform-qa on the staging instance
[21:25] <brendand> stgraber, great thanks