[03:15] <roasted> hello friends
[03:29] <eltigre> hey, I am having big trouble with postgres on a remote ubuntu 10.04 vm
[03:29] <eltigre> basically postgres doesn't start no matter what I do
=== DaIRCKing is now known as GTAXL
[05:22] <someguy> Anyone have experience with rails and ubuntu production servers here?
[05:22] <someguy> I'm trying to figure out how to get into my rails console
[05:33] <someguy> #rubyonrails
=== smb` is now known as smb
[10:07] <amarcolino> Hi I am trying to create a minimal server install, however, I am in doubt because I've looked at the mini.iso install and while it is small in size apparently it will be the same as installing from the server iso on it pulls the applications online. Just wondering if this is true, I would like to build the server myself and only have the bare requirements to run the system as well as setup lvm on install.
[10:08] <melmoth> i think you are right, the mini iso is just enough to start the install, then the installer fetch what it needs from remote repo
[10:08] <rbasak> amarcolino: use whichever installer you prefer. Just don't select any tasks. That will give you a minimal install. There's an option (a function key) in the boot menu that'll make this the default IIRC.
[10:09] <rbasak> The difference between mini and normal is just in what's already on the media rather than needing to be downloaded. You still choose what you want installed in the installer itself in both cases.
[10:10] <amarcolino> melmoth, rbasak, thanks if that is the case I will use the sever iso, I would have thought the mini iso would've been slower considering it pulls the applications online compared to the server iso, hmmm...
[10:11] <rbasak> amarcolino: yes that makes sense. Optical media seeks are slow though. Depends on your connection :)
[10:12] <amarcolino> rbasak, Ok, I get it, thanks for the info going to continue figuring out how I am going to setup the whole thing before I install it
[10:13] <rbasak> Technically there are three "tasks" - minimal, standard and server. I can't remember which combination the installer lets you pick. I think minimal and standard are always installed. But you'll want standard - minimal is only good for installing other things and is pretty useless on its own
[10:16] <amarcolino> huh?
[10:18] <amarcolino> I havent checked yet but will, this is going to be a basic server for storage, web development and virtualization using headless vbox. There are still a lot of things I need to think about, what I want is a clean system that I can slowly build upon
[10:20] <amarcolino> The hardware is quite old, maybe eight years old, 4GB ram, 1TB HD x2, but still works so I thought no point having it in a corner not doing anything
[10:25] <rbasak> Tasks are sets of packages you can pick from the installer (and later) to be installed. Packages are the basic component of what is picked to be installed. The system is unusable without the minimal task. The minimal task is only really good for installing other packages. The standard task is the set of packages which give you a normally functioning Unix. The server task gives you additional packages which you'd expect to have on a server. You're
[10:25] <rbasak> probably best off starting by asking the installer for a "Basic Ubuntu server" which gives you those three, and starting from there.
[10:28] <amarcolino> Awww, okidoki, will do that when the time comes
=== Nafallo_ is now known as Nafallo
[13:52] <zul> jamespage: just about to upload oslo-config_2013.1~b4
[13:53] <jamespage> zul, not renaming right?
[13:53] <zul> nope
[13:53] <zul> jamespage: http://pastebin.ubuntu.com/5576333/
[13:54] <jamespage> okies
[13:59] <caribou> zul: If I need to get a folsom pkg in the cloud archive fixed, what is the process ? where do I get the source pkg ?
[13:59] <caribou> zul: as I understand it, there is no SRU for cloud-archive packages
[14:00] <zul> caribou:  you submit a merge proposal for lp:~openstack-ubuntu-testing/nova/grizzly
[14:00] <caribou> zul: very minor fix : a dependancy issue
[14:00] <caribou> zul: I think it's already fixed in grizzly, lemme check
[14:01] <zul> caribou: if you are talking about novnc it probably is
[14:01] <caribou> zul: yep, that's the one
[14:01] <zul> caribou:  i think its already fixed in grizzly give it a shot
[14:01] <caribou> zul: just need the Suggests:novnc to be made a Depends:
[14:02] <caribou> zul: then if it's fixed in grizzly, is there a process to get it retrofitted in Folsom ?
[14:02] <wilmaaaah> hi, i can't make use of acpi on my 12.04 server. do i need to comple my own kernel? or can that be done by adding a module?
[14:02] <zul> caribou:  which bug is this again?
[14:04] <histo> wilmaaaah: power management is built into kernel now.
[14:04] <wilmaaaah> my main problem seems to be that i can't get the cpu temperature
[14:05] <wilmaaaah> can't find it under /proc
[14:05] <jamespage> zul, tarballs.openstack.org is obsolete right?
[14:05] <caribou> zul: https://bugs.launchpad.net/nova/+bug/1066845
[14:05] <uvirtbot> Launchpad bug 1066845 in nova "nova-novncproxy is not running; Suggest: novnc should be Depends" [Low,Fix released]
[14:05] <zul> jamespage:  for most opentack projects it is
[14:05] <zul> caribou: ill see what i can do
[14:05] <caribou> zul: thanks
[14:06] <wilmaaaah> oh, i found lm-sensors. will try that
[14:07] <caribou> zul: when installing with --install-suggests, it works fine btw
[14:07] <zul> caribou: goody :)
[14:25] <jamespage> zul, when you get a chance please can you review the fix-watch-file MP's for all core projects at https://code.launchpad.net/~openstack-ubuntu-testing/+activereviews
[14:29] <zul> jamespage:  done
[14:35] <jamespage> zul: ta
=== acrocity_ is now known as acrocity
[14:56] <zul> jamespage/yolanda: https://code.launchpad.net/~zulcss/quantum/quantum-fix-pep8/+merge/151265
[14:58] <yolanda> zul, why is that patch in ChanceScheduler?
[14:58] <zul> yolanda:  because pep8 tests are failing
=== wedgwood_away is now known as wedgwood
[14:59] <jamespage> zul, +1
[15:00] <zul> jamespage:  k thanks
[15:00] <zul> jamespage:  i sent that upstream so we can drop this patch once it gets accepted
=== evilnickveitch is now known as evilnick-afk
=== gary_poster|away is now known as gary_poster
[15:37] <zul> yolanda: is there a bug for the boto and ceilometer conflict?
[15:38] <yolanda> zul, i saw that bug yesterday, let me check
[15:38] <yolanda> https://bugs.launchpad.net/ceilometer/+bug/1102110
[15:38] <uvirtbot> Launchpad bug 1102110 in ceilometer "Grizzly testing packages : python-ceilometer installation fails" [Undecided,In progress]
[15:40] <plars> hallyn: hi
[15:40] <plars> hallyn: regarding https://code.launchpad.net/~serge-hallyn/ubuntu-test-cases/server-lxc2/+merge/150491
[15:41] <plars> hallyn: I was hoping that someone else from the server team would be reviewing it, but I'm sort of inclined to just accept it now that it's in the ubuntu-test-cases branch
[15:42] <plars> hallyn: hallyn unless you see a problem with it, the test is broken today, so at least this would allow us to easily see if it gets us past the existing problem
[15:52] <pr3d4t0r> Greetings./
[15:56] <pr3d4t0r> Q. When logging on to Ubuntu Server we're getting the "*** System restart required ***" message -- is there a log that shows why, or which .deb component required the restart?  It's getting pretty annoying how often this comes up.  These are production servers -- we don't want to bounce them so often without a good reason.  Thanks in advance.
[15:59] <Jare> pr3d4t0r: cat /var/run/reboot-required.pkgs
[16:00] <pr3d4t0r> Jare: Heh - thanks.  I found it at the same time that you replied, thanks.
[16:01] <pr3d4t0r> Jare: I see the package -- is there (in the system) a log of the reason why that package requires the restart?
[16:02] <pr3d4t0r> Jare: I can probably look at the commit or publication log for the package in Debian or Ubuntu's web sites.  Just curious to see if that change log can be viewed in the system (since this affects multiple boxes on the EC2 cloud and Chef handles provisioning/updates).
[16:05] <hallyn> plars: I agree, as I've told psivaa before
[16:05] <hallyn> plars: i coudl see value in stgraber reviewing it, but for anyone on server team it would be a waste of their time imo
[16:06] <hallyn> plars: please just merge it and we'll proceed from there
[16:06] <hallyn> plars: hm, i guess the one person who wouldn't be wasting their time might be jamespage
[16:06] <stgraber> hallyn: looking
[16:07] <hallyn> stgraber: thanks
[16:08] <stgraber> hallyn: ah, I should be able to save you a few minutes in those tests
[16:08] <stgraber> hallyn: I just noticed that the API test script doesn't need to be a .in anymore
[16:09] <hallyn> stgraber: oh since when?  it ws only a week or two ago it definately ahd to be :)
[16:09] <hallyn> stgraber: but, cool
[16:10] <stgraber> hallyn: not in staging yet, finishing the change here ;)
[16:10] <hallyn> stgraber: cool
[16:12] <Jare> pr3d4t0r: iirc the reboot-required is just an on/off switch, but you might get some info by viewing the pkg changelog "apt-get changelog pkg-name"
[16:17] <zastern> Is there a way to tell if a process is bumping up against its open file handles limit?
[16:18] <RoyK> why would libssl require a reboot?
[16:19] <stgraber> hallyn: sent the change upstream and commented in the MP
[16:19] <stgraber> RoyK: libssl itself doesn't, but it's the safest way to ensure that everything which uses it has been restarted
[16:19] <pr3d4t0r> Jare: Coolio - thanks!
[16:20] <RoyK> stgraber: that's what I mean - all I'd need to do is restart apache (if using ssl), mysql (if using ssl), postgresql (if using ssl) and ssh
[16:20] <stgraber> RoyK: yes
[16:20] <RoyK> but then, there's a new kernel waiting, so I guess it won't hurt ;)
[16:21] <hallyn> stgraber: sigh, i would have preferred the MP not hang on that, but thanks.
[16:22] <stgraber> hallyn: the lxc change should be quite easy to review (unless git has been stupid and shows a silly long diff, not sure) so we can have that in staging in the next few minutes
[16:22] <hallyn> plars: as you say the tests are broken, so ideally i'd like you to take the MP as is, and open a new bug with stgraber's comments, which are all good but none urgent
[16:23] <hallyn> plars: (and assign the new bug to me)
[16:23] <hallyn> stgraber: looking
[16:23] <stgraber> hallyn: the policy-rc.d/lxc init job stuff is trivial to fix so I guess you can do that in a minute or so (just dump 'echo manual > /etc/init/lxc.conf' and drop most of the code ;)). pep8/pyflakes may take longer and is fine to postpone
[16:24] <stgraber> hallyn: however I'm really good at doing pep8/pyflakes fixes, so I can do it for you ;)
[16:25] <hallyn> stgraber: i'd prefer to test before pushing though :)
[16:25] <hallyn> and that takes awhile in utah
[16:25] <hallyn> what i have now works
[16:25] <hallyn> don't see your email yet, hmm
[16:25] <hallyn> oh, but i see you fixed the manpage?  cool :)
[16:26] <stgraber> hallyn: the manpage looks good on my machine, so I guess someone fixed it upstream
[16:26] <stgraber> hallyn: oh wow, 946 pep8 warnings in the server test branch ;) I'll send a MP to fix those in a few minutes but that'll be unrelated to your own MP
[16:27] <hallyn> stgraber: lol, i of course would prefer it to be not unrelated to but on top of my MP :)
[16:29] <stgraber> hallyn: well, most of the fixes will be for scripts outside of the lxc ones (I scanned the whole server branch)
[16:29]  * hallyn finishes lxc-attach first, rather than allowing high prio test breaks to turn low prio cleanup sinto high prio blockers
[16:29] <hallyn> stgraber: just run 'dep8' ?
[16:29] <hallyn> never used it, will play with it
[16:29] <stgraber> hallyn: yep
[16:29] <stgraber> hallyn: *pep8
[16:30] <stgraber> hallyn: PEP-8 is the Python Enhancement Proposal 8 which barry and a few others worked on. It's the python coding guidelines and the command line tool will complain for anything that doesn't match the upstream guidelines
[16:30] <hallyn> right, mistyped :)
[16:30] <hallyn> jjohansen: is there a max length on apparmor profile names?
[16:32] <zul> yolanda:  patch coming for the tests stuff
[16:32] <yolanda> zul , submitted to openstack, or patched in the package?
[16:33] <zul> yolanda: both
[16:33] <yolanda> good news!
[16:34] <yolanda> about ceilometer, it's still giving some troubles with tests, and with the requests<1.0 issue
[16:34] <yolanda> they patched the test of components but still ceilometer is pointing to <1.0
[16:36] <hallyn> nm, i'll read it the long way
[16:40] <jjohansen> hallyn: hrmmm, I think the compiler uses a fixed sized buffer of PATH_MAX
[16:42] <zul> yolanda:   http://paste.ubuntu.com/5576734/
[16:42] <hallyn> jjohansen: but that's not enforced int he kernel, but the userspace tools?
[16:42] <jjohansen> hallyn: yes
[16:42] <jjohansen> hallyn: kernel side, there is a max path lookup buffer control
[16:43] <yolanda> zul, great
[16:43] <hallyn> jjohansen: ok, thanks - i was trying to decide whether https://github.com/hallyn/lxc/commit/cceb4f2fecb423ddeda8f3592bad17ce59b74f1b was worth it
[16:43] <jjohansen> hallyn: /sys/module/apparmor/parameters/path_max
[16:43] <yolanda> but the right way should be that tests directory is correcty set?
[16:44] <hallyn> jjohansen: oh, cool.
[16:44] <hallyn> well, that's big enough that it's prolly worht it.  (btw don't look too closely, i just typed it out, haven't doublechecked for idiotic mistakes :)
[16:44] <hallyn> jjohansen: thanks, ttyl
[16:45] <jjohansen> hallyn: oh hrmm, the library might have a max too, and I am pretty sure that getprocattr is limited to an entry of 1 PAGE
[16:46] <jjohansen> I'd have to double check
[16:47] <hallyn> jjohansen: it's ok, i'll just leave it like this, future proof too
[16:52] <zul> yolanda: there is a bunch of fixes needed for the ceilometer package wants we get the fixes in then ill start uploading it to raring and the CA
[16:53] <yolanda> zul, fixes in the package?
[16:53] <yolanda> or in the code?
[16:53] <zul> both
[16:53] <yolanda> do you want me to make some fixes in the package? what problems are we having?
[16:54] <stgraber> hallyn: wow, that branch contains a lot of copy/paste stuff, I ended up mostly doing recursive sed to fix those ;)
[16:54] <yolanda> normally i find the problems with dependencies, the requests one, and that i have to skip the tests in order to build it
[16:55] <stgraber> hallyn: down to just 276 warnings to fix now
[16:59] <hallyn> i'm pretty sure all those tests were converted from other suites over to utah, so yeah, i'd expect cut/paste in that process
=== VD is now known as Guest89990
[17:20] <hallyn> stgraber: uh, still not seeing your commit on lxc-devel
[17:23] <stgraber> hallyn: forwarded
=== CallingP1nther is now known as apetite
[17:46] <hallyn> stgraber: thanks.  acked.  imap has been treating me badly since last night, so not sure if it got deleted there, or if it got held up at the list.
[18:08] <paco1> hello masters!
[18:10] <paco1> how to see the options in a package?
[18:10] <paco1> thanks very much
[18:11] <sarnold> paco1: "options in a package"?
[18:11] <stgraber> hallyn: https://code.launchpad.net/~stgraber/ubuntu-test-cases/fix-pep8-pyflakes/+merge/151300
[18:12] <stgraber> hallyn: who should I subscribe to have this reviewed/merged? Ideally it should be done ASAP before the scripts I fixed start changing.
[18:12] <paco1> yes, for example, openldap come with a full of options if i install it by source
[18:13] <hallyn> stgraber: either jamespage or plars i think
[18:13] <paco1> how to know the options come with the package installation?
[18:13] <hallyn> stgraber: jamespage did most of the original work
[18:13] <hallyn> so he should be able to review quickly
[18:13] <plars> stgraber: does it conflict with hallyn's earlier one, or depend on it?
[18:14] <hallyn> this attach apparmor profile change thing is turning into a disaster
=== Hexi_ is now known as Guest28206
[18:15] <plars> hallyn: also, if you could delete https://code.launchpad.net/~serge-hallyn/ubuntu-test-cases/server-lxc-fixapi whenever you get a moment, I think it's superceded by the other right?
[18:15] <hallyn> plars: yes it is
[18:16] <hallyn> deleted
[18:20] <plars> stgraber, hallyn: they appear to conflict a bit in 2 files
[18:23] <stgraber> plars: yeah, I'd expect them to conflict slightly on the two lxc python files
[18:24] <stgraber> plars: did you already merge hallyn's branch? if so, I'll re-submit based on the updated master branch
[18:24] <plars> stgraber: I was about to
[18:24] <plars> stgraber: do you mind if I push it and have you rebase it on that?
[18:25] <stgraber> plars: nope, go ahead.
[18:27] <plars> oh
[18:27] <plars> I can't push
[18:27] <zul> yolanda:  still around?
[18:27] <plars> hallyn: I think you're going to have to push it
[18:27] <plars> hallyn: or someone from ubuntu-server-developers team
[18:32] <hallyn> plars: I'm not allowed to push to that ...
[18:33] <hallyn> wait waht?
[18:33] <hallyn> i am!  sorry!
[18:33] <hallyn> pushed
[18:33] <plars> :)
[18:33] <hallyn> sorry for wasting your time
[18:33] <zul> adam_g:  https://code.launchpad.net/~zulcss/ceilometer/deps-refresh/+merge/151073 and https://code.launchpad.net/~zulcss/ceilometer/boto-conflict/+merge/151304
[18:34]  * hallyn out - biab
[18:35] <hallyn> woohoo, figured out my thinko, attach with apparmor working.  now to clean that up
[18:37] <hallyn> stgraber: shout when it's ported and i'll push?
[18:37] <hallyn> (lp:~stgraber/ubuntu-test-cases/fix-pep8-pyflakes)
[18:37] <hallyn> (now, biab)
[18:37] <yolanda> zul, here
[18:37] <zul> yolanda: https://code.launchpad.net/~zulcss/ceilometer/boto-conflict/+merge/151304
[18:38] <yolanda> done
=== CallingP1nther is now known as apatite
[18:41] <stgraber> hallyn, plars: https://code.launchpad.net/~stgraber/ubuntu-test-cases/fix-pep8-pyflakes/+merge/151300 updated
[18:42] <plars> stgraber: thanks
[18:50] <hallyn> stgraber: pushed, thanks
=== mike_ is now known as Guest26993
[19:00] <becom33> I'm having error installing couple of libs http://pastebin.com/rGfEjL69 help please
[19:03]  * becom33 anyone ?
[19:04] <sarnold> becom33: hunh, that's odd, where is 2.7.5.dfsg-1ubuntu1 coming from?
[19:04] <becom33> I have no idea
[19:04] <becom33> I installed ubuntu server and did a apt-get update
[19:05] <becom33> after thats I started to get that error
[19:05] <sarnold> 2.6.31.dfsg-2ubuntu1.11 at least makes some sense, that is the newest version in 8.04 lts..
[19:06] <becom33> :/ what am i suppose to do now ?
[19:06] <sarnold> becom33: check your APT sources lists to see if you've got inconsistent deb lines -- say, updates or security from a different release
[19:06] <becom33> I'm not suer
[19:06] <becom33> sure *
[19:06] <becom33> :/ Im just gonna install again and see
[19:07] <sarnold> becom33: re-run "apt-get update" and then try again..
[19:13] <zul> adam_g: ceilometer doesnt use python-setuptools-git
[19:14] <adam_g> zul, then it should be dropped from d/control all together?
[19:14] <zul> adam_g: yep
=== CallingPanther is now known as apatite
=== CallingP1nther is now known as apatite
[19:25] <becom33> sarnold, now I'm having this error http://pastebin.com/8CYjhuzY
[19:25] <becom33> I did a apt-get update
[19:26] <sarnold> becom33: o_O that .. is confusing.
[19:27] <becom33> maybe my source is outdated ?
[19:28] <zul> adam_g: https://code.launchpad.net/~zulcss/ceilometer/deps-refresh/+merge/151309
[19:29] <becom33> sarnold,
[19:30] <sarnold> becom33: sorry, that one doesn't make any sense to me :)
[19:31] <hallyn> stgraber: jjohansen: so when you lxc-start a container, it joines a restricted apparmor profile.  when you lxc-attach it, by efault, we want to join that same profile.  my question,
[19:32] <hallyn> if we say 'lxc-attach -e' (meaning 'dont' drop privileges), do we want to nto switch apparmor profiles?
[19:32] <hallyn> i think we do anyway,
[19:32] <hallyn> since otherwise we're subjecting the host to things running in the container, but the smae could be argued for -e in general
[19:33] <hallyn> i'm going to for nwo have it always switch profiles, and if someone complains we can maybe add a new option, with even bigger warning
[19:34] <jjohansen> hallyn: hrmmm, thats tough I guess I would error towards the more restrictive (so switch profiles), because if you decide your wrong its easier to loosen than tighten
[19:35] <hallyn> jjohansen: yeah, agreed, thanks.  mind you as it is -e will also avoid c group restrictions,w hich is also a big deal...  but we can add it later
[19:38] <adam_g> zul, python-sqlachemy  (<= 0.7.9) | python-sqlalchemy (<< 0.6.3-2), ?
[19:39] <zul> adam_g: doh ill fix that
[19:40] <zul> adam_g: http://paste.ubuntu.com/5577222/
[19:40] <adam_g> zul, also, why are python-{glance, swift, nova} needed? requiring those installs the entire codebase for each
[19:40] <stgraber> hallyn: always switch sounds good
[19:40] <zul> adam_g: because thats the way that ceilometer works afaik
[19:41] <adam_g> oh, ok
[19:41] <stgraber> hallyn: I suppose we could extend -e to take arguments in the future, so you can do -e cgroup,apparmor to have it only drop capabilities but keep the new processes out of cgroup and apparmor restrictions
[19:41] <zul> adam_g: actually it should be ok with python-glanceclient now
[19:41] <zul> so ill remove those as well
[19:44] <zul> adam_g: can you check one more time?
[19:47] <hallyn> stgraber: sounds good.  won't even mention it until someone asks for it.
[19:47] <hallyn> :)
[19:47] <adam_g> zul, the MP is gone?
[19:51] <zul> adam_g: deleted it and started over
[19:51] <zul> hold on
[19:51] <zul> adam_g: https://code.launchpad.net/~zulcss/ceilometer/deps-refresh/+merge/151309
[19:52] <stgraber> hallyn: we'll just need to keep it in minde when implementing attach() in the API so that at least the API call does it right, then it'll just be a matter of rebasing lxc_attach.c on the API
[20:01] <adam_g> zul, is python-{nova, glance, swift, etc} needed or just the clients? im grepping thru the ceilometer src now and it looks like it needs the actual server code
[20:02] <zul> adam_g: tools/pip-requires says it needs the clients
[20:02] <adam_g> zul, hmm
[20:12] <zul> adam_g:  im going to wait til monday for this
[20:13] <adam_g> k
[20:26] <hallyn> stgraber: did you have any pending patches for raring's lxc package?
[20:26] <hallyn> i'd like to push the attach-apparmor patch on monday (pending/addressing feedback from the list)
[20:28] <stgraber> hallyn: hmm, let me see what we pushed to staging since 0.9~alpha3 that I would like to see in Ubuntu before rc1 is released (in less than two weeks)
[20:29] <stgraber> hallyn: nah, I can wait two weeks to get the rest in ;) It's not like I actually use the packages in raring anyway.
[20:30] <hallyn> stgraber: is there a feature freeze to worry about after that rc1?
[20:31] <stgraber> hallyn: yep, rc1 is the last milestone before 0.9 is out, so while I don't think we'll freeze entirely, I certainly plan for rc1 to be as close to final as possible and release 0.9 2-3 weeks after rc1 is out
[20:31] <stgraber> hallyn: saw my "On the road to rc1" e-mail?
[20:31] <hallyn> stgraber: i meant 13.04 ff
[20:32] <stgraber> hallyn: ah, that, well, it depends on whether we'll have a 13.04 release ;)
[20:32] <hallyn> i feel 0 urgency regarding staging tree :)
[20:32] <hallyn> right...
[20:32] <hallyn> limbo
[20:32] <hallyn> all right i'll just carry on
[20:33] <stgraber> hallyn: in any case, I'm perfectly happy to put my release team hat on and give a FFe for 0.9 final
[20:33] <hallyn> stgraber: ok then i'll aim my patches at staging and not package for now :)
[20:34] <stgraber> hallyn: if we end up releasing 13.04, I'd like to see us release with a stable version of lxc ;)
[20:34] <stgraber> and ideally not have hundreds of patches on top of it this time around :P
[20:34] <hallyn> part of that is saying no to features :)
[20:34] <hallyn> but, agreed
[20:37] <hallyn> haha, that one is fixed upstream (an dnow in pkg) too.  nice.  thanks Dwight
[20:39] <hallyn> which means i can look at cgroups patch.  nice
[21:19] <hallyn> stgraber: your patch JUST made it through lxc-devel
[21:19] <hallyn> list seems tob e way behind.  not good
[21:22] <stgraber> hallyn: ok, that explains why I haven't seen yours yet...
[21:26] <hallyn> stgraber: ok - i intend to send a new, complete cgroup patch late tonight.  (gonna go enjoy sunshine for a few mins right now and get back to it later)
[21:28] <stgraber> hallyn: sunshine? what's that? (been grey here for the past few weeks) :)
[22:23] <elementz> hi, i am in the process of installing an ubuntu image to a VPS host system, which comes with a single core, and 512 mb of ram. Now I have the option to install ubuntu 12.10 either in the 32 or 64 bit version. i understand that the 64 bit version would give me an advantage when using a multicore cpu, but what about my special use case? would i gain any advantage when installing a 64bit os?
[22:41] <hallyn> stgraber: lxc-ls, in python, going through c api, is a bear to debug :)
[22:42] <stgraber> hallyn: ;) what's the bug you're looking at?
[22:42] <hallyn> stgraber: one i seem to have introduced with my cgroup stuff.  lxc-ls hangs on Container.__init__
[22:43] <hallyn> i've got a hunch what it is, just not sure where.  (i think i'm calling to the monitor from the monitor itself, or somesuch)
[22:43] <hallyn> hm, maybe i can remote gdb attach once it's running
[22:44] <stgraber> hallyn: gdb -p should work but won't necessarily be that useful
[22:44] <hallyn> it only does it wwith --fancy
[22:44] <stgraber> hallyn: right, without --fancy it doesn't create Container objects
[22:45] <hallyn> oooh.  no, it's simpler.  i'm not dropping a semlock
[22:45] <DawLi> Hi, We are a small team developing a web designer software [open source], and we would like to know more about how to get funding for the project within the open source community.
[22:45] <hallyn> right, i didn't think it woudl be very helpful :)
[22:45] <hallyn> but it does confirm i'm in sem_wait.  boggle.
[22:46] <stgraber> hallyn: FWIW, if it hangs in Container.__init__ it's either because of lxc_container_new or get_keys as those are the only two C API calls done by it
[22:47] <hallyn> stgraber: yeah pdb had pointed me at that.  seems to be at ContainerNetworkNew().
[22:48] <stgraber> right, ContainerNetworkNew parses get_keys to create the network objects
[22:48] <hallyn> but pdb really didn't seem helpful for stepping/pinpointing/getting stacktrace
[22:48] <hallyn> well no, the weird thing was it tended to show
[22:48] <hallyn>         self.network = ContainerNetworkList(self)
[22:49] <hallyn> but that __init_ doesn't actually walk the keys
[22:49] <hallyn> 'what have i done'
[22:51] <hallyn> drat.  thought i had a unity bug, but i guess i'ts really just another effing nvidia bug
[22:52] <stgraber> hallyn: hmm, yeah, pdb isn't terribly useful when half the calls are done through a C binding ;)
[22:56] <hallyn> aaaand, laptop shut off.  hal^Wunity trying to stop me reporting a bug against it, no doubt
=== wedgwood is now known as wedgwood_away
=== wedgwood_away is now known as wedgwood
[23:02] <stgraber> hallyn: your apparmor patch just made it to the list ;) reviewing now
[23:02] <hallyn> woot
[23:04] <stgraber> yeah, that took a while ;)
[23:22] <stgraber> hallyn: apparmor patch pushed to staging (sourceforge will tell you that in a day or so I guess ;))
[23:22] <hallyn> stgraber: great, thanks
[23:23] <hallyn> stgraber: haha, see, ubuntu is too quiet.  it wasn't telling me that lxc-ls was ending ina  segfault the first tim ei run it (leaving semaphores locked) until i deleted the semaphores and ran under strace.
[23:35] <stgraber> hallyn: is it just me or sourceforge was actually fast this time around? I just got a copy of the e-mail I sent your 10min ago.
[23:40] <hallyn> stgraber: let's hope they'v efixed their issue
[23:45] <hallyn> stgraber: interesting - c.get_ips() works fine until i do c.state(), then c.get_ips() segfaults.
[23:47] <stgraber> hallyn: get_ips() segfaults?? that's weird because it's not supposed to do any C call
[23:48] <stgraber> hallyn: only C calls get_ips() does is check access the container name and running properties
[23:49] <hallyn> anyway stgraber and - it's on container which arenot running
[23:49] <stgraber> hallyn: however, it's calling lxc-attach to grab the IP information, so maybe there's something going quite wrong when using the API + calling lxc-attach?
[23:49] <stgraber> oh, well, if the container isn't running, then the only thing it does is access the running property
[23:49] <stgraber> hallyn: that's calling ->is_running(c)
[23:50] <hallyn> stgraber: note this is with my cgroup patch...
[23:53] <hallyn> (not with the attach patch only)
[23:53] <hallyn> all right, gonna have dinner and worry abou this later - gnight