| TheClitCommander | rww, whats up | 02:20 |
|---|---|---|
| TheClitCommander | rww, hi | 02:20 |
| === sgnb` is now known as sgnb | ||
| pitti | Good morning | 10:40 |
| 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:56 |
| pitti | infinity, stgraber ^ FTR (otherwise I'll invent something) | 10:57 |
| wgrant | pitti: Sure, let me see. | 12:05 |
| 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:39 |
| ubottu | bug 1382524 in autodep8 (Ubuntu) "[MIR] autodep8" [Undecided,New] https://launchpad.net/bugs/1382524 | 12:39 |
| roaksoax | win 13 | 12:40 |
| === _salem is now known as salem_ | ||
| infinity | pitti: Lemme look. | 12:43 |
| infinity | pitti: No-brainer indeed. Approving and promoting. | 12:44 |
| pitti | infinity: ack, thanks | 12:57 |
| === doko_ is now known as doko | ||
| === salem_ is now known as _salem | ||
| === Spads_ is now known as Spads | ||
| 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:49 |
| cjwatson | well except that there's no syslinux-common on anything other than amd64/i386 nowadays | 13:50 |
| * rbasak looks | 13:53 | |
| cjwatson | mvo: has anyone brought https://launchpad.net/bugs/1347834 to your attention yet? | 13:53 |
| ubottu | Ubuntu bug 1347834 in ubuntu-release-upgrader (Ubuntu) "UnboundLocalError: local variable 'e' referenced before assignment in doUpdate, line 924" [Undecided,Confirmed] | 13:53 |
| mvo | cjwatson: no, sorry, I have a look right now | 13:53 |
| === Guest4574 is now known as mfisch | ||
| cjwatson | mvo: ta | 13:59 |
| === timrc-afk is now known as timrc | ||
| rbasak | * For the time being, Marking all packages as amd64 and i386 only | 14:03 |
| rbasak | instead of any. | 14:03 |
| rbasak | syslinux (3:6.03~pre18+dfsg-1) | 14:04 |
| rbasak | Some multiarch magic might be needed here. | 14:04 |
| 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:05 |
| 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:06 |
| lutostag | rbasak: I dont think we do, it seems like something we do one-offs for due to lack of machines | 14:08 |
| rbasak | lutostag: do you know how much we care about this problem? | 14:11 |
| lutostag | rbasak: not sure how much of an impact it has... | 14:12 |
| rbasak | lutostag: AIUI, it means it's impossible for a non-Intel arch machine to be a cluster controller right now. | 14:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| === quadrispro_hds is now known as quadrispro | ||
| 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:17 |
| 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:18 |
| 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:19 |
| rbasak | roaksoax: what's your opinion on this? | 14:20 |
| roaksoax | rbasak: otp | 14:21 |
| rbasak | ok | 14:21 |
| rbasak | cjwatson: understood, thanks. | 14:21 |
| roaksoax | rbasak: so you are saying maas does not install on arm? | 14:23 |
| roaksoax | rbasak: due to recent changes in syslinux packaging? | 14:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| infinity | doko: That python2.7 upload looks like a no-op to me, since ^gcc always matched regardless? | 14:37 |
| 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:38 |
| rbasak | Filed bug 1383332 | 14:39 |
| ubottu | bug 1383332 in maas (Ubuntu) "maas-cluster-controller is uninstallable on non-Intel architectures" [Undecided,New] https://launchpad.net/bugs/1383332 | 14:40 |
| === Spads_ is now known as Spads | ||
| 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:41 |
| 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:42 |
| 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:44 |
| cjwatson | it's probably OK | 14:46 |
| cjwatson | and it was arch all until recently | 14:46 |
| cjwatson | indeed it's arch all again in unstable now | 14:47 |
| 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:52 |
| rbasak | I will follow up on the QA side of this though. If it's important, it should have been flagged months ago. | 14:53 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| ubottu | 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:18 |
| 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:19 |
| xnox | ah, it's a cherry-pick, so yes. | 15:20 |
| apw | xnox, ahh that one, yes it was upstream fixy fun | 15:22 |
| 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:24 |
| infinity | xnox: PS, there's a release in 3 days. | 15:25 |
| === _salem is now known as salem_ | ||
| ppisati | doko: FYI, perhaps you already saw that - https://www.mail-archive.com/linaro-toolchain@lists.linaro.org/msg04529.html | 15:42 |
| apw | ppisati, are we expecting to see that "limit" come down through stable into older releases ? | 15:59 |
| 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:05 |
| 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 ;) | 16:06 |
| === 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_ | ||
| sergiusens | pitti: hey, can we discuss adt with device constraints? | 18:14 |
| voldyman | hey guys, i am making some changes in ubiquity, how do you test it? | 19:25 |
| TheMuso | voldyman: You might have more luck getting an answer in #ubuntu-installer. | 19:42 |
| === flufl is now known as barry | ||
| 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:41 |
| 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:52 |
| ubottu | Ubuntu bug 1382020 in ido (Ubuntu) "ido ftbfs in utopic" [High,Confirmed] | 20:52 |
| 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:53 | |
| tedg | doko, bregma was going to look into the xorg-gtest because it seems to not compile. | 20:54 |
| stgraber | brendand: why? | 21:04 |
| 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:05 |
| 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:06 |
| brendand | stgraber, ? | 21:21 |
| 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:24 |
| brendand | stgraber, great thanks | 21:25 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!