[00:42] <racarr__> RAOF: Ok so I am trying to send you the xmir changes on github...the thing is I had some issue with vladmir and the intel driver and you werent around so I ended up basing them just on the packaging source
[00:42] <racarr__> so now I am trying to port them to vladimir, well there isnt much to do, but anyway I think thats done
[00:42] <RAOF> racarr__: Ah, cool.
[00:43] <racarr__> but how ... should I build it lol
[00:43] <racarr__> i.e. what are some reasonable ./configure options
[00:43] <racarr__> because there is no deb dir in vladimir
[00:44] <RAOF> Hm. That's dropped out of my zsh history ;)
[00:44] <racarr__> oh no
[00:44] <racarr__> we will have to consult the sage atop X11 mountain.
[00:45] <RAOF> racarr__: But I'd just build it with --enable-xmir as a first go.
[00:45] <racarr__> ahahha ok
[00:45] <racarr__> I tried config.log and got ./configure --prefix=/usr --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --build=x86_64-linux-gnu lt_cv_prog_compiler_static_works=no lt_cv_prog_compiler_static_works=no --disable-silent-rules --disable-static --without-dtrace --disable-strict-compilation --enable-debug --enable-unit-tests --with-int10=x86emu --with-extra-module-dir=/usr/lib/x86_64-
[00:46] <racarr__> but it doesnt work
[00:46] <racarr__> presumably because of quotes but I havent found where to put them all yet
[00:46] <racarr__> lol
[00:48] <racarr__> hmm
[00:49] <racarr__> RAOF: I need a new xtrans presumably I need to update
[00:49] <racarr__> to utopic?
[00:54] <RAOF> racarr__: Hm, dunno, seems to work for me (on utopic) :)
[00:55] <racarr__> ok well enter the unicorn after meeting
[02:00] <racarr__> RAOF: Ok I am making a beeline for food then will send you patch that I expect to ork on vladmir and you can try it out
[02:01] <RAOF> Wickedcool.
[02:01] <RAOF> TO THE COFFEEOTRON!
[06:30] <RAOF> Are we going to be using EXPECT_THAT for all test expectations, rather than all of the various EXPECT_{GE,TRUE,WHATEVER} specialisations that exist?
[06:40] <duflu> RAOF: I hope not. Sometimes the latter is much clearer
[06:41] <duflu> Although people seem to be converting everything to the former
[06:44] <RAOF> Yeah. I'm not sure why EXPECT_THAT(foo(), Eq(true)) is any clearer than EXPECT_TRUE(foo()).
[06:49] <duflu> RAOF: Coming soon: Lots of EXPECT_DEATH in some of my new tests :)
[06:49] <duflu> and EXPECT_EXIT
[06:49]  * RAOF is a fan of EXPECT_DEATH
[06:49] <duflu> lol
[08:26] <anpok> hm seems like due to a change in initialization order the session manager gets an added surface before the input targeter / input registrar hence it complains that it cannot set the focs to that surface
[08:26] <anpok> (on one of my cleanup branches)
[08:32] <anpok> hm i think it happens in a different thread have to look again
[08:35] <alan_g> anpok: the SurfaceCoordinator ought to be coordinating the surface addition. (Although I was interrupted in that doing cleanup)
[08:37] <anpok> hm
[08:37] <anpok> the issue is actually different again
[08:38] <anpok> the moment I now register the input registrar (great names) as observer to the scene, at that moment nobody holds a strong reference to the scene yet
[08:39] <anpok> oh scene is not even part of the DisplayServer::Private
[08:40] <anpok> input dispatcher conf had one
[08:43] <anpok> should i make a small mp for DisplayServer::Private to hold the_scene() early in the initialization?
[08:44] <anpok> yes, mir::compositor::Scene seems to be wrong.. but that would be another (bigger?) change?
[08:45] <anpok> i wanted to say - we should have  mir::scene::Scene and it should look different..
[08:50] <alan_g> anpok: if you're writing something that needs the scene then why isn't that keeping a reference?
[08:51] <alan_g> It seems wrong to rely on "someone else" holding ownership for you
[08:51] <anpok> well it does not necissarily need the scene - it is something that is bridging information between the scene and what the droidinput::InputDispatcher sees
[08:51] <anpok> thats true
[08:52] <anpok> i find the entities that we store in DisplayServer::Private rather arbitrary
[08:52] <anpok> at the moment the objects there are objects that need to be informed about stop / start / pause
[08:53] <alan_g> They're the ones that the DS needs to start/pause/resume/stop
[08:53] <alan_g> That's not arbitrary
[08:53] <anpok> we could also make an abstraction for that .. a system state observer .. yes inverting that.. and react on state changes in the components
[09:00] <alan_g> anpok: does that help your current lifetime management issue?
[09:01] <anpok> no it might unveil further issue
[09:01] <anpok> *issues
[09:02] <anpok> i hestitated to add the scene to the registrar, because the interface of scene requires a shared ptr to register..
[09:02] <anpok> so I would have to do something odd like shared_from_this or well rely on the caller to register - just like before
[09:03] <anpok> with my statement above I wanted to stress that ownership (as a keep alive concept) and observation of changes should be somehow separate
[09:04] <anpok> and we could redefine the role of starting and stopping as something that needs subsrcription to a state change
[09:04] <anpok> and then we would have to define ownership separately and make it more explicit
[09:04] <anpok> and more fine grained...
[09:05] <alan_g> OK  I agree that if scene owns registrar then registrar can't also own scene
[09:06] <anpok> this is not a solution (explicit ownership) - just another problem :)
[09:06] <alan_g> But registrar could have a pointer to scene - as scene is guaranteed to outlive it
[09:06] <anpok> pointer?
[09:07] <alan_g> "SomeType*"
[09:07] <alan_g> registrar-scene(this)
[09:07] <alan_g> registrar->scene(this)
[09:11] <alan_g> Or just passing this to the function(s) that need it
[09:11] <alan_g> *"this"
[09:12] <anpok> then scene needs to know registrar - which it shouldnt since it is only an impementation detail introduced for droidinput inputdispatcher
[09:13] <anpok> yes, before the scene observer we had that reference to registrar inside the scene
[09:13] <alan_g> "the interface of scene requires a shared ptr to register"
[09:14] <anpok> to register an observer
[09:14] <anpok> not to the registrar (tm)
[09:15] <alan_g> Oh I misunderstood
[09:15] <duflu> Anyone else notice gdb crashes a lot now
[09:16] <duflu> It's really annoying
[09:16] <duflu> (?)
[09:16] <duflu> I just trying gdb gdb and it just shows a stack overflow (and no symbols)
[09:16] <alan_g> So there's the problem: registrar shouldn't implement Observer
[09:16] <alan_g> duflu: no
[09:17] <anpok> duflu: no gdb worked great recently
[09:17] <alan_g> It should "own" scene and register a distinct observer type
[09:17] <duflu> Hmm, RAOF was reporting the same problems...
[09:18] <anpok> havent updated... like at least for a week or so
[09:18] <anpok> alan_g: ok that would solve it
[09:19] <anpok> (just have to check who owns registrar)
[09:19] <alan_g> It also keeps to the single responsibility principle
[09:19] <anpok> hm ok the enumerator
[09:19] <anpok> which is then owned by the droidinput InputDispatcher
[09:20] <anpok> which is then owned by the mia::AndroidInputDispatcher..
[09:20] <duflu> Oh, it seems to be program-specific:
[09:20] <duflu>  mir_unit_tests --gtest_filter="FatalTest.*"
[09:20] <duflu> Gah
[09:20] <anpok> and then we are at DIsplayServer
[09:20] <anpok> ok
[09:20] <duflu> I mean:
[09:20] <duflu> Reading symbols from bin/mir_unit_tests...Segmentation fault (core dumped)
[09:20] <anpok> bbiab
[09:20]  * alan_g wonders if we could generate an "ownership" DAG for Mir
[09:20] <anpok> duflu: too many symbols - running out or memory? or broken memory?
[09:21] <anpok> alan_g: we could trace constructor calls in CachedPtr
[09:21] <anpok> with the symbol name underneath
[09:21] <anpok> or maybe it can be extracted from the symbol name of the functor somehow
[09:24] <duflu> alan_g: I've always thought DAG enforcement should be part of a super-shared_ptr
[09:24] <duflu> mir::sp::FTW
[09:24]  * alan_g was thinking build time, not runtime. And adding to the generated docs
[09:32] <anpok> libclang \o/ - now i am gone
[15:32] <greyback> Crazy idea, but is there a way to run mir in such a way that it doesn't connect to the hardware or composite anything, but clients could connect to it and make surface and stuff?
[15:33] <greyback> would be handy for testing IMO
[15:40] <anpok> greyback: there should be an offscreen option
[15:41] <alan_g> greyback: it isn't crazy - it is handy for testing
[15:43] <anpok> you could also disable input then the hosting server would not open any devices.. but it would also disable the dispatch of input hmm
[15:43] <anpok> what was the intention of the --enable-input option?
[15:44] <anpok> to not open input devices, or to not deal with input events of any source ...
[15:47] <greyback> anpok: alan_g: offscreen option on my desktop still tries to twiddle the VTs
[15:47] <greyback> mir_demo_server_shell --offscreen  =>  std::exception::what: Failed to find the current VT
[15:49] <alan_g> alf_: you're responsible for the offsceen option aren't you? ^^
[15:52] <alf_> greyback: alan_g: the offscreen support is rough still (proof of concept mostly, we were waiting from feedback from interested parties that never came)
[15:52]  * alan_g thinks we have a new "interested party"
[15:54] <anpok> and feedback
[15:54] <greyback> alf_: yeah, I'd like to have that ability for proper integration testing of unity-mir with mir
[15:54] <greyback> so in a test env, I can launch & stop apps
[15:54] <greyback> not a major request mind, but would be nice to have
[15:55] <alf_> greyback: ok, so what can we assume about the test environment in terms of display support (e.g. drivers with Mesa/GBM)?
[15:56] <alf_> greyback: also do you want to be able to get visual output e.g. through screencasting?
[15:58] <greyback> alf_: I guess my initial thought was a null display driver, so nothing gets drawn anywhere
[15:59] <anpok> greyback: and do you want it to open input devices / not open any devices but allow the dispatch of synthetic input events?
[16:00] <greyback> anpok: the latter option would be preferred
[16:01] <alf_> greyback: perhaps offscreen is not what you are looking for, but an even leaner dumb server (like the ones we use in the mir integration/acceptance tests)?
[16:01] <anpok> there is an option --enable-input that does the former, we could add one for the latter..
[16:01] <greyback> alf_: ah, what dumb server is this?
[16:02] <anpok> or what alf says - that one does what you want wrt to input testing
[16:03] <alf_> greyback: it's not an executable, it's a server configuration with the major components stubbed which we used to instantiate our various test server instances
[16:03] <alf_> greyback: tests/mir_test_framework/stubbed_server_configuration.cpp
[16:04] <greyback> alf_: sounds handy. Let me play with it. If I find it useful, I might request a package containing it so unity-mir's integration/acceptance tests can use it
[16:06] <greyback> alf_: anpok: thanks guys!
[16:06] <alf_> greyback: yw
[17:03] <anpok> greyback: or look at InputTestingServerConfiguration i believe it is the same plus a fake event hub plus the common input dispatching stuff
[17:04] <greyback> anpok: ah nice, thanks
[19:41] <racarr__> kdub_: Hey I replied to your comments on cursor-spike btw...fixed the style one...I think shared_ptr really is appropriate though
[19:41] <racarr__> because the idea is, surfaces will share ownership of the loaded cursor images
[19:42] <racarr__> so, if no one is interested in the magnifying glass image it goes away and on the other hand everyone has the same instance of the default image
[19:42] <racarr__> of course the loader can also implement caching by keeping its own strong references
[19:43] <kdub_> racarr__, I guess my thought was though that its strange that an observer gets ownership
[19:43] <kdub_> like, having the surface have ownership makes sense to me
[19:43] <racarr__> oh...for the observer! Aha maybe I misread your comment sorry...
[19:44] <kdub_> right
[19:44] <racarr__> Hmm.
[19:44] <racarr__> ok I think you are right
[19:45] <racarr__> will fix it up
[19:45] <racarr__> sometimes...im not sure what to do in these situations
[19:45] <racarr__> because just using shared_ptr EVERYWHERE can get costly
[19:45] <racarr__> but whenever I use a reference to something managed by a shared_ptr elsewhere
[19:45] <racarr__> I feel like I am laying a trap lol
[19:48] <racarr__> ok brb lunch
[19:48] <racarr__> ...I cant believe its 92 degrees
[19:48] <kdub_> racarr__, yeah, hot down here too, 100 tomorrow
[19:49] <bschaefer> racarr__, its 82 here :(, i want rain
[19:57] <racarr__> Yesterday it kind of made me like woozy and tired
[19:57] <racarr__> but today ive been drinking iced coffee all day
[19:57] <racarr__> and really like it
[20:00] <bschaefer> iced coffee....must ... get some now....
[21:50] <racarr__> the error message when you only pass 8 arguments to a mock that expects 9 can be quite
[21:50] <racarr__> fabulous
[21:51] <racarr__> I dont understand what ipc factory is for
[21:51] <racarr__> in order to add a new argument to session mediator constructor
[21:51] <racarr__> you have to change literally over 10 call sites/declarations
[21:52] <kgunn> anyone...i think i'm an over-user of clean (lots of scar tissue from symbian days...using reallyclean), whats kind of your rule of thumb do you make clean ?
[21:54] <racarr__> basically never
[21:54] <racarr__> I recenetly cleaned over 40 gigs of mir build dirs all at once though
[21:54] <racarr__> :p
[21:55] <racarr__> the only time I make clean is with qmake because...I have had several issues with it lol
[21:55] <racarr__> kdub_: Ok passing references in cursor phase 3 now
[22:01] <kdub_> racarr__, ack
[22:02] <racarr__> phase 4 incoming!
[22:02] <racarr__> lol
[22:02] <kdub_> yknow, i should start naming my branches 'phases'
[22:02] <kdub_> one less thing to name :)
[22:03] <racarr__> kdub_: http://xkcd.com/1296/
[22:03] <racarr__> MY HANDS ARE TYPING WORDS
[22:05] <kdub_> racarr__, lol, yeah
[22:07] <racarr__> kgunn: So if we were to wait on cursor API for 0.2 there is no point in waiting past phase 4 because at that point
[22:07] <racarr__> clients could use it etc
[22:08] <racarr__> still no themed image loaders, but they can request the images, disable the cursor, etc...it can be tested and once we add the image loader will all just work
[22:08] <racarr__> again im really not sure its worth waiting though if we release again in a week or something
[22:09] <racarr__> I dont think we really profit much from trying to get certain things
[22:09] <racarr__> in certain releases
[22:09] <racarr__> and it might be better to just have consistent fast releases
[22:35] <rsalveti> kdub_: interesting bug for you: bug 1319582
[22:35] <rsalveti> kdub_: basically, eglDestroySurface never gets called when starting/closing apps with ubuntu touch
[22:36] <rsalveti> and as a side effect, the window surface never gets released when running it on the emulator
[22:36] <rsalveti> as it allocates a host side gl window surface, and waits that call to happen for it to release it
[22:37] <rsalveti> kdub_: we're not calling eglDestroySurface because the app is just normally killed, without any special clean-up
[22:37] <kdub_> rsalveti, hmm
[22:37] <rsalveti> any idea on how this could be solved on the client side?
[22:38] <kdub_> make sure to clean up resources? :)
[22:38] <rsalveti> right, but which component should take care of that?
[22:38] <rsalveti> the system-compositor?
[22:39] <kdub_> which egl context is the one that's leaking?
[22:39] <rsalveti> when you open an app, it creates a surface and a color buffer
[22:39] <rsalveti> the color buffer is released just fine, but the surface never gets released
[22:41] <kdub_> I guess I don't know the brew of components in play well enough to reason to a solution...
[22:42] <rsalveti> tvoss: maybe you have an idea ^
[22:42] <kdub_> the emulator is running a mir instance, like usc+unity8, right?
[22:42] <rsalveti> kdub_: yeah, exactly as we have on a nexus device
[22:42] <rsalveti> but the egl/gles driver is a translator that uses your host gl
[22:42] <kdub_> and there's probably some sort of pass-through driver
[22:43] <kdub_> right
[22:43] <kdub_> but the translator is an android window surface, right?
[22:43] <rsalveti> https://code-review.phablet.ubuntu.com/gitweb?p=CyanogenMod/android_sdk.git;a=blob;f=emulator/opengl/DESIGN;hb=refs/heads/phablet-trusty
[22:44] <rsalveti> right, when you ask for a surface, it sends the message to your host, via qemu pipe, that then creates the surface
[22:44] <rsalveti> but for the client this is just a normal android surface
[23:39] <racarr__> OHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
[23:39] <racarr__> RAOF: Email incoming in 1 minute lol
[23:39] <RAOF> Wooot!
[23:42] <racarr__> RAOF: ok 0001-input.patch is a completely untested integration of it in to vladimir
[23:43] <racarr__> I mean not even compiled or really looked at lol, but who knows
[23:43] <racarr__> and then xmir-deb
[23:43] <racarr__> is the working xmir directory from my
[23:43] <racarr__> ubuntu xserver patched to work with it
[23:43] <racarr__> um.
[23:43] <racarr__> I did have to delete my input drivers to test it
[23:44] <RAOF> Bitchn'
[23:47] <racarr__> als o make sure to replace your xinput driver before rebooting, it can be really disorienting


