[00:17] <Unit193> ^^ Died
[00:18] <wrst> what???
[00:19] <Unit193> Er... Not actually, just timeout and that's IRC death
[00:20] <Unit193> wrst: Woops, not the best wording it seems
[00:21] <wrst> OK whew I was worried
[00:24] <wrst> :)
[00:24] <Unit193> Talk to her much?
[00:25] <Unit193> Oh, and she doesn't hate me :D  Searched for me before I searched for her :P
[00:32] <wrst> she helps us out with LoCo issues very helpful
[00:34] <Unit193> I know her from something else, but she's your LoCo contact person :D
[00:35] <wrst> yep
[00:51] <cyberanger> Unit193: Microsoft bob, hang on
[00:54] <cyberanger> Unit193: http://toastytech.com/guis/bob.html
[01:05] <linuxman410> wrst u here
[01:05] <linuxman410> cyberanger u here
[02:00] <wrst_> hmm linuxman410 just gave that a look, looks pretty normal as far as hardware
[02:01] <wrst> linuxman410: grub issues?
[02:02] <linuxman410> wrst it just goes to blank screen
[02:02] <wrst> after grub?
[02:03] <linuxman410> wrst it does not even show grub
[02:03] <wrst> hmm weird
[02:03] <wrst> what distro?
[02:04] <linuxman410> ubuntu 11.04 alternate install
[02:05] <wrst> hmm weird looks like it should work really well with that unless something weird with the video
[02:06] <Unit193> You have to hit shift to see grub
[02:07] <Unit193> Left Shift
[02:07] <linuxman410> wrst i put bodhi on it based on 10.04 and it runs good
[02:29] <Unit193> Peer isn't very nice...
[02:30] <linuxman410> wrst i hit left shift no grub


[17:43] <fosburg> Type 1 fonts; Question, Adobe type one fonts are for windows and MAC, what OS for type 1 fonts is used for Linux--Ubuntu?
[17:46] <fosburg> Will Adobe Type 1 (MAC) fonts work with a Linux OS?
[18:22] <maco> better off asking in #ubuntu, more people
[18:35] <fosburg> Ok, I try that. Thanks


