[01:25] <menn0> thumper, waigani: I just did a "juju destroy-environment local --yes  --force" to 2 env JES both of which had new LXC containers coming up and the containers were left behind
[01:26] <menn0> known limitation until the new env descruction stuff happens?
[01:26] <waigani> hmmm...
[01:26] <thumper> menn0: known...
[01:26] <waigani> menn0: thanks for the heads up, I'll add it to my things to manually test
[01:26] <thumper> menn0: I can explain...
[01:26] <thumper> not surprising
[01:27] <thumper> which is why we want to tell people to use system destroy
[01:27] <thumper> and environment destroy
[01:27] <thumper> not destroy-environment
[01:27] <menn0> cool
[01:27] <menn0> just making sure it was a known thing
[01:28] <thumper> I'll explain when I'm not shoveling food in my mouth
[01:29] <menn0> I can pretty much guess where the problem is so no rush
[01:42] <menn0> thumper: i thought I just finished the state pool stuff but it seems i've made the state server panicky
[01:42] <menn0> thumper: I think I know why though
[01:49] <thumper> menn0: did you want to hop on a call to hear why destroy-environment --force is evil?
[01:50] <menn0> thumper: sure
[01:50] <thumper> menn0, waigani: https://plus.google.com/hangouts/_/canonical.com/evil
[02:11] <waigani> thumper: http://reviews.vapour.ws/r/2250/, cheers
[02:15] <sinzui> thumper: "destroy-environment --force" is  eveil  because it circumvents blocks, leaves resources behind, and users report bugs that juju did exactly as they told it to do?
[02:15] <thumper> for JES it is evil because it doesn't contact the api server, and just destroys the system environment, leaving all hosted environments running but headless
[02:16]  * thumper goes to make a coffee urgently
[02:16] <sinzui> thumper: ouch, but --force also circumvents the api server, which is why my blocks can be ignored
[02:23] <thumper> sinzui: yes, it doesn't even try
[02:23] <thumper> sinzui: the new system destroy and environment destroy commands do try
[02:24] <sinzui> thumper: hurray for sanity
[03:13] <menn0> thumper: if you have time: http://reviews.vapour.ws/r/2445/
[03:13] <menn0> thumper: i'm really happy with how this worked out
[03:13]  * thumper looks
[03:30] <thumper> menn0: mostly good, just concerned about reordering the defer calls
[03:31] <menn0> thumper: hmmm I wasn't intending on reordering them
[03:31]  * menn0 checks
[03:32] <thumper> you moved them all into a single function that is deferred
[03:32] <thumper> but then still call defer on each of the internals
[03:32] <thumper> and you changed the order
[03:32] <thumper> effectively reorering
[03:32] <menn0> but defers run inside out
[03:32] <thumper> either reorder and don't defer
[03:32] <thumper> or defer
[03:33] <thumper> yes
[03:33]  * menn0 does a quick check on play
[03:33] <thumper> happy to talk through
[03:34] <menn0> thumper: I think I did the right thing: http://play.golang.org/p/fzFmAHa86q
[03:34] <menn0> sorry
[03:34] <menn0> hang on
[03:35] <menn0> thumper: this one: http://play.golang.org/p/S4ehts8JxY
[03:36] <thumper> menn0: but you did version three in http://play.golang.org/p/2d9vMgldxc
[03:36] <menn0> thumper: I see what I screwed up
[03:36] <menn0> all the defers in the new func shouldn't be there
[03:36] <menn0> i'm an idiot
[03:36] <thumper> right
[03:36] <menn0> thumper: my eyes were not seeing the inner defers
[03:37] <menn0> man I was trying to make that code clearer and unintentionally made it much worse
[03:37] <thumper> :)
[03:39] <menn0> thumper: i saw the bit about env.Life ! state.Alive too
[03:39] <menn0> i'll fix that in a followup PR
[03:39] <menn0> it's not really related to this change
[03:40] <menn0> I think the condition should still be there, but as: else if env.Life() == state.Dead
[03:41] <thumper> hmmm...
[03:41] <thumper> nope
[03:42] <thumper> because we may want to get logs from a dead environment
[03:42] <thumper> prior to everything being deleted some time later
[03:42] <menn0> thumper: hmm ok
[03:46] <thumper> the dying / dead aspects should stop us adding things to the environment
[03:46] <thumper> but we need to be able to view / introspect it while it is dying
[03:46] <thumper> and after it is dead
[03:46]  * thumper looks in the morgue
[03:46] <menn0> thumper: but remmeber we've removed most of the assertions on env life
[03:47] <menn0> thumper: I guess the critical places, like adding a machine still check
[03:47]  * menn0 wishes you could edit past IRC comments :)
[03:49]  * menn0 pushes the StatePool PR
[03:50] <thumper> right
[03:50] <thumper> dead / dying environments can't get new machines or services
[03:50] <thumper> everything else needs a machine or service
[03:50] <menn0> can't get storage either i'm pretty sure
[03:50] <thumper> although in the coming future we should also check environment level network spaces and storage
[03:50]  * thumper nods
[03:51]  * thumper has to head into town briefly
[03:51] <thumper> bbl to review waigani's branch
[03:51]  * menn0 has to swap his UK driver's license for a NZ one
[03:53] <thumper> gee menn0
[03:53] <thumper> jumping the merge gun
[03:53] <thumper> :)
[03:53]  * thumper does a post hoc shipit
[03:53] <menn0> thumper: sorry... missed there wasn't one there already
[05:18] <menn0> thumper: if you have time: http://reviews.vapour.ws/r/2446/
[08:52] <dimitern> dooferlad, TheMue, morning
[08:52] <dooferlad> dimitern: hello!
[08:52] <dimitern> dooferlad, TheMue, can you have a look at http://reviews.vapour.ws/r/2448/ please?
[08:53] <dooferlad> dimitern: on it
[08:53] <dimitern> dooferlad, cheers
[08:54] <dooferlad> dimitern: we really need to get better at splitting cosmetic changes from functional changes :-|
[08:54] <dooferlad> dimitern: or get a better diff viewer!
[08:55] <dimitern> dooferlad, yeah, when there's no deadline to catch :)
[08:55] <dooferlad> dimitern: :-)
[08:59] <dimitern> dooferlad, also, if you can give it a spin on EC2 - bootstrap, space list, space create, subnet add, subnet list (with juju subnet -- debug .. if needed), subnet add with CIDR and/or ProviderId
[09:00] <dimitern> dooferlad, --constraints spaces= does not cause errors in my tests, but obviously doesn't yet respect them
[09:01] <dooferlad> dimitern, TheMue: hangout
[09:02] <dimitern> dooferlad, omw, getting coffee
[09:04] <TheMue> dooferlad: omw, got coffee
[09:52] <dooferlad> dimitern: do you have a moment for EC2 testing?
[09:52] <dimitern> dooferlad, sure
[09:53] <dooferlad> dimitern: https://ide.c9.io/dooferlad/juju
[09:53] <dooferlad> TheMue: ^^ if you want to join in
[09:53] <TheMue> dooferlad: having phone, come in a few moments
[09:54] <dimitern> dooferlad, omw
[10:47] <TheMue> dimitern: btw, would you like a feature flag for the spaces support? like for address allocation? that way we could turn it on and off in tests with dummy.
[10:48] <dimitern> TheMue, nope, we need another way to turn it on and off - e.g. having a "broken" method is one way
[10:49] <TheMue> dimitern: ok
[10:49] <dimitern> TheMue, or a flag settable by calling dummy.SetSupportsSpaces(bool)
[10:52] <TheMue> dimitern: a direct method needs that you have direct access to the provider. often it is hidden deeply in our embedded tests. so I prefer the "broken" approach
[10:54] <dimitern> TheMue, I'm fine with either - it's the same effort I think
[10:55] <TheMue> dimitern: in first implementation yes, in tests I really liked the indirect approach - here with feature flag, but broken is fine too - during the tests
[12:54] <mattyw> axw, https://github.com/juju/juju/pull/3072/files#diff-aa7f5128113461cdc1ee5c2335a09d6cR52
[13:26] <frankban> ericsnow: I replied to your requests at http://reviews.vapour.ws/r/2416/ could you please take another look?
[13:36] <sinzui> dimitern: master wasn't merged into net-cli. your branch failed. Master now has singnigicant divergence and we don't know if it is good.
[13:37] <sinzui> dimitern: I am not sure what to recommend. test master and hope for a pass, then test the updated net-cli to get a pass?
[13:39] <natefinch> finally got my code working... now to remove 100 printfs
[13:47] <dimitern> sinzui, we merged master this morning
[13:48] <dimitern> sinzui, and I have a PR which hopefully solves pingerSuite.TestAgentConnectionDelaysShutdownWithPing and MachineSuite.TestManageEnvironRunsInstancePoller
[13:48] <sinzui> dimitern: excellent. master just started testing. I will make net-cli the most important branch to test next. I am setting CI to wait 8 hours if there is a failure to give people time to investigate and retry failures cause by subtrates
[13:49] <dimitern> sinzui, awesome
[13:56] <dimitern> dooferlad, TheMue, please have a look http://reviews.vapour.ws/r/2454/
[13:57] <TheMue> dimitern: yep
[13:57] <dooferlad> dimitern: on it
[13:57] <dimitern> cheers guys!
[13:59] <wwitzel3> ericsnow, natefinch, katco: hangout working for you guys?
[13:59] <katco> was in one half an hour ago
[13:59] <ericsnow> wwitzel3: yep
[14:00] <katco> ericsnow: moonstone working fine
[14:00] <natefinch> wwitzel3: make sure it's having you join with your canonical account
[14:02] <TheMue> dimitern: reviewed
[14:08] <dimitern> TheMue, ta!
[14:09] <dooferlad> dimitern: done
[14:09] <ericsnow> cmars: is this what I think it is?  http://reviews.vapour.ws/r/2453
[14:10] <cmars> ericsnow, yep
[14:10] <ericsnow> cmars: cool!
[14:10] <cmars> :)
[14:11] <dimitern> dooferlad, thanks!
[14:14] <ericsnow> cmars: at least it got reviewed <wink>
[14:20] <cmars> ericsnow, we're going to re-review it in greater detail next week. important to get it landed for now to get CI testing, but it won't be glossed over. all other PRs have been reviewed carefully
[14:20] <ericsnow> cmars: oh, I don't doubt that :)
[14:21] <ericsnow> cmars: thanks for getting it done!
[14:21] <cmars> ericsnow, wasn't me, really. axw & wallyworld are the heroes
[14:23] <ericsnow> cmars: ah, right; commit history FTW :)
[14:25] <dimitern> TheMue, I'm not sure what's your last comment about? adding a comment in the patched function checking the result of newWorker?
[14:26] <TheMue> dimitern: only adding comments I missed when creating this test. that FinishedWorker means the Addresser doesn't run while not FinishedWorker means it's the Addresser (sadly not direct testable)
[14:27] <TheMue> dimitern: but it's only maintenance cosmetic, for later
[14:28] <TheMue> dimitern: maybe we should add a worker.HasFinished(w worker.Worker) bool for it soon, when those tests get more. will keep it in mind for the Firewaller
[14:30] <dimitern> TheMue, I see, ok I'll add comments about the meaning of a FinishedWorker as a result
[14:30] <dimitern> dooferlad, about your comment
[14:30] <dimitern> dooferlad, I don't believe the issue is related to clock time
[14:31] <dooferlad> dimitern: oh, I thought you were increasing the timeout
[14:34] <dimitern> dooferlad, yeah, but your comment caused me to think of a different approach
[14:34] <dimitern> dooferlad, using attempt loops we don't have to sleep explicitly
[14:52] <ericsnow> frankban: I'm reading through your responses to my review right now :)
[14:52] <frankban> ericsnow: ty!
[15:35] <niemeyer_> Hey all
[15:36] <natefinch> howdy niemeyer_
[15:36] <niemeyer_> Do we have any envs with MongoDB deployed on IPv6?
[15:37] <natefinch> there was talk about that on the mailing list.  I think the answer is that it needs work, i.e. not really working currently, though I don't know the details.
[15:54] <mgz> cmars: hey, are you around
[15:55] <ericsnow> frankban: thanks for the thoughtful responses to my review comments
[15:56] <ericsnow> frankban: I see where you're coming from now
[15:58] <frankban> ericsnow: cool, thank you, reading your review
[15:59] <ericsnow> frankban: BTW, good call on making the JSON field tag "yaml" :)
[16:03] <ericsnow> frankban: my only remaining concern is about adding the "guiserver" methods to the "public" API facade
[16:05] <frankban> ericsnow: yeah I was looking at that
[16:05] <frankban> ericsnow: the GUI is really just a user client, and I am not sure about having a separate facade for the GUI because the GUI basically uses all the Client methods already (including the mega-watcher)
[16:06] <frankban> ericsnow: actually I think the GUI is the most used juju API client after juju itself ;-)
[16:06] <ericsnow> frankban: :)
[16:07] <ericsnow> frankban: I think it would be good to at least have methods like GetBundleChanges on a separate facade
[16:07] <frankban> ericsnow: so the GUI is JS connecting the ws, it needs the user to authenticate and all the endpoint it uses are in the client facade (excpet for the initial admin.login one)
[16:07] <ericsnow> frankban: ah
[16:08] <ericsnow> frankban: that's fine
[16:08] <frankban> ericsnow: so basically like this the change is transparent, the GUI connects and sends requests over the ws, and GetBundleChanges is one request like many others (ServiceDeploy etc.)
[16:09] <ericsnow> frankban: so one goal is to minimize changes to the GUI client code?
[16:10] <frankban> ericsnow: yes, and we can adjust things later if the amount of GUI specific endpoints increases, but I don;t believe so
[16:10] <ericsnow> frankban: using multiple facades on the same WS should be fine, no?
[16:10] <ericsnow> frankban: k
[16:10] <frankban> ericsnow: thanks
[16:12] <ericsnow> frankban: I still think there should be a bit more discussion (on juju-dev) about where methods like GetBundleChanges should live in the API
[16:13] <ericsnow> frankban: but moving the code to a more appropriate place later (if needed) wouldn't be hard
[16:13] <frankban> ericsnow: I agree, but consider this is merging into a feature branch, I think we will be able to introduce these changes gradually, and rick_h_ is already working on this
[16:13] <ericsnow> frankban: how urgent is it that GetBundleChanges land?  Could it wait a few days?
[16:13] <ericsnow> frankban: oh, duh
[16:13] <frankban> ericsnow: this is not landing in trunk
[16:14] <ericsnow> frankban: feature branch :)
[16:14] <ericsnow> frankban: I'll give you a ship-it but encourage you to at least ask jam and fwereade about it :)
[16:15] <ericsnow> frankban: oh, and there are some missing tests
[16:15] <frankban> ericsnow: thanks! yes this will be a long running branch and with rick_h_ we are already working on getting people aware of our goals and the changes to be made for the embedded gui story
[16:15] <frankban> ericsnow: which ones? back to reading the review
[16:15] <rick_h_> ericsnow: there's a spec with this work out to wallyworld and jam atm
[16:16] <rick_h_> ericsnow: we're waiting on feedback but with holidays and such we're moving forward with the feature branch with the caveat that things will be tweaked based on feedback
[16:16] <ericsnow> rick_h_: cool!
[16:16] <rick_h_> ericsnow: as you mention, moving the endpoint isn't really going to make/break anything here.
[16:16] <rick_h_> ericsnow: https://docs.google.com/document/d/1zZY0a-dby-VnrBXaoFARIN8Mj6pdXLeZzTXmH0mRUik/edit in case it helps at all or you're curious
[16:16] <ericsnow> rick_h_: yep :)
[16:17] <rick_h_> ericsnow: but we're definitely eager for core folks to know/udnersteand what's up and where things are headed as we want to make sure we're doing thigns by the book, that your folks feel comfy with fixes that might be required later/etc.
[16:18] <rick_h_> ericsnow: so please feel free to push back on anything you would to another core team
[16:18] <ericsnow> rick_h_: sounds good; I'll be sure to read through the spec
[16:18] <rick_h_> ericsnow: ty, any feedback is welcome. I ran thumper through it last night
[16:18] <ericsnow> rick_h_: you can count on me to speak up :)
[16:18] <rick_h_> ericsnow: and we look forward to the other when they're back on duty
[16:18] <rick_h_> :)
[16:18] <frankban> ericsnow: GetBundleChanges is tested in apiserver/client/bundles_test.go
[16:20] <ericsnow> frankban: hmm, we're trying to move away from full-stack tests like that
[16:20]  * ericsnow looks at tests for other API methods (on server and client)
[16:20] <frankban> ericsnow: thanks
[16:23] <ericsnow> frankban: blech, our existing tests aren't very good examples :/
[16:23] <frankban> :-/
[16:24] <ericsnow> frankban: for an example of unit-ish tests see apiserver/backups and api/backups
[16:25] <ericsnow> frankban: "feature" tests (effectively integration tests) live in the top-level featuretests package
[16:26] <ericsnow> frankban: we're making an effort to improve our approach to testing in core which is why I'm bringing all this up
[16:27] <frankban> ericsnow: sure, I made a note and I'll take a look on Monday
[16:27] <ericsnow> frankban: coolio
[16:27] <frankban> ericsnow: thanks and have a nice weekend
[16:28] <ericsnow> frankban: you too and thanks for working on this!
[19:15] <natefinch> ericsnow: this id/name thing is killing me
[19:15] <ericsnow> natefinch: how so?
[19:17] <natefinch> ericsnow: just the fact that sometimes we munge the name/id and sometimes we don't.... and so I have to know exactly when to munge the name/id to match what's stored in whichever map
[19:17] <ericsnow> natefinch: we should always be identifying them by the full ID
[19:18] <ericsnow> natefinch: where in particular are we not?
[19:19] <natefinch> ericsnow: but what is the full ID and where do I get it from?  This is the problem I have with untrack.    So the current problem is getting the test infrastructure to do the right thing when I tell it to untrack.... which is actually kind of a problem in itself that we have logic in the test infrastructure
[19:20] <natefinch> ericsnow: like stubAPIClient
[19:21] <natefinch> ericsnow: https://github.com/natefinch/juju/blob/untrack-cmd/process/context/base_test.go#L287
[19:21] <ericsnow> natefinch: the user should have passed in the full ID (or the name, by which we look up the full ID)
[19:22] <natefinch> ericsnow: the user doesn't know what the full ID is, since that's a composed thing which we create, isn't it?  They know the name... I don't think they can possibly be expected to know anything else
[19:23] <ericsnow> natefinch: that's fine; we just have to do the lookup for them
[19:24] <natefinch> ericsnow: my point is... the fact that we're doing all this logic stuff in stubAPIClient is bad.  We're duplicating production code logic, and relying on this test harness to have the same implementation.
[19:25] <ericsnow> natefinch: the API client shouldn't be doing any of that lookup
[19:25] <ericsnow> natefinch: I thought we agreed that we would hold off on that part
[19:25] <ericsnow> natefinch: i.e. the API client should always expect full IDs
[19:26] <natefinch> ericsnow: I'm talking about this - https://github.com/natefinch/juju/blob/untrack-cmd/process/context/base_test.go#L201
[19:26] <natefinch> ericsnow: that's logic that is duplicating what the real apiclient would be doing
[19:29] <ericsnow> natefinch: setNew is just a convenience function to inject values into the API
[19:30] <ericsnow> natefinch: it's not part of the stubbed API implementation
[19:33] <natefinch> ericsnow: Ahh, I was missing a flush in there... I didn't expect that to make a difference, but it does.  Sorry.
[19:34] <ericsnow> natefinch: np :)
[20:37] <natefinch> ok, everything works... now to merge wwitzel3's rename commit :/
[20:44] <natefinch> oh this is gonna suck
[20:45] <natefinch> evidently git is not smart enough to merge <file renamed> with <file modified>   .... how is that not something it can just do automatically?
[20:45] <natefinch> "oh hey, the old file just got moved, so I'll merge the changes into the new location" :/
[20:46] <ericsnow> natefinch: yeah, I just went through that pain yesterday
[20:48] <natefinch> google/stack overflow to the rescue....  git rebase feature-proc-mgmt -X rename-threshold=5%
[20:49] <natefinch> ....mostly
[21:09] <katco> can i get a rubber-stamp on http://reviews.vapour.ws/r/2455/? this exact patch has already been landed in 1.24
[21:16] <perrito666> katco: done
[21:16] <katco> perrito666: ty sir
[21:16] <perrito666> since I reviewed the other one I believe you :)
[21:17] <katco> haha
[21:23] <perrito666> I must say, buying an electric toaster is a life changing decision, I no longer forget and burn my toasts
[21:24] <perrito666> (which mostly happens while reading this channel or reading code of juju)