[00:02] <xubuntu91d> join
[06:38] <bonsaitree> Is there a way to change the icon of the network manager? I don't like this Android-styled 3 bar triangle-alike icon, and want to replace it with the old-school 4-5 bars icon. Anyone knows how to do this and is this possible? Thanks in advance.
[06:39] <pmjdebruijn> probably via /usr/share/icons
[06:40] <pmjdebruijn> but realisticly you shouldn't really mess with that
[10:28]  * ssarah hallo
[10:30] <knome> hello.
[11:29] <NewUser> Hi
[11:29] <NewUser>       hello
[11:56] <nsh> anyone else know of issues with broken menus in qt4/5 apps?
[11:56] <nsh> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
[11:56] <nsh> QCommonStyle::drawComplexControl: Control 1 not handled
[12:50] <xubuntu58o> help
[12:53] <xubuntu58o> ls
[14:06] <DexterF> oi
[14:07] <DexterF> where's the memtest gone on 16.04?
[14:07] <DexterF> (live)
[14:55] <DexterF> guys?
[14:56] <DexterF> (and gals, if there be any)
[14:59] <dreamer> hi all, somehow some if my configured locales are set to french. this has no use to me. how can I make
[14:59] <dreamer> them english?
[14:59] <dreamer> (this is from a default xubuntu installation btw. tres weird)
[15:21] <krytarik> DexterF: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/883017/comments/3
[15:26] <krytarik> dreamer: http://askubuntu.com/questions/232592/xubuntu-12-04-wrong-time-change-system-language
[15:32] <dreamer> oddly I do see that I'm using french ubuntu mirrors
[15:33] <dreamer> but the system language is in english
[15:35] <dreamer> krytarik: it's set to english. but the locales are still complaining about french (I also removed french as an installed language)
[15:36] <dreamer> this is really weird
[15:38] <DexterF> krytarik: gah. ok, ill try standalone or legacy or whatever
[15:43] <krytarik> dreamer: Then also see: https://help.ubuntu.com/community/Locale
[15:49] <dreamer> ah ok. I have to log out and back in
[16:07] <mises> when i right click on thunar, an option comes up named "delete" which gets rid of a file permanently without moving it to trash, how can i remove this option?
[17:01] <bonsaitree> How do i know which .png image is used for the network-manager? When i go into /usr/share/icons/ubuntu-mono-light/status/ there are 3 folders there - 16, 22, 24.
[17:10] <GridCube> bonsaitree: it depends on the size of your panel, if its 16px or less it uses the 16px one, if its 32px wide it uses that one, if its more than 64px wide it uses that one
[17:11] <bonsaitree> GridCube:Yup, but how do i find out the resolution of my icon?
[17:11] <GridCube> look at the size of your panel
[17:12] <bonsaitree> GridCube:My bad, instead of panel, i read icon, sorry
[17:17] <bonsaitree> GridCube:Interesting, my panel size is 24px, i am deleting all of the icons for network-manager, battery, etc (making a backup folder) from the folder, and the icons are still in the panel, there is no blank space or something. Is it somehow linked with those .pngs, so even if their location is modify, they can still be accessed?
[17:17] <bonsaitree> modified*
[17:17] <GridCube> you probably need to reload the panel
[17:17] <GridCube> xfce4-panel --restart i think
[17:17] <GridCube> or --reload
[17:19] <bonsaitree> GridCube: "No running instance of xfce4-panel was found"
[17:19] <GridCube> o.O
[17:19] <GridCube> thats not right
[17:19] <GridCube> are you using xfce?
[17:19] <bonsaitree> GridCube:Sure
[17:20] <GridCube> well, don't know where to help you there
[17:20] <bonsaitree> GridCube:xfce4-panel 4.12.0
[17:21] <GridCube> run it?
[17:22] <bonsaitree> xfce4-panel: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
[17:22] <bonsaitree> + a floating grey box
[17:22] <bonsaitree> clickable and movable
[17:22] <GridCube> lol
[17:22] <GridCube> sorry but no idea
[17:23] <GridCube> restart xfwm4
[17:23] <bonsaitree> Me neither
[17:24] <bonsaitree> GridCube:The man page won't give any info on how to restart
[17:24] <GridCube> xfwm4 --replace
[17:26] <bonsaitree> GridCube:The GUI is uglier now
[17:26] <GridCube> but you have one, so thats a start
[17:28] <bonsaitree> GridCube:Had to reboot, everything froze
[17:29] <GridCube> mmmkay
[17:29] <GridCube> luckily you got your system back i guess?
[17:30] <bonsaitree> Yes
[17:30] <GridCube> good, do you have xfce4-panel running? and your window decorations as well?
[17:31] <bonsaitree> GridCube:I will check again, since it was not running previously
[17:31] <bonsaitree> Nope, no running instance
[17:31] <bonsaitree> should i run it?
[17:32] <GridCube> well, do you have a panel?
[17:32] <GridCube> o.o
[17:32] <GridCube> i mean
[17:32] <bonsaitree> GridCube:Yes
[17:32] <GridCube> then you should have an instance of it running ain't it not?
[17:35] <bonsaitree> GridCube: http://i.imgur.com/HkzWRc6.png
[17:35] <GridCube> sep, parece que está corriendo
[17:36] <GridCube> wait
[17:36] <GridCube> you running commands in root?
[17:36] <GridCube> o.O
[17:36] <GridCube> you shouldn't
[17:36] <bonsaitree> GridCube:Why not?
[17:36] <GridCube> because it's not a good idea, you are in an ubuntu ecosystem, is designed to not use root unless extremely necesary
[17:37] <GridCube> if i had to bet, i'd say that its trying to see if root is running xfce4-panel or something, probably not, but still
[17:37] <bonsaitree> GridCube:Yes, but if i am positioned in a path, and want to open GUI there and modify directly, it is a lot better to use root, otherwise i would not be able to modify
[17:37] <knome> also if you run applications with the root permissions, it's possible that something doesn't work
[17:38] <knome> "because i'm lazy" isn't a good reason to use root.
[17:38] <bonsaitree> Isn't root the superlative?
[17:38] <GridCube> yeah, if it started the panel in root mode then your user might not be able to see it
[17:39] <bonsaitree> Or some things are intentionally designed to not work on root, to prevent damage?
[17:39] <GridCube> thats most of ubuntu bonsaitree
[17:39] <GridCube> unless extremely needed, you never need root
[17:39] <knome> a lot of user-facing software should NOT be ran as root because doing that creates permission problems.
[17:40] <bonsaitree> My ignorance then
[17:40] <GridCube> P: we all have to learn one day
[17:41] <bonsaitree> So, should i then try those things you mentioned with a regular user?
[17:41] <GridCube> yes, maybe? i don't know now if permissions are in the way, not my area of expertise if i have one
[17:42] <bonsaitree> yes, not it reloades the panel
[17:42] <bonsaitree> now*
[17:42] <knome> it's likely that some permissions are already wrong as you've ran stuff as root, but you can try
[17:42] <knome> so are you now back to the starting point?
[17:42] <bonsaitree> But, the initial thing that we made this for
[17:43] <bonsaitree> The icons are still there, and i have removed them
[17:43] <knome> ok, so are you using the ubuntu-mono-light theme?
[17:43] <bonsaitree> knome:That's what i thought now. Maybe i am deleting in the wrong theme folder
[17:44] <knome> first of all, deleting random files from directories that need root write access isn't generally a good idea
[17:44] <knome> second, check which icon theme you are using first
[17:44] <bonsaitree> knome:Even if you backup them and they are a regular .png?
[17:45] <knome> yes.
[17:45] <bonsaitree> I will ask why, if you have the time for a short answer
[17:45] <bonsaitree> If not, it's okay :)
[17:45] <knome> the (icon) theming, as many other configuration related things are built so that you can override the system defaults
[17:46] <knome> so instead of having to remove any files (that again need root rights using which might end up wrong) you can add files to your personal configuration
[17:49] <bonsaitree> mhm
[17:50] <knome> and if a package is updated, it's possible that the files are created again
[17:50] <knome> so you'll lose your modification
[17:50] <knome> that's one argument why you would want to do the configuration on a non-system level
[17:51] <bonsaitree> elementary Xfce darker is the theme i am using
[17:57] <Guest7876> hello folks, anyone able to try and help me with a small issue?
[17:57] <knome> ask the question and find out? :)
[18:00] <Guest7876> when i'm watching movies on VLC the screen goes totally blank after around 10 minutes.  I bump the mouse it comes back.  XFCE power manager is turned off, my xset settings are set to off, noblank and noexpose, and dpms is off.
[18:00] <knome> turn the presentation mode on from the power applet on the panel
[18:01] <Guest7876> should i only do this when watching a movie?  something like caffenine for xscreensaver?
[18:02] <Guest7876> or can i just leave it checked?
[18:02] <knome> you can leave it checked if you don't ever want the monitor to turn off
[18:04] <Guest7876> great, thanks.  first time i've been hear and that was way faster and easier than expected.. take care.
[21:57] <skrite> exit


