 I was trying to work on this part last week but the PDF I found on Internet with the informations isn't text but images, so I can't search for keywords
[03:24] <marcoagpinto> this gives a ton of extra work
[03:24] <marcoagpinto> yes, with cola
[03:25] <marcoagpinto> I won't risk opening the PDF with Word 365 as it may contain virus
[03:25] <marcoagpinto> :)
[03:26] <marcoagpinto> it is from the US military
[03:26] <marcoagpinto> in 2012 in the masters I went to the military academy to copy my PowerPoint for the exam and my pen drive got infected with a virus which  no antivirus found
[03:27] <marcoagpinto> only after I inserted the pen drive in Ubuntu is when I saw hidden files
[03:27] <sarnold> marcoagpinto: have you tried https://github.com/manisandro/gImageReader or similar tools?
[03:27] <marcoagpinto> ahhhh
[03:27] <lotuspsychje> you exchange data with the military?
[03:27] <marcoagpinto> :)
[03:27] <lotuspsychje> got fancy friends marcoagpinto
[03:27] <marcoagpinto> lotuspsychje: I studied in the military academy
[03:27] <marcoagpinto> :)
[03:27] <lotuspsychje> wow wow
[03:27] <lotuspsychje> no cola jokes from me here
[03:28] <marcoagpinto> https://marcoagpinto.com/me_militarymasters.html
[03:29] <sarnold> lol the can of coke
[03:29] <marcoagpinto> yes, a gift
[03:29] <marcoagpinto> :)
[03:29] <marcoagpinto> I was forbidden to drink cola at the academy, but I was offered one after the exam
[03:30] <lotuspsychje> haha
[03:31] <sarnold> cool :D
[03:35] <marcoagpinto> damn militaries have virus no software can detect
[03:35] <marcoagpinto> :)
[03:35] <marcoagpinto> it is always dangerous
[07:41] <ducasse> good morning
[09:40] <marcoagpinto> ahhhh... back from some sleep
[14:51] <lotuspsychje> ogra: just tested out snapd purge from our previous discuss, works like a charm without issues
[14:51] <ogra> indeed 🙂
[14:51] <lotuspsychje> unloads all the related snap loops and snap store and done
[14:52] <lotuspsychje> tnx for the hint!
[15:06] <Maik> lotuspsychje: consuming too much memory?
[15:06] <lotuspsychje> Maik: no, it was a test for myself after a conversation with ogra
[15:07] <Maik> ah ok
[15:07] <lotuspsychje> i always thought snapd removed essential gnome base parts aswell, wich it did not
[15:07] <Maik> indeed ;)
[15:08] <lotuspsychje> i dont mind snapd by default, but handy to know it can be a choice afterall
[15:56] <imrjd> users should have the choice to install either from a deb based package or snap
[15:57] <lotuspsychje> imrjd: at ubuntu setup you mean?
[15:58] <imrjd> from app store
[16:00] <lotuspsychje> imrjd: there's snap-store vs gnome-sofware
[16:00] <imrjd> if Pop-os can do it why not Ubuntu
[16:01] <lotuspsychje> how does popOs handle it?
[16:02] <oerheks> interesting, does pop os offer all snap packages as deb? no.
[16:02] <oerheks> all latest version as deb? no.
[16:02] <imrjd> no, we can select if we want to install as a deb or a snap
[16:02] <imrjd> in ubuntu the source is only snap
[16:03] <oerheks> so.... does pop os offer all snap packages as deb?
[16:03] <imrjd> yes
[16:03] <imrjd> i had Pop-os for a while
[16:03] <oerheks> no, it does not.
[16:06] <imrjd> then?
[16:06] <oerheks> i think you mix up with flatpak
[16:06] <leftyfb> imrjd: since popOS is derived from Ubuntu, what you are saying makes no sense. If a package is only available as a snap ubuntu and there's no .deb package, then PopOS does not have a .deb available
[16:07] <leftyfb> imrjd: can you name 1 example of where PopOS has a .deb available for a package where Ubuntu only has a snap and no .deb?
[16:07] <oerheks> skype.deb?
[16:10] <leftyfb> I don't know that I would accept skype as an example. skype.com has them available there. If PopOS has it as well, they are just copying it from there. Also http://apt.pop-os.org/proprietary/pool/focal/main/binary-amd64/s/  I don't see skype listed there
[16:11] <leftyfb> imrjd: can you name 1 example of where PopOS has a .deb available for a package where Ubuntu only has a snap and no .deb?
[16:12] <oerheks> sublime text?
[16:12] <leftyfb> oerheks: are you asking or giving examples?
[16:12] <oerheks> as example
[16:12] <imrjd> Spotify
[16:14] <leftyfb> imrjd: I'm pretty sure PopOS is just copying the .deb from spotify's website and hosting it. They do not build it themselves.
[16:14] <imrjd> its available for installation
[16:18] <imrjd> you can check it out in a VM
[16:18] <imrjd> Pop-Os
[16:19] <imrjd> only reason i am ubuntu is most apps and hardware have good chance to work and supported
[16:21] <imrjd> that is why i was cribing about a deb package for spotify
[16:22] <imrjd> i want to avoid snaps as much as i can
[16:23] <oerheks> i want to avoid binairy blobs :-D
[16:24] <imrjd> snap doesn't have binary blobs
[16:25] <imrjd> In Pop-os when you go to app store which is based on elementary, you can select to install a package as a deb
[16:27] <oerheks> firefox in ubuntu-software, gives 2 instances, deb and snap
[16:27] <oerheks> just that silly spotify-client is available as snap only
[16:30] <imrjd> ubuntu just wants to shove snaps to us
[16:30] <imrjd> in ubuntu store there are two firefox, one in deb format and one in snap
[16:31] <oerheks> i would use the firefox snap if i want the newest next version
[16:32] <imrjd> wouldn't apt update it also?
[16:32] <oerheks> apt could, but snap have their own mechanism to check
[16:33] <imrjd> brb
[20:00] <sarnold> heads up, the new grub2 updates are a significant change from the past https://discourse.ubuntu.com/t/grub2-secureboot-bypass-2021-and-one-grub/21200 -- we're not going to release these immediately, we're going to go through the -proposed process, if you've got time and inclination to test these out, please provide feedback on https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/1917509
[22:36] <jeremy31> Anybody know what program to use to extract a windows exe file that file roller won't handle?
[22:37] <daftykins> is it a self extractor?
[22:38] <daftykins> if you could pop it somewhere online i don't mind taking a stab
[22:38] <jeremy31> Not sure, it is for a wireless driver
[22:39] <jeremy31> It is the first one at https://www.totolink.net/home/menu/detail/menu_listtpl/download/id/128/ids/36.html
[22:40] <jeremy31> The linux driver is for Ralink but the device has a Realtek USB ID
[22:40] <daftykins> hrmm the top V3 link is giving me a zip
[22:40] <jeremy31> daftykins: A exe packed in a zip
[22:40] <daftykins> gotcha, judged too quick xD
[22:41] <jeremy31> I thought it would be easy when I saw the zip file
[22:43] <daftykins> just having a play with it, 7-zip had no idea what to do which is rare
[22:44] <jeremy31> I think I tried that and innoextract
[22:47] <daftykins> ah ha got it
[22:47] <daftykins> one mo
[22:48] <daftykins> ok if i PM to share the link? don't want it in public logs :D
[22:49] <jeremy31> daftykins: try a PM now
[23:07] <sarnold> binwalk may know how to cope
[23:09] <daftykins> it was one of those evil installshield wrappers where you can't even view the contents of the .cab that sneakily unzips to %temp% upon run
[23:10] <daftykins> jeremy31: this something you just bought?


