[08:55] <pstolowski> Cimi, morning! did you have a chance to test fix-temp-scopes branch of shell plugin?
[09:12] <tsdgeos> Saviq: so what do we do with https://code.launchpad.net/~ted/unity8/delay-indicator-start/+merge/241124 ? ask ted for improvements? approve? discard
[09:12] <tsdgeos> ?
[09:13] <tsdgeos> Cimi: what's missing for a top approval in https://code.launchpad.net/~mterry/unity8/tutorial-refactor/+merge/239874 ?
[09:15] <Saviq> tsdgeos, I think we can discard, will talk to Ted later today
[09:15] <tsdgeos> oki
[09:26] <Cimi> pstolowski, all looks fine
[09:26] <Cimi> thanks :)
[09:27] <Cimi> tsdgeos, I need to re-review the latest changes
[09:27] <Cimi> tsdgeos, it was on hold for design
[09:27] <tsdgeos> i see
[09:30] <Saviq> seb128, bug #1415141 and bug #1417773
[09:32] <seb128> Saviq, not sure, have a "t a a bt" rather than "bt" would be more useful
[09:32] <seb128> rsalveti, ^
[09:32] <seb128> mine had libqnmbearer.so in the bt
[09:32] <seb128> https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1417525 btw
[09:38] <dandrader> tsdgeos, hey
[09:38] <dandrader> tsdgeos, about lp:~dandrader/unity8/indicatorsBarEatsAllInput
[09:38] <dandrader> tsdgeos, you mean that you open the indicators (on a tablet)
[09:38] <dandrader> tsdgeos, then tap several times on the greyed out area
[09:38] <dandrader> tsdgeos, the first tap will make the indicators panel close
[09:38] <tsdgeos> no no
[09:39] <tsdgeos> not the greyed out area
[09:39] <tsdgeos> the top bar
[09:39] <dandrader> tsdgeos, and the subsequent ones will make the foreground app blink
[09:39] <tsdgeos> basically if you press just in the between of the top bar and the greyed area
[09:39] <tsdgeos> but since that's hard that i do is start pressing in the middle of the top bar and then go slowly done
[09:39] <tsdgeos> down
[09:39] <tsdgeos> so eventually i get to the right place
[09:40] <dandrader> greyback, https://launchpadlibrarian.net/196557582/buildlog_ubuntu-vivid-amd64.unity8_8.02.4%2Bbzr1570~ubuntu15.04.1_FAILEDTOBUILD.txt.gz
[09:41] <tsdgeos> dandrader: does that make sense? or want a video?
[09:44] <dandrader> tsdgeos, video
[09:44] <dandrader> tsdgeos, but its it the same thing as what I explained? do you also get this issue? isn't it the same thing?
[09:44] <tsdgeos> it is the same thing
[09:44] <dandrader> tsdgeos, like just tapping in the center of the greyed-out area
[09:45] <tsdgeos> there's just one pixel instead of whole area from before
[09:45] <dandrader> tsdgeos, so what you're hitting is just the very edge of the greyed out are I guess
[09:45] <tsdgeos> guess so yes
[09:45] <dandrader> tsdgeos, its very first, top, row of pixes
[09:47] <tsdgeos> dandrader: let me try to record the video
[09:54] <tsdgeos> dandrader: it's uploading, will tell you once my poor upload link is done
[09:56] <tsdgeos> dandrader: https://www.youtube.com/watch?v=zfsdVA1ZyC8
[10:02] <dandrader> tsdgeos, would you get the very same behavior (and bug) if you tapped right in the middle of the app area not covered by the indicators bar?
[10:03] <tsdgeos> you mean "over the app"?
[10:03] <dandrader> tsdgeos, yes
[10:04] <tsdgeos> no, over the app is fine
[10:04] <tsdgeos> just hides the indicators and that's it
[10:04] <dandrader> tsdgeos, weird. that's not what I get
[10:05] <dandrader> tsdgeos, even if you tap fastly, multiple times ?
[10:05] <tsdgeos> ah you're right, it does happen ^_^
[10:05]  * dandrader wonders if the bug is more evident in the shellRotation branch...
[10:05] <tsdgeos> so it's not just one pixel, it's just pressing fast two times
[10:06] <tsdgeos> so you're right this may be a different bug
[10:06] <dandrader> tsdgeos, so it's the indicator's darkened area that lets input go through while the closing animation is playing
[10:06] <tsdgeos> dandrader: do you want me to check if this happened before and we treat it as a different bug or want to fix it together?
[10:07] <dandrader> tsdgeos, also the flicker is more evident if you have only unity8-dash running
[10:07] <dandrader> tsdgeos, as it will flicker between the white dash ui and the black background
[10:08] <tsdgeos> lol yeah
[10:09] <Saviq> duflu, dandrader http://doc.qt.io/qt-5/qml-qtquick-propertyanimation.html#easing.type-prop
[10:09] <dandrader> tsdgeos, so will you approve the branch then? :-)
[10:10] <tsdgeos> dandrader: sure i'll have another look and open a separate bug for the other thing
[10:10] <dandrader> tsdgeos, ok, thanks!
[11:29] <tsdgeos> damn this internal compiler error
[11:29] <tsdgeos> Saviq: i guess it's making us unlandeable?
[11:29] <Saviq> tsdgeos, yes
[11:29] <Saviq> tsdgeos, people are working on it
[11:29] <tsdgeos> :/
[11:29] <tsdgeos> :)
[12:01] <tsdgeos> Cimi: ping
[12:02] <tsdgeos> Cimi: unping
[12:02] <Cimi> tsdgeos, lol
[12:19] <Cimi_> tsdgeos, https://code.launchpad.net/~cimi/unity8/fix-open-new-scope-from-tmp/+merge/248538
[12:20]  * tsdgeos clicks the button
[12:40] <Saviq> larsu, just so you know https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1385331/comments/9
[12:40] <larsu> thanks
[13:20] <Saviq> @unity: I've a workaround for the armhf compile error, want to just check it in to trunk so that no one has to wait, any opposition http://paste.ubuntu.com/10053410/ ?
[13:21] <mzanetti> +1
[13:21] <mterry> Saviq, +1
[13:21] <mterry> Saviq, make sure you don't have tags  ;)
[13:21] <Saviq> mterry, ;)
[13:21] <Saviq> mterry, I actually do (thanks to colo), but I'll strip them right after
[13:23] <Saviq> @unity: we're back in (unity8 on armhf) building business
[13:23] <dandrader> nice
[13:40] <Saviq> olli, FYI, got a workaround from doko+slangasek for the unity8 build issue, we're unblocked
[13:40] <olli> saweet, what was the issue?
[13:40] <olli> sumding in the toolchain?
[13:40] <olli> Saviq, ^
[13:41] <Saviq> olli, yeah, new gcc release
[13:42] <Saviq> olli, would've known that yesterday already if I realized that silos have proposed enabled (and I was having trouble reproducing, because the new gcc was in proposed still, is moved to release now)
[13:42] <Saviq> s/realized/remembered/
[13:46] <olli> Saviq, thx
[13:46]  * olli takes notes
[14:43] <om26er> MacSlow, Hi!
[14:43] <MacSlow> om26er, hey there
[14:43] <om26er> MacSlow, is there a way to disable the OSD during testing ?
[14:44] <MacSlow> om26er, the tests themselves or the daemon?
[14:44] <om26er> I am trying to fix an Autopilot test for messaging-app and the notifications block the searchbar
[14:44] <om26er> MacSlow, the daemon
[14:45] <MacSlow> om26er, hm...
[14:46] <MacSlow> om26er, can you recompile?
[14:46] <om26er> MacSlow, ahm, no the tests are supposed to run on production
[14:47] <om26er> MacSlow, can't I just stop the notifications service ?
[14:47] <MacSlow> om26er, that would probably be the best idea
[14:47] <MacSlow> but it's a plugin in unity8...
[14:48] <MacSlow> om26er, so it's different from the regular (old-school) desktop notify-osd
[14:48] <om26er> MacSlow, right, I'll try to find other solutions then.
[14:48] <MacSlow> om26er, wait there's a way... once sec
[14:50] <om26er> great :)
[14:51] <MacSlow> om26er, hm... getting rid of /usr/share/dbus-1/services/org.freedesktop.Notifications.service (move it some where else) and restart dbus
[14:51] <MacSlow> om26er, I think that should do the trick
[14:52] <MacSlow> om26er, wait...
[14:54] <MacSlow> om26er, the first idea just disables (old) notify-osd...
[14:54] <Saviq> om26er, I imagine you're talking about an automated, reliable way to do this?
[14:55] <MacSlow> Saviq, I'm wondering if one can disable a single unity8 plugin at runtime
[14:55] <Saviq> MacSlow, I'd say that's the wrong direction
[14:55] <om26er> Saviq, yeah, something like that. Perhaps a gsetting key or some kind of thing
[14:55] <Saviq> om26er, that sounds like we want an autopilot emulator for notifications, where you can actually verify the notification is showing up, and wait for it to close (or interact with it)
[14:56] <MacSlow> Saviq, I know of nothing in unity-notifications that would allow it being disabled at runtime... just uninstaling it, but that's not an option for om26er's needs
[14:56] <om26er> Saviq, that can take a while in cases where we rush 5-6 notifications together. But yes, sounds like a solution in the end.
[14:57] <om26er> initctl stop unity8-notifications :D *dreams*
[14:59] <MacSlow> om26er, but you want something that works for now right
[15:00] <om26er> MacSlow, indeed.
[15:00] <MacSlow> Saviq, I guess that "initctl stop unity8-notifications" is another bullet-point on the nice-to-have list then?!
[15:03] <Saviq> MacSlow, not really, we don't (and I don't imagine we will) have a notification daemon
[15:04] <Saviq> om26er, that helper might have an option to disable it for a while if you need it
[15:04] <MacSlow> Saviq, well in the long run... but currently we kind of still have
[15:04] <Saviq> om26er, or just "consume" them all as they come in
[15:04] <Saviq> MacSlow, no, it's part of the shell
[15:05] <MacSlow> om26er, btw... you just want them to now show up (and block input to surfaces below), right?
[15:05] <MacSlow> s/now/not
[15:05] <Saviq> MacSlow, and it will remain that, even if we'll get the post office in between
[15:05] <Saviq> in which case it might be possible to stop the post office, but that still feels like the bad solution to me ;)
[15:06] <om26er> Saviq, yes I think if we can disable it for a few seconds our purpose will fulfill
[15:06] <om26er> MacSlow, exactly.
[15:06] <Saviq> om26er, if you don't care about the process, couldn't you just prepare the history db before starting the test?
[15:07] <om26er> Saviq, thats one option I was going to look into.
[15:07] <om26er> or create messages before the app starts.
[15:08] <Saviq> om26er, I think there's other, better solutions for this issue indeed :)
[15:10] <MacSlow> om26er, I currently can't think of a way to disable the notifications without messing around with the sourcecode.
[15:11] <om26er> MacSlow, that's fine, I'll discuss with the messaging-app devs for a solution at the history service's end.
[15:11] <MacSlow> om26er, one could change the dbus-interface name and recompile unity-notifications... or - on the unit8-side/QML - make the notification-renderer swallow all notifications
[15:12] <MacSlow> om26er, sorry for the touble
[15:36] <Saviq> MacSlow, has there been a design review of swipe-to-dismiss?
[15:37] <MacSlow> Saviq, yes... that happened looong ago
[15:38]  * Saviq hopes that we'll get the ability to dismiss sds just as well (i.e. dismiss, not reject, in terms of an incoming call)
[15:39] <MacSlow> Saviq, an expanded snap-decision can't be dismissed (closed)... that's by design... collapsed snap-decisions can though
[15:39] <Saviq> oh ok
[15:40] <MacSlow> Saviq, and that's also covered in the qmltest for them
[16:07] <dandrader> tsdgeos, how do I get rid of this silliness? paste.ubuntu.com/10055796/
[16:08] <tsdgeos> export LC_ALL=C ?
[16:08] <dandrader> it's the most diehard qmltest failure we have
[16:08]  * dandrader tries
[16:08] <tsdgeos> or en_US
[16:08] <tsdgeos> or something don't remember
[16:08] <tsdgeos> i usually just run with -i -k
[16:08] <tsdgeos> and then serach for the fail! and if they're this i ignore them :D
[16:09] <tsdgeos> lazy man
[16:16] <Saviq> MacSlow, testNotifications fails for me fairly often: http://paste.ubuntu.com/10055920/
[16:16] <Saviq> (the new one)
[16:17] <Saviq> MacSlow, looks like that failure https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/360/testReport/junit/%28root%29/qmltestrunner/NotificationRendererTest__test_NotificationRenderer/
[16:17] <tsdgeos> Saviq: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1411748 doesn't affect rtm since the code it's fixing is not part of rtm (or wasn't last time i checked)
[16:18] <Saviq> tsdgeos, hmm hmm... news scope on arale, though, not there outside of rtm?
[16:18] <tsdgeos> arale is vivid-based i've been told
[16:18] <Saviq> tsdgeos, ok then I've no way to see that bug
[16:19] <tsdgeos> Saviq: why not? just install vivid on a krillin?
[16:19] <Saviq> and well, there is an rtm channel for it (I'm using... trying to...)
[16:19] <Saviq> tsdgeos, no news scope
[16:19] <Saviq> or is there?
[16:19] <MacSlow> Saviq, yeah... I will look into that.
[16:19] <Saviq> don't think there is
[16:19] <tsdgeos> maybe not
[16:19] <tsdgeos> Saviq: what i did was just get krillin rtm, add the patch that breaks this and then add the patch that fixes it
[16:20] <tsdgeos> ^_^
[16:20] <Saviq> tsdgeos, ;)
[16:26] <mzanetti> kdub: libevdev2 libmirplatform6 libmirserver29 mir-platform-graphics-android mir-platform-graphics-mesa
[16:26] <mzanetti> sorry... should have been kgunn..
[16:26] <kdub> :)
[17:12] <seb128> Saviq, qtmir update in vivid today? ;-)
[17:12] <seb128> I could use a working desktop daily tomorrow
[17:13] <Saviq> seb128, out of my hands, camako and racarr are landing new mir with qtmir now...
[17:13] <seb128> k
[17:13] <Saviq> seb128, let me know if you want just a fixed qtmir package
[17:13] <seb128> well, depending when the other set lands
[17:14] <seb128> I would like to see the gtk fix to land this week
[17:14] <seb128> it would make some of our testing/work easier
[17:14] <seb128> up to you what form that landing takes
[17:15] <Saviq> seb128, I'll find out how the guys are doing and land it myself if needed, before the end of the week
[17:15] <seb128> thanks
[18:24] <tvw> I am using Unity on ubuntu, since I am more a terminal user than a gui-user. No I wonder what desktop environment is best for people who prefer to use a mouse and a gui interface?
[23:39] <mterry> Is anyone familiar with what differences exist between tryTest and testTest?  I've got this problem where a DirectionalDragArea isn't working in testTest but does in tryTest...  :(


[04:08] <Avago_Broadqual> why would ubuntu server route via IPv6 and then stop after about 30 seconds of being online?
[04:08] <Avago_Broadqual> I have given it a static IPv6 address
[04:13] <Avago_Broadqual> ok figured it out, it was an old 16.04 vm that has migrated to 20.04 and I did not configure netplan
[04:14] <Avago_Broadqual> slapped a default config and now I have a SLAAC and DHCP IPv6 that is routable
[15:32] <shubjero> what replaced systemd-timesyncd.service on ubuntu 20.04? We used to use systemd-timesyncd.service on 18.04, then i upgraded and now its gone
[15:33] <shubjero> is there a timesync process I can monitor?
[15:35] <shubjero> On 18.04 I would have zabbix monitor systemd-timesyncd was running as per "systemd+    2665  0.0  0.0 135440  5036 ?        Ssl  Sep23   0:06 /lib/systemd/systemd-timesyncd"
[15:36] <sdeziel> shubjero: systemd-timesyncd is still present in 20.04 (but it moved to a dedicated/separated package)
[15:37] <shubjero> sdeziel: oh ok and I see that chrony is the new defaily
[15:37] <shubjero> *default, ugh
[15:38] <sdeziel> shubjero: installing chrony removes systemd-timesyncd
[15:38] <sdeziel> and yes, chrony replaced the other ntp server/client as the new default
[15:38] <cpaelzer> chrony is the default since bionic
[15:39] <cpaelzer> replacing ntpd
[15:41] <shubjero> thanks sdeziel cpaelzer


[09:24] <sakrecoer> oh no! get well soon Eickmeyer !
[09:27] <sakrecoer> i'm curious about the rationale behind defaulting to pipewire, does it mean ubuntustudio is now less popular among audio producers?
[09:28] <sakrecoer> the config tools states that pipewire is good for most users, but jack+pulse is good professional/prosumer users.
[09:28] <sakrecoer> or... put differently, does it mean ubuntustudio is more popular among all the other crafts than it is with audio producers.
[09:30] <gordonjcp> well, pipewire is getting better and better
[10:47] <sakrecoer> but apparently not good enough yet for professional/prosumer use...
[10:53] <gordonjcp> why do you think that?
[11:03] <sakrecoer> because the audio config tool says so, beacuse my experience says so, and because the pipewire devs say so
[11:05] <sakrecoer> https://ubuntustudio.org/switching-audio-setup/
[11:06] <sakrecoer> in my use case, pipewire shows good improvement in that sound is ok. But latency is very far from acceptable.
[11:07] <gordonjcp> latency is overrated
[11:07] <gordonjcp> what sort of latency figures are you getting?
[11:07] <sakrecoer> overrated? not even a podcaster could work with this latency
[11:08] <gordonjcp> well, how much latency are you talking about?
[11:08] <sakrecoer> i can't give you a number, i don't need a number. it's enough to make unusable for realtime audio recording
[11:10] <sakrecoer> but it's fine with jack, i'm not complaining. i'm just curious why it is the default.
[11:43]  * Eickmeyer is up early for no reason
[11:44] <Eickmeyer> sakrecoer: I just did a demonstration in Riga that proved that Pipewire is ready for professional use. As the person who wrote the audio config, I just need to change some strings. Feel free to use Pipewire and be comfortable.
[12:48] <sakrecoer> except, i can't use pipewire, Eickmeyer. Am used to latency but this is more like a delay pedal.
[12:48] <Eickmeyer> sakrecoer: Why can't you use pipewire?
[12:48] <sakrecoer> because the latency is too high
[12:49] <sakrecoer> i'm at 64 96000 and it's like half second delay
[12:49] <Eickmeyer> I'll have a fix for that soon. You'll be able to lower the latency. I had an issue where it used to be (in the older version) a simple variable change, now it's a big command change.
[12:49] <sakrecoer> cool!
[12:49] <Eickmeyer> Yeah, changing it in the config won't work right now.
[12:50] <sakrecoer> i changed it with a pipewire command...
[12:50] <Eickmeyer> pipewire-metadata by any chance?
[12:50] <sakrecoer> let me check the logs...
[12:50] <sakrecoer> pw-metadata
[12:51] <sakrecoer> i assume it's the same
[12:51] <Eickmeyer> Yep, that's what I needed it to do. So, yes, the same.
[12:51] <sakrecoer> not sure i understand "that's what i needed it to do"
[12:51] <Eickmeyer> You *might* just need a newer version of pipewire. The jack bridge is supposed to be zero latency. You might also try installing pipewire-alsa.
[12:52] <Eickmeyer> "that's what i needed it to do" = the config interface
[12:52] <Eickmeyer> I wrote that thing.
[12:52] <sakrecoer> oh, well it didn't help me.. it got better but far from good enough.
[12:53] <Eickmeyer> You're missing my point though. I had next to no latency when I did my demo in Riga.
[12:53] <sakrecoer> what's your point?
[12:54] <Eickmeyer> My point is something is up with your system if it is having trouble. You might need a newer version of Pipewire, the one in 23.10 isn't the RC for 1.0
[12:54] <sakrecoer> wait...
[12:55] <sakrecoer> that sounds almost like "it works on my machine, so your machine is broken"
[12:55] <Eickmeyer> It works on 3 of my machines.
[12:55] <Eickmeyer> And Robin Gareus's machines.
[12:55] <sakrecoer> well... it works on none of mine
[12:56] <sakrecoer> one with firewire, i suppose that is "expected".. the other with a USB audio card
[12:56] <Eickmeyer> Try installing pipewire-alsa, reboot, and see if that helps.
[12:57] <sakrecoer> i'll try that
[12:58] <sakrecoer> might work with the usb device, but i doubt it will work with the firewire one.
[12:58] <sakrecoer> i'll just use the setting recommended for profession/prosumer audio on that one :D
[13:00] <Eickmeyer> As far as the rationale on switching to Pipewire by default: all the other flavors did it, so we needed to do it for compatibility reasons. Also, if we didn't do it, then we would never do it. Being stuck in the past and not moving forward with technology because "it's always been that way" is no excuse for not doing what needs to be done.
[13:00] <Eickmeyer> Yeah, if you need to use the old Jack/PulseAudio setup, do it. Nothing is stopping you.
[13:01] <sakrecoer> first part makes a lot of sense!
[13:01] <sakrecoer> second part, is your opinion and i respect it. Mine is not the contrary but not the same
[13:01] <Eickmeyer> Even falktx considers Pipewire "Jack3".
[13:02] <sakrecoer> i'm not sure what that is supposed to say to me, but i don't think it makes sense to discuss any further. I understand why you made it default, that's all i was asking for
[13:03] <Eickmeyer> Sounds good.
[13:04] <sakrecoer> thanks for all the hard work, Eickmeyer! i mean it!
[13:04] <sakrecoer> have good friday everyone!
[13:04] <Eickmeyer> You're quite welcome. I guess I just feel attacked sometimes when it comes to that decision. :)
[13:07] <sakrecoer> i appologize if i made you feel attacked. that was not my intention. i do contain a certain degree of frustration in that my rig is suddenly no longer operational. But i don't mean to put that on you.
[13:08] <Eickmeyer> Well, that's why the multiple options exist. I hope that 24.04 has all the kinks worked out.
[13:08] <sakrecoer> or anyone for that matter. all i want is to understand where things are going, and what i can do to mitigate the present and anticipate the future.
[13:08] <Eickmeyer> PipeWire is largely out of my hands since it's in main and that's a core dev access thing.
[13:09] <sakrecoer> i know from history that you will do a great job and i have no doubt about that. It might not pleas me, but that is my problem. not yours <3
[13:10] <sakrecoer> although, i'm pretty sure i will be impressed :)
[13:11] <sakrecoer> anyways, gotta go back to the coal mine. Thank you for the indicators and for your time!
[13:13] <Eickmeyer> See ya! o/
[19:19] <OvenWerks> sakrecoer: pulse/jack is not pro, jack on its own is. Pulse still has (and always will have) issues. PW is where linux is going, either peacefully or kicking and screaming.
[19:22] <OvenWerks> PW is in many ways better than pa/jack already. It handles (un)plugging of devices much better and for anything but FW devices is pretty good. It still respects jackd or Ardour asking for a device.
[19:24] <OvenWerks> PW dev has stated there are plans to allow the use of jackd backends like ffado and intends to use the jackd libjack directly in the future as well.
[19:25] <OvenWerks> Things have moved forward since then as I have been out of things for a while.
[19:27] <OvenWerks> I think the only place it is worth using jackd any more has nothing to do with pulse as PA does not handle low latency very well in my experince. Even if it dose work, it sure uses a lot of dsp/cpu compared to jackd, etc.
[19:29] <OvenWerks> So, if using a computer strictly as an effects box or softsynth (I am "soft" on the softsynth as mostly I can get by with more latency there) I would jackd only. Say with a R-pi for example.