[01:03] <clovertone> hello. I'm having a little trouble installing Hamachi
[01:04] <clovertone> during installation, everything goes fine until the end when it tries to start the service, it shows an error.
[01:05] <clovertone> I used this installation guide on youtube http://www.youtube.com/watch?v=rpkUEGjDzn8
[01:06] <clovertone> but prior to that I installed the latest LSB package, as recommended on the hamachi website, using apt-get
[01:07] <clovertone> this is the error from Terminal:Starting LogMeIn Hamachi VPN tunneling engine logmein-hamachi/sbin/start-stop-daemon: Unable to start /opt/logmein-hamachi/bin/hamachid: Exec format error (Exec format error) *
[14:55] <czajkowski> ebel: got them details yet so I can get the dns change
[14:56] <ebel> ah feck no, sorry
[14:56] <ebel> i'll do that later tonight postwork
[14:56] <ebel> well, i'll send you the details.
[14:56] <ebel> i suggest pinging everyone involved incl. new web masters to make sure everyone's ready to go
[14:56] <ebel> sorry!
[14:58] <czajkowski> np


[00:16] <guiverc> sorry Bashing-om, comment(s) made 18.04.4 general comm...  blogo (linux firmware)  but still reading
[00:21] <Bashing-om> guiverc: :D will catch up soonest ya done .
[00:21] <guiverc> looks good Bashing-om (done)
[00:51] <Bashing-om> guiverc: The 2 minor edits done - Awaiting nextes :D
[01:43] <krytarik> Bashing-om: "Call for nominations: Developer Membership Board" - should be in General rather than Other Community News.
[01:48] <Bashing-om> krytarik: considered such - but as of limited interest best as "general" ?
[01:51] <krytarik> Since when do we consider level of interest on putting official news into the General Community News section?  Like, the last similar one I quickly remember, is the IRC Council election results..
[01:56] <Bashing-om> krytarik: I always consider what might be of interest and where . there are many things I run across I could add to the letter if I did not consider General avalability. You are the boss, if ya want the item moved - I move it :)
[01:57] <krytarik> Also, in the 18.04.4 summary, I think we should either drop the notion of Łukasz being on the Foundations Team, or since he is obviously also on the Release one, mention that.  Also, please just copy-paste his first name as I just did as to spell it correctly.
[01:57] <Bashing-om> krytarik: Fixing.
[02:09] <krytarik> Aha, last one was actually "Core Channel Operator Appointments", and it also went into Other Community News - I also think wrongly.
[02:12] <Bashing-om> krytarik: Proper to change as Łukasz 'sil2100' Zemczak signed off as "Foundations Team" ?
[02:13] <krytarik> Well, that's just his signature, he can represent many more teams - important here is the context.
[02:15] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: GNOME 3.36’s New Default Background is Seriously Cool @ https://www.omgubuntu.co.uk/?p=162991 (by Joey Sneddon)
[02:19] <Bashing-om> krytarik: K -- and back to DMB - has come to Mark's attention: https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040893.html. I best tread lightly here.
[02:20] <krytarik> And to continue the thought on the official news, if you just look at the issue summary, in this case a personal FOSDEM report and Mir News would all seem to be more important than the DMB elections - and in fact, if it wasn't for the issue of no Planet items being there again and manual intervention, the latter wouldn't even be in the summary.
[02:23] <Bashing-om> ^^ Great point - taken .
[02:25] <krytarik> And Mark only speaks of the public nominations there, not the public call for them.
[02:28] <krytarik> Also, given Core Developers as per <https://launchpad.net/~ubuntu-core-dev> is a proper name, we should probably capitalize it like this too.
[02:34] <Bashing-om> krytarik: having to catch up on "Core Channel Operator Appointments" - gimme a bit yet.
[02:46] <Bashing-om> krytarik: Sorry I do not follow the context for "Core Channel Operator Appointments" . Where am I at ?
[02:57] <krytarik> Bashing-om: Nevermind that, didn't want to confuse you.
[02:59] <Bashing-om> krytarik: confused is easily done :P .. OK .. think I have all edits done // double check me please.
[03:47] <krytarik> Bashing-om: Yeah, appears to be it - just shouldn't it be "the request" instead? >_>
[03:48] <Bashing-om> krytarik: Looking again :P
[03:50] <Bashing-om> krytarik: Yepper, agree should be  as "the request" .
[03:53] <Bashing-om> krytarik: done
[04:04] <krytarik> Okey dokey, thanks.
[04:15] <Bashing-om> Not done 'til it is done. and not done 'til krytarik says it is done :P
[10:07] -BottyMcBotFace:#ubuntu-news- ::Softpedia:: Elementary OS to Build the Next-Generation Linux App Store @ https://news.softpedia.com/news/elementary-os-to-build-the-next-generation-linux-app-store-529141.shtml (by Bogdan Popa, Microsoft News Editor)
[15:00] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: ‘Habits’ App Measures Mouse Distance & How Many Keys You Press a Day @ https://www.omgubuntu.co.uk/?p=163026 (by Joey Sneddon)
[17:44] -BottyMcBotFace:#ubuntu-news- ::Planet:: Omer Akram: Network-based IPC using WAMP protocol @ https://om26er.com/2020/02/10/network-based-ipc-using-wamp-protocol/
[17:56] -BottyMcBotFace:#ubuntu-news- ::OMG!Ubuntu:: OpenShot Video Editor Just Got a Massive Update @ https://www.omgubuntu.co.uk/?p=163106 (by Joey Sneddon)
[20:00] <Bashing-om> UWN: checked channel log, nothing to change to the issue. Pulling "WIP" time to push 21:00 GMT.
[20:57] <Bashing-om> Issue advisory sent - doing the Forum post next.
[21:04] <Bashing-om> Forum post completed - abridged the 19.10 updates. Doing the redirects next.
[21:16] <Bashing-om> Re-directs also done - pending is publishing to the social medias :D
[21:26] <guiverc> Bashing-om, push 617 to fridge?
[21:27] <Bashing-om> guiverc: Yup - looks all good to go :D
[21:30] <guiverc> http://fridge.ubuntu.com/2020/02/10/ubuntu-weekly-newsletter-issue-617/  (18.04.4 postponed fridge link re-done)
[21:33] <Bashing-om> Fridge: spot check - check good :D
[21:33] <Bashing-om> guiverc: Clear now to wipe Gdoc ?
[21:34] <guiverc> tweeted; yep re gdoc
[21:34] <Bashing-om> wipping :P
[21:36] <Wild_Man> Here early and still to late
[21:36] <guiverc> Wild_Man, facebook hasn't been done (I hate fb; so wanna do?)
[21:37] <Wild_Man> yes guiverc I will do it
[21:37] <guiverc> Thanks  :)
[21:37] <Wild_Man> You're welcome
[21:41] <Bashing-om> And we now do UWN518 :P
[21:46] <Wild_Man> You may want to look at the new image for the UWN on FB https://www.facebook.com/
[21:47] <Bashing-om> Wild_Man: I have no FB account - is there a direct link so I can look at the banner ?
[21:49] <Wild_Man> Yeah I clicked on it but it gave me this link and now I do not see the post I just posted, give me a minute
[21:51] <guiverc> yeah I don't see 617 on fb either
[21:54] <Wild_Man> https://www.facebook.com/UbuntuWeeklyNewsletter/?eid=ARBkB6KjEo-upmA8253AvifjPwsybRC3446bRNnT80LEaU_gDUY7yN6NNB2AMgiJgw6IBn5fK3f9EcKd
[21:55] <guiverc> I see 617 on fb :)
[21:55] <Wild_Man> The old image is used on the FB page but the new one is used when the UWN actually posts but it off center and does not look very good that way omo
[21:56] <Wild_Man> I have to do other things now as usually be back shortly, fixing the image is really not in my wheelhouse
[21:56] <guiverc> I concur.  most of ubuntu circle gets in, plus text to right that distracts..
[21:57] <Wild_Man> I am not sure how ti fix it but I bet krytarik does he is good with images and centering
[21:57] <Bashing-om> FB: too out of my editing skills and access.
[21:57] <Wild_Man> We need that image put on the fb page as well for the profile image
[21:58] <Wild_Man> krytarik, fixed the one for the forums FB page
[22:01] -BottyMcBotFace:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 617 @ http://fridge.ubuntu.com/2020/02/10/ubuntu-weekly-newsletter-issue-617/
[23:17] -BottyMcBotFace:#ubuntu-news- ::Planet:: Ubuntu Blog: Testing your user contract @ https://ubuntu.com/blog/testing-your-user-contract


