[02:00] <jamesh> duflu: for that Wayland related bug I was tracking yesterday, setting WAYLAND_DEBUG=1 for the app was helpful: it showed an error from the server that GTK never bothered to print
[02:00] <jamesh> it seems it was a mutter bug after all: https://gitlab.gnome.org/GNOME/mutter/issues/138
[02:00] <gitlab-bot> GNOME bug 138 in mutter "Error 71 (Protocol error) dispatching to Wayland display" (comments: 0) [1. Bug, 5. Wayland, Closed]
[02:04] <duflu> jamesh, good. So at least one of my comments yesterday was right. Fixed in mutter 3.28.2 and 3.29.2, so cosmic is already fixed.
[02:05] <jamesh> I'll have to remember WAYLAND_DEBUG=1 for the future
[02:05] <jamesh> it turns on protocol logging in both libwayland-client and libwayland-server
[02:06] <jamesh> MUTTER_VERBOSE=1 didn't really tell me anything about the wayland protocol side of gnome-shell
[02:08] <duflu> Fortunately I have never needed to discover that option
[02:10] <jamesh> It's just a bit annoying when GTK turns "set_parent_of was called with an invalid child" into "Error 71 (Protocol error) dispatching to Wayland display."
[02:14] <duflu> Yeah that's poor form. "Error 71" is something you should never see. Instead there should be more useful information as to what 71 represents
[02:17] <jamesh> sometimes I wasn't even getting the "Error 71": it looks like sometimes GTK was seeing the socket close before getting the string error message from the server
[02:19] <duflu> jamesh, I guess if you can find the most definite component to blame (objectively) then log a bug
[05:50] <didrocks> good morning
[05:55] <jibel> salut didrocks
[05:56] <jibel> ça va?
[06:00] <didrocks> ça va jibel, et toi ? :)
[06:01] <jibel> didrocks, bien bien, c'est vendredi :)
[06:01] <didrocks> héhé
[06:01] <jamesh> some instructions for testing portals with snaps: https://forum.snapcraft.io/t/desktop-portal-testing-notes-for-app-developers/5711
[06:23] <oSoMoN> good morning desktoppers, and happy Friday!
[06:23] <duflu> Morning didrocks, jibel, oSoMoN
[06:26] <oSoMoN> hey duflu
[06:38] <didrocks> good morning duflu, salut oSoMoN
[06:38] <didrocks> joyeux vendredi !
[06:45] <oSoMoN> salut didrocks
[07:57] <willcooke> morning
[07:59] <didrocks> hey willcooke
[08:03] <duflu> Morning willcooke
[08:03] <jamesh> hi willcooke
[08:04] <duflu> willcooke, as Monday is a holiday I'll decide how I feel about working on the day. It depends on the balance between unresolved domestic tasks and wanting to catch up on unresolved Ubuntu tasks
[08:05] <Laney> oops, I forgot the desktop team due to being pinged
[08:05] <Laney> HI!!!!!!!!!!!!!
[08:06] <didrocks> hey hey Laney :)
[08:06] <duflu> Hi Laney
[08:07] <willcooke> duflu, ack
[08:09] <didrocks> Laney: you forgot the desktop team?
[08:09] <didrocks> how dare you :p
[08:09] <didrocks> Laney: that's not a 9 anymore…
[08:09] <Laney> I was fulfilling my potential elsewhere
[08:10] <didrocks> ;)
[08:10] <didrocks> backup plan, "can plan for the future" :)
[08:10] <didrocks> hum
[08:10] <didrocks> not pot file in g-c-c?
[08:11] <Laney> not pot pot not
[08:11] <didrocks> lalala :)
[08:11] <Laney> didn't get generated in the build?
[08:12] <didrocks> I was looking at the option to not purge :)
[08:12] <didrocks> --git-no-purge running
[08:13] <didrocks> yep, build time
[09:41] <duflu> There is starting to be a backlog: https://gitlab.gnome.org/GNOME/mutter/merge_requests/
[09:41] <duflu> Fortunately I'm about to EOW and need to prepare to cook dinner, so don't mind
[09:57] <duflu> Night
[10:13] <didrocks> willcooke: small question about whoopsie auto/never request integration in gnome-initial-setup… We link the "first status report" with the auto/never errors mode, correct?
[10:14] <didrocks> willcooke: so, if the user say "send system infos", it turns whoopsie in auto send mode, and if the user opt out, it will never send any report? (then, there is the toggle in g-c-c to switch between never/manual/auto)
[10:14] <didrocks> I don't see anything mentionning error reports in the mockup
[10:17] <willcooke> erm
[10:17]  * didrocks sees willcooke thinking
[10:17] <willcooke> you can hears the cogs working
[10:18] <willcooke> I dont think it's supposed to go in g-i-s
[10:18] <willcooke> I think it's suppose to go on the first whoopsie message with a checkbox saying "Don't ask me again" or words to that effect
[10:18] <didrocks> willcooke: hum, not what we discussed last time IIRC
[10:18] <willcooke> I dont think we should tie it in to the "send data"
[10:19] <didrocks> willcooke: so, we would have 2 additional options on the dialog?
[10:19] <willcooke> 1 sec, I think I have an email with designs in it
[10:19] <didrocks> because remember, there are 3 options
[10:19] <didrocks> never show the dialog, nor report
[10:19] <didrocks> always show the dialog
[10:20] <didrocks> always report without asking
[10:21] <willcooke> yeah, so in that case the checkbox on the whoopsie dialog would work, like "Remeber this choice" -> "Yes" = always auto send, "no" -> never send, never prompt  <do nothing> = Always prompt
[10:21] <Laney> Don't ask me again -> Report / Cancel
[10:21] <Laney> ya
[10:22] <didrocks> I guess we should have some better text than Yes/No, but yeah
[10:22] <willcooke> https://wiki.ubuntu.com/ErrorTracker#line-65
[10:22] <willcooke> oh, no that's not quite it
[10:23] <didrocks> yeah, there isn't the option there
[10:23] <willcooke> k, so thinking about what we have
[10:24] <willcooke> we have the toggle between auto always send and off in g-c-c
[10:24] <didrocks> that's already done
[10:24] <didrocks> and uploaded
[10:24] <willcooke> so that's how you can change your mind later
[10:24] <willcooke> so yeah, IMO, adding something to the whoopsie dialog is the right thing
[10:25] <willcooke> didrocks, I can speak to m_pt next on Monday if you can wait
[10:25] <willcooke> s/next/first thing
[10:25] <willcooke> or maybe you can play around with it and we can work out the exact woding later
[10:25] <didrocks> willcooke: sure, there is no hurry
[10:25] <didrocks> willcooke: https://imgur.com/a/7EnRi9a
[10:26] <didrocks> this is what I changed in GCC
[10:26] <willcooke> neat!
[10:26] <didrocks> also, the existing dialog was a lie
[10:26] <willcooke> ha yeah
[10:26] <didrocks> and so, the global label switch between "Never/Manual/Always"
[10:26] <willcooke> I noticed that
[10:26] <willcooke> I kinda hoped it was a bug which crept in which made it always report automatically
[10:26] <didrocks> (ofc, the switch off disable the option box)
[10:26] <willcooke> but alas no
[10:27] <didrocks> the person implementing it didn't look at the API it seems :)
[10:27] <willcooke> heh
[10:27] <didrocks> so yeah, I think something around that in the dialog, without taking too much space
[10:27] <didrocks> knowing that if we see taht dialog, it means we are in "manual" already
[10:28] <didrocks> (so no need to show that option)
[10:28] <willcooke> ah yeah
[10:33] <didrocks> willcooke: btw, we can't know if a crash prevents login
[10:33] <didrocks> willcooke: warning you, as I've seen g-c-c mockups which was relying on that to propose "auto mode" being only allowed in that case
[10:49] <willcooke> didrocks, I dont think I follow - so in cases where you can't login, can we force auto upload?  I guess by time time you can't login, the session has already tried to start  - so we cant have one setting for gdm and one for the desktop session propper?
[10:50] <didrocks> willcooke: no, the setting is global
[10:50] <didrocks> willcooke: I mean, in the original design "auto" was only if you can't log in
[10:51] <didrocks> but it's nor the existing semantic, nor what we want to achieve (prompt less the users)
[10:57] <willcooke> ah, kk
[11:54] <nessita> hello all. I have an old laptop running ubuntu 16.04, and since a few "boots" ago, when I login with my user, it will not display/load the propfile. Restarting lightdm usually fixed it, but the last time I
[11:54] <nessita> I've tried doing that would not fix it
[11:56] <nessita> on one of the attempts to login, I've got an apport dialog saying that "compiz profile loader" had failed, but did not show a traceback
[11:56] <nessita> is there any way I can "fix" that use in that installation?
[12:04] <nessita> I've found a crash file in /var/crash for unity_compiz_config_profile_setter and I've sent it with apport-bug
[12:07] <mgedmin> nessita: you could try logging in using a different session type (e.g. gnome-shell, if you've got it installed)
[12:07] <mgedmin> and then, hm, reset your compiz settings?  IIRC there was a command to do that, let me google ...
[12:08] <mgedmin> hm, unity-tweak-tool --reset-unity ?
[12:09] <nessita> mgedmin, at this time I don't have a different session type, but yeah I was trying to reset the compiz settings, let me try that command
[12:09] <nessita> mgedmin, thanks, it worked!
[12:37] <popey> tseliot: sadly the latest nvidia driver from your ppc didn't fix the crash. Just installed a snap and my xorg exploded again :(
[13:49] <kenvandine> tkamppeter, cups-pk-helper has been accepted in bionic-proposed
[13:49] <kenvandine> tkamppeter, please test it and comment on the bug
[14:01] <tseliot> popey: ok, please try 396 too from this PPA. Failing that, I'll try to reproduce the problem here: https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[14:02] <popey> tseliot: ok, thanks. in parallel jdstrand is providing support from the snapd side, believing he can reduce the triggers that cause it.
[14:07] <tseliot> popey: ok. BTW, I've just had a look at the new stacktraces, and  it looks like the failure takes place in the input pthreads in X11, and there is no sign of things being related to the nvidia driver, other than the nvidia package being installed on your system.
[14:13] <popey> tseliot: ah, that fits with what jdstrand is working on, so thanks! :D
[14:14] <tseliot> popey: you're welcome ;)
[16:14] <oSoMoN> have a great week-end everyone!
[17:08] <Laney> laters!
[17:55] <popey> kenvandine: ..
[17:55] <popey> https://www.irccloud.com/pastebin/af4eotDW/problem%20installing%20gnome-chess
[18:01] <popey> (we were gonna add it to the featured editor's picks, but won't if it's busted)