[00:00] <cjwatson> huh, you're right, I have a very very distinct memory of discussions about that in Seville though
[00:00] <cjwatson> maybe it was something related but subtly different
[00:01] <cjwatson> oh, perhaps udev-lvm-mdadm-evms-gutsy
[00:02] <cjwatson> heh, yes, https://blueprints.launchpad.net/ubuntu/+spec/udev-lvm-mdadm-evms-gutsy is definitely worth looking at in conjunction
[00:17] <slangasek> # In Ubuntu uploads should go to precise
[00:17] <slangasek> yes, they should all go to precise
[00:18]  * slangasek stabs the language center of his brain harder
[00:19] <infinity> slangasek: Yeah, I don't think I'll ever get used to it.
[00:20] <infinity> Maybe we can get a perky == precise hack into launchpad, and upload to the correct suite. :)
[00:29] <cjwatson> it took me three months to stop typing interpid.
[00:34] <infinity> I remember a lot of rejected "gusty" uploads.
[00:35] <cjwatson> oh, yeah, that too
[00:35] <slangasek> heh
[00:35] <slangasek> dch -r, dudes :P
[00:38] <cjwatson> I wasn't always in the habit of editing /usr/bin/dch locally before I got round to upgrading to the next release
[00:38] <cjwatson> (I am now)
[00:38] <slangasek> ah :)
[01:30] <cjwatson> skaet: is this a true candidate tomorrow - should we ensuring that base-files and the CD volume labels are final?
[01:30] <cjwatson> or just a smoke test?
[01:30] <cjwatson> *should we be
[01:31] <cjwatson> ReleaseProcess doesn't indicate that we should be doing so until Monday
[01:31] <cjwatson> so I guess I'll just go to bed, somebody else can deal with that if it's needed :)
[01:31] <cjwatson> debian-installer and ubiquity uploaded, hopefully at least conceivably final
[01:36] <stgraber> cjwatson: good night!
[03:23] <ScottK> infinity and Daviey: Thanks for looking into memcached.
[03:43]  * infinity puzzles over both the weird version on that postfix upload and the really quick accept...
[03:43] <infinity> Who accepted that?
[03:44]  * infinity wonders if lamont accepted his own upload...
[03:45] <lamont> infinity: I did not
[03:45] <lamont> OTOH, I haven't exactly finished updating the debian chroot to build the upload for debian
[03:45] <infinity> lamont: It would seem that no one else is speaking up either. :P
[03:46] <micahg> lamont isn't an AA AFAIK
[03:46] <lamont> and that's a perfectly valid "yeah, just import over me" version number
[03:46] <lamont> micahg: I have a duck
[03:46] <infinity> micahg: lamont is a duckie, he has full LP access.
[03:46] <lamont> OTOH, AA stuff scares me enough to just avoid it entirely
[03:46] <micahg> lamont: I know, but I don't see you as the type to abuse it :)
[03:46] <infinity> lamont: While you're in a package maintaining mood, RT#48330? :)
[03:47] <stgraber> skaet: just so you know, I just found what looks like a python-gevent bug breaking weblive for Oneiric systems (possibly limited to these with IPv6 connectivity). Only Edubuntu ships with python-x2go/python-gevent by default but we'll likely want that working in the release (as it's advertised in the install slideshow).
[03:47] <infinity> micahg: Yes, lamont's never abused access to anything in his life. ;)
[03:48] <lamont> infinity: give it some relationship to 48181?  I'd be inclined to shrug if you went in and said 48181 depended on 48330
[03:48] <lamont> that argument holds at least some water
[03:48] <infinity> 48181?
[03:48]  * infinity looks.
[03:49] <lamont> I have one other zomfg ticket ahead of 48181, and I'm planning to have a weekend this week
[03:49] <infinity> I'm not sure I can argue that. :P
[03:49] <infinity> But it's a 2-line patch.
[03:49] <lamont> infinity: oh.  orthogonal activities?
[03:50] <infinity> lamont: Yeah.  48181 is an OEM one-off project, not proper armhf in Soyuz.
[03:50] <lamont> ok
[03:50] <infinity> lamont: 48330 is Soyuz.
[03:50] <infinity> (And needs doing between now and P, but I'd prefer to have all our ducks i na row well ahead of P, so I'm not panicking on opening day)
[03:50] <lamont> infinity: I've got pre-O craziness that wins over it.
[03:51] <ScottK> infinity: I accepted it.
[03:51] <lamont> OTOH, if you happened to have a source package that was based on -cat, that becomes much more of a slamdunk
[03:51] <infinity> ScottK: Mmkay.  Just seemed a bit quick.
[03:51] <infinity> lamont: I can do that.
[03:51] <lamont> infinity: it got built and tested in a ppa
[03:51] <lamont> postfix that is
[03:51] <ScottK> It was because I'd reviewed it before it was uploaded.
[03:51] <infinity> lamont: I realised the current -cat one was Colin's, not yours. :P
[03:52] <lamont> with ScottK poking me about it starting a couple days ago
[03:52]  * infinity wonders if he can still upload to archive.admin ...
[03:52] <lamont> pretty sure we removed that key
[03:52] <infinity> Oh, no, it was an scp queue, wasn't it?
[03:52] <lamont> yeah
[03:52] <infinity> Foiled.
[03:52] <infinity> lamont: I'll toss a fixed package on chinstrap.
[03:53] <lamont> cool.  ref it in the ticket, and etc, etc
[03:54] <lamont> fortunately, dpkg on the buildds is run inside the chroot, so we don't need a hardy version
[03:54] <lamont> and with that, way past my bedtime
[03:54] <infinity> lamont: Yeah, I know, I fixed that misfeature. ;)
[03:54] <infinity> lamont: Just need this for soyuz.
[03:54] <lamont> your homedir on osageorange is another option for where to drop it
[03:55] <infinity> What host is that?
[03:55] <infinity> New amd64 porter, I'm guessing?
[03:55] <lamont> porter box, should have a lucid-cat chroot on it
[03:55] <lamont> it's the new ronne
[03:55] <infinity> Yeah, I don't keep up.  Never use porter boxes.
[03:55] <infinity> I always have to look them up when I tell others to. :P
[03:55] <lamont> heh
[03:56] <micahg> there are aliases for them now
[03:56] <infinity> Oh?
[03:57] <micahg> infinity: porter-<arch>
[03:57]  * infinity just tried amd64.canonical.com amd64-porter.canonical.com and amd64.porter and gives up hope that it's intuitive. :)
[03:57] <lamont> MachineOverview
[03:57] <infinity> Oh, sure.
[03:58] <infinity> lamont: Looks like porter-armhf might need some DNS love (scheat)
[03:58] <infinity> Sure, it has no armhf chroots yet, but whatever. :P
[03:58] <lamont> bah
[03:58] <lamont> throw that at RT, it seems trivial to me
[03:58] <lamont> as in it'll just go through the vg queue and be done in a couple days
[03:59]  * infinity nods.
[03:59] <lamont> logging in would be work
[04:00] <lamont> and my day ended quite a while ago
[04:00] <infinity> So did mine. :P
[04:00] <lamont> heh
[04:05] <infinity> lamont: Uploaded to osageorange, changes is signed (on the off chance that the archive accepts my key?), and threre's a debdiff sitting there too.
[04:07] <stgraber> skaet: actually just spent a bit of time debugging that python-gevent thing now. It's a weird bug but actually very far from being critical (socket.getaddrinfo hanging for > 30s when one of your DNS servers doesn't answer)
[04:08] <ScottK> Sounds easy enough to fix though.
[04:09] <stgraber> pretty weird bug though. I have 3 DNS servers, two of them work fine, including the first one. getaddrinfo always returns within a second, except from python-x2go which uses python-gevent
[04:09] <infinity> lamont: And ticket updated to reflect that.
[04:09] <stgraber> trying to reproduce with just socket or gevent.socket won't get me the bug. Doing it from x2go, gets me the bug every time I try it
[04:09] <ScottK> What does it use for DNS?
[04:10] <stgraber> ScottK: http://paste.ubuntu.com/703175/
[04:10] <ScottK> Congratulations, BTW.
[04:11] <stgraber> weblive-appserv02.nx.stgraber.org, 6622, socket.AF_UNSPEC, socket.SOCK_STREAM are the parameters to socket.getaddrinfo() (added some debug in paramiko)
[04:11] <stgraber> thanks :)
[04:12] <pitti> Good morning
[04:12] <pitti> cjwatson: langpacks> I'll just remove the broken ones for now; need to investigate why the heck they are built without a corresponding -base
[04:12] <infinity> pitti: Mornin'.
[04:13] <pitti> skaet: langpacks will be uploaded tomorrow; they weren't meant to be on the RC (but current images have Tuesday's langpacks, so are reasonably current for testing)
[04:16] <infinity> pitti: I'm waiting on a final apt upload from mvo for RCish images anyway.
[04:16] <infinity> pitti: Well, for ARM, that is.  You can spin others before, if you like. ;)
[04:17] <pitti> seems we still have the daily cron jobs even
[04:17] <pitti> https://wiki.ubuntu.com/OneiricOcelot/ReleaseTaskSignup doesn't have someone responsible for RC2, but as we don't release it, I guess the only thing that we need doing is spinning images and posting them to the tracker for QA?
[04:18] <infinity> Yeah, we're not releasing.  So, whatever.
[04:18] <infinity> Also heard rumours that we won't start calling things RC until after the weekend.
[04:19] <ScottK> stgraber: For a test you might switch the failing call in dns.py to use python-dns or python-dnspython.  That would at least give you an idea if if the issue was in the code below that call.
[04:19] <pitti> oh, so we could still accept fixes today?
[04:19] <infinity> Yeah.
[04:19] <ScottK> I would.
[04:19] <ScottK> In fact I did a few minutes ago.
[04:19] <pitti> e. g. I have https://code.launchpad.net/~jbicha/ubuntu/oneiric/jockey/update-help-link/+merge/77782, which is a trivial and obvious fix for broken help button
[04:19] <infinity> Well, we can accept fixes until release day, but we pretty obviously don't want to unless they're critical. :P
[04:19] <infinity> pitti: Do it.
[04:19] <pitti> (due to the ubuntu-docs reorg)
[04:20] <pitti> well, not exactly critical, but very low-risk (arch: all package, and all that)
[04:20] <ScottK> Sounds like the kind of final polish we should have.
[04:20] <infinity> pitti: I don't think the team as a whole is committed to being in RC mode until the sprint, which starts Monday morning.
[04:20] <pitti> ScottK: yeah, I agree
[04:20] <pitti> but RC on Monday sounds fine to me; we'd still want some urgent fixes in, if we can get them
[04:20] <infinity> pitti: So, I think it's sane to get base-files and such in over the weekend, turn off dailies Monday morning, and go from there.
[04:21] <pitti> sounds fine
[04:21] <pitti> so a REAL release candidate for the first time? :-)
[04:21]  * infinity crosses his fingers.
[04:22] <pitti> we should still get the current dailies some testing, though, to spot some OMG installer problems
[04:22] <infinity> I've kind of come to the conclusion that I just have to live with any ARM bugs we find from here on.
[04:22] <infinity> THough I'm really, really tempted to hack up oem-config to stop/start (ana)cron before/after the install.
[04:22] <infinity> The regression potential for messing that up isn't worth it, though.
[04:23] <ScottK> pitti: If you have a free moment today, I think KDE 4.6.5 is sufficiently aged to move to natty-updates.
[04:23] <pitti> ScottK: yep, will do
[04:23] <ScottK> Thanks.
[04:23] <pitti> I'll have a look today why evolution-exchange is uninstallable
[04:24] <pitti> slangasek, infinity, ogra_: do you know about all the linaro kernels on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt ?
[04:25] <pitti> they are also shown as being uninstallable on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html (some of them)
[04:25] <pitti> should they be in main and are missing some seeding/metapackages, or demoted?
[04:42] <infinity> pitti: vexpress and omap4 are used by d-i.. That may need some seeding, if things aren't smart enough to sort that out.
[04:43] <infinity> pitti: linaro-mx51 can go to universe, as can st1-5, unless we have a support commitment there I'm not aware of (we certainly don't use them for images)
[04:43] <infinity> pitti: linaro-omap as well.
[04:45] <infinity> pitti: Might need Colin's input on vexpress.  I can chase down the rest.
[04:45] <pitti> hm, indicator-datetime went to oneiric-proposed
[04:45] <pitti> could just as well have gone to final, I guess?
[04:46] <infinity> Oh, I didn't even notice the pocket on that one...
[04:48] <pitti> http://launchpadlibrarian.net/82049869/indicator-datetime_0.3.0-0ubuntu1_0.3.0-0ubuntu2.diff.gz looks safe enough to me, anyway, and it affects the live system
[04:48] <pitti> infinity: I can remove the proposed package and reupload to oneiric?
[04:48] <infinity> pitti: yeah, please do, I didn't notice the suite when I accepted it.
[04:48] <pitti> roger
[04:48] <micahg> pitti: you'd have to bump the version
[04:49] <pitti> micahg: yeah, I won't retrofit the changelog
[04:50] <infinity> pitti: don't accept that u-boot to proposed either, I'm going to grill jcrigby about why he didn't want that in release.
[04:51] <pitti> infinity: *nod*
[04:51] <infinity> pitti: Actually, better idea, maybe I'll reject it from -proposed, so I can talk to him about it without someone else accepting it. :P
[04:53] <infinity> pitti: Oh, I suppose u-boot-linaro-mx53loco can go to universe, we're building mx53 from universe anyway.
[04:53] <infinity> (Though it comes from main sources, so I could just as easily seed it)
[04:53] <infinity> I've always found the source-in-main-binary-in-universe thing kinda messed up. :/
[04:56]  * infinity fixes some kernel seeds.
[04:56] <pitti> ok, let's see what's left after your seed changes
[05:00] <infinity> pitti: Updated, if you want to manually trigger a mismatches check.
[05:01] <pitti> infinity: I'll just wait for cron, before I break anything
[05:01] <infinity> pitti: Wuss. ;)
[05:01] <pitti> infinity: so you seeded mx53 only? mx51, st1-5, and omap should still go to universe?
[05:02] <infinity> pitti: mx53 is in universe, and should stay there (the u-boot can go).
[05:02] <infinity> pitti: I fixed up seeds for omap, vexpress, and omap4 for main, and mx51 and st1-5 can go.
[05:02] <pitti> ah, good
[05:02] <pitti> still wondering why their sources are in main
[05:03] <infinity> Who knows.
[05:03] <stgraber> ScottK: http://paste.ubuntu.com/703195/
[05:03] <pitti> demoting, of course I just missed the publisher
[05:03] <infinity> I'm wondering why linaro-omap is in main when the images use -omap, but I need to talk to Colin about that, since he builds d-i for both.
[05:03] <stgraber> ScottK: at least I'm pretty sure it's a gevent weirdness now :)
[05:04] <ScottK> Yeah.
[05:18] <infinity> pitti: You can remove libreoffice-gcj too, it's NBS.
[05:19] <pitti> weird, why it isn't on http://people.canonical.com/~ubuntu-archive/nbs.html ..
[05:19] <infinity> Probably because it's still in the .dsc and NBS isn't smart.
[05:19] <infinity> It's conditionally built.
[05:19] <pitti> aah
[05:19] <infinity> And not on any of our architectures.
[05:19] <pitti> presumably for backports
[05:19] <infinity> No, for arches that use gcj instead of openjdk.
[05:19] <infinity> We just don't ship any of those. :P
[05:20] <pitti> cheers, doing
[05:20]  * infinity finds http://people.canonical.com/~ubuntu-archive/testing/oneiric_outdate.txt helpful for stuff like that.
[05:20] <micahg> Ubuntu freebsd coming any time soon? :D
[05:20] <infinity> When one package from a source is out-of-date, you know something's up. ;)
[05:22] <nigelb> micahg: Tomorrow's headlines - "Ubuntu developer membership board member wonders when Ubuntu freebsd is coming out"
[05:23] <micahg> nigelb: context FTW :)
[05:23] <infinity> pitti: ibmasm-utils and msr-tools can be removed on armel and powerpc (should have been done in natty, no one noticed)
[05:23] <nigelb> micahg: Heh. :)
[05:24] <infinity> pitti: All those pings combined, and two buildds catching up, and armel will be completely up-to-date again.    Weren't we meant to do something about that kdesdk/ppc build failure?
[05:27] <infinity> ScottK: I reproduced it but didn't have the time to debug. :/
[05:27] <ScottK> Yes.  You were going to fix it ...
[05:28] <infinity> I was going to fix it?
[05:28] <infinity> Really?
[05:28] <ScottK> Yes.
[05:28] <infinity> Lies and subterfuge.
[05:28] <ScottK> I'm sure you volunteered.
[05:28] <micahg> infinity: I'm in the same boat as you :)
[05:28] <ScottK> I know it's way too complicated for me.
[05:28] <infinity> Ugh.
[05:28] <infinity> Can it please not be CMake?
[05:29] <micahg> infinity: a generated file doesn't seem to work on powerpc
[05:29] <infinity> micahg: And by 'work' you mean 'exist'.
[05:29] <micahg> right
[05:30] <infinity> And yeah, I got that far before I got busy.
[05:30]  * infinity updates his oneiric chroot to have another poke with a sharper stick.
[05:32] <ScottK> The python-defaults upload that is about to appear only has minor changes from what we have now, but it lines us up with what's supposed to push the python2.7 transition into Debian Testing today, so I think it'd be good so have that for release.
[05:32] <ScottK> That one.
[05:33] <infinity> I'll look at it when it gets diffy.
[05:34] <ScottK> Thanks.
[05:35] <ScottK> Kubuntu alternates all fit again.
[05:35] <infinity> pitti can fix that.
[05:35] <ScottK> Somehow they grew 10MB yesterday to I had to strip some lang packs off.
[05:36] <pitti> ScottK: most likely https://launchpad.net/ubuntu/+source/kubuntu-docs/11.10ubuntu2 ?
[05:36] <ScottK> Yes.  That would do it.
[05:36] <ScottK> But notice what pocket that's in.
[05:36] <ScottK> It wasn't supposed to be accepted yet.
[05:36] <micahg> xubuntu alternates are 10MB larger as well
[05:37] <infinity> Did we get a kernel image suddenly bloating or something?
[05:38] <ScottK> And kubuntu-doc is on both live and alternate, so it wouldn't have affected both.
[05:38] <infinity> ScottK: It was only your alternates that grew?
[05:38] <ScottK> Yes.
[05:38] <pitti> ScottK: eww, missed that; straight to -updates?
[05:38] <infinity> So, something d-i-ish, or something in your ship seed.
[05:39] <infinity> And something in common with xubuntu.
[05:39] <infinity> This is a fun game.
[05:39] <ScottK> Yep.
[05:39] <pitti> ScottK: we also got new delta langpacks on Tuesday, which will shrink again tomorrow when we do a -base refresh
[05:39] <micahg> usually the langpacks do this when stuff moves between base and non-base
[05:39] <ScottK> Fortunately the alternates have language packs to remove.
[05:39] <ScottK> Maybe that was it.
[05:39] <pitti> ScottK: so if you add up the size of all language-pack-XX on the images, that's what will go away on Saturday's images
[05:41] <ScottK> Easy enough to put them back if we get more room.
[05:42] <pitti> ScottK: so, about the kubuntu-docs blunder, sorry about that; should we reupload the previous version, and the current one to -proposed?
[05:42] <ScottK> The biggest reason to wait was fear that the added translations would make it too big.
[05:43] <ScottK> Since we aren't over on the live CD, I think we can leave it.
[05:43] <ScottK> I was suprised Riddell uploaded it so soon if it was for updates.
[05:51] <infinity> ScottK: Your CDs shouldn't be building against updates anyway.
[05:51] <infinity> ScottK: Check your manifests, that package shouldn't be there.
[05:52] <ScottK> It's there.
[05:52] <infinity> Really?
[05:52] <ScottK> Yep.
[05:52] <infinity> That's a bug in our code, then. :P
[05:52] <infinity> Well maybe a misfeature.
[05:52] <infinity> Since we build against updates for point releases.
[05:52] <ScottK> I don't think so.  I think we normally build against updates, it's just usually empty.
[05:52] <infinity> And I guess maybe we're expecting (incorrectly) that updates is empty on release. ;)
[05:53] <ScottK> We used it last cycle to fix a dvd seed problem by uploading kubuntu-meta to -updates and then just respinning the dvd.
[05:53] <ScottK> That way the CDs weren't out of date at release ...
[05:54] <ScottK> Nice trick, eh?
[05:54] <ScottK> I think pitti thought of it.
[05:54] <pitti> I still remember that one
[05:55] <pitti> I'm not surprised that -updates lands on images, it's just strange to have it
[05:55] <pitti> in all but that one case we have used zero-day SRUs for fixing major upgrade bugs
[05:55] <pitti> which don't affect images
[06:01] <cjwatson> Yeah, we've used that trick a couple of times
[06:02] <pitti> hey cjwatson  -- early for you :)
[06:02] <infinity> Up to and including making sure openssl-blacklist DIDN'T land on CDs because it was too effin' huge.
[06:02] <infinity> That was entertaining.
[06:02] <infinity> cjwatson: Want to check the lightdm in the queue, since it relates to your pet bug?
[06:03] <cjwatson> pitti: Thursdays are odd for me, toddler sign class
[06:03] <cjwatson> (and believe me I'm not happy to be awake)
[06:04] <infinity> Beer.
[06:05] <infinity> Some may argue it's too early to drink, but in your world, it's probably more late than early.
[06:08] <cjwatson> lightdm> still doesn't look like an entirely proper fix to me (overrides PAM), but it looks OK
[06:08] <cjwatson> and somebody else seems to have beaten me to it
[06:08] <cjwatson> I hadn't tested the previous one yet ;-)
[06:09] <ScottK> I think it's officially late here.  Good night.
[06:09] <infinity> Night.
[06:14] <slangasek> pitti: I know nothing about current linaro kernel packages, sorry
[06:14] <infinity> slangasek: I sorted it.
[06:14] <infinity> Ish.
[06:19] <infinity> Someone verify that I can spell "oneiric" correctly and accept jasper?
[06:21] <pitti> one-eye-rick looks fine; accepted
[06:24] <infinity> That sounds vaguely dirty.
[06:25] <infinity> Right, I remember the kdesdk failure.  structviewpreferences.h doesn't exist, and ISN'T REFERENCED FROM THE BUILD SYSTEM AT ALL.
[06:26] <infinity> (I'm not bitter)
[06:26] <infinity> Friggin CMake.
[06:26] <micahg> infinity: it's supposed to be generated by a .kcfg file IIRC
[06:27] <infinity> Yeah, I have no clue how any of that works. :P
[06:27] <micahg> me neither :P
[06:54] <doko> do we already accept uploads for -proposed?
[06:59] <infinity> pitti: Oh, the other issue with those mismatches is linux-meta-linaro being crufty.  I need to talk to jcrigby about that, since not all the linaro sources are in sync. :/
[07:01] <infinity> cjwatson: And on the topic of ARM kernels, is there a reason for the linaro-omap d-i build alongside the -omap one?
[07:01] <infinity> cjwatson: (That you know of?)
[07:02] <cjwatson> infinity: I just do what I'm told.  But both of them are in d-i right now, so let's keep them both for oneiric ...
[07:02] <infinity> Yeah, I wasn't planning to change it, was just curious if you had a rationale.
[07:02] <cjwatson> doko: -proposed can always be uploaded to from the moment a series opens
[07:02] <cjwatson> doko: whether anyone will process it ... :-)
[07:03] <cjwatson>   * Add linaro-omap netboot target to armel images, copied from versatile;
[07:03] <cjwatson>     this is useful for all OMAP2+ boards supported in this kernel.
[07:03] <cjwatson> was for linaro-omap - that was lool
[07:03] <cjwatson> I don't really want to know, I just let y'all shuffle kernels around
[07:05] <infinity> cjwatson: Heh.
[07:06] <jbicha> will there be an actual milestone RC like the Betas or is RC just test builds for final?
[07:07] <infinity> jbicha: The latter.
[07:08] <jbicha> infinity: thanks, that's how I read the schedule but just wanted to verify
[07:10] <cjwatson> slangasek: do we want to ditch stderr from 'modprobe -q vesafb' in your recent initramfs-tools change?  I've noticed that my live CD boots in kvm have started showing "FATAL: Error inserting vesafb (/lib/modules/3.0.0-12-generic/initrd/vesafb.ko): No such device" on the console, which seems untidy and may alarm people
[07:13] <slangasek> cjwatson: mmm yes - sorry for not catching that
[07:30] <lool> infinity: we can chat about OMAP flavors if you like
[07:31] <lool> infinity: There was also a linaro-vexpress build which got disabled due to some missing kernel configs a while ago (that actually just got fixed); both of the linaro-* builds are suitable for running with qemu-linaro or on real hardware
[07:31] <lool> the linaro-omap one targets OMAP3 and OMAP4
[07:31] <lool> I think we could do without the OMAP build entirely, but that's not really Linaro's decision to make
[07:32] <infinity> lool: We'll chat about flavours after release. :)
[07:32] <infinity> lool: Not inclined to do anything about it right now, we'll go with what we have.
[07:38] <pitti> so seems some linaro kernels are still missing something: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[07:38] <infinity> pitti: meta issues.  Scroll up and check nick hilights.
[07:39] <infinity> pitti: I'll sort it with jcrigby tomorrow.
[07:39] <pitti> ok, thanks
[07:51] <pitti> libgdata is FTBFS (probably link ordering), looking
[07:53] <infinity> slangasek: \o/
[08:07] <pitti> ^ trivial FTBFS fix, review appeciated
[08:10] <jbicha> pitti: I noticed the FTBFS because I was going to make libgdata-dev depend on its gir
[08:12] <infinity> jbicha: Would you still like to make that change?
[08:12] <infinity> jbicha: You can grab pitti's source from the queue and then I can reject it. ;)
[08:12] <pitti> I can reject the current upload
[08:12] <pitti> infinity: all in bzr
[08:12] <pitti> jbicha: ^
[08:12] <infinity> pitti: Crazy talk.  You kids and your fancy bizedares.
[08:14] <pitti> ^ simple installability fix, review appreciated
[08:16] <pitti> jbicha: libgdata upload rejected, and uncommitted the release tag in bzr to pretend it never happened :)
[08:17]  * infinity decides to try to get some sleep tonight.
[08:17] <infinity> Toodles, everyone.
[08:17] <pitti> sleep well!
[08:18] <pitti> jbicha: doing the dependency change now
[08:19] <pitti> ... and reuploaded
[08:19] <jbicha> pitti: thank you
[08:21]  * ogra_ wonders why omap4 images suddenly try to install oem-config-kde
[08:21] <ogra_> (and fail badly)
[08:22] <ogra_> was there any seed change ? we never had that package installed
[08:27] <ogra_> hrm, i should probably learn to read before talking, ignore me
[08:35] <ogra_> pitti, can we hold back on arm images until after the arm meeting today, i have no info about the banshee breakage from NCommander yet and dont know iff we need a seed change (to rhythmbox) or not
[08:35] <ogra_> (which indeed in turn will require a meta upload)
[08:35] <infinity> ogra_: We're not spinning RC until the end of the weekend.
[08:35] <infinity> ogra_: It's just dailies as usual for now.
[08:35] <ogra_> oh ?
[08:36] <ogra_> why is that ?
[08:36] <infinity> Just seemed to be the general concensus around here.
[08:36] <infinity> And the release sprint starts Monday morning, so that seems like a sane time to turn off the cronjobs and roll up our sleeves.
[08:37] <ogra_> k, well, kate told me she wanted images during the day ... that was my last update
[08:37] <pitti> well, we still get dailies
[08:37] <infinity> ogra_: omap4 images installing oem-config-kde?  where?
[08:37] <pitti> jibel: is the auto-tester for dailies running?
[08:37] <ogra_> infinity, in the kubuntu build that failed
[08:38] <pitti> i. e. do we get notified if something really breaks?
[08:38] <infinity> ogra_: Oh, well that sort of makes sense in kubuntu.
[08:38] <ogra_> infinity, i hadnt finished my first coffee ...
[08:39] <infinity> ogra_: But yeah, the failure is just the usual ubiquity-out-of-sync issue.
[08:39] <ogra_> and evo crashes badly if i scroll down to the bottom of the log so i didnt really regard the subject line while trying to scroll as slow as possible to actually see the end of the log
[08:39] <ogra_> one day i need to switch to TB or file a bug for evo about that :P
[08:44] <pitti> ugh, http://people.canonical.com/~ubuntu-archive/component-mismatches.txt just exploded
[08:44] <pitti> did we just get a new nova? (didn't see one), or was there some seed change?
[08:44] <pitti> Daviey: ^
[08:44] <jibel> pitti, yes it is running. is your intention to really break something today ?
[08:45] <pitti> jibel: not just today!
[08:46]  * pitti promotes cobbler-enlist
[08:50] <Daviey> pitti: Hmm.. that will be my fault.
[08:52]  * Daviey fix0rs
[08:53] <pitti> Daviey: cheers
[09:03] <Daviey> pitti: When it refreshes, it should just be tgt and it's children, which fell out of main this cycle - but should be there.
[09:03] <Daviey> bug 594372 is the old MIR, can you promote it when it's clear what needs nbumping?
[09:03] <ubot4> Launchpad bug 594372 in tgt (Ubuntu Maverick) (and 7 other projects) "MIR: tgt (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/594372
[09:04] <pitti> Daviey: can do
[09:04] <Daviey> thanks.
[09:05] <Daviey> i thought c-m's used to generate every 15mins or so, seems to be hourly now :(
[09:06] <pitti> Daviey: has always been hourly, as it needs to wait for publisher
[09:10] <nigelb> 45
[09:10] <pitti> nigelb: off by three
[09:10] <nigelb> pitti: heh, ironically, I was indeed looking for /window 42 :)
[09:17] <pitti> cjwatson, Daviey: could either of you please review my libgdata and evolution-exchange uploads?
[10:12] <pitti> Daviey: I just did the necessary promotions/demotions for nova
[10:12] <pitti> c-m should look better in ~ 1.5 hours
[10:35] <pitti> ScottK: any idea what to do with kdesdk's kdesvn dependency? should that get a very late MIR, or dependency dropped? (I remember that we had the same problem in ealier releases)
[10:36] <cjwatson> pitti: accepted libgdata and evolution-exchange
[10:36] <pitti> cjwatson: cheers
[11:55] <doko> pitti, ScottK: that should be gone. kdesdk did build now. somebody insisted to have to debug it on powerpc only
[11:56] <tumbleweed> bdrung: distro-info was picked up by lp, and I requested a sync. (someone please ack it)
[12:27] <Daviey> pitti: thanks
[12:50] <ScottK> doko: Thanks.
[12:58] <Laney> phppgadmin distro-info look ok to me
[13:10] <pitti> Laney: accepted
[13:11] <Laney> cheers
[13:11] <orava> Hi, when 11.10 RC will be available?
[13:36] <stgraber> good morning
[13:46] <ev> hiya
[13:47] <Daviey> 14:36 < stgraber> good morning <-- fail. it's the afternoon.
[13:48] <hggdh> Daviey: good morning ;-)
[13:57] <skaet> hiya
[13:58] <Laney> hey
[13:59] <kenvandine> hey skaet
[14:00] <skaet> pitti, have all the langpacks landed now?
[14:02] <skaet> ogra_, wat;s the background on the glade-3 armel translations sitting in the new queue?
[14:02]  * skaet scratching her head over them.
[14:02]  * ogra_ has no clue, first time i hear about it
[14:03]  * skaet figures to see if pitti knows where they've come from then....
[14:03] <cjwatson> the translations are not the things that are new.
[14:03] <cjwatson> I will review that
[14:03] <skaet> thanks cjwatson. :)
[14:03] <ogra_> package name changes ?
[14:03] <ogra_> 8or is that source-new we are talking about)
[14:04] <cjwatson> I will deal with it
[14:04] <ogra_> k
[14:04] <cjwatson> nor is it armel-specific btw
[14:04] <Laney> binary new; they added gtk2 variants
[14:04] <ogra_> aha
[14:05] <doko> who did accept libx86 and xen? just want to know how it was accepted (web UI or command line tol)
[14:06] <skaet> Daviey, nova fix in the queue from Robie,  are you reviewing and accepting it for the candidates?
[14:15] <cjwatson> pitti: your glade-3 3.8.0-0ubuntu2 upload said that glade-gnome is built by the glade source package now, but I don't see that.  Did you have a glade upload that you aborted when didrocks decided to reintroduce glade-gnome to glade-3?
[14:25] <stgraber> are we planning for a mass rebuild later today? otherwise I'd like to have a respin of Edubuntu to pick up the new ubiquity for testing.
[14:26] <skaet> stgraber, will go kick it off.
[14:26] <stgraber> thanks
[14:29] <skaet> its started now.
[14:34] <pitti> skaet: no, langpack export is starting tonight, will build them tomorrow morning
[14:35] <pitti> cjwatson: didrocks needed the gtk2 variant back for quickly
[14:35] <pitti> cjwatson: it's actually not called "glade-gnome" any more, just glade
[14:35] <cjwatson> pitti: so the mentioned glade change never happened?
[14:36] <cjwatson> pitti: didrocks' upload reintroduces a 'glade-gnome' binary package, that's why I'm asking
[14:36] <cjwatson> I wanted to make sure that wouldn't collide with a change to the glade source package
[14:36] <skaet> pitti, was wanting to get the candidates created with the langpacks today, so jibel could test them out tomorrow,  any options?
[14:37] <pitti> skaet: the export takes about 24 hours..; but when we discussed that a week or two ago it was fine?
[14:37] <didrocks> cjwatson: the paths are different, it's basically the same than libgladeui-common's one, with a different (glade3) path
[14:37] <skaet> pitti, I appear to have misunderstood.  I thought they'd be ready by today, not starting to export today.
[14:38] <cjwatson> sorry, I seem to be being unclear, I don't care about any of this stuff :)
[14:38] <cjwatson> pitti's previous upload implied that glade-gnome was being added as a binary to the glade source package
[14:38] <cjwatson> I want to make sure that didn't happen so that this glade-3 upload in NEW won't collide
[14:38] <cjwatson> I can read the rest of the rationale and such for myself
[14:38] <pitti> glade-gnome is not really meant to exist any more
[14:38] <pitti> in a GNOME 3 world
[14:39] <cjwatson> *sigh* is anyone actually going to answer my question? )
[14:39] <didrocks> cjwatson: there is no overwrite, if that's the question, it's gnome-common for the gtk2 glade flavor and libgladeui-common for the gtk3 glade
[14:39] <pitti> as all the widgets etc. are in GTK now
[14:39] <cjwatson> :)
[14:39] <cjwatson>   * debian/control: Drop glade and glade-gnome, they are built by the "glade"
[14:39] <pitti> cjwatson: so, glade-gnome is not meant to be built by the glade source
[14:39] <cjwatson>     source package now.
[14:39] <cjwatson> did this happen or did it not?
[14:39] <cjwatson> this should be yes or no
[14:39] <pitti> "yes" for the  glade binary, "no" for glade-gnome
[14:40] <pitti> and glade-gnome isn't meant to be built by glade
[14:40] <cjwatson> OK
[14:40] <pitti> so everything should be fine
[14:40] <cjwatson> thanks, that's all I wanted to know
[14:40] <pitti> but I don't know why didrocks introduced glade-gnome as well
[14:40] <pitti> didrocks: ^ are these the extra gnomeish widgets on top of glade-gtk2?
[14:40] <didrocks> pitti: right, it seems that some widgets in glade only show if we get this extra ones
[14:41] <didrocks> (in glade, like, in glade gtk2)
[14:41] <pitti> didrocks: yes, those are from the old "extra" gnome libs, all of which are obsolete in 3
[14:41] <pitti> cjwatson: so, as long as there are no file collisions, it shoudl be fine; want me to check?
[14:42] <didrocks> (there is not normally, I ensured that using the old glade3/ path instead of glade/)
[14:43] <cjwatson> pitti: it looks fine, but I'm sure a second pair of eyes wouldn't hurt.  The files are in cocoplum:/tmp/cjwatson/
[14:50] <doko> pitti, cjwatson: the kdesvn component mismatch isn't a real one. kdesdk depends on kdesdk-kio-plugins (>= 4:4.7.1-0ubuntu2) | kdesvn-kio-plugins. the former is in main
[14:53] <pitti> cjwatson: install well alongside glade binaries, debs look ok to me, and both the old and the new glade work
[14:54] <cjwatson> ok, and it can go in universe, can't it?
[14:54] <pitti> yes, as quickly is universe, too
[14:56] <cjwatson> ok, accepted then, thanks
[14:56] <pitti> thanks
[14:57] <mvo> if someone like cjwatson could review the apt upload, that would be great, it got some good review from mdeslaur and infinity already, but the more eyes the better
[15:03] <pitti> I'm afraid I'm mostly useless right now, my head is exploding (got a cold); I'll try to take a nap, back on TB meeting
[15:03] <pitti> please don't hesitate to call my mobile if something bad happens
[15:06] <skaet> ok pitti.   hope you feel better soon.
[15:29] <ev> RT 48349 is for a signed wubi
[15:35]  * skaet thanks whoever just reviewed glib2.0,  which appears to have the fix for bug 804946
[15:35] <ubot4> Launchpad bug 804946 in glib2.0 (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_variant_unref() (affects: 227) (dups: 83) (heat: 1020)" [Critical,Fix released] https://launchpad.net/bugs/804946
[15:36] <infinity> That was me.
[15:40] <skaet> :)
[15:51]  * Laney wonders if 12.10 wouldn't have been a better choice for the LTS given that Debian will be frozen from June
[16:04] <cjwatson> http://article.gmane.org/gmane.comp.time.tz/4133 erk
[16:05] <micahg> skaet: we're going to need a firefox upload to fix upgrades from natty to oneiric with the same firefox version, I assume we want this fixed on the live media as well?
[16:06] <micahg> skaet: problem we're fixing is missing search engines again
[16:06] <skaet> micahg, ok,  what's the ETA?
[16:07]  * skaet wondering if we need this in today's images, or if its going to need to go into Monday's final, or an SRU.
[16:07] <micahg> skaet: well, I can do this one of 2 ways, I can fix the current issue, but it'll come back to bite us again when we upgrade to 8, or I can try to fix it right so we hopefully aren't bitten by it again
[16:08] <micahg> the first, I can upload a fix in a few minutes, the other will be several hours
[16:09] <skaet> micahg,  please fix the current issue,  and upload that.   That will give us the backup, and get the builds started.   If you have a better fix,  we can decide tomorrow to get it ready and included for Monday's builds.
[16:09] <micahg> skaet: ok
[16:10]  * skaet figures micahg will do a better proper long term fix without her asking for the next few hours... is it ready yet?;)
[16:12] <skaet> cjwatson, urk indeed.
[16:13] <micahg> skaet: so, Chris Coulson committed a fix to bzr, it should be a permanent fix
[16:14] <micahg> I'll upload it
[16:14] <skaet> micahg, thanks.
[16:19] <micahg> skaet: do you want me to do a test build first or just upload? (only change was in the postinst)
[16:20] <skaet> micahg,  test build first please,  just in case.    We have time,  waiting for WUBI upload.
[16:20] <micahg> skaet: ok, should be about a half hour then
[16:21] <skaet> micahg, thanks. :0
[16:21] <skaet> :)
[16:57] <micahg> skaet: so, apparently, the upgrade issue with Firefox was discussed with pitti yesterday and they decided to SRU, I'm not sure if the issue of people upgrading off of live media was brought up
[16:58] <skaet> micahg, yeah, so it appears.
[17:00] <jdstrand> micahg: can you briefly summarize the issue?
[17:00] <jdstrand> (for me-- sorry that I am not up on backscroll, etc)
[17:01] <micahg> jdstrand: upgraders from natty w/the same version will lose their search engines Bug #869311
[17:01] <ubot4> Launchpad bug 869311 in firefox (Ubuntu Oneiric) (and 1 other project) "searchplugins installation damaged after natty->oneiric upgrade (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/869311
[17:01] <jdstrand> so, I go from 0ubuntu<IP_ADDRESS> to 0ubuntu1 and lose my search engine?
[17:02] <micahg> jdstrand: right
[17:02] <jdstrand> micahg: 7.0.1+build1+nobinonly-0ubuntu2 will fix this?
[17:02] <jdstrand> (whether it is SRU or not)
[17:02] <micahg> jdstrand: yes
[17:03] <jdstrand> micahg: what is on the iso right now?
[17:03] <micahg> 7.0.1+build1+nobinonly-0ubuntu1 should be
[17:04] <jdstrand> micahg: ok, so this should not affect new installs, correct?
[17:04] <micahg> jdstrand: right, only upgrades (which I thought the live media supports as well)
[17:04] <jdstrand> micahg: so your concern is natty users using the CD to upgrade
[17:05] <micahg> but I guess if people are upgrading off live media, they'll either be out of date on natty, or will just run upgrades on oneiric afterwards
[17:05] <micahg> so I guess it can go to SRU
[17:05] <micahg> jdstrand: yes
[17:05] <jdstrand> well, we can't say the former is true, we can say that latter is
[17:05] <jdstrand> micahg: can this simply be a 0-day SRU?
[17:05] <micahg> jdstrand: yep
[17:08] <jdstrand> IMHO, that is the best course of action because they will immediately get the updates most of the time. it seems that people upgrading off of oneiric install media would also be getting network upgrades as well
[17:08] <micahg> jdstrand: right and if they don't they probably didn't have the previous upgrades either (so won't experience the issue)
[17:09] <jdstrand> cool
[17:09] <ev> about to step out for dinner
[17:09] <ev> still waiting for a signed wubi from IS
[17:10] <ev> will check back when I get home tonight
[17:10] <jdstrand> skaet: I think that perhaps this should be a release note in the Technical Overview: "Ubuntu 11.04 users who are upgrading via Ubuntu 11.10 install media may lose access to Firefox search engines until performing a standard upgrade (LP: #869311)."
[17:10] <jdstrand> (or similar)
[17:10] <skaet> ev, ok,  WUBI's on the critical path for building the images.
[17:11] <infinity> Is there a sane way to determine why I can see private bugs?
[17:11] <infinity> https://bugs.launchpad.net/ubuntu/+source/geoclue <-- I see 20+ private bugs there, and I'm curious if people who actually need to see them can.
[17:12] <micahg> infinity: go to a bug and click on edit bug mail, it should tell you why you can see it
[17:12] <skaet> jdstrand, ack.   will add it then.
[17:12] <micahg> skaet: do you want a release notes task on the bug?
[17:12] <skaet> micahg, yes please.
[17:12] <micahg> skaet: and should I just leave the upload for chris next week then?
[17:12] <ev> skaet: indeed, text me if I need to run back to the office
[17:13] <ev> skaet: my mobile is in the directory
[17:13] <Laney> infinity: by being in a team which is subscribed to the bug (usually crash bug triagers)
[17:13] <Laney> don't know if that is sane
[17:13] <infinity> Laney: Ahh, so basically, any ubuntu dev can see those.  Check.
[17:13] <jdstrand> micahg: thanks for looking into this and bringing it up :)
[17:13] <infinity> Laney: It may or may not be sane, but in this case, I'd like people to actually be trying to fix that bug. :P
[17:13] <infinity> Laney: 20+ dupes of the same bug sounds less than ideal.
[17:13] <jdstrand> micahg: is the ubuntu2 upload something that chris can handle next week?
[17:14] <micahg> infinity: bug control is allowed to see retraced bugs, and ubuntu-dev is a member
[17:14] <micahg> jdstrand: yes
[17:14] <micahg> jdstrand: as long as the 7 day SRU period is waved
[17:14] <skaet> ev,  thanks will do.
[17:14] <jdstrand> micahg: cool. feel free to commit any work you've done and just ask him to review/upload
[17:15] <jdstrand> micahg: yeah-- that'll need to be coordinated with pitti (which is convenient since he is on both the SRU and release teams :)
[17:31] <skaet> stgraber, edubuntu 20111006.1 is available
[17:34] <skaet> crontab has been disabled
[17:35] <stgraber> skaet: rsyncing
[17:51] <skaet> heya,  who let the ubuntu-meta package through,  and what was it fixing?
[17:52] <cjwatson> you can answer the latter question using https://launchpad.net/ubuntu/+source/ubuntu-meta/+changelog
[17:53] <cjwatson> I wasn't the one who accepted it but I would have done if I'd seen it
[17:53] <skaet> thanks cjwatson
[17:53] <cjwatson> the seed commit message is "remove banshee from armel and replace it with rhythmbox, banshee is unusable on arm"
[17:54] <skaet> yup,  am looking at it now.
[17:57] <pitti> micahg, skaet: as chris is on holiday, and the firefox issue is upgrade-only, a 0-day SRU should do, I think
[17:57] <pitti> chris has a fix, but needs testing, etc.
[18:17] <ogra_> skaet, banshee is unfixable in time, the meta upload switches armel back to rhythmbox
[18:18] <ogra_> sorry, i should have announced it here, but was in a hurry to get catfood before the shop closes
[18:18] <skaet> ogra_,  ack.  infinity, ^^
[18:19]  * skaet stepping out to lunch, biab
[18:19] <ev> skaet: Got your message. We've just sat down to eat. I'll check and move the wubi binary into the right place once we're done.
[18:19] <ogasawara> pitti: I uploaded a new linux-meta to resolve the missing lbm-headers and -extra meta packages, could you accept it in the queue?
[18:19] <skaet> ev:  thanks!
[18:19] <pitti> ogasawara: splendid, thanks!
[18:21] <stgraber> skaet: I'll be uploading a new edubuntu-meta shortly, just a refresh to follow the changes to ubuntu's and apparently one of our meta wasn't up to date on ARM (which we don't ship anyway)
[18:39] <stgraber> skaet: I've been discussing a NetworkManager/libnl bug in private with cyphermox. It prevents anyone on an ipv6 only network to connect to the internet when they use a static configuration.
[18:40] <stgraber> it's a pretty rare setup, thought the annoying part is that if we push the fix as an SRU, they won't be able to install it unless they manually fix the route from a shell (as they won't get connectivity until the fix is downloaded)
[18:40] <stgraber> is that something you'd consider for release or should we instead document and get that as SRU (hoping it's indeed a very very rare setup)?
[18:42] <Daviey> stgraber: Is it a regression from Natty?
[18:43] <stgraber> cyphermox: do you know? ^
[18:43] <stgraber> Daviey: I would think it's but I don't have a lucid system around me here to easily check
[18:43] <cyphermox> Daviey: I'd venture a "yes", but tbh I didn't spend much time playing with ipv6 on natty
[18:44] <cyphermox> otoh, this part of the NM code didn't really changed that I know of, so perhaps it was the same in natty
[18:44] <Daviey> It's a setup i want to create at home, but i'd expect some tweaking.  I imagine others in the same situation would expect the same, am i wrong?
[18:44] <cyphermox> there's two issues: one with libnl not playing nice, and one with missing bits in NM
[18:45] <cyphermox> Daviey: what do you mean by tweaking?
[18:45] <stgraber> Daviey: well, when filling the IPv6 manual configuration in NM, I'd kind of expect it to actually set that configuration :) and not everything but the default gateway
[18:45] <Daviey> cyphermox: potential to add my own patches.
[18:45] <cyphermox> ah, no, don't think you'd need to add that much
[18:45] <cyphermox> even if you just set one static ipv6 with a gateway, the default gateway for the interface is never set
[18:46] <cyphermox> partly due to libnl, partly because there are small bugs in NM for that; plus then it wouldn't be removed, for the same reason
[18:47] <cyphermox> and I fail at copy paste.
[18:47] <cyphermox> stgraber: Daviey: the changes in NM are relatively simple and self-explanatory: http://paste.ubuntu.com/703472/
[18:48] <stgraber> cyphermox: wow, that's like the shortest NM patch I've seen in month!
[18:49] <cyphermox> the change in libnl3 would warrant a quick review, but basically "reverts" to libnl1 behavior: http://paste.ubuntu.com/703546/
[18:49] <cyphermox> stgraber: isn't it two patches?
[18:49] <stgraber> cyphermox: right ;)
[18:49] <ScottK> stgraber: Accepted edubuntu-meta
[18:50] <infinity> cyphermox: Those both look fine to me.
[18:50] <infinity> skaet: You willing to hold off your respins for a couple hours for this NM fix?  Your call.
[18:50] <infinity> skaet: Actually, we're still updating metas and stuff...
[18:50] <infinity> cyphermox: Just do it. :P
[18:50] <cyphermox> infinity: zug zug
[18:51] <infinity> cyphermox: Your Blizzard fanboy is showing.
[18:51] <skaet> infinity,  yeah, and waiting for ev to upload WUBI.
[18:51] <stgraber> cyphermox: I plan on running a full ipv6 test on alternate + desktop tomorrow, just to be sure. So having that in now would be good.
[18:51] <skaet> WUBI upload is my trigger to kick off the builds.     If anyone has a good reason for waiting for something else,  please post now.
[18:52] <cyphermox> yup, it's a matter of minutes, the packages are pretty much ready and I've been running with them since yesterday
[19:05] <cyphermox> stgraber: I'm going to need sponsoring for the libnl3 changes.
[19:13] <infinity> cyphermox: I can sponsor.
[19:14] <infinity> cyphermox: Throw me a debdiff somewhere or something.
[19:14] <cyphermox> infinity: merge proposal good enough? https://code.launchpad.net/~mathieu-tl/ubuntu/oneiric/libnl3/lp856209/+merge/78485
[19:14] <infinity> Ick.
[19:14] <infinity> Yes.
[19:15] <infinity> (debdiff is so much faster than me checking out a branch I don't normally work with)
[19:15] <infinity> I can, however, diff from your MP and live with that. ;)
[19:19] <infinity> cyphermox: Is NM on its way to the queue?
[19:20] <infinity> cyphermox: libnl3 uploaded.
[19:22] <cyphermox> yes, uploading now
[19:22] <cyphermox> doen
[19:23] <cyphermox> heh, I could have sent you a debdiff just the same, since I did make one
[19:23] <infinity> No matter, LP diffs for me.
[19:23] <infinity> Just easier to apt-get source when I have a local mirror than to checkout a branch I never use.
[19:23] <infinity> Especiall since I have to apt-get source anyway for paranoia.
[19:23] <infinity> (I always diff before I upload to make sure there's no cruft in the VCS I'm using)
[19:24] <cyphermox> right. I was paranoiing, hence the slow response
[19:24] <cyphermox> retested the different eth0 wlan0 with ipv6 or without, and mbm and vpns for good measure
[19:27] <infinity> I'll accept as soon as I verify these are the same two diffs I reviewed before. :)
[19:28]  * infinity waits for the queueu to get diffy with it.
[19:28] <cyphermox> infinity: it's not quite the same
[19:29] <cyphermox> infinity: for NM I added a small thing, just dropping some messages I had forgotten from warn to debug
[19:30] <cyphermox> that way I don't end up spamming everyone's syslog with 10 extra lines per connection
[19:30] <infinity> That sounds pleasant.
[19:30] <infinity> I'll re-review for the hell of it.  It was small. :)
[19:31] <cyphermox> sure
[19:33] <slangasek> cjwatson: did the vesafb error suppresion fix go ahead already?
[19:54] <ScottK> pitti: Thanks for taking care of moving kde 4.6.5 to -updates.
[20:05] <infinity> slangasek: Changelog says no.
[20:08] <infinity> slangasek: We're still waiting on wubi, I believe, so go go go? :)
[20:13] <stgraber> ScottK: thanks (for edubuntu-meta)
[20:19] <ScottK> No problem.
[20:21] <slangasek> infinity: ok, initramfs-tools uploaded; I have not tested it
[20:23] <infinity> slangasek: You rebel.
[20:23] <slangasek> I'm not rebelling, just informing :)
[20:24]  * skaet shifting location,  biab
[20:45] <bdrung> tumbleweed: where? i synced it.
[21:01] <bdmurray> I'm gonna rename p-series to Precise okay?
[21:02] <bdmurray> In launchpad that its
[21:03] <slangasek> bdmurray: thanks :)
[21:03] <stgraber> are there any script currently looking for p-series that'll need updating?
[21:03] <bdmurray> Well, I was just writing one and didn't want it needing updating ;-)
[21:04] <bdmurray> using the version is more reliable
[21:08] <skaet> bdmurray, thanks :)
[21:09] <bdmurray> hrm, actually it results in an error with out an e-mail address for changes to go to
[21:14] <slangasek> ah, so we need precise-changes to get set up
[21:14] <bdmurray> or to use the api
[21:15] <bdmurray> I don't have permission to change the displayname though
[21:21]  * infinity thinks we're almost ready for a base-files upload.
[21:22] <Daviey> Isn't that usually done on release week?
[21:22] <infinity> Or, apparently we're not doing that until -3
[21:22] <infinity> Yeah, getting ahead of the new and improved schedule, apparently. ;)
[21:23] <skaet> :P
[21:23] <Daviey> infinity: release later, release okayish.
[21:23]  * Daviey looks at cloud-init
[21:24] <slangasek> cjwatson: any traction on bug #745960?
[21:24] <ubot4> Launchpad bug 745960 in grub2 (Ubuntu Oneiric) (and 3 other projects) "Cannot boot grub after installing to LVM (affects: 19) (heat: 108)" [High,Incomplete] https://launchpad.net/bugs/745960
[21:25] <Daviey> slangasek: Did you see that udev without dbus installed is apparently causing non-deterministic boot fails?
[21:25] <infinity> cjwatson: Shouldn't syslinux-themes-* be "Arch: amd64 i386" in light the whole dependency on memtest86+?
[21:25] <slangasek> Daviey: um, no
[21:26] <skaet> Daviey, is fix for bug 850880 going to land in time for release?
[21:26] <ubot4> Launchpad bug 850880 in cobbler (Ubuntu Oneiric) (and 1 other project) "cobbler-ubuntu-import does not pull from -updates (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/850880
[21:26] <Daviey> skaet: yep
[21:26] <slangasek> Daviey: do you have a bug number for this?
[21:27] <slangasek> udev itself doesn't use dbus
[21:28] <Daviey> slangasek: I'm not sure, hggdh mentioned that jibel was still trying to work out enough information to raise a bug.  I suggested he talk with jhunt tomorrow
[21:28] <slangasek> Daviey: ok, well I'm pretty skeptical of this bug description to be honest
[21:28] <slangasek> we have three other known udev issues related to initramfs races
[21:28] <Daviey> slangasek: Apparently installing dbus was enough to get reliable booting.. Perhaps it's slowing down the boot.
[21:29] <Daviey> *shrug*
[21:29] <slangasek> I think it's more likely that they're seeing one of these
[21:29] <Daviey> That is all i know.
[21:29] <slangasek> and that dbus is a red herring
[21:29] <slangasek> ev: how was dinner? :)
[21:30] <Daviey> smoser: cloud-init, why did you bump the timeout by 1?
[21:31] <Daviey> smoser: So this catches the failure, and re-tries X times.. doesn't just catch and error out, right?
[21:32] <slangasek> Daviey: a udev bug report tomorrow is almost certainly too late for us to get any kind of fix in for release.  But then, the same is probably true of a bug report today, so.
[21:34] <Daviey> slangasek: I agree that it's probable to be the same issue.. Does that mean the already declared bug is unlikely to be resolved for release?
[21:35] <slangasek> Daviey: yes, all of these udev bugs are going to be zero-day SRU material
[21:35] <Daviey> geez.
[21:35] <Daviey> I would have thought that it was bit of a release blocker.
[21:35] <slangasek> that would imply an unhealthy amount of rushing
[21:35] <Daviey> Some hardware having 100% boot failure.. Doesn't help them it being in -updates.
[21:35] <slangasek> what hardware has 100% boot failure?
[21:36] <ev> slangasek: We're just trying to flag the waitress for the bill
[21:36] <slangasek> that's absolutely not the message communicated in these bugs
[21:36] <Daviey> slangasek: Much of the Canonical IS hardware AIUI :)
[21:36] <slangasek> then perhaps you should clarify what you mean by "the already declared bug"
[21:36] <slangasek> because none of the things we're tracking bear the slightest resemblance to that
[21:37] <slangasek> (not that Canonical IS is going to run O on their hardware, but still)
[21:37] <Daviey> slangasek: bug 818177 was reported by CorpServices hardware.  bug 862823, was by IS.  Are you certain they don't have the same root cause?
[21:37] <ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
[21:37] <ubot4> Launchpad bug 862823 in udev (Ubuntu) "udev causes a kernel panic on oneiric network install (affects: 1) (heat: 39)" [High,Confirmed] https://launchpad.net/bugs/862823
[21:39] <Daviey> The failure jibel is seeing is in kvm..  However, i don't have enough data about that to comment.
[21:39] <slangasek> Daviey: 818177 as it's currently being worked is nothing at all like a 100% boot failure.  If that was the original symptom, I'm afraid that's been drowned out by Adam's and Serge's debugging of unrelated configurations
[21:39] <Daviey> the 'hardware' is kvm, i mean
[21:40] <slangasek> 862823 *could* be the same as bug #818177 but there's really not much evidence yet to support this
[21:40] <ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
[21:41] <Daviey> slangasek: ah, comment 1 is 1:10 success
[21:41] <slangasek> i.e., 862823 has insufficient information to actually implement a fix
[21:41] <Daviey> Gah, Trellis said he was going to update the bug earlier
[21:43] <Daviey> 09:30 < Daviey> TREllis: hey, can you comment if you were using LVM to produce bug 818177,
[21:43] <ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
[21:43] <Daviey> 09:37 < TREllis> Daviey: howdy, originally yes but it's visible without LVM according to the support guys in montreal who were installing oneiric yesterday on the same systems
[21:43] <slangasek> right - the LVM issue has been triaged off to a different bug
[21:44] <slangasek> (that's the one that adam_g is seeing, principally)
[21:44] <slangasek> 818177 is now about udev reaping its children, which is a race condition that should happen *rarely*
[21:45] <slangasek> if there is hardware that's failing 100%, then we definitely need to escalate
[21:45] <ev> On my way to a computer now. Will sort wubi straight away
[21:45] <slangasek> ev: whoo :)
[21:47] <Daviey> slangasek: I'll see if i can grab some more details tomorrow morning.
[21:48]  * ev underground
[22:00] <Daviey> slangasek: Ah, Trellis did say that on some hardware they were blocked from testing it because of a binary firmware rename which hasn't been handled.
[22:00] <Daviey> http://pb.daviey.com/GPWt/
[22:00]  * infinity loves how initramfs-tools uploads make ~1200 packages uninstallable.
[22:00] <slangasek> infinity: buy a bigger hamster
[22:00] <infinity> slangasek: amd64 too!
[22:00] <Daviey> (which smb and apw where notifed of today, don't know that there is a bug.)
[22:00] <slangasek> amd64 is a bigger hamster!
[22:00] <infinity> http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html <-- See?!
[22:01] <infinity> Our hamsters are just fine!
[22:01] <slangasek> Daviey: right, I saw that error in the original bug data, though I don't understand how it relates to the hang-on-boot symptom
[22:01]  * infinity goes to pet some dev boards.
[22:01] <Daviey> infinity: lets just ship i386, only breaks 5 packages
[22:01] <infinity> Daviey: Seems reasonable.
[22:02] <slangasek> Daviey: is that hang completely reproducible?
[22:03] <hggdh> slangasek: I think this maybe just a race condition; it happens frequently on our Jenkins rig for i386 minimal-virtual server install, and infrequently elsewhere
[22:04] <Daviey> slangasek: I only learned of it at 8:30 UTC today, and if you have the scrollback, you know as much as i do.
[22:06] <Daviey> infinity: Is that initramfs-tools induced issue transient?
[22:06] <infinity> Daviey: Of course.
[22:07] <Daviey> A happy ending.
[22:07] <infinity> Daviey: Just a great example of the "archive skew" issue that we keep whining about. :)
[22:07] <slangasek> hggdh: what happens, exactly?
[22:07] <slangasek> hggdh: I have at least three different udev bugs in the air at the moment, I need a precise description
[22:08] <slangasek> (a precise description for oneiric, of course ;P)
[22:09] <hggdh> slangasek: as far as I can determine: system boots, everything seems OK; / remains RO, and udev gets completely lost
[22:09] <hggdh> after some minutes you get a login prompt, but / is still RO
[22:09] <Daviey> http://pb.daviey.com/ohJw/
[22:09] <hggdh> reboots may, or may not, reproduce
[22:10] <slangasek> hggdh: right.  Bug #818177 to a T then
[22:10] <ubot4> Launchpad bug 818177 in udev (Ubuntu Oneiric) (and 3 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 8) (heat: 62)" [High,Triaged] https://launchpad.net/bugs/818177
[22:10] <hggdh> yes, really sounds like it
[22:10] <infinity> pitti: All ARM-related component mismatches should be taken care of now.
[22:10] <hggdh> interesting is that we pretty much *only* see it on a i386 install
[22:10] <slangasek> and dbus is a red herring for that
[22:11] <hggdh> I also think so, I was able to reproduce & reboot correctly without it
[22:11] <infinity> pitti: Not sure what the story is on then linux-* stuff that wants to fall into universe.  Not sure if that's a failure to seed, or incorrect overrides when NEWing.
[22:11] <infinity> pitti: (For x86, that is, I got the ARM linux-* stuff happy, as I said)
[22:13] <slangasek> Daviey: ^^ ok, hggdh and I are aligned now :)
[22:13] <Daviey> super
[22:54] <ev> I see no wubi signed binary. The ticket hasnt been updated
[22:54] <ev> Am I missing something?
[22:54] <skaet> ev,  there's was a direct link pasted to #is window.
[22:54] <skaet> just a sec, and I'll grab it again.
[22:55] <skaet> ev, pasted in pm.
[22:56] <ev> Right. Sorted
[22:56] <ev> Wubi is ready for the CDs
[23:01] <skaet> :)
[23:04] <hggdh> slangasek: if it will help any, we are now saving the boot log (actually, the console log) on Jenkins, so next time it fails we will have it
[23:07] <slangasek> hggdh: I think that particular bug is well-understood now, and the console log doesn't give too much relevant debugging detail by default; I might have some test packages later that would give more interesting output though
[23:24] <skaet> ev, where should I be looking for Wubi to land before triggering builds?
[23:29] <slangasek> skaet: it's published directly via people.canonical.com and pulled from there onto antimony by the build scripts; so if ev says "ready", you should be able to trigger anytime
[23:30] <skaet> slangasek,  thanks!!
[23:30] <slangasek> skaet: hold
[23:30] <skaet> holding
[23:30] <slangasek> http://people.canonical.com/~evand/wubi/oneiric/ doesn't show anything updated after 17:40pm
[23:30] <ev> No, thats correct
[23:30] <skaet> slangasek, wubi-r241-signed.exe is there
[23:30] <ev> It's the stable symlink
[23:31] <slangasek> ok
[23:31] <ev> Which points to 241-signed
[23:31] <skaet> 17:41 is when it was created by IS
[23:31] <slangasek> it's just backdated?
[23:31] <slangasek> ah, ok
[23:31] <slangasek> skaet: good to go then :)
[23:31] <skaet> slangasek, ev,  thanks \o/
[23:31] <ev> Sure thing
[23:35] <skaet> WUBI, CDs, DVDs building...
[23:37] <skaet> Daviey,  any last updates I should be checking for being built, before kicking off server?
[23:46] <smoser> Daviey, I did bump the timeout.  previously it was not catching that error and thus exiting without retrying.  i bumped the timeout to increase the chance of getting a response before giving up.
[23:47] <smoser> the fact is, that on nova, the MD service is painfully slow, and 2 seconds might not return . so all we're doing is killing it by repeatedly asking it for something.
[23:48] <smoser> i dont want to disable the timeout *and* retry, because then ew'd potentially do X retries with OS default timeout (which is quite long).
[23:56] <infinity> skaet: I see a cloud-init upload still being debated for server.
[23:57] <infinity> smoser: Accepted.  Even if it's the wrong solution, I fail to see how it's much worse.
[23:59] <skaet> infinity, ok.  will wait for it to build, and then trigger the alternates


