[00:27] <peitschie> NET||abuse: you said you have a branch on your local machine... is that a branch or a checkout?
[00:27] <NET||abuse> branch
[00:34] <peitschie> NET||abuse: did you do a pull or merge on your local branch to try and get the changes from the server branch?
[00:34] <NET||abuse> pull
[03:23] <spiv> vila: https://bugs.launchpad.net/bzr/+bug/672382
[03:37] <poolie> hi all
[03:43] <spiv> poolie: hey, welcome back!
[03:43] <poolie> hi there
[03:44] <poolie> it's good to be back; those were not the smoothest flights i ever had
[03:44] <spiv> I imagine Qantas is pretty chaotic atm.
[03:58] <poolie> very
[03:58] <poolie> there were something like 10 staff deadheading on our flight
[03:58] <poolie> i guess they are moving a lot of people and equipment around to try to cope; the a380s probably carry nearly twice what the 747s do
[04:23] <lifeless> poolie: lol - boeing considered a 650seat 747
[04:24] <lifeless> poolie: the 400ER 3-class seats 416 according to  http://en.wikipedia.org/wiki/Boeing_747
[04:25] <lifeless> poolie: and the A380 450
[04:25] <lifeless> (from adding the numbers in http://www.seatguru.com/airlines/Qantas_Airways/Qantas_Airways_Airbus_A380.php)
[04:26] <poolie> ok, and the a380 is somewhere around 650?
[04:26] <poolie> ah, so not such a big difference
[04:26] <poolie> i guess the qf a380s have a lot of business class seats
[04:26] <lifeless> 72!
[04:27] <lifeless> http://www.qantas.com.au/travel/airlines/a380/global/en agrees with the figures
[04:28] <poolie> on my flight across they realocated some business seats to premium class, and some premium seats to economy
[04:28] <lifeless> you were scheduled on an a380 flight ?
[04:29] <poolie> on the way back i was meant to be on an a380 from lax-syd
[04:29] <lifeless> nice
[04:29] <poolie> i eventually flew on a 747 because all their a380s are grounded
[04:30] <poolie> it was very chaotic
[04:30] <poolie> some people had already been waiting around LA for three days
[04:30] <lifeless> http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=10686109
[04:31] <lifeless> emirates seem to have an excellent deal there
[04:31] <lifeless> (if you're paying in that bracket)
[04:32] <poolie> i think this weekend is a great demonstration that you can pay 5 figures for a 1st class ticket and still be stuffed around for hours
[04:32] <lifeless> for sure
[04:33] <lifeless> as far as I'm concerned its all about the sleeping
[04:33] <poolie> perhaps slightly more considerately, but they still have to stand around in the gate lounge wondering if they will ever leave
[04:33] <poolie> me too
[04:33] <lifeless> sleeping and power
[04:33] <lifeless> and air NZ have power in economy ;)
[04:33] <poolie> i used points to get premium to sfo on the way across, and ended up getting a business physical seat
[04:33] <poolie> (with premium-grade food etc)
[04:33] <poolie> and that was brilliant
[04:33] <lifeless> poolie: -lol- nice
[04:34] <lifeless> I'm surprised they bothered splitting your menu our
[04:34] <lifeless> out
[04:34] <spiv> poolie: hurrah!
[04:34] <lifeless> ok, afkish
[04:34] <poolie> i think they have semipermanently reallocated some rows to other classes
[04:34] <poolie> hugh got a premium seat without technically being upgraded
[04:35] <poolie> anyhow i'm just catching up on bills, mail stuff
[04:35] <poolie> ping me if there's anything urgent
[04:35] <spiv> *nod*
[07:00] <vila> hi all !
[07:02]  * KombuchaKip is unsure why his client randomly decided to log himself into #bzr
[07:03] <gthorslund> hi vila!
[07:03] <vila> _o/
[07:46] <poolie> hello vila
[07:46] <vila> poolie: hey !
[07:50] <poolie> how are things with you?
[07:50] <vila> fine ! A large plate for the week but I'm hungry :-P
[07:51] <vila> pp'ing, releasing 2.3b3, more conflict resolution, bzr config bugs, plenty of fun ahead :)
[07:51] <poolie> cool :)
[07:51] <poolie> i've seen some of this
[07:52] <poolie> the conflict features sound good
[07:52] <poolie> it seesm like it's more in the way of user feedback than bugs as such?
[07:53] <vila> hmm, right, the implementation is incomplete so that first triggered a bug, but that's still incomplete. I think I can implement --prefer-this/--prefer-other/--take-both quite easily now (which is why I didn't implement --take-this/--take-other for text conflicts in the first place)
[07:54] <vila> deep down though, the bug is revealing a hole in the test coverage (big surprise :-)
[07:56] <vila> oh, and I'd like to switch to sphinx for good too (bug I'm not sure I will be able to tackle this one *this* week ;)
[07:57] <fullermd> Getting lazy in your old age or somethin'?   :p
[07:57] <vila> hehe
[07:58] <vila> my age always seem to inversely proportional to the fun I have, or something ;)
[07:59] <fullermd> Well, at least you spend less on bail money  ;)
[08:01] <vila> oh, and I'd like to implement 'bzr gardener pull'  which should allow to mirror a set of branches with a single command
[08:01] <poolie> that would be kind of nice
[08:02] <poolie> it'd be better if it could get unified with other things that deal with sets of branches, like colo
[08:02] <poolie> i may package that this week, if max and jelmer haven't already
[08:04] <vila> well, there are a couple of long term ideas I'd like to implement there (colo and looms support included), so I'd prefer to keep it separated for now
[08:04] <poolie> vila did john tell you anything much about uds?
[08:05] <poolie> it was a good trip
[08:05] <poolie> (well, the travel kinda sucked, but the meetings were good)
[08:05] <vila> poolie: not that much, he seem pretty busy on other subjects these days...
[08:05] <GaryvdM> Hi all
[08:05] <poolie> when i get my thoughts in order i'll send an update
[08:05] <vila> poolie: and I couldn't find the time to track UDS
[08:05] <vila> poolie: cool
[08:06] <poolie> i feel a bit more convinced we should focus together on a smaller set of topics
[08:06] <vila> GaryvdM: hey !
[08:06] <GaryvdM> vila: I should be able to build windows installers tonight
[08:06] <poolie> and set them as goals for 2.3
[08:06] <poolie> hi gary
[08:06] <vila> GaryvdM: great !
[08:08] <vila> poolie: my foci for 2.3 are conflict resolution, config, sphinx, automated installer build, nightlies, I'll stop there ;)
[08:09] <jelmer> mwhudson: Did you manage to figure out what was wrong with the twisted branch?
[08:09] <jelmer> 'morning vila, poolie, GaryvdM
[08:09] <GaryvdM> Hi jelmer
[08:09] <vila> there is certainly work to do on tree transform, in-memory trees for tests for which I may find simple steps to progress
[08:09] <vila> jelmer: _o/
[08:10] <poolie> hi there jelmer
[08:10] <vila> poolie: in-memory trees is something I may start playing with in bzr-gardener where it will be easy to measure performance gains
[08:11] <poolie> vila, i think those are all good things (and they're pretty much what i thought you were doing)
[08:11] <vila> poolie: better ancestry graphs handling is a bit more work but again bzr-gardener would be a good sand box
[08:11] <poolie> but i wonder if we should either get more people onto them too, or set specific targets for 2.3
[08:12] <vila> poolie: I agree with the feeling but I haven't yet found the right means :-}
[08:12] <poolie> generally speaking i'm not a big fan of putting time into estimation when you could just spend it doing things, but...
[08:12] <vila> poolie: I have a bunch of notes about the next generation config I should submit (noted in my TODO) but it's still too much brain dump so far
[08:13] <vila> poolie: yeah, it's even harder if you try to do time estimates if you don't do the work yourself
[08:13] <vila> meh
[08:14] <vila> it's even harder to do reliable time estimates for things you don't do yourself
[08:21] <fullermd> That's never stopped my clients from telling me how long things should take...
[08:23] <vila> hehe, funny, I explained that recently: first you estimate how long it will take, then the sales guy decides how much it will sell it and when the whole price is decided, a new schedule is deduced
[08:24] <vila> somehow the sales guy always shorten the delay instead of the unit price, go figure why most projects are behind schedule after that...
[08:25] <spiv> fullermd: perhaps the deal should be "you can tell me how long it will take if I can then tell you what the 'per-hour' rate will be"
[08:25] <vila> spiv: oh, you *can* say that before the price is fixed, everybody always agree at this point :)
[08:26] <fullermd> I was talking with this guy I work with the other week about our respective current projects, both of which are wildly beyond their original conceptions in every way.
[08:26] <fullermd> Him: After this, I'm going to feel no shame at all about turning in astronomical estimates in the future.
[08:26] <fullermd> Me: I said that the last 6 projects.  I've learned that I suck at astronomy.
[08:27] <vila> fullermd: trivial details we don't want to hear about, what we care is: is is still the same price and the same delay, that's what you signed
[08:28] <fullermd> Oh sure.  It's just not the same project anymore   :)
[08:28] <vila> Me: but you said you wanted 'X' not half of the alphabet ! Them: don't start with the details again :)
[08:51] <vila> poolie: do you have any pending mail for contributor agreements ?
[08:52] <poolie> meaning new submissions?
[08:52] <vila> yup
[08:53] <poolie> from tzeentch?
[08:53] <vila> exactly
[08:55] <vila> ping losa, any news or feedback about rt #41340 ?
[08:58] <vila> Does anyone know the IRC nick for nmb ?
[08:58] <vila> aka Neil Martinsen-Burrell
[09:02] <vila> poolie, nmb: Am I nitpicking too much if I prefer check_output=True over blank_output_matches_anything=False in  https://code.edge.launchpad.net/~nmb/bzr/662509-ignore-blanks/+merge/38889 ?
[09:02] <vila> there is a slight ambiguity there that I fear will come back haunt us later...
[09:02] <poolie> vila, i don't seem to have a mail about that from tzeentch
[09:02] <poolie> i should go soon
[09:02] <GaryvdM> vila: it seems he does use 'nmb' - see http://irclogs.ubuntu.com/2008/08/26/%23bzr.html
[09:03] <vila> poolie: ok, I'll ping him via the review again then
[09:03] <vila> GaryvdM: great, thanks
[09:04] <poolie> to me 'check_output' doesn't make it so clear that this is specifically about the handling of blank output
[09:04] <poolie> also i think generally if there's a varargs option that defaults to off, it's better to have the non-default state be thing=True
[09:05] <vila> ok, then how about *empty*_output_matches_anything instead of blank_output_matches_anything
[09:06] <vila> which is really the itching part
[09:07] <vila> I still need to implement it for the test-script command anyway so I'm not asking nmb to do it
[09:14] <poolie> so the difference between 'empty' and 'blank' is key?
[09:22] <vila> poolie: well, 'key' may be a bit strong, but 'blank' in my mind means that a blank line is allowed which isn't true
[09:25] <poolie> true
[09:25] <poolie> ok, so s/blank/empty/ would be fine with me
[09:25] <poolie> or even s//null
[09:26] <vila> k
[09:27] <vila> so I'll make a submission with this tweak and implement it for test-script in a superseding submission
[09:32] <poolie> ok
[09:32] <poolie> so it's good night from me...
[09:36] <jbowtie> Just released bzr-tfs 0.3.0, with TFS 2010 and tfs.codeplex.com support
[09:38] <jelmer> jbowtie: \o/
[09:47] <GaryvdM> Bla - no python2.4/2.5 in lucid/mavrick
[09:48]  * GaryvdM starts building karmic vm...
[09:48] <vila> GaryvdM: err, I thought you can still install 2.4/2.5 in lucid no ?
[09:49] <GaryvdM> vila: you can build from source, but you can't apt-get install
[09:50] <GaryvdM> https://launchpad.net/ubuntu/+source/python2.5 - no lucid/maverick
[09:50] <vila> GaryvdM: my bad, you're right
[09:51] <vila> GaryvdM: I knew I had a VM for that, just misremember lucid instead of karmic ;)
[10:09] <fullermd> All those adjectives sound alike to me  ;p
[10:14] <maxb> GaryvdM: https://launchpad.net/~maxb/+archive/preserved may help for 2.5/lucid
[10:22] <mgz> jbowtie: you should make a post in that IronPython vcs thread
[10:31] <mgz> right, I'm off out.
[10:32] <GaryvdM> maxb: Thanks.
[10:32]  * GaryvdM waves to mgz
[10:52] <vila> ping losa, any news or feedback about rt #41340 ?
[11:03] <vila> mgz: rats, I missed you, ping me when you're back
[13:01] <vila> ping LOSA
[14:21] <vila> ping losa
[14:22] <Chex> vila: good morning there
[14:23] <vila> Chex: good morning !
[14:23] <vila> Chex:  any news or feedback about rt #41340 ?
[14:30] <Chex> vila: I am working on clearing a backlog of LOSA requests, give me a bit and  I will get back to you
[14:31] <vila> Chex: sure
[15:39] <elmo> hey, how do I get a specific branch using bzr-git?
[15:39] <jelmer> elmo: hi
[15:39] <elmo> bzr: ERROR: The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree'.
[15:39] <jelmer> elmo: there's no way to do that at the moment (bzr lacks the UI to specify non-head branches), although you can import all branches using "bzr git-import"
[15:40] <elmo> also, ^-- what?
[15:40] <elmo> jelmer: ok
[15:40] <elmo> I don't think i want to import all branches, that'd probably be rude
[15:40] <jelmer> elmo: your repository contains git submodules, which can not be mapped to anything in bzr yet
[15:40] <elmo> I guess I'll just have to face the music^Wgit
[15:40] <jelmer> elmo: "git clone" will fetch all branches too, so I don't think it would too rude to fetch all branches
[15:41] <jelmer> elmo: but yeah, for the moment you don't really have an alternative to using git if there are submodules.
[16:42] <quicksilver> vila: are you an ediff expert?
[16:45] <vila> quicksilver: ask your question, we'll see ;)
[16:45] <quicksilver> vila: I had a conflict which had more 'regions' that it should have
[16:45] <quicksilver> vila: two entirely different changes, coincidentally, shared a common line in the middle.
[16:45] <vila> weird but better than the opposite no ?
[16:46] <quicksilver> vila: I wanted to tell ediff "treat these two differences as one big difference"
[16:46] <quicksilver> so that I could then press the button which means 'keep both'
[16:46] <vila> why don't just you do it twice ?
[16:47] <vila> quicksilver: you know you can edit the regions too and then ask ediff to keep whatever you want
[16:48] <vila> ha no, you mean they shouldn't overlap the way they are displayed ?
[16:51] <quicksilver> vila: takes a moment to explain.
[16:51] <quicksilver> vila: tree A has "{preA}{common}{postA}"; tree B has "{preB}{common}{postB}"
[16:51] <quicksilver> vila: correct resolution is "{preA}{common}{postA} {preB}{common}{postB}"
[16:52] <quicksilver> vila: if I press "keep both" twice, I will get lines all interleave
[16:52] <quicksilver> "{preA}{preB}{common}{postA}{postB}"
[16:52] <quicksilver> vila: see?
[16:52] <vila> yeah, so you need to edit manually then
[16:52] <quicksilver> if I could say "treat this as one difference"
[16:52] <quicksilver> then "keep both" would be the right thing.
[16:52]  * vila nods
[16:53] <vila> does it occur frequently ?
[16:53] <quicksilver> in fact {common} was "my $self=shift;" which is a very common line in perl.
[16:53] <quicksilver> likely to occur at the beginning of many functions.
[16:53] <vila> yeah, as do '{' and such :-/
[16:53] <quicksilver> yes, that would be another obvious example
[16:53] <quicksilver> (although I've never had it happen with '{' I don't think)
[16:53] <vila> weak point in the diff algorithm...
[16:53]  * quicksilver nods
[16:54] <LeoNerd> I've often wanted with diff to "pin" two lines, to say that a specific line on each side was the "same" line
[16:54] <quicksilver> this is the first time I remember it happening exactly like this.
[16:54] <vila> pretty rare given the few feedback we get on such cases
[16:54] <quicksilver> vila: funnily enough I switched from emacs to Apple's Filemerge.app to resolve this one.
[16:54] <quicksilver> and Filemerge did the right thing anyway.
[16:55] <quicksilver> no idea why. It must have some heuristics for combining nearby regions.
[16:55] <vila> but the conflicts were generated by bzr right ?
[16:55] <quicksilver> yes.
[16:55] <quicksilver> I gave filemerge all four files file{,.BASE,.OTHER,.THIS}
[16:55] <quicksilver> and it worked it out.
[16:55] <vila> so patiencediff, the algo we use, is *generally* better, partly because it found this common line :-/
[16:56] <quicksilver> ;)
[16:56] <vila> so Filemerge certainly use a different algorithm and recalculate the conflicts from scratch ignoring bzr proposals
[16:56] <vila> I don't think we have an easy way to change the diff algo used by merge
[16:57] <vila> there are discussions about that though
[16:57]  * quicksilver nods
[16:57] <quicksilver> I don't often get conflicts which annoy me
[16:57] <quicksilver> but then again, we don't often let branches diverge all that far
[16:57] <quicksilver> this was a particularly long-lived, far-diverged branch.
[16:58] <vila> you can try 'bzr remerge <file>' with various options (but keep a copy of your file with your conflict resolution, remerge will destroy them)
[17:04] <mgz> vila ping, but I'm only in for an hour.
[17:04] <vila> mgz: ok, I wanted to ask about your connection hook mp
[17:05] <mgz> goforit.
[17:05] <vila> mgz: I think you should put it back in NeedsReview state so we can ping spiv :)
[17:06] <mgz> that sounds reasonable.
[17:07] <vila> I thought about it a bit more and I'm pretty sure we never reconnect because most of the time bzr+ssh is used and ssh never drops connections (or at least *I* never experimented that nor have I heard about such cases)
[17:08] <vila> so until reconnect is implemented for smart mediums, we can have two hooks, one for smart medium and one for the other transports
[17:08] <vila> they don't have to have the same signature at least to start with
[17:08] <mgz> sounds like it would work.
[17:08] <mgz> how much are we worried about burdening our future selves with interfaces we don't want any more?
[17:09] <vila> even if not perfect, that would allow progress in the right direction
[17:10] <vila> well, I don't know, but most probably at connection time you want to know the url and whatever info you can can gather about the client which is not much
[17:10] <quicksilver> vila: hmm, right.
[17:10] <quicksilver> vila: "weave" does a better job, for my needs, for this specific case
[17:11] <quicksilver> vila: what I mean is that 'weave' treats it as one big difference region
[17:11] <quicksilver> so 'keep both' is the right thing
[17:11] <vila> quicksilver: honestly no idea, but that the one I would try first
[17:11]  * quicksilver nods
[17:11] <quicksilver> thanks
[17:11] <quicksilver> ah no, it did something odd
[17:11] <quicksilver> it took into account my local changes already
[17:11] <quicksilver> hmm
[17:11] <quicksilver> I think I needed to back out my changes before remerging.
[17:12] <vila> quicksilver: it is supposed to do a better job for highly diverged branches
[17:13] <vila> quicksilver: err, what ? remerge redo the merge, it's not supposed to do that on top of your modifications
[17:14] <quicksilver> vila: I had already resolved the conflict
[17:14] <quicksilver> it appeared to take advante of my current file
[17:15] <quicksilver> the stuff in "TREE" contained the lines that, in fact, were never in "TREE"
[17:15] <quicksilver> (they were only present in OTHER, but they were present in my locally resolved copy of course)
[17:17]  * vila scratches head
[17:19] <vila> quicksilver: make a backup, then 'bzr revert <file>' 'bzr remerge --merge-type weave <file'
[17:19] <vila> >
[17:21] <quicksilver> vila: OK, expected result now.
[17:26] <quicksilver> vila: amusingly, smerge-ediff then "undoes" that improvment by automatically refining the diff when you enter ediff ;P
[17:26] <vila> :)
[18:52] <abentley> jam, james_w: recipe builds of lp:qtwebkit are causing problems because branching lp:qtwebit is taking lots of memory during the fetch.  My machine is up to 1G so far.
[18:53] <james_w> abentley, is this what was the immediate cause of the rollback of lp-buildd during UDS?
[18:54] <abentley> james_w: it seems likely.
[18:54] <abentley> james_w: Our logging isn't very good, so I can't be sure about the precise cause.
[18:55] <james_w> ok
[18:55] <abentley> bigjools believes that the large memory consumption is causing excessive swapping, which reduces responsiveness, which breaks other builders because we're doing synchronous polling.
[18:55] <james_w> abentley, I don't think it's a bzr-builder problem exactly? Just fetching with bzr shows the high memory usage?
[18:55] <jam> james_w: my direct test showed about 1gb for a "bzr branch"
[18:55] <jam> it is just a huge branch
[18:56] <jam> wide and deep
[18:56] <jam> (lots of files, lots of history)
[18:56] <abentley> james_w: yes, but maybe we can avoid the problem in bzr-builder.
[18:56] <jam> abentley: we killed the build earlier, not sure what to do right now
[18:57] <abentley> jam: VmPeak:	 1487216 kB here.
[18:57] <jam> abentley: 64bit machine?
[18:57] <jam> (I was testing on 32)
[18:57] <abentley> jam, no, 32.
[18:57] <abentley> jam, AIUI 1G is the max physical memory we can hope for.
[18:58] <jam> abentley: anyway it is arguably a bzrlib problem, but we don't have any quick-and-fast answers there
[18:58] <jam> I cut it in half for bzr 2.2, but large branches still take a lot of memory
[18:58] <jam> it is mostly the CHK stuff that is the problem
[18:58] <abentley> jam, Okay, I wasn't sure what the status was.  Thanks.
[18:59] <abentley> james_w: would it be reasonable to do lightweight checkouts instead of copying the branch?
[19:02] <james_w> abentley, we could if we analyze the recipe to check if we will do a commit as we build it
[19:03] <abentley> james_w: How do we determine whether we'll do a commit?
[19:04] <james_w> abentley, I think commits are just done after merges currently, but I can't remember for sure
[19:05] <abentley> james_w: they are done so that subsequent merges can use the correct parent information?
[19:06] <james_w> abentley, yes
[19:06] <james_w> nest-part as well now
[19:06] <james_w> so pretty much every recipe will commit
[19:07] <abentley> james_w: Okay, maybe stacked branches instead of lightweight checkouts?
[19:07] <james_w> yes, that would work
[19:07] <james_w> will that cut down memory usage in this case?
[19:07] <abentley> james_w: Okay, I'll see if that actually cuts down memory usage.
[19:08] <james_w> heh :-)
[19:08] <jam> james_w, abentley: Except for the current bug that we refuse to commit in a stacked branch because of issues with stacking and basis inventories
[19:08] <james_w> ah
[19:09] <abentley> jam, doh.
[19:09] <abentley> james_w: btw, nest-part is a partial merge, so its parent information should not be recorded.
[19:10] <james_w> abentley, I assume that is taken care of
[19:11] <abentley> james_w: Sorry, what do you mean by "nest-part as well now"?
[19:20] <james_w> abentley, nest-part does a commit after doing the work
[19:21] <abentley> james_w: I can understand that merge would do a commit after doing the work in order to allow subsequent merges to use the correct parent information.  Since nest-part cannot introduce parent information, why does it do a commit?
[19:22] <james_w> abentley, I don't know
[19:51] <mwhudson> jelmer: nothing more than was discussed here
[21:06] <BasicOSX> bzr branch remote only gives me the .bzr directory, drawing a blank on how to get the actual files to work on. Anyone help me?
[21:09] <lifeless> you've got a local notrees shared repo
[21:09] <lifeless> 'bzr checkout .' will populate a tree on a branch
[21:10] <jam> mwhudson: sorry about the email spam. I normally don't re-use branches, does it send 1 email per mainline rev?
[21:13] <mwhudson> jam: it's ok, i can ignore email pretty effectively :)
[21:13] <mwhudson> and yeah, one mail per rev
[21:22] <jam> mwhudson: do you know if there is a decent way to check if a daemon has exited? (Namely, something that is not a child so you can't waitpid() on it)
[21:23] <mwhudson> jam: not really, you can send the "signal" 0 to it if you had the pid and interpret the result
[21:24] <jam> mwhudson: this is for the test suite. the mthaddon
[21:24] <jam> noted that we needed a pid file
[21:24] <jam> so that indicated I should be daemonizing
[21:24] <jam> and I wanted to start and stop such a thing cleanly
[21:24] <jam> and have the test suite wait for it to exit
[21:24] <jam> but... not very easy to get right, from what I can tell
[21:25] <exarkun> If you rely on PIDs, then there's race conditions
[21:25] <jam> exarkun: there is, but I'm not worried about spawning 32k processes in the meantime
[21:25] <exarkun> If the daemon is listening on a unix socket, then connect attempts to that socket will begin to fail after it exits
[21:26] <exarkun> jam: It's not just processes.
[21:26] <exarkun> Maybe it's just as unlikely to have a TID collision, but I don't know how TIDs are allocated.
[21:40] <jam> mwhudson: I don't remember if you're a vim or emacs guy. Any chance you know about pyflakes + vim?
[21:41] <mwhudson> jam: i've been using emacs for ~one third of my life now :-)
[21:41] <mwhudson> jam: for the daemons, there is some hair in the launchpad code base for this already
[21:42] <mwhudson> jam: lifeless has been working on it recently, i think there is a librarianfixture somewhere you could maybe crib from
[21:42] <jam> mwhudson: I'm not sure if that is a long time or not :)
[21:42] <mwhudson> although that might be oriented around twisted daemons, come to think of it
[21:43] <jam> mwhudson: I went with a simple loop around os.kill(..., 0) and trapping ESRCH
[21:57] <jam> mwhudson: mind if I nominate you to review the updated patch?
[22:00] <mwhudson> jam: no
[22:01] <jam> mwhudson: https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386
[22:01] <jam> I don't know the specific urgency
[22:01] <jam> I can't deploy to qastaging until that is fixed
[22:01] <jam> but the l-o-s-
[22:01] <jam> are out-of-town this week
[22:02] <jam> so I may not be able to anyway,
[22:04] <mwhudson> i really hope there's some library code somewhere you could have used rather than writing all that from scratch :/
[22:04] <mwhudson> lifeless: hi
[22:05] <lifeless> hi
[22:05] <mwhudson> lifeless: i know you've been working on external process stuff for tests recently, can you look at https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/40386 ?
[22:05] <peitschie> mornin everybody :)
[22:06] <mwhudson> lifeless: and see if you know if there is library code for any of this?
[22:06] <lifeless> there is in twistd
[22:08] <mwhudson> yeah
[22:08] <mwhudson> i guess that's a "no" then really
[22:09] <jam> mwhudson: well the fork-a-daemon code was taken from a "python daemon" search and tweaked for my use case
[22:10] <jam> so I didn't have to write it completely manually
[22:10] <lifeless> mwhudson: that glue isn't what I've been working on; though I'd certainly want a Fixture wrapping it.
[22:10] <lifeless> it would be nice to have bin/run know about it too
[22:11] <mwhudson> bin/run runs the service already, but not as a daemon
[22:12] <jam> lifeless: yeah, bin/run and runlaunchpad.py know how to do it, but that isn't how they run things in production
[22:13] <jam> just one of the pain points for this experiment.
[22:17] <mwhudson> jam: might it be better to wait for the daemon to respond to hello than to write its pid file?
[22:17] <jam> mwhudson: I'm not sure i understand
[22:18] <mwhudson> jam: in TestCaseWithLPForkingServiceDaemon._start_subprocess
[22:18] <jam> are you saying the service shouldn't write its own pid file until it gets a request?
[22:18] <mwhudson> jam: no, i'm saying the test helper should wait until a request gets a response
[22:20] <jam> mwhudson: fair point, anything else?
[22:20] <millun> hi guys
[22:20] <millun> can i ask something?
[22:20] <millun> i've pushed a branch up on an FTP account
[22:21] <millun> what do i do now? (in bzr explorer)
[22:21] <jam> mwhudson: I need the pid for other reasons, but I could wait for hello and then check the file
[22:21] <millun> when i try to checkout - bzr explorer asks me like 3 times about the password
[22:21] <mwhudson> jam: it just seems that there is a tiny possibility of a race
[22:21] <mwhudson> with the current code
[22:22] <jam> millun: I believe the recommendation is to use a full branch and not to use a lightweight checkout for a remote branch
[22:22] <jam> mwhudson: where?
[22:22] <jam> I don't doubt it
[22:22] <jam> you can't use the normal "waitpid()" sort of tools
[22:22] <mwhudson> jam: just the thing we were talking about already
[22:22] <mwhudson> the daemon writes this pid before it listens on the socket
[22:23] <millun> jam,
[22:24] <millun> jam i thought at first that i need to checkout becAuse branching offered me shared repository while i need colocated
[22:24] <millun> right?
[22:24] <spiv> 'write pid file' and 'service is ready' aren't quite the same thing.
[22:24] <jam> millun: if you need collocated, you still want a local branch to checkout
[22:25] <poolie> hi mwhudson, jam
[22:25] <poolie> spiv
[22:25] <jam> spiv: well, it could be, it depends how I write the code :)
[22:25] <millun> is collocated already a property of the branch? or it matters from user to user
[22:25] <jam> millun: layout is a property of the user
[22:26] <jam> well, location
[22:27] <millun> Bind new branch to parent location? (should i check this?
[22:27] <millun> i am using colocated branches in /Var/www/projectname
[22:28] <GaryvdM> millun: A work arround to the password problem is to put the password in authentication.conf (Settings -> Credentials in bzr explorer) http://doc.bazaar.canonical.com/latest/en/user-reference/configuration-help.html#the-authentication-configuration-file-authentication-conf
[22:30] <GaryvdM> millun: I'm working on making bzr explorer/qbzr keep it connections open, so that it does not have to ask for the password so often, but this is going to take a while...
[22:32] <poolie> hi there GaryvdM
[22:32] <GaryvdM> Hi poolie
[22:32] <mwhudson> jam: i asked for a couple of small changes
[22:34] <jam> mwhudson: I was pretty sure that you need setsid() to guarantee you'll disconnect from the terminal
[22:35] <mwhudson> jam: ok
[22:35] <jam> mwhudson: http://www.itp.uzh.ch/~dpotter/howto/daemonize
[22:35] <millun> cool GaryvdM
[22:38] <millun> jam: so i need to create a shared repo in /var/www/ and branch to /var/www/projectname. instead of /var/www/projectname/trunk
[22:38] <jam> btw, hi poolie, nice to you have you back around and online
[22:39] <poolie> thanks, it's good to be back
[22:39] <poolie> we should send some news from uds while it's relatviely fresh
[22:40] <glyph> Hello!
[22:40] <millun> does it make any sense?
[22:41] <glyph> I have recently discovered that the twistedmatrix.com bzr mirror has some old revisions that were generated with an earlier version of bzr-svn ("v3" in revids, I don't know what version that corresponds to)
[22:41] <glyph> and this causes problems
[22:41] <glyph> I am wondering how I should go about fixing this
[22:41] <glyph> or rather, what the suggested 'best practice' (if there is such a thing) for dealing with data which is similarly not-quite-corrupt-but-still-problematic
[22:42] <jam> millun: I personally don't know the 'colocated' style that bzr-explorer mentions very well.
[22:42] <spiv> glyph: mwhudson looked at this yesterday
[22:42] <GaryvdM> glyph: Hello. I saw in my logs that you were looking at the fonts in qbzr. I've landed a patch in qbzr trunk to have the mono space font defined in one place.
[22:42] <jam> and I'm not sure whether you are saying it is your personal need for where it goes, or whether you are asking if it is how bzr-explorer wants it
[22:43] <glyph> GaryvdM: Yay.  Is it a place where I can customize it? :)
[22:43] <spiv> glyph: it appears to be more that the svn repo itself contains some revisions stamped with v3 revids (on trunk even)
[22:43] <glyph> spiv: oh, crap :(
[22:44] <glyph> wait a second
[22:44] <glyph> is that actually a problem?
[22:44] <GaryvdM> glyph: It now also tries to use "Monospace" before "Courier New"
[22:44] <spiv> glyph: well!
[22:44] <glyph> if they're stamped as such, presumably everyone will agree on the revid and there won't be an issue.
[22:44] <spiv> glyph: so bzr-svn presumably is helpfully preserving the v3-ness of revs before the latest rev stamped that
[22:44] <glyph> GaryvdM: even better
[22:44] <glyph> spiv: except sometimes when it isn't?
[22:44] <spiv> And assuming the better v4 format for later revs
[22:44] <jam> mwhudson: due to layering, I went with "wait for the socket to exist" rather than "wait for a message on the socket". Is that sufficient for you?
[22:45] <jam> at that point you can try to connect at least.
[22:45] <jelmer> glyph: I'm trying to reproduce the issue here, but it's taking a very long time to pull all revisions down
[22:45] <mwhudson> jam: yeah
[22:45] <spiv> glyph: but if you have an old branch from before that point it'll be v3.  Or something.
[22:45] <glyph> jelmer: well, that's the bug, innit ;)
[22:46] <glyph> spiv: Oh.  If I have an old branch from before that point it will pull it down *as v4*, because since there are new stamped revs it will just assume that branch should be the newest, goodest thing.
[22:46] <jelmer> glyph: not necessarily, I'm not sure if there's a good reason one branch is a different mapping than the other
[22:46] <glyph> ahem
[22:46] <spiv> glyph: jelmer is about 100x more of an authority on this than me of course
[22:46] <glyph> _no_ stamped revs
[22:46] <jam> mwhudson: k, pushed, and ready for your re-review
[22:46] <glyph> in that branch's history.
[22:46] <spiv> glyph: btw, r23001 in svn trunk
[22:46] <GaryvdM> glyph: No customization yet   - I would like to have code to get your desktop setting. I cant find a way to do this, so I may end up coding a version for gnone, kde, mac.
[22:46] <jam> mwhudson: my EOD. but I'll respond to anything tonight/tomorrow if you have any more feedback
[22:47] <GaryvdM> * I cant find a way to do this with qt...
[22:47] <jam> I get to take my son to "soccer" practice (for 3yr old) should be a lot of fun
[22:47] <mwhudson> jam: ok, i guess i'll throw it at ec2 land :-)
[22:47] <spiv> glyph: I'm honestly not sure at all
[22:48] <glyph> spiv: That's the behavior I'm seeing.
[22:48] <glyph> Looking at the local bzr log of these branches I've got.
[22:48] <glyph> So, probably the best thing to do practically speaking for this branch would be to destructively rebase the branch using svn ('merge forward') and then just start over
[22:49] <spiv> glyph: my wild guess is... probably?
[22:49] <glyph> it's only got one revision in it anyway, and desperately needs to be updated to be more current with trunk, so there's not a lot to lose :)
[22:50] <glyph> spiv: so, thanks for the explanation of the preserving-the-v3-ness based on revision order in SVN, that was a key clue :)
[22:50] <glyph> exarkun: you may be interested in that discussion in case you do some old twisted branches with bzr
[22:50] <exarkun> I'm less interested in discussion and more interested in tools that work
[22:51] <spiv> glyph: well, thank mwhudson more than me :)
[22:51] <spiv> exarkun: here's the short form, as I understand:
[22:51] <spiv> exarkun: land your branches faster and there'd be no problem :P
[22:51] <glyph> exarkun: oh.  #git, in that case, I guess? :P
[22:51] <exarkun> glyph: oh man.  you said it, not me.
[22:51] <spiv> I'm sure jelmer will figure out how to make it work better, though.
[22:51] <glyph> exarkun: "If you're working with a very old branch, merge it forward in SVN first, to avoid this problem."
[22:52] <glyph> I can be more specific than that, with a precise revision number, but that's a good rule of thumb.  Maybe that's what spiv meant by 'r23001'?
[22:53] <mwhudson> radix committed something to trunk with bzr
[22:54] <radix> what
[22:54] <radix> what
[22:54] <exarkun> radix: why do you always break everything
[22:54] <radix> what
[22:54] <glyph> radix: yeah man what the hell is your problem
[22:54] <radix> did I break something like three years ago
[22:54] <radix> is that what this is about
[22:54] <glyph> radix: don't worry, dash would have broken it if you hadn't.
[22:55] <mwhudson> and yeah, svn 23001 was it
[22:55]  * jelmer wonders if he should phase out file property-based bzr-svn metadata
[23:25] <GaryvdM> Good night all zzzzzz