[11:33] <mup> PR pc-gadget#84 closed: Update partition layouts for 22-xinyi-pc-classic <Created by medicalwei> <Merged by xnox> <https://github.com/snapcore/pc-gadget/pull/84>
[13:22] <mup> PR snapcraft#4072 closed: accounts.py: tweak for grammatical effect a couple comments <Created by rpjday> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4072>
[15:38] <mup> PR snapcraft#4077 opened: linters: allow "categories" for subfiltering <Created by tigarmo> <https://github.com/snapcore/snapcraft/pull/4077>
[16:37] <mup> PR snapd#12658 opened: tests: use quiet tool from snapd-testing-tools <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12658>
[17:52] <mup> PR snapd#12656 closed: tests: fix TestDeviceUnlockErr test in debian-sid and ubuntu 23.04 <Simple 😃> <Test Robustness> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12656>
[19:13] <mup> PR snapcraft#4078 opened: lint: fix multi-part imports <Created by mr-cal> <https://github.com/snapcore/snapcraft/pull/4078>
[20:43] <mup> PR snapcraft#4078 closed: lint: fix multi-part imports <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4078>
[23:13] <mup> PR snapcraft#4075 closed: tests: mock dependency loading for patch elf test <Created by mr-cal> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4075>


[05:45] <mborzecki> morning
 - Great. No issues. Yes, testing will be next.
