[00:23] <smspillaz> bregma: you around ?
[00:23] <smspillaz> bregma: I'm not sure what your view is on encoding Interface/Impl names, if you could clarify that would be great
[00:30] <smspillaz> Trevinho: ^ would be good to get your thoughts on that
[00:30] <smspillaz> I know that the style guide document says "use -Interface" but I also know that lots of people hate -Interface
[00:31] <Trevinho> smspillaz: I'm not sure I got what you mean...
[00:32] <smspillaz> Trevinho: do you prefer interface classes to be named FooInterface or Foo
[00:33] <smspillaz> and is that the general preference
[00:33] <Trevinho> Ah... I'd prefer FooInterface... or AbstractInterface if that's the case
[00:33] <Trevinho> sorry
[00:33] <Trevinho> AstractFoo
[00:33] <smspillaz> Trevinho: AbstractFoo ?
[00:33] <smspillaz> okay :)
[00:34] <Trevinho> yeah, sorry :P
[00:34] <bregma> I prefer Foo as the interface and use the bridge pattern
[00:34] <smspillaz> no problem, was just looking for what people preferred
[00:34] <smspillaz> bregma: okay, so whats the verdict :)
[00:34] <smspillaz> bregma: Foo/FooImpl or AbstractFoo/Foo ?
[00:35] <smspillaz> (one of the things I don't like about code review is that reviewers almost always disagree on style :))
[00:36] <bregma> I don't like having structure creep into names in APIs, so I dislike Abstract, and Impl implies a private implementation behind the interface so it should never leak out
[00:36] <bregma> so I prefer Foo/Foo::Impl
[00:38] <smspillaz> bregma: Trevinho: what's the verdict then, and can we get this written down somewhere ?
[00:38] <bregma> yes, I'd like to get it written down
[00:39] <Trevinho> smspillaz: we have the style docs... they probably should be updated with these things too
[00:39] <smspillaz> bregma: btw, when you say Foo::Impl, do you mean a subclass? eg, Foo::Impl ?
[00:39] <smspillaz> erm, class Foo::Impl
[00:39] <bregma> yes, a nested class
[00:39] <bregma> using the pimpl idom
[00:39] <smspillaz> bregma: well, it wouldn't quite be nested
[00:40] <smspillaz> erm , a pimpl
[00:40] <smspillaz> bregma: but if you mean something like having the interface class with a static factory method which returns Foo::Impl through its interface then I guess that's okay
[00:41] <bregma> is the goal not to separate interface from implementation, to allow the implementations and interfaces to vary independently (ie. a Nux implementation, a mock interface)?
[00:41] <smspillaz> bregma: yes, Extract Interface
[00:45] <bregma> I think the best approach is to use the pimpl idiom (the bridge pattern) and have the interface class constructor take a factory function that defaults to creating the usual Nux-based implementation
[00:45] <bregma> a factory function that creates a mock implemntation can be used for the tests
[00:46] <smspillaz> bregma: that's not a pattern I've seen before, but its somewhat workable (although I'm a bit skeptical of interfaces having constructors)
[00:47] <bregma> I would really like to see as much nux as possible hidden behind facades
[00:47] <smspillaz> bregma: actually that could get a little awkward
[00:48] <smspillaz> if you wanted to create a MockFoo on the stack, that inherited from foo, you'd have to provide a "constructor" which returns a reference to the same thing in order to satisfy the interface constructor
[00:48] <smspillaz> erm, a "factory function"
[00:49] <smspillaz> bregma: do you want me to provide a sample of what I'm thinking of so I know we're both on the same page ?
[00:49] <bregma> it could be a little awkward if it goes too far, but right now it makes testing and maintenance harder because it's almost impossible to reason about functionality when a class has a 10-level inheritance heirarchy, ober 100 member functions, and 50 public member variables
[00:50] <smspillaz> bregma: I know :)
[00:50] <smspillaz> bregma: what I'm suggesting is that your method of having the interface class take a factory function is the awkward part
[00:50] <smspillaz> not the interface itself
[00:51] <bregma> I disagree, I've used that design before without problems
[00:51] <bregma> just not with nux and properties and introspection
[00:51] <smspillaz> bregma: hmm, okay. I'll just hack something together to see if we're both on the same page here
[00:52] <bregma> I've been playing wit hthe Switcher classes for the last few days for #824965, before I looked at your MP
[00:52] <bschaefer> smspillaz, hey, when you get a chance, can you take a look at this: https://code.launchpad.net/~brandontschaefer/compiz/lp.1002246-check-valid-strut-windows/+merge/140569
[00:52] <smspillaz> bschaefer: sure
[00:53] <bregma> so I'm pretty certain we have the same goals
[00:53] <smspillaz> bregma: ah, hence the review :)
[00:53] <bschaefer> smspillaz, thanks, im not sure how I feel about it but its a tough problem to fix
[00:53] <smspillaz> bschaefer: actually, what was the problem with using ~PlaceWindow ?
[00:53] <bschaefer> smspillaz, the ~PlaceWindow gets called after the DestoryNotify event
[00:54] <smspillaz> bschaefer: yep, its supposed to
[00:54] <bschaefer> which the problem is the DestroyNotfiy is coming into compiz to later
[00:54] <bschaefer> to late*
[00:54] <smspillaz> does it come after the countdown timer ?
[00:54] <bregma> smspillaz, the review was actually because I'm trying to get through the backlog of MPs, it's just a coincidence
[00:54] <smspillaz> bregma: :)
[00:54] <smspillaz> bregma: great to see you're doing that
[00:54] <bschaefer> smspillaz, the count down is super late (The Fallback one)
[00:55] <bschaefer> smspillaz, which happens after everything
[00:55] <smspillaz> bschaefer: have you tried bumping up the timer ?
[00:55] <smspillaz> oh
[00:55] <bschaefer> hmm no I have not
[00:55] <smspillaz> well in that case it shouldn't be a problem
[00:55] <smspillaz> as long as we only ever hit the doHandleScreenSizeChangeFallback code after we get the DestroyNotify for the unity windows
[00:55] <smspillaz> I mean what should happen is this:
[00:56] <bschaefer> yeah that is what happens, the fall back is way after the DestroyNotify
[00:56] <bschaefer> the problem is we collect these windows, then we destroy the window, leaving the destroyed windows in the list
[00:56] <bschaefer> but the destoryed windows are still valid to compiz, but not the xserver
[00:57] <bschaefer> until the DestroyNotify comes through
[00:57] <smspillaz> ConfigureNotify on root window -> Place::handleScreenSizeChange -> strut windows collected -> Unity::handleScreenSizeChange -> unity struts destroyed -> Nondestroyed struts send a PropertyNotify (remove them from list) -> Destroyed struts send a DestroyNotify (-> ~PlaceWindow -> remove from list) -> mStrutWindows should now be zero, call doHandleScreenSizeChange
[00:58] <smspillaz> bschaefer: right, what I'm trying to say is that you can remove the windows from mStrutWindows and call if (mStrutWindows.empty()) doHandlescreenSizeChange () from within ~PlaceWindow
[00:58] <smspillaz> PlaceWindow has a private member variable "window", and you just call mStrutWindows.remove (window)
[00:59] <bschaefer> i tried that and .... hmm
[00:59] <bschaefer> now im wondering why it didn't work
[00:59] <smspillaz> The only reason I can see it not working is if the non-destroyed strut windows don't update their struts
[01:00] <smspillaz> in which case we just do the fallback anyways
[01:00] <bschaefer> thats what happens, it is destroyed, but compiz holds the struts still, so to compiz the struts are still valid
[01:00] <smspillaz> however if the DestroyNotify comes before the fallback, then there's really no problem
[01:00] <bschaefer> until the the destroy
[01:00] <smspillaz> bschaefer: ah
[01:00] <bschaefer> I even tried updateStruts()
[01:00] <bschaefer> but that didn't seem to work either which was odd
[01:01] <smspillaz> right it will just error out
[01:01] <bschaefer> yu[
[01:01] <smspillaz> .. I think
[01:01] <bschaefer> well
[01:01] <smspillaz> actually
[01:01] <bschaefer> it should set it to false if hasNew is false
[01:01]  * bschaefer has to double check
[01:01] <bschaefer> its a huge function
[01:02] <smspillaz> bschaefer: src/window.cpp: after the second XGetWindowProperty
[01:02] <smspillaz> add an else block after that first if () check
[01:02] <smspillaz> that sets hasNew to true
[01:03] <bschaefer> smspillaz, well I would still have to update the list...but instead of doing XGetGeometry
[01:03] <smspillaz> if both properties fail to be read then we should assume that the window has no struts
[01:03] <bschaefer> do update struts on each one
[01:03] <smspillaz> bschaefer: okay, so two things
[01:03] <bschaefer> smspillaz, is it setting it to false?
[01:03] <smspillaz> bschaefer: yes
[01:03] <bschaefer> o there it is
[01:03] <smspillaz> bschaefer: so first you need to update the list on ~PlaceWindow
[01:03] <bschaefer> alright
[01:03] <smspillaz> and second you need to call w->updateStruts () before updating the list
[01:03] <smspillaz> with that small fix applied
[01:04] <bschaefer> smspillaz, the small fix being the w->updateStruts call?
[01:04] <smspillaz> the small fix being the hasNew = false
[01:04] <smspillaz> after
[01:04]  * bschaefer still needs to change the indention for reading compiz files
[01:05] <smspillaz> http://paste.ubuntu.com/1448984/
[01:05] <bschaefer> it should be getting set to false on line 974
[01:06] <bschaefer> oo right
[01:06] <smspillaz> bschaefer: use qtcreator and go into tool -> editor settings -> c++, change "always use spaces" to off, change "indent width" to 4 and "tab width" to 8
[01:06] <smspillaz> quickest way to get compiz style
[01:06] <bschaefer> I use vim, and I have the compiz stuff commented out
[01:06] <bschaefer> i've just been to lazy to go edit that haha
[01:07] <bschaefer> smspillaz, hmm wont it still be false if this fails though? if (result == Success && data)
[01:08] <bschaefer> overall it says if (!hasNew)
[01:08] <bschaefer> so its false coming into this function
[01:08] <bschaefer> or cond sorry
[01:08] <smspillaz> yes, it is
[01:08] <smspillaz> so the way that function works
[01:08] <smspillaz> is that it checks _NET_WM_STRUT_PARTIAL
[01:08] <smspillaz> and then if that fails it goes to _NET_WM_STRUT
[01:08] <smspillaz> if either one succeeds, it sets the new strut values
[01:09] <smspillaz> both calls to XGetWindowProperty are going to fail because the window does not exist
[01:09] <smspillaz> so, in that case, we should reset its struts back to zero
[01:09] <smspillaz> hence the hasNew = true
[01:09] <bschaefer> yes, so result should not == Succes though
[01:09] <smspillaz> correct
[01:09] <bschaefer> but isn't it already false?
[01:09] <smspillaz> result ?
[01:09] <smspillaz> or hasNew ?
[01:10] <bschaefer> result = XGetWindowProperty (screen->dpy (), priv->id,
[01:10] <bschaefer> will get result != false
[01:10] <bschaefer> i mean
[01:10] <bschaefer> result will not equal success, but hasNew at this point is already fase
[01:10] <bschaefer> false
[01:10] <smspillaz> yes
[01:10] <bschaefer> f (!hasNew)
[01:10] <smspillaz> and you want to se it to true
[01:10] <bschaefer> ooooo
[01:10] <smspillaz> sorry, I typoed it in my pastebin
[01:10] <bschaefer> that is what I got confused about :)
[01:11] <smspillaz> http://paste.ubuntu.com/1448991/
[01:12] <bschaefer> smspillaz, hmm but don't we want line 1145 to be ran?
[01:12] <bschaefer>       priv->struts = NULL;
[01:13] <bschaefer> smspillaz, ill play around with it, thanks!
[01:14] <smspillaz> hmm
[01:14] <smspillaz> okay, actually I'm wrong
[01:15] <smspillaz> bschaefer: check that in its current implementation, priv->struts is indeed set to NULL when you call updateStruts
[01:15] <bschaefer> it seems we need this to be true: hasOld != hasNew ||
[01:16] <smspillaz> that should be the only thing that matters
[01:16] <bschaefer> smspillaz, alright, ill check that because I tried this twice and it seemed to work when I was doing XGetProperty, but when I removed that it seemed to fail to set it to false
[01:16]  * bschaefer might have been forgetting to flush X
[01:16] <smspillaz> then on ~PlaceWindow you can do (window->updateStruts (); mStrutWindows.remove(window); if (mStrutWindow.empty ()) doHandleScreenSizeChange ());
[01:16] <smspillaz> bschaefer: XGetWindowProperty is a sychronous operation there's no need
[01:17] <smspillaz> gotta run bbl
[01:17] <bschaefer> smspillaz, alright, thanks a lot!
[01:17] <bschaefer> (i meant that XGetWindowProperty() was causing things to be flush, ie. why updateStruts() worked when that was there)
[01:17]  * bschaefer is most likely wrong
[01:18] <smspillaz> XGetWindowProperty calls _XReply which is an implicit flush-and-sync
[01:19] <bschaefer> o cool, good to know
[01:22] <smspillaz> bregma: yeah, no so sure about the default constructor. Here is what I think you're talking about
[01:22] <smspillaz> bregma: http://paste.ubuntu.com/1449009/
[01:23] <smspillaz> Foo.h has a depedency on FooImplFactory.h
[01:23] <smspillaz> not really sure you want that
[01:23] <smspillaz> bbl
[01:25] <smspillaz> bregma: if I'm wrong, can you paste an example of what you're talking about ?
[01:36] <bschaefer> well awesome, that worked....I must have been doing something horribly wrong haha
[02:08] <bregma> smspillaz, I'm in and out, I'll try to post what I mean in a bit
[02:42] <smspillaz> bschaefer: :)
[02:42] <smspillaz> bregma: okay, no problem. I'll split up the proposals now while I'm waiting
[04:20] <bregma> smspillaz, http://paste.ubuntu.com/1449232/ -- an example taken from another project with some global substitution of class names for clarity
[04:20] <bregma> not in Unity code style
[04:21] <smspillaz> bregma: thanks, I'll take a look
[04:22] <bregma> I have no idea if it's clear or not, but it compiles and runs
[04:22] <smspillaz> bregma: ah right
[04:22] <smspillaz> bregma: see my issue there is that you've got a dependency on Controller::Impl within Controller
[04:23] <smspillaz> this looks more like the pimpl idiom than it does the bridge pattern
[04:24] <bregma> the pimpl idiom _is_ the bridge pattern
[04:25] <smspillaz> bregma: well, in this implementation it is, yes
[04:26] <smspillaz> bregma: it is clever though, no virtual functions in the interface
[04:26] <bregma> virtual functions in the interface cause Fragile Base Class syndrome
[04:26] <smspillaz> agreed
[04:26] <smspillaz> bregma: I wanted to do something like this for compiz in fact :)
[04:27] <smspillaz> bregma: that being said, the controller interface is internal. I'm not too worried about ABI stability there
[04:27] <bregma> true, force of habit doing years of library API development on my part
[04:28] <smspillaz> bregma: its a good habit
[04:28] <smspillaz> bregma: anyways. I can do it like this if you want
[04:28] <smspillaz> it would be quite different to most of the code in unity though
[04:28] <bregma> but simple, solid interfaces make testing easier and reasoning about the code easier
[04:28] <bregma> and we can modify the other faces gradually as we do other things
[04:29] <smspillaz> I agree
[04:29] <smspillaz> testing will be a bit more awkward though
[04:29] <smspillaz> you'll have something like this:
[04:29] <smspillaz> bregma: actually hmm
[04:30] <smspillaz> bregma: see the thing with testing and google mock generally is that we need to have access to the underlying MockFoo in order to set expectations on it
[04:30] <bregma> yes, which means the Impl will have to be a mock object
[04:30] <smspillaz> right, but I need to have access to it
[04:31] <smspillaz> which means either adding a getter to Controller to get a MockImpl (not gonna happen) or having this awkward "CreateImplFunction" which just returns a reference to the existing mock object
[04:31] <smspillaz> so you'd have something like (just thinking aloud)
[04:31] <smspillaz> MockFoo::Ptr p (new MockFoo);
[04:32] <smspillaz> Controller::CreateImplFunction f ([&]{ return p; })
[04:32] <smspillaz> Controller c (x, y, f);
[04:32] <smspillaz> would that make sense ?
[04:33] <bregma> why not just Controller c(x, y, [](){return Ptr(new MockImpl); });  ?
[04:33] <bregma> oh, wait
[04:33] <smspillaz> bregma: because I need to have access to the actual MockImpl
[04:33] <bregma> yeah, I just realized
[04:33] <smspillaz> unless you want to make an interface for MockImpl
[04:33] <smspillaz> ;-)
[04:33] <smspillaz> An interface for your interface!
[04:34] <smspillaz> bregma: btw, some people don't like NVI, prepare for some disagreement on reviews :)
[04:34] <bregma> no no, the Ptr type is a unique_ptr, you can use a unique_ptr on a stack-based object
[04:34] <smspillaz> or it might just be the NV/P/I strain of NVI
[04:35] <bregma> I'm not so worried about reviews, I have a big club I can weild if I have to
[04:35] <smspillaz> bregma: you can use unique_ptr on the stack ?
[04:35] <smspillaz> wouldn't that mean that CreateImplFunction would have to return a const unique_ptr <Controller> & >
[04:35] <smspillaz> ?
[04:35] <bregma> yes, the defaulted second argument is the deleter object, which can just do nothing
[04:36] <smspillaz> (since unique_ptr is noncopyable iirc)
[04:36] <smspillaz> or rather, it sets the old one to NULL
[04:36] <smspillaz> which isn't really what you want
[04:36] <smspillaz> impl would have to be shared
[04:37] <bregma> it's better if it's unique and a special deleter is used for mock impls
[04:37] <bregma> "there can be only one"
[04:37] <smspillaz> bregma: yeah, just the issue is this:
[04:37] <smspillaz> unique_ptr <MockImpl> mock (new MockImpl)
[04:38] <smspillaz> controller (x, y, [&](){ return mock; } -> Impl::Ptr &)
[04:38] <smspillaz> now mock is NULL
[04:38] <smspillaz> (I'm sure that lambda syntax was not correct, just ignore it :))
[04:40] <smspillaz> bregma: so can I make it shared ?
[04:41] <bregma> unique_ptr only runs the deleter on the underlying pointer, it does not null it out, that's why you need to supply a null deleter
[04:41] <bregma> I'm trying to find an example
[04:43] <bregma> this one has an example: http://stackoverflow.com/questions/8274451/well-how-does-the-custom-deleter-of-stdunique-ptr-work
[04:43] <smspillaz> bregma: ah, thanks. TIL
[04:44] <bregma> I expect to see some hairy stuff from people like Alexandrescu when more people start experimenting with std::unique_ptr
[04:45] <smspillaz> bregma: sadly there is no "one true style" for C++
[04:45] <smspillaz> its all "my opinion is that"
[04:46] <smspillaz> bregma: BTW, do you mind if I rename SwitcherView to View?
[04:46] <smspillaz> I'll call the default implementation NuxView
[04:46] <smspillaz> they both sit in unity::switcher
[04:46] <bregma> it would be more consistent with switcher::controller
[04:47] <smspillaz> :)
[04:47] <smspillaz> bregma: BTW, I hope I don't come across as argumentative. I was just trying to work through the thought process. Thanks for the advice :)
[04:48] <bregma> no problem, I've been ruminating on this for a while so it's good to hash it out
[04:48] <smspillaz> :)
[04:49] <bregma> it's nice to do something non-administrative, too...  too much management, not enough programming these days
[04:49] <smspillaz> why is that a common theme?
[04:49] <smspillaz> bregma: you know its awesome, since I've left, I can actually be productive now
[04:50] <smspillaz> the great irony of employment
[04:51] <bregma> yeah, like the irony or working from home:  less time commuting but much much more time working
[04:51] <bregma> in fact, it's nearly midnight here and I have to get up in a few hours to start my day
[04:51] <smspillaz> bregma: I always thought this would happen: http://theoatmeal.com/comics/working_home
[04:52] <smspillaz> bregma: heh, get some sleep maybe. I figured it was late. Nice talking :)
[04:53] <bregma> heh, comic nailed it
[04:54] <smspillaz> I love the oatmeal. Frank and to the point
[05:16] <Al562> Hello, does anyone know how to reset keyboard shortcuts back to default??
[07:39] <smspillaz> hmm
[07:39] <smspillaz> bschaefer: you around ?
[07:40] <bschaefer> smspillaz, ish, whats up?
[07:40] <smspillaz> bschaefer: can you check if the standalone switcher crashes on startup for you?
[07:40] <bschaefer> smspillaz, sure
[07:40] <smspillaz> I'm doing some refactoring and its crashhing in an odd place that I haven't touched but I don't want to recompile all of unity
[07:41] <bschaefer> hmm nope doesn't seem to seg fault for me
[07:41] <smspillaz> okay, thanks, I'll keep looking into this
[07:41] <bschaefer> though its a bit odd...good luck!
[07:41] <bschaefer> I should head off to bed...
[07:49] <smspillaz> ah, FFS
[07:49] <smspillaz> you have to install it to run the examples
[10:43] <gatis> According to X11 specification XGrabKeyboard() should grab all keyboard events exclusively to my client, but its not the case for Super_L (windows key), Alt, which trigger Unity shortcuts
[10:43] <gatis> any ideas why Unity doesn't respect GrabKeyboard ?
[12:23] <smspillaz> gatis: I think GrabKeyboard does not override passive grabs
[12:23] <gatis> smspillaz: i found this https://bugs.launchpad.net/unity-2d/+bug/964414
[12:24] <gatis> i think that the culprit
[12:24] <smspillaz> yeah if I remember correctly that was a lot more complicated than it seemed
[12:27] <smspillaz> gatis: are you running precise or quantal ?
[12:27] <sil2100> I thought that thing got finally resolved?
[12:28] <sil2100> This bug I mean
[12:28] <smspillaz> "resolved"
[12:28] <smspillaz> if I remember correclty we added a workaround to not use the tap detection code on the super key
[12:29] <gatis> smspillaz: precise
[12:29] <smspillaz> gatis: yeah I dunno if we ever backported it
[12:30] <gatis> ah, then i will need to install quantal one day to verify
[12:35] <sil2100> hm, I think we had packages prepared for precise
[12:36] <sil2100> But indeed those never got released I think
[12:36] <sil2100> Since we were working on packaging the workaround on UDS
[12:51] <Mirv> the fix is only in raring because there is a side-effect being investigated by brandon (dash pops up when display is switched)
[12:52] <Mirv> if that can be tackled and also that fix backported, then we could finally move forward to releasing the fixes in 12.10 & 12.04. but it seems complicated.
[12:53] <Mirv> btw, I now summarized the Compiz unredirection status at http://losca.blogspot.fi/2012/12/compiz-fullscreen-unredirection-update.html
[12:56] <smspillaz> Mirv: what graphics hardware are you running ?
[13:01] <Mirv> smspillaz: depends on machine... sandybridge quantal, radeon precise machines for example
[13:02] <Mirv> smspillaz: if you refer to the display switch / dash pop up, that happens with the hardware key of at least dell xps 13 which is wired to output super+p
[13:25] <smspillaz> Mirv: I was wondering if you had any machines with nvidia cards
[13:25] <smspillaz> need testers for the buffer_age stuff
[13:25] <smspillaz> though I guess it just generally needs testing
[13:29] <Mirv> smspillaz: sil2100 now has one, running precise though
[13:29]  * sil2100 has one
[13:29] <smspillaz> ah
[13:29] <sil2100> It's an old machine though
[13:30] <sil2100> And it has precise only
[13:30] <smspillaz> sil2100: <8300GT ?
[13:33] <sil2100> smspillaz: yes, 7400Go if I remember correctly
[13:33] <smspillaz> sil2100: yeah, they've moved it to -legacy now
[13:36] <sil2100> Poor old laptop... :(
[13:39] <smspillaz> sil2100: I couldn't get the newer version of osx my my desktop machine too (2006 iMac)
[13:54] <popey> smspillaz, i have one running raring
[13:55] <popey> smspillaz, GTX 460 if that's any use
[13:59] <smspillaz> popey: go test ppa:smspillaz/compiz-experimental and file bugs/oddities/whatever with the compiz-experimental-ppa :)
[13:59] <smspillaz> performance improvements inbound
[13:59] <smspillaz> (with the compiz-experimental-ppa tag)
[13:59] <smspillaz> I accidentally a word
[14:09] <popey> smspillaz, ok
[14:12] <smspillaz> popey: :)
[14:12] <popey> smspillaz, anything in particular I should be looking for?
[14:12] <smspillaz> flickery things
[14:13] <popey> roger
[14:13] <smspillaz> its basically a combination of recycling backbuffers (drawing less stuff) partial updates in nux (drawing less stuff)
[14:14] <smspillaz> any time you get (drawing less stuff) wrong it usually means flickering, bleeding or trails
[14:14] <smspillaz> popey: the ones I know about are a crash on dragging launcher icons, and flickering when using the workspace switcher
[14:24] <popey> smspillaz, package in your ppa wants to remove loads of stuff
[14:25] <popey> smspillaz, paste.ubuntu.com/1450079
[14:31] <smspillaz> popey: great, I guess I'll have to refresh the version numbers
[14:31] <smspillaz> I hate debian packages
[14:31] <popey> :)
[14:31] <smspillaz> let me go on the record as saying: debian is the worst distribution ever.
[14:31]  * smspillaz quickly vacates the room
[14:32] <popey>  /kickban smspillaz
[14:33] <smspillaz> popey: hmm, I don't really care about the fact that its removing unity-2d ... 1) do you have the staging ppa enabled? 2) could you grab me the output of apt-cache policy unity ?
[14:33] <smspillaz> popey: okay, so debian is the worst distribution I've ever used BUT
[14:33] <popey> i have the daily desktop ppa enabled
[14:33] <popey> i can remove it
[14:33] <popey> revert to stock
[14:33] <smspillaz> I've only ever used debian based distros so
[14:33] <smspillaz> XD
[14:33] <smspillaz> popey: this one at least depends on ppa:unity-team/staging
[14:34] <popey> oh, ick
[14:34] <popey> meh, my system is now in a mess
[14:35] <smspillaz> its not in a mess until it doesn't boot
[14:35] <smspillaz> even then its not /really/ in a mess until your kernel image is corrupt and you don't have any other kernel images
[14:35] <smspillaz> then you're screwed
[14:36]  * smspillaz has recovered a system from kernel and init=/bin/bash before, not fun
[14:38] <popey> yeah, need to fiddle a bit
[15:13] <Trevinho> mterry: ready for your review: https://code.launchpad.net/~3v1n0/bamf/soname-up/+merge/140695 ;)
[15:14] <mterry> trevinho, thanks!
[15:41] <Trevinho> mterry: I've updated it to 4, since it was never done before... And I'd like to keep it synced with major version... But if that's something too big, I'll move to just 1.0.0...
[15:41] <mterry> synced with major version?
[15:42] <mterry> oh is the version 4.x.x for bamf in general?
[15:42] <Trevinho> mterry: yes
[15:42] <mterry> Trevinho, well I guess the next question is when do you bump major versions?  :)  Since it doesn't seem to have been based on SONAMEs before
[15:42] <mterry> Trevinho, so you might get in this same situation again of mismatched version/SONAME
[15:43] <mterry> Trevinho, but regardless, there's no problem with bumping up to 4, I was just curious, and wanted to forstall confusion about the 3 in the libbamf3-0 name
[15:43] <mterry> forestall even
[15:43] <Trevinho> mterry: yes, that's a possibility I tought... I don't know which is the best approach... for unity (and libunitycore) for example.. we used to bump the soname at every new major version... And that's something we could do here too...
[15:44] <bregma> that's just broken
[15:44] <Trevinho> mterry: that name was added because of the gtk3/gtk2 thing (that was wrong, since libbamf never depended on gtk)
[15:44] <Trevinho> mterry: I wanted to change that too... but I asked to didier and he preferred to stay with it
[15:45] <mterry> Trevinho, yeah, now that the 3 is there...  I'd just as soon keep it too
[15:45] <mterry> Trevinho, and bumping SONAME when we don't need to is bad.  I'd just say keep it de-coupled from major version number to resist the urge to bump it unnecessarily
[15:45] <mterry> Trevinho, speaking of unnecessary...  why did we remove the API again?  :)
[15:46] <mterry> Trevinho, one could always just make the API a no-op...
[15:46] <Trevinho> mterry: these apis were totally unneeded...
[15:47] <mterry> Trevinho, sure...  But everytime a SONAME is bumped, a kitten dies is all I'm saying  :)
[15:47] <Trevinho> mterry: mh... I wanted to cleanup things that we have in and that were not needed anymore
[15:48] <Trevinho> mterry: mh, I know... But we have to at some time
[15:48] <mterry> Trevinho, I'm just being a punk.  Anyway.  I'd say go with 1 for SONAME and update the package names
[15:48] <Trevinho> ok
[15:48] <mterry> Trevinho, are there any other API cleanups you want to squeeze in while we're bumping anyway?
[15:50] <Trevinho> mterry: mhmh... probably few additions, but not removal... Even if there's an ABI change in progress by andyrock (not sure because he probably could just use the padding space we have in structs)
[15:52] <Trevinho> mterry: question: why the gir packaging is currently disabled for bamf?
[15:52] <andyrock> Trevinho, mterry https://code.launchpad.net/~andyrock/bamf/bamf-window-tab-mockable/+merge/140704
[15:53] <Trevinho> andyrock: since you're there please add some padding to the tab class (window one should already have it)
[15:54] <mterry> Trevinho, not sure
[16:01] <Trevinho> mterry: I've pushed the updates to the branch...
[16:01] <Trevinho> mterry: it would be nice to get the gir packaged as well btw
[16:02] <mterry> Trevinho, yeah...  Do we not have any python consumers now or are there static bindings for that?
[16:03] <Trevinho> mterry: I think that who is using it with pyhton just uses the raw DBus API (but loosing some features)
[16:03] <mterry> Trevinho, your last update added an empty chunk to the changelog
[16:03] <Trevinho> mterry: autopilot does it for example (but also because it was not using gir at all due to some old dependency)
[16:07] <mterry> Trevinho, also you correctly noted that the libglib2.0-dev needed to be updated, but you did 2.30 instead of 2.32 like the Build-Depend.  Should probably be same
[16:07] <Trevinho> mterry: actually the library needs a lower version than bamfdaemon
[16:07] <Trevinho> mterry: that's why I didn't put the same values
[16:07] <mterry> Trevinho, ah OK
[16:08] <mterry> Trevinho, so has bamf never needed libwnck or what?
[16:08] <Trevinho> mterry: the daemon yes, the library never
[16:08] <Trevinho> mterry: the library only depends on dbus and glib
[16:08] <mterry> Trevinho, and does the daemon no longer need it?
[16:08] <Trevinho> mterry: so... it depends on it since it depends on the daemon, but not strictly
[16:09] <Trevinho> mterry: so you can link on libbamf even without having libwnck-dev installed
[16:10] <mterry> Oh daemon still needs it, sure
[16:10] <Trevinho> mterry: oh I forgot to move some debian files... (doing it now)
[16:15] <Trevinho> mterry: do we really need Depends: ${shlibs:Depends} on libbamf3-dev?
[16:15] <mterry> Trevinho, no I shouldn't think so
[16:21] <Trevinho> mterry: everything pushed should be ok now
[16:22] <mterry> Trevinho, it's not a big deal, but I do like the the trailing commas on the last item in a dep list
[16:22] <mterry> Trevinho, keeps future diffs shorter and easier to read when we add one at the end
[16:22] <Trevinho> mterry: i've removed some
[16:22] <Trevinho> Ah, ok
[16:22] <Trevinho> sorry... I read a "I don't"... Putting it back
[17:42] <Trevinho> mterry: I've fixed the gir building, should I move it in another branch?
[17:52] <mterry> Trevinho, yeah please
[17:52] <Trevinho> mterry: it's already up: https://code.launchpad.net/~3v1n0/bamf/gir-package/+merge/140742 ;)
[17:52] <mterry> will get to the other branch too but got distracted
[18:36] <Trevinho> mterry: done
[22:01] <Trevinho> mterry: I've update the gir branch too
[22:01] <mterry> trevinho, awesome
[22:02] <Trevinho> uff, few merge issue.. Fixing them now
[22:03] <mterry> trevinho, ${shlibs:Depends} could be dropped yeah.  I thought it was used for gir's but guess not
[22:03] <Trevinho> mterry: eh, no it uses ${gir:Depends}-.. clearing it
[22:03] <mterry> trevinho, as for gir1.2-bamf-3-1, I'm reasonably sure that's not right
[22:03] <mterry> trevinho, e.g. libsecret doesn't use SONAME
[22:03] <mterry> trevinho, but...
[22:04] <mterry> trevinho, gtk uses 3.0...  I wonder if that's 3.SONAME?
[22:05] <Trevinho> mterry: I don't know... it could be, that's why I'm asking... I don't know if there are clear policies on these tasks
[22:07] <Trevinho> mterry: libdbusmenu is using libdbusmenu.so.4 and gir gir1.2-dbusmenu-glib-0.4
[22:08] <mterry> trevinho, this part I'm less clear on.  Let me see if there's docs anywhere
[22:11] <Trevinho> mterry: other things are confusing as well... for example librest-0.7-0 has soname 0 and gir gir1.2-rest-0.7
[22:12] <mterry> trevinho, yeah.  Many don't have the SONAME as part of it.  But I feel like they should...
[22:12] <Trevinho> mterry: yeah i think too, also if they depends on a lib that has soname on the name itself...
[22:26] <mterry> trevinho, they seem all over the place.  appindicator does gir1.2-appindicator3-0.1 (which is weird because it has SONAME 1 and I would expect gir1.2-appindicator3-1)
[22:27] <mterry> trevinho, (though, to be fair, I think I named that one back in the day)
[22:30] <mterry> Trevinho, I'd vote for gir1.2-bamf3-1  ...  for matching the other names (though really the other names should bamf-3-1 instead of bamf3-1)
[22:30] <Trevinho> mterry: mh... not having clear policies on these things creates a little of confusion..
[22:30] <mterry> Trevinho, I searched, but didn't see one
[22:30] <Trevinho> mterry: yeah, me too
[22:30] <mterry> Trevinho, couldn't even find where the original gir1.0 vs gir1.2 issue was settled
[22:30] <mterry> I think that was just a post in debian's bug tracker
[22:32] <Trevinho> mterry: so also the typelib name should be Bamf3-1.typelib instead of Bamf-3.typelib ?
[22:33] <mterry> Trevinho, yeah, it should track the package name.
[22:34] <mterry> Trevinho, but honestly I'd like to ask around first and see if anyone knows the real policy for these things before we go ahead
[22:34] <mterry> Trevinho, most people that know are on holiday.  Maybe wait until the next year
[22:34] <Trevinho> mterry: ok... So I'll keep it waiting
[22:37] <Trevinho> mterry: please let me know when you have any info..
[23:36] <fginther> bregma, ping
[23:40] <bregma> fginther, pong
[23:41] <fginther> bregma, do you happen to know anything about Jussi's precompiled header change for unity failing to build in the staging ppa?
[23:41] <fginther> https://launchpadlibrarian.net/126181515/buildlog_ubuntu-raring-amd64.unity_6.12.0daily12.12.05bzr3003pkg0raring0_FAILEDTOBUILD.txt.gz
[23:42] <fginther> bregma, I was unable to find him online
[23:42] <bregma> only that, according to Jussi, "it broke the build because in Jenkins something is stripping compiler flags in unity-shared"
[23:42] <bregma> then he said he'dlook into it tomorrow
[23:43] <bregma> he's at, what UTC-2?
[23:43] <fginther> ok, didn't know if he expanded on that to you. Thanks for checking.
[23:43] <fginther> yeah, he should be online before too long
[23:43] <bregma> my first guess is that Jenkins is pulling in a newew cmake and it does something different with the flags
[23:44] <bregma> but he's the expert on cmake, so I trust he'll figure it out
[23:44] <fginther> Ok, I'll just send him an message with my brain dump, hopefully it will get him the info he needs.
[23:44] <fginther> bregma, thanks for the help
[23:44] <bregma> pleasure