[17:48] <rhpot1991> superm1: tgm4883 mrand dmfrey wants to report a bug for the user's groups, where should that go
[17:49] <tgm4883> the users group?
[17:50] <dmfrey> just wanted to see if dialout could be added to the main users groups by default
[17:50] <rhpot1991> he says it should be in the dial out group for access to libcec
[17:50] <dmfrey> libcec is for access to the usb cec adapters
[17:51] <dmfrey> i also noticed that the ChannelIcons storage group is not being created, so no channel icons are downloading
[17:51] <tgm4883> is that a new storage group?
[17:51] <tgm4883> I don't remember that one
[17:52] <dmfrey> i was looking into why my channel icons weren't showing on new 12.04 backend install
[17:52] <dmfrey> i guess they used to be in ~.mythtv/channels
[17:53] <dmfrey> but the documentation seems to indicate they should now be in (in mythbuntu) /var/lib/mythtv/channels and mythfrontend looks for them in the Storage group ChannelIcons
[17:53] <tgm4883> Bugs go at https://bugs.launchpad.net/mythbuntu/+filebug
[17:53] <Zinn> [bugs.launchpad.net] OpenID transaction in progress
[17:53] <tgm4883> why does libcec need dialout?
[17:54] <dmfrey> that is the group the /dev/ttyACM0 device gets created into
[17:54] <dmfrey> pulse-eight usb cec adapter
[17:54] <tgm4883> Does that group make sense for that device?
[17:57] <tgm4883> secondly, does the device need to be accessed by the frontend or backend?
[17:59] <dmfrey> not sure if it makes sense, i will ask in the pulse-eight channel if that is preferred
[17:59] <dmfrey> it is accessed in the frontend
[17:59] <dmfrey> if you don't have libcec installed, you usually see 'cecadapter.cpp:128 (Open) CECAdapter: Failed to load libcec.' in the logs
[18:06] <superm1> dmfrey: does the backend user need to be in it or the frontend user?
[18:06] <tgm4883> superm1, sounds like frontend user
[18:06] <dmfrey> frontend
[18:07] <superm1> dmfrey: hmm well the default user ubuntu creates gets put in the dialout group
[18:09] <dmfrey> weird, mine wasn't in there
[18:09] <dmfrey> this was a fresh install from sunday night
[18:16] <dmfrey> i check both my machines, fresh install from sunday night and monday morning, one is x86_64, other is 32 pae and neither have dialout in the groups
[18:16] <superm1> hmm weird, what did you install from?
[18:16] <superm1> mythbuntu ISO or ubuntu ISO or ubuntu server ISO
[18:19] <dmfrey> mythbuntu iso
[18:37] <superm1> hmm weird
[18:43] <dmfrey> ok, i had to not only add libcec but libcec-dev to get mythfrontend to recognize that libcec was installed
[18:46] <dmfrey> went looking through the cecadapter.cpp and saw the libcec headers it was trying to load which were not on my system
[18:46] <dmfrey> installing the dev package fixed that
[19:00] <tgm4883> dmfrey, I think I'm too invested in this email thread for a project I don't even work on
[19:02] <rhpot1991> tgm4883: welcome aboard
[19:04] <tgm4883> rhpot1991, yea, I'm kinda tired of people that demand things for free
[19:05] <rhpot1991> I'm tired of visual studio crashing
[19:07] <dmfrey> rhpot1991, shoot me now, haven't looked at visual studio in over 10 years :)
[19:07] <dmfrey> tgm4883, yeah, i am not sure what he thinks that will do that something like mythexport doesn't already do
[19:08] <dmfrey> plus the app would in essence have to watch the program for your in order to download and store, it would still need to kick off a hls stream
[19:08] <dmfrey> my last email pretty much says it is not gonna do it
[19:08] <tgm4883> dmfrey, I think he just wants it more integrated, which would probably be great, but would require a lot more on the app side and probably still be clunky
[19:08] <tgm4883> yea my last email basically says patches probably welcome
[19:09] <rhpot1991> I misunderstood what he was asking I guess
[19:09] <rhpot1991> I though the wanted to access recordings without transcoding
[19:10] <rhpot1991> the problem with local storage is that its anti HLS too
[19:10] <tgm4883> rhpot1991, he doesn't want to wait for transcoding
[19:10] <tgm4883> so no mythexport, yes HLS
[19:10] <rhpot1991> in theory we could prob wget it all, modify the playlist and have it pull from local
[19:10] <dmfrey> i am not sure that you could record the hls stream to a file in java anyway
[19:10] <rhpot1991> playlist isn't done until the transcoding is done too
[19:10] <tgm4883> dmfrey, could you just store the file chunks?
[19:10] <rhpot1991> so you can't pull till everything is done
[19:11] <tgm4883> as rhpot1991 said, store the m3u8 file, alter it for local playback of the file chunks, and be on your way?
[19:12] <rhpot1991> not a great solution due to things I just said though
[19:12] <tgm4883> rhpot1991, I don't like the timeframe of it, taking super long to actually get the files needed
[19:12] <tgm4883> rhpot1991, I think it's perfectly fine though size wise
[19:12] <dmfrey> tgm4883, i don't think so, since they are offloaded to an external player
[19:13] <rhpot1991> tgm4883: ya I thought he wanted no transcoding which leads to huge files
[19:13] <tgm4883> dmfrey, well what do you do right now? You download the m3u8 file and hand it to VIDPLAYER?
[19:13] <tgm4883> rhpot1991, no he wants HLS to transcode it
[19:13] <rhpot1991> tgm4883: ya
[19:13] <rhpot1991> get the playlist via the api call
[19:13] <tgm4883> rhpot1991, even then, except for nexus devices I don't think size matters ;)
[19:13] <rhpot1991> pump that to the player
[19:13] <rhpot1991> who handles the rest
[19:14] <rhpot1991> tgm4883: well even if you max out with a 32gb card
[19:14] <rhpot1991> thats maybe 2-3 large recordings
[19:14] <rhpot1991> I was going to explore doing some local non transcoding with google tv possibly
[19:14] <tgm4883> rhpot1991, I think that is probably all you need, but if you HLS transcode it you should get more
[19:14] <rhpot1991> if you are local and it can handle your content no reason you need ot transcode
[19:15] <tgm4883> rhpot1991, dmfrey so what if you download the m3u8 file to a cache dir, edit it, then hand it over to VIDPLAYER?
[19:15] <rhpot1991> tgm4883: its built as the transcoding happens I believe
[19:15] <rhpot1991> so you'd have to wait till all transcoding was done
[19:15] <rhpot1991> get it then, modify, use
[19:15] <dmfrey> but soon they will be introducing an ondemand hls
[19:15] <tgm4883> ondemand?
[19:15] <dmfrey> you will literally be able to jump to a specific spot in the program
[19:16] <tgm4883> isn't it already on demand?
[19:16] <tgm4883> ah
[19:16] <dmfrey> it will all be coded into the rest endpoint
[19:16] <tgm4883> that will be nice :)
[19:16] <dmfrey> including video size, bitrate, etc
[19:16] <tgm4883> then you could do what netflix does I'm guessing
[19:16] <tgm4883> adjusting bitrate on the fly?
[19:16] <dmfrey> pretty much
[19:16] <dmfrey> could possibly
[19:16] <dmfrey> until i see it, i am not sure
[19:16] <dmfrey> probably be in on .27
[19:17] <tgm4883> I'm assuming there is still file storage though on the backend for HLS transcodes
[19:17] <dmfrey> if not .28
[19:17] <dmfrey> i assume so. in the streaming storage group
[19:18] <dmfrey> now that i think about it, we could probably make the app kick off a hls stream, so that it pre-transcodes on the backend, then you can come to it whenever you want
[19:18] <dmfrey> right now we start it, wait, then play it
[19:18] <dmfrey> when done, we kill the stream
[19:18] <dmfrey> on the backend
[19:19] <tgm4883> yea I think the main issue is the transcoding time
[19:19] <dmfrey> could almost implement a watch it later feature so it is already transcoded on the backend
[19:19] <dmfrey> then should be able to ff and rew
[19:19] <dmfrey> that might be something to think about
[19:19] <dmfrey> i gotta get my data loading issues solved first
[19:20] <dmfrey> so its not so slow for people
[19:20] <tgm4883> dmfrey, if you did a watch it later feature, you could make that a prerequiset of 'download locally"
[19:20] <dmfrey> true
[19:21] <tgm4883> so with the data loading issues, you are pulling the entire schedule?
[19:21] <dmfrey> not sure if the myth services api allows for downloading the .m3u8 files themselves
[19:21] <dmfrey> the first time through, i load each day at a time, then parse it to a db
[19:21] <tgm4883> is that really necessary?
[19:21] <dmfrey> that is for implementing a youtube like search from the action bar
[19:22] <tgm4883> hmm
[19:22] <dmfrey> like mythweb does it
[19:22] <dmfrey> i don't want to be constantly accessing the the backend
[19:22] <dmfrey> my thought now is to download hour chunks  and store them as json
[19:23] <dmfrey> use that for the program guide when you page through the hours and days from local files
[19:23] <tgm4883> dmfrey, well, I only think you need it locally if you want to have offline searching
[19:23] <tgm4883> which I don't think is needed
[19:23] <dmfrey> implement etag into them so i know when data changes to redownload a chunk here and there
[19:23] <tgm4883> what if there was a services API for searching the schedule?
[19:23] <dmfrey> i didn't find one
[19:24] <tgm4883> right, I meant if one was added
[19:24] <dmfrey> maybe it will be added, but don't think that is available now
[19:24] <tgm4883> probably right
[19:24] <tgm4883> similar to the "list titles" being unavailable
[19:25] <dmfrey> in the /Guide services, you can get the program guide, get details for a particular program, or the channel icon
[19:25] <dmfrey> yeah
[19:25] <dmfrey> maybe in the /Dvr GetFilteredProgramList, but that might be for just what you have recorded already
[19:25] <tgm4883> yea that is just what is recorded already
[19:26] <tgm4883> and that returns way too much info IMO
[19:26] <dmfrey> so, following android design guidelines, download data locally, store in content provider, only access network when needed
[19:27] <tgm4883> ah
[19:27] <dmfrey> pretty much to save battery, etc.
[19:27] <tgm4883> that changes things
[19:27] <dmfrey> global search needs content provider
[19:27] <dmfrey> so if i keep the files locally, i can use them, parse them when needed, etc.
[19:27] <dmfrey> setup alarm tasks to delete old stuff
[19:28] <dmfrey> and, once etag is publicly available, can use that to determine of the network resource changed and only download when needed
[19:29] <dmfrey> i like json for local storage because i can parse that in java much faster than xml
[19:30] <dmfrey> plus for the program guide i put in the latest version, the data is already structured in the format i need to move through that pager
[19:31] <dmfrey> and have been reading up on managing some caches of files for quicker ui/ux response
[19:31] <dmfrey> could prove to be quite a fast interface
[19:32] <dmfrey> so basically when you start the app, start downloading the data chunks in the background and let you do whatever you want in the app
[19:32] <tgm4883> right, which makes sense
[19:32] <dmfrey> however, you will only be able see the data up to the point where you downloaded it
[19:32] <dmfrey> which i think is acceptable
[19:32] <tgm4883> which I think is reasonable
[19:32] <dmfrey> since it will eventually fill in everything
[19:35] <tgm4883> exactly
[19:35] <tgm4883> so probably just grab the more often used stuff first
[19:35] <tgm4883> probably schedules last
[19:36] <dmfrey> right
[19:49] <rhpot1991> ignore where type == reality tv
[19:49] <rhpot1991> populate with breaking bad instead
[19:49] <dmfrey> :)
[23:17] <kenalex> hello