[06:04] <mardy> hi mborzecki!
[06:04] <mborzecki> mardy: hey
[07:20] <mborzecki> meh, the opensuse i586 build on obs fails on go-efilib, unclear why
[07:21] <mborzecki> unless the source tarball is missing dependencies maybe?
[07:32] <mup> PR snapd#10898 closed: cmd/snap-confine/snap-confine.apparmor.in: update ld rule for s390x impish <⚠ Critical> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10898>
[08:22] <mup> PR snapd#10899 opened: packaging: fixes for building on openSUSE <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>
[08:28] <mborzecki> trivial PR ^^
[08:29] <mvo> mborzecki: thanks!
[08:32] <jamesh> mvo: could you merge https://github.com/snapcore/snapd/pull/10173 for me? The spread failures looks spurious, as the PR only adds infrastructure to support other PRs rather than change any existing behaviour.
[08:32] <mup> PR #10173: interfaces: add polkit security backend <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/10173>
[08:32] <mvo> jamesh: sure
[08:32] <jamesh> thank you
[08:37] <mup> PR snapd#10173 closed: interfaces: add polkit security backend <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10173>
[08:59] <flotter> HACKING.md: Note that if you are using go 1.16 or newer you need to disable the
[08:59] <flotter> go modules feature. Use: export GO111MODULE=off
[09:00] <flotter> Is this still (was it ever) true? I installed go v1.16.x and things for me work fine with modules enabled ?
[09:00] <flotter> (it builds fine)
[09:00] <mvo> flotter: that is no longer true I think, it might be a overlook
[09:00] <mvo> flotter: we moved to 1.13 recently so this may be outdated
[09:02] <flotter> ok thx, this is what I thought.
[09:04] <flotter> The HACKING.md guide attempts help users for 3 cases: "From snapd 2.52, snapd supports Go 1.13 and onwards. From snapd 2.38
[09:04] <flotter> to 2.52, snapd requires Go 1.9+. Versions before 2.38 support Go 1.6+."
[09:05] <flotter> Do we really want to support those historic cases in this guide? It feels like it is opening up a can of worms, with module support and not.
[09:05] <flotter> Would it not make sense to draw a line in the sand and make the guide apply only to the commit point and later ? then we can make it very clear
[09:16] <mborzecki> zyga-mbp: hi, can you take a look at https://build.opensuse.org/request/show/924171 ?
[10:06] <mborzecki> mardy: can you take a look at https://github.com/snapcore/snapd/pull/10899 ?
[10:06] <mup> PR #10899: packaging: fixes for building on openSUSE <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>
[11:16] <mardy> mborzecki: +1, minor suggestion
[11:58] <mup> PR snapd#10891 closed: gadget: add mapping trait types + functions to save/load <Simple 😃> <Needs Samuele review> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10891>
[12:17] <miguelpires> mvo: can you merge https://github.com/snapcore/snapd/pull/10897, please? spread failures seem unrelated
[12:17] <mup> PR #10897: osutil: ensure parent dir is opened and sync'd <Simple 😃> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10897>
[12:23] <zyga-mbp> good morning
[12:24] <zyga-mbp> mvo: rpi4 now supports secure boot
[12:24] <ogra> zyga-mbp, you mean they added a proper TPM?
[12:24] <zyga-mbp> mvo: I've got a working low cost automation solution for rpi4 (extensible to all versions), off the shelf components and low complexity
[12:24] <zyga-mbp> ogra nope
[12:24] <zyga-mbp> mvo: the system can automate 4 x rpi4 boards
[12:24] <ogra> (pi has always supported "secure" boot through i2c or spi attached key storages)
[12:25] <zyga-mbp> mvo: or 3 x rpi4 and auto-recover itself
[12:25] <ogra> (but thats only FSVO secure ... since you can tap into the buses and sniff they keys)
[12:25] <zyga-mbp> ogra: https://github.com/raspberrypi/usbboot/pull/93/files
[12:25] <mup> PR raspberrypi/usbboot#93: WIP: Add support for secure-boot - see Readme.md <Created by ghollingworth> <https://github.com/raspberrypi/usbboot/pull/93>
[12:25] <zyga-mbp> this is better
[12:26] <zyga-mbp> ogra: one-time programmable though
[12:26] <zyga-mbp> ogra but has a nice test mode to check it works before going in with the fuse burner
[12:26] <ogra> zyga-mbp, OOOH ! signing the EEPROM itself !!
[12:26] <zyga-mbp> eeprom, eeprom config and the image
[12:26] <zyga-mbp> (booted image)
[12:26] <ogra> yeah
[12:26] <zyga-mbp> read that, it's cool
[12:27] <ogra> very nice
[12:28]  * zyga-mbp will write control software to spread-automate pi4 at home and in his office lab
[12:29] <zyga-mbp> happy to share and co-develop if you have interest and cycles
[12:33]  * zyga-mbp reboots, back after update
[12:43] <mup> PR snapd#10900 opened: o/devistate: introduce DeviceManager.Unregister <Created by pedronis> <https://github.com/snapcore/snapd/pull/10900>
[13:43] <mup> PR snapd#10901 opened: overlord: add managers unit test demonstrating cyclic dependency between gadget and kernel updates <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10901>
[15:23] <mup> PR snapd#10879 closed: gadget/ondisk.go: add listBlockDevices() to get all block devices on a system <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10879>
[15:48] <mup> PR snapd#10902 opened: interfaces/apparmor: allow read access to random files for haveged <Created by snowsky> <https://github.com/snapcore/snapd/pull/10902>
[16:59] <mup> PR snapd#10903 opened: gadget/ondisk.go: include the filesystem UUID in the returned OnDiskVolume <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10903>
[17:24] <mup> PR snapd#10904 opened: osutil/disks, many: switch to defining Partitions directly for MockDiskMapping <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10904>
[18:06] <holmanb> Question about "why are snaps loop devices"? -> from https://snapcraft.io/docs/snap-format: "This method delivers fast and extremely predictable installations, with no installation remnants, and no way for a snap’s content to be mutated or interfered with. A snap is either installed and available as originally built, or it is not available at all."
[18:06] <holmanb> Is this the primary reason?
[18:24] <mup> PR snapd#10902 closed: interfaces/apparmor: allow read access to random files for haveged <Needs security review> <Created by snowsky> <Closed by snowsky> <https://github.com/snapcore/snapd/pull/10902>
[18:26] <ogra> holmanb, yes, snaps are gpg signed readonly squashfs images that support binary deltas (so downloads are small) ... you cn not tinker with the content but squashfs also uses compression so a snap is usually smaller than the same contnet installed as other packages
[18:33] <holmanb> ogra: Thanks :) That makes sense. Last night I was just looking at boot time in systemd-analyze critical-chain and went down the rabbit hole of "why is snap taking so much of this time?" -> "loop devices are slow" -> "start playing with perf and get frustrated with ubuntu's perf packaging" -> "why snap use loop devices anyways?"
[18:39] <ogra> well, loop devices (or mounting filesystem images in general) is slow on rotary disks ... i think that assumption is that these are rare nowadays for boot media 🙂
[18:39] <ogra> *that the
[18:39] <ogra> (you nearly seen no boot impact on NVME disks, SSDs and the like)
[18:40] <holmanb> ogra: I was testing in lxd, would that affect it perhaps?
[18:40] <holmanb> I'm on NVME
[18:40] <ogra> hmm, it might
[18:41] <ogra> i rarely have snaps in my lxd containers (i use them to build snaps though 🙂 )
[18:41] <ogra> though lxd usually does not do an actual boot unless you use a VM backend of it
[18:42] <holmanb> ogra: checked how system, snapd time in critical-chain is negligable (150ms)
[18:43] <holmanb> *host
[18:43] <ogra> yeah, thats typical
[18:44] <ogra> ogra@acheron:~$ systemd-analyze critical-chain|grep snapd
[18:44] <ogra>               └─snapd.socket @13.583s 👍ms
[18:44] <ogra>                   └─snapd.apparmor.service @13.089s +488ms
[18:44] <ogra> ogra@acheron:~$ snap list | wc -l
[18:44] <holmanb> in lxd snapd took up over half the total boot time
[18:44] <ogra> 103
[18:44] <ogra> heh
[18:45] <ogra> my emoji plugin thought it shuld give the 1ms a thumbs up 🙂
[18:45] <holmanb> XD
[18:45] <holmanb> ```
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# systemd-analyze critical-chain | grep snapd
[18:45] <holmanb>   └─snapd.seeded.service @9.679s +6.108s
[18:45] <holmanb>     └─snapd.service @7.639s +2.036s
[18:45] <holmanb>           └─snapd.socket @7.586s +2ms
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# snap list | wc -l
[18:45] <holmanb> 4
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# systemd-analyze
[18:45] <holmanb> Startup finished in 17.694s (userspace)
[18:45] <holmanb> graphical.target reached after 15.791s in userspace
[18:46] <holmanb> ```
[18:46] <holmanb> in case that's of any value ^^
[18:46] <ogra> that soounds rather normal ...
[18:47] <ogra> you can technically disable the snapd.service unit, a use of any snap command should launch it via the socket anyway
[18:48] <ogra> snap seeding usually only happens on first boot, i wonder why you see it there
[18:49] <holmanb> Sure, I don't really need it running but I figured I'd dig in a little and learn more since I don't know much about snaps
[18:49] <holmanb> Thanks for answering some newbie questions :)
[18:49] <ogra> np ... we've all been newbies once 😉
[19:18] <mup> PR snapcraft#3589 opened: snap: correct patch apply for patchelf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>
[20:53] <mup> PR snapcraft#3589 closed: snap: correct patch apply for patchelf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>


