[02:20] rww, whats up [02:20] rww, hi === sgnb` is now known as sgnb [10:40] Good morning [10:56] 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] wgrant: wednesday will be too old [10:56] wgrant: sorry for missing that, all the traveling since Friday made me forget [10:57] infinity, stgraber ^ FTR (otherwise I'll invent something) [12:05] pitti: Sure, let me see. [12:39] 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:39] bug 1382524 in autodep8 (Ubuntu) "[MIR] autodep8" [Undecided,New] https://launchpad.net/bugs/1382524 [12:40] win 13 === _salem is now known as salem_ [12:43] pitti: Lemme look. [12:44] pitti: No-brainer indeed. Approving and promoting. [12:57] infinity: ack, thanks === doko_ is now known as doko === salem_ is now known as _salem === Spads_ is now known as Spads [13:49] 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] well except that there's no syslinux-common on anything other than amd64/i386 nowadays [13:53] * rbasak looks [13:53] mvo: has anyone brought https://launchpad.net/bugs/1347834 to your attention yet? [13:53] Ubuntu bug 1347834 in ubuntu-release-upgrader (Ubuntu) "UnboundLocalError: local variable 'e' referenced before assignment in doUpdate, line 924" [Undecided,Confirmed] [13:53] cjwatson: no, sorry, I have a look right now === Guest4574 is now known as mfisch [13:59] mvo: ta === timrc-afk is now known as timrc [14:03] * For the time being, Marking all packages as amd64 and i386 only [14:03] instead of any. [14:04] syslinux (3:6.03~pre18+dfsg-1) [14:04] Some multiarch magic might be needed here. [14:05] rbasak: I think we need syslinux for maas server side specifically -- ie running maas-cluster on arm64 or the like [14:05] rbasak: so if you need some help... :) [14:05] Hi [14:05] lutostag: right. A MAAS server installed on arm64 should still be able to manage amd64 nodes, for example. [14:05] So it should be able to get chain.c32 and the other pieces it needs installed from syslinux packaging. [14:06] It seems pretty late to be making drastic changes to syslinux packaging though. [14:06] lutostag: do we have any CI on this use case? Or do we not actually care about it? [14:08] rbasak: I dont think we do, it seems like something we do one-offs for due to lack of machines [14:11] lutostag: do you know how much we care about this problem? [14:12] rbasak: not sure how much of an impact it has... [14:13] lutostag: AIUI, it means it's impossible for a non-Intel arch machine to be a cluster controller right now. [14:14] 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] roaksoax: ^^ moving syslinux from all -> x86,amd64 -- how important is it? [14:15] lutostag: uninstallable packages on our released images is generally a sadness-making thing, aside from anything else [14:15] lutostag: huh? [14:15] 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] 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] 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] If we make it an arch-specific dep, then that'll make it installable but presumably leave it a little broken. [14:16] So I'm asking how important this use case is for us. === quadrispro_hds is now known as quadrispro [14:17] 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] To me, the multiarch solution seems the best, and maybe least regression risk for this point in the cycle I guess. [14:18] Assuming that change would be acceptable to the release team. [14:18] I'm afraid not [14:18] 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] 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] rbasak: That sounds least invasive, albeit perhaps not globally ideal [14:19] 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] roaksoax: what's your opinion on this? [14:21] rbasak: otp [14:21] ok [14:21] cjwatson: understood, thanks. [14:23] rbasak: so you are saying maas does not install on arm? [14:23] rbasak: due to recent changes in syslinux packaging? [14:24] 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] roaksoax: due to a syslinux change in packaging that landed on 1 July. [14:25] (AFAICT) [14:25] I noticed it on powerpc but that may just be whatever happens to be on images. [14:26] rbasak: well, I've seen it running on arm without an issue [14:26] 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] roaksoax: it won't install on arm, today [14:26] rbasak: but yeah, maas should be able to deploy i386/amd64 nodes even if it is runnong on ppc64el [14:26] unless you go to some non-default lengths to sort out multiarch [14:27] 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] rbasak: I would say it is important provided that we support running those arches [14:28] We support running arm64, yes? [14:28] cjwatson, how did you get the release date of vivid? just guessing or is there a release schedule proposal? [14:28] I'll file a bug then, thanks. [14:29] rbasak: thanks! [14:29] 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] so that's the last Thursday in April [14:37] doko: That python2.7 upload looks like a no-op to me, since ^gcc always matched regardless? [14:38] cjwatson, thanks and yes, guessing is better than nothing. [14:38] i uploaded 0.23 to unstable [14:38] bdrung_work: great, thanks [14:38] you're welcome [14:39] Filed bug 1383332 [14:40] bug 1383332 in maas (Ubuntu) "maas-cluster-controller is uninstallable on non-Intel architectures" [Undecided,New] https://launchpad.net/bugs/1383332 === Spads_ is now known as Spads [14:41] rbasak: We could look at just flipping syslinux-common to arch:all. [14:41] rbasak: If the 32-bit and 64-bit builds are the same. [14:41] infinity: yeah. I wondered why he changed it in the first place. [14:42] I think the builds are the same. For the bits that MAAS needs, anyway. [14:42] (I think those bits run in real mode) [14:42] infinity, no, it's set to -gcc [14:44] Binary files amd64/usr/lib/syslinux/modules/bios/hdt.c32 and i386/usr/lib/syslinux/modules/bios/hdt.c32 differ [14:44] Binary files amd64/usr/lib/syslinux/modules/bios/sysdump.c32 and i386/usr/lib/syslinux/modules/bios/sysdump.c32 differ [14:44] Binary files amd64/usr/lib/syslinux/modules/efi32/hdt.c32 and i386/usr/lib/syslinux/modules/efi32/hdt.c32 differ [14:44] Binary files amd64/usr/lib/syslinux/modules/efi32/sysdump.c32 and i386/usr/lib/syslinux/modules/efi32/sysdump.c32 differ [14:44] Binary files amd64/usr/lib/syslinux/modules/efi64/hdt.c32 and i386/usr/lib/syslinux/modules/efi64/hdt.c32 differ [14:44] Binary files amd64/usr/lib/syslinux/modules/efi64/sysdump.c32 and i386/usr/lib/syslinux/modules/efi64/sysdump.c32 differ [14:44] that's the complete diff -ru [14:44] that might just be non-reproducibility [14:44] doko: Ahh, didn't think the triplet case. Check. Thanks. [14:46] it's probably OK [14:46] and it was arch all until recently [14:47] indeed it's arch all again in unstable now [14:52] rbasak: Right, Colin's cherry-picking that change from Debian, so that solves that. [14:52] ok, yeah. I'll take that bug then [14:52] Oh, OK. Thanks! [14:53] I will follow up on the QA side of this though. If it's important, it should have been flagged months ago. [15:14] 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] infinity: i'm barely around. What's up? [15:15] * xnox should stop idling on irc when i'm not available. [15:15] xnox: I don't remember, so it can't have been important. [15:15] xnox: But I bet slangasek would like to yell at^W^Wtalk to you. [15:16] infinity: are you on the right side of the pond to meet up and have dinner this week? [15:16] xnox: On the left side. [15:16] xnox: he's on the left side of the pond [15:16] xnox: also, please to be fixing plymouth [15:16] slangasek: i've noticed that you push overwrote plymouth branches. I haven't checked yet, what happen there. [15:17] slangasek: i'm using 14.04 LTS and plymouth works great there =))))) [15:17] "push overwrote"? [15:17] xnox: yes, plymouth works great in 14.04, which is the release you didn't break it in :-P [15:17] slangasek: was bad or really bad? [15:18] xnox: A little from column A, a little from column B. [15:18] 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:18] bug 1362333 in ubiquity (Ubuntu) "After reboot of Ubuntu installation, password for LVM encryption is not accepted" [Undecided,Confirmed] https://launchpad.net/bugs/1362333 [15:19] 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] slangasek: with upstart or systemd. [15:19] xnox: upstart. [15:19] xnox: upstart, unless someone snuck in a change to the default init that I didn't notice ;) [15:19] slangasek: i see a useful upload from andy. Did apw upstream that? [15:20] ah, it's a cherry-pick, so yes. [15:22] xnox, ahh that one, yes it was upstream fixy fun [15:24] 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] xnox: PS, there's a release in 3 days. === _salem is now known as salem_ [15:42] doko: FYI, perhaps you already saw that - https://www.mail-archive.com/linaro-toolchain@lists.linaro.org/msg04529.html [15:59] ppisati, are we expecting to see that "limit" come down through stable into older releases ? [16:05] apw: the gcc limit? it should [16:05] ugg [16:05] apw: and it seems T is affected - http://pastebin.ubuntu.com/8603452/ [16:06] 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] doko, i hope you will know ;) === salem_ is now known as _salem === cody-somerville_ is now known as cody-somerville === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === _salem is now known as salem_ [18:14] pitti: hey, can we discuss adt with device constraints? [19:25] hey guys, i am making some changes in ubiquity, how do you test it? [19:42] voldyman: You might have more luck getting an answer in #ubuntu-installer. === flufl is now known as barry [20:41] 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] xnox: and apparently I don't understand the semantics of POSIX shell 'read' [20:52] stgraber, can i get added to https://launchpad.net/~ubuntu-qa-website-devel/+members? [20:52] tedg: ping on https://bugs.launchpad.net/ubuntu/+source/ido/+bug/1382020 [20:52] Ubuntu bug 1382020 in ido (Ubuntu) "ido ftbfs in utopic" [High,Confirmed] [20:53] redirect ping bregma ^ [20:53] Oh, he's not online. That's a good trick. [20:53] * tedg 's IRC Kung-Fu is weak [20:54] doko, bregma was going to look into the xorg-gtest because it seems to not compile. [21:04] brendand: why? [21:05] (that's a privileged team with admin access over iso.qa.ubuntu.com, so I need a good reason :)) [21:05] 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] stgraber, i'm re-evaluating the qa tracker to be used again by QA [21:06] stgraber, i'd like to play around with the dev instance - http://iso.qa.dev.stgraber.org/ [21:06] stgraber, i won't touch production - balloons will back me up [21:21] stgraber, ? [21:24] brendand: try logging in again now [21:24] brendand: in theory I've given admin access to canonical-platform-qa on the staging instance [21:25] stgraber, great thanks === salem_ is now known as _salem