[08:13] <Odd_Bloke> bjf: Heads up: argyle is running in PS4 at the moment, and we've been asked to move it to PS4.5 by the end of the week.
[09:29] <Laney> did aufs go away in our 4.0?
[09:29] <Laney> my schroots broke :(
[09:34] <Odd_Bloke> bjf: apw: Oh, it's not by the end of the week, it's by July 15 (next Wednesday).
[09:35] <Odd_Bloke> bjf: apw: I've redeployed the service, and opened RT #82789 to open up the same firewall holes as we have for the PS4 deployment.
[09:35] <infinity> Laney: Erk, it sure did...
[09:36] <infinity> apw: Where'd aufs go?
[09:36] <infinity> Laney: You can s/aufs/overlay/ for now (or downgrade).
[09:38] <Laney> infinity: Ya, done that, thanks.
[10:32] <apw> infinity, it was meant to be there, i am sure tim updated it
[12:29] <infinity> apw: I'm sure modinfo tells me I don't have it.
[12:29] <infinity> Althought, CONFIG_AUFS_FS=m ...
[12:29] <infinity> Wha?
[12:52] <apw> infinity, yeah its disabled in the makefile, seems to build just fine, so i am proposing to do a non-abi bumper with it enabled
[12:53] <infinity> apw: If it works, that seems reasonable.
[13:45] <bjf> Odd_Bloke, so our "cloud provider" has asked us to move to a new cloud but it's up to us to do that? and i suppose any/all firewall exceptions are also up to us to tell them about?
[13:49] <rbasak> awe: do you mind posting your /var/log/apt/history.log somewhere from yesterday's grub2 incident? I'd like to see what exactly did what when your system originally broke to understand the issue better.
[13:54] <awe> rbasak, in a mtg, and just about to join a standup; I'll ping you when I free up
[13:54] <rbasak> OK, thanks.
[14:02] <Odd_Bloke> bjf: Something like that, yes.
[14:03] <Odd_Bloke> bjf: But they have at least been fairly responsive; new rabbitmq is at 162.213.33.247 and the firewall holes should have been punched.
[14:03] <Odd_Bloke> (In their defense, all I had to do was say "copy the PS4 firewall rules", so hopefully they should all be correct)
[14:05] <bjf> Odd_Bloke, since we access it via ip addr, it will require code changes
[14:06] <Odd_Bloke> bjf: Yeah. :(
[14:07] <bjf> Odd_Bloke, from what you are telling me. the new one is in place and i should be able to switch over right now if i wanted ... correct?
[14:08] <Odd_Bloke> bjf: That's my understanding; but check first?
[14:09] <bjf> Odd_Bloke, ok ... i'll do a little checking and if it goes well, make the switch
[14:13] <bjf> apw, ^^^^ i'll do some testing to make sure the msgq service is working for the systems we want it 
[14:16] <apw> bjf, sounds good, as i will need to shock-and-awe on the dashboard
[14:18] <awe> did someone say my name?  ;)-
[14:18] <apw> :)
[14:18] <apw> infinity, ok just enablnig aufs seems to work just fine, soooo ... i'll get that uploaded
[14:19] <apw> ogasawara, seems we are missing aufs in the kernel we just did, so i am proposing to do a non-abi bumper for it
[14:19] <awe> rbasak, http://pastebin.ubuntu.com/11848708/
[14:19] <ogasawara> apw: ack
[14:19] <infinity> apw: Works for me.
[14:20] <infinity> apw: I can never decide from minute to minute if my schroots should be overlay, aufs, or lvm, but hey, it's nice to be spoiled for choice.
[14:20] <infinity> apw: (I still wish overlay could paper over the one or two things that make me keep turning to aufs...)
[14:21] <rtg> apw, the 4.0 Wily upload is missing AUFS ?
[14:21] <infinity> rtg: Yep.
[14:21] <infinity> rtg: It's in the config, but apparently disabled in the Makefile.
[14:21] <infinity> (oops)
[14:21] <rtg> infinity, oh, damn
[14:22] <rtg> sure is
[14:22] <rtg> better check the 4.1 branch
[14:23] <rtg> looks like that one is OK
[14:23] <rbasak> awe: thanks!
[14:23] <infinity> rtg: Misplaced your cowboy hat in between versions?
[14:23] <awe> np
[14:24] <infinity> rbasak: So, that totally has apt-get being the culprit, not update-manager.  We can stop panicking.
[14:25] <infinity> rbasak: As in, *someone* got impatient that grub wasn't upgrading and ran "apt-get install grub" and said "sure, remove everything" when it prompted.
[14:25] <infinity> In fact, wait.  That's grub1, even.
[14:25] <infinity> awe: So, that was totally self-inflicted.
[14:26] <infinity> awe: Your manual installation of grub1 removed grub2, and you said "yes".
[14:26] <rbasak> infinity: AIUI, awe had a problem after the update, and he tried to fix it by installing grub
[14:26] <rbasak> infinity: but yes, the problem wasn't cause because the grub2 signed package got removed. Must have been caused by some other thing.
[14:26] <infinity> rbasak: Well, there are no removals until that point.
[14:26] <rbasak> Right
[14:27] <awe> infinity, I only did the manual install of grub *after* my system stopped rebooting correctly
[14:27] <awe> and yes, it was a mistake
[14:28] <awe> but didn't really worsen or improve anything
[14:28] <infinity> awe: Check.  What are/were the symptoms of "not booting correctly"?
[14:29] <apw> rtg, yes, you ripped aufs out and switch the way it was updated for v4.1
[14:29] <awe> I'm dual-booting a macair osx + utopic
[14:29] <awe> after yesterday morning's update
[14:29] <rtg> apw, right, I'm using the upstream mechanism
[14:29] <awe> my machine no longer booted into rEFInd
[14:29] <awe> I got a "Your screwed screen"
[14:30] <awe> ( ie. do you wanna re-install OS X from TimeMachine backup, fresh install, go online for help, or bring up disk tools )
[14:30] <apw> rtg, indeed, i mean that is why the disablement didn't get carried over, one was against ubuntu/Makefile, the other against fs/Makefile
[14:30] <rtg> apw, yup
[14:30] <awe> so now on restart, I need to do an Option+Pwr boot, and then select EFI boot
[14:30] <awe> the other options being the two OSX recovery partions
[14:31] <infinity> awe: Curious.  I don't know much of anything about rEFInd, but since rbasak's been trying to be helpful, I'll let him keep at it. :P
[14:31]  * awe heads to yet another mtg
[14:31] <awe> thanks infinity
[14:31] <rbasak> Well, I'm not sure any more :-/
[14:32] <rbasak> Not sure how much more helpful I can be. I was concerned yesterday that there might be a grub2-signed breakage problem, and so when awe's problem appeared, was concerned that it was that.
[14:32] <rbasak> But it wasn't, so perhaps my concern isn't as big of an issue (that's the trouble with a sample size of 1). But that doesn't help at all with awe's actual problem, of which I have no idea.
[14:36] <arges> rodsmith: hey, awe had some issues with rEFInd. Maybe you can help?
[14:36] <rodsmith> Hi. I'm told somebody has a rEFInd question. I'm the current maintainer. What's the question?
[14:36] <rtg> apw, there are significant changes to overlayfs in 4.2; perhaps you could add to your TODO list to forward port "UBUNTU: SAUCE: overlay: add backwards compatible overlayfs format support V3"
[14:36] <apw> rtg, ack
[14:36] <rtg> apw, in unstable master
[14:36] <apw> master or master-next ?
[14:37] <awe> rodsmith, rbasak, I just joined a planning meeting; short version... I updated yesterday, and my macair no longer boots into rEFInd
[14:37] <rtg> apw, I think I'm gonna drop unstable master-next 'cause it really isn't very useful. what do you think ?
[14:37] <awe> now, I have to do an 'Option' + Pwr, and select "EFI Boot" every time
[14:37] <awe> not sure if I re-bless from OS X would fix this?
[14:37] <awe> This is the first time an Ubuntu update has broken things for me
[14:37] <rodsmith> awe: Can you get into both OS X and Ubuntu via the Option key?
[14:38] <awe> I get to rEFInd via the option key, and have only booted Ubuntu from there since
[14:38] <awe> haven't checked OSX
[14:38] <rodsmith> awe: If you can get into OS X, try re-installing rEFInd.
[14:38] <awe> without the option key
[14:38] <awe> I get a "Do you want to re-install or fix things" screen
[14:38] <rodsmith> awe: The Ubuntu update probably tried to install/re-install GRUB, which messed things up.
[14:39] <awe> right
[14:39] <awe> I'll try a re-install from OS X and see if that fixes things
[14:39] <rodsmith> awe: The "re-install or fix things" prompt sounds like APT didn't quite set everything up right.
[14:39] <awe> right
[14:39] <awe> thanks
[15:19] <rtg> manjo, smb: I see that dm-raid45 hasn't been updated since April 2009. We are carrying it as a SAUCE driver. Do you think it is still relevant ?
[15:20] <manjo> rtg, wow... I will need to look coz I am not sure who is using that 
[15:20] <smb> rtg, depedns on how many people use a non-Intel fakeraid in bios mode... 
[15:21] <smb> Intel MSM and DDS should be handled by mdadm nowadays
[15:21] <smb> rtg, Sure we will notice (after release) when you rip it out for now
[15:22] <rtg> smb, well, I haven't ripped it out yet. I'm just reviewing SAUCE patches
[15:22] <manjo> smb, wasint there an issue where softraid was not write able ? 
[15:22] <manjo> smb, May be that issue with mdadm is already fixed 
[15:23] <smb> manjo, at some point long time ago. but afaict Trusty works without dmraid
[15:23] <manjo> rtg, will that impact backport kernels for lts ? 
[15:24] <rtg> manjo, yup
[15:24] <manjo> ugh
[15:24] <rtg> maybe it should wait until after 16.04 to be removed
[15:24] <manjo> when does precise sunset? /me does the math
[15:25] <manjo> 12.04 .. so 17.04? 
[15:25] <rtg> yup
[15:25] <manjo> s**t 
[15:26] <smb> rtg, Might be that is what we said before T... But with a crisp memory like mine and we should have written it down... but then maybe we did and I just forgot where
[15:27] <rtg> smb, its no big deal. so far maintenance has been easy, but I wanted to be sure the driver actually still worked
[15:29] <TJ-> rtg: If it's any help I can do some tests with a Promise controller; which kernel/ubuntu release would you want testing?
[15:29] <smb> rtg, I doubt I ever tested the other module ever again after mdadm worked for Intel... and none of my other hw would have fakeraid beyond levels 1
[15:29] <manjo> rtg, also people using vmware stuff might still need that module on precise 
[15:29] <rtg> ok, I'll defer removing the driver
[15:47] <apw> rtg, we if we are removing it in 16.04 we should disable it in the main build and re-enable it in the lts-backport
[15:47] <rtg> apw, I was thinking _after_ 16.04
[15:53] <apw> then you might need to support it in the backports up to and including 18.04 in 16.04 even if it is disabled in those releases
[15:53] <apw> because it _is_ enabled in 16.04
[15:55] <rtg> apw, 16.04 is the last backport for 14.04. perhaps we should only enable dm-raid45 in the backport and not in 16.04 proper
[15:57] <apw> rtg, that was my suggestion indeed
[16:09] <infinity> rtg: I concur with apw (and you).  If you intend to drop drivers, do so in 16.04, but add them back to the lts-x kernel.
[16:09] <rtg> infinity, now I just gotta remember to do it
[16:09] <infinity> rtg: Though, you could also drop them in wily and add them back to the lts-w kernel too.
[16:09] <infinity> rtg: Which gives people some time to get used to the idea.
[16:10] <rtg> yup
[16:11] <infinity> rtg: Makes an argument for maintaining lts-w starting around, oh, now, though.  So you don't end up with 73 post-its detailing "stuff that needs to happen on top of the backport". :)
[16:11] <rtg> thats just too logical
[16:12] <unixabg> Greetings, does the 15.04 kernel have multi-layer overlayfs support? (multi-layer meaning more than 2)
[16:15] <apw> unixabg, that is a feature of later kernels, so wily may have it iwth the very latest kernels
[16:19] <unixabg> apw: humble appreciation for response.
[16:20] <apw> unixabg, i don't think 3.19 had it, but i am not 100% sure
[16:21] <unixabg> apw: would you know what version would have such support?
[16:22] <unixabg> I ask since I am wanting to test it some and I need partial .squashfs files for service packs.
[16:23] <apw> unixabg, looks like v4.0 was the first upstream release with it in
[16:23] <apw> so only wily very latest kernel would have it
[16:28] <unixabg> apw: thank you and I will work on testing with that then.
[16:31] <unixabg> apw: what is the shortest route to install and test the 4.x kernel?
[16:31] <apw> well other than running wily, you could install that kernel from the archive by hand
[17:12] <unixabg> apw: thank you for the assistance I will download from http://cdimage.ubuntu.com/daily-live/current/
[18:59] <dsd> hi, i read that Ubuntu Wily might be based on Linux 4.1. is there a Ubuntu kernel git tree for that already?
[19:03] <rtg> dsd, ultimately Wily will release with 4.2
[19:06] <dsd> i see
[19:07] <dsd> and have you started the process of moving the patches from 3.19 to a newer kernel like that?
[19:07] <dsd> or is that going to happen a bit later
[19:08] <rtg> dsd, All 4.1 work is happening here until 4.2 is released: git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily master-next
[19:11] <dsd> thanks!
[20:01] <unixabg> apw: have you worked on casper? I ask since I see an apw there on a commit message.
[21:13] <apw> unixabg, only in a very peripheral way, but the last upload was in my name in trusty yes
[22:24] <SturmFlut> Good midnight! Anybody still awake?