[10:53] <oly_> hi, is there any way to tell ubuntu one to ignore .pyc files it keeps creating conflicts on these files between machines
[19:03] <XiXaQ> are notes and contacts on Ubuntu one supposed to be synced with my evolution?
[19:04] <XiXaQ> oh, my contacts are synced. Great. But what about notes? I can't find anything about it in Evolution.
[19:04] <dobey> notes are tomboy notes
[19:05] <dobey> https://wiki.ubuntu.com/UbuntuOne/Tutorials/Notes
[19:06] <XiXaQ> there
[19:06] <XiXaQ> there's that one again...
[19:06] <XiXaQ> I always thought Ubuntu were supposed to ship one application per feature.
[19:06] <CardinalFang> XiXaQ, Maybe.  If you have  evolution-couchdb  package installed.
[19:08] <XiXaQ> I don't understand why anyone would want to replace Evolution with tomboy...  Breaks the feel of ubuntu desktop as well.
[19:08] <dobey> XiXaQ: unfortunately there is some overlap, because evolution is more like several applications in one, rather than an application per task
[19:09] <XiXaQ> right, but then we should replace all of it with wiki-applications instead.
[19:09] <XiXaQ> there is already a wiki-based task-manager, right up the alley with tomboy.
[19:09] <dobey> tomboy isn't a task manager though :)
[19:09] <XiXaQ> and we can switch to a web based mail client and a web based calendar, then we don't need evolution anymore at all.
[19:10] <dobey> i can't agree with that :)
[19:11] <XiXaQ> then you don't think the philosophy of having one application per feature is nice?
[19:11] <dobey> i don't think the web is nice
[19:11] <XiXaQ> I'd like to have a RSS feed manager, but we can't have that because Firefox already supports it.
[19:12] <XiXaQ> I'd like to have alarm clocks, but I can't have that either, because Evolution can do that.  It's annoying :)
[19:13] <dobey> we can have it, because firefox isn't an rss reader. it's a web vm
[19:13] <XiXaQ> and xchat can't be included because Empathy supports IRC?
[19:13] <dobey> i don't know about xchat
[19:13] <XiXaQ> no, we can't have it. I've been working on getting that for years.
[19:13] <dobey> i don't use xchat or empathy
[19:13] <XiXaQ> xchat cannot be included because Empathy supports IRC.. It was the same with Pidgin.
[19:14] <XiXaQ> I'm not talking theory here. All those ideas have been actively dismissed because of these reasons.
[19:14] <dobey> eh. i don't know who you have been arguing with about them
[19:14] <XiXaQ> hmm?
[19:14] <dobey> but dismissal does not constitute invalidity
[19:15] <dobey> evolution can also do rss, btw
[19:15] <XiXaQ> this is not just me. From time to time, on the mailinglists, these discussions have popped up over the years, and have been shot down.
[19:16] <dobey> sounds like health care :)
[19:17] <XiXaQ> I've always agreed with the philosophy. I still do, which is why I don't like having Tomboy as a glaring exception to a nice rule.
[19:18] <dobey> i rather think that evolution is the exception. but perhaps the right arguments have yet to be made, to get the changes done
[19:19] <dobey> granted, any such changes are highly unlikely to happen in lucid, given it's an LTS
[19:23] <dobey> i have to run for a bit, later :)
[19:23] <XiXaQ> oh, I love Evolution, I use it all the time.
[19:23] <XiXaQ> this is getting off topic anyway, I think. :)
[19:23] <XiXaQ> I got the answer. Thanks :>
[22:52] <Dont-Hate> hello
[22:52] <Dont-Hate> I need a little help , any body here to share with me some tips
[23:04] <Izinucs> What's the status with kubuntu and the ubuntu one service.. is kubuntu setup to autosync with ubuntu one like ubuntu is?
[23:15] <Dont-Hate> any body there


