=== Class7_ is now known as Class7
[07:19] <jibel> Good morning
[07:20] <didrocks> salut jibel
[07:21] <jibel> Salut didrocks , ça va?
[07:21] <duflu> Hi jibel + didrocks
[07:22] <jibel> Hi duflu
[07:27] <didrocks> jibel: ça va et toi ?
[07:27] <didrocks> hey duflu
[07:39] <jibel> didrocks, ça va bien
[07:54] <oSoMoN> good morning desktoppers
[07:59] <duflu> Hi oSoMoN
[08:02] <oSoMoN> hey duflu
[09:01] <Laney> yo
[09:02] <seb128> hey Laney
[09:02] <seb128> good morning desktopers
[09:07] <duflu> Hey Laney and seb128
[09:07] <seb128> hey duflu, how is the hacking going today?
[09:08] <duflu> seb128, incredibly frustrating (upstream made a few conflicts for me today) but now very fruitful. How are you?
[09:08] <oSoMoN> good morning Laney, seb128
[09:08] <duflu> Although the frustration also came from community testing discussions
[09:10] <duflu> And it came from knowing I need to finish on time to cook dinner tonight, and will be away tomorrow. Everything is my own making in a way
[09:14] <seb128> lut oSoMoN
[09:15] <seb128> duflu, well, if things get ready friday or next week rather than today it's no big deal, we are early in the cycle and their is no freeze or anything pending, just relax and go cook dinner
[09:21] <Laney> morning seb128 duflu oSoMoN
[09:21] <Laney> whats up
[09:22] <willcooke> morning all
[09:24] <duflu> Hi willcooke
[09:33] <oSoMoN> good morning willcooke
[09:33] <willcooke> oSoMoN, thanks for testing with Sogou, its great to hear it works!
[09:35] <oSoMoN> yeah, I was pleasantly surprised that it didn't require any tweaking
[09:44] <seb128> hey willcooke
[10:03] <seb128> who here has an "airplane mode" key on their laptop keyboard?
[10:05] <willcooke> seb128, I have a "wifi off" button
[10:06] <seb128> willcooke, I'm not sure it's the same? it's to test/debug bug #1740894
[10:06] <ubot5> bug 1740894 in xkeyboard-config (Ubuntu Cosmic) "KEY_RFKILL is not passed to userspace" [Low,Fix committed] https://launchpad.net/bugs/1740894
[10:06] <seb128> the xkeyboard-config SRU makes the key being handled, but apparently then getting out of airplane mode fails
[10:07] <willcooke> if I run xev I should see KEY_RFKILL right?
[10:07] <seb128> though your key might trigger the same mode
[10:08] <willcooke> reading the bug
[10:09] <seb128> willcooke, well, it's easy, it's basically "using the key should toggle airplane mode on/off"
[10:09] <seb128> though the reporter here seems to have an issue where the second use doesn't success to toggle it off
[10:13] <willcooke> my key works fine, so I guess I can't reproduce
[10:25] <seb128> k, might be hardware specific
[10:26] <seb128> willcooke, thx for testing
[10:26] <seb128> Laney, ^ that mentions XPS, maybe you could give it a try see if yours behaves the same way?
[10:32] <Laney> seb128: the rfkill key?
[10:32] <Laney> it works, I use it often
[10:33] <Laney> mainly to toggle NM when it craps itself :-)
[10:35] <Laney> oh yeah, I am on wayland tho
[10:36] <Laney> hello from x
[10:36] <Laney> the key still works, sorry :(
[10:53] <jibel> seb128, what's the naming convention for blueprints?
[10:56] <jibel> seb128, would desktop-dd-<project_name> be fine?
[12:39] <seb128> jibel, yes, that sounds fine as naming
[12:44] <seb128> Laney, weird :/ what keycode does it generate? our xkeyboard-config didn't have the definition of rkfill so it shouldn't be working
[12:45] <seb128> or maybe it's handled at the hardware level ... but g-s-d is supposed to inhibit the kernel handling
[12:47] <Laney> https://paste.ubuntu.com/p/g6T7RNrtDZ/ that's what xev says
[12:53] <seb128> no KeyPress KeyRelease events, weird
[12:54] <Laney> don't get those for other osd keys either
[12:54] <Laney> probably the osd grabs focus
[12:55] <seb128> the debug comments on https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/90 have the events
[12:55] <gitbot> GNOME issue 90 in gnome-settings-daemon "Airplane mode key on Asus ZenBook Flip UX561UD laptop not working in gnome-shell 3.30 (X or Wayland) but working on console. (Ubuntu Cosmic 18.10)" [3. Not Gnome, Closed]
[12:55] <seb128> unsure what's different
[12:55] <Laney> or g-s-d has grabbed the key or something
[12:55] <seb128> I wonder if it means g-s-d is bailing out from inhibiting the kernel handling for you
[12:56] <seb128> and so the key is being handled low level
[12:56] <Laney> would expect to see it for volume up/down no?
[12:56] <seb128> unless it's the same and hardware handled on the xps
[12:56] <seb128> I don't remember exactly how those are working :/
[12:56] <seb128> well, thx for trying :)
[12:57] <Laney> If I map them to another key it still gives me the same events
[12:59] <seb128> I do get a keyrelease event here with the volume
[12:59] <seb128> but no keypress
[12:59] <seb128> weird
[12:59] <seb128> KeyRelease event, serial 38, synthetic NO, window 0x5000001,
[12:59] <seb128>     root 0xf7, subw 0x0, time 23588627, (-28,858), root:(1318,910),
[12:59] <seb128>     state 0x10, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
[12:59] <seb128> that's under and xorg session, not wayland
[12:59] <Laney> i'm on xorg now
[13:00] <seb128> k
[13:00] <seb128> well I don't know enough about that stack to have a guess at the difference between the systems
[13:00] <seb128> the bug is also not that important, I'm just going to put it on the side for now
[13:00] <seb128> thx for poking though!
[13:01] <Laney> I could see if the SRUed package makes it worse for me too
[13:02] <seb128> it would be useful to see if it creates a difference in the xev/g-s-d handling at least
[13:30] <Laney> seems more buggy with respect to coming out of airplane mode now
[13:30] <Laney> also my key sends XF86WLAN now XF86RFKill, that's probably why it worked
[13:30] <Laney> s/now/not/
[13:34] <seb128> ok, so you at least confirm the regression
[13:36] <Laney> seems so :<
[13:36] <seb128> I'm confused though
[13:36] <seb128> the diff is https://launchpadlibrarian.net/394768060/xkeyboard-config_2.23.1-1ubuntu1_2.23.1-1ubuntu1.18.10.1.diff.gz
[13:36] <seb128> it shouldn't impact on your key since the symbol it's using was already define before that change
[13:38] <Laney> all very weird
[13:39] <seb128> yeah, exactly my though :)
[13:39] <seb128> +t
[13:44] <andyrock> Laney: do snaps have access to /run
[13:44] <andyrock> ?
[13:44] <Laney> dunno
[13:46] <andyrock> Laney: otherwise the boot-id seems like a good idea but in the short-term we still that workaround
[13:47] <Laney> good old short-term workarounds :-)
[13:49] <seb128> andyrock, jdstrand probably knows
[13:50] <andyrock> I'll keep that in mind when I'll rewrite the way canonical-livepatch updates the status file (we need that anyway)
[13:50] <seb128> oh I see you asked on #snappy
[13:50] <seb128> probably a better idea :)
[13:50] <andyrock> Laney: I know but we really want that fixed in the short-term :P
[13:51] <jdstrand> andyrock: what in /run do you want access to? (the short answer is that /run is (for the most part) /run from the host, but security policy limit what you can access there)
[13:52] <andyrock> jdstrand: yeah I got  the same answer in #snappy
[13:53] <Laney> andyrock: sure, I didn't try to stop you fixing it
[13:53] <Laney> I was more hinting that I bet this code still exists in 5 years
[13:54] <Laney> it's like the curse you bring down when you call something "short term" :P
[13:58] <andyrock> 😂
[14:03] <andyrock> seb128: Laney: so it looks like that we can use /run/user/0/snap.canonical-livepatch/status
[14:04] <seb128> except the issue Jamie just pointed out :p
[14:04] <andyrock> ah countermand
[14:05] <seb128> well, that's an ongoing discuss/item for this cycle, if you say the status file code needs updating anyway
[14:05] <seb128> meanwhile the update-notifier "temporary" solution will do...
[14:05] <Laney> the lifetime of that directory is not right
[14:05] <andyrock> Laney: is not per boot?
[14:05] <seb128> it's linked to the active session?
[14:05] <Laney> your xdg runtime directory gets removed when your last session ends
[14:06] <seb128> right, well there is no active session atm for those snaps
[14:06] <seb128> which is the issue Jamie was pointing you, /run/user/0 doesn't exist
[14:07] <Laney> ok, but it's not right even if it did
[14:08] <seb128> yeah, it should probably just be a file under /run
[14:09] <Laney> anyway
[14:09] <seb128> yeah
[14:09] <seb128> thx for the input Laney!
[14:09] <Laney> I usually try to propose nicer solutions if I see them
[14:09] <Laney> often they get ignored
[14:09] <Laney> that is life
[14:10] <Laney> ignored / not done
[14:10] <andyrock> can you argue that in #snappy
[14:11] <Laney> is there an argument ongoing?
[14:12] <Laney> if it were me I'd probably file a bug on livepatch asking if they think that is a good idea in the first place, as a first step
[14:13] <Laney> well, assuming there is a bug tracker for that thing :P
[14:17] <seb128> no much "arguing" no, discussing potential ways to provide what is needed
[14:17] <Laney> cool
[14:17] <seb128> but yeah, at this point best in a bug report
[14:17] <seb128> andyrock, let me know the bug number once you have it filed :)
[14:17] <Laney> it's a way to track the issue without having to spend a lot of time on it now or interrupt anyone
[14:18] <Laney> and if you can get it on a backlog, possibly even worked on at some point ;-)
[14:19] <seb128> zyg_a says they could add access to /run/snap.<SNAP_NAME> and maybe to it for the next .1
[14:20] <Laney> that would be nice
[14:20] <Laney> on that note, I have some avocado to eat
[14:20] <Laney> BYE
[14:20] <seb128> s/to it/do it/
[14:20] <seb128> Laney, enjoy!
[14:51] <Laney> big tasty
[14:56] <willcooke> kenvandine, you around for a quick call with diddledan?
[14:56] <kenvandine> sure
[14:56] <kenvandine> 5 minutes?
[15:00] <willcooke> kenvandine, cancel that, thx
[15:00] <kenvandine> willcooke: ok, just give me a shout if you need me
[15:02] <willcooke> thanks kenvandine
[15:43] <CarlenWhite> Huh. Got hit with a nasty lockup and didn't get a kernel panic screen. Picture just stuck and played a bit of sound in repeat.
[16:01] <seb128> Laney, btw https://bugs.launchpad.net/bugs/1802112 if you were interested by the details of that discussion
[16:01] <ubot5> Ubuntu bug 1802112 in snapd "Snaps can't write to /run by default" [Undecided,New]
[16:03] <Laney> nice, that went quite smoothly
[16:23] <Laney> how does XDG_RUNTIME_DIR even work for snaps?
[16:23] <Laney> do they have to make it and set up like the wayland socket and stuff themselves?
[16:25]  * Laney read the launch script, looks like it
[16:29] <Laney> https://forum.snapcraft.io/t/wayland-dconf-and-xdg-runtime-dir/186
[16:29] <Laney> went a bit quiet though
[16:31] <willcooke> wheeeeee: https://imgur.com/a/jbV2eaH
[16:43] <andyrock> 😂
[16:44] <andyrock> willcooke: I can take a look
[16:44] <andyrock> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1797205 do we want this in cosmic?
[16:44] <ubot5> Ubuntu bug 1797205 in gnome-control-center (Ubuntu) "/usr/bin/gnome-control-center:11:g_type_check_instance:g_signal_handlers_block_matched:als_enabled_state_changed:ffi_call_unix64:ffi_call" [High,In progress]
[16:44] <Laney> that one is filed somewhere
[16:44] <Laney> it actually doesn't happen for me any more on cosmic
[16:45] <willcooke> andyrock, not urgent, but I logged a bug anyway: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1802139
[16:45] <ubot5> Ubuntu bug 1802139 in gnome-shell (Ubuntu) "Typing a long password in to the polkit dialog causes the dots to overflow the input field" [Undecided,Confirmed]
[16:46] <Laney> could be 86a520b880808ad18d397ab8e7a7a05b1a8b4e4c
[16:48] <willcooke> yeah, sounds like it could help
[16:48] <willcooke> https://git.launchpad.net/gnome-shell/commit/?id=86a520b880808ad18d397ab8e7a7a05b1a8b4e4c
[16:50] <andyrock> That reminds me that I get a crash when closing that dialog on gnome-shell upstream
[16:53] <Laney> it's ba33a05dd27e1c23bfcfbd4ac06fcb0d6e06ebf4 in the 3.28 branch, queued up for the next stable release
[16:53] <Laney> plenty of fixes in there :/
[16:55] <andyrock> :/ is for the fixes or because it's taking to lot to release the next 3.28.x ?
[16:55] <Laney> fixes are :D
[16:55] <Laney> not having them is :/
[16:56] <Laney> it is UNACCEPTABLE for it to be dark at this time too
[16:57] <andyrock> dsl is :/
[16:57] <andyrock> *dst
[17:02] <willcooke> I concur
[17:05] <seb128> willcooke, bug #1797205 doesn't have many reports so far so need to SRU imho but if we do one for other fixes we can include that one
[17:05] <ubot5> bug 1797205 in gnome-control-center (Ubuntu) "/usr/bin/gnome-control-center:11:g_type_check_instance:g_signal_handlers_block_matched:als_enabled_state_changed:ffi_call_unix64:ffi_call" [High,In progress] https://launchpad.net/bugs/1797205
[17:07] <andyrock> kk
[17:08] <Laney> it's in the branch, will get it naturally if we do the update
[17:09] <Laney> in 3.30.2 even, already out
[17:09] <andyrock> just asking because it has been in the "in review" trello list for too much
[17:10] <andyrock> maybe we need a list "waiting for release"
[17:12] <Laney> you could help it along by preparing the SRU ;-)
[17:15] <andyrock> Laney: sure thing
[17:16] <andyrock> let me prepare a mp to release in D before
[17:16] <Laney> cool
[17:16] <Laney> should be the same except changelog and control probably
[17:17] <andyrock> I'll do debian unstable too
[17:17] <Laney> nice one
[17:17] <Laney> I can review that tomorrow
[17:18]  * Laney uploads more bits to the systemd-user ppa
=== pstolowski is now known as pstolowski|afk
[17:23] <Laney> backporting this stuff to the package is so irritating
[17:23] <Laney> I should be doing it in git, at least then it would remember how to resolve the conflicts
=== chrisccoulson_ is now known as chrisccoulson
[22:17] <oSoMoN> kenvandine, popey: FYI, https://bugzilla.mozilla.org/show_bug.cgi?id=1505593
[22:17] <ubot5> Mozilla bug 1505593 in Untriaged "[snap] Update prompt does nothing" [Normal,Unconfirmed]
[22:18] <kenvandine> oSoMoN: thanks
[22:24]  * oSoMoN is off to bed and to a long week-end, see ya all next week