[01:36] -queuebot:#ubuntu-release- Unapproved: apache2 (bionic-proposed/main) [2.4.29-1ubuntu4.22 => 2.4.29-1ubuntu4.23] (ubuntu-server)
[01:38] -queuebot:#ubuntu-release- Unapproved: apache2 (focal-proposed/main) [2.4.41-4ubuntu3.10 => 2.4.41-4ubuntu3.11] (i386-whitelist, ubuntu-server)
[01:39] -queuebot:#ubuntu-release- Unapproved: apache2 (impish-proposed/main) [2.4.48-3.1ubuntu3.3 => 2.4.48-3.1ubuntu3.4] (i386-whitelist, ubuntu-server)
[07:30] -queuebot:#ubuntu-release- Unapproved: libxfce4util (kinetic-proposed/universe) [4.16.0-1 => 4.17.2-1] (i386-whitelist, ubuntu-budgie, xubuntu) (sync)
[07:36] <Ukikie> (I know it'll be held, that's just from experimental.)
[09:48] -queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (jammy-proposed) [2.1.4-0ubuntu0.1]
[11:20] -queuebot:#ubuntu-release- Unapproved: nginx (kinetic-proposed/main) [1.18.0-6ubuntu14 => 1.18.0-6ubuntu14.1] (ubuntu-server) (sync)
[11:21] -queuebot:#ubuntu-release- Unapproved: fribidi (kinetic-proposed/main) [1.0.8-2ubuntu3 => 1.0.8-2ubuntu3.1] (core, i386-whitelist) (sync)
[11:21] <rbasak> I'd like to upload an addition of xl2tpd to lto-disabled-list and a rebuild of xl2tpd to be staged for Kinetic, so that there's an assurance against future regression in an SRU upload to xl2tpd to fix it for Jammy. It's a hot bug on Jammy so I'd like to SRU this asap. How should I stage the Kinetic upload?
[11:21] <rbasak> Just stick it in the queue?
[11:32] -queuebot:#ubuntu-release- Unapproved: lto-disabled-list (kinetic-proposed/main) [24 => 25] (core, i386-whitelist)
[11:39] <rbasak> ^ I did that
[11:45] -queuebot:#ubuntu-release- Unapproved: evolution-data-server (jammy-proposed/main) [3.44.0-2 => 3.44.1-0ubuntu1] (i386-whitelist, ubuntu-desktop)
[12:07] -queuebot:#ubuntu-release- Unapproved: xl2tpd (jammy-proposed/universe) [1.3.16-1 => 1.3.16-1ubuntu0.1] (no packageset)
[12:16] <tsimonq2> Morning!
[12:18] <tsimonq2> Long time no see. Anyway, an SRU will be incoming, probably sometime this weekend, to fix the issue manually installing on btrfs for Studio and Lubuntu. Won't need a respin, maybe just a second set of eyes on the upload and the paperwork since I'm rusty. :)
[12:29] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (focal-backports) [1:7.2.6-0ubuntu<IP_ADDRESS>~bpo20.04.1]
[12:29] <ddstreet> ricotz sorry for the delay!
[12:33] -queuebot:#ubuntu-release- Unapproved: evolution (jammy-proposed/universe) [3.44.0-1ubuntu1 => 3.44.1-0ubuntu1] (ubuntu-mate, ubuntukylin)
[12:36] -queuebot:#ubuntu-release- Unapproved: gnome-desktop (jammy-proposed/main) [42.0-1ubuntu1 => 42.1-0ubuntu1] (ubuntu-desktop)
[12:46] <ricotz> ddstreet, thanks, I assume there was nothing to complain :)
[12:52] <ddstreet> yep looked fine to me :)
[12:52] <jbicha> tsimonq2: do you have a bug report?
[12:56] <ricotz> ddstreet, great
[13:39] -queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.16]
[14:40] <juliank> vorlon: sil2100 so britney has a lot of links from old tests that were run in jammy but links to kinetic pocket, and that 404s, because those failures were not copied over
[14:49] <vorlon> juliank: sure; but those being missing doesn't cause britney to mis-promote any packages, and if the packages are stuck in -proposed for long enough the tests will get re-run, so this isn't a serious issue
[14:49] <juliank> yeah we just got confused, hadn't noticed that before
[14:52] <juliank> I disabled bos01 again, it ran without having been patched for the proxy and caused failures
[14:54] <juliank> And restarted those tests
[14:54] <juliank> but that was like 4 hours ago (just FYI)
[14:55] <vorlon> yes; I had no information about what the patch was the proxy
[15:28] -queuebot:#ubuntu-release- Unapproved: libnotify (focal-proposed/main) [0.7.9-1ubuntu2 => 0.7.9-1ubuntu<IP_ADDRESS>] (desktop-core, i386-whitelist)
[15:30] -queuebot:#ubuntu-release- Unapproved: libnotify (jammy-proposed/main) [0.7.9-3ubuntu5 => 0.7.9-3ubuntu<IP_ADDRESS>] (desktop-core, i386-whitelist)
[15:40] -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.11]
[15:44] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.7~18.04.1 => 27.8~18.04.1] (core)
[15:46] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.7~20.04.1 => 27.8~20.04.1] (core)
[15:46] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.7~16.04.1 => 27.8~16.04.1] (no packageset)
[15:46] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (impish-proposed/main) [27.7~21.10.1 => 27.8~21.10.1] (core)
[16:19] -queuebot:#ubuntu-release- Unapproved: macaulay2 (kinetic-proposed/universe) [1.19.1+ds-6 => 1.19.1+ds-8] (no packageset) (sync)
[16:21] -queuebot:#ubuntu-release- Unapproved: accepted macaulay2 [sync] (kinetic-proposed) [1.19.1+ds-8]
[16:45] -queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (kinetic-proposed/universe) [1:22.04.4 => 1:22.10.1] (lubuntu, ubuntustudio)
[16:54] -queuebot:#ubuntu-release- Unapproved: json-c (kinetic-proposed/main) [0.15-2build4 => 0.16-1] (core, i386-whitelist) (sync)
[16:58] <bdmurray> jbicha: It looks like gdm3 is fully phased now
[17:01] <jbicha> thank you, next time I'll try to be more patient 😉
[17:02] <vorlon> base-files to migrate soon via skiptest.  There was a bit of weirdness with some of the triggered tests not finishing - that bears watching, but the tests themselves are useless for validating the base-files update
[17:03] <vorlon> "soon" == "now"
[17:04] <vorlon> and retriggering debootstrap-triggered tests once that migrates
[17:09] <tsimonq2> Please accept calamares-settings-ubuntu, it fixes an installer issue that I plan on submitting an SRU for. Would like to get one more round of testing prior to the SRU. Thanks.
[17:12] <vorlon> tsimonq2: we don't do manual reviews of packages in unapproved while the archive is frozen, except for toolchain-related packages that need ordered acceptance.  Everything else gets let in when the archive opens, and is not a blocker for SRU.
[18:52] -queuebot:#ubuntu-release- Unapproved: devscripts (kinetic-proposed/main) [2.22.1ubuntu1 => 2.22.1ubuntu2] (core, i386-whitelist)
[19:21] -queuebot:#ubuntu-release- Unapproved: nautilus (jammy-proposed/main) [1:42.0-1ubuntu2 => 1:42.1.1-0ubuntu1] (ubuntu-desktop)
[19:36] <ddstreet> vorlon bdmurray is distro-info getting updated this week?
[19:36] <ddstreet> been out of date since jammy
[19:36] <ddstreet> i thought it was part of the relese checklist items?
[19:38] <ddstreet> oh it did get updated two days ago...
[19:39] <ddstreet> AH 'phasing' is enabled for server systems now...
[19:39] <ddstreet> guess that's why i can't get it and my system is still out of date :)
[19:41] <sarnold> phasing in apt?
[19:41] <ddstreet> it might be worth updating distro-info-data *before* the release so that people aren't stuck with out-of-data distro-info data after each release
[19:41] <ddstreet> yep apt phasing happens for desktop and server systems now
[19:42] <sarnold> I don't recall seeing that in the release notes -- could someone who knows somerthing about it add it to the notes?
[19:42] <ddstreet> that was done for impish, i think
[19:42] <sarnold> no 'phas' on that page either :(
[19:43] <ddstreet> i assume juliank would know the best wording to add to the notes
[19:45] <vorlon> the distro-info-data update requires the release name, which we don't get before the prior release
[19:47] <juliank> ddstreet: sarnold please copy paste from 21.04, and add "Since 21.04,"
[19:49] <sarnold> juliank: beautiful! thanks :D will do
[19:50] <jbicha> juliank: do you know how apt phasing works if for instance evolution 3.44.1 depends on evolution-data-server 3.44.1 and they both are going into -updates?
[19:50] <bdmurray> vorlon: perhaps we should just fully phase distro-info-data
[19:50] <bdmurray> https://discourse.ubuntu.com/t/phased-updates-in-apt-in-21-04/20345
[19:50] <juliank> jbicha: it breaks/keeps back the upgrade
[19:51] <jbicha> breaks?
[19:51] <juliank> jbicha: we need to  add phased upgrade groups, for this and like grub stuff
[19:52] <juliank> jbicha: I'm not aware of this happening, but it could also decide to remove a package
[19:52] <juliank> But I think it should keep them at the old version
[19:52] <jbicha> I'm mostly keeping the updates separated so that the dependency will get fully phased first, but I feel like I might have to push mutter & gnome-shell simultaneously for some future SRU
[19:53] <juliank> So far we had no breakage reports at least
[19:53] <juliank> But it's implemented using pinning to deny not fully phased updates
[19:53] <juliank> Not by reverting those upgrades that have not fully phased yet
[19:53] <juliank> Were fully means for your machine
[19:54] <juliank> There's more weirdness that we need launchpad feature work for to make nicer
[19:55] <juliank> Because it should keep old version in updates until new one reaches 100%
[20:33] <tsimonq2> vorlon: Thanks for the clarification, I didn't know that it wasn't a blocker for an SRU. Thanks!
[20:35] -queuebot:#ubuntu-release- Unapproved: gjs (jammy-proposed/main) [1.72.0-1 => 1.72.0-3~ubuntu22.04.1] (desktop-core, desktop-extra, i386-whitelist, mozilla)
[20:36] <Trevinho> when someone has time, this SRU is quite important, as people with Turkish locale (at least) has a basically broken desktop ^
[20:45] <rbasak> bdmurray: are you planning to accept the Kinetic Unapproved queue or should I re-upload?
[20:47] <Trevinho> yeah, same question here :)
[20:48] <Trevinho> well actually in my case I'd wait for the debian sync, when debian wakes up...
[20:49] <rbasak> Ah my question is answered in #ubuntu-devel
[20:49] <rbasak> (the answer is yes)
[21:00] -queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (kinetic-proposed) [1:22.10.1]
[21:00] -queuebot:#ubuntu-release- Unapproved: accepted lto-disabled-list [source] (kinetic-proposed) [25]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted devscripts [source] (kinetic-proposed) [2.22.1ubuntu2]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted nmap [source] (kinetic-proposed) [7.92+dfsg2-1ubuntu1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted pam [source] (kinetic-proposed) [1.4.0-13ubuntu1]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (kinetic-proposed) [1.482]
[21:01] -queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [sync] (kinetic-proposed) [42.0-1]
[21:03] -queuebot:#ubuntu-release- Unapproved: rejected distro-info-data [source] (kinetic-proposed) [0.52ubuntu1]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (kinetic-proposed) [1.419]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted lubuntu-meta [source] (kinetic-proposed) [22.10.1]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-budgie-meta [source] (kinetic-proposed) [0.95]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (kinetic-proposed) [1.283]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-meta [source] (kinetic-proposed) [0.47]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-meta [source] (kinetic-proposed) [2.242]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted kubuntu-meta [source] (kinetic-proposed) [1.420]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (kinetic-proposed) [0.93]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-meta [source] (kinetic-proposed) [0.267]
[21:05] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-unity-meta [source] (kinetic-proposed) [0.5]
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted fribidi [sync] (kinetic-proposed) [1.0.8-2ubuntu3.1]
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted libxfce4util [sync] (kinetic-proposed) [4.17.2-1]
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted json-c [sync] (kinetic-proposed) [0.16-1]
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted nginx [sync] (kinetic-proposed) [1.18.0-6ubuntu14.1]
[21:31] -queuebot:#ubuntu-release- New binary: libnma [amd64] (kinetic-proposed/main) [1.8.38-1] (desktop-core)
[21:31] -queuebot:#ubuntu-release- New binary: libnma [s390x] (kinetic-proposed/main) [1.8.38-1] (desktop-core)
[21:32] -queuebot:#ubuntu-release- New binary: libnma [ppc64el] (kinetic-proposed/main) [1.8.38-1] (desktop-core)
[21:34] -queuebot:#ubuntu-release- New: accepted libnma [amd64] (kinetic-proposed) [1.8.38-1]
[21:34] -queuebot:#ubuntu-release- New: accepted libnma [s390x] (kinetic-proposed) [1.8.38-1]
[21:34] -queuebot:#ubuntu-release- New: accepted libnma [ppc64el] (kinetic-proposed) [1.8.38-1]
[21:35] -queuebot:#ubuntu-release- New binary: libnma [arm64] (kinetic-proposed/main) [1.8.38-1] (desktop-core)
[21:37] -queuebot:#ubuntu-release- New: accepted libnma [arm64] (kinetic-proposed) [1.8.38-1]
[22:01] -queuebot:#ubuntu-release- New binary: icu [amd64] (kinetic-proposed/main) [71.1-2] (core, i386-whitelist)
[22:01] -queuebot:#ubuntu-release- New binary: icu [i386] (kinetic-proposed/main) [71.1-2] (core, i386-whitelist)
[22:03] -queuebot:#ubuntu-release- New binary: icu [s390x] (kinetic-proposed/main) [71.1-2] (core, i386-whitelist)
[22:04] -queuebot:#ubuntu-release- New binary: icu [ppc64el] (kinetic-proposed/main) [71.1-2] (core, i386-whitelist)
[22:06] -queuebot:#ubuntu-release- New: accepted icu [amd64] (kinetic-proposed) [71.1-2]
[22:06] -queuebot:#ubuntu-release- New: accepted icu [ppc64el] (kinetic-proposed) [71.1-2]
[22:06] -queuebot:#ubuntu-release- New: accepted icu [i386] (kinetic-proposed) [71.1-2]
[22:06] -queuebot:#ubuntu-release- New: accepted icu [s390x] (kinetic-proposed) [71.1-2]
[22:17] -queuebot:#ubuntu-release- New binary: icu [armhf] (kinetic-proposed/main) [71.1-2] (core, i386-whitelist)
[22:22] -queuebot:#ubuntu-release- New: accepted icu [armhf] (kinetic-proposed) [71.1-2]