[00:07] <cjohnston> jc bug 725352
[00:07] <ubot2> Launchpad bug 725352 in ubuntu "Title bars are gone on 11.04" [Undecided,New] https://launchpad.net/bugs/725352
[00:07] <cjohnston> jcastro: ^ :-(


[02:06] <Keybuk> refactoring is such great fun
[02:27] <ion_> Heh
[02:28] <AlexExtreme> why's that? :)
[02:37] <Keybuk> cleaned up event.c a little bit
[02:37] <AlexExtreme> cool
[02:37] <Keybuk> got rid of the evily named EventEmission structure
[02:38] <Keybuk> (that's now just Event)
[02:38] <Keybuk> (and what was Event is now EventInfo)
[02:38] <Keybuk> also added some ref-counting stuff, so we can keep Event information around after it's been handled (since it populates environment, etc.)
[02:42] <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070520120917-6yanaj1t0a1ej3zd?start_revid=scott%40netsplit.com-20070520121451-6273as3mqxmumuai#init/job.c
[02:49] <ion_>          * should be releaed and the event should be freed.
[02:49] <ion_> test_event.c
[03:00] <Keybuk> :-)
[03:00] <Keybuk> next thing to figure out is what the difference between Jobs and States means
[03:02] <Keybuk>  * should they be configured in different directories?
[03:03] <Keybuk>    or should they be the same, just without processes specified
[03:03] <Keybuk>    - if different, how do we avoid name clashes?
[03:03] <Keybuk>    - if the same, how do we prevent "start STATE" from working?
[03:03] <Keybuk>      and what happens if you turn a file from a job to a state or vice-versa?
[03:05] <AlexExtreme> if it's the same, can't you prevent start STATE from working by having init work out whether it is a state, and if it is chuck back an error and bail out?
[03:05] <AlexExtreme> or is it not possible to work out?
[03:07] <ion_> Perhaps the use cases should be considered to determine that.
[03:07] <ion_> That is, what Keybuk said.
[03:21] <Keybuk> what I want to avoid is having the entire Job structure around for a State
[03:21] <Keybuk> otherwise, what's the difference?
[03:21] <Keybuk> I can see two easy ways to do that
[03:21] <Keybuk> one is to have a states hash, as well as a jobs hash, and have something evil in cfgfile.c that returns State instead of Job if there's no processes configured, etc.
[03:22] <Keybuk> but you'd then have to look in both hashes all the time
[03:24] <Keybuk> the other way would be to get rid of the jobs hash
[03:24] <Keybuk> instead have a "registry"
[03:24] <Keybuk> that'd probably have several levels
[03:24] <Keybuk> 1) configuration directory (e.g. /etc/??, ~/.??, etc.)
[03:25] <Keybuk> 2) filename
[03:25] <Keybuk> 3) state or job found there
[03:25] <Keybuk> and hash at (3)
[03:25] <Keybuk> that way, a file that defines both a state and a job (ie. an ordinary job) would be able to used as either a state or a job
[03:25] <Keybuk> but a file that defined just a state could only be used as a state
[03:25] <Keybuk> also that makes -HUP easy ;P
[03:26] <Keybuk> and I could move all the "replacement" stuff into that
[03:27] <Keybuk> (though when do you replace a State file?)
[04:30] <Keybuk> I guess the major question is: does it make sense to let sysadmins manually start/stop a "state" ?
[04:30] <Keybuk> e.g. if you've defined "user-can-login" as a state
[04:31] <Keybuk> (or writable-filesystem, filesystem-and-networking, etc.)
[04:38] <AlexExtreme> i don't think it makes sense, really. they aren't processes, so you should really be able to start/stop them. and if you have a case where a state hasn't really been reached, yet the sysadmin still starts it, it could cause some problems
[04:39] <AlexExtreme> so in the long run it'd be less problematic, IMO
[04:40] <ion_> I cant think of a state a sysadmin would need to start or stop manually. I cant think clearly with this flu in addition to my usual symptoms, though. :-)
[04:41] <Keybuk> hmm
[04:41] <Keybuk> so better question, should you be able to have a pre-start and/or post-stop script for a state?
[04:46] <AlexExtreme> hmm
[04:46] <AlexExtreme> i'm not sure...
[04:46] <AlexExtreme> i can't really think of a use case for that
[04:47] <ion_> How about having a process ping a remote host every once in a while and set a network-reachable state based on the pong?
[04:47] <AlexExtreme> at the moment we can create a job without a main process, just a pre-start and post-stop. are those states or are they still jobs?
[04:48] <Keybuk> exactly
[04:49] <Keybuk> use case: runlevel-2 state that sets utmp on the way in?
[04:49] <AlexExtreme> hmm
[04:49] <AlexExtreme> yes
[04:49] <Keybuk> user-can-login state that removes /etc/nologin on the way in, touches it on the way out?
[04:49] <AlexExtreme> yep
[04:50] <Keybuk> I can think of examples that are "nice"
[04:50] <Keybuk> and can't think of any counter-reasons why it should be forbidden
[04:50] <ion_> Yeah, definitely.
[04:50] <AlexExtreme> yep
[04:54] <Keybuk> which means that "State" would need the same internal state machine as "Job"
[04:54] <Keybuk> along with the ability to define processes, and their environment
[04:54] <Keybuk> so the difference between a state and a service is purely semantic
[05:06] <Keybuk> that makes things much easier, since it answers the questions like how to decide when to replace a state definition with one from an updated config file
[05:07] <ion_> Defining states just as jobs without a main process follows the KISS principle.
[06:00] <Keybuk> yeah
[06:07] <keir> i have a possibly rude question: how long until upstart begins shrinking boot time via parallel process start, etc?
[06:07] <AlexExtreme> it already can do
[06:07] <AlexExtreme> it'll *probably* be available in ubuntu 7.10
[06:10] <keir> i don't mind long boots on my desktop, but they are killer on my laptop
[06:10] <keir> especially since suspend is broken
[06:10] <Keybuk> it's interesting how hating the first normally co-incides with being affected by the 2nd :p
[06:11] <keir> heh
[06:11] <keir> i dream of fresh-install XP SP2 boot times for ubuntu
[06:11] <keir> now that os boots fast!
[06:12] <Keybuk> only the first time ...
[06:12] <cortana> but if you add up all the times you _have_ to boot it, i wonder which one eats a larger chunk of one's life
[06:16] <keir> true! but i used to run it on my laptop for old games
[06:16] <keir> i only had FF and the games installed
[06:16] <keir> i always got very jealous when it would boot up in 15 seconds or so
[06:17] <cortana> it's a good thing that winodws boots in about 20-25 seconds
[06:17] <cortana> i have to reboot about 3-4 times ususally to get my keyboard to work
[06:18] <Keybuk> Upstart's primary goal isn't to make boot faster
[06:18] <keir> Keybuk, i know
[06:18] <Keybuk> it's too make it more reliable and robust
[06:18] <cortana> there is a totally random 75% chance that my keyboard will _not_ work on any given boot into xp :(
[06:18] <Keybuk> as well as provide more flexibility for what's actually running
[06:18] <keir> Keybuk, it'd be great if that was a side effect :)
[06:18] <Keybuk> we just happen to also think it will speed it up
[11:01] <quitte> hi. has anyone tried compiling upstart using uclibc? I get this error:child.c: In function 'nih_child_poll': child.c:141: error: 'WEXITED' undeclared (first use in this function) WNOWAIT is also undeclared
[12:10] <quitte> now I'm getting undefined reference to `inotify_add_watch. do you happen to know what is missing in uclibc for that,too?
[12:12] <Keybuk> sys/inotify.h
[12:13] <quitte> hmm. that should comefrom the kernel, not uclibc?
[12:14] <Keybuk> the libc still has to define the syscall
[12:14] <quitte> ah
[12:20] <quitte> it's already there. what is this nih thing?
[12:23] <Keybuk> it's the standard library that upstart uses
[12:23] <Keybuk> like glib, or something


[01:24] <mpt> I propose that each time someone visits their own +karma page, their karma drops by 10 points
[01:24] <LaserJock> :-)
[01:25] <Kmos> hehe
[01:26] <LaserJock> mpt: karma -= $bigheadpoints
[01:27] <mpt> What does "-=" mean?
[01:28] <LaserJock> karma = karma - $bigheadpoints
[01:29] <jamesh> in place subtraction
[01:30] <Kmos> :)
[01:30] <Kmos> mpt: u're not a coder
[01:30] <Kmos> hehe
[01:31] <Kmos> karma-=rand() % 10;
[01:31] <Kmos> hehe
[01:37] <mpt> oh, decrementing
[01:38] <mpt> LaserJock, in the beta interface everyone has a bighead, so decrements for everybody
[01:41] <LaserJock> mpt: :(
[01:42] <LaserJock> mpt: speaking of big heads, in beta I now see a hackergotchi in 2 places
[01:43] <Kmos> LaserJock: maybe in the left top corner will be the hackergotchi
[01:43] <Kmos> and not in the right
[01:43] <LaserJock> mpt: but the one in the upper left looks really crowded, at least on my page
[01:43] <Kmos> anyone knows?
[01:43] <Kmos> :)
[01:43] <mpt> LaserJock, we're currently discussing appropriate sizes for the graphics in each place
[01:44] <mpt> Kmos, the one in the upper left appears on all your pages. The one on the right appears only on your Overview page.
[01:44] <Kmos> yep
[01:45] <Kmos> the upper left one won't be replaced by hackergotchi of each user?
[01:45] <mpt> Kmos, it should be already
[01:45] <LaserJock> it is now
[01:45] <mpt> try uploading one and see
[01:46] <Kmos> i've one
[01:46] <Kmos> let's check my page
[01:47] <mpt> kiko, I think bug 89183 should be Critical, because it's quite common, and appears to prevent people from using Launchpad (though they can get around it with URL-hacking, that's not obvious). What do you think?
[01:47] <Ubugtu> Malone bug 89183 in launchpad "beta URLs don't redirect to production if person is not in beta team" [High,Confirmed]  https://launchpad.net/bugs/89183
[01:47] <LaserJock> +1 for that
[01:48] <LaserJock> I keep forgetting when I'm pasting
[01:49] <dsas> heh ditto.
[01:50] <Kmos> https://beta.launchpad.net/~gothicx/
[01:50] <Kmos> it's on the right
[01:56] <Kmos> i think yes :)
[03:16] <Ubugtu> New bug: #93565 in malone "Launchpad compresses white-space in middle of input" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93565
[03:22] <nowhere_man> I did not follow any news about it, so I don't know: has LP's source code been released?
[03:24] <jamesh> nowhere_man: no.
[03:24] <jamesh> nowhere_man: we've released a few of the base components (e.g. the CVS/Subversion import code), but probably not the bits you are aftrer
[03:26] <nowhere_man> OK, is there any long-term plan for a release?
[03:28] <jamesh> nowhere_man: I can't give you an answer better than what's in the faq: https://launchpad.net/faq
[03:29] <nowhere_man> oh sorry, I didn't see there's a FAQ (LP is quite unresponsive at the moment)
[03:29] <nowhere_man> I'll check it, thanks
[03:33] <Kmos> cya tomorrow
[05:56] <Ubugtu> New bug: #93585 in launchpad-bazaar "codebrowse atom feeds expose vostok hostname" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93585
[06:49] <lifeless> review meeting in 10
[07:01] <lifeless> review team meeting
[07:02] <spiv> Oh, already.
[07:02] <lifeless> 5pm
[07:02] <jamesh> kind of
[07:03] <BjornT> hi
[07:04] <lifeless>     *
[07:04] <lifeless>       Roll call
[07:04] <lifeless>     *
[07:04] <lifeless>       Next meeting
[07:04] <lifeless>     *
[07:04] <lifeless>       New raw SQL coding standard - RobertCollins
[07:04] <lifeless>     *
[07:04] <lifeless>       Queue status.
[07:04] <lifeless> meh
[07:04] <lifeless> that sucked
[07:06] <lifeless> anyhow, good to see we're all here
[07:06] <lifeless> so, next meeting, one week, same time ?
[07:06] <spiv> I like this time.
[07:06] <BjornT> i can't make it next week, i'll be travelling at that time.
[07:07] <lifeless> BjornT: are you not travelling a reasonable delta from this time? or the day
[07:09] <BjornT> lifeless: i'll probably take the whole monday off as a holiday. if not, i could probably start working at 0900UTC
[07:11] <lifeless> W
[07:11] <lifeless> We'll hold it without you, thats fine;
[07:11] <lifeless> just add your apologies :)
[07:11] <BjornT> sure :)
[07:12] <lifeless> so, new coding standard - has that been resolved on the list ?
[07:12] <lifeless> or is it still in debate ?
[07:13] <BjornT> i think it's been more or less resolved, hasn't it?
[07:13] <spiv> I wonder if we can apply the randomise order hack to non-SQLObject SELECT queries?
[07:14] <BjornT> basically, make sure that tests get a reliable order. if the ui needs the same order, place the order by in sql, otherwise sort the results in the tests.
[07:14] <lifeless> yeah, I think that was consensus
[07:14] <jamesh> that's the rule of thumb I use
[07:14] <lifeless> I've added roughly that to the LaunchpadHackingFAQ
[07:14] <lifeless> perhaps one of you could see if it parses right ?
[07:14] <jamesh> i.e. don't test the order of a result set unless the order of the result set is worth testing
[07:15] <lifeless> jamesh: thats a good way to phrase it
[07:15] <spiv> brb, phone
[07:17] <lifeless> in a related thing, rinchen added this to the tipsforreveiwers: 'Please make sure that fmt:date and fmt:datetime becomes the standard usage everywhere, UNLESS there is a really good argument for just using fmt:datetime.'
[07:17] <lifeless> I can't parse that properly, I'm guessing there was a transcription error somewhere.
[07:17] <lifeless> anyone know more ?
[07:17] <jamesh> Mark sent an email about this
[07:17] <BjornT> yeah, he probably meant that we should use the new formatters sabdfl added
[07:18] <jamesh> but he was suggesting fmt:approximatedate, iirc
[07:18] <BjornT> fmt:approximatedate and fmt:displaydate
[07:18] <lifeless> jamesh: perhaps you can ensure that https://launchpad.canonical.com/DatetimeUsageGuide documents this ?
[07:19] <lifeless> and then we can remove the code policy from tips for reviewers
[07:19] <lifeless> so that we have policy for date time in the one place :)
[07:19] <jamesh> good idea
[07:20] <jamesh> Joey also posted an email about "tips for reviewers - review implementation for consistency across Pillars"
[07:20] <jamesh> I am not sure what that means though
[07:20] <lifeless> Yeah
[07:20] <lifeless> neither am I, or stub.
[07:20] <lifeless> I've mailed him directly explaining that I'm confused, and added a note about that.
[07:20] <jamesh> maybe we'll get clarification when he starts work today
[07:21] <lifeless> I noticed the wiki updates on saturday, hopefuly I wasn't too abrupt in my emails :). It felt a little weird to see several in-strange-place-hard-to-understand updates happening all at once.
[07:21] <jamesh> I'm guessing it is along the lines of "if it works for distributions, it should work for products"
[07:21] <jamesh> and vice versa
[07:22] <lifeless> so whole swathes of the ui don't hold that true
[07:22] <spiv> back.
[07:22] <lifeless> i.e. branches are asymmetric
[07:22] <lifeless> and bugs
[07:22] <jamesh> yep
[07:22] <jamesh> bugs work for products and distros
[07:22] <lifeless> and distroreleases
[07:22] <lifeless> but not projects
[07:23] <BjornT> bugs work for projects
[07:23] <jamesh> distroreleases are roughly equivalent to product series
[07:23] <lifeless> do they? for some reason I thought that you could not target a bug at a project, only a product
[07:23] <jamesh> that's true
[07:23] <jamesh> you can list the bugs for a project though
[07:23] <lifeless> right
[07:24] <BjornT> lifeless: sure. you can't target a bug to a project, but there's is a 'report a bug' on the project page
[07:24] <lifeless> I don't mean 'are not functional', I mean 'are asymmetric'
[07:24] <jamesh> BjornT: it is missing from the actions portlet
[07:24] <lifeless> which is a break of '"if it works for distributions, it should work for products"'
[07:24] <jamesh> lifeless: well, there isn't really an analogue of projects for distributions
[07:25] <lifeless> jamesh: can I rope you in to check my lphackingfaq update ?
[07:25] <jamesh> distribution is roughly equivalent to product
[07:25] <lifeless> jamesh: distro <-> project distrorelease <-> product :)
[07:25] <lifeless> its kinda morphed from that these days
[07:25] <lifeless> I'm oooold skool
[07:25] <BjornT> what about product series? :)
[07:25] <jamesh> lifeless: I'd say distro <-> product and distrorelease <-> productseries
[07:26] <lifeless> jamesh: I'd have said source package <-> productseries, or something like that.
[07:27] <jamesh> lifeless: you can draw similarities there too, but then I'd say DistributionSourcePackage <-> Product and SourcePackage <-> ProductSeries
[07:28] <lifeless> BjornT: did I miss the minutes for the wednesday review meeting last week ?
[07:29] <BjornT> lifeless: seems like you did. i did send them to launchpad-reviews.
[07:29] <lifeless> BjornT: did you link them to the agenda wiki page ? :)
[07:30] <BjornT> lifeless: ah, i might have forgot that :)
[07:30] <lifeless> BTW they should be sent to launchpad@ as well as launchpad-reviews.
[07:30] <BjornT> ok, didn't know that.
[07:30] <lifeless> SteveA asked for that, so that the whole team knows what reviewers are planning/doing.
[07:30] <BjornT> sounds reasonable
[07:33] <lifeless> ok, review queue status
[07:33] <lifeless> I've not assigned stuff yet today, doing ater ther meeting
[07:33] <lifeless> 27 items
[07:33] <jamesh> I've sucked in the last week, but will send off Mark's review today.
[07:34] <spiv> That's ok, after the meeting I'm planning on powering through all the stuff in my queue.  It's mostly small, and I've already started on david/launchpad/vcs-import-sync-status.
[07:34] <lifeless> 8 more than one week open (up one from last week).
[07:34] <lifeless> ok.
[07:35] <lifeless> I'll do a nag on my thursday if its not significantly improved then
[07:36] <lifeless> ok, I think thats all.
[07:36] <lifeless> jamesh: I'm putting the following down as action item:
[07:36] <lifeless> * Jamesh to check Roberts update of LaunchpadHackingFAQ, and update the DatetimeUsageGuide page to match Marks UI policy (And remove from TipsForReviewers when done).
[07:36] <lifeless> jamesh: thanks
[07:37] <lifeless> 5
[07:37] <jamesh> lifeless: I'm rewriting it to not just refer to Raw SQL
[07:37] <lifeless> jamesh: excellent
[07:37] <spiv> Yes, I think TipsForReviewers ought not repeat things that all devs are expected to know.
[07:37] <lifeless> spiv: right
[07:37] <jamesh> rather note that you need to be more careful of raw SQL, since the randomisation isn't done there
[07:37] <lifeless> I think Rinchen wanted to get the message across
[07:37] <spiv> jamesh: I wonder if we could make that happen, though...
[07:38] <jamesh> spiv: once we switch to $NEWORM, hopefully there will be less reason to use raw SQL ...
[07:38] <lifeless> and isn't aware of how all our documentation sits together
[07:38] <spiv> That's true.
[07:38] <jamesh> although $NEWORM doesn't support randomisation yet
[07:40] <lifeless> we should make that happne
[07:40] <lifeless> :)
[07:40] <jamesh> yep
[07:40] <spiv> We ought to write a test about it, so that $NEWORM won't work for us until we have it ;)
[07:40] <lifeless> sweet
[07:40] <lifeless> what degree of confidence do we want on it ? :)
[07:41] <lifeless> jamesh: ping me tomorrow about your new branches please, I got busy.
[07:47] <jamesh> lifeless: lphackingfaq entry updated
[07:47] <lifeless> thanks!
[08:25] <Ubugtu> New bug: #93606 in launchpad-bazaar "Better reporting of SFTP permission errors" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93606
[08:46] <Ubugtu> New bug: #93609 in launchpad-bazaar "Better error messages for bzr lp://" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93609
[10:00] <Ubugtu> New bug: #93630 in malone ""Binary package hint" is a mysterious term" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93630
[10:17] <Ubugtu> New bug: #93614 in launchpad "OpenPGP keys: Keys pending validation: Never get the e-mail" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93614
[10:35] <Ubugtu> New bug: #93637 in rosetta ""Your browser languages" doesn't do anything useful" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93637
[11:42] <Nafallo> mrevell: hi!
[11:42] <mrevell> Nafallo: Hi
[11:43] <Nafallo> mrevell: I promise not to take screenshoots :-)
[11:43] <mrevell> Nafallo: Cool, thanks :) I'll add you to the team. When you have a moment, it'd be helpful if you could reply to my email.
[11:44] <mrevell> Nafallo: Okay, you're now in the team!
[11:44] <Nafallo> mrevell: oh, you've sent another one? or just confirm there to? :-)
[11:45] <mrevell> Nafallo: I sent an email asking you to confirm that you won't take screen shots of the beta interface.
[11:45] <mrevell> Nafallo: But I assume that's why you just pinged me here :)
[11:45] <Nafallo> mrevell: sure was. but I can reply aswell ;-)
[11:45] <mrevell> Nafallo: Thanks :)
[11:46] <mrevell> Nafallo: If you have any questions, please ask.
[11:46] <mrevell> Nafallo: You'll automatically be redirected to the beta interface, but you can disable that for two hours at a time, on the standard Launchpad home page
[11:48] <Nafallo> wow
[11:48] <Nafallo> this rocks! :-)
[12:58] <cprov> good morning !
[12:58] <Hobbsee> hiya cprov
[02:24] <Nafallo> hi again :-)
[02:25] <Nafallo> I'm translating in Rosetta and would like to propose to have the bar with Next and Last etc both on top and on bottom... is that possible? :-)
[02:25] <Nafallo> I have to scroll all over the place if I don't want to make changes now :-P
[02:31] <Kmos> i agrre :)
[02:31] <Kmos> agree
[02:31] <matsubara> Nafallo: bug 52806
[02:31] <Ubugtu> Malone bug 52806 in rosetta "interface: "next" should be at the bottom, too" [Medium,Confirmed]  https://launchpad.net/bugs/52806
[02:31] <Nafallo> kewl. I'll subscribe then :-)
[03:36] <kiko> ahoy there!
[03:50] <ddaa> ahoy kiko
[03:51] <kiko> how's it going david
[03:51] <ddaa> kiko: can you move https://beta.launchpad.net/debian-cd/main to obsolete-junk, please?
[03:51] <kiko> sure.
[03:51] <ddaa> going well here
[03:51] <ddaa> gnuhello import is live
[03:52] <ddaa> btw, it's better to ask me if you need an import to get done, at the moment it NEEDS manual intervention to go forward
[03:52] <ddaa> and if you just approve it yourself, I may just miss it.
[03:53] <kiko> ddaa, I clicked on the wrong button unfortunately. thanks for pointing that out!
[03:53] <ddaa> btw, why is it that we needed gnuhello imported all of sudden?
[03:53] <kiko> ddaa, SteveA or sabdfl suggested it for a sample project IIRC
[04:04] <sabdfl> i did
[04:06] <geser> any idea who I could poke about bug #87077?
[04:06] <Ubugtu> Malone bug 87077 in launchpad-buildd "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87077
[04:08] <matsubara> cprov, bigjools: ^
[04:13] <cprov> matsubara: hi, it's only related with lp-buildd code, infinity should be working on it.
[04:14] <geser> I've mailed infinity about it but it seems he is busy with other things.
[04:16] <popey> lp seems a bit sluggish at the moment
[04:17] <cprov> geser: I see, but he is the one that could help you with this, either requesting fixes in current ubuntu perl or in our chroots. You can also nag archive-admins about it.
[04:17] <popey> just getting the front page is taking well.. a long time
[04:23] <ddaa> I see we just have our first format 6 branch uploaded to launchpad...
[04:30] <popey> something odd going on in launchpad
[04:30] <popey> sometimes it delivers pages fine, sometimes it prompts firefox to want to download pages
[04:31] <ddaa> that would be the gzip problem
[04:31] <popey> "the gzip problem"?
[04:32] <ddaa> popey: are you talking about beta.launchpad.net, or about launchpad.net?
[04:32] <popey> beta
[04:34] <ddaa> popey: next time you have this download prompt, it would be nice if you could dowload it and check what the gunzip command does with it.
[04:34] <popey> i did, its plain text
[04:35] <ddaa> can you put it in a pastebin?
[04:36] <ddaa> we had some problems recently with launchpad serving apparently empty gzipped pages, but that was supposedly fixed on beta, that's why I asked.
[04:37] <ddaa> the problem occurs randomly and is hard to reproduce, so we need as much detail as possible to fix it.
[04:38] <popey> hmm
[04:38] <popey> bunch of nulls at the start of this one
[04:38] <popey> makes it difficult to copy/paste :S
[04:38] <popey> http://pastebin.ubuntu-uk.org/35
[04:38] <popey> there you go
[04:40] <matsubara> popey: could you please add the info to bug 89194?
[04:40] <Ubugtu> Malone bug 89194 in launchpad "LP (regular and beta) sending gzipped, zero byte replies" [High,Confirmed]  https://launchpad.net/bugs/89194
[04:40] <ddaa> apparently popey has a different, albeit probably related, problem
[04:42] <popey> how much info do you want attached?
[04:42] <popey> just from HTTP1.1 to <!DOCTYPE ?
[04:43] <ddaa> just upload the whole file as an attachement
[04:43] <popey> ok
[04:43] <ddaa> we're not worried about a few more kb in the librarian :)
[04:44] <popey> heh
[04:47] <popey> ok, added
[04:53] <BenC> Anybody with an lp database magic wand around?
[04:53] <BenC> I need the packages assigned to empty-team reassigned to ubuntu-kernel-team
[04:53] <BenC> and if possible, delete empty-team
[05:21] <Ubugtu> New bug: #93765 in launchpad "[beta]  Hackergotchi should have text on the left hand" [Undecided,Unconfirmed]  https://launchpad.net/bugs/93765
[05:36] <sladen> mmm, no launchpad bugs messages for 6hours.  Am I just being exceptionally lucky?
[05:37] <kiko> lifeless, can you check send-bug-notifications on gangotri?
[05:37] <kiko> thanks for reminding me sladen
[05:48] <Theuni> hmm. is it possible the codebrowser is broken down?
[05:48] <Theuni> loading http://codebrowse.launchpad.net/~refreshng-dev/refreshng/dev takes a long time and then some apache decides it doesn't want to wait any longer
[05:49] <SteveA> Theuni: we need to upgrade the bzr and pack the knits on there
[05:49] <SteveA> which will make it work faster
[05:49] <Theuni> ah hi SteveA
[05:49] <SteveA> so watch out for some changes there over the next week or two
[05:50] <Theuni> alright
[05:50] <Theuni> btw: how are you doing your deployment/development with launchpad?
[05:50] <oojah> sladen: I think you're just causing trouble to be honest...
[05:50] <Theuni> do you use something like buildout or are you interested in using it?
[05:51] <SteveA> we use a .deb package with dependencies for things we need to have installed
[05:52] <SteveA> and nested bzr trees for stuff we customize
[05:52] <SteveA> BenC: hi.  did you get your request seen to?
[05:52] <BenC> SteveA: Not that I'm aware of :)
[05:53] <SteveA> how many packages are we talking about?
[05:53] <SteveA> I can do it using the launchpad ui for you, but I'd rather leave it to stub to use the database directly.
[05:54] <Theuni> SteveA: Interesting. Jim is currently looking into using buildout to package software up as RPMs to use those for distribution. I was wondering whether you guys would be interested in having a similar thing to do that for .deb. I'm interested in this and wonder if other people are as well.
[05:54] <BenC> SteveA: like ~15
[05:55] <SteveA> BenC: mail me a list of launchpad URLs or names of packages, and I'll do it
[05:55] <BenC> SteveA: email addr?
[05:55] <SteveA> steve @ canonical
[05:56] <SteveA> extra points for a GPG sig ;-)
[05:56] <SteveA> Theuni: I don't really understand the use-case for it
[05:57] <kiko-fud> SteveA, the use case for packaging python into debs?  really?
[05:57] <SteveA> I understand python eggs -> .debs
[05:58] <BenC> SteveA: Sent and signed, thanks :)
[05:58] <Theuni> Right. A project infrastructure might contain more things than just eggs though. E.g. files that go to /etc/ or somewhere else.
[05:59] <SteveA> BenC: I have a couple of calls, but I'll attend to these later today.  Let me know if it's urgent and you need these sooner
[05:59] <Theuni> buildout projects maintain this information and can keep them within a central sandbox e.g. for developing or you could make it store them centrally.
[05:59] <SteveA> Theuni: that's part of the skill of making .deb packages for Ubuntu -- knowing the right policies on what goes where, and how to install and uninstall and upgrade well
[05:59] <Theuni> however, sysadmins seem to like getting software into production not via version control but packaged stuff.
[05:59] <BenC> SteveA: It's important, but not a case for dropping other things
[06:00] <SteveA> BenC: ok, have it for you in a few hrs
[06:00] <kiko-fud> let me see if I can get lunch here
[07:16] <SteveA> Theuni: hi
[07:16] <SteveA> Theuni: > See the dump attached.
[07:16] <SteveA> ???
[07:25] <siretart> is it possible to set tags with the MaloneEmailInterface?
[07:25] <kiko> siretart, it's not, no.
[07:25] <siretart> k
[07:25] <kiko> there's a bug filed on it but this is requested rather infrequently
[07:27] <ddaa> Theuni: it looks like the attachement is missing :)
[07:33] <LaserJock> kiko: I'm guessing we'll be doing it quite a bit
[07:33] <kiko> LaserJock, time to motu it
[07:33] <LaserJock> we're launched a "tag the Universe" campaigne
[07:34] <LaserJock> we've also got 450+ request-for-package bugs to file/tag
[07:39] <Lumiere> imo tags should be part of the affects area
[07:39] <Lumiere> not part of the description
[07:39] <kiko> Lumiere, that's complicated.
[07:40] <Lumiere> I know
[07:40] <Lumiere> but I'm doing the same thing as LaserJock
[07:40] <Lumiere> and there are a LOT of clicks to do that in Malone
[07:44] <LaserJock> Lumiere: if you had lots of tags wouldn't it get cluttered fast?
[07:45] <Lumiere> it's still just a space separated list
[07:48] <kiko> I think Lumiere actually means he'd like them to be editable inside the bug page
[07:48] <kiko> instead of on a separate page
[07:48] <kiko> not that they'd fit in with the affects targets.
[07:50] <LaserJock> ah
[07:50] <LaserJock> I see
[07:50] <LaserJock> that'd be cool for sure
[07:53] <Lumiere> yes
[07:53] <Lumiere> because the more you try and use them
[07:54] <Lumiere> the less you want to have to click a bunch to find/edit it
[08:27] <swimmerino88> hi to evrebody!i have a simple question...i have registered me in launch...now what do i have to do to become an ubuntu tester?
[08:28] <kiko> swimmerino88, join #ubuntu-bugs or #ubuntu-devel
[08:29] <swimmerino88> ok
[08:30] <stgraber> swimmerino88: if you want to test iso, I'd suggest you to join #ubuntu-iso
[08:31] <swimmerino88> stgraber: no my idea is to test the the unstable ubuntu distros
[08:31] <stgraber> swimmerino88: that's what's done by the ubuntu testing team on the channel I just gave you
[08:32] <stgraber> swimmerino88: testing Feisty and reporting bug
[08:32] <swimmerino88> stgraber:ok thank you!
[08:33] <stgraber> swimmerino88: np