[00:14] <lool> /!\ Mir FTBFS in PPA
[00:15] <lool> racarr: https://launchpadlibrarian.net/153780284/buildlog_ubuntu-saucy-amd64.mir_0.0.15%2B13.10.20131014-0ubuntu1_FAILEDTOBUILD.txt.gz
[00:15] <lool> it's this flaky new test
[00:15] <lool>  10/155 Test  #10: acceptance-tests.ServerShutdown/OnSignal.* .............................***Failed    0.02 sec
[00:15] <lool> I've retried the builds
[00:15] <lool> but this is no good
[00:15] <lool> kgunn: ^
[00:22] <kdub> lool, alan_g was looking into that towards the end of euro-day
[00:23] <lool> failed again
[00:26] <lool> it's kind of unfortunate because it built on armhf
[00:26] <lool> and that will block other builds like the platform-api fix
[00:42] <lool> ok, succeeded on 3rd try
[00:45] <racarr> lool: Yay. Thanks
[00:46] <lool> racarr: would still be good to fix this  :-/
[01:10] <racarr> lool: I know I think Alang is working on it
[01:16] <lool> unity-system-compositor and platform-api now in PPA
[01:23] <racarr> lool: I think we should get some good autopilot runs when it runs :D
[01:25] <lool> yeah
[01:25] <lool> especially with the keyboard fix
[01:47] <racarr> Mm :D
[02:11] <RAOF> mlankhorst: What ended up being the problem with nested? I'm trying to rework it to remove the bonghits involved in mystically passing around a gbm_device *.
[03:25]  * duflu wonders what said "bonghit" looks like in code
[07:02] <tvoss> good morning
[07:03] <RAOF> tvoss: Good morning!
[07:03] <tvoss> RAOF, hey there :) how goes?
[07:04] <RAOF> Acceptably.
[07:05] <RAOF> Thinking about foreign surfaces, still trying to figure out precisely what mlankhorst's patches for nested-gbm actually *do*, so we can make the nested code less maniacal, the usual.
[07:05] <duflu> Maniacal is fun, in small portions
[07:09] <RAOF> I'm a fan of not doing http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/nested/nested_platform.cpp#L59 and http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/gbm/native_gbm_platform.cpp#L37
[07:44] <tsdgeos> guys
[07:44] <tsdgeos> what's calling mir::graphics::android::MirNativeWindow::dequeueBuffer ?
[07:44] <tsdgeos> i can't seem to grep-find what calls it
[07:44] <tsdgeos> but i have a thread here that is doing it
[07:44] <tsdgeos> so someone is :D
[07:45] <tsdgeos> #25 0x42aad0c4 in mir::graphics::android::MirNativeWindow::dequeueBuffer (this=<optimized out>, buffer_to_driver=0x5219b970) at /build/buildd/mir-0.0.14+13.10.20131011/src/shared/graphics/android/mir_native_window.cpp:165
[07:45] <tsdgeos> #26 0x4468ab0e in ?? ()
[07:45] <tsdgeos> #27 0x4468ab0e in ?? ()
[07:51] <alf_> tsdgeos: AFAIK, it's called only by the driver. We pass this to the android drivers, as part of our custom native window implementation.
[07:52] <om26er> duflu, hello! when your second branch lands re: bug 1227739 is someone working on using those changes in unity-mir or platform-api ?
[07:52] <tsdgeos> alf_: i see
[07:53] <duflu> om26er: The main fix for Mir isn't even proposed yet. Those awaiting review are just prereq enhancements. But no, no one is assigned the platform-api task.
[07:54] <om26er> duflu, that means you have another branch inprogress ?
[07:54] <tsdgeos> alf_: thing is, if i shutdown unity+mir when nothing is moving, it's all fine, if i shut it down while some animation is going on (i.e. there's painting) this is one of the threads that seems to be kept alive
[07:55] <duflu> om26er: Yes. It's blocked by the one still awaiting review (because I fear it could be rejected so don't want to complete the fix based on that)
[07:55] <tsdgeos> can't totally blame on it, but i wonder who is supposed to tear it down
[07:56] <om26er> duflu, ok, thanks.
[07:56] <tsdgeos> btw, if the comment in https://code.launchpad.net/~aacid/mir/fix_mismatched_delete/+merge/190885 is true shouldn't the CI job be fixed so that it merges the target before running CI?
[08:00] <alf_> tsdgeos: Mir should be tearing the graphics subsystem down. A couple of things could be going wrong here: 1. Mir is not tearing down correctly 2. Mir is not tearing down at all, because e.g. the shell is still holding a shared_ptr to a Mir resource/subsystem
[08:01] <tsdgeos> alf_: mir is teared down
[08:01] <tsdgeos> or looks like it to me
[08:02] <tsdgeos> at least mir::run_mir has returned
[08:02] <tsdgeos> of course that doesn't mean it has tearned down properly or much i guess :D
[08:02] <alf_> tsdgeos: what I mean is that if e.g. the shell is holding a strong pointer to Mir's graphics subsystem, the server will be torn down, but the graphics subystem will not be uninitialized
[08:03] <alf_> tsdgeos: at least not at the right time
[08:03] <tsdgeos> alf_: but that "not tearing down" problem only happens when there's an animation running
[08:03] <tsdgeos> if all is static it works
[08:03] <tsdgeos> i don't see us holding an extra resource when animating
[08:04] <tsdgeos> which may be of course :D
[08:04] <tsdgeos> maybe just still haven't found that bit of code
[08:04] <alf_> tsdgeos: yeah, I am not sure either, just guessing, trying to give some leads :)
[08:05] <tsdgeos> sure :-)
[08:08] <alf_> tsdgeos: I know that unity-mir is holding a shared_ptr to a MirSurface, which may be related to this problem. So one possible scenario is: mir server is torn down, graphics torn down, but the MirSurface (which is backed by a "native window" used by the driver) is not destroyed because shell/qt/qml is still trying to use it
[08:09] <tsdgeos> may be
[08:09] <alf_> tsdgeos: valgrind may give you more hints about what is going on there
[08:09] <tsdgeos> i does actually hang/deadlock while we are deleting the window
[08:09] <tsdgeos> i.e. i successfully leave qt's event loop
[08:09] <tsdgeos> and when i try to delete the window
[08:10] <tsdgeos> it goes deep in somewhere
[08:15] <alan_g> duflu: I didn't get a chance to look at lp:~mir-team/mir/verify-MirConnection - is it still a problem?
[08:15] <duflu> alan_g: Not really. I'm now questioning the whole exercise. Might be best to reconsider all libmirclient error handling semantics post-saucy
[08:16] <duflu> Because we need to halt broken clients and show them where they're broken... but that conflicts with the existing design of allowing invalid connection handles to many functions. And in many cases silently ignoring them
[08:17] <alan_g> duflu: OK. What we've implemented isn't self-consistent
[08:17] <duflu> alan_g: Correct
[08:18] <duflu> alan_g: I think we need to detect bad parameters and crash the client immediately. But that's enough of a semantic change I'm struggling to call it a "fix" we could squeeze into saucy
[08:20] <alan_g> duflu: I think it is too big a discussion for this week. But I agree the broad principle
[08:27] <duflu> alan_g: https://bugs.launchpad.net/mir/+bug/1239978
[08:43] <alf_> Saviq: Do you also need a "stopped" event from mir? Returning from run_mir is essentially a "stopped" event.
[08:44] <Saviq> alf_, not right now, but dunno if it'll be needed later by something
[08:44] <alf_> Saviq: My plan is to add "started" for now. If we need it it can be trivially added.
[08:44] <alf_> Saviq: (stopped)
[08:44] <Saviq> alf_, +1
[08:45] <tjaalton> the xorg packages keep getting xmir related crashes all the time, and I doubt those will get fixed as sru?
[08:47] <duflu> tjaalton: True. It would only be a big problem if the crashes can't be easily de-duplicated though... ?
[08:47] <tjaalton> de-duplicated? i've no idea which ones are related to which
[08:49] <duflu> tjaalton: I mean we can deal with it so long as there's sufficient stack info for you to know it's a Mir bug... and then for us to recognize which Mir bug
[08:49] <tjaalton> i mean, shouldn't there be a word sent out that anyone sticking to saucy should just disable xmir?
[08:49] <tjaalton> oh I can recognize xmir from ProcCmdline
[08:49] <duflu> tjaalton: That's a nice thought but in the world of Ubuntu, users will constantly customize and experiment even when we suggest not to
[08:50] <tjaalton> so that's fine, but the bug view is getting cluttered with all these bugs with '[xmir]..' :)
[08:50] <duflu> tjaalton: Is it? Are they correctly assigned to the xmir project?
[08:50] <tjaalton> no
[08:50] <tjaalton> crashers are sent to xorg-server
[08:50] <tjaalton> it's a manual process after that
[08:51] <duflu> tjaalton: I know how that is. Spent most of the past could of years dealing with Unity crashes landing in Compiz :/
[08:51] <tjaalton> although xdiagnose could be smarter..
[08:51] <tjaalton> now that I think of it
[08:52] <duflu> tjaalton: If you could automagically bump them to the xmir project then we'd see them and help with the triage
[08:53] <tjaalton> yeah I'll see if it can be done
[08:54] <tjaalton> depends on apport I think
[09:04] <asac> it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
[09:04] <asac> (something bad, in short, after a couple of minutes)
[09:04] <asac> err
[09:04] <asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
[09:04] <asac> (something bad, in short, after a couple of minutes)"
[09:04] <asac> kgunn: ^^
[09:04] <asac> thats again uncovered/triggered by MIR landing still
[09:05] <tvoss> asac, do we have any more detail on what is going wrong?
[09:06] <asac> tvoss: no its misty dark
[09:06] <asac> tvoss: you run the APs one by one its kind of working... but if it runs all in one shot it will stall completely
[09:12] <tvoss> asac, okay
[09:12] <tvoss> asac, any reason we suspect mir and not u8?
[09:18] <asac> tvoss: so unity8 could be the candidate, but since mir landing started regressing all the tests
[09:18] <asac> its the first stop for every issue until we have managed to get the rest to green once
[09:18] <asac> then we can more easily blame the right folks again
[09:18] <asac> tvoss: if you feel its u8 from the looks, lets have Saviq also check
[09:18] <asac> Saviq: sdk team tests:
[09:18] <asac> 11:04 < asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot +  phablet-test-run ubuntuuitoolkit and see what happens
[09:18] <tvoss> asac, reflashed phone, testing now
[09:19] <tvoss> asac, just saying that both the Mir team and the U8 team should look into regressions to be more efficient
[09:19]  * Saviq checks
[09:19] <asac> tvoss: yeah. good news is that mir team is in the same team as unity8 :)
[09:19] <asac> so... :)
[09:19] <Saviq> asac, except we're not ;)
[09:20] <asac> we put them organizationally close to each other for such cases
[09:20] <asac> Saviq: both report to kgunn ... who spans this bigger team
[09:32] <alf_> greyback: https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134 , let me know if this is enough for you
[09:34] <greyback> alf_: looks reasonable, will test it out in ~1 hour
[09:34] <alf_> greyback: ok
[09:42] <alan_g> duflu: shall we move the "privatize" and "tidy-up" branches to WIP for the time being?
[09:42] <duflu> alan_g : Yeah "Resubmit" for when we have a T-series branch
[10:26] <tvoss> alf_, got an eta on https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134
[10:26] <tvoss> ?
[10:32] <tvoss> alan_g, ping
[10:32] <alan_g> tvoss: ?
[10:33] <tvoss> alan_g, hey, so we are seeing slowdown of rendering after multiple app starts/stops in autopilot test scenarios
[10:33] <tvoss> alan_g, as I have seen some mp's for ensuring correct session deconstruction recently, could you check if we actually clean up sessions, their surfaces and buffers?
[10:34] <tvoss> alan_g, I have a gut feeling that we somehow have closed sessions alive in mir/unity8
[10:34] <alan_g> tvoss: you mean like the one I wasn't convinced cleaned sessions up?
[10:35] <tvoss> alan_g, yup :)
[10:35] <tvoss> alan_g, perhaps we can prove with a simple cout in the session/surface d'tor?
[10:36] <alan_g> tvoss: have you tried enabling the session mediator report?
[10:36] <tvoss> alan_g, nope, not yet
[10:37] <tvoss> Mirv, didrocks again, to establish a baseline: how do we run the uitk testsuite?
[10:38]  * alan_g realizes that won't prove anything
[10:38] <didrocks> phablet-test-run ubuntuuitoolkit
[10:38] <Mirv> tvoss: flash, apt-get install ubuntu-ui-toolkit-autopilot on device, run phablet-test-run ubuntuuitoolkit
[10:39] <tvoss> Mirv, didrocks thx
[10:39] <alan_g> tvoss: is is probably ms::surfaces that need to be cleaned up - and it is entirely possible that unity hangs onto them after the session closes. (We need a surface manager report)
[10:40]  * alan_g hasn't looked at the unity code for a long time - "possible" is not an accusation
[10:45] <tvoss> alan_g, can you help me and look into that?
[10:50] <alan_g> tvoss: I'm going to knock up a quick report from surface manager and first try a basic mir server. If that's clean I'll try dropping it into u8
[10:51] <tvoss> alan_g, +1, and many thanks
[10:51]  * alan_g hates interruptions
[11:04] <alan_g> tvoss: the ownership of surfaces is such a mess that I can't spot an effective place to report on it. Digging...
[11:05] <alf_> tvoss: I am the submitter, you should ask the reviewers :)
[11:05] <alf_> tvoss: ah, you mean about the fix, working on it
[11:06] <tvoss> alf_, sorry, ENOCONTEXT ;)
[11:06] <alf_> tvoss: @eta for server-started-notification
[11:07] <tvoss> alf_, ah, thanks
[11:07] <dandrader> alf_, Since you have a recent fix in qtubuntu I suppose you've also built it in your device recently. I'm trying to build it myself but I'm getting these errors: http://paste.ubuntu.com/6240031/  I should have all the needed  libraries installed as I've run "apt-get build-dep qtubuntu"
[11:08] <dandrader> any ideas?
[11:10] <alf_> dandrader: the build command is not linking against -lEGL, but I don't know why that is, I didn't have any problems with it
[11:11] <dandrader> alf_, so it's not "-lGLESv2"?
[11:14] <alf_> dandrader: that is only GLES 2, you also need to link against EGL
[11:15] <dandrader> alf_, ah, ok. "EGL", "GLES", they look so similar. :)    thanks for the hint!
[11:36] <Mirv> congrats on the performance improvements (the situation after a fresh boot), extremely nice. scrolling not hitch free yet, but that's probably a combination of many factors.
[11:37] <Mirv> but it's night-and-day difference in swiping between lenses or indicators with the new mir
[11:39] <tvoss> Mirv, thanks :) all credit to kdub :)
[11:53] <alf_> kdub: ^^ \o/
[12:39] <om26er> racarr, ping
[12:48] <tvoss> Mirv, which image will have the performance fix?
[12:57] <Mirv> tvoss: it's now in release pocket (since 0.5h), so the next one. I assume the number is #98.
[13:03] <mlankhorst> RAOF: see the patch I wrote
[13:03] <mlankhorst> RAOF: basically the GBM allocator expected a gbm_surface
[13:03] <mlankhorst> and then it passed gbm_surface->dri_private to the mir call
[13:05] <mlankhorst> RAOF: look at the forwarding calls defined in src/gbm/backends/dri/ for dri2_loader_extension
[13:07] <mlankhorst> dri_get_buffers_with_format  dri_flush_front_buffer dri_get_buffers
[13:11] <om26er> Mirv, when do we spin a new build ?
[13:13] <Mirv> om26er: ask ogra_ or didrocks
[13:13] <ogra_> om26er, once everything planned is in the archive