[00:43] <hallyn> rbasak: great, thanks
[01:52] <patdk-lap> heh, I always set dedicated ipmi interface, set static ipmi ip
[01:52] <patdk-lap> normally fixes up those issues
[02:19] <sarnold> patdk-lap: even for the home lab?
[02:26] <patdk-lap> expecially
[02:26] <patdk-lap> I'm running 7 vlans currently here at home
[02:27] <patdk-lap> none of that is a lab though
[02:38] <sarnold> none of my switches can do vlan, heh
[02:39] <sarnold> I've never learned enough about vlans to see it as a priority, so i've never spent the extra money
[02:39] <patdk-lap> I don't own a switch that doesn't do vlans
[02:40] <patdk-lap> swapping the current one out soon, for a poe model
[02:42] <patdk-lap> crap, this unbound issue I have, is still present as a bug :(
[07:48] <frickler> jamespage: coreycb: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1567811
[07:48] <jamespage> frickler, oh good spot!
[07:57] <smb> jamespage, if possible maybe depend loosely on both variants. Would be nice to have something like "provides" aliases for services. But I cannot find anything
[07:58] <jamespage> smb, we only have libvirt-bin in Ubuntu right?
[07:58] <smb> jamespage, right now, but it might change in future when we get rid of more delta
[07:59] <jamespage> smb, sure - we can switch when we do that :-)
[08:00] <smb> jamespage, of course :) but still a pain to always think of the implications if say backporting into cloud-archive
[08:00] <smb> for sysvinit scripts it was at least possible to say this provides libvirt-bin and libvirtd... but rather useless nowadays
[08:41] <frickler> jamespage: smb: if you want to add Alias=libvirtd.service to libvirt-bin.service, that would also work, just tested that variant
[08:42] <jamespage> frickler, that's a nice backwards compat feature
[08:43] <smb> Yeah... wondering why I did not see that in the systemd.service doc
[08:44] <smb> jamespage, would you know whether hallyn has some other things queued or shall I wait till he comes around to sync up
[08:44] <jamespage> smb,  not sure tbh
[08:44] <jamespage> smb, I'd wait for hallyn
[08:44] <smb> jamespage, ack
[08:44] <jamespage> smb, I'd also say that this is not critical for xenial
[08:44] <jamespage> hmm - well not from openstack's perspective
[08:45] <jamespage> I have no idea about other systemd units that might be dependening on libvirtd
[08:45] <smb> jamespage, hard to say. just if there is an "Alias" option that should not break anything existing while resolving anything we do not know about
[08:46] <jamespage> smb, yah so maybe it does make sense for compat with direct syncs from debian
[08:46] <jamespage> smb, shall I raise a libvirt task for that bug as well?
[08:47] <smb> jamespage, That is what we usually tried to maintain (for build dependencies and in sysvinit, just did not know about alias for systemd). yeah I think makes sense. probably can be lesser prio as you fix nova
[08:52] <bvi> anyone experience with ServeRAID M5120 in jbod mode?
[08:52] <bvi> installer doesn't even boot when this hba in in the server (lenovo x3650m5)
[08:55] <smb> frickler, Just to confirm: under which section did you add the alias? Install?
[08:57] <frickler> smb: yes, then disable/enable the service once in order to create the symlink
[08:58] <smb> frickler, ok, thanks
[09:09] <bvi> err M5210 .... damn typo
[09:09] <frickler> would it make sense to change to upstream connection of https://launchpad.net/ubuntu/xenial/+source/nova to mitaka instead of essex?
[10:53] <frickler> jamespage: https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1567881
[12:30] <BlessJah> ubuntu seems to completely ignore preseed file I provide
[12:32] <BlessJah> In syslog I can see file has been loaded properly, but I cannot get any directive working, it still asks me questions that has been answered
[13:13] <frickler> jamespage: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1567935 is my final one for today, but https://bugs.launchpad.net/neutron/+bug/1567923 might also be interesting for you
[13:27] <supNow> just upgraded ubuntu server to 14.04 and I'm getting a grub_term_highlight_color not found error. google search suggests it can't find grub but I havn't found any real information on how to fix.
[13:28] <supNow> From reading it's saying that it can't find the bootloader. I have booted into a live session from a usb drive. Is there an easy way to fix it from there? Or should I try to boot into ubuntu-server using grub from the usb drive?
[13:30] <hateball> !fixgrub | supNow
[13:32] <supNow> @hateball it was actually ubuntu-server upgrade. There is no windows. Will that same thing work though that you linked?
[13:35] <hateball> supNow: Yes, it just tells you how to reinstall grub
[13:35] <supNow> ok great, thanks
[13:47] <coreycb> jamespage, we're not going to be able to sync magnum at this point in the cycle as it needs a big bump to python-docker
[13:47] <hallyn> smb: queued up for libvirt? i got nothing
[13:47] <ddellav> coreycb swift is ready for review/push lp:~ddellav/ubuntu/+source/swift
[13:48] <coreycb> ddellav, ok
[13:48] <jamespage> coreycb, 1.5.0 not good enough?
[13:48] <jamespage> coreycb, we may want the new version anyway - jgrimm - thoughts ^^ ?
[13:48] <coreycb> jamespage, not according to requirements.txt
[13:48] <smb> hallyn, k, I sent you a patch as well as have pushed a branch to lpgit. don't think its urgent now that nova got fixed
[13:49] <jgrimm> jamespage,  syncing magnum?
[13:49] <jgrimm> or bumping up python-docker?
[13:49] <coreycb> jgrimm, python-docker
[13:49] <jamespage> jgrimm, no syncing python-docker - we're right up to date with docker so we may actually want that right?
[13:50] <jgrimm> yes, we are at latest upstream
[13:50] <jgrimm> not sure if python-docker is that current tho?
[13:51] <jgrimm> docker.io-1.10.3 is what we carry.
[13:51] <coreycb> jgrimm, it's a bit behind, we're currently at 1.5.0 and it looks like they're up to 1.8.0 upstream
[13:52] <hallyn> smb: you didn't push to the xenial branch?
[13:53] <smb> hallyn, no, though I could have I guess. I used a smb/xenial one
[13:57] <jgrimm> coreycb, indeed 1.5.0 sounds quite long in the tooth.   I'm not seeing anything in their docs that gives me a warm fuzzing on what versions of docker their client supports?
[13:58] <jgrimm> coreycb, but i'd think you'd be better off moving up, though testing needed
[14:10] <kaffien> i ran a do-release-upgrade and ended up on 16.04.  Now our veeam setup cannot contact the NFS shares.  Is there something i need to configure on my ubuntu server to allow that again?
[14:12] <kaffien> veeam cannot connect to the SSH server i have running either
[14:12] <kaffien> but i can via a ssh client  on that same workstation.   nmap shows all the appropriate ports are open.
[14:12] <kaffien> nm wrong channel
[14:28] <coreycb> jamespage, ddellav: all of the final mitaka release packages are uploaded to xenial for mitaka now (sans the magnum sync)
[14:31] <jgrimm> \o/
[15:38] <ppetraki> if I use an lxd profile to limit the number of cpus to say 2. /proc/cpuinfo is showing two cpus, but lscpu is showing all the host cpus. Is that the intended behavior? http://pastebin.ubuntu.com/15690427/
[15:39] <patdk-wk> yes
[15:39] <patdk-wk> the kernel restricts what cpu's things can run on
[15:40] <patdk-wk> but it doesn't go around limiting the view of the physical hardware
[15:40] <ppetraki> ah ok
[15:41] <ppetraki> thanks
[15:45] <sdeziel> ppetraki: /proc/cpuinfo of the container is a lxcfs mount showing just the CPUs that you have enabled for that host
[15:50] <nacc> ppetraki: lscpu is looking in /sys/ in contrast, iirc
[15:58] <tiblock> Hi. I have ubuntu 14.04 server with 20GB on / and some logs files ate everything and i was not able to lauch anything so i removed about 18gb logs but `df -h` says only 300mb free, `ncdu` says 2.1gb used. Tryed to do `tune2fs -m 5 /dev/...` but its not helping. How to get space back?
[15:59] <tiblock> Oh, it just jumped to 9.8gb free... Okay. Problem kinda solved itself. Still missing about half but 9.8gb its okay.
[15:59] <nacc> tiblock: might need to issue a `sync;sync` if you deleted a ton of files
[15:59] <nacc> tiblock: it would probably be better to figure out what log exploded
[16:00] <lordievader> tiblock: Restart your loging service, it probably still has a link open to those files, thus they are still on disk.
[16:00] <tiblock> nacc, after `sync;sync` still says 8.8gb used and i fouln log, my own application made it, forgot to add folder to logrotate. I deleted that logs.
[16:01] <nacc> tiblock: ah ok, yeah i'd check lsof or as lordievader said
[16:01] <nacc> tiblock: in case it's being held open
[16:01] <nacc> `du -h` at the appropriate level might give you a better idea of what is consuming space rather than `df`
[16:02] <tiblock> Ah i see, `lsof` shows<PHONE_NUMBER> byte log file opened and says `(deleted)`. Okay, there is my space. Thank you very much!
[16:03] <tiblock> Awesome! After restart of that application i got all my space back.
[16:03] <tiblock> 2.2gb used
[16:05] <nacc> tiblock: nice, yeah, it was presumably still ref'd so couldn't be fully removed from disk (just unlinked from the fs effectively)
[16:06] <lordievader> You can do lovely tricks with this...
[16:08] <nacc> lordievader: "lovely" :)
[16:13] <sdeziel> nacc: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1556308 was approved for upload when you get a chance
[16:14] <nacc> sdeziel: ack, i don't have upload rights :)
[16:14] <nacc> sdeziel: hence sponsors is subscribed
[16:14] <sdeziel> oh didn't know.  The Ubuntu delta should be kept minimal
[16:17] <patdk-wk> figured cron restart would be a temp fix, nope :(
[16:18] <patdk-wk> ah, I'll look
[16:18] <sdeziel> patdk-wk: latest Debian and soon Ubuntu will use the package helper which now calls unbound-anchor with a full path. Only unbound-checkconf will need fixing making it a oneliner
[18:16] <ppetraki> before first install lxd, I configured my own bridge, bridge0 (via nm) and made that the default bridge. Then I created a new profile called scaleout, which when used makes my containers use lxcbr0, which doesn't even exist. Even claims there's an IP address, which is unreachable. That's a bug right?
[18:44] <sarnold> ppetraki: that does sound like a bug; iirc there's a way to tell lxd which bridge to use (it's liable to be a different mechanism than whatever you used to mark yours 'default') -- but it feels funny that it then reports unreachable IPs
[19:03] <ppetraki> sarnold, well, I told it not to even make the lxcbr0 (whatever the default bridge is) to begin with, it physically doesn't exist. So it's like the new profile, which I created from scratch decided to inherit a device config without telling me. It gets better, when I take the 'device' config from default and insert it into my new profile, those containers now have no interface.
[19:04] <ppetraki> sarnold, about to retest on a fresh vm, I'll keep you posted
[19:05] <sarnold> ppetraki: note that recent lxd changes have switched to using lxdbr0 by default, among other bridge-related changes https://launchpad.net/ubuntu/+source/lxd/+changelog
[19:06] <sarnold> ppetraki: it may be worth mkaing sure your image has the 2.0.0~rc9-0ubuntu3 release..
[19:18] <ppetraki> sarnold, ok, I have that release installed. the default config isn't getting my bridge. http://pastebin.ubuntu.com/15696446/  . just installed this vm from scratch
[19:20] <sarnold> ppetraki: probably one for stgraber ^^^
[19:20] <ppetraki> sarnold, ... and if I restart the lxd service it's there :)
[19:20]  * ppetraki sees if it can use it
[19:20] <sarnold> hunh
[19:21] <ppetraki> sarnold, http://pastebin.ubuntu.com/15696528/
[19:22] <stgraber> ppetraki: either you're on an old packaging which doesn't restart lxd-bridge for you or your lxc profile command ran right before the change is effective
[19:22] <sarnold> ppetraki: try the ps aux again after sudo service lxd start; iirc it's a socket-activitated thing
[19:22] <ppetraki> stgraber, just installed the whole distro an hour ago
[19:22] <stgraber> ppetraki: ok, so chances are that if you ran that lxc profile command again a second later it would have been right
[19:22] <ppetraki> stgraber, see http://pastebin.ubuntu.com/15696446/
[19:23] <stgraber> ppetraki: ok, so yeah, you are on the latest, which means that the change very likely was applied a few ms after you ran that lxc profile command
[19:24] <stgraber> ppetraki: profile changes can only be applied after the daemon is started so the very first query you do may return the old config. We do however hold container startup until the config was updated so you can't race it and start a container with the old bridge.
[19:26] <ppetraki> stgraber, I'm not the fastest typist in the world, perhaps a few seconds passed between the start and me asking for the profile. In either case, it's easy enough to sleep a sec or restart the service before continuing.
[19:26] <stgraber> ppetraki: lxd is socket activated
[19:27] <stgraber> ppetraki: so the first lxc command you run will start it, it won't be running until then
[19:27] <ppetraki> stgraber, ah, right, the new systemd stuff
[19:27] <ppetraki> ok
[19:27] <stgraber> so if the first command you run is "lxc profile show default" then it very likely will show you the old values
[19:27] <ppetraki> stgraber, I'll just poll for the right keys to show up then
[19:27] <stgraber> if it's the second command you run, it should be fine as the profile update script is very quick and starts immediately when the API is available
[19:28] <sarnold> is there a do-nothing command that'll start it that would be a nice first command to run?
[19:28] <stgraber> ppetraki: why do you need to wait?
[19:28] <stgraber> sarnold: lxc finger
[19:28] <sarnold> stgraber: looks perfect :)
[19:29] <ppetraki> stgraber, I don't. Just like you said, if I run the lxc command again it should have reflect the correct profile
[19:29] <sarnold> ppetraki: try: 'lxc finger ; lxc profile show default' and see if that's the results you expect
[19:29] <ppetraki> stgraber, so when I script this, I'll just call that and wait until bridge0 actually shows up in the config
[19:29] <stgraber> ppetraki: well, my question is more, why do you need to check that bridge0 made it in there?
[19:29] <ppetraki> stgraber, its correct
[19:30] <ppetraki> stgraber, about to create a bunch of containers with it via script
[19:30] <stgraber> ppetraki: if the next thing you do is launch a container, lxd will already wait for profile config updates to be done before actually starting it
[19:30] <ppetraki> so I want it to be correct
[19:30] <ppetraki> stgraber, ok, I will try that, less work, better
[19:31] <stgraber> yeah, we sure didn't want users running "lxc launch ubuntu:14.04 blah" as their first command and that picking up the wrong bridge, so we do have logic to avoid that very problem :)
[19:32] <ppetraki> I'm sure. It's just that I just spent a hour or so working with a slightly older version that wasn't as well behaved. So I got a little paranoid
[19:32] <stgraber> we just can't do the same with the profile API as the profile update script itself needs the API to be functional to update the config :)
[19:32] <stgraber> ah yeah, that particular fix was introduced in rc9
[19:32] <ppetraki> stgraber, good stuff so far, it looks like it'll suit us well. passing through kernel devices was fun
[19:33] <stgraber> :)
[19:33] <ppetraki> now to get the rest of the stack up
[19:37] <ppetraki> stgraber, ugh, check this out. it's like the default profile isn't the default. http://pastebin.ubuntu.com/15696865/
[19:37] <stgraber> ppetraki: nope, you're just not reading this right :)
[19:37] <ppetraki> of course!
[19:37] <stgraber> ppetraki: it's listing you the interfaces INSIDE the container
[19:38] <stgraber> ppetraki: ubuntu:x/amd64 is pretty dated (last beta) so it still has lxcbr0
[19:38] <stgraber> ppetraki: if you were to use ubuntu-daily:x/amd64 you wouldn't see that interface anymore
[19:38] <sdeziel> stgraber: nested lxc ?
[19:38]  * ppetraki switches images
[19:38] <stgraber> sdeziel: yeah, it's showing the lxcbr0 that's running inside the container as we have lxd pre-installed in cloud images
[19:39] <sdeziel> makes sense, thanks
[19:40] <sarnold> owwwww
[19:40] <sarnold> now my head hurts
[19:42]  * patdk-wk is so far happy with lxc, though, it kindof annoying to adjust my apparmor profiles for it
[19:43] <patdk-wk> or is there a better way to *stack* apparmor profiles
[19:43] <patdk-wk> think I use changehat :(
[19:44] <patdk-wk> ah, used aa_change_profile
[19:45] <tyhicks> patdk-wk: the Xenial kernel has support for stacking AppArmor profiles
[19:45] <sarnold> patdk-wk: I -think- that just landed..
[19:46] <patdk-wk> ya, I'm using 16.04
[19:46] <sarnold> patdk-wk: .. dunno if lxd has adapted yet
[19:46] <tyhicks> patdk-wk: the required userspace changes will hopefully land within the next few days
[19:46] <tyhicks> sarnold: no, they haven't
[19:46] <patdk-wk> I found out my profile change didn't work, so I created a lxc profile + my changes
[19:46] <patdk-wk> then adjust the lxc profile to allow that profile to be used
[19:46] <patdk-wk> worked for now, just seems like a bit of extra work
[19:46] <patdk-wk> ok
[19:46] <tyhicks> patdk-wk: you'll (hopefully) soon have aa_stack_profile() in Xenial's libapparmor
[19:47] <patdk-wk> so that will only work when running lxc 16.04 guests?
[19:47] <patdk-wk> but not 14.04 right?
[19:47] <patdk-wk> unless backport libapparmor somehow
[19:47] <sarnold> the stacks would be managed by the 16.04 lts system; i'd expect it to work..
[19:48] <tyhicks> patdk-wk: it'll require a 16.04 host
[19:48] <tyhicks> patdk-wk: note that lxc/lxd integration for stacked profiles is not in place yet
[19:48] <patdk-wk> oh
[19:49] <tyhicks> patdk-wk: as long as you have a 16.04 host, it should work with any ubuntu container, including 14.04
[19:49] <patdk-wk> so the inside will call normal aparmor call, and it will be adjusted to a stack call?
[19:49] <patdk-wk> I think that is what I don't get :)
[19:49] <patdk-wk> ok :)
[19:49] <tyhicks> the container setup code in the host will change to aa_stack_profile() (or simply adjust policy)
[19:50] <tyhicks> inside the container, nothing needs to change
[19:50] <patdk-wk> well, I have a good test for it when it's ready atleast :)
[19:50] <tyhicks> great :)
[19:50] <patdk-wk> updating my profiles for 16.04 was fun, so many new things I can limit :)
[19:51] <tyhicks> :)
[19:51] <sarnold> :D
[21:04] <ppetraki> stgraber, I guess I can't call this from a container? mlockall( MCL_CURRENT|MCL_FUTURE ); our process doesn't want to be swapped out
[21:05] <stgraber> ppetraki: I'm guessing that's a privileged call so not for unprivileged containers
[21:06] <stgraber> ppetraki: you could try to make the container privileged though (lxc config set NAME security.privileged true && lxc restart NAME)
[21:06] <ppetraki> stgraber, can I make it a privledged container?
[21:06] <stgraber> at which point root in the container will be real root outside of it, so unless the kernel is being weird because of cgroups and stuff, this should work
[21:09] <ppetraki> stgraber, that's working
[21:10] <ppetraki> it got further, and then I ran out of space :). good, it looks like it's getting the resources it needs
[21:47] <Velus-universe> hello im folling this https://help.ubuntu.com/community/PostfixVirtualMailBoxClamSmtpHowto and i get to  this bit Make Dovecot listen for authentication requests and it says the code needs to be updated for newer version? can someone help me with this bit please?
[21:54]  * patdk-lap wonders why it wouldn't work
[21:56] <Velus-universe> https://help.ubuntu.com/community/PostfixVirtualMailBoxClamSmtpHowto#Configure_Dovecot shows a pre and post 12.4 setup and they look different, i cant figure out how it needs to be changesd
[21:59] <Velus-universe> patdk-lap, would you bhe able to help me with this please
[22:00] <patdk-lap> http://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
[22:01] <patdk-lap> though, you still need the passdb and userdb sections
[22:05] <Velus-universe> patdk-lap, would the service auth be like this then http://pastebin.com/EMuMbmnN
[22:07] <patdk-lap> remove executable
[22:07] <patdk-lap> remove user
[22:08] <patdk-lap> and the example you are following uses auth-client instead of auth
[22:08] <Velus-universe> ok
[22:09] <patdk-lap> dunno why they are having you use cram-md5, that is horrible
[22:10] <Velus-universe> ok patdk-lap ifd i remove the user and that it reuses connection
[22:14] <patdk-lap> odd, I don't have it
[22:17] <Velus-universe> i got it working now anyway, now i just need to ad mx records to my domain name but i forgot how to do them lol
[22:18] <patdk-lap> just mx?
[22:18] <patdk-lap> if you plan to send email you should have ptr, spf, and maybe dkim
[22:18] <Velus-universe> yeah i will be doing them in a bit but i need to figure out how to do the mx i will be setting up the ptr and spf after the mx
[22:19] <conrmahr> Can you format a disk with a RAID array on UBNTU server?
[22:19] <patdk-lap> conrmahr, what does that even mean?
[22:20] <conrmahr> I know I'm an idiot
[22:20] <conrmahr> I took an 4TB WD Red Drive from a Synology DiskStation
[22:21] <conrmahr> and installed it on a computer runnning Ubuntu Server but it can't mount it.
[22:21] <patdk-lap> well ya
[22:21] <patdk-lap> no one claims synology uses some standard raid/filesystem that ubuntu understands
[22:21] <conrmahr> Can I just erase and format it to ext4?
[22:21] <patdk-lap> I personally have no idea what they use
[22:21] <patdk-lap> sure
[22:22] <conrmahr> yeah that's what i want to do
[22:22] <sarnold> patdk-lap: i'd always had the impression that it was dm-raid with ext4; iirc they even use ecryptfs for their encrypted storage
[22:22] <patdk-lap> dunno
[22:22] <sarnold> but their own 'magic raid" thing may be different, non-standard..
[22:22] <conrmahr> f-synology
[22:22] <conrmahr> im sick of it
[22:22] <patdk-lap> most of them use mdadm/dm-raid
[22:22] <conrmahr> i just want to run my own Ubuntu server
[22:22] <patdk-lap> some of them, heh, don't
[22:23] <patdk-lap> I know mine uses raid-3d
[22:25] <patdk-lap> believe it was made by ibm
[22:25] <Velus-universe> patdk-lap, i have done the mx record now yay
[23:51] <conrmahr> Can anyone help me format a HDD on Ubuntu server with a raid array?
[23:52] <nacc> conrmahr: you mean you want to use SW RAID with the partitions of a single HDD?
[23:53] <conrmahr> i just remove everything from a HDD and start fresh with a clean ext4 partition
[23:54] <nacc> conrmahr: ok, maybe just restate what you are trying to do?
[23:55] <conrmahr> Yes I have a computer with a 60GB SSD with Ubuntu Server on it
[23:55] <conrmahr> I want to install a 4TB WD Red HDD as a secondary
[23:56] <bekks> And where is that raid array then?
[23:56] <conrmahr> but that WD HDD is from a Synology NAS which was formated with a RAID array
[23:56] <bekks> So you need to put a new primary partition table on it.
[23:56] <bekks> Do you use UEFI?
[23:56] <conrmahr> yes
[23:57] <conrmahr> i think i've tried but it says it's "in use"
[23:57] <bekks> You've tried what?
[23:57] <conrmahr> with 'parted"
[23:57] <conrmahr> new primary partition
[23:57] <bekks> UEFI has no primary partitions.
[23:58] <bekks> you are still trying to use legacy mode.
[23:59] <conrmahr> i'm pretty sure my BIOS is UEFI
[23:59] <conrmahr> let me check