[06:01] <ducasse> morning all
[06:37] <jink> Hi ducasse.
[06:38] <ducasse> \o jink
[06:39] <jink> ^__^
[07:14] <EriC^^> morning ducasse o/
[07:16] <ducasse> hi EriC^^ - all well?
[07:19] <lordievader> Good morning
[07:20] <ducasse> morning lordievader - how's life treating you? :)
[07:20] <lordievader> Quite allright, how are you doing?
[07:21] <EriC^^> ducasse: yup, yourself?
[07:21] <EriC^^> good morning lordievader
[07:23] <ducasse> good here, it's absolutely _pouring_ down outside, i'm inside where it's nice and warm :)
[07:23] <lordievader> Hey EriC^
[07:23]  * lordievader slided coffee into the room
[07:51]  * ducasse swears and mumbles
[09:17] <lordievader> ducasse: What is going on?
[09:20] <ducasse> just some guy who was asking how to start a remote x application (on the remote display), when what he _actually_ wanted was to show it on his local (windows) machine. he kept giving wrong answers and holding back information - bad way to start the day ;)
[10:42] <brunch> damn, alt-arrowkey alt-fn causes desktop to switch to a tty
[10:42] <brunch> 17.10 feels really unstable now
[10:44] <Ben64> maybe they should hold off on releasing it until next month
[12:53] <BluesKaj> Howdy folks
[12:57] <ducasse> wb BluesKaj - had your morning coffee yet? :)
[12:58] <BluesKaj> Hi ducasse, not quite, on my 2nd cup. How's it going today?
[12:59] <ducasse> pretty good day, just about to head out to get some groceries in between intense showers of rain. and you?
[13:01] <BluesKaj> good here, clear and sunny, forecasting 25C today and lower 20s all week , cooling of nextweek to around 18 , that'll  be perfect for doing some work around the house and yard
[13:02] <BluesKaj> no rain in the forecast
[13:04] <ducasse> here we're hovering around 13°C, been raining constantly for a weel. forecast: one more day of pouring rain, then two days of thunderstorms
[13:06] <BluesKaj> bummer, you're getting what we had in july and aug :/
[13:07] <ducasse> oh, we had it then as well - it's been quite a wet summer :)
[13:15] <BluesKaj> maybe we'll have less snow thi winter, I hope, now that I don't ski anymore
[13:15] <BluesKaj> I miss it skiing , but my knees don't
[13:16] <BluesKaj> err I miss skiing rather
[13:25] <BluesKaj> Hi EriC^^
[13:25] <EriC^^> hi BluesKaj
[13:26] <BluesKaj> well, opensuse didn't do much for me, my search continues....  :-)
[13:27] <BluesKaj> the RPMs have poor nvidia driver support
[13:33] <BluesKaj> Kubuntu Artful is very stable and quick compared to previous releases, even on this old pc
[16:37] <immu> EriC^^,
[16:37] <immu> EriC^^, hiiii
[16:37] <EriC^^> hey immu
[16:37] <EriC^^> how are you?
[16:37] <immu> i am good on Ubuntu 17.10
[16:38] <EriC^^> nice
[17:05] <immu> watching apple live event booting into windows
[17:05] <immu> brb


[03:11] <Nivex> I wonder why Zareason doesn't let you pick Xubuntu but does let you pick Kubuntu
[03:54] <holstein> prolly what they are comfortable configuring and supporting
[03:54] <Nivex> their offerings are tempting though
[04:01]  * holstein looking...