[13:24] <alf_> greyback: did you get a chance to try the server-started-notification branch with unity(-mir)?
[13:25] <greyback> alf_: just compiling now
[13:26] <alf_> greyback: ok
[14:34] <greyback> alf_: well I've tried your branch, I get a started() call, but I'll have to trust you that it happens when mir is ready to get client connections
[14:35] <alf_> greyback: Trust me, I know what I am doing https://www.youtube.com/watch?v=nnwWKkNau4I
[14:36] <greyback> alf_: :D
[14:41] <Saviq> ogra_, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 looking sane for the SIGSTOP?
[14:42] <ogra_> Saviq, awesome !
[14:48] <alan_g> tvoss: The mir code doesn't leak surfaces. I'll have to update my phone image to investigate further - here's the code if it helps you: https://code.launchpad.net/~alan-griffiths/mir/draft-surfaces-report/+merge/191215
[15:00] <Saviq> ogra_, so... that makes us pause when ran by hand... any way we can detect we're running under upstart?
[15:00] <Saviq> ogra_, to only emit it if we are?
[15:00] <Saviq> hmm we could set an env var
[15:08] <ogra_> Saviq, one sec ... meeting ...
[15:08] <Saviq> ogra_, we went for $UPSTART_JOB == "unity8"
[15:12] <ogra_> Saviq, i dont really get what you are referring to
[15:12] <ogra_> the above patch looks just fine
[15:13] <Saviq> ogra_, if we just "$ unity8" in bash
[15:13] <Saviq> ogra_, the process will pause
[15:13] <ogra_> yeah you should never do that
[15:13] <Saviq> ogra_, and we need to SIGCONT it (or well, "$ fg")
[15:14] <Saviq> ogra_, for testing
[15:14] <ogra_> use upstart to start and stop it
[15:14] <Saviq> ogra_, we often need console output and stuff
[15:14] <ogra_> ah, k
[15:14] <Saviq> ogra_, and it's just easier to not have to go through upstart
[15:14] <ogra_> yeah then add stuff to the unity8 job that reacts to an env var
[15:15] <ogra_> and sets debug options etc
[15:15] <Saviq> ogra_, we have that
[15:15] <Saviq> ogra_, it's still easier to just ./unity8
[15:16] <Saviq> ogra_, I just did if ($UPSTART_JOB == "unity8") raise(SIGSTOP);
[15:16] <ogra_> well, but that wont give you the same env that the user has
[15:16] <Saviq> ogra_, that seriously wrong?
[15:16] <ogra_> i dont think so
[15:16] <ogra_> but i think testing stuff without upstzart involved will taint your results
[15:16] <Saviq> ogra_, we obviously will
[15:16] <Saviq> ogra_, autopilot does, if nothing else
[15:17] <Saviq> ogra_, it's just for day-to-day dev
[15:17] <ogra_> right
[15:17] <ogra_> ship a developer start script ;)
[15:17] <Saviq> ogra_, we do ;D
[15:17] <ogra_> start-unity8
[15:17] <Saviq> ./run
[15:17] <ogra_> ah,, good
[15:17] <Saviq> ogra_, and that we'll make to use upstart
[15:17] <ogra_> ok
[15:18] <Saviq> ogra_, but we don't want to break the "./unity8" case unnecessarily
[15:18] <ogra_> right
[15:31] <kgunn> racarr, hey did you happen to look into why unwanted characters show up in text fields sometimes ? e.g. * when you hit the power button ?
[15:35] <tvoss> alan_g, thanks, are you looking further
[15:35] <tvoss> ?
[15:35] <alan_g> tvoss: Am updating my phone image as we chat
[15:35] <tvoss> alan_g, ack
[15:36]  * alan_g thinks it weird the instructions haven't changed since last time
[15:49] <alf_> Saviq: +1 for not breaking './unity8' case
[15:51] <alf_> Saviq: if the $UPSTART_JOB scheme doesn't work, we could make unity8 read e.g. UNITY8_SIGSTOP_ON_STARTED env. variable, and set that in unity8.conf
[15:51] <alf_> Saviq: when invoking unity8
[15:55] <tvoss> greyback, for my mp: unity-mir already uses mir, which uses exceptions
[15:57] <tvoss> greyback, also: how do you handle cases where creation of an object would result in an invalid object? with an isValid() accessor?
[15:59] <greyback> tvoss: true, we can't avoid that, but it's why if mir throws an exception, unity-mir doesn't try to catch it, nor does unity8, so unity8 quits
[15:59] <greyback> tvoss: yes
[16:00] <tvoss> greyback, well, that's the opposite of exception safety
[16:01] <tvoss> greyback, just saying :)
[16:02] <greyback> tvoss: I'm not arguing, I'm just saying what we do with Qt
[16:03] <tvoss> greyback, ack, I will adjust the mp. Still saying we should revisit how we consider exception safety :)
[16:04]  * alan_g wonders why mir exceptions are propagating to unity on a thread Mir doesn't own
[16:05] <greyback> tvoss: no objection here, as long as Qt's particulars are considered. It was written before exceptions were commonplace, so it wasn't designed to use exceptions itself. I'd love a primer on safe exception usage with Qt
[16:18] <tvoss> greyback, ack
[16:19] <tvoss> greyback, I left the static functions, they are at least as good as const static members
[16:19] <tvoss> greyback, addressed your other comments
[16:21] <greyback> tvoss: thank you
[16:44] <racarr> Morning
[16:44] <racarr> kgunn: I am not sure * whn you hit the powe button was a real thing...I could never reproduce it I think we fixed the other unwanted characters though, that's the thing I was pinging you about it yesterday
[16:46] <racarr> reworded: We fixed some kind of unwanted character bug
[16:46] <racarr> not sure about the power button
[16:46] <racarr> are you sure thats a thing?
[16:49] <davmor2> racarr: open terminal hit the power button you got a ? in the terminal and then a second when you powered it back on
[16:50] <davmor2> racarr: let me see if it is still in place on 97
[16:51] <davmor2> racarr: Ah is a * now
[16:51] <davmor2> racarr: I forgot open terminal and tap it so the keyboard it up then press the power button
[16:52] <davmor2> racarr: although it might be fixed by the fix you are talking about
[16:53] <davmor2> racarr: does that help?
[16:54] <racarr> davmor2: Yes thanks I am checking now
[16:54] <racarr> it could be the bug from yesterday actually...
[16:55] <racarr> as the surface loses focus
[17:00] <racarr> davmor2: kgunn: Ok. it's a thing. its not the thing from yesterday actually just the key event really is going through
[17:00] <racarr> and getting mapped incorrectly
[17:00] <racarr> the shell needs to grab it...need to figure out how to do that with the monitor situation
[17:04] <davmor2> racarr: \o/
[17:08] <racarr> I really thought  I tried that last week
[17:08] <racarr> wonder if I did something silly or there really is some sort of
[17:08] <racarr> inconsistency to the mismapping
[17:08] <racarr> *shrug*
[17:36] <kgunn> racarr: thanks (sorry late response, i had an early lunch)
[17:36] <racarr> s'ok
[17:36] <kgunn> racarr: so the "thing" yesterday...does it potentially fix this one https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1238098
[17:37] <racarr> kgunn: Yes
[17:37] <kgunn> sweet
[17:40] <racarr> kgunn: Very hopefully...shouldn't we have new AP runs very soon
[17:40] <racarr> or do we have them *checks*
[17:40] <kgunn> racarr: yeah...Saviq was saying we should be down to like 1 failure on unity8 AP run
[17:40] <kgunn> racarr: which means they should turn almost everything back on
[17:41] <racarr> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/mako/97:20131015:20131015/4732/
[17:41] <racarr> unity8 and ubuntu-ui-toolkit finally succeeded
[17:41] <racarr> which is nice
[17:41] <racarr> I think the extra characters really are gone because that was killing
[17:41] <racarr> ui toolkit
[17:41] <racarr> filemanager and rssreader got worse?
[17:41] <kgunn> racarr: cool...i'm gonna mark that fixed, was that fix in unity-mir or mir or ubuntu-keyboard
[17:42] <racarr> kgunn: platform-api
[17:42] <kgunn> racarr: thanks...the only one i didn't guess :)
[17:42] <kgunn> wow...its getting creepy dark here in dallas....
[17:42] <kgunn> storm movin' in
[17:43] <racarr> kgunn: lol, and my initial guess for where it would be was
[17:43] <racarr> qtubuntu
[17:43] <racarr> its like some sort of bug wheel of fortune
[17:43] <kgunn> :))
[17:44] <kgunn> ubuntu-roullette
[17:44] <racarr> kgunn: No, that's the adult themed free software chat roulette alternative
[17:44] <kgunn> lol
[17:45] <racarr> I want to write a phone app.
[17:52] <racarr> kgunn: ricmm had a fix in the pipe for the power key stuff https://code.launchpad.net/~ricmm/unity-mir/add-keyfilter-interface/+merge/189727 we are testing, coordinating, etc :)
[17:52] <kgunn> racarr: thanks
[19:00] <lool> guys, just tested latest mir from image that was just published and it's *flying* much better performance with the locking changes   \o/
[19:00] <tvoss> kdub, ^ \\o//
[19:00] <tvoss> lool, thx
[19:03] <kdub> :D
[20:01] <racarr> It actually feels really smooth now :) except for the occasional
[20:01] <racarr> pause
[20:02] <racarr> kgunn: I think you were right with that idea you had last week that
[20:02] <racarr> something happens to the animation curve when you lift
[20:02] <racarr> your finger up
[20:03] <kgunn> racarr: yeah..the numbers from qml timing seem to indicate that also....
[20:03] <kgunn> and gerry was pretty sure there's a decelration in qt somewhere
[20:03] <kgunn> which we've selected by default
[20:04] <racarr> I'm not sure it's exactly that (lifting the finger actually)
[20:04] <racarr> I've just been sitting here for like 5 minutes flipping the dash trying to figure out why it doesnt look right lol
[20:04] <racarr> I think the thing is
[20:04] <racarr> it's quite slow to accelerate, you notice just
[20:04] <racarr> put your finger around an icon and quickly drag
[20:05] <racarr> and the icon falls far behind your finger
[20:05] <racarr> quite a bit...
[20:05] <racarr> and I think
[20:05] <racarr> the finger jerks in response to this haha
[20:05] <racarr> i.e. my physical finger
[20:06] <racarr> because if I really focus on making a smooth motion with my finger and not look at the screen as much it seems pretty smooth
[20:06] <racarr> *shrug*
[20:07] <racarr> it seems also like if you go really fast it will keep up
[20:07] <racarr> so there must be some sort of deacceleration or some acceleration with a weird curve
[20:08] <racarr> there's also something that looks strange when you
[20:08] <racarr> flick fast and focus on white blocks
[20:08] <racarr> like the top bar text...
[20:09] <racarr> but I think that might just be...a weird effect from when the white passes over the light part of the background
[20:09] <racarr> it definitely doesnt look right though
[20:10] <racarr> On the other hand. It works well enough that you can investigate minor issues like this without being distracted by general system failure. Huzzah :D
[20:11] <racarr> kgunn: If nothing critical comes up can I spend some time investigating the animation model? or do I need to dig in to autopilot more
[20:11] <racarr> http://reports.qa.ubuntu.com/smokeng/saucy/
[20:11] <racarr> build 98 is running I guess?
[20:13] <racarr> ricmms branch fixes the power key thing :) just need gerry and saviq to review I guess
[20:35] <Saviq> racarr, ricmm, do we know where the asterisk come from in any case?
[20:36] <Saviq> like who translates PowerKey to * ?
[20:39] <racarr> Saviq: Probably a combination of xkbcommon and qtubuntu...
[20:39] <racarr> probably mostly qtubuntu
[20:39] <racarr> by that I mean we probably have errors in both our xkbcommon mapping and the interpretation in qtubuntu
[20:40] <racarr> though. it does in fact come out of xkbcommon
[20:40] <racarr> mapped to volume up
[20:40] <racarr> and we added that to the qt key table mapping
[20:40] <racarr> so it's a little hard to say
[20:41] <racarr> *thinks*
[21:17] <RAOF> mlankhorst: Where's the canonical location of your patch? I don't think I've got the whole context of your changes.
[21:18] <mlankhorst> RAOF: shrug I merged ubuntu debian packaging, upstream/9.2 branch
[21:18] <mlankhorst> sec :P
[21:18] <mlankhorst> real changes were 2 pastebins I posted here before
[21:19] <mlankhorst> http://paste.debian.net/58054/ git show + git diff appended
[21:20] <mlankhorst> probably applies against the egl-image*-i965 branch
[21:22] <RAOF> Oh, right.
[21:29] <RAOF> Because we were populating gbm_dri.
[21:31] <RAOF> So that's a perfectly good fix, just one that doesn't allow me to stop passing the gbm_dri_device * through the platform.
[21:36] <mlankhorst> :P
[21:36] <mlankhorst> well the #if 0'd code still works
[21:37] <mlankhorst> but yeah needs gbm if available
[21:37] <mlankhorst> lookup extension probably sitll fails, dno if there is one or not
[21:37] <mlankhorst> but it expects a gbm something
[21:38] <mlankhorst> I if 0'd it for debugging, mostly
[21:38] <mlankhorst> that way i can test nested mir path with a demo client
[22:07] <RAOF> mlankhorst: I mean I'd prefer to do something like http://paste.ubuntu.com/6242735/ , which doesn't work, but I don't really see why not.