[08:59] <cult-> hello, i would like to raise awereness of a broken library in ubuntu repository, i contacted the maintainer in email but he hasn't responded. what should I do?
[09:05] <cult-> ubuntu-bug libodb-dev for xenial 16.04, more info: http://www.codesynthesis.com/pipermail/odb-users/2016-May/003280.html
[09:20] <cult-> https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
[09:41] <cult-> where can I find the build logs?
[09:41] <cult-> nevermind
[09:41] <rbasak> https://launchpad.net/ubuntu/+source/libodb/2.4.0-1 -> Builds
[09:43] <cult-> https://launchpadlibrarian.net/228769724/buildlog_ubuntu-xenial-s390x.libodb_2.4.0-1_BUILDING.txt.gz
[09:43] <cult-> i can't seem to find any errors. but when i built it from source by myself, all was ok.
[09:50] <cult-> but what i see is that there's only s390x architecture available in xenial, why not amd64?
[09:50] <cult-> can it be the source of the problem?
[11:44] <Vej> How do we set the status for a bugreport, which contains the opinion, that a package should be excluded from the ubuntu installer?
[11:45] <Vej> It feels like an "Opinion", but the officiall description needs a "difference of opinion" which is not the case here.
[11:46] <rbasak> IMHO, if it's clear to developers what the request is, then Triaged.
[11:46] <rbasak> If developers disagree, they can set it to Won't Fix.
[11:47] <rbasak> If they agree, then the bug can remain open to track when it is done.
[11:47] <Vej> rbasak: Thank you. I will set to Triaged then.
[15:15] <Laibsch> Just found another example in bug 1540706 of why the penalv-bot is harming the community and alienating valuable contributors.
[15:16] <Laibsch> I mean, you have to be insane to ask a guy who reported a valid issue, then goes ahead and fixes the issue himself, then goes ahead and pushes the patch upstream and respond by "please follow our procedure and run some silly scripts because we ALWAYS do, whether or not it makes sense".
[15:17]  * Laibsch thoroughly pissed off again
[15:51] <rbasak> I agree. It was inappropriate to mark that Incomplete. If an upstream-committed patch for the issue has been identified, the bug almost always automatically Triaged.
[15:51] <rbasak> bdmurray: ^