[00:02] <bregma> cnd, no matter what I try the pthreads libs are not getting picked up for xorg-gtest when I try to build geis HEAD, have I missed something obvious?
[00:03] <cnd> bregma, the probably need to be specified manually in LIBADD or LDADD
[00:03] <cnd> are they?
[00:04] <bregma> you mean I need to explicitly specify a dependency of xorg-gtest that only gets used by xorg-gtest and nothing in geis?  that seems broken.  Why does it work for you and jenkins?
[00:07] <cnd> I don't know, but specifying a dependency of another library that you built yourself doesn't make sense to me
[00:08] <cnd> sorry, it makes sense to me
[00:08] <cnd> when using the Makefile-xorg-gtest.am from xorg-gtest, it adds -lpthread to XORG_GTEST_LIBS
[00:09] <bregma> why isn't that symbol defined in the xorg-gtest autoconf macro, they way it is for pretty much everything else under the sun?
[00:20] <cnd> bregma, perhaps it should
[00:31] <bregma> is there any reason I shouldn;t upload utouch-evemu at this point?
[00:36] <cnd> bregma, nope :)
[00:37] <cnd> the issue I was thinking about yesterday, device props, has been implemented since forever
[00:37] <cnd> I just didn't realize it :)
[00:37] <cnd> there are no outstanding bugs, so have at it
[00:45] <bregma> done, one down
[00:46] <cnd> bregma, MPs out: https://code.launchpad.net/~chasedouglas/utouch-geis/ungrab-test/+merge/100060 https://code.launchpad.net/~chasedouglas/utouch-geis/fix-ungrab/+merge/100061
[00:53] <cnd> bregma, what do you think about a geis release? should we wait for dandrader's fixes?
[00:53] <cnd> he seems somewhat close, but they are also merely refinements
[00:53] <cnd> since we currently have a broken geis in precise
[00:53] <cnd> it's kinda late today anyway though...
[00:54] <cnd> I suppose we might as well wait till tomorrow
[00:56] <bregma> doesn't his MR do the entire fix?
[00:57] <bregma> either way, I want his fix in if possible, and tomorrow is as good a day as any
[00:59] <bregma> what about frame and grail?  are they ready for release?
[01:01] <cnd> bregma, frame has one minor bug that hasn't been worked on yet, not a blocker
[01:01] <cnd> grail is ready
[01:02] <cnd> bregma, oh, I didn't see dandrader's MP :)
[01:03] <bregma> it's just so exciting to get new releases out, it's just like Christmas
[01:03] <bregma> I intend to go over dandrader's fix tomorrow, it's getting late here
[01:10] <cnd> bregma, np, though I might get to it tonight :)
[01:10] <cnd> or how about right now :)
[01:25] <cnd> bregma, I wouldn't worry about reviewing dandrader's branch tonight
[01:25] <cnd> it needs a fix before it's ready to be merged
[01:29] <cnd> I see we reviewed simultaneously :)
[01:53] <bregma> another 15-hour day, time to walk away from the computer
[01:55] <bregma> (not a continuous 15 hours, I'm not an addict)
[02:35] <cnd> heh
[12:07] <Satoris> bregma: trying to execute run_pygeis with newest Geis gives AttributeError: 'module' object has no attribute 'GEIS_INIT_SYNCHRONOUS_START'. Is this a known issue?
[12:45] <bregma> Satoris, is this from an installed package or is it in the build directory?
[12:45] <Satoris> Build directory.
[12:45] <Satoris> In-source build.
[12:47] <bregma> I suspect the problem is in trying to pick up the new python runtime from within the build tree, I've had problems with that and I'm not sure if I ever fixed them all
[12:47] <Satoris> So effectively bzr branch, cd, autogen, configure, make, cd python, ./run_pygeis
[12:48] <Satoris> But shouldn't SYNCHRONOUS be in the system tree also, because I have the daily build PPA.
[12:48] <Satoris> And inded, running pygeis from /usr/bin fails also.
[12:51] <Satoris> Should I file a bug on this?
[12:52] <bregma> yes, there's a line missing from python/geis/__init__.py
[12:56] <Satoris> I see it. But after fixing that I get a different error.
[12:57] <bregma> AttributeError: 'NoneType' object has no attribute 'activate' ?
[12:58] <Satoris> Yes.
[12:59] <bregma> that looks like a bug in pygeis itself, it explicitly passes None to a fucntion and calls .zctivate() on it
[12:59] <bregma> s/.zctivate/activate/
[13:00] <bregma> dunny what the developer was thinking there
[13:01] <bregma> I think that tool may need to be rewritten
[13:02] <Satoris> Is there an other way to test the Python bindings?
[13:04] <bregma> geisview should work, it's the main python tool
[13:05] <bregma> only I think you need to set LD_LIBRARY_PATH and PYTHONPATH manually if you run it in the build directory, I can't remember is I wrote a wrapper script
[13:08] <Satoris> There does not seem to be one.
[14:14] <cnd> bregma, tvoss, Satoris: standups!
[14:15] <cnd> I'll be working on releases for much of the day I think
[14:15] <tvoss> chromium gyp fun, restored geis green on jenkins
[14:15] <cnd> then looking through any and all bugs I can figure out
[14:15] <tvoss> refactored parts of the patch to ease testing
[14:15] <bregma> what's the status on frame and grail releases?
[14:16] <Satoris> Found critical bug in launchpadlib, bug fixes and code cleanup.
[14:16] <Satoris> s/critical/high/
[14:16] <cnd> bregma, they just need to be done
[14:17] <bregma> mm'kay
[14:17] <cnd> bregma, geis in jenkins has one failure
[14:17] <bregma> I'm waiting for dandrader's fix to get in before making a geis release
[14:17] <cnd> Geis1AttributeTests.tap_touch_count
[14:17] <bregma> right
[14:17] <Satoris> bregma: will merge the Python fix in a few seconds.
[14:18] <cnd> bregma, I'm not sure what's wrong with it off the top of my head
[14:18] <bregma> I can reproduce the tap count failure locally
[14:18] <bregma> I'll take a look and see if I can spot anything
[14:18] <cnd> ok
[14:19] <tvoss> bregma, if it helps: it only happens on amd64
[14:20] <cnd> tvoss, no it happens on i386 too
[14:20] <cnd> bregma, tvoss, Satoris: I'm leaving for a couple hours
[14:20] <tvoss> cnd, ack
[14:20] <cnd> will be back, in an undisclosed location, soon :)
[14:20] <bregma> I plan to take the week end off this week
[14:23] <bregma> in the mean time, if we're asked, we will neither confirm nor deny knowledge of your whereabouts
[14:24] <Satoris> cnd: did not put the script in Helipad or Arsenal due to the bug and confusion on what will happen to those projects.
[14:26] <bregma> tvoss, you have #950974 assigned to you for utouch-grail, it's targeted for this release and marked as 'in progress': should that be changed or is there a fix pending?
[14:26] <tvoss> cnd,
[14:26] <tvoss> bregma, fix is pending, I can have it in like next week
[14:30] <bregma> I would like to release utouch-grail 3.0.4 today to get the tap fixes out and get some wider testing of the touch accounting changes, we can push  #950974 into the 3.0.5 release
[14:30] <tvoss> bregma, that would be great
[14:30] <bregma> utouch-frame has no outstanding bugs targeted, it should go out today, too
[16:25] <cnd> tvoss|dinner, bregma: I'm back
[16:26] <cnd> the portland posse is having a knitting session at the OSU open source labs
[16:26] <bregma> do you knit?
[16:27] <cnd> knitting is a euphemism :)
[16:29] <bregma> not to my wife
[16:29] <bregma> knitting is a religion
[16:49] <cnd> dandrader, do you have a fix for xsync alarms in the utouch-grail tools?
[16:49] <cnd> if not, I'll try to whip one up
[16:51] <dandrader> cnd, I do but own my own version test app derived from those tools. not published anywhere. It's not in a perfect shape so feel free to do so
[16:51] <dandrader> s/own my/on my
[16:51] <cnd> ok
[16:58] <bregma> dang, I just realized I booked the wrong return date for UDS
[16:59] <bregma> I booked a return flight on Thursday instead of Saturday
[16:59] <bregma> tere are no convenient flights Saturday anyway, since BART doesn't start running until 06:00
[17:01] <cnd> that sucks
[17:02] <bregma> evidently if you want to leave the Bay Area during daylight hours and head east you are out of luck
[17:04] <cnd> that seems odd
[17:04] <cnd> bregma, I'm leaving friday late morning to go to indian
[17:04] <cnd> indiana
[17:05] <cnd> actually, it's early afternoon
[17:05] <cnd> 1:06 PM
[17:06] <cnd> OAK->SLC
[17:06] <cnd> SLC->IND at 5:02 MDT
[17:06] <cnd> dandrader, bregma, I approved the xsync MP
[17:09] <cnd> dandrader, is it necessary to delete the alarm?
[17:09] <cnd> I guess I'll find out
[17:09] <dandrader> cnd,  if not you will get an endless streams of alarm events from the time your timeout has been reached
[17:09] <cnd> ok
[17:17] <cnd> dandrader, oh wait
[17:17] <cnd> you forgot an XFlush after creating the alarm
[17:18] <dandrader> cnd, hmm, what its absence can cause?
[17:18] <cnd> the request would be put into the Xlib queue
[17:18] <cnd> but it might not be sent to the server
[17:18] <cnd> so in effect, the alarm may be set now, or any time in the future
[17:18] <cnd> including after it was supposed to fire :)
[17:19] <cnd> so a tap may not be recognized properly
[17:20] <dandrader> it has already been merged. Should I make a new proposal with this addition?
[17:20] <dandrader> cnd,
[17:20] <cnd> dandrader, just commit it on top
[17:20] <dandrader> ok
[17:20] <cnd> and reference that it was missed in the MP
[17:22] <cnd> bregma, any luck on that geis test?
[17:23] <bregma> not yet
[17:24] <cnd> bregma, you haven't released grail yet, have you?
[17:24] <cnd> I'm going to fix the tools for the xsync alarm stuff
[17:25] <cnd> nope, doesn't look like it
[17:27] <bregma> all I did with grail was fix the failed daily build
[17:28] <cnd> k
[17:40] <bregma> bah, I can't get the tap_touch_count test failure to happen locally any more
[17:46] <bregma> whoops, got it again, it's very transient
[18:01] <cnd> hmm
[18:02] <cnd> dandrader, I think the positivetransition test is just broken in the server
[18:02] <cnd> and I just don't feel like maintaining a list of alarms
[18:02] <cnd> so I'm going to try fixing it instead :)
[18:02] <dandrader> cnd, you're my hero :)
[18:05] <cnd> dandrader, would we still have to delete the alarm?
[18:05] <cnd> or do you think it would just disappear?
[18:05]  * cnd digs into the source
[18:06] <dandrader> cnd, I would think you have to delete in any case
[18:16] <cnd> dandrader, interesting, embedded in the sync implementation is a coment and if statement that we can use
[18:16] <cnd> or not
[18:16] <cnd> it didn't do what I thought it would :)
[18:16] <cnd> about to install my debug xserver build though
[18:16] <cnd> we'll find out
[18:29] <cnd> dandrader, aha!
[18:30] <cnd> http://paste.ubuntu.com/907656/
[18:30] <cnd> notice that I set the delta to 0 and used XSyncCADelta when creating the alarm
[18:30] <cnd> if the delta is 0, the alarm will only fire once
[18:31] <cnd> and then there's XSyncChangeAlarm
[18:31] <cnd> so we can have one alarm per grail instance
[18:31] <cnd> and just keep changing it as needed
[18:32] <dandrader> what if you need more than one timeout to be set simultaneously (ie. one at X+123 and another at X+345)
[18:33] <dandrader> I mean, I you want to set a new timeout before the current one timed out
[18:33] <cnd> dandrader, you could have two alarms, but when would you need two alarms for one grail instance?
[18:33] <cnd> if you need to set a new timeout that is later than the current one, then just change it
[18:34] <dandrader> so you don't need to update grail state at both moments, X+Y and X+Z? Only at X+Z?
[18:35] <cnd> correct
[18:35] <dandrader> ah, then that simplifies things
[18:35] <cnd> whatever grail says *now* is all that matters
[18:35] <dandrader> I didn't make that assumption
[18:35] <cnd> admittedly, the xsync implementation didn't work quite like that
[18:35] <cnd> I'm trying to fix up the grail test case right now
[18:35] <cnd> to ensure it all works properly
[18:37] <dandrader> cnd,  by the way: what the heck this delta means (in XSyncAlarmAttributes)?
[18:38] <dandrader> now that you've been enlightened by reading the source code :)
[18:38] <cnd> dandrader, apparently, it determines the *next* timeout after the alarm fires
[18:38] <cnd> it defaults to 1
[18:38] <cnd> so that's why the alarm continuously fires
[18:38] <cnd> I think we should be using PositiveTransition, but it doesn't work
[18:38] <cnd> but PositiveComparison + delta = 0 is good enough
[18:40] <dandrader> what a strange API...
[18:46] <cnd> sadly, I only have my netbook with me
[18:46] <cnd> much slower than behemoth...
[18:49] <cnd> dandrader, http://paste.ubuntu.com/907686/
[18:50] <cnd> it includes a fix where the grail test was still querying the server time instead of using the alarm notify event
[18:50] <cnd> oops
[18:56] <bregma> it looks to me like the cause of the intermittent tap_touch_count failure is that the captive X server does not receive notification of the evdev device until the test is over: the udev message is delayed until the write on the device is closed
[19:03] <cnd> bregma, hmm... interesting
[19:04] <cnd> bregma, do we need to flush the uinput writes?
[19:11] <bregma> I dunno, I'm still tracing through, but there's definitely something weird with ordering, because I play with the select() in the test and still nothing happens in the X server until the test starts to shut down
[19:11] <bregma> except when it works
[19:16] <bregma> ah, no, I think the server can;t open /dev/event/input19 (EBUSY), and gives a "PreInit returned 11" and ignores the device
[19:17] <cnd> bregma, that's likely because another X server has grabbed it
[19:18] <cnd> bregma, there's two remedies:
[19:18] <cnd> 1. run your tests in a VT
[19:18] <cnd> 2. install the xorg-gtest from git master which includes an X snippet to *not* grab virtual test devices
[19:18] <cnd> and then restart your X server
[19:18] <cnd> and ensure the test device has "Virtual Test Device" somewhere in its name
[19:19] <cnd> dandrader, MP for grail: https://code.launchpad.net/~chasedouglas/utouch-grail/xsync-alarm/+merge/100226
[19:19] <cnd> dandrader, would you be interested in releasing and creating an upload for grail after that's merged?
[19:20] <dandrader> cnd, sure
[19:20] <cnd> biab, going to get lunch
[20:12] <cnd> dandrader, ok, lets make a release of grail
[20:12] <cnd> I've started tracking bugs better, following bregma's lead :)
[20:12] <cnd> so let's start by looking at the open grail bugs
[20:14] <cnd> https://bugs.launchpad.net/utouch-grail
[20:14] <cnd> everything that is Fix Committed should be milestoned for 3.0.4
[20:15] <dandrader> nine in total
[20:15] <cnd> hmmm... wish I could search for unmilestoned bugs
[20:16] <dandrader> ok, they all have their milesone correctly set
[20:17] <cnd> ok
[20:17] <cnd> and every other bug should be sane
[20:18] <cnd> oops, I need to mark the xsync alarm bug as fix committed
[20:18] <cnd> ok, looks good
[20:18] <cnd> dandrader, now, we can make a release
[20:19] <cnd> I fixed make distcheck (yay), so checkout trunk, configure it, then run sudo make distcheck
[20:19] <cnd> probably on a VT unless you have the xorg-gtest snippet installed
[20:19] <cnd> cause it will attempt to run the tests
[20:20] <cnd> hopefully they all pass and it generates the tarballs
[20:20] <cnd> then release it upstream on lp :)
[20:21] <cnd> let me know when you're done
[20:21] <dandrader> ok
[20:41] <dandrader> cnd, release done. now for the package?
[20:41] <cnd> dandrader, now we have to move all the bugs to fix released
[20:41] <cnd> for the upstream package
[20:41] <cnd> I'll start from the bottom of the bug list
[20:42] <dandrader> cnd, so you will change that statuses yourself or I do it?
[20:42] <cnd> I can fix them
[20:42] <cnd> you can start the packaging
[20:43] <dandrader> ok
[20:43] <cnd> when you run bzr mu, before committing we need to add all the utouch-grail (ubuntu) bugs fixed to the changelog
[20:46] <cnd> alright, grail only has one real bug that is low
[20:46] <cnd> dandrader, btw, remember to leave the release as UNRELEASED
[20:47] <cnd> when committing entries in the debian/changelog
[20:59] <cnd> hmm, network is down here
[21:01] <cnd> the network died here
[21:01] <cnd> did I miss anything?
[21:33] <cnd> dandrader, how's it going?
[21:33] <dandrader> cnd, getting there
[21:33] <cnd> ok
[21:33] <cnd> I was afraid I never really reconnected :)
[21:34] <dandrader> crap. clicked on the wrong button
[21:35] <cnd> heh
[22:15] <cnd> urgh, I think the "Warning: failed to get previous touch value" bug has a root cause in mtdev
[22:16] <cnd> dandrader, you sure things are going ok? :)
[22:16] <dandrader> cnd, hehehhehe. yes. every time some missing bit and I have to rollback and commit again
[22:17] <cnd> heh
[22:23] <dandrader> source package looks good. now running pbuilder
[22:29] <cnd> cool
[22:31] <cnd> nope, I think the warning is due to a bug in xserver-xorg-input-synaptics
[22:33] <dandrader> what warning?
[22:33] <dandrader> anyway, pushed stuff to lp:utouch-grail/ubuntu
[22:33] <dandrader> cnd, ^
[22:34] <cnd> you might see the warning in ~/.xsession-errors
[22:34] <cnd> or when running any of our command line tools
[22:34] <cnd> when using the magic trackpad
[22:34] <dandrader> cnd,  I think the next step now is dput? so you will take it from here
[22:35] <dandrader> ?
[22:35] <cnd> yeah, review, sign, and upload :)
[22:35] <cnd> I'm checking it out now
[22:36] <dandrader> ok. I'm done for today. have a nice weekend!
[23:33] <cnd> bregma, are we releasing geis today?
[23:34]  * cnd guesses no...
[23:36] <bregma> I don't think so
[23:36] <bregma> not until I get all the tests to pass on my machine
[23:37] <bregma> there appears to be some sort of refcounting problem that sometimes causes the backend not to get properly deleted, which means the X connection does not get closed
[23:38] <bregma> I think I have it fixed, and it just moves somewhere else
[23:39] <bregma> typical