[00:05] <arraybolt3> Fixing up some IMO critical issues currently, I still hadn't added a way to enforce only one instance being running at a time, nor had I enabled displaying the window in a way other than by clicking a systray icon.
[03:03] <arraybolt3> well everyone's going to hate me for my commit message's verbosity (or lack thereof), but I had to change so many tiny things everywhere that I didn't feel a bunch of individual commits were worth the effort (especially not this early in Lubuntu Update's development history).
[03:03] <arraybolt3> so... pushing "A bunch of improvements" :P
[03:03] <tsimonq2> bah LGTM *rubber stamp*
[03:05] <arraybolt3> Will try to test it a bit more tomorrow and package it. (I didn't get to do a final "does this still update things properly?" test so I'm leery of calling this alpha-quality yet.)
[03:05] <arraybolt3> but by tomorrow there'll probably be new updates to install :D
[03:13] <tsimonq2> Sounds good!
[03:31] <tsimonq2> https://ubuntu-archive-team.ubuntu.com/transitions/html/html/qt-5.15.12.html
[04:13] <arraybolt3> tsimonq2: currently attempting to supplant lubuntu-update-notifier with Lubuntu Update, and I have a question.
[04:14] <arraybolt3> I think the systemd-timer thing isn't necessarily a great idea, since it may attempt to run the updater before the user has even logged in.
[04:14] <arraybolt3> (I could be mistaken there but that's what it looks like to me.)
[04:15] <arraybolt3> Do you mind horribly if I just revert back to the autostart way we used to always do this?
[04:16] <arraybolt3> (also repeatedly executing the new updater will not have the intended effect - it is designed to run as a persistent background process. Re-launching it is how you force the window to appear.)
 Are systemd timers both executed once on login and then again when scheduled, or just when scheduled?
 I'm really not a fan of any kind of persistent background service unless it's a completely separated daemon
 Remember those issues we were having where the LXQt processes are still left hanging with the update notifier?
 I mean having a background storage running for the updater when not logged into lxqt would use resources if you logged into another desktop enviorment as well right
[04:28] <arraybolt3> umm, Lintian is b0rked
 That's the way it currently works/that's the bug but it's not by design
 yeah :(
 I didn't quite have time today to finish that up, but check the transition tracker
 May just be an NCR
[04:28] <arraybolt3> tsimonq2: yeah, I see what you're saying. I don't know how exactly systemd timers really work, I sort of assumed they just always executed when scheduled.
 *shrug* nah I get what you're saying, I dunno, those are just my thoughts, if you have something that works and is still resource efficient I'm game to hear it
 With Lintian... it's definitely broken on Sid right now but is Ubuntu broken too?
 What's happening arraybolt3?
[04:33] <arraybolt3> ahem:
[04:33] <arraybolt3> !ping
[04:33] <arraybolt3> gah
[04:33] <arraybolt3_> tsimonq2: https://termbin.com/xugr
[04:33] <arraybolt3_> (sorry, my main IRC client went into hyper lag mode)
[04:34] <arraybolt3-kirc> tsimonq2: https://termbin.com/xugr
[04:34] <arraybolt3-kirc> did that get through the first time?
[04:34] <arraybolt3-kirc> I can't hardly see what's happening :P
[04:35] <arraybolt3-kirc> looks like my bouncer went down
[04:38] <arraybolt3> oh there now it works
[04:51] <arraybolt3> tsimonq2: I think that since we have other persistent services of sorts in LXQt (namely the panel, PCManFM-Qt, etc.), I'd like to *try* doing this the easy way since it seems cleaner. Iff it causes issues, we can use your hard systemd-based way.
[04:51] <arraybolt3> s/iff/if/
 hahahahahaha looks like it's Perl NCR time
 *shrug* just test with loginctl and make sure that either SDDM or LXQt kills the session right :)
[05:08] <arraybolt3> yeah, that ought to work
 Re Calamares @tsimonq2 selecting "about" on left hand side of installer has links to Calamares team etc but no internet set up until after reboot -
 If you happen to have the time could we please get a bug to track this? (re @Leokolb: Re Calamares @tsimonq2 selecting "about" on left hand side of installer has links to Calamares team etc but no internet set up until after reboot -)
 Will do .. (re @tsimonq2: If you happen to have the time could we please get a bug to track this?)
 Thank you :)
 Subbmitted bug 2049088 (thought that this might have been reported before - but found nothing..  :) (re @tsimonq2: Thank you :))
