[02:12]  * Keybuk finally gets around to proving some of the bugs sadmac fixed in 0.5
[02:49] <sadmac> Keybuk: which ones?
[02:52] <Keybuk> $ENV's replacement being the same length as the variable name+$ for example
[02:53] <sadmac> oh yes
[02:53] <Keybuk> I'm going to be strict from now on ;) all bug fixes must come with test cases
[02:54] <sadmac> not a problem
[02:54]  * sadmac goes back to writing tests
[02:58] <sadmac> Keybuk: test_com.netsplit.Nih.Test_object: tests/com.netsplit.Nih.Test_impl.c:766: my_setup: Assertion `server != ((void *)0)' failed.
[02:58] <sadmac> Keybuk: I started getting these failures writing my testcases, but reverting my changes doesn't fix them
[02:58] <Keybuk> err
[02:58] <Keybuk> that implies your test d-bus server isn't running?
[02:58] <Keybuk> have you checked it got killed ok before?
[02:58] <Keybuk> usually it's test_dbus-daemon
[02:59] <sadmac> I see a test_com.netspli
[02:59] <sadmac> that's probably it
[03:00] <sadmac> ahh, segmentation fault
[03:00] <sadmac> something strangely comforting about knowing its your own fault after one of those phantom errors.
[03:05] <sadmac> Keybuk: how much later will you be around?
[03:06] <Keybuk> not much
[03:06] <Keybuk> why?
[03:07] <sadmac> Keybuk: I have the async api and one test case. I want to show it to you before I write more so I know if the API as at least right. But I have a segfault left to scrub out so its not quite ready :)
[03:11] <Keybuk> cool
[03:11] <Keybuk> I may be around long enough ;)
[03:12] <sadmac> Keybuk: dbus_shutdown is triggering the segfault. Its being called from the teardown function (which I haven't touched). Only thing I can think of that would do it is a call to dbus_connection_read_write_dispatch (conn, -1);
[03:12] <sadmac> seems like without that it didn't segfault (though the test didn't really run)
[03:23] <Keybuk> that implies you've got your references mixed up somewhere
[03:24] <sadmac> ah
[03:24] <sadmac> what's happening then?
[03:25]  * sadmac sees definite double-deref
[03:26] <sadmac> dunno how that could do this, but its a bug
[03:26] <sadmac> Keybuk: \o/
[03:27] <sadmac> Keybuk: how do you want this then?
[03:35] <Keybuk> got a bzr tree?
[03:37] <sadmac> Keybuk: yeah, writing the commit notes now...
[03:37] <sadmac> I had more outstanding than I thought.
[03:46] <sadmac> Keybuk: https://code.launchpad.net/~cjdahlin/libnih/async
[03:50] <Keybuk> ok, give me a few minutes to finish up this bit
[03:50] <Keybuk> and I'll take a look
[03:52] <sadmac> k
[04:08] <Keybuk> urgh
[04:08] <Keybuk> the valgrind attacks.  you die
[04:09] <Keybuk> (not your code, mine)
[04:09] <Keybuk> http://rafb.net/p/EzdMTh82.html
[04:10] <Keybuk> nothing worse than an invalid write into a freed block where the write and free are inside the same function
[04:10] <Keybuk> (and that function is "free" :p)
[04:10] <sadmac> ot
[04:10] <sadmac> *oy
[04:16] <sadmac> isn't it 4am over there?
[04:22] <Keybuk> yes
[04:22] <Keybuk> don't you ever stay up all night hacking? :)
[04:25] <Keybuk> why names?
[04:28] <Keybuk> unless I'm missing something, the dispatch function doesn't take the method call arguments
[04:31] <Keybuk> I'd generate a typedef for the callback function and put it in the .h file
[04:31] <Keybuk> and use that
[04:31] <Keybuk> if callback is NULL, should send without expected reply
[04:32] <Keybuk> NihAsyncNotifyData should be in the .c file, since it should never be exposed
[04:32] <Keybuk> should be typedef'd to that name
[04:32] <Keybuk> member names should line up
[04:33] <Keybuk> userdata -> data
[04:33] <Keybuk> proxy should probably go first too
[04:33] <sadmac> Keybuk: for which callback?
[04:34] <Keybuk> argument to the async dispatch function
[04:34] <sadmac> Keybuk: ah, nm, I misunderstood for a moment
[04:34] <Keybuk> struct nih_blah_blah -> NihBlahBlah
[04:34] <Keybuk> I wouldn't call it that though
[04:34] <Keybuk> make it similar to the DBus Name
[04:34] <Keybuk> NihDBusPendingCall or something
[04:34] <sadmac> Keybuk: you omit the CamelCase form on another struct in dbus.h
[04:35] <Keybuk> do I?
[04:35] <sadmac> pretty sure
[04:35] <Keybuk> I bet I typedef'd it first ;)
[04:35] <Keybuk> NihDBusInterface?
[04:35] <Keybuk> line 44: typedef struct nih_dbus_interface NihDBusInterface;
[04:36] <sadmac> Keybuk: ah. so it is.
[04:36] <Keybuk> I can't quite work out what you're doing with the callback definition in asyncDispatchPrototype() - a typdef would definitely help here
[04:37] <Keybuk> and then it'd be obvious you've forgotten all about in_args ;)
[04:37] <sadmac> Keybuk: line 1283
[04:37] <Keybuk> oh
[04:37] <Keybuk> they should go first
[04:38] <sadmac> Keybuk: I figured put the consistent-between-all stuff first
[04:38] <Keybuk> proxy, input arguments, callback, data
[04:38] <Keybuk> my_str_to_int (proxy, "foo", get_int, NULL);
[04:38] <Keybuk> reads the right way then
[04:39] <sadmac> yeah, I can see that..
[04:40] <Keybuk> you don't actually check whether the pending call completed?
[04:40] <Keybuk> in fact
[04:40] <Keybuk> dbus_pending_call_steal_reply doesn't return NULL to indicate out of memory
[04:41] <Keybuk> it returns NULL to indicate no reply received yet
[04:41] <Keybuk> in case of timeout, dbus_pending_call_steal_reply returns an error
[04:42] <Keybuk> in fact, how do we deal with errors at all? :)
[04:42] <sadmac> oh yeah, I hadn't done that yet had I?
[04:42] <Keybuk>         # FIXME: Reply isn't the best parent for this, but proxy isn't here.
[04:42] <Keybuk> comment doesn't make sense given you use proxy ;)
[04:42] <sadmac> oh, fixed it
[04:43] <Keybuk> should the proxy be passed to the callback function?
[04:43] <Keybuk> I think it makes sense for it to be
[04:43] <Keybuk> in case the callback wants to make more calls
[04:43] <Keybuk> an error handler is going to look like  void (*error_handler) (void *data, NihDBusProxy *proxy;
[04:44] <Keybuk> which I guess means you have to provide both
[04:44] <Keybuk> my_str_to_int (proxy, "foo", get_int, deal_with_error, NULL);
[04:44] <Keybuk> but it's probably ok for the error handler to be NULL
[04:44] <Keybuk> actually
[04:45] <Keybuk> no it's not, let's make that required if a callback is givne
[04:45] <Keybuk> nih_alloc (..., struct) -> nih_new ()!
[04:46] <Keybuk> you don't provide a free function for the pending call
[04:46] <Keybuk> that's kinda important, since otherwise you'll leak the async data structures
[04:46] <Keybuk> the free call might want to do something like call the error handler
[04:46] <Keybuk> setting some useful error
[04:47] <sadmac> ok
[04:47] <Keybuk> so for str_to_int, that'd look something like
[04:47] <Keybuk>   my_str_to_int (proxy, "1234", int_reply, error_handler, data);
[04:47] <Keybuk> with the others being
[04:48] <Keybuk> void int_reply (void *data, NihDBusProxy *proxy, int num);
[04:48] <Keybuk> void error_handler (void *data, NihDBusProxy *proxy);
[04:48] <Keybuk> ( the error would be retrieved with nih_error_get() )
[04:55] <sadmac> Keybuk: we could save a function pointer by just adding an "int succeeded" to the callback
[04:57] <Keybuk> error_handler would be more consistent with other functions
[04:57] <Keybuk> e.g. nih_io
[04:59] <sadmac> Keybuk: did you look at the testcase?
[04:59] <sadmac> there's a bit of conventional intrigue there too
[04:59] <Keybuk> I did, my eyes have not recovered ;)
[05:00] <sadmac> Keybuk: I do like gcc's mandate of the auto keyword in that context
[05:00] <sadmac> "hey, we need to break a grammar ambiguity. Know any keywords that aren't busy?"
[05:06] <Keybuk> hah
[05:07] <sadmac> Keybuk: if you have a better way to structure those I'm open to it. What I like about this method is that the tests still read in the order they're run.
[05:07] <Keybuk> I'll either hate it ...
[05:07] <Keybuk> or convert everything else to use them ;)
[05:08] <Keybuk> ngggarrrrgh
[05:08] <sadmac> huh?
[05:08] <Keybuk> the valgrind error can be replicated with the absolute simplest of code
[05:08] <Keybuk> c = job_class_new (NULL, "foo");
[05:09] <Keybuk> j = job_new (c, NULL);
[05:09] <Keybuk> nih_free (c)
[05:09] <sadmac> that's ugly
[05:09] <Keybuk> the strange thing is that this should all just work now
[05:10] <Keybuk> the whole point of refs is that if you have a pointer, you have a ref
[05:10] <Keybuk> so they should collapse cleanly *sigh*
[05:11] <sadmac> one thing I wish we could do (and I'm nearly certain we can't) is have a NIH_FRAME macro instead of nih_local, and you simply parented things to it to make them have a reference held by the current stack frame
[05:11] <Keybuk> I considered that approach
[05:11] <Keybuk> I decided nih_local was nicer
[05:12] <sadmac> I like having the frame parent, but the things you'd have to do to make it work would offset any nicety.
[05:12] <sadmac> you'd have to hide a var somewhere in the function somehow to run your cleanup
[05:13] <sadmac> or pillage the stack manually
[05:13] <Keybuk> having the frame parent feels a bit like assembler
[05:13] <sadmac> or keep a costack and call everything that uses it through wrappers
[05:13] <Keybuk> just saying "this is local" feels a bit like python ;)
[05:13] <sadmac> I think its the word "frame"
[05:13] <Keybuk> the aim is to simplify the code
[05:14] <Keybuk> you'd have to do something like:
[05:14] <Keybuk>   {
[05:14] <Keybuk>     NIH_LOCAL local;
[05:14] <Keybuk>     char *str;
[05:14] <Keybuk> ...
[05:14] <Keybuk>      str = nih_strdup (local, "foo");
[05:14] <Keybuk>   }
[05:14] <Keybuk> it kinda gets lost in the fog a bit
[05:14] <sadmac> the need to declare it is what kills it
[05:14] <sadmac> and that's what I can't factor out
[05:15] <Keybuk> yeah
[05:15] <Keybuk> if that were
[05:15] <Keybuk>   {
[05:15] <Keybuk>     char *str;
[05:15] <Keybuk> ...
[05:15] <Keybuk>     str = nih_strdup (NIH_LOCAL, "foo");
[05:15] <Keybuk> that would be ok
[05:15] <Keybuk> but I don't think you can declare variables right there ;)
[05:15] <Keybuk> and even if you could, the second use of NIH_LOCAL would break it
[05:15] <sadmac> what I /really/ wish is that you could do this:
[05:15] <Keybuk> (and I see what causes this valgrind bug now ...
[05:16] <Keybuk>  it's the ancient thing-is-in-a-hash-table bug)
[05:16] <sadmac> void foo (char nih_local *bar) {...
[05:16] <Keybuk> class->jobs is a hash table
[05:16] <Keybuk> job is in that
[05:16] <sadmac> and it would make bar nih_local and /ref/ it
[05:16] <Keybuk> when you free job, it removes itself from the hash
[05:16] <Keybuk> but if you free class, the hash should be freed first
[05:16] <Keybuk> sadmac: huh?
[05:17] <Keybuk> how does that work
[05:17] <Keybuk> it's an arg passed in, it's inherently already ref'd by something and you don't need to care
[05:17] <sadmac> Keybuk: pthread_create()
[05:17]  * Keybuk wonders why this valgrind bug doesn't affect old nih_alloc
[05:18] <Keybuk> timestamp: Thu 2006-12-21 00:24:05 +0000
[05:18] <Keybuk> message:
[05:18] <Keybuk>   * nih/io.c (nih_io_message_new): Do not assign a default list
[05:18] <Keybuk>   destructor, it's not in a hidden list and there are bad consequences
[05:18] <Keybuk>   of freeing a child with a default destructor if the list its in gets
[05:18] <Keybuk>   freed first; new rule - default destructors only if the list is hidden
[05:18] <Keybuk>   and never freed!
[05:18] <Keybuk> ...
[05:18] <Keybuk> especially since I apparently hit it over 2 years ago :p
[05:19] <sadmac> Keybuk: if we go thread-safe, stack references are more important, because a piece of code referencing a function doesn't tell us as much about other pieces of code that might be dealing with the memory area
[05:19] <sadmac> that's when things like this become interesting
[05:19] <sadmac> but back to your valgrind issue... have a fix?
[05:26] <Keybuk> no, not yet
[05:26] <Keybuk> I'm trying to understand why it's breaking now first
[05:28] <sadmac> Keybuk: while we're here, I had a hypothesis: why do you put the function types on the line above the name when defining and on the same line when declaring?
[05:29] <Keybuk> common C practice
[05:29] <Keybuk> grep ^function_your_looking_for *.c
[05:29] <Keybuk> as a way of locating the code
[05:30] <sadmac> part A confirmed
[05:30] <sadmac> Keybuk: part B: do you use cscope?
[05:31] <Keybuk> nope
[05:31] <sadmac> mhm
[05:31] <Keybuk> why?
[05:32] <sadmac> Keybuk: the theory is that if you used cscope you wouldn't put the function definition on two lines'
[05:32] <sadmac> Keybuk: because you'd be able to find the function no matter how it was formatted
[05:33] <Keybuk> I use ctags, which are pretty much the same thing
[05:33] <Keybuk> but it's something I find useful in other people's code
[05:33] <Keybuk> so I do it too
[05:33] <Keybuk> and it has the advantage of making a function definition really obvious
[05:35] <sadmac> gives you more space for arguments too
[05:35]  * sadmac used to pride himself on the distant right margin of his VB code
[05:35] <sadmac> ah was I ever that young?
[05:37] <Keybuk> heh
[05:37] <Keybuk> my C coding style is kinda wacky really
[05:37] <Keybuk> like the way I line up argument and variable names
[05:38] <Keybuk> and if (! foo)
[05:39] <sadmac> Keybuk: the putting spaces between function names and open parens kills me. especially now that I'm paid to be in kernel code
[05:39] <Keybuk> haha
[05:39] <Keybuk> someone once said that there are only two types of programmers
[05:40] <Keybuk> those that put a space between function names and their parameters, and those that don;t
[05:40] <sadmac> Keybuk: and the guys who wrote procmail
[05:40] <sadmac> that's definitely a new species
[05:41] <sadmac> fd.o's C style guidelines are pretty backward too
[05:41] <sadmac> 2-space tabs? doing it wrong.
[05:41] <Keybuk> here's a question for you then
[05:42] <Keybuk> if you don't like foo(...)
[05:42] <Keybuk> do you do for(...) ?
[05:42] <sadmac> Keybuk: no, because for is yellow in vim
[05:42] <sadmac> yellow things get a space before the args
[05:43] <sadmac> except for sizeof
[05:43] <sadmac> because linus says so
[05:45] <Keybuk> sizeof shouldn't have ()s
[05:45] <Keybuk> sizeof int
[05:46] <sadmac> you take the size of nicer things than I do
[05:46] <sadmac> sizeof(typeof(**x))
[05:46] <Keybuk> typeof doesn't have ()s either
[05:47] <Keybuk> besideswhich
[05:47] <Keybuk> sizeof/typeof is meaningless
[05:47] <Keybuk> sizeof **x
[05:47] <Keybuk> is the same
[05:47] <sadmac> ...whoa...
[05:47] <sadmac> you're right
[05:49] <sadmac> Keybuk: what about those people that name the function arguments outside of the declaration header?
[05:50] <Keybuk> those people need to stop denying the 80s happened
[05:50] <sadmac> or go code COBOL in a hole somewhere
[05:51] <sadmac> HOLBOL?
[05:51] <Keybuk> arguments outside the header is old-style K&R C
[05:51] <Keybuk> we program in ANSI C nowadays
[05:51] <sadmac> sort of
[05:55] <sadmac> Keybuk: can we add cscope.out to the ignorefile?
[05:57] <Keybuk> no ;)
[05:57] <Keybuk> for the same reason I don't put TAGS in there
[05:58] <Keybuk> (you should only ignore output expected to be generated by the ordinary build process)
[05:59] <sadmac> Keybuk: does bzr have a local ignore?
[06:01] <Keybuk> I don't think so
[06:01] <sadmac> damn
[06:01]  * sadmac misses git
[06:02] <Keybuk> oh, yes
[06:02] <Keybuk> ~/.bazaar/ignore
[06:04] <sadmac> cool
[06:04] <sadmac> bug!
[06:05] <sadmac> as soon as I added a line to ~/.bazaar/ignore, all the object files showed up in bzr status
[06:05] <Keybuk> oh, I think that's deliberate
[06:05] <Keybuk> bzr has a built-in global ignore
[06:05] <Keybuk> if you make a new one, it overrides bzr
[06:06] <sadmac> can I source the normal one?
[06:06] <Keybuk> hmm
[06:06] <Keybuk> did you not have a .bazaar/ignore already ?
[06:06] <Keybuk> you just did echo > .bazaar/ignore
[06:06] <Keybuk> didn't you?
[06:06] <sadmac> FUUUUUUUUUUUUUUUUUUUUUUUUUUUU
[06:06] <Keybuk> rm it
[06:07] <Keybuk> run bzr ignored
[06:07] <Keybuk> then edit it ;)
[06:07] <sadmac> superior usability!
[06:08] <Keybuk> you can't use that word
[06:08] <Keybuk> you like git
[06:09] <sadmac> I /can/ however use my vcs
[06:09]  * sadmac uses interactive rebase to do obscure things you can't even imagine in O(1)
[06:09] <Keybuk> I can use git too, I just strongly dislike it
[06:09] <Keybuk> Linus tells you not to rebase
[06:09] <Keybuk> he says every time someone rebases, he kills a kitten
[06:09] <sadmac> interactive rebase is better than rebase
[06:10] <sadmac> it basically lets you put everything in the repo in any order you want.
[06:10] <sadmac> its like using ed on the object files, but you can play louder techno music
[06:11] <Keybuk> you're not supposed to fuck with the repo
[06:11] <sadmac> I don't get much other action, and the repo understands my needs
[06:11] <sadmac> don't judge me, what we do is beautiful
[06:13] <Keybuk> :D
[06:13] <sadmac> oh /repo/.   If that broke down into some hardcore I'd be seriously amused.
[06:20] <Keybuk> heh
[06:20]  * Keybuk spots the basic difference between old nih_alloc and new nih_alloc
[06:21] <sadmac> o yeah?
[06:21] <Keybuk> revno: 455
[06:21] <Keybuk> committer: Scott James Remnant<EMAIL_ADDRESS>[06:21] <Keybuk> branch nick: libnih
[06:21] <Keybuk> timestamp: Mon 2007-10-15 23:14:14 +0100
[06:21] <Keybuk> message:
[06:21] <Keybuk>   * nih/alloc.c (nih_alloc_using, nih_alloc_reparent, nih_realloc):
[06:21] <Keybuk>   Change the order in which children allocations are stored in the
[06:21] <Keybuk>   list such that the last allocation is freed first rather than
[06:21] <Keybuk>   the other way around.  This solves issues of children being stored
[06:21] <Keybuk>   inside an allocated hash table which will be freed first.
[06:23] <Keybuk> in other words, old nih_alloc frees things in the opposite order to that they are allocated in
[06:23] <sadmac> that working implies that the parenting ordering is a subset of the allocation ordering
[06:24] <sadmac> its perfectly possible to:
[06:24] <sadmac> 1) allocate item with no parent
[06:24] <sadmac> 2) allocate hash table
[06:24] <sadmac> 3) stick item in hash table
[06:24] <sadmac> in which case this would break
[06:24] <Keybuk> yeah I never really fixed the original bug
[06:24] <Keybuk> I just kept moving it around every time I noticed it ;)
[06:25] <sadmac> what you should do is not free the memory right away but put it into some kind of list, and then free everything in the list only when its know that all the references are stable.
[06:27] <sadmac> nih_free (void *item)
[06:27] <sadmac> {
[06:28] <sadmac>         static int rec_depth = 0;
[06:28] <sadmac>         ...
[06:28] <sadmac>         rec_depth++;
[06:28] <sadmac>         ...
[06:28] <sadmac>         nih_insert_item_into_free_list(item);
[06:29] <sadmac>         if (! --rec_depth) {
[06:29] <sadmac>                 nih_free_all_free_list();
[06:29] <Keybuk> yeah, that's the plan
[06:29] <Keybuk> finalise the object first
[06:37] <sadmac> Keybuk: where do I move the NihAsyncNotifyData struct so it shows up in the C files?
[06:38] <Keybuk> you might have to define something to do that
[06:39] <sadmac> mmh
[06:39]  * sadmac thinks about rewriting all this with a templating engine again
[06:41] <Keybuk> ...with child in older sibling list
[06:41] <Keybuk> BAD: block 0xacd108 (child->entry.next) freed unexpectedly
[06:41] <Keybuk> 	at tests/test_alloc.c:243 (child_destructor_test).
[06:41] <Keybuk> sweet
[06:41] <sadmac> have a testcase then?
[06:42] <Keybuk> I think so
[06:42] <Keybuk> though one passes but fails valgrind
[06:42] <Keybuk> oh, hah
[06:42] <Keybuk> because I'm an idiot
[06:42] <Keybuk> my test case uses TEST_FREE_TAG ... which uses nih_alloc
[06:42] <Keybuk> can't test nih_alloc with TEST_FREE_TAG you dolt
[06:56] <Keybuk> right
[06:57] <Keybuk> I now have two test cases
[06:57] <Keybuk> that both work
[06:57] <Keybuk> if you use _add () the first test case fails
[06:57] <Keybuk> if I change it to _add_after () the second test case fails
[07:01] <sadmac> Keybuk: ok, last I saw I asked about typedefs
[07:06] <Keybuk> I didn't see that
 Keybuk: is there a place to put the typedefs for the callbacks
[07:07] <Keybuk> anything above that?
[07:07] <sadmac> 01:43  * sadmac fixes a longstanding problem with his vimrc
[07:07] <sadmac> then before that you said you were an idiot
[07:08] <Keybuk> heh
[07:08] <Keybuk> not sure if there's a place in the python code
[07:08] <Keybuk> I certainly meant to have one, but may not have added that func
[07:09] <Keybuk> should go at the top, before externPrototypes
[07:38] <sadmac> I'm sleeping now.
[07:47] <Keybuk> heh
[07:47] <Keybuk> I'm just about to do that
[07:47] <Keybuk> I'm worried
[07:47] <Keybuk> my code worked first time
[07:54] <Keybuk> Upstart's test suite largely works too
[07:54] <Keybuk> there's a few failures, but I don't _think_ they are related
[08:07] <Keybuk> (and frankly, the d-bus stuff works - and that really abuses nih_alloc :p)
[08:08] <Keybuk> http://bazaar.launchpad.net/%7Escott/libnih/trunk/revision/639
[08:09] <Keybuk> in summary: first call all the destructors, then free them all
[08:09] <Keybuk> but rather more efficient without the need to recurse ;)
[21:23] <Keybuk> right
[21:23] <Keybuk> you and me, valgrind...
[21:25] <sadmac> Keybuk: what about you, him, and valgrind?
[21:26] <Keybuk> going to fix these remaining test case failures
[21:26] <Keybuk> I'm also trying to decide whether it's a bug to call nih_free () on an object with a parent
[21:26] <Keybuk> ion_: what do you think?
[21:27] <ion_> I’d lean on only allowing to free by unrefing.
[21:27] <ion_> uh, towards
[21:27] <Keybuk> what if you never allocated it with a reference in the first place? :)
[21:28] <sadmac> Keybuk: I'd lean toward /that/ being a bug
[21:28] <sadmac> or rather impossible
[21:28] <Keybuk> well, you have to start somewhere?
[21:28] <ion_> Ah, right, parentless objects don’t have a reference.
[21:28] <ion_> Hmm
[21:28] <Keybuk> otherwise you'd need a global reference, which is basically the same as NULL ;)
[21:28] <sadmac> Keybuk: exactly
[21:28] <Keybuk> so why not use NULL?
[21:29] <Keybuk> the disadvantage of a global reference, and the reason nih_alloc doesn't have one, is that valgrind thinks the object is in use ;)
[21:29] <sadmac> Keybuk: yes. Use NULL by all means.
[21:29] <Keybuk> so doesn't bitch if you forget to free
[21:29] <Keybuk> that was the other main reason I opted for "nih_local" and NULL rather than NIH_LOCAL as the parent
[21:30] <sadmac> Keybuk: you could have a debug mode where you htonl() the refs that are from the root object
[21:32] <Keybuk> huh?
[21:32] <sadmac> Keybuk: "encrypt" references from the root object when -DDEBUG so valgrind can't read them
[21:33] <ion_> How about just making unref() free parentless objects, and behave as before with objects with parents?
[21:35] <Keybuk> that involves having a debug mode though ;)
[21:35] <Keybuk> ion_: nih_unref (ptr, NULL) type thing?
[21:38] <ion_> Or maybe make nih_free barf if the object has parents?
[21:40] <Keybuk> or make nih_free only do something if the object has parents?
[21:46] <ion_> How should it be used then?
[21:46] <ion_> If you nih_new() without a parent and nih_free() it, nothing would happen, right?
[21:47] <Keybuk> I mean if the object hasn't parents
[21:47] <Keybuk> so nih_free() matches nih_new(NULL, ...)
[21:47] <sadmac> Keybuk: what's the difference between what you get from nih_alloc(NULL, ...) and what you have in nih_unref() when you've removed the last ref and its about to be freed
[21:47] <Keybuk> and nih_unref() matches nih_ref() or nih_new(ptr, ...)
[21:47] <Keybuk> sadmac: none
[21:47] <Keybuk> if you like, nih_alloc (NULL, ...) gives you something that's unreferenced, but not free
[21:47] <Keybuk> a bit like gobject's sunken ref ;)
[21:47] <sadmac> Keybuk: that's my issue. its identical to the dead state
[21:48] <Keybuk> it means you can allocate something, add a reference, and then not worry about it
[21:48] <Keybuk> you don't have to drop your own
[21:49] <sadmac> Keybuk: IMHO such an object persisting for any amount of time is as bad as a pointer to already freed memory persisting for any amount of time.
[21:51] <Keybuk> it varies
[21:51] <Keybuk> some reference-counting systems are strict
[21:51] <Keybuk> when you allocate, what you have returned has a single reference
[21:52] <Keybuk> if you pass that to anything and it takes a reference, it must add *another* reference
[21:52] <Keybuk> and if you don't want it anymore, you *must* drop the single reference you had when it was allocated
[21:52] <Keybuk> D-Bus's is like that
[21:52] <sadmac> Keybuk: why does nih_unref() free the object then?
[21:52] <Keybuk> the problem with these is that it's easy to forget to drop the reference you got when you allocated it, or easy to forget to take one when you want it
[21:52] <sadmac> Keybuk: its a valid object still
[21:52] <Keybuk> so others have the concept of a floating reference
[21:53] <Keybuk> when you allocate, what you have has only a floating reference
[21:53] <Keybuk> if anything references it, the floating reference is sunk and turned into a real reference
[21:53] <Keybuk> so when you pass it to things that take a reference, it gets turned into a real one
[21:53] <Keybuk> and since that happens, you don't need to worry about unrefing when you don't want it anymore
[21:53] <Keybuk> ...
[21:53] <Keybuk> non-deliberately, nih_alloc turns out to be a bit like the last one
[21:54] <Keybuk> you can allocate with a reference, or without
[21:54] <Keybuk> if you allocate without, it kinda behaves like a non-explicit floating reference
[21:54] <Keybuk> in reality, it's an unreferenced objetc
[21:54] <Keybuk> this works nicely for things like nih_local
[21:54] <Keybuk> since that only discards unreferenced objects
[21:55] <Keybuk> indeed, there's a call for - nih_discard() - which is a safety "I'm done with an unreferenced object, but am not sure that anyone else took a reference" call
[21:55] <Keybuk> and you can return an object to unrefernced as well - nih_unref_only ()
[21:56] <Keybuk> this is all a bit ... strange really ;)
[21:56] <Keybuk> it's what happens when you design an API by evolution
[21:56] <sadmac> Keybuk: I can see the argument for it existing, but I don't like it as a long-term condition
[21:56] <Keybuk> especially when you turn a simple halloc rip-off, into a talloc rip-off into something that afaik is unique
[21:56] <sadmac> Keybuk: I'd like to think of it as mid-transaction database inconsistency
[21:57] <sadmac> Keybuk: its an error for such a thing to exist, but we defer the error on the grounds of "it'll not be that way anymore in a few lines"
[21:57] <ion_> Perhaps rename nih_free as nih_discard (deleting the present nih_discard) to avoid confusion and make it free the object if it has no parents.
[21:57] <Keybuk> ion_: err, that would be exactly what nih_discard does right now, no? :p
[21:57] <ion_> Indeed.
[21:58] <Keybuk> though would it error if it has parents?
[21:58] <sadmac> Keybuk: so rather rename nih_discard to nih_free, and kill the current nih_free
[21:58] <Keybuk> (nih_discard doesn't)
[21:58] <ion_> No, ignore it if it has parents.
[21:58] <ion_> It shouldn’t be called nih_free if it might not free the object IMO.
[21:59] <Keybuk> nih_free always frees right now
[21:59] <Keybuk> even if it has parents
[21:59] <Keybuk> I tend to agree there though, nih_free would be a bit odd if it didn't always free
[21:59] <ion_> Yes, i suggest getting rid of it. :-)
[21:59] <sadmac> Keybuk: nih_free not always freeing is weird
[22:00] <sadmac> Keybuk: but if you have an interest in API consistency (and it /is/ kind of convenient that we don't have to rewrite all that much right now) it might be better to keep the old symbol/
[22:00] <ion_> So the norm would be to nih_discard anything you allocated without a parent, and nih_unref anything you referenced. No nih_free.
[22:00] <Keybuk> heh
[22:01] <Keybuk> I just made nih_free assert
[22:01] <Keybuk> (if there were parents left)
[22:01] <Keybuk> lots of things broke
[22:01] <ion_> :-)
[22:01] <Keybuk> mostly test cases, by the looks of it
[22:01] <sadmac> Keybuk: what I would prefer is that if you are going to allocate without a parent, you /must/ assign the pointer to an nih_local. dunno what C gives us to enforce that though.
[22:03] <Keybuk> dunno, dig through the gcc ref manual ;)
[22:03] <sadmac> I've learned to like that thing
[22:04] <sadmac> Keybuk: I wonder what happens if you do void * nih_local my_func () {...
[22:05] <Keybuk> the attribute will apply to the function instead of the return value
[22:05] <sadmac> Keybuk: but it can't because its not a function attribute
[22:06] <Keybuk> so gcc will error
[22:06] <Keybuk> return types don't have variable attributes ;)
[22:06] <sadmac> probably
[22:06] <Keybuk> the __attribute__ binds right


[06:26] <dpm> good morning
[11:00] <johhnn> hello, in my app the indicator does not show on top panel when running the app as root? how to solve this?
[12:08] <newUSR> hi all
[12:09] <newUSR> have a question about organization of my app
[12:09] <newUSR> i've used quickly to create main layout
[12:11] <newUSR> now i want to add openGL window using gtkglext
[12:11] <newUSR> that openGL should be packed into preconstructed widget that i created in glade
[12:12] <newUSR> where should i do this?in main()?
[12:13] <newUSR> i really want to keep my app extensible and easy to upgrade
[12:13] <newUSR> .../correct
[12:15] <newUSR> any good suggestion is welcome...tnx
[12:56] <nandersson> Hi, where do I put my app.desktop-file when I package my .deb? I have had a look at the gnome-games packages for guidance but I couldnt find them. I looked in debian/ for .desktop-files but couldnt find any.
[14:36] <nandersson> Just found it in data/ thanks anyway :)
[14:38] <nandersson> One thing I am not clear about though is why an underline proceeds Name and Comment in gnomine.desktop.in.in:
[14:38] <nandersson> [Desktop Entry]_Name=Mines_Comment=Clear hidden mines from a minefield Exec=/usr/games/gnomine
[14:46] <dpm> nandersson, it is so that it can be marked for translation
[14:47] <dpm> if you leave out that underscore in the .in file, the name and comment will always be in English
[14:48] <nandersson> dpm, Ah, okey. Thanks a lot!


[01:14]  * jenkinbr is engaged :)
[01:15] <tonyyarusso> Congrats
[03:48] <tonyyarusso> Hey guys, the web site should be back up all happy on Karmic now.  Let me know if you notice any issues.
[04:17] <jenkinbr> sweet :)
[20:12] <Takyoji> See if you can find a way to get a Mini 10v with Ubuntu pre-installed: http://www.dell.com/content/products/productdetails.aspx/laptop-inspiron-10?c=us&l=en&s=dhs&cs=19
[20:12] <Takyoji> They made it VERY obscure now
[20:12] <Takyoji> Bonus points to anyone that can find it
[20:13] <Takyoji> (I have found it though, yes)
[20:16] <Takyoji> So basically on the basic overview they by default have it with XP, but now have given the option of Windows 7, while burying the option of Ubuntu much further from view.
[21:14] <Takyoji> I love how nobody cares. :P


[00:04] <harmw> harlowja:
[00:04] <harmw> pkg install python27 py27-yaml py27-requests py27-prettytable py27-cheetah py27-boto dmidecode e2fsprogs gpart sudo
[00:04] <harlowja> thx
[00:04] <harmw> and a python setup.py build with this one: https://pypi.python.org/packages/source/j/jsonpatch/jsonpatch-0.6.tar.gz
[00:04] <harmw> then get cloud-init source and setup.py that aswell
[00:05] <harmw> its bedtime here though
[00:05] <harmw> :)
[00:05] <harlowja> np
[00:05] <harlowja> then some rc.d stuff i guess?
[00:06] <harmw> ive only run it manually
[00:06] <harmw> after installing it
[00:06] <harmw> python setup.py build
[00:06] <harmw> python setup.py install -O1 --skip-build --root /
[00:06] <harlowja> k
[00:07] <harlowja> thx harmw
[00:07] <harmw> np
[00:09] <harlowja> will see how far we can get


[01:09] <mozmck> I'm trying to use pkexec in a bash script with no success.  I have a script called "installer" that just has the command "dpkg -i *.deb"  If I use gksudo ./installer, it works great.  But gksudo is not installed in Xubuntu by default so that is not an option for me.
[01:10] <mozmck> pkexec tells me it can't find ./installer  So I passed it the full path to the installer, and then dpkg says it can't find the deb files.  So I added a cd <location of files> in the ./installer script, and that didn't seem to help.
[01:11] <mozmck> Any idea what I'm doing wrong?
[01:11] <knome> mozmck, for starters, this isn't really the support channel
[01:11] <knome> !pkexec
[01:12] <mozmck> ok, which channel is?
[01:12] <knome> #xubuntu
[01:13] <mozmck> ok, thanks
[09:30] <Unit193> I seem to be missing the link to delete a testcase, I realized technically I did http://iso.qa.ubuntu.com/qatracker/milestones/351/builds/105604/testcases/1658/results
[09:50] <slickymasterWork> Unit193, are you an admin there?
[09:59] <Unit193> Of course not.
[10:02] <slickymasterWork> hmm, that's odd
[10:02] <slickymasterWork> because I am and I'm not seeing any delete option
[10:03] <slickymasterWork> I only have an 'Edit' option
[10:03] <slickymasterWork> flocculant ^^
[12:30] <knome> slickymaster, maybe you are not an admin, just an editor or sth
[12:33] <knome> Unit193, what exactly are you trying to delete?
[12:34] <knome> Unit193, move upgrade from the core testsuite to the upgrade testsuite?
[12:35] <knome> and tbe, i don't think there is a "delete" action, only disable
[12:35] <knome> which is silly because now the tracker is full with disabled things
[14:12] <flocculant> you can delete results - though they appear to just strike through
[14:13] <flocculant> Unit193: you've not got rights to do any of that - what exactly is it you want?
[14:36] <slickymasterWork> flocculant, but not testcases?
[18:36] <flocculant> slickymaster: nope - there till the electrons stop spinning on the server
[20:25] <Unit193> flocculant: Right, I was just trying to change *my* testcase results.  After running my usual, noticed the 'core upgrade', which technically fits mine better as I don't have xubuntu-desktop.
[20:25] <flocculant> aah right - you should be able to edit that
[20:26] <flocculant> mmm
[20:27] <flocculant> don't appear to see any from you
[20:28] <flocculant> oh nvm - assumed you were talking about core :p
[20:29] <flocculant> do you see a 'pencil' by your result - if you do you might be able to do something - if not I would need to delete it
[20:57] <Unit193> OK, I'll have to check.
[20:57] <Unit193> But, I did upgrade one hardware to Xenial! \o/
[20:57] <Unit193> Plymouth even seemed to work...
[20:58] <flocculant> woohoo
[20:58] <flocculant> Unit193: if you can't - add your new one and I'll nix the old one
[20:59] <Unit193> Ok, will do, have to head out now.
[20:59] <flocculant> yep - have a good whatever :)
[21:00] <Unit193> Yeah no, I'm helping someone go to the store, it'll be awful.
[21:00] <flocculant> :)
[21:23] <pleia2> flocculant: no word from jcastro re: vps, and I haven't seen him around this week :\
[21:24] <flocculant> k- kind of assumed that was the case or you'd have said something :)
[21:24]  * pleia2 nods
[21:24]  * flocculant guessed you'd say that too :p
[21:25] <flocculant> I guess we'll want to move - pretty sure knome  wants to - and one more assumption being you'd want to see the back of it too


[10:46] <qwebirc74334> Can anyone tell me the easiest way to wipe the list of channels out, and start all over again?
[10:47] <qwebirc74334> I re-ran the channel scan, and it got buggered with dupes, etc.


 Yes I just filled up
 Same
 Free Pandora for a year
 https://www.youtube.com/watch?v=zwgaTYOx0RI
 Ha, I just watched that a while ago
 about an hour ago
 I didn't know that's what single sign on meant.
 really Penn Dutch?
 @SivaMachina, Well played


[11:09] <clivejo> Hi, Kubuntu have filed a FFE for KDE software we'd like to get into Xenial, to date there has been no reply/update to the request, who would I need to speak to about that?
[12:30] <apw> you are at least asking in the right place i believe
[12:34] <clivejo> me?
[12:34] <knome> yes
[12:34] <knome> sending bribes to release team postal addresses usually works
[12:34] <knome> :P
[18:42] <coreycb> bdmurray, arges: hi, when you get a chance can you promote packages to -updates for bugs 1544568 1460164 1531963?
[18:44] <ogra_> can someone please let ubuntu-core-generic-initrd out of binary new ?
[18:46] <ogra_> (well, once ubuntu-core-generic-initrd actually hits the queue :P )
[19:10] <cking> can anyone devote some cycles to my FFE request for powerstat, LP#1550366


[01:40] <starcraft-ntbk> new doc member?
[13:59] <zul> morning
[13:59] <ttx> o/
[14:00] <mathiaz> o/
[14:01] <ttx> soren, smoser: ?
[14:01] <Daviey> \o - Apologies, can't be here for the meeting - please see my comments on the ubuntu-server ml regarding spamassassin
[14:01] <ttx> Daviey: will read -- see you next week ;)
[14:01] <Daviey> \o
[14:01] <smoser> 0/
[14:01]  * stgraber waves
[14:02] <ttx> #startmeeting
[14:02] <MootBot> Meeting started at 08:02. The chair is ttx.
[14:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:02] <ttx> Today's agenda:  https://wiki.ubuntu.com/ServerTeam/Meeting
[14:02] <ttx> [TOPIC] Review ACTION points from previous meeting
[14:02] <MootBot> New Topic:  Review ACTION points from previous meeting
[14:03] <ttx> ACTION: kirkland to add a recipe covering virsh to https://help.ubuntu.com/community/KVM/VirtManager
[14:03] <ttx> kirkland left a note about that on the meeting agenda
[14:03] <ttx> Done -- https://help.ubuntu.com/community/KVM/VirtManager and https://help.ubuntu.com/community/KVM/Virsh
[14:03] <ttx> ACTION: nurmi to investigate bug 455625
[14:03] <ttx> I don't think nurmi is around
[14:04] <ttx> I'll add two more two his list, since absents are always wrong...
[14:05] <ttx> [ACTION] numri to help validation/fixing bugs 460085 and bug 461156
[14:05] <MootBot> ACTION received:  numri to help validation/fixing bugs 460085 and bug 461156
[14:05] <ttx> smoser: no progress on that last one ?
[14:05] <soren> o/
[14:05] <smoser> no. i've not gotten around to digging there, and have sent irc pings but no response.
[14:05] <ttx> ok
[14:05] <ttx> ACTION: Daviey to investigate spamassassin status in lucid
[14:06] <ttx> Daviey sent an update about this on ubuntu-server ML
[14:06] <soren> He said he'd sent somethign to the...
[14:06] <soren> right.
[14:06] <ttx> ACTION: mathiaz to update the fridge
[14:06] <mathiaz> ttx: sent an email to news teeam
[14:07] <ttx> mathiaz: change is not effective yet ?
[14:07] <mathiaz> ttx: it is actually
[14:07] <ttx> good :)
[14:07] <ttx> [TOPIC] UDS: server track planning
[14:07] <MootBot> New Topic:  UDS: server track planning
[14:08]  * nijaba waves
[14:08] <ttx> mdz is not around, but he should work on scheduling the server track before the end of the week.
[14:08] <ttx> If you want to make sure he doesn't miss your blueprint, please name it server-lucid-* and set him as approver.
[14:09] <ttx> There can be two parallel sessions in the server track (as with other tracks)
[14:10] <ttx> so you should subscribe to the blueprints you are interested in to try to avoid scheduling conflicts
[14:10] <ttx> Any questions ?
[14:10] <zul> nope
[14:11] <zul> mdz is leading the tracks?
[14:11] <ttx> stgraber: some of yours are close to some others
[14:11] <ttx> zul: yes
[14:11] <ttx> server-lucid-desktop-cloud and server-lucid-nx
[14:11] <ttx> server-lucid-contextualization and server-lucid-non-accel-virt
[14:11] <ttx> Those might get scheduled on the same slot, I don't really know.
[14:11] <stgraber> ttx: right, I guess some of them weren't visible on LP at the time I added mine
[14:12] <ttx> stgraber: they probably were, but blueprint search is not so good :)
[14:12] <ttx> ok, moving on...
[14:12] <ttx> [TOPIC] Merging, merging, merging
[14:12] <stgraber> well, for the NX one, I guess we can discuss the big picture at one and the specific of getting NX in at the other
[14:13] <ttx> stgraber: right
[14:13] <MootBot> New Topic:  Merging, merging, merging
[14:13] <ttx> Lucid is open for merging, which is a great way to learn packaging for starters
[14:13] <stgraber> the other doesn't mention contextualization but alternate virtualization technologies, that's quite different (at least from my point of view)
[14:14] <ttx> stgraber: ok
[14:14] <ttx> mathiaz: do you think we should compile a list of easy merges ?
[14:14] <mathiaz> ttx: we could
[14:14] <mathiaz> ttx: it seems to have helped last time
[14:15] <ttx> mathiaz: do you have time to do that ?
[14:15] <mathiaz> ttx: I can have a look at it
[14:15] <ttx> + the relevant blogging publicity ?
[14:15] <ttx> ok
[14:15] <mathiaz> ttx: sure
[14:15] <ttx> [ACTION] mathiaz to compile a list of easy merges for publication
[14:15] <MootBot> ACTION received:  mathiaz to compile a list of easy merges for publication
[14:16] <ttx> mathiaz: note that there are quite a few easy Java library merges, however we are trying to commit to debian-java in parallel, so it might make sense to keep those alone
[14:17]  * mathiaz oks
[14:17] <ttx> Comments on the subject of merging ?
[14:17] <zul> there is a couple of syncs already taken care of as well
[14:17] <ttx> does the MoM output update ?
[14:18] <mathiaz> ttx: it should
[14:18] <ttx> It didn't reflect my merging so far
[14:19] <ttx> looks stuck at Nov 9
[14:19] <zul> yeah it looks like it hasnt been updated
[14:19] <mathiaz> ttx: yeah - Keybuk kicked off a new instance of MoM
[14:19] <mathiaz> ttx: as it used to sync from unstable
[14:20] <ttx> mathiaz: ...
[14:20] <mathiaz> ttx: it may take some time to do the first round of merges of testing
[14:20] <ttx> ok
[14:20] <ttx> [TOPIC] Assigned and to-be-assigned bugs
[14:20] <MootBot> New Topic:  Assigned and to-be-assigned bugs
[14:20] <mathiaz> ttx: so I don't know how usefull MoM is for now
[14:21] <ttx> http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[14:21] <MootBot> LINK received:  http://qa.ubuntu.com/reports/team-assigned/canonical-server-assigned-bug-tasks.html
[14:21] <ttx> Nothing needs assignment, comments on other bugs ?
[14:21] <zul> nope
[14:21] <ttx> I'll retest the eucalyptus in -proposed sometime today
[14:22] <mathiaz> ttx: great thanks
[14:23] <ttx> Moving on...
[14:23] <ttx> [TOPIC] Weekly SRU review
[14:23] <MootBot> New Topic:  Weekly SRU review
[14:23] <ttx> mathiaz: mind driving that part ?
[14:23] <mathiaz> ttx: nope
[14:23] <mathiaz> let's go ahead for the list review
[14:24] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[14:24] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ubuntu-server-team/fixedbugs.ubuntu-server.latest.html
[14:24] <zul> i have 2
[14:24] <mathiaz> anything worth SRU on this list?
[14:24] <zul> bug #403775
[14:25] <zul> and bug #479250
[14:25] <ttx> zul:  which series is affected ?
[14:25] <zul> both are for hardy
[14:26] <Keybuk> ttx: actually merges.ubuntu.com is entirely based off testing
[14:26] <Keybuk> it's stuck at Nov 9 because that's when the first v3 source package hit testing ;)
[14:27] <ttx> Keybuk: so the reports are not regenerated with new packages uploaded to lucid ?
[14:27] <Keybuk> correct
[14:28] <ttx> Keybuk: is that a bug or a feature ? :)
[14:28] <Keybuk> that it can't process v3 packages?
[14:28] <Keybuk> it's an RT ticket
[14:28] <ttx> Keybuk: ok, thx
[14:29] <mathiaz> ok - so all nomination lists are empty
[14:29] <mathiaz> http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[14:29] <MootBot> LINK received:  http://qa.ubuntu.com/reports/ubuntu-server-team/acceptedbugs.ubuntu-server.latest.html
[14:29] <mathiaz> ^^ list of accepted bugs that have an assignee
[14:29] <mathiaz> the eucalyptus SRU is on its way
[14:29] <ttx> zul: there is a new candidate for samba sru (again) something about winbind
[14:29] <zul> ttx: yeah I saw that this morning
[14:30] <zul> i wanted to talk to you about it first
[14:30] <ttx> bug 479955
[14:30] <mathiaz> zul: how are other SRU doing for hardy?
[14:30] <ttx> zul: ok, off-meeting
[14:30] <zul> mathiaz: good just looking for testers as usual
[14:31] <mathiaz> zul: ok
[14:31] <mathiaz> https://code.launchpad.net/~ubuntu-server/+activereviews
[14:31] <mathiaz> is empty
[14:31] <mathiaz> zul: are you using package branches?
[14:31] <zul> mathiaz: yep just been concentrating on lucid this week
[14:32] <mathiaz> zul: great.
[14:32] <mathiaz> that's all for the weekly SRU review
[14:32] <ttx> thanks mathiaz !
[14:32] <ttx> [TOPIC] Open Discussion
[14:32] <MootBot> New Topic:  Open Discussion
[14:33] <ttx> Who will be in not-so-sunny Dallas next week ?
[14:33]  * stgraber waves
[14:33] <zul> mememememme
[14:33] <mathiaz> o/
[14:33] <mjeanson> o/
[14:34]  * zul is looking forward to wearing short
[14:34] <ttx> A texan once told me that it never rained in Texas, but apparently he lied
[14:34] <zul> shorts even
[14:34] <ttx> http://www.weather.com/weather/tenday/USTX0327?from=36hr_topnav_undeclared
[14:34] <MootBot> LINK received:  http://www.weather.com/weather/tenday/USTX0327?from=36hr_topnav_undeclared
[14:35] <ttx> Looks like... Dublin in summer.
[14:35]  * nijaba wonders in what list should 450044 appear.  Status has not changed since last week.
[14:36] <ttx> bug 450044
[14:36] <nijaba> ttx: you had agreed last week that it was SRU worthy
[14:36] <ttx> I did ?
[14:36]  * nijaba thinks so...
[14:37] <ttx> note that I wasn't present at last week meeting ...
[14:37] <mathiaz> euca2ools is not part of the packages to which the ubuntu-server team is a bug contact
[14:37] <ttx> ah-ah
[14:37] <ttx> mathiaz: it should
[14:38] <mathiaz> ttx: it is now
[14:38] <ttx> I admit some ignorance on how euca-bundle-vol should behave
[14:38] <nijaba> ttx: it is fixed in eucalyptus, according to neil soman
[14:39] <nijaba> ttx: I think it would be a good idea to allow a very common operation to work with UEC
[14:39] <ttx> nijaba: ok, adding to my list, though I'm quite busy those days
[14:40] <nijaba> ttx: I bet you are, but sometime is better than never :)
[14:40]  * ttx wonders when was the last time he was /not/ busy
[14:40]  * nijaba just wanted to make sure this bug was not forgotten
[14:40] <ttx> any other subject ?
[14:41] <zul> ttx: before you started working on ubuntu?
[14:41] <ttx> zul: no, at the very beginning, I remember having some free time.
[14:42] <ttx> [TOPIC] Next meeting date and time
[14:42] <MootBot> New Topic:  Next meeting date and time
[14:42] <ttx> We'll skip next week
[14:42] <ttx> and be back on Nov 25, probably 1400 UTC again
[14:43] <ttx> though we are still trying to better accomodate the west coast.
[14:43] <mathiaz> works for me
[14:43] <ttx> #endmeeting
[14:43] <MootBot> Meeting finished at 08:43.
[14:43] <nijaba> Thanks ttx
[14:44] <mathiaz> thanks ttx
[14:44] <nijaba> See you in Dalla
[14:44] <nijaba> Dallas too :)
[14:44] <stgraber> thx, see you all in Dallas
[14:46] <ttx> o/
[16:59] <davmor2> hello
[17:00] <ara> hello
[17:01] <cr3> ahoy, mateys
[17:01] <ara> today all the US folks won't attend, so it should be a quick meeting :-)
[17:02] <ara> OK, let's start
[17:02] <ara> #startmeeting
[17:02] <MootBot> Meeting started at 11:02. The chair is ara.
[17:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:03] <ara> Agenda:
[17:03] <ara> # SRU testing -- sbeattie (Steve Beattie)
[17:03] <ara> # Bugday highlights -- pedro
[17:03] <ara> # Testing Team blueprint
[17:03] <ara> [TOPIC] -  SRU testing -- sbeattie (Steve Beattie)
[17:03] <MootBot> New Topic:  -  SRU testing -- sbeattie (Steve Beattie)
[17:03] <ara> sbeattie is on holiday, but he asked me to pass his SRU report here
[17:04] <ara> he's very committed :-)
[17:04] <ara> Stable Release Update (SRU) Acivity for the past week (since 2009-11-04):
[17:04] <ara> * karmic: 40 new packages in -proposed and 46 packages pushed to -updates
[17:04] <ara> * jaunty: 3 new packages in -proposed (clamav, kvm, landscape-client) and 4 packages pushed to -updates (isdnutils, kdepim, pm-utils, pythonmagick)
[17:04] <ara> * intrepid: no package activity (except security updates)
[17:04] <ara> * hardy: 2 new packages in -proposed (apache2, lilo-installer) and 1 package pushed to -updates (pidgin)
[17:04] <ara> * dapper: no package activity (except security updates)
[17:05] <ara> Thanks to Simon Déziel, Id2ndR, madbiologist, Bernhard, Kenneth Pålsson, Charles Curley, Ariel Faigon, Francis Russell, mzc, Lemmiwinks, Brian O'Keefe, fabrice_sp, sigvdr, Psycona, Luca Ferretti, Roman Fiedler, squishlikeabug, nentis, Edward, Evan Broder, Imre Gergely, Alex Muntada, Anders Virving, Neil Messenbird , cochisebt, Andreas Wenning, Rod Davison, Christophe Sauthier, Nicolas Adenis-Lamarre, Stephen Laverty, Matti Hi
[17:05] <ara> ljanen, starslights, Matej Kenda, Mattias Holmlund, Paul Elliott, olive, YoBoY, prometheus, Peter Whittaker, Peter Lyons, Nathan Handler, Andrea Veria, Alessio Treglia, las, Tobias Kerzenmacher and others for testing SRUs this week.
[17:05] <ara> Lots of people!
[17:05] <pedro_> things are looking good there, as per http://people.canonical.com/~ubuntu-archive/pending-sru.html
[17:05] <ara> help would be appreciated with SRUs that have been sitting in the -proposed queue for a while (http://people.canonical.com/~ubuntu-archive/pending-sru.html lists the length of time a given package has been waiting).
[17:06] <pedro_> yeah, especially bug 444979 and bug 462626
[17:07] <pedro_> thanks for nothing ubottu
[17:07] <ara> nice, Launchpad :)
[17:08] <ara> OK, next topic
[17:08] <pedro_> well those are the oldest sru there, so might need a bit more of attention
[17:08] <ara> indeed
[17:08] <ara> one wonders where the original reporter is :)
[17:08] <ara> [TOPIC] Bugday highlights -- pedro
[17:08] <MootBot> New Topic:  Bugday highlights -- pedro
[17:08] <ara> pedro_ even
[17:09] <pedro_> right so past week we had the Gwibber hug day https://wiki.ubuntu.com/UbuntuBugDay/20091105
[17:09] <pedro_> not a lot of people contributed though, but we managed to triage a lot of reports there
[17:09] <ara> who is kamus?
[17:09] <pedro_> ~48 or so
[17:09] <ara> he/she did a great job there
[17:10] <pedro_> ah kamus is a bugsquad member, he's always rocking on the bug days
[17:10] <pedro_> yes big thank to him and to Adam
[17:10] <pedro_> and tomorrow we're having a bug day based on Nautilus https://wiki.ubuntu.com/UbuntuBugDay/20091112
[17:11] <pedro_> so any help is more than welcome
[17:12] <pedro_> that's all from here
[17:12] <ara> OK
[17:12] <ara> [TOPIC] Testing Team blueprint -- ara
[17:12] <MootBot> New Topic:  Testing Team blueprint -- ara
[17:12] <ara> OK, as you may now know, we want to improve the way we test in Ubuntu for Lucid
[17:13] <ara> We are working on creating a new Testing team with regular meetings, mailing list, roadmaps etc.
[17:13] <ara> We are going to be discussing the topic in UDS Dallas, so if you are interested, please, subscribe to the blueprint
[17:13] <ara> https://blueprints.launchpad.net/ubuntu/+spec/lucid-qa-testing-team
[17:14] <ara> also, in the Spec, under BoF agenda, you can add the items you think are worth discussing
[17:14] <ara> https://wiki.ubuntu.com/Specs/TestingTeam
[17:14] <pedro_> is that blueprint/discussion already scheduled?
[17:15] <ara> yes, it is wednesday, in the latest slot of the day (IIRC)
[17:15] <pedro_> maybe people can attend to it remotely, IRC always help
[17:15] <pedro_> cool
[17:15] <ara> yes, of course, remote attendees are more than welcome
[17:16] <davmor2> not that late I don't think I will
[17:17] <ara> davmor2, :)
[17:17] <ara> OK, that's everything for me
[17:17] <ara> anything else?
[17:17] <davmor2> Nope
[17:18] <ara> any other topics?
[17:18] <davmor2> nope
[17:18] <pedro_> noup just a quick question
[17:19] <ara> pedro_, yes?
[17:19] <pedro_> regarding the uds schedule, do you know why the sessions don't appear on http://summit.ubuntu.com/uds-l/track/qa/
[17:20] <pedro_> but they do on the daily ones
[17:20] <ara> pedro_, I think per track is broken in the summit site
[17:20] <ara> jono ? ^
[17:20] <pedro_> i'm a bit confuse about that
[17:21] <ara> I will ask jono again and will send an email about to ubuntu-qa
[17:22] <pedro_> ah might be that, not really important though just a little doubt
[17:22] <pedro_> ara, awesome, thank you
[17:22] <ara> OK, I think we can wrap up
[17:23] <ara> #endmeeting
[17:23] <MootBot> Meeting finished at 11:22.
[17:23] <ara> Thanks guys :)
[17:23] <pedro_> thanks
[17:23] <davmor2> bye
[17:27] <jono> ara, that is broken, known bug
[17:27] <jono> jcastro ^
[17:27] <jono> a fix is in the works
[17:27] <jono> jcastro can follow up
[17:28] <ara> thanks jono
[23:53] <johnvilsack> Greetings folks!  The Ubuntu Community Marketing Team meeting will begin in about ten minutes.  I'd like to give folks a few minutes to gather and come in if they would like :)
[23:54] <johnvilsack> If I'm doing this wrong, please let me know :)  This is my first time moderating such a meeting here.
[23:54] <DPic> doing great johnvilsack =]
[23:54] <johnvilsack> I appreciate the encouragement! :)