[07:07] <dholbach> good morning
[15:32] <dholbach> nigelb: at least I got to hear some noise from sweet India :)
[15:32] <nigelb> haha
[15:32] <dholbach> nigelb: no need to go crazy :)
[15:32] <nigelb> you heard the echo from germany :p
[15:32] <dholbach> but it was FROM India :)
[15:33] <dholbach> alright, whatever
[15:33] <nigelb> heh
[15:33] <dholbach> so there's a few things I wanted to talk about
[15:33] <nigelb> anyway, so we're way out of track
[15:33] <dholbach> 1) Ubuntu Global Jam coming up soon
[15:33] <dholbach> 2) Patch Days + Tuition Sessions
[15:33] <dholbach> 3) Interviewing current contributors about their experience with the process
[15:33] <dholbach> 4) Reaching out more generally
[15:34] <dholbach> 5) Reactivating Bobbo! :-D
[15:34] <nigelb> heh
[15:34]  * vish thinks the review process needs to be review first :(
[15:34] <vish> reviewed*
[15:34] <nigelb> why?
[15:34] <nigelb> I thought it was fine with no complaints
[15:35] <nigelb> ('cept for nitpickers like you :p)
[15:35] <vish> 1: we dont need so many tags ;p
[15:35] <dholbach> I think it's just important to hear what our new contributors have to say in any case
[15:35] <nigelb> Yes, we do.
[15:35] <vish> no.. :s
[15:35] <nigelb> how else doo you intend to keep track of the buckets?
[15:35] <dholbach> shall we go through them one by one?
[15:35] <vish> We need only 4 statuses:
[15:35] <vish> - forwarded [this will work for all patches debian/upstream]
[15:35] <vish> - needs-work  [these three are for patches which are lp projects]
[15:35] <vish> - accepted
[15:35] <vish> - rejected
[15:36] <nigelb> vish: but if a patch is marked rejected we might still goo with it
[15:36] <vish> nigelb: we cant keep baby sitting patches for ever :(
[15:36] <nigelb> for example the ayatana does a lot of stuff rejected upstream
[15:36] <vish> nigelb: rejected is for an Ubuntu task..
[15:36] <nigelb> tags are per bug reports not per task
[15:37] <vish> plus we need to do what bgo does , status of the patches , rather than tag bug reports
[15:37] <vish> me need to get that in lp :)
[15:37] <nigelb> status of patches was discussed at uds
[15:37] <nigelb> If i remember, you were there :p
[15:37] <vish> yeah , thats what i'm saying ;)
[15:37] <nigelb> jcastro had an acition item and he updated it recently.
[15:37] <nigelb> while its a good idea lp team thinks its too much of work to implement right now
[15:38] <nigelb> and they suggested that we use tags which we're already doing
[15:38] <nigelb> (this is the result of the action item)
[15:38] <vish> nigelb: why do we need patch-fowarded-upstream + -debian ? why not just patch-forwarded?  if a relevant patch needs to to upstream/debian it is evident
[15:39] <nigelb> We can have a patch forwarded to upstream and debian at the same time
[15:39] <nigelb> how do you track that?
[15:39]  * vish never saw such a bug yet :s
[15:39] <nigelb> I did.
[15:39] <dholbach> ok
[15:40] <dholbach> I feel like we should have that discussion separately :)
[15:40] <nigelb> heh
[15:40] <nigelb> I shoulda been at uds
[15:40] <dholbach> in terms of feedback I can imagine that there's a lot of other stuff coming up
[15:40] <nigelb> this would have been so much easier if we could sit down and discuss :/
[15:40] <dholbach> but we need to start reaching out to those new contributors first
[15:40] <nigelb> instead of having reports maybe we need to blog about examples
[15:41] <nigelb> like what effraim does for packaging.  that would seem interesting
[15:41] <vish> dholbach: thats the first complaint any new contrib keeps whining about , too many patches :( , thats why i brought it up :)
[15:41] <dholbach> I did a blog post like that already, anybody else wants to have a go?
[15:41]  * vish fades aways
[15:41] <nigelb> dholbach: I do.  Its my turn for reports today.  I'll do some.
[15:41] <dholbach> vish: sorry, I didn't mean to rebuff your comments
[15:41] <dholbach> vish: I think they're important, but I felt that it was part of a longer conversation
[15:42] <dholbach> and tried to go through the quicker pieces first
[15:42] <vish> cool.. :)
[15:42] <nigelb> dholbach: we need to have a patch day soon :)
[15:43] <nigelb> shall we bug pedro about it today? next thursday perhaps?
[15:43] <dholbach> pedro is at GUADEC right now
[15:43] <nigelb> ahhh.  Oh no.
[15:43] <dholbach> so maybe the thursday afterwards
[15:43] <dholbach> which would leave more time for organisation
[15:43] <nigelb> Yes.
[15:43] <dholbach> I'm happy to send him a mail about it
[15:43] <dholbach> ok
[15:44] <dholbach> regarding http://wiki.ubuntu.com/UbuntuGlobalJam
[15:44] <nigelb> Same system as last time, 1 person in the channel provides support for questions etc
[15:44] <dholbach> it's going to be quite a big event, happening in a month
[15:44] <dholbach> it'd be nice if we could integrate info about Cleansweep into either http://wiki.ubuntu.com/UbuntuGlobalJam directly or maybe http://wiki.ubuntu.com/Jams/Bugs
[15:44] <dholbach> do you think that makes sense?
[15:45] <nigelb> yes.  it does
[15:45] <dholbach> do you think you can have a look and see where it fits in well?
[15:45] <nigelb> I was planning on having a bug jam in our city.  May be I could organize it towards patches
[15:45] <dholbach> I'll also mention it as part of the UGJ announce
[15:45] <dholbach> sounds awesome
[15:45] <nigelb> I will. I will either fix it or talk to pedro about it first
[15:45] <dholbach> fantastic
[15:45] <dholbach> that's two discussion points off the list already :)
[15:46] <dholbach> let's talk about the actions in a few days again so we can see where we stand
[15:46] <nigelb> ok
[15:46] <nigelb> I'll go compose that blog post now
[15:46] <dholbach> how can we reach out more generally and also reach out to existing contributors about their experience with the process?
[15:46] <dholbach> shall we maybe just ask during the patch days?
[15:46] <nigelb> yeah.  good idea
[15:47] <nigelb> just 4 questions would do
[15:47] <nigelb> small enough for people to spare 5 minutes
[15:47] <dholbach> are you going to draft something up so we can ask them immediately during the event?
[15:47] <nigelb> yep, I will :)
[15:47] <dholbach> super
[15:47] <dholbach> and maybe we should think about reaching out more after those events again
[15:48] <nigelb> yeah, have a list of people who participated and poke them often
[15:48] <dholbach> I think I'll CC bobbo in all those discussion mails too
[15:48] <nigelb> yep, good idea
[15:48] <dholbach> maybe he's interested in helping out
[15:48] <nigelb> also, you could display that counter on your site
[15:48] <nigelb> and also poke and push other community folks like jono to display it
[15:49] <dholbach> I'll have a look and see
[15:49] <nigelb> torture them if you have to :D
[15:50] <dholbach> haha
[15:54] <dholbach> nigelb: sent the summary
[15:54] <dholbach> nigelb: let's re-review in a few days
[15:54] <nigelb> okay
[16:02] <vish> dholbach: there is one item jcastro was supposed to do during UGJ
[16:02]  * vish finds blueprint
[16:05] <dholbach> https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-global-jam
[17:10] <vish> nigelb: poke..
[17:11] <nigelb> vish: ouch
[17:11] <vish> nigelb: right , so back to the reduce tags
[17:12] <vish> nigelb: is there any way , we can reduce ,them , seems a bit much .. we can make it a lot more simpler
[17:12] <nigelb> vish: I'm thinking of it now that you say it so vehemently
[17:13] <vish> we have nearly 11-12 tags , and the first thing anyone sees that list they go .. awww :s
[17:13] <nigelb> best part...
[17:13] <nigelb> we always use only 3 :/
[17:13] <vish> yeah
[17:14] <nigelb> patch-needswork, patch-forwarded-upstream
[17:14] <nigelb> well, the othe one is "patch"
[17:15] <nigelb> vish: I've asked doctormo to take a look at the process
[17:15] <vish> Nicke: i say , we combine the tags and reduce to just 4.. and we dont ask anyone to babysit the patch , we need to make the submitter  more familiar with upstrea/debian
[17:15] <vish> we cant keep reporting back , upstream says "so so.."
[17:15] <vish> err , nigelb ^
[17:16] <vish> Nicke: unping ;)
[17:16] <nigelb> can give me a few days to talk to others?
[17:16] <nigelb> vish: unping is so LOL.  Now you've pinged him/her twice >D
[17:16] <vish> nigelb: no probs for me ;)
[17:16] <vish> ;)
[17:18] <nigelb> vish: also, bug me next week.  I might get overwhelmed. :D
[17:18] <vish> nigelb: hehe , alteast he wont keep wondering whaaaaat! :)
[17:18] <vish> nigelb: meh , i forget more than you ;p , thats why i mention now ..
[17:18] <nigelb> haha
[21:55] <massimo_> evening all !
[22:01] <massimo_> somebody got some tips for a newcomer?
[22:28] <massimo_> having trouble finding my fingerprint? command : gpg --fingerprint does not return anything, any help plz?


[09:51] <silverarrow> heard anything on the dailies
[09:51] <silverarrow> ?
[09:52] <kanliot> sup silverarrow
[09:52] <silverarrow> hi
[09:52] <silverarrow> it`s almost sad to leave 12.04
[09:55] <smartboyhw> Hi:P
[09:55] <smartboyhw> silverarrow, you mean when the new dailies will be built?
[09:56] <silverarrow> no, more like feedback fromt testing
[09:56]  * smartboyhw is not understand what silverarrow is saying then:P
[09:58] <silverarrow> hm
[09:58] <smartboyhw> feedback from testing what do yuo mean silverarrow ?
[09:59] <smartboyhw> *you
[09:59] <silverarrow> well, there have been new issued regularly ?
[09:59] <smartboyhw> silverarrow, new what?
[10:00] <silverarrow> brb, update with restart
[10:00] <smartboyhw> OK
[11:17] <xnox> I'd like to add a testcase to Ubuntu Desktop Mandatory
[11:17] <xnox> or possibly run-once
[11:18] <xnox> Install (reinstall) & Install (upgrade)
[11:19] <xnox> basically bug 1056571 and bug 1050562
[11:19]  * xnox is a bit confused how'd we managed to release all of these milestone images without these options =)
[11:19]  * xnox is fixing this now.
[11:22] <xnox> oh and server images as well, as they are also affected.
[13:33] <balloons> xnox, :-) So the image should have these options now?
[13:34] <xnox> balloons: after partman-auto is uploaded the next server images and all alternates will get the reuse option (in place upgrade/reinstall)
[13:34] <balloons> kk
[13:34] <xnox> balloons: after my ubiquity fix is uploaded with new partman-auto embedded the desktop images will get the reuse option (in place upgrade/reinstall)
[13:35] <xnox> balloons: but...... how did we not notice this earlier =)
[13:35] <xnox> balloons: and is it ok to add just a test case?
[13:36] <balloons> xnox, ? on the how and why we arrived at what we arrived at
[13:36] <balloons> and yes we can add a testcase. This cycle was about rounding up the tests we do have and seeing what
[13:36] <balloons> is what
[13:36] <balloons> I'd like to enhance and change how we test ubiquity
[13:41] <xnox> balloons: do we have uds-r session about it?
[13:42] <balloons> not yet, but indeed we will
[13:42] <balloons> however, I don't want to necessarily wait until uds to talk about it or do some work on it.. we'll see what can be squeezed in
[17:39] <balloons> xnox, btw, I did add your 2 testcase requests to the list to work
[17:44] <xnox> balloons: awesome =)
[17:45] <balloons> xnox, do you the tool jibel mentioned besides xpresser?
[17:46] <xnox> balloons: autopilot? no.
[17:46] <balloons> yea.. I know about autopilot.. I thought there may have been somehting else
[17:51] <jibel> balloons, ldtp ?
[17:52] <balloons> ahh jibel :-) perhaps.. thank you
[18:03] <xnox> well ldtp is the first one, it's based on a11y frameworks.
[18:03] <xnox> and there were mago python binding on top of ldtp but they are old / not maintained any more?!
[18:03] <xnox> and ubiquity is not fully a11y
[18:03] <xnox> unity is not a11y at all....
[18:04] <xnox> so pure ldtp / a11y based testing will not do, as you just would not be able to do it.
[18:04] <xnox> the xpresser - will break every time there is a change to the theme?
[18:05] <nagappan> xnox, yup
[18:06] <nagappan> xnox, it also based on the app you are planing to automate
[18:06] <nagappan> xnox, in VMware, we run tests in Unity mode as well for VMware Workstation and Player without any issues
[18:07] <nagappan> xnox, I guess davmor2 had success in automating his app (ubuntu-software-center)
[18:07] <xnox> nagappan: do you automate on the host or guest? I think it would be perfect if xpresser could run on the host -> automating e.g. installer running in the VM
[18:08] <xnox> otherwise i'd have to presseed the desktop cd to install xpresser and start that up somehow =/
[18:12] <nagappan> xnox, we automate both, but the guest VM, was pre-created
[18:13] <xnox> nagappan: ok. And you click stuff in the VM? interesting.
[18:13] <nagappan> xnox, we are now in the process of integrating Sikuli with LDTP, which will create VM from scratch
[18:13] <nagappan> xnox, yup, the reason is LDTP will run in the guest, so we can run the remote commands