[17:00] -ubottu:#lubuntu-devel- Bug 2049088 in calamares (Ubuntu) "Calamares install has links to external site but no browser until after install" [Undecided, New] https://launchpad.net/bugs/2049088
[17:25] <tsimonq2> So, after further investigation, yes, the core issue for this has been reported before: https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1981473 - that being said, this specific issue is not one that was in the scope of that bug report.
[17:25] -ubottu:#lubuntu-devel- Launchpad bug 1981473 in calamares (Ubuntu) "Calamares fails to open 'donate' or 'Lubuntu support'" [High, Confirmed]
[17:26] <tsimonq2> IMO both are useful :)
[18:55] <arraybolt3> Back to work today on Lubuntu Update - I forgot that it needed a patched lxqt-sudo, and Palo made some serious improvements to my original patch which I need to test.
[18:56] <arraybolt3> so anyway, currently tangled up with that, also $DAYJOB may interrupt at any time, but that's what I'm on currently.
[18:57] <arraybolt3> also tsimonq2: anything wrong with the version number "1.0.0~alpha1" for the lubuntu-update-notifier package containing Lubuntu Update?
[19:18] <arraybolt3> looking hopeful
[19:20] <arraybolt3> alrighty, it works!
[19:20] <arraybolt3> well enough anyway - it appears to try to display the notification about updates a *little* too early when first booting, but it does start upon login.
[19:20] <arraybolt3> now to see if I can cause pileup
[19:21] <arraybolt3> woohoo, the session pileup bug is gone too!!!
[19:21] <arraybolt3> and you can even show the window without clicking the tray icon.
[19:22] <arraybolt3> So I'm going to label this a success and do some uploads.
[19:24] <arraybolt3> Collaborative development at its best - submit a PR that gets a PR submitted against it that you review and merge so that it can be merged into main :D
[19:42] <arraybolt3> patched lxqt-sudo uploaded
[19:51] <arraybolt3> Lubuntu Update 1.0.0~alpha1 now uploaded.
[19:51] <arraybolt3> it's probably going to depwait but I think the archive is supposed to autoretry those.
[19:51] <arraybolt3> (I made it so that it depended on an equal or greater version of lxqt-sudo as the one I had just uploaded)
[20:07] <RikMills> sometimes it takes its time to retry
[20:08] <RikMills> 'ubuntu-build lubuntu-update-notifier noble-proposed retry' is a one liner to do it
[20:10] <tsimonq2> Sorry, just got back from lunch, walking into another meeting.
[20:10] <tsimonq2> +1 on what RikMills said - thanks for your help here arraybolt3!!!!!!!!!!!!!!!!!!
[20:11] <arraybolt3> Happy to! Everything is pushed to Git and uploaded to the archive.
[20:11] <arraybolt3> NOTE: lubuntu-update-notifier's repo *is untouched.*
[20:12] <arraybolt3> The new packaging and code is in the lubuntu-update repo.
[20:12] <arraybolt3> lubuntu-uodate-notifier's package on the other hand has been clobbered.
[20:13] <tsimonq2> roger roger :)
[20:14] <tsimonq2> Looks like the lxqt-sudo binaries will be published and good in the next hour, I'd set like a sleep 3200 or something :P