[12:41] <Kolus> I'm having an issue with Ubuntu 17.04 and am wondering what I need to gather in order to report a possible bug
[12:41] <zteam> Hi, is there any ETA then really annoying kernel bug is fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838
[12:41] <ubot5`> Ubuntu bug 1674838 in linux (Ubuntu Zesty) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [High,In progress]
[12:42] <zteam> Kolus, you should run ubuntu-bug package, and you are going to need a launchpad account I belive (I'm just a regular user myself)
[12:42] <Kolus> wondering if this is the same issue
[12:43] <Kolus> zteam, out of curiosity what is the bug your looking into?
[12:43] <zteam> Kolus:this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838
[12:43] <ubot5`> Ubuntu bug 1674838 in linux (Ubuntu Zesty) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [High,In progress]
[12:45] <zteam> It's really killing the fun to use Ubuntu for me, I now I can use a vanilla kernel in the mean time, but then I can't use the Nvidia driver instead :-/
[12:46] <zteam> Kolus, what's your bug?
[12:47] <Kolus> since updating to 17.04, I've been having issues with Blender, the screen and menu's bleed over each other on the VGA feed and on the HD feed from my system, there is high block pixlation
[12:47] <Kolus> seems to be a graphics refresh issue
[12:48] <Kolus> i've seen a similar problem with AMD drivers in the past with older versions of Ubuntu, but 16 was stable
[14:55] <zteam> Hi, is there any ETA then really annoying kernel bug is fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1674838
[14:55] <ubot5`> Ubuntu bug 1674838 in linux (Ubuntu Zesty) "kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129" [High,In progress]


[00:15] <kwmonroe> bolthole: blahdeblah is correct, you can't rely on order of any hook execution.. so the hooks must handle the potential for nothing being returned by relation-get
[00:16] <blahdeblah> thanks for confirming, kwmonroe
[00:16] <kwmonroe> in your case, it would probably be easiest to wire in your webapp using webapp-container-relation-changed
[00:16] <kwmonroe> you are guaranteed that relation-changed *will* fire anytime data on the relation changes
[00:16] <kwmonroe> (vs relation-joined)
[00:18] <kwmonroe> so, a webapp-container-relation-changed hook for you might look like "FOO=`relation-get webapp-path`; if [ ! -z $FOO ]; then wget the webapp and move it to $FOO; else do nothing and wait for the next time relation-changed runs.
[00:18] <kwmonroe> eventually, relation-get webapp-path will return data (once tomcat sends it), and your -changed hook will get it.
[00:20] <bolthole> thanks. I kinda empirically found out that gets fired when I want it to. Nice to know that it's guarranteed that way.
[00:21] <bolthole> now that I think about it some more though...
[00:22] <bolthole> I trhink that mbruzek is approaching the information exchange the wrong way.
[00:22] <bolthole> he is using the relationship to share the tomcat webapp directory
[00:23] <bolthole> but... when and ifjuju ever gets to the point whre subordinate services can be removed....
[00:23] <bolthole> I'm thinking that the relationship may be severed, before the service gets told to 'stop' itself.
[00:23] <bolthole> But at that point, it has just lost the information on where to cleanup itself. becuase that information was in the relatoinship, which doesnt exist
[00:24] <kwmonroe> you can remove subordinate services today in juju.  relation-departed will fire, which is where you should remove any data that you don't want left on the principal unit.
[00:24] <bolthole> huh. so relatoin-departed is inappropriately named? it should be called "relation-deparTING"?  ;-)
[00:25] <kwmonroe> meh, i guess.  -departed means the relationship is tearing down but you can still access relation data (like webapp-path).  -broken means the relation is gone.
[00:38] <bolthole> WOOO! I got it to work!
[00:44] <kwmonroe> nice bolthole!
[00:48] <bolthole> kwmonroe could you please aprove my one-char-syntax-error fix to the tomcat charm?
[00:49] <bolthole> i submitteed it this morning. it was ignored, and someon else worked on the charm so there were conflicting lines.
[00:49] <bolthole> i just redid it for no conflicts. please push it through before more conflicts happen?
[00:50] <bolthole> the webapp-path value is completely unusable without the fix.
[00:52] <kwmonroe> sure bolthole - let me take a look
[00:53] <kwmonroe> bolthole: i only see this from 18 hours ago.  did you see another commit to trusty/tomcat that made this merge conflict?
[00:53] <kwmonroe> https://code.launchpad.net/~bolthole/charms/trusty/tomcat/trunk/+merge/284213
[00:57] <bolthole> yeah just 60 seconds beofre i wrote that :)
[00:57] <bolthole> https://code.launchpad.net/~bolthole/charms/precise/tomcat/trunk/+merge/284373
[00:58] <bolthole> on wiat, its precise
[00:58] <bolthole> not trusty. yet.
[00:59] <bolthole> so i guess thre's no conflict for the trusty one, and hyou could just approve that one too ;)
[01:31] <bolthole> Thanks
[01:33] <kwmonroe> bolthole: you talking to me?  if so, yw :)
[01:34] <bolthole> :)   So.. how does the charm version in the store, get derived from the backend code baes?
[01:34] <bolthole> one is at 15, the other is at 3 or something?
[01:35] <kwmonroe> yeah bolthole - there's no correlation.  at least not one that i can figure out.
[01:36] <kwmonroe> i mean, i guess you could have 10 commits to LP, push to store making charm rev 1, then 4 more commits to LP, push to make charm rev 2, then 1 more LP commit, push to make charm rev3.
[01:36] <kwmonroe> i but i don't know how you could look at an LP commit number and figure out the charm revno.
[01:37] <bolthole> okay, so it isnt automatic; you have to make some kind of explicit push each time
[01:37] <kwmonroe> that's correct
[01:39] <kwmonroe> well, no, that's not correct.  i don't know how it works.  the numbers just go up ;)
[01:39] <bolthole> dohhh
[01:40] <kwmonroe> oh oh oh -- maybe it is how it works.. each commit bumps the LP revision, but only a push triggers the ingestion into the store.
[01:40] <kwmonroe> and now i have thought too much about this.  thanks.
[08:06] <icey> does juju on openstack support the storage hooks?
[09:26] <jamespage> gnuoy, quick review pls - https://code.launchpad.net/~james-page/charm-helpers/lp1537155/+merge/284411
[09:34] <bloodearnest> marcoc|airplane, the subordinate thing is a red herring, I would just like to be able to discover the units running on the this machine, in the same way I can find out the hostname of the machine
[09:34] <bloodearnest> to avoid having to explicitly configuring that info in every charm
[09:40] <bloodearnest> the context here is *not* charm code. It's a library that is used by our apps to standardise/improve their log outout
[09:41] <bloodearnest> we currently tag each log line with the hostname of the machine, which is easy to discover. But the hostname is kinda useless in a juju world, we are more interested in the juju unit that the app runs under
[09:41] <bloodearnest> so I was wondering if there's away to discover the juju units running automatically
[09:42] <bloodearnest> or else, every charm for each service that uses this library (10+) would need to be manually updated to set an env var or similar with the unit name
[13:16] <deanman> Hi, I'm trying to learn more about Juju by using the official vagrant boxes and they fail to properly boot up both on windows and MacOSX. I've tried trusty64 trusty32 and wily 64. All of them are stuck at "Intalling package: cloud-utils"
[13:46] <stokachu> kadams54: with theblues library how can i pull a specific revision? for example, bundle = cs.bundle('data-analytics-with-sql-like/5')
[13:48] <stokachu> specifically for a bundle
[13:58] <rick_h_> stokachu: yes, https://api.jujucharms.com/charmstore/v4/openstack-base-34/archive/bundle.yaml vs https://api.jujucharms.com/charmstore/v4/openstack-base-39/archive/bundle.yaml
[13:58] <rick_h_> stokachu: the thing is that a new revision might be due to a readme update or the like
[13:58] <rick_h_> stokachu: so not all reivsions will be changes to the bundle.yaml file itself
[13:58] <stokachu> ah ok
[13:59] <rick_h_> I was confused because that openstack 38 and 39 revisions the files were the same
[13:59] <rick_h_> but the readme was different
[14:04] <stokachu> so i can generate the archive url with cs.archive_url('data-analytics-with-sql-like-4') but that doesn't contact the charmstore to validate it
[14:05] <rick_h_> stokachu: not sure on the library itself
[14:05] <stokachu> i guess i could just generate the api url and check that a 200 is returned
[14:06] <rick_h_> stokachu: yea, have to bug jcsackett or some other folks that work on that atm
[14:06] <stokachu> rick_h_: ok cool, will do thanks
[16:47] <tych0> marcoc|airplane: https://github.com/lxc/lxd/issues/1477
[16:47] <stokachu> how do you force a destroy-controller with juju 2.0?
[16:48] <stokachu> i interrupted a lxd bootstrap and now juju is unable to cleanup after itself
[16:48] <tych0> marcoceppi: er, https://github.com/juju/juju/pull/4191
[16:48] <tych0> i am bad at copying and pasting
[16:58] <marcoceppi> tych0: aren't we all
[17:05] <cmagina> tvansteenburgh: hey, did you get a chance reproduce that bundletester issue i've been hitting?
[17:07] <tvansteenburgh> cmagina: i was unable to repro. would you mind filing a bug here https://github.com/juju-solutions/bundletester/issues
[17:07] <cmagina> tvansteenburgh: will do, thanks for trying
[17:07] <tvansteenburgh> please include traceback
[17:08] <tvansteenburgh> i will have another look soon
[20:28] <adam_g> does juju / local provider log output of uvtool errors?
[21:59] <lazypower|travel> adam_g I don't believe so
[21:59] <lazypower|travel> But i'm not 100% on that.
[22:49] <bolthole> scalability question: what if we have a 'cloud' where we anticipate 200-300 services? how can we use juju for that and keep it manageable?
[23:03] <rick_h_> bolthole: we'd suggest a controller with multiple models in HA mode
[23:03] <rick_h_> bolthole: the controller multiple model work is in the 2
[23:03] <rick_h_> p alpha work
[23:03] <rick_h_> bah 2.0
[23:24] <bolthole> rick_h_ sounds like you are describing more scalability. however, I am actually trying to focus on manageability
[23:25] <rick_h_> bolthole: i'm talking about moving those 200 services into 20 more tightly scoped models
[23:25] <rick_h_> so you're managing things in smaller groups
[23:25] <bolthole> ah, good
[23:26] <bolthole> demo or screenshots?
[23:26] <rick_h_> bolthole: https://jujucharms.com/docs/devel/wip-systems
[23:27]  * rick_h_ looks for youtube talk
[23:27] <rick_h_> https://youtu.be/-1aVgnJIwLk
[23:28] <rick_h_> bolthole: shows the old gui visualizing it
[23:28] <rick_h_> bolthole: don't have one with the new gui atm
[23:28] <bolthole> ah
[23:28] <bolthole> thanks for the video
[23:31] <bolthole> cant use sound at the moment....  is "model" the thing tothe right of juju/admin ?
[23:31] <bolthole> so,
[23:31] <bolthole> juju/admin/openstack
[23:31] <bolthole> "openstack" is a model view?
[23:35] <rick_h_> bolthole: yea the model name is sonething you give whwb you create it
[23:36] <rick_h_> you'll see different names as the video goes on
[23:36] <bolthole> "it"
[23:38] <bolthole> you said that was with the "old" gui... but I dont see that option with the trusty/juju-gui screen?
[23:38] <rick_h_> bolthole: it was a demo
[23:39] <rick_h_> bolthole: today you use the jes festure flag in that doc link
[23:39] <rick_h_> bolthole: and use the gui 2.0 deployed into the admin model
[23:39] <bolthole> oh. um.. waitaminute though...
[23:41] <bolthole> the feature flag you are referring to, is   for "multiple environments"?
[23:41] <rick_h_> bolthole: yes
[23:41] <bolthole> models == enviroments? or someting else?
[23:42] <rick_h_> bolthole: where we're doing s/environments/models in 2.0
[23:42] <bolthole> ugh. naming overload:(
[23:42] <bolthole> but.. I dont want to set up a separate juju .. controller(?) for every model wehave
[23:42] <bolthole> that seems rather wasteful
[23:42] <rick_h_> no one controller many models
[23:43] <bolthole> huh
[23:43] <rick_h_> once your bootstrapped you can creat more and more models
[23:43] <rick_h_> try it out in that doc link
[23:43] <bolthole> so whats the new name for what is now called environments? :-D taht is to say "my azure environment" vs "my amazon environment" ?
[23:44] <rick_h_> my azure controller
[23:44] <rick_h_> and in 2.0 you give them names and can have multiple azurr controllers
[23:44] <rick_h_> so cloud-controllers-models
[23:44] <bolthole> ah, k.  thanks.  Rough ETA for release of this thing?
[23:45] <rick_h_> 16.04
[23:45] <rick_h_> april release
[23:45] <bolthole> thanks
[23:45] <rick_h_> i'm showing some of it at the summit next wed
[23:45] <rick_h_> the charmers summit


[13:51]  * xnox just saw commits by "Arch Librarian<EMAIL_ADDRESS>[13:52]  * xnox slowly backs away
[13:53] <mgz> if you cross the arch librarian, he will set is sub librarians on you
[13:53] <xnox>  /o\
[15:08] <Sebboh> So, here's what I've done so far (approximately).  apt-get install bzr; bzr checkout bzr+ssh://blah-blah foo; cd foo; bzr --help; bzr status  ...And then it told me that like, all the files were modified.  So then I immediately joined here to complain about this, rather than like, google it.  What exactly should I google here?  "bzr doesn't act as I expect"? :/
[15:09] <Sebboh> Do we have some local definition of 'modified'
[15:10] <beuno> Sebboh, so
[15:10] <beuno> what is modified in them?
[15:12] <Sebboh> I *just* checked them out.  omg, maybe it's permissions.  I checked out into a filesystem that doesn't support permissions.  Does bzr consider permissions changes to be modifications?
[15:12] <beuno> yes
[15:12] <beuno> that's why I ask
[15:12] <LeoNerd> Ooh.
[15:12] <galaxyAbstractor> Hey, I am trying to push something to launchpad, but all I get is "bzr: ERROR: Unable to connect to SSH host bazaar.launchpad.net; [Error 2] The system cannot find the file specified". Anyone knows what's up? How is that missing file related to not being able to connect to the host?
[15:12] <beuno> bzr diff will tell you
[15:12] <galaxyAbstractor> (I can ping the host just fine and connect to it trough putty)
[15:12] <LeoNerd> If the permissions of the files on disk don't match what bzr thinks they should be, then yes.. that will count as a difference
[15:13] <Sebboh> I'm reading back over my messages in here, and I'd like to apologize for my tone.  I'm trying to quit cigarettes... :(
[15:15] <fullermd> I have a friend who had a plan for that.
[15:15] <fullermd> His theory was that you shouldn't fight it.  Anytime you want a cigarette, just go ahead and eat one.
[15:20] <Sebboh> lol
[15:20] <mgz> galaxyAbstractor: so`ssh -vv<EMAIL_ADDRESS>gets you through to the now shells message? then look in your log for the full traceback and pastebin it, `bzr version` tells you where to find the log
[15:25] <galaxyAbstractor> mgz http://pastebin.com/J5xm3Kra
[15:27] <mgz> pants
[15:28] <mgz> galaxyAbstractor: run the same command again with BZR_PDB=1 set in the environment,
[15:29] <mgz> then when you're dropped into the debugger,
[15:31] <galaxyAbstractor> and then?
[15:32] <mgz> hit 'u', then 'p orig_error', then 'p argv' and double check that the first item in argv actually exists on disk
[15:34] <galaxyAbstractor> oh, where is plink.exe supposed to go? I have it in my downloads folder but maybe I had to put it somewhere else? The guide didn't really say anything about that
[15:34] <galaxyAbstractor> I would assume that's the issue?
[15:35] <galaxyAbstractor> This is what I get http://i.imgur.com/xldx8DM.png
[15:35] <mgz> I set the full path to plink in BZR_SSH
[15:35] <mgz> so, C:
[15:35] <mgz> er...
[15:36] <mgz> BZR_SSH=C:/Program Files/putty/plink.exe or whatever
[15:38] <galaxyAbstractor> oh, the Create ssh key said that value should be only "plink" so that's what I put https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
[15:39] <galaxyAbstractor> I feel quite stupid about that
[15:40] <mgz> it can be only plink, but then it must be on your path
[15:40] <mgz> I can edit that page to be clearer
[15:42] <galaxyAbstractor> yeah, it works now, thanks
[15:43] <mgz> ace
[15:43] <galaxyAbstractor> is plink optional tho? Seems like I'm the only one in class that used plink, and it works fine for everyone else without it
[15:45] <mgz> ...that page is so confusing...
[15:46] <mgz> I use plink, various other people use paramiko (a python ssh library) that we bundle with the all-in-one installer
[15:49] <galaxyAbstractor> Most only did the pageant step tho
[21:26] <greggypoo> hi - I'm a long-time rcs user who recently learned git and I love git, and I am forced to use bazaar for a certain project, and I am finding it awkward, I am always running into "surely this is easy and will sort itself out like it does in git," but it always turns out to be clunky and slow and difficult instead.  but i'm super ignorant of bazaar (and pretty ignorant of git if it comes down to it)
[21:26] <greggypoo> so what i'm looking for is a flame war between a seasoned git user and a seasoned bzr user, i think if i could read such a thing it would honestly help me understand bzr better
[21:26] <greggypoo> any ideas :)
[21:54] <mgz> just read the user docs, from core concepts onwards?
[23:18] <maxb> greggypoo: I'd suggest just asking about specific issues here. There are plenty of people who can help you find equivalent bzr concepts to git ones


[02:00] <corfy> Ever since I discovered that Google Calendar has the ability to remind me about events by sending a text message to my phone, I haven't had a problem remembering the Ubuntu meetings.
[02:01] <corfy> Of course, I haven't seen too many people in the meetings lately
[02:18] <corfy> This has nothing to do with Ubuntu, but 3 of the 4 Hancock County School systems are calling for a 2-hour delay tomorrow. Mt. Vernon Community Schools is the only hold-out right now
[02:24] <corfy> Let's see... Indiana LinuxFest is scheduled for March 25-27. Registrations have started, they are also looking for speakers.
[02:25] <corfy> Ubuntu 11.04 is due out April 28. I must admit, I hadn't heard of a narwhal until this release was announced.
[02:30] <corfy> If Ubuntu keeps its current release pattern, 13.04 will be released on my birthday. That will be the "R" release. I'm hoping the mascot for that one will be a raccoon, but I doubt that animal will be exotic enough.
[02:33] <corfy> Welcome
[02:33] <corfy> How are you doing this evening?
[02:37] <corfy> For those keeping notes (and to follow up on my previous unrelated post), Mt. Vernon Community Schools will be delayed by 2 hours tomorrow. That completes the set of Hancock County schools.\