[01:12] <adam_g> zul: you around?
[02:17] <adam_g> smoser: so, with keystone in place regular users can access glance directly through glance client. not sure how youd like to extend the publish scripts, but OS_USERNAME, OS_PASSWORD, OS_TENANT_NAME and OS_AUTH_URL need to be set accordingly
[02:18] <smoser> adam_g, right.
[02:19] <smoser> i think the goal would be to maybe take a flag '--cloud=nova', but basically just DTRT if the environment had nova config versus ec2.
[02:19] <smoser> and in the case where both were present consult a environment variable, or require the flag
[04:06] <Zanzacar> I am trying to find a text based installer image for ubuntu-server 32bit but am not sure which is which.
[04:06] <Zanzacar> This is where I went http://releases.ubuntu.mirrors.uk2.net/ for my information.
[04:09] <Zanzacar> can I just download the alternate version here? http://www.ubuntu.com/download/ubuntu/alternative-download#alternate
[04:11] <qman___> Zanzacar, ubuntu server uses the text based installer already
[04:11] <qman___> if you're having problems, try the nomodeset option
[04:13] <Zanzacar> This computer I am trying to install ubuntu-server on locks up at the selection of the language.
[04:13] <Zanzacar> I thought it might be a video card problem. What is nomodeset option?
[04:13] <twb> Zanzacar: what release are you installing?
[04:14] <Zanzacar> 11.10
[04:14] <qman___> if it locks up before you can select a language, odds are you won't be able to install
[04:14] <qman___> could try the key presses blind and see if it goes
[04:15] <qman___> nomodeset disables KMS, which doesn't work in some rare instances, it's the new thing that enables a high resolution console
[04:15] <qman___> I think it's F6 to disable, but that's after you select a language
[04:19] <Zanzacar> I will trying pressing f6 and see what happens, or maybe trying the keys blind but that doesnt seem reasonable.
[04:29] <Zanzacar> so F6 didnt do anything and I didnt see any changes from trying to just press enter a bunch of times and go throught he menus blind.
[04:29] <Zanzacar> any other thoughts?
[04:42] <Tohuw> If my local network is 10.254.7.0/24, what is the proper syntax to express every 10.in-addr.arpa address except that subnet? I need to know so that I can list it in my modified rfc1918 zones file. Or is it top-down processing, such that a later reference to that subnet and another db will take precedence?
[04:44] <qman___> Zanzacar, try a different graphics card, or try 10.04 or 8.04 to see if either works, it'll help narrow down the problem
[04:44] <qman___> also verify the md5sum on your burn
[04:45] <qman___> you can literally md5sum /dev/scd0 and it should match the ones on the mirror
[04:45] <Zanzacar> gotcha I think I might try a previous version
[06:15] <Zanzacar> qman I have tried version 8.04 and that didnt work either :( I am guessing this system is just not supported?
[06:17] <SpamapS> Zanzacar: perhaps try the mini.iso
[06:20] <Zanzacar> I think it isnt ubuntu I think it is this computer. I tried to boot to a windows xp CD that I know works and I just get a blinking _
[06:23] <SpamapS> Zanzacar: yeah, step 1.. get a decent computer. :)
[06:28] <twb> SpamapS: when one is ever made, you let me know.
[06:31] <Zanzacar> so I think I figured out my "problem" my bios was disabling my usb-keyboard. which was giving me problems.
[06:38] <SpamapS> twb: the Amiga 500 was pretty good
[07:06] <Zanzacar> thats an awesome comp.
[07:07] <Zanzacar> ya for on board keyboard. i wonder how fast i can type with this.
[09:07] <jamespage> morning all
[09:10] <lynxman> jamespage: morning!
[09:10] <jamespage> lynxman, howdy!
[09:11] <jamespage> lynxman, hope it nicer wherever you are :-)
[09:11] <lynxman> jamespage: I'm almost finished with rabbitmq-server but now... (oh the news) looks like the cddb packaging skips a fair amount of files that are required to be there, so I'm converting it to plain install
[09:11] <lynxman> jamespage: it's raining and gray here
[09:11] <jamespage> lynxman, snap
[09:12] <jamespage> although my weather indicator just died so I can't really tell...
[09:12] <jamespage> :-)
[09:12] <jamespage> lynxman, switching to straight debhelper is probably a good thing
[09:12] <jamespage> but I would suggest we get it stuck in the PPA for the openstack test lab before it gets uploaded just like we did for the 2.7.1 upgrade
[09:13] <jamespage> I don't suppose that SpamapS is still awake?
[09:13] <lynxman> jamespage: don't think so, but I'm more than happy with that, I'm just comparing notes with the release the rabbitmq guys do
[09:14] <lynxman> jamespage: anyway I'll get my hands dirty with this this morning ;)
[09:14] <jamespage> \o/
[09:23] <jamespage> Daviey, around?
[09:30] <Daviey> jamespage: o/
[09:33] <jamespage> Daviey: are you intending on reviewing any of the zentyal packages?
[09:36] <Daviey> jamespage: Yes, SpamapS should be sharing them out.. but i guess if we get to them first, it works well.
[09:36] <Daviey> jamespage: Are you able to poke what is going on with https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/job/precise-server-amd64_lamp-reboot/lastCompletedBuild/testReport/test/LampRebootTest/testModPhp/ ?
[09:36] <jamespage> Daviey, I was going to knock some off this morning
[09:36] <jamespage> Daviey, SpamapS is looking at that (one of his new reboot tests)
[09:37] <Daviey> jamespage: ahh, cool
[09:37] <jamespage> Daviey, I wanted to get you opinion on some general observations before I started - do you have time?
[09:37] <Daviey> jamespage: always
[09:37] <jamespage> Daviey, OK so 1.  All of the packages are native format - I think this is OK but wanted to check....
[09:38] <jamespage> The VCS is upstream and the code is Ubuntu specific as far as I can tell
[09:40] <jamespage> 2. copyright files are not DEP-5 format - I know this is optional -I would normally request that this be updated but this late in the cycle I think as long as the content is correct we should not block on that
[09:43] <Daviey> jamespage: I have no problems with native packages in Ubuntu, but it does make life harder for derivatives of Ubuntu.
[09:43] <Daviey> It's policy compliant, but i did see a rejection recently asking about it.
[09:44] <Daviey> jamespage: Well, if it's a one-time job for all the packages, fixing to DEP-5 would be nicer.
[09:44] <Daviey> (considering it's now 'offical')
[09:44] <jamespage> Daviey, yeah - so I see
[09:45] <Daviey> jamespage: if it's a cheap thing to do for all the packages, lets do it.. Otherwise, lets leave it.
[09:46] <jamespage> Daviey: OK - although of course they are native packages so upstream will have to make all of the amends....
[09:47] <Daviey> jamespage: Okay, i imagine we might want to make other changes aswell.
[09:47] <Daviey> Lets convert them to 3.0 (quilt)
[09:47] <Daviey> Then we can post a diff back.
[09:48] <jamespage> Daviey, explain - not sure I get it?
[09:50] <Daviey> jamespage: Sorry.. I mean.  Do you think we should convert all the packages to 3.0 (quilt), rather than native..
[09:50] <Daviey> And fix the changelog
[09:50] <Daviey> As in, shall we open bzr branches?
[09:51] <jamespage> Daviey, that would be my preference
[09:51] <jamespage> I think its just easier to manage
[09:51] <jamespage> but its more work now
[09:51] <Daviey> jamespage: Can you point me to the src?
[09:52] <jamespage> Daviey, packages for review are here https://launchpad.net/~jacalvo/+archive/zentyal-precise/
[09:52] <Daviey> jamespage: Ok, i'll import them all to bzr now.
[09:53] <Daviey> (unless you want to?)
[09:55] <Daviey> jamespage: for starters, the Maintainer field isn't policy compliant
[09:57] <jamespage> Daviey, missing Uploaders?
[09:57] <Daviey> jamespage: no, it should be @ubuntu.com
[09:57] <Daviey> (minor quibble really)
[09:58] <jamespage> Daviey, even if it is a native package?
[09:58] <Daviey> Makes no difference, native to Ubuntu, not native to upstream.
[09:58] <jamespage> I guess thats why I'm a little uncomfortable with native format
[09:59] <jamespage> with the way its structured the packaging is maintained in the upstream VCS
[09:59] <Daviey> The main PITA is carrying patches
[09:59] <Daviey> ie, you patch directly.
[09:59] <jamespage> to which NO ubuntu-devel has access
[10:00] <jamespage> so it really is native to upstream - not Ubuntu :-)
[10:01] <jamespage> I had similar with the rds packaging - took a while to explain
[10:01] <Daviey> jamespage: *awesome* LP is offline
[10:01] <jamespage> Daviey: lol
[10:03] <jamespage> Daviey: ebox was not native format - as this is basically a rename/upgrade I think that it should not change
[10:04] <jamespage> Daviey, infact it looks like the native-non-native transition happened last time as well.
[10:04] <Daviey> lol
[10:07] <jamespage> Daviey, so are we agreed that WE should be making that transition, not upstream
[10:07] <jamespage> or do we need to discuss with them first?
[10:10] <Daviey> jamespage: They have euro TZ people iirc
[10:10] <Daviey> jamespage: Fancy trying to look up irc nicks?
[10:10] <jamespage> Daviey, on it now
[10:10] <Daviey> cool
[10:18] <jacalvo> jamespage, do you want to discuss anything about zentyal packages? :)
[10:18] <jamespage> jacalvo, you read my mind!
[10:18] <jamespage> jacalvo: Daviey and I where just discussing whether we should switch them from native to non-native format
[10:19] <jacalvo> I'm sure bencer would also be present in the discussion, he's AFK now, but he can read the log later
[10:19] <jamespage> its been done in the past for ebox
[10:19] <jacalvo> I suppose it's not a problem, specially if there is no other option :)
[10:20] <jamespage> jacalvo, well native really means native to Ubuntu, not native to zentyal
[10:20] <jamespage> so having them as non-native packages would make more sense IMHO
[10:20] <jamespage> easier to manage as well...
[10:21] <Daviey> jamespage: https://code.launchpad.net/zentyal
[10:22] <jacalvo> so we need to set the versions to something like 2.3-0ubuntu1 ?
[10:22] <jacalvo> or does it have more implications?
[10:22] <Daviey> jacalvo: that is perfect.
[10:23] <jamespage> jacalvo, spot on
[10:23] <Daviey> jacalvo: As long as it is > that what is currently in Ubuntu (any release)
[10:23] <jacalvo> seems easy then, I'm a bit busy now but I'll work on that asap
[10:24] <jacalvo> thanks for your help!, and let me know if we can do anything else
[10:25] <Daviey> jacalvo: What is the 'version' of this release?
[10:25] <Daviey> jacalvo: 2.3.1?
[10:26] <jacalvo> well, each module has its own version, and some of them are already 2.3.2
[10:26] <Daviey> ah, ok..
[10:27] <Daviey> jacalvo: Do you happen to know what versions diverged between Ubuntu and your PPA's?
[10:27] <Daviey> as in, I see some ones that really went into Ubuntu, and others such as 1.5.1-0ubuntu1~ppa1~lucid1
[10:27] <jamespage> Daviey, so those should be the old ebox packages?
[10:28] <Daviey> right
[10:28] <jacalvo> the old ebox packages are 2.0
[10:28] <jacalvo> they were introduced in natty
[10:28] <jacalvo> 1.5 are even older
[10:28] <Daviey> jacalvo: right, but i'm trying to find an easy way of trimming the changelog to reprenset exactly what went into Ubuntu
[10:28] <jacalvo> not sure if I understand your questions about what versions diverted...
[10:28] <jacalvo> diverged*
[10:29] <jacalvo> ah ok
[10:29] <jacalvo> let me see
[10:29] <Daviey> maybe steal the oneiric ubuntu changelog, place it in, and prepend with "New upstream version"
[10:30] <jacalvo> you mean changes in the code? there a lot because there is a whole major release in the middle (2.2)
[10:30] <jacalvo> which was never uploaded to ubuntu
[10:31] <jacalvo> all the changes of the intermediate 2.1.* and 2.2.* versions
[10:31] <jacalvo> or you mean changes in the packaging?
[10:32] <jacalvo> http://git.zentyal.org/zentyal.git/blob/refs/heads/precise:/main/core/ChangeLog (from 2.3.2 to 2.0)
[10:33] <jacalvo> to 2.0.15 more precisely
[10:37] <jamespage> Daviey: I think this links to the whole native -> non-native packaging format switch
[10:38] <jamespage> Daviey: I would not expect to find entries for PPA's/package updates that have never been in any distro in the distro changelog
[10:38] <jamespage> Daviey: ?
[10:38] <Daviey> right, so stealing the Oneiric changelog is probably sane.. and adding a new entry?
[10:40] <jamespage> Daviey: I think so - I'm just trying to figure out how we can converge the packaging maintenance going forwards
[10:40] <jamespage> rather than having the 'import native version' + 'delta non-native version' that we seem to have been doing with ebox
[10:40] <jamespage> if that makes sense...
[10:40] <Daviey> right
[10:41] <Daviey> jacalvo: Would you be happy to revert to non-native?
[10:41] <jacalvo> yes, I think there is no problem at all
[10:41] <Daviey> Then, all we should have to do is import.. and flush non-ubuntu changelog entries
[10:42] <jamespage> Daviey: the problem is that the zentyal release is a native package is it not?
[10:42] <jamespage> rather than a tar.gz of the source code?
[10:42] <Daviey> jamespage: right, but if they revert, we are gold
[10:42] <jamespage> ah -  I see
[10:43] <jamespage> so in the future zentyal releases 2.4.0-0ubuntu1 into PPA
[10:43] <jamespage> someone then merges that into the distro packaging branch and uploads?
[10:43] <jamespage> picking up any deltas that have been made since the previous upstream zentyal package?
[10:43] <Daviey> jamespage: right..
[10:44] <jacalvo> mm, but I was going to release a 2.3 installer right today, I can't change that to -0ubuntu1 now...
[10:44] <jacalvo> is that ok?
[10:44] <jamespage> I guess that could be jacalvo once he gets from PerPackage upload rights :-)
[10:44] <jacalvo> I mean, can be done just in the future when a major version switch is done?
[10:44] <Daviey> jamespage: ideally, they'd do something like 2.4.0-0ubuntu1~zentyal for non-ubuntu uploads.
[10:44] <jacalvo> bencer is already applying for that :)
[10:44] <jamespage> jacalvo, great
[10:44] <jacalvo> for the Per-Package Upload rights
[10:45] <Daviey> \o/
[10:45] <jamespage> Daviey: still feels sticky to me
[10:45] <Daviey> jamespage: oh?
[10:46] <jamespage> I don't like that fact that we potentially have packaging delta in the distro
[10:46] <jamespage> that just makes work for someone
[10:46] <Daviey> jamespage: Hmm, i'm not sure we will?
[10:47] <jamespage> Daviey, agreed but it is possible
[10:48] <Daviey> jamespage: have a plan?
[10:48]  * jamespage scratches his head
[10:49] <jamespage> other than ask jcalvo to start releasing the source code for each module in a completely different way - not really
[10:49] <jamespage> but that does not make much sense either....
[10:50] <jamespage> jacalvo, zentyal is Ubuntu only?
[10:50] <jacalvo> yes
[10:50] <jacalvo> it started as debian only
[10:50] <jacalvo> but it turned to ubuntu only in 2004
[10:51] <jamespage> jacalvo, Daviey: OK so lets just make sure we work really closely together going forwards an use the zentyal released packages as upstream for Ubuntu
[10:52] <jamespage> having a ~zentyalX suffix on the version number makes alot of sense from that perspective and we should probably retain those in the Ubuntu changelog.
[10:53] <bencer> jamespage: Daviey i was reading the backlog
[10:53] <bencer> zentyal is ubuntu only software
[10:53] <bencer> so for me makes sense to release it as native packages
[10:53] <Daviey> jamespage: I hate having non-archive uploads in d/changelog :)
[10:53] <bencer> what is not pretty straigthforward is how to deal with ubuntu uploaded packages versioning and ppa uploaded packages versioning
[10:54] <bencer> Daviey: i agree
[10:54] <bencer> and what we have in debian/changelog is a mess now
[10:54] <bencer> as we are uploading the packages i was thinking about forget the previous things in debian/changelog and do a clean start
[10:55] <jamespage> bencer, +1 on that
[10:55] <jacalvo> yeah, that sounds good
[10:56] <bencer> jamespage: do you agree on maitaining the native packaging too?
[10:56] <bencer> we have a lot of things that go in the packaging like upstart jobs
[10:56] <bencer> that we totally depend on that
[10:56] <Daviey> bencer: If you do something like, 2.4.0-0ubuntu1 for Ubuntu uploads, then do 2.4.0-0ubuntu1+ppa[0.9] to incremement on the prior upload.. Then as you get closer a new 'release' you can do 2.5.0-0ubuntu1~ppa[0..9] (~ means less)
[10:57] <jamespage> hmm
[10:57]  * jamespage thinks again about native packaging approach
[10:58] <bencer> i like the native thing, we dont have plans to port zentyal to other distros
[10:59] <bencer> we depend on upstart, we depend on ubuntu packages versions for the configuration templates...
[10:59] <jamespage> bencer, OK you are talking me round to the idea
[11:00] <bencer> i think native packaging is ok, what i'm not sure is how to deal with ubuntu uploaded versions and our ppa uploaded versions then
[11:01] <jamespage> bencer: we need to ensure that upgrades select ubuntu over PPA
[11:01] <jamespage> so if someone is using the PPA things work out OK
[11:01] <bencer> jamespage: this is "desired" or is in the policy?
[11:02] <Daviey> no
[11:02] <jamespage> desired
[11:02] <Daviey> If zentyal want to make a post release PPA that users can use, that is fine.
[11:02] <Daviey> So the version needs to be higher than Ubuntu
[11:02] <jacalvo> I don't understand that, so if a user wants to get a newer version from our ppa he should be able to...
[11:02] <Daviey> .. but smarts have to be taken to make sure you don't go higher than the next Ubuntu version.
[11:03] <Daviey> (hence appending +ppa0 or ~ppa0)
[11:03] <jamespage> Daviey: so using a ~zentyal on the PPA uploads makes sense then
[11:03] <jamespage> native or non-native packaging.
[11:04] <jamespage> jacalvo, so in the current versions:
[11:04] <jamespage> PPA currently has 2.3.1~zentyal for precise
[11:04] <jamespage> we push 2.3.1 into precise - folk who have the PPA enabled get the version from precise
[11:05] <jamespage> post release of precise you push 2.3.2~zentyal to the PPA for precise - people get the PPA version instead of distro
[11:05] <bencer> that sounds fine for me
[11:05] <bencer> jacalvo: what do you think?
[11:05] <jamespage> when 2.4.0 is pushed into 'Q' then users get that
[11:06] <bencer> jamespage: sorry, what 'Q' means?
[11:06] <jacalvo> the one after 'P' ;)
[11:06] <jamespage> bencer: next release of ubuntu
[11:06] <jamespage> precise+1
[11:07] <bencer> ok
[11:08] <jamespage> Daviey: are you happy with this proposed approach?
[11:08] <jacalvo> I suppose it is ok
[11:09] <jacalvo> but I can change the ppa versions now, it will have to wait some days until the next release
[11:09] <jacalvo> is that a problem for uploading the current ppa:jacalvo/zentyal-precise ones?
[11:09] <jacalvo> I suppose when you talk about PPA you mean ppa:zentyal/2.3, right?
[11:10] <bencer> jacalvo: yes
[11:10] <bencer> i think as long as we have the packages in the ppa with that versioning once precise is released, is ok
[11:11] <jacalvo> we can have them before that for sure
[11:11] <Daviey> jamespage: wfm
[11:11] <jacalvo> so finally we stick to native with package versions like 2.3.3~zentyal, right?
[11:11] <Daviey> Before saying that is OK, i'd like to discuss it with an Archive Admin.
[11:11] <Daviey> (sorry)
[11:12] <jacalvo> no problem
[11:12] <bencer> 2.3.3 for ubuntu universe, 2.3.3~zentyal for out ppa
[11:12] <bencer> *our ppa
[11:14] <bencer> jamespage: Daviey how do you suggest to deal with the debian/changelog then, imho upstream changelog and debian/changelog on native packages should be exactly the same
[11:14] <jamespage> jacalvo, bencer, Daviey: I'll start working through the packages now in terms of general review pending confirmation from an AA on the discussed approach to versioning
[11:14] <bencer> jamespage: ok, thanks
[11:15] <jacalvo> thanks!
[11:16] <jamespage> bencer, jacalvo: I'll update the bug report with feedback on each one
[11:16] <jacalvo> great
[11:16] <bencer> jamespage: do you have any opinion on the changelog thing?
[11:17] <jamespage> bencer: I think we should retain the entries for the ~zentyal versions
[11:17] <jamespage> its a bit like what we do with Debian - but we are downstream to you
[11:18] <bencer> as long as the version in the ppa is the same than in the ubuntu should be fine
[11:18] <jamespage> after all we keep Debian changelog entries even tho they have not been uploaded to Ubuntu
[11:18] <bencer> i wonder how we would deal if we had to do any upload to -proposed or -security
[11:19] <jamespage> I think we should deal with that in the distro; for example if we need to update 2.3.1 we go to 2.3.1ubuntu0.1 for the fixes
[11:19] <bencer> and then merge that changelog in the upstream changelog?
[11:19]  * jamespage hopes his thinking is rationale
[11:20] <jamespage> bencer: the fix should land in the upstream version first; then land in the current Ubuntu dev release - and then be backported
[11:20] <bencer> imagine we are in upstream 2.3.5 and we need to upload 2.3.3ubuntu0.1
[11:20] <bencer> ok
[11:20] <bencer> in that case, we 2.4 gets uploaded to ubuntu+1, the changelog for 2.3.3ubuntu0.1 would be lost?
[11:21] <jamespage> in your VCS yes
[11:21] <Daviey> jamespage: did you see i imported all the packages to bzr?
[11:21] <jamespage> but not in the version maintained for Ubuntu in launchpad
[11:21] <jamespage> Daviey: yes - thanks thats really helpful
[11:21] <jamespage> I'll review from there
[11:22] <jamespage> Daviey: if you are intending on looking at some I'll pickup zbuildtools -common and -core now
[11:22] <bencer> Daviey: jamespage did you see the review that christophe already did on the packages?
[11:22] <bencer> os this is inteded to be a parallel review?
[11:22] <jamespage> bencer, no - its not in the bug report - do you have a link
[11:22] <jamespage> ?
[11:23] <bencer> he sent me that by mail
[11:23] <Daviey> i don't think is aw it either
[11:24] <bencer> still i didnt have time to have a look at his comments
[11:24] <jamespage> bencer: please could you paste it into the bug report
[11:24] <bencer> sure, give me 20min to have a look at it
[11:25] <bencer> so, the workflow should be maintaining the ubuntu packaging in bzr
[11:25] <bencer> and sync from out upstream git to there
[11:26] <bencer> merge with the possible ubuntu-specific changes, like security uploads in the changelog, or whatever
[11:26] <bencer> and push to the archive, right?
[11:26] <jamespage> thats pretty much inline with what we have discussed
[11:27] <bencer> understood then, sounds good
[11:27] <jamespage> actually taking it directly from git makes alot of sense.
[11:27] <bencer> a bit weird that upstream gets the ~zentyal and not the plain release
[11:27] <bencer> but not a big deal
[11:29] <Daviey> zul: Anything left to do on, bug 934064 ?
[11:30] <Daviey> smb: In the meeting yesterday, i intended to bring up bug 905219, is it on your radar?
[11:31] <smb> Daviey, No it was not
[11:31] <bencer> jamespage: Daviey going to review huats comments and i will attach them on the lp issue
[11:31] <smb> Daviey, but I see Chris assigned there
[11:32] <Daviey> bencer: cool
[11:32] <Daviey> smb: great
[11:33] <iclebyte> is there some app which lets you pick a mirror and setup your /etc/apt/sources.list file?
[11:33] <jamespage> bencer: OK I'll find something else todo until thats posted (don't want to dupe effort)
[11:39] <Daviey> iclebyte: we talked about it, but don't thik we put proper effort into it.. you could try apt-spy
[11:41] <bencer> jamespage: https://bugs.launchpad.net/ubuntu/+source/ebox/+bug/928501/comments/15
[12:06] <lynxman> jamespage: need to poke your brain for a bit whenever you're around :)
[12:06] <zul> Daviey:  dont think so
[12:28] <rbasak> jamespage: ping
[12:28] <jamespage> lynxman, rbasak: pong
[12:28] <jamespage> lynxman, wassup
[12:52] <lynxman> jamespage: hey :)
[12:54] <uksysadmin> can I bug someone about rabbitmq and clustering vs HA?
[12:55] <uksysadmin> (it is in a ubuntu install ;-))
[12:56] <lynxman> uksysadmin: clustering in 2.6.1 is a bit tricky, but go ahead :)
[12:56] <lynxman> jamespage: so rabbitmq 2.7.1 package, it's based on the upstream rules and it's cddb
[12:57] <lynxman> jamespage: problem being I've already added a quilt patch (for a bug fixed by therve) and we use the new install method for the other subpackages
[12:57] <jamespage> lynxman, lemme take a look
[12:57] <lynxman> jamespage: so we can either rework the cddb into the new format and push the change upstream to rabbitmq or try to keep it as close as possible to the original
[12:57] <lynxman> jamespage: let me paste you the rules file
[12:57] <lynxman> jamespage: http://pastebin.ubuntu.com/872948/
[12:58] <lynxman> jamespage: now problem being that with the mixed format DEB_MAKE_INSTALL_TARGET doesnt work properly and only packs the binaries
[12:59] <uksysadmin> its more a general q - we're looking at rabbitmq in prod, and I believe already we have to stray from ubuntu 12.04 rabbitmq for some reason (I'm late in with the project - they're now shouting help).
[13:00] <jamespage> lynxman, hmm
[13:00] <lynxman> uksysadmin: just wait for 2.7.1 new package then :)
[13:00] <uksysadmin> lynxman, when's that due?
[13:00] <lynxman> jamespage: I know I'm frying something not properly, for sure, I can push my debian directory to a branch for review
[13:00] <lynxman> uksysadmin: as soon as I finish :)
[13:00] <jamespage> lynxman, I think I see the issue
[13:01] <jamespage> the package does not use any sort of patch system and is implicitly format 1.0
[13:01] <lynxman> jamespage: so what do you reckon it is?
[13:01] <jamespage> thats all bad
[13:01] <lynxman> jamespage: yeah I moved it to quilt 3.0 format
[13:01] <uksysadmin> lynxman lol
[13:01] <jamespage> so adding a quilt patch and switching format it probably not the right way to approach this at this point in the release
[13:02] <jamespage> I would apply the patch directly into the source tree (as someone has already done)
[13:02] <uksysadmin> and then I'll get the guys to follow the clustering recommendations.  what does clustering give that load balancing doesn't? in a cluster is one node acting as some sort of master?
[13:02] <lynxman> jamespage: lp:~lynxman/junk/rabbitmq271debian
[13:03] <lynxman> jamespage: yeah saw that but I just wanted to be clean, you reckon that's the problem then? :)
[13:03] <lynxman> uksysadmin: active active vs active passive pretty much
[13:03] <jamespage> lynxman, it might be; I'd endeavour to have as little impact on this package to make your changes at this point in the cycle
[13:04] <lynxman> jamespage: alright, I'll go that way then and see if that recovers the issues :)
[13:04] <lynxman> jamespage: wish me luck
[13:04]  * lynxman dives
[13:04] <jamespage> lynxman, onesecond - lemme check
[13:04] <lynxman> jamespage: alright
[13:04] <uksysadmin> where load balance is active active (as you can hit multiple nodes) vs cluster which is replicating to slaves? Or have I got that the wrong way around?
[13:04] <jamespage> so what specifically was the issue you are seing?
[13:04] <lynxman> uksysadmin: wrong way around in this case
[13:05] <uksysadmin> lynxman, ok cheers.
[13:05] <lynxman> jamespage: all is packaging okay, but the rabbitmq-server package lacks the libraries, so it's not listening to $RABBIT_BIN and $RABBIT_LIB in the rules
[13:05] <uksysadmin> (guess who has a meeting on rabbitmq in 1 hr... ;-))
[13:05] <lynxman> jamespage: I reckon that's due to the package format change
[13:05] <lynxman> uksysadmin: I hope not me :D
[13:05] <uksysadmin> you can be invited if you want
[13:05] <uksysadmin> ;-)
[13:05] <lynxman> uksysadmin: I have hmm... to pay my taxes... yes
[13:08] <jamespage> lynxman, so long as you have managed your patches OK cdbs + source format 3.0 (quilt) should be OK
[13:08] <lynxman> jamespage: so then the lack of libraries must be something else
[13:08] <jamespage> rabbitmq-server.links looks dodgy
[13:08] <uksysadmin> damn, should've thought of that one.  I said washing my hair but it didn't go down too well.
[13:09] <lynxman> uksysadmin: maybe lack of long hair makes that one a bit more dubious ;)
[13:09] <lynxman> jamespage: hmm haven't touched that one
[13:09] <uksysadmin> :)
[13:24] <jamespage> lynxman, I think its the way you have transitioned the rabbitmq-server binary package stuff
[13:24] <jamespage> lynxman, just trying something
[13:24] <lynxman> jamespage: hmm okay I'll wait for your feedback then
[13:24] <lynxman> jamespage: this is quite a complicated package :/
[13:25] <jamespage> lynxman, it def running the make install correctly
[13:28] <jamespage> lynxman, well I've learn't something new today
[13:29] <jamespage> lynxman,  $(DEB_DESTDIR) for a source package with a single binary package looks to get set to debian/$package_name
[13:29] <jamespage> but with multiple binary packages it get set to debian/tmp
[13:30] <jamespage> so the package was working implicitly before as everything got installed to debian/rabbitmq-server
[13:30] <jamespage> and is now borked as there is no explicit install for rabbitmq-server
[13:31] <lynxman> jamespage: aha!
[13:31] <lynxman> jamespage: very interesting :)
[13:31] <lynxman> jamespage: so I should just change $DEB_DESTDIR for debian/$package_name right?
[13:31] <jamespage> no
[13:33] <lynxman> jamespage: hmm what do you recommend then :)
[13:33]  * lynxman is clearly out of his depth in this baby
[13:33] <jamespage> lynxman, $***"£"$%"£!"£!"$%
[13:34] <jamespage> lynxman, write an rabbitmq-server.install file that picks up the right bits.
[13:34] <lynxman> jamespage: while at the same time keeping the rules file as it is
[13:34] <lynxman> jamespage: correct?
[13:35] <jamespage> almost
[13:37] <jamespage> lynxman, you will have to tweak install/rabbitmq-server::
[13:38] <jamespage> maybe
[13:38] <lynxman> jamespage: hmm would you reckon just converting it to dh_ would be better?
[13:39] <jamespage> lynxman, well maybe but I would not want to switch build system without collab from the debian maintainer
[13:39] <jamespage> even with dh you will still need to override dh_auto_install or whatever todo the same as the rules file is doing now
[13:39] <Daviey> utlemming: what is the status of locale issue on the cloudimg's?
[13:40] <zul> good morning
[13:40] <Daviey> afternoon zul
[13:41] <ivoks> hi guys
[13:41] <lynxman> zul: morningtons
[13:42] <jamespage> lynxman, you just need to make sure that the .install file also picks up the files details in rules OR install them directly to debian/rabbitmq-server in rules
[13:42] <jamespage> rather the DEB_DESTDIR
[13:42] <lynxman> jamespage: that's what I'm saying, substitute $DEB_DESTDIR for debian/rabbitmq-server
[13:42] <Daviey> ivoks: hola
[13:42] <lynxman> jamespage: that would be the less delta-ish change
[13:42] <jamespage> yes but only in the install/rabbitmq-server target
[13:43] <Daviey> ivoks: It seems the mail stack might want some love, would you be such a lover?
[13:44] <lynxman> jamespage: like this http://pastebin.ubuntu.com/873007/
[13:44] <lynxman> Daviey: smooth one
[13:44] <ivoks> Daviey: lol
[13:45] <Daniel__> i installed ubuntu server onto my computer and then installed gnome after my server software installed, but it says could not update ICEauthority file and then my home folder/.ICEauthority.
[13:45] <ivoks> Daviey: i can add it to my TODO list... it can't get any love before friday :)
[13:45] <Daniel__> me
[13:46] <Daviey> ivoks: \o/
[13:47] <Daviey> ivoks: You might be interested in bug 930916, it looks pretty painless :)
[13:49] <Daviey> smoser / utlemming: At some point, would either of you two be able to revist running cloud img's outside of the cloud?
[13:50] <Daviey> ie, does it still work
[13:50] <Myrtti> Daniel__: have you perchance enabled the root account?
[13:51] <lynxman> jamespage: yeah that did it :)
[13:53] <smoser> Daviey, it does work.
[13:53] <smoser> in precies images its much simpler.
[13:54] <ivoks> Daviey: one question thou...
[13:54] <Daviey> smoser: is there doc's?
[13:54] <ivoks> Daviey: sure i can take a look, but i'm not core-dev; i'm not even motu anymore :) what else can i do for that bug? it does have a patch attached
[13:55] <Daviey> ivoks: well you are rubbish :)
[13:55] <Daviey> ivoks: It would be great to see you push or ubuntu server package set :)
[13:55] <lynxman> Daviey: by extension all non MOTUs as myself are rubbish? ;)
[13:55] <Daviey> lynxman: no, just ivoks
[13:56] <ivoks> i guess i have to re-apply for motu and apply for core-dev eventually
[13:56] <ivoks> yeah, i sucks
[13:56] <Daviey> ivoks: if you let MOTU expire, it should be a pretty simple task to re-gain it.
[13:57] <lynxman> jamespage: package looks good now and all plugins work properly, where do you want it so it can be properly sponsored and tested
[13:57] <jamespage> lynxman, please can you push it as a branch to launchpad
[13:58] <lynxman> jamespage: will do
[14:04] <lynxman> jamespage: the bzr branch for rabbitmq-server is still on 2.6.1
[14:04] <lynxman> jamespage: you want me to do the upstream merge and push the debian changes into the new branch? or just push the debian dir as it is
[14:05] <Daviey> smoser: Have you tried to use nested kvm in canonistack?
[14:05] <smoser> $ modprobe kvm-intel
[14:05] <smoser> FATAL: Module kvm_intel not found.
[14:05] <smoser> GAH!
[14:06] <Daviey> smoser: i installed -generic
[14:06] <Daviey> and it is found, but fails to load
[14:06] <smoser> yeah
[14:06] <smoser> but...
[14:06] <smoser> maybe we shoudl put those into -virtual
[14:06] <Daviey> smoser: This is what i am thinking...
[14:06] <smoser> Daviey, doc on cloud-init
[14:06] <smoser>  http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/nocloud/README
[14:06] <Daviey> but i wanted to get it working first.. :)
[14:06] <Daviey> "kvm: no hardware support"
[14:06] <smoser> (on running images outside of cloud)
[14:06] <Daviey> Shame hallyn is away
[14:06] <Daviey> smoser: thanks
[14:07] <jamespage> lynxman, debdiff then
[14:07] <smoser> Daviey, its unlikely that hte host has the kvm module loaded with support for nested
[14:07] <Daviey> smoser: it's default in precise.
[14:07] <smoser> well, ask is.
[14:07] <smoser> IS
[14:07] <Daviey> on it :)
[14:08] <smoser> oh, and i know you dont care, Daviey (since your "`id -u` == 0" on your systems), but all of that link runs non-root
[14:09] <Daviey> smoser: lolz
[14:09] <lynxman> jamespage: roger that
[14:10] <smoser> Daviey, fyi http://paste.ubuntu.com/873047/
[14:10] <smoser> i'll open a bug for kvm in guests
[14:10] <smoser> but...
[14:10] <smoser> its not free (~1M in modules)
[14:10] <Daviey> smoser: dude, steal all my thunder, why not :)
[14:11] <Daviey> smoser: yeah, i tried intel and amd64 for luck.
[14:11] <smoser> $ apt-cache show linux-image-3.2.0-18-virtual  | grep ^Size
[14:11] <smoser> Size: 12084572
[14:11] <smoser> you can open a bug.
[14:11] <smoser> go for it.
[14:11] <Daviey> smoser: TBH, i think 1M makes sense.. Considering the default is to enable nesting, we should allow clouds to do it by default IMO.
[14:12] <smoser> Daviey, its probably a toy
[14:12] <smoser> toys are nice.
[14:12] <smoser> but they're toys
[14:12] <lynxman> smoser: toys are flashy too
[14:12] <smoser> its an add of 950896 to a package that is 12084572
[14:13] <smoser> and lynxman and Daviey both like flashy (as noted by their laptop vendor)
[14:13] <Daviey> smoser: being able to run a half decent development cloud within the cloud is pretty swish.
[14:13] <Daviey> smoser: Think it's better just to suggest people switch to -generic?
[14:13] <smoser> i think "half decent" might be a bit of an exageration.
[14:13] <smoser> but sure.
[14:13] <Daviey> it's only an apt-get away!
[14:14] <smoser> open a bug.
[14:15] <zul> Daviey: so question for you, I have been talking to ttx about swift
[14:15] <zul> Daviey:  swift 1.4.7 is going to be released real soon now.
[14:16] <zul> however 1.4.8 is going to have some new featues (i dont know what they are since i dont follow swift as closely as i probably should)
[14:16] <zul> do we want to do a FFE for 1.4.8 or just leave it at 1.4.7
[14:16] <ttx> Updated http://wiki.openstack.org/EssexReleaseSchedule with their new schedule
[14:16] <zul> my prefrence is to leave it at 1.4.7
[14:17] <smoser> zul, but features are shiney
[14:17] <smoser> and Daviey likes shiney
[14:17] <smoser> :)
[14:17] <zul> smoser: shiney like dubloons
[14:18] <smoser> i dont care if that decorated egg is hollow and extremely fragile, ITS SHINEY!
[14:18] <zul> Daviey: the point being that 1.4.7 you get a known quantity with 1.4.8 close to an ubuntu release you dont
[14:19] <smoser> you could ask yourself, wwttxd
[14:19] <lynxman> jamespage: bug #948993 with debdiff attached, you can take it at will :)
[14:19] <smoser> (ww ttx do)
[14:20] <zul> smoser: i ask myself that question everyday, additionally what would brian boitano do as well?
[14:20] <zul> crap now i have that song in my head
[14:20] <smoser> he'd make a plan and he'd follow through
[14:20] <smoser> thats what brian boytano would do
[14:20] <ttx> I ask myself what would Chuck Norris do.
[14:20] <zul> and have save the maidens fair
[14:21] <lynxman> ttx: just punch the bad guy in the face, and resist gravity like a boss
[14:21] <smoser> http://youtu.be/XuRJSsAYxDA
[14:21] <smoser> awesome.
[14:21] <ttx> lynxman: that's what I suggested to zul in PM
[14:22] <zul> lynxman: very pratical
[14:23] <Daviey> ttx: Development through PM's++
[14:24] <Daviey> zul: Really don't have enough information.  The fact that a swift release *is* a production release is encouraging
[14:24] <Daviey> Really, what matters - is what is tagged as essex aswell.
[14:25] <Daviey> The fact that if they didn't use 'releases', but used milestones, such as essex-4.. we'd adopt it without a second thought.
[14:26] <ttx> Daviey: I think you need to wait for the change to see if it's worth it
[14:26] <ttx> i.e. ship 1.4.7 until you can assess if 1.4.8 is worth the FFe hassle
[14:29] <Daviey> ttx: What release is being tagged as essex final?
[14:31]  * Daviey raises again that swift being an openstack project is as transparent as mud.. the Release schedule indicates that .8 could be an option?
[14:33] <Daviey> ttx: ?
[14:35] <ttx> Daviey: "the last they release". Hopefully 1.4.8
[14:35] <zul> Daviey: im just afraid its not going to get enough testing done by us
[14:35] <ttx> Daviey: see  #openstack-meeting about making them change
[14:35] <ttx> arh
[14:35] <ttx> see #openstack-packaging
[14:46] <jamespage> lynxman, does this fix the issue therve was talking about yesterday?
[14:47] <lynxman> jamespage: as well, it's the patch I ported to quilt :)
[14:47] <jamespage> lynxman, inets-plugin?
[14:49] <lynxman> jamespage: yesh
[14:54] <rbasak> jamespage: bug 932628 is fixed in ubuntu, right?
[14:55] <jamespage> yes
[14:55] <rbasak> never mind, of course it is
[14:55] <rbasak> ok
[14:58] <jamespage> lynxman, not sure I get the need for -erlang-client
[14:58] <jamespage> the old package did not enable it and restart
[15:00] <lynxman> jamespage: erlang-client is required by the stomp plugin, it's the ampq_client plugin, it's automatically enabled by dependencies if you enable stomp but I included it in order to maintain 100% compatibility with the previous packages
[15:00] <jamespage> lynxman, hm
[15:00] <jjohansen> stgraber: the new apparmor should hit the archive today some time (ie its just waiting on the submission processes atm)
[15:00] <lynxman> jamespage: if you don't fancy it removing the package and dependency will have the same effect
[15:01] <jamespage> I think that the rabbitmq-server package needs to replace it and earlier versions of the rabbitmq-stomp package otherwise its going to break on upgrade
[15:01] <jamespage> lynxman, let me have a hack at it...
[15:02] <lynxman> jamespage: that's why I added the package here as well
[15:02] <lynxman> jamespage: either that or obsolete the erlang-client package
[15:02] <smb> More smb nitpick reloaded: bug 949028
[15:02] <stgraber> jjohansen: good to hear. I turned off apparmor for lxc yesterday, once I see the new apparmor landing I'll try it, update the profile and re-enable it in LXC
[15:15] <jamespage> lynxman, did earlier versions of rabbitmq-stomp actual enable the plugin?
[15:15] <lynxman> jamespage: earlier versions had the plugin binary and the config necessary for rabbitmq to enable the plugin
[15:16] <lynxman> jamespage: there was not an enablement mechanism per se, that's new to 2.7.1
[15:16] <jamespage> ah - I see
[15:16] <lynxman> jamespage: so the packages have become empty of binary content but just config and enablement mechanisms
[15:16] <jamespage> lynxman, did plugins enable automagically < 2.7.1
[15:17] <lynxman> jamespage: not always, just adding the binary didn't, you also needed to provide config (in some cases), in some others just providing the binary did it
[15:17] <lynxman> jamespage: for ampq_client (erlang-client) just providing the binary works, but now you actually need to activate it
[15:17] <jamespage> lynxman, so rabbitmq-erlang-client is needed in actual fact - just todo that enablement
[15:18] <lynxman> jamespage: correct
[15:18] <lynxman> jamespage: same for rabbitmq-stomp
[15:19] <lynxman> jamespage: but it's a very explicit way of saying "I really want that plugin going"
[15:19] <lynxman> jamespage: in rabbitmq-stomp case there's also extra config
[15:19] <jamespage> lynxman, OK - I understand now
[15:19] <jamespage> we need to add some Breaks to rabbitmq-server - I can do that
[15:20] <jamespage> its going to replace files owned by other packages so they have to be un-installed first
[15:20] <zul> smoser: /usr/bin/glance has been split out into its own package btw
[15:20] <lynxman> jamespage: I added them and then removed them when adding the other packages, but you're right (must have thought about that)
[15:21] <lynxman> jamespage: Breaks: rabbitmq-stomp (<< 2.7.1-0), rabbitmq-erlang-client (<< 2.7.1-0)
[15:21] <jamespage> and plugins
[15:22] <jamespage> 2.7.1 is enough
[15:22] <lynxman> jamespage: cool :)
[15:24] <SpamapS> jamespage: Breaks+Replaces will be in order actually
[15:24] <smoser> zul, woot. youcan slose that bug if you think it should be.
[15:24] <zul> smoser: will do so on friday when i upload it
[15:24] <jamespage> SpamapS, Replaces as well? we will still have -stomp and erlang-client packages
[15:26] <smoser> ah. k.
[15:26] <SpamapS> jamespage: Breaks will only prevent concurrent configuration
[15:26] <smoser> thank you zul.
[15:26] <zul> smoser: no worries
[15:26] <jamespage> SpamapS, to replaces will ensure it drops the package before unpacking?
[15:26] <SpamapS> jamespage: so if your new package overwrites files from a previous version of some other package, it needs to Replaces: it so that it can do that before the upgrade of the other package.
[15:26] <jamespage> snpa
[15:26] <SpamapS> jamespage: no, Replaces allows you to selectively replace files.
[15:27] <jamespage> SpamapS, ah - I see
[15:27] <SpamapS> jamespage: then later the new version will be extracted and configured.
[15:27] <SpamapS> s/will/can/
[15:27] <SpamapS> jamespage: if you don't do Replaces.. you may still get conflicting file problems
[15:28] <lynxman> SpamapS: jamespage: would it be convenient then to do Replaces: per subpackage?
[15:32] <jamespage> lynxman, do you think that plugins-common should be part of rabbitmq-server now?
[15:32] <jamespage> it just enables a .d configuration directory
[15:34] <lynxman> jamespage: it does make sense to centralise the packaging if we pull in the plugins doesn't it
[15:34] <lynxman> jamespage: otherwise you can just strip it out, the existing package is OK as it is
[15:34] <lynxman> jamespage: until the rabbitmq guys change something again :)
[15:36] <SpamapS> lynxman: no, if its the same binary name, it doesn't need to do a replaces.
[15:36] <SpamapS> thats assumed
[15:37] <SpamapS> its only if rabbitmq-server replaes a file that was in rabbitmq-stomp ...
[15:37] <SpamapS> replaces rather
[15:37] <lynxman> SpamapS: it does since the plugin is now in the server package
[15:38] <SpamapS> lynxman: same path? I thought they had different paths
[15:38] <lynxman> SpamapS: same path just different filename
[15:38] <lynxman> SpamapS: if I recall properly (which at this point I might not)
[15:40] <lynxman> SpamapS: you're right, different path /usr/lib/rabbitmq/lib/rabbitmq_server-2.7.1/plugins/rabbitmq_stomp-0.0.0.ez
[15:40] <lynxman> SpamapS: jamespage: so no need for Replaces:
[15:41] <SpamapS> Is there even a reason for a Breaks ?
[15:41] <jamespage> SpamapS, lynxman: sounds like there might not be
[15:41] <jamespage> aside from for plugins-common
[15:42] <lynxman> SpamapS: jamespage: only if the previous package dependencies were not declared properly, then in that case we can be in a case where stomp plugin for 2.6.1 is side by side to server from 2.7.1, and even with that I can see a partial use for Breaks, not a full justification
[16:04] <SpamapS> lynxman: I thought we were going to add a rabbitmq-stomp to the rabbitmq-server package
[16:05] <lynxman> SpamapS: that's what we did
[16:05] <lynxman> SpamapS: have a look at the debdiff
[16:05] <lynxman> SpamapS: attached to bug #948993
[16:08] <jamespage> lynxman, I posted a revised debdiff to bug 948993
[16:08] <jamespage> it drops the plugins-common package altogether
[16:08] <lynxman> jamespage: fair enough
[16:09] <jamespage> I did a quick test and it upgrades OK from what it already in the archive
[16:09] <jamespage> SpamapS, any chance you could have a quick peek as well ^^
[16:09] <lynxman> jamespage: I was quite doubtful about adding it or not, I erred on the side of concentrating everything on the same source package
[16:10] <jamespage> lynxman, OK - so that was the easy bit done
[16:10] <jamespage> lynxman, I think this will need a FFe for two reasons
[16:10] <jamespage> 1) its two NEW packages from rabbitmq-server
[16:11] <jamespage> (but they do replace existing ones so that should be OK)
[16:11] <jamespage> 2) the new packages will need to sit in main; the old ones are in universe - so its all a little confused.
[16:11] <jamespage> feels like an MIR albeit a minor one
[16:12] <lynxman> jamespage: hmm alright, I'll be excited to assist into this :)
[16:12] <jamespage> Daviey: as our friendly release team member are you able to confirm the above?
[16:13] <Daviey> lynxman: do you have a debdiff i can look at?
[16:13] <lynxman> Daviey: attached to bug #948993
[16:13] <Daviey> SpamapS has been tracking rabbitmq.. do you have thoughts SpamapS ?
[16:13] <lynxman> Daviey: reviewed and finely tuned by jamespage
[16:14] <Daviey> well it's certainly rock solid then!
[16:14] <jamespage> Daviey: don't count on it
[16:14]  * jamespage still gets confused by Breaks/Replaces...
[16:14] <lynxman> Daviey: I can't look for a higher blessing than jamespage's one
[16:14] <Daviey> jamespage: everyone does :)
[16:15] <SpamapS> I'll take a look shortly
[16:25] <SpamapS> lynxman: which debdiff am I looking at.. yours or james page's?
[16:26] <jamespage> SpamapS, second one (mine)
[16:26] <lynxman> SpamapS: second (jamespage)
[16:26] <jamespage> I add some tweaks and tidy
[16:27] <lynxman> jamespage: you gave it the pixie dust of quality :)
[16:27] <jamespage> :-)
[16:29] <SpamapS> ah ok, so rabbitmq-plugins-common is entirely removed?
[16:30] <lynxman> SpamapS: yes because it's already a package existing in universe, the inclusion on rabbitmq-server was just done to centarlise the rabbitmq package management on the rabbitmq-server source (which makes sense) but doesn't modify in any way the current package
[16:30] <SpamapS> and the only thing that depended on it, rabbitmq-stomp, doesn't anymore, so yeah, the Breaks/Replaces should cause its removal, if not, autoremove will
[16:31] <SpamapS> +Suggests: ruby
[16:31] <SpamapS> lynxman: ??
[16:32] <SpamapS> usually only hipsters Suggest ruby..
[16:32] <lynxman> SpamapS: that's legacy from iamfuzz, discard :)
[16:32]  * lynxman removes his hipster glasses
[16:32] <jamespage> lol
[16:32] <lynxman> SpamapS: in this case the pacakge as existing is fine, it shouldn't be removed otherwise the plugins config will break badly
[16:34] <lynxman> SpamapS: so the intention (just to be clear) is that rabbitmq-plugins-common is still used by rabbitmq-stomp
[16:34] <lynxman> SpamapS: I was doubtful about which way to go (include it in the source or not) so I did, and jamespage (in his good sense) thought that it wasn't really necessary
[16:35] <lynxman> SpamapS, jamespage: although now we'll finish with a package in main that provides a plugin package in main that depends from a package in universe
[16:35]  * lynxman thinks its early enough to drink now
[16:35] <jamespage> lynxman, SpamapS: for the sake on one config file that could quite happily site in rabbitmq-server it felt like overkill
[16:36] <jamespage> lynxman, ?
[16:37] <jamespage> no I dropped the need for plugins-common completely
[16:37] <lynxman> jamespage: ah, it shouldn't :)
[16:37] <jamespage> it can be rm'ed
[16:37] <SpamapS> lynxman: rabbitmq-erlang-client.postrm has a *very minor* error in it
[16:37] <lynxman> jamespage: the structure that plugins-common provide is required and necessary for any and all plugins
[16:37] <lynxman> jamespage: so we need to depend on it
[16:37] <lynxman> SpamapS: oh :)
[16:37] <lynxman> SpamapS: do tell!
[16:37] <SpamapS> lynxman: http://www.debian.org/doc/debian-policy/ch-relationships.html .. note that Depends are not guaranteed to be around during postrm, so you need to handle the case where rabbitmq-server has been removed
[16:38] <lynxman> SpamapS: oops... that'll be a tricky one
[16:39] <SpamapS> lynxman: basically, if $? == 100 after invoke-rc.d rabbitmq-server restart , that should be accepted
[16:39] <lynxman> SpamapS: that's why I added the exit 0 at the end of postrm though
[16:39] <SpamapS> lynxman: your set -e will fail before thats reached
[16:40] <lynxman> SpamapS: hmm true
[16:40] <SpamapS> lynxman: actually you also need to do a -x check on rabbitmq-plugins before executing it
[16:40] <SpamapS> lynxman: in fact, I think its sufficient to just wrap the two actions in that
[16:41] <SpamapS> if rabbitmq-plugins is gone, its not likely that rabbitmq-server is restartable, or that it matters if you're trying to restart it. :)
[16:41] <jamespage> that will need to be applied to rabbitmq-stomp as well
[16:41] <lynxman> jamespage: yeah both postrm scripts are almost identical
[16:41] <jamespage> +1
[16:41] <SpamapS> heh.. haven't gotten to that yet. :)
[16:42] <lynxman> rabbitmq-plugins-common needs to be there, or integrate what it does into -server otherwise
[16:42] <jamespage> lynxman, already done the second debdiff
[16:42] <lynxman> jamespage: cool
[16:42] <jamespage> (last line of rules file)
[16:42]  * SpamapS wishes the bzr branch were up to date. :-P
[16:43] <SpamapS> lynxman: has rabbit always purged all of its data on purge w/o asking the user's permission?
[16:43] <SpamapS> I think thats a bug that we should look at fixing.
[16:43] <lynxman> SpamapS: yes as far as I'm concerned, that's untouched
[16:44] <lynxman> SpamapS: agree
[16:45] <SpamapS> mysql gets this part right.. need a debconf question
[16:46] <SpamapS> lynxman: I know these aren't your bugs.. but this is also wrong: +                deluser rabbitmq
[16:46] <SpamapS> users should simply be left on the system forever
[16:48] <lynxman> SpamapS: I'm writing all this down so we can fix all this, I'd rather just publish a quality package if I have my name in it :)
[16:48] <SpamapS> lynxman: indeed, me too. :)
[16:49] <SpamapS> lynxman: if nothing else, lets get these reported as bugs
[16:49] <SpamapS> lynxman: we should also see if Debian is interested in syncing ubuntu -> debian for rabbit.. looks like the Debian maintainers are kind of MIA
[16:49] <lynxman> SpamapS: I know the debian maintainer, will ping him with the new package
[16:49] <lynxman> SpamapS: he's a busy guy :)
[16:50] <lynxman> SpamapS: would it be okay then if I open a couple bugs then modify the debdiff to fix all this?
[16:50] <SpamapS> lynxman: indeed.. I just now noticed 2.6 is there now.. it had a bit of a lag last cycle which is whyw e ended up with a -0ubuntu version
[16:50] <lynxman> SpamapS: could have this done by the end of the night
[16:50] <Ayrton> Hello everyone. I seted up a openvpn server, and trying to access it through a socks proxy with the command "openvpn --socks-proxy localhost 1080 --config client.ovpn" and I get this error: http://paste.ubuntu.com/873096/
[16:50] <SpamapS> lynxman: sure, I'll stop my review until your post a new change
[16:50] <lynxman> SpamapS: cool, thank you!
[16:50] <SpamapS> lynxman: let me know if you need anything else.
[16:51] <lynxman> SpamapS: will do, hope I can have a new debdiff in under 20 mins
[16:51] <lynxman> SpamapS: as soon as its considered solid I'll ping the debian maintainer too
[16:53] <grendal-prime> mount.cifs works fine from cli...even in a script..but cron execution fails?
[16:53] <grendal-prime> anyone else run into this?
[16:55] <grendal-prime> because im totally blown away by this straight up crazness
[17:23] <jetole> Does anyone know about how to setup traffic shaping and policing using tc from iproute2? I want to create a tbf or an htb with all vlans except on in it but it looks like I need to specific a device for each tc rule and this is confusing the heck out of me
[17:27] <zul> adam_g: i added glance-client and some horizon fixes this morning
[17:28] <adam_g> zul: sweet
[17:30] <rbasak> jetole: do you know about http://lartc.org/howto/? Lots of useful help there.
[17:35] <adam_g> zul: where are those changes at?
[17:35] <zul> lp:~openstack-ubuntu-testing/{swift,glance,horizon}/precise-essex-proposed
[17:42] <jetole> rbasak: yes I have read parts here and there over the years including some recently but will look again
[17:42] <rockets> I need to backup files over a network - I can access said files via smb, sftp, scp, ftp, or NFS. I *cannot* use rsync, due to a bug in my NAS where when you rsync tons of files, some of them are randomly deleted ON THE NAS (yes I know, I know, horrible). Any suggestions for an alternative to rsync?
[17:42] <rockets> I'm backing up to an ubuntu server.
[17:42] <jetole> rbasak: I found a section about the intermediate quueing device a moment ago while AFK and looking on my phone but looks like I will have to compile that in
[17:43] <jetole> according to lartc.org, one of the problems with queuing that IMQ solves is "A qdisc can only see traffic of one interface, global limitations can't be placed" http://lartc.org/lartc.html#LARTC.IMQ
[17:46] <SpamapS> rockets: if your NAS has a bug that causes rsync to delete files, any other thing that does individual files will also be problematic
[17:47] <SpamapS> rockets: I'd suggest doing snapshots with tar in that case.
[17:47] <rockets> SpamapS, can tar do incremental backups?
[17:48] <rockets> our current solution, rsnapshot, uses hardlinsk to create many incrementals without using additional space, unless a file has changed
[17:48] <rockets> it works via rsync
[17:48] <lynxman> SpamapS: I've added the new debdiff to bug #948993 whenever you can review it I'll be grateful
[17:48] <lynxman> SpamapS: need to leave now for the evening, will be online again in ~5 hours
[17:54] <SpamapS> lynxman: cheers, thanks!!
[17:54] <roaksoax> zul: have tyou ever handle postgresql user/pass/db creation in a postinst?
[17:55] <zul> roaksoax: not personally but you might want to look at dbconfig-common
[17:55] <roaksoax> zul: cool, thansk
[18:23] <rbasak> jetole: I don't really know anything about advanced routing that isn't on lartc.org :-)
[18:24] <adam_g> zul: note https://github.com/openstack/nova/commit/314dd69ab00cb35b0683a384023e0cae9844428b  <- not sure if we want to choose one auth strategy to specify in nova.conf as a default
[18:25] <zul> adam_g: nah
[18:33] <pabelanger> ubuntu-motu suggested I ask my openstack (nova) packaging questions here.  I've uploaded a debdiff for bug 907152 to resolve a race condition between nova-compute-kvm and libvirt.  I've subscribed to ubuntu-sponsors but also wanted to make sure I notified the package maintainers too
[18:35] <zul> pabelanger: we are a bit backed up but we can get to it today
[18:36] <pabelanger> zul: ya, no rush.  Just wanted to notify the proper people.  Thanks
[18:43] <adam_g> pabelanger: is this something that should be proposed to openstack upstream?
[18:44] <adam_g> pabelanger: oh, i see. nevermind
[18:44] <pabelanger> adam_g: Possible. Right now I am not sure of the workflow of who maintains the packages
[18:44] <pabelanger> I was under the impression the packages are managed in Ubuntu, rather then upstream
[18:44] <adam_g> pabelanger: yeah, my bad. didn't realize it was an issue with the upstart job
[18:46] <SpamapS> pabelanger: that start on condition may cause issues later on
[18:47] <SpamapS> pabelanger: any time you use *and*, you may find unintended consequences.
[18:47] <pabelanger> SpamapS: OIC
[18:47] <SpamapS> actually really the start on condition that it has now is a bit silly
[18:47] <pabelanger> recommendations?
[18:47] <SpamapS> Because a box may have tons of IFACE!=lo
[18:48] <SpamapS> pabelanger: perhaps just 'start on started libvirt-bin' .. if libvirt-bin is a) Depended on by the package, and b) using a sane start on
[18:48] <pabelanger> Ya, somebody suggested they be removed and only start on libvirt-bin
[18:48] <pabelanger> doh
[18:48] <pabelanger> too slow
[18:49] <pabelanger> Let me check the package
[18:49] <pabelanger> and re-upload
[18:49] <SpamapS> The stop on then needs adjusting
[18:49] <SpamapS> to 'stop on stopping libvirt-bin'
[18:49] <pabelanger> ack'd
[18:50] <SpamapS> Otherwise nova-compute will be stopped when the system goes into runlevel 1, but not started back up when it returns to runlevel 2
[18:50] <SpamapS> (which is actually already an open bug)
[18:50] <SpamapS> Oo we should have a push to fix all the runlevel1 bugs
[18:52] <SpamapS> pabelanger: I lied.. its not an open bug, but it should be one
[18:52] <SpamapS> and I lied again, it is, bug 820694
[18:52] <pabelanger> A quick look at the control file shows nova-compute-xcp does not depend on libvirt-bin
[18:52] <SpamapS> silly launchpad search doesn't find tags when you search for them
[18:54] <pabelanger> however, I have never used nova-compute-xcp, so I don't really know what that package does
[19:05] <SpamapS> pabelanger: does nova-compute-xcp contain that upstart job?
[19:07] <pabelanger> SpamapS: no :(
[19:07] <SpamapS> pabelanger: ahh, looks like you have a problem there.. ;)
[19:08] <pabelanger> Yup, suggestions on how to account for nova-compute-xcp?
[19:08] <SpamapS> pabelanger: couple ideas..
[19:08] <SpamapS> pabelanger: either you can have a 'start on runlevel [2345]' job, /etc/init/nova-compute-xcp.conf , which starts nova-compute...
[19:09] <SpamapS> pabelanger: or you can find an "or" that is suitable and will always be after libvirt-bin
[19:10] <SpamapS> pabelanger: I suspect that XCP has a daemon that needs to be started for it to work as wel
[19:10] <pabelanger> okay, let me check for option 2
[19:10] <pabelanger> seems like the cleaner one to do
[19:11] <SpamapS> pabelanger: I don't see anything in xcp though.. so I think you're going to have to go with option 1.. we *have* identified a need for a "late in boot" event in upstart, but it does not exist yet.
[19:11] <SpamapS> as its going to require some re-structuring
[19:11] <pabelanger> ack'd, let me do that then
[19:12] <SpamapS> xcp-xapi: /etc/init.d/xcp-xapi
[19:13] <SpamapS> pabelanger: thats probably the service you want to start after, and since it is a sysvinit script, you probably want 'start on stopped rc RUNLEVEL=[2345]'
[19:14] <SpamapS> pabelanger: in truth, doing that as the 'or' with libvirt-bin would *probably* work fine.. but it will race with libvirt-bin
[19:15] <SpamapS> pabelanger: ok, now that I've loaded up your head with upstart madness.. time to eat lunch
[19:15] <pabelanger> ya, let me see if I can get my brain around that
[19:21] <smoser> roaksoax, ping
[19:21] <smoser> you have any reason not to take bug 943000
[19:21] <smoser> for oneiric updates
[19:22] <smoser> hggdh, can you put a SRU blob in the description on that one ?
[19:23] <roaksoax> smoser: i'll take a look at it later today
[19:23] <hggdh> smoser: roj
[19:23] <smoser> roaksoax, i can do it.
[19:23] <smoser> i'm patch piloting
[19:23] <roaksoax> hggdh: how were you trying to update it and what ISO were you using?
[19:23] <smoser> roaksoax, but if you want to say "go away smoser, then i'im good with that"
[19:24] <smoser> i did wonder about the recreate, but it is clearly a bug
[19:24] <smoser> but, yeah...
[19:24] <roaksoax> smoser: if you want it, go for it, though, since I haven't experienced that issue myself, I'm wondering why. Cause last time I had an issue with os_version *wasn't* because of a bug per se, but rather an issue of not having the os_version in the list of os_versions
[19:24] <smoser> its not fixed in precise as i see.
[19:25] <smoser> yea.
[19:25] <smoser> so we should  make sure it is fixed in precise
[19:25] <smoser> which at the moment it is not
[19:25] <smoser> but why you can have something there without a distro is i guess the real question
[19:25] <hggdh> roaksoax: I had just edited a system def, and clicked on save
[19:26] <hggdh> this is not so much "without a distro", as a different code path taken
[19:26] <hggdh> if you look at the backtrace, you will notice that the call had "distro=None" as one of the parameters
[19:26] <roaksoax> hggdh: ahh this issue is in esxi
[19:26] <benji> hey guys, I'm trying to start two ephemeral lxc instances of the same base machine but they both have the same MAC and therefore both claim the existing DHCP lease.  Am I missing something?
[19:27] <roaksoax> smoser: yeah just fix it in precise, and go ahead with the SRU
[19:27] <smoser> actually... we do have his change
[19:27] <smoser> in precise
[19:27] <smoser> that code is garbage
[19:27] <gary_poster> put another way (I think), how do you tell libvirt to go get a new MAC address for a particular container
[19:27] <smoser> and there are multiple blocks that lok the same
[19:27] <smoser> we do have that one
[19:29] <smoser> ah.
[19:30] <smoser> we have the first hunk of hggdh change, but not the second in trunk
[19:30] <smoser> s/trunk/precise/
[19:30] <smoser> upstream seems busted too if you hit the profile without a distro path.
[19:30] <hggdh> this is probably because the affected code changed a lot
[19:31] <smoser> no. its broken upstream.
[19:31] <smoser> clearly.
[19:31] <smoser> unless you can no longer get to that code without distro being set.
[19:31] <hggdh> so I had to rebase & extend the commit to apply
[19:32] <smoser> (in which case there are pointless checks for that)
[19:32] <smoser> so what did you do hggdh to see this ?
[19:33] <hggdh> I just updated an existing system def
[19:35] <smoser> what update did you make ?
[19:35] <hggdh> I changed a profile -- which had not been changed for quite a while
[19:36] <hggdh> I then went on to look at the profile itself -- had a distro set
[19:36] <hggdh> and the distros did not get changed in a very long time (mostly the one I was using, Lucid-i386)
[19:41] <roaksoax> zul: how is the database creation and stuff handled in horizon?
[19:41] <zul> roaksoax: you might want to look at keystone
[19:43] <hggdh> smoser: of course, there is the question of why the different code path *now*. But the upstream commit pretty much just checked if distro was set before using it, so I did the same on my code path
[19:44] <roaksoax> zul: cool, using dbconfig-common
[19:50] <smoser> hggdh, yeah, its clear to me that upstream trunk is broken if somehow you get into write_pxe_file at https://github.com/cobbler/cobbler/blob/HEAD/cobbler/pxegen.py with a 'distro' set to None
[19:50] <smoser> i'm not sure how you got there, but if you do, it will clearly die at append_line = "BOOTIF=%s"
[19:51] <smoser> i just dont know how you're hitting that code.
[19:51] <smoser> hggdh, i can't reproduce anything here.
[19:53] <smoser> in fact, the upstream commit you point to seems like it would still fail for whatever case it was failing.
[19:55] <pabelanger> SpamapS: so you think 'start on stopped rc RUNLEVEL=[2345] or libvirt-bin' is the solution? I'm still unclear why 'start on stopped rc RUNLEVEL=[2345] and libvirt-bin' would cause issues.
[20:02] <SpamapS> pabelanger: because rc could, in theory, finish before libvirt-bin is started
[20:02] <SpamapS> pabelanger: but in reality, that is very unlikely
[20:05] <pabelanger> okay, so 'start on stopped rc RUNLEVEL=[2345] or libvirt-bin' it is
[20:06] <pabelanger> and, 'stop on runlevel [!2345] or libvirt-bin' too?
[20:06] <pabelanger> err
[20:06] <pabelanger> and, 'stop on rc RUNLEVEL=[!2345] or libvirt-bin'
[20:06] <RoyK> 'stop on nervous breakdown or panic'
[20:06] <pabelanger> still new to upstart
[20:13] <hggdh> smoser: this is where we get the error:
[20:14] <hggdh> dammit
[20:23] <smoser> boy, hggdh you were upset
[20:23] <smoser> :)
[20:23] <hggdh> heh
[20:23] <hggdh> my IRC client decided to misbehave
[20:24] <smoser> so.
[20:24] <hggdh> smoser: this is the code path taken:
[20:24] <smoser> it looks to me like if you have an 'Image' loaded, then you'
[20:24] <smoser> then you're dead
[20:24] <hggdh>         # image names towards the bottom
[20:24] <hggdh>         for image in image_list:
[20:24] <smoser> yeah
[20:24] <hggdh>             if os.path.exists(image.file):
[20:24] <hggdh>                 contents = self.write_pxe_file(filename=None, system=None,
[20:24] <hggdh>                         profile=None, distro=None, arch=image.arch, image=image)Y
[20:24] <smoser> you're done there if image_list is not empty
[20:24] <hggdh> yes
[20:24] <smoser> and that is the case now in upstream trunk too
[20:25] <hggdh> hum
[20:25] <smoser> roaksoax, ^
[20:25] <smoser> you see that.
[20:25] <smoser> basically if you get an image, you're hosed
[20:26] <hggdh> there are a lot of places where the code can misbehave on the call above, not only distro
[20:26] <hggdh> I based my patch on the commit I saw, and adjusted for another test on distro
[20:27] <hggdh> but did not change anything else, since I have no idea of the consequences
[20:27] <hggdh> but, at least now, I can use cobbler on oneiric
[20:27] <smoser> yeah. hggdh k.
[20:27] <smoser> thanks for being patient with me
[20:27] <smoser> except for when you said 'dammit' and left
[20:27] <smoser> :)
[20:28] <hggdh> thank YOU for being patient with me
[20:28] <hggdh> and for the record, the dammit was not for you, but for weechat
[20:28] <smoser> hggdh, https://github.com/cobbler/cobbler/issues/16
[20:28] <smoser> sure it was, hggdh.
[20:29] <hggdh> yeah, this is it
[20:29] <hggdh> smoser: never! I would never say 'dammit
[20:29] <hggdh> ' to you, dammit!
[20:33] <cemc> hi. how can i check if I have packages installed from outside main/universe/multivers? like PPAs, third party repos etc?
[20:34] <cemc> without looking in /etc/apt/sources* obviously
[20:39] <hggdh> smoser: so. Do I add the SRU data?
[20:42] <smoser> sure.
[20:42] <smoser> please do.
[20:42] <smoser> can't helpk.
[20:42] <smoser> can't hurt
[20:42] <smoser> and i will get the precise fixed.
[20:43] <hggdh> perfect, thank you
[20:44] <grendal-prime> nevermind i figured out the answer...you all can stop looking
[20:54] <gary_poster> smoser, hi.  do you have any knowledge of libvirt and MAC addresses, or can you point to someone who might, or should we wait for hallyn?
[20:55] <smoser> i didn't understand your question above, gary_poster but all i saw was your "put another way" statement.
[20:57] <koolhead17|afk> soren, around
[20:58] <SpamapS> pabelanger: hrm. stop on complicates things.
[20:58] <pabelanger> indeed
[20:58] <gary_poster> smoser, we use lxc-start-ephemeral, which puts an overlayfs over an existing lxc container, gives it another name, and starts it.  The problem is that the MAC address for the ephemeral is the same as the base--and this is the case for all of the ephemeral instances with the same base.
[20:58] <SpamapS> pabelanger: no, actually I think its ok.. let me think about it
[20:59] <gary_poster> smoser, so, we are looking at various hacks around this that we can do in our instance, but it would be very nice if we could tell libvirt "hey!  please make a new virtual MAC for this ephemeral instance, and don't use that one that we're based on!"
[20:59] <jetole> Hey guys, if anyone knows tc and qdiscs and all that, I am still trying to find the best way to attach multiple devices under the same queuing discipline for example we have about a dozen vlans going through the firewall connected to a 10mbps/10mbps symmetrical metro ethernet connection and I want to place a limit of 9mbps on all vlans except one but on the some total of all vlans so, for example, vlan1 can use 9, vlan2 can use 9 but vlan1 and ...
[21:00] <gary_poster> smoser, and we don't see how to do that yet.  Does that make sense yet?  If so, any ideas?
[21:00] <jetole> ... vlan2 at the same time, both of their traffic can never use more then 9
[21:00] <jetole> does anyone know how I can do that?
[21:01] <smoser> i didn't realize lxc-start-ephemeral had anything to do with libvirt
[21:02] <SpamapS> pabelanger: I think you can just do 'stop on runlevel [016]' .. This means you might stop libvirt-bin while nova is still running, but thats something libvirt should handle gracefully.
[21:02] <SpamapS> it shouldn't
[21:02] <SpamapS> why would lxc-start-ephemeral make use of libvirt?
[21:02] <jetole> while reading the docs I see different ways to attach qdiscs to a specific device i.e. I can rate limit vlan1 but it has no effect on vlan2 or I can rate limit each one separately but the sum of both having a 9mbps limit would be a total of 18mbps. I can't see how to do a collective rate limit on all
[21:02] <SpamapS> other than to potentially make use of libvirt-bin's default virbr0 ?
[21:03] <pabelanger> zul: re: glance package, I wondering if chmod 0700 /etc/glance/ is too restrictive of the directory.  While all the files inside have 644 permissions.  Any thoughts on loosing it a bit?
[21:03] <zul> pabelanger: there is a fix pending
[21:03] <pabelanger> great
[21:03] <gary_poster> smoser, it doesn't directly, and maybe we are barking up the wrong tree.  the script is pretty simple right now and doesn't touch libvirt.  We thought it might need to.  Let's get back to the core problem then.  As I said, ephemeral instances have the same MAC addresses as their base.  That means they get the same ip addresses from the local dhcp server.
[21:04] <gary_poster> this means that if you run them simultaneously, you hav an insane state
[21:04] <gary_poster> in which one IP points to multiple instances
[21:04] <lifeless> hah! I was wasking wgrant this yesterday
[21:04] <lifeless> the ephemeral script needs to mangle the hwaddr in the config
[21:04] <lifeless> s/wasking/asking/
[21:04] <pabelanger> zul: do you happen to have a bug number?
[21:05] <zul> pabelanger: no but it is pending
[21:05] <pabelanger> ack'd
[21:05] <smoser> gary_poster, right.
[21:05] <gary_poster> lifeless, ah! I think I understand.
[21:05] <smoser> that *does* make sense.
[21:05] <smoser> i just was confused by libvirt
[21:05] <smoser> as it has nothing to do with it as i undertsand it.
[21:05] <gary_poster> sorry, it seems not
[21:07] <smoser> gary_poster, look in lxc-clone
[21:07] <smoser> # change hwaddrs
[21:07] <smoser> you probably need to do that.
[21:07] <gary_poster> smoser, sounds perfect
[21:07] <smoser> ther eight be other stuff you need to do also.
[21:08] <gary_poster> ack
[21:08] <koolhead17|afk> Is there any reason why oVirt is not available on Ubuntu? :(
[21:09] <lifeless> koolhead17: noone has packaged it ?
[21:10] <koolhead17> lifeless,  does it mean it will only be available for RPM based distros :(
[21:10] <lifeless> no
[21:10] <SpamapS> gary_poster: I know that ephemeral is attractive because of the cleanup/overlayfs .. but is it worth trying to just use lxc-clone ?
[21:10] <lifeless> it means it will be available where people package it
[21:11] <lifeless> SpamapS: s/attractive/omgessential/
[21:12] <koolhead17> lifeless,  it means its not even in Debian as o now!! :P
[21:12] <lifeless> SpamapS: the LP tree is a pretty heavy footprint, the shared disk cache *and* the tempfs combine to give us ~0 IO during a test run
[21:12] <gary_poster> SpamapS, heh, we were just discussing that. :-)  the overlayfs gives us speed that we believe we need because the whole point of this is to be running in parallel.  Past experiments in other similar approaches ran against...what lifeless said
[21:13] <mdeslaur> SpamapS: didn't get any feedback on mysql in -proposed by any chance, have you?
[21:13] <SpamapS> mdeslaur: no feedback, the one server I tested them on has been working fine
[21:14] <SpamapS> mdeslaur: the updates I did for Debian progressed faster than I thought they would.. so they just released 5.1.61 for stable... which I'm sure you noticed ;)
[21:14] <mdeslaur> SpamapS: ok, thanks...FYI, I'm going to push them out on monday, and then the regression fix on tuesday, and then the regression fix for the regression fix on wednesday :)
[21:14] <mdeslaur> SpamapS: yeah, I saw that
[21:14] <SpamapS> mdeslaur: I'll be watching the New list closely
[21:14] <mdeslaur> SpamapS: cool, thanks
[21:15] <SpamapS> mdeslaur: I suspect many will have to be Won't Fix though. :-P
[21:15] <mdeslaur> hehe
[21:20] <gary_poster> whee, hangs & restarts are fun
[21:35] <jMCg> Hey folks -- how do I allow multicast in ufw?
[21:52] <smoser> gary_poster, another option (which i'm almost certain you aren't going to like)
[21:52] <smoser> is to just use lxc-clone, but have btrfs in /var/lib/lxc
[21:53] <smoser> then it "just works" and does btrfs snapshots.
[21:53] <smoser> :)
[21:53] <smoser> but then you have to cleanup also
[21:54] <koolhead17> Ursinha, around. the guy erased it all. :D
[21:54] <Ursinha> koolhead17, lol
[21:54] <koolhead17> hahahaha. :P
[21:56] <gary_poster> smoser, :-) cool idea.  The in-memory part of our overlayfs approach is believed to be very important though
[22:14] <adac> hi guys: I got the following problem: http://pastebin.com/sr4W847a but -f unfortunately does not solve the problem.  I noticed that my boot partition seems to be completely full: /dev/sda5             228M  228M     0 100% /boot Is this maybe th reason for this behaviour?
[22:18] <lynxman> SpamapS: did you have time to review? :)
[22:21] <SpamapS> lynxman: no. :(
[22:22] <lynxman> SpamapS: aww, well anytime you can please :)
[22:22] <lynxman> SpamapS: I still have a couple puppet patches to do tonight
[22:28] <psyferre_> Hey folks, would anyone have a quick moment for advice?  My putty session timed out while running a grub update, and like an idiot I decided to just give the machine a quick reboot to resolve the dpkg lock.  Now the system starts to boot but does not quite get to a prompt.  I assume I just need to get in and run dpkg --configure -a... is a live cd the best way to go about this?
[23:09] <pabelanger> psyferre: try #ubuntu for support
[23:09] <hggdh> smoser: SRU data added to the bug. I will install your version as soon as it is available (but it will be a manual install via dpkg, we do not allow -proposed on this server)
[23:11] <Myrtti> pabelanger: actually the topic states "Ubuntu Server discussion and support" - but I suppose that particular problem might be answered in #ubuntu too
[23:11]  * pabelanger nods
[23:12] <pabelanger> not really a server specific issue, but grub in general
[23:13] <psyferre> pabelanger: thank you for the response!
[23:14] <pabelanger> psyferre: but yes, I would use the live boot-cd to try and repair it
[23:24] <imcsk8> hello i have a problem authenticating a ssh session via pam-ldap. i can connect succesfully to the ldap server whith this user. i get this error in auth.log "pam_ldap: error trying to bind as user "uid=108584,ou=fing,dc=uach,dc=mx" (Invalid credentials)  Failed password for invalid user 108584 "
[23:25] <imcsk8> can somebody give me a hint? here are extracts from the log file and from the config files http://pastebin.com/NdiRLriQ