[05:19] <jibel> morning
[05:20] <jibel> cyphermox, guided
[05:35] <didrocks> good morning!
[05:40] <oSoMoN> good morning desktoppers
[05:47] <didrocks> hey oSoMoN
[05:47] <didrocks> how are you?
[05:58] <oSoMoN> salut didrocks
[05:58] <oSoMoN> I'm good
[05:58] <oSoMoN> you?
[05:59] <didrocks> I'm great! Getting bearable temperatures, finally
[06:06] <oSoMoN> it's rainy here today, dropped from 32°C yesterday to a forecast of 23°C today
[06:09] <seb128> good morning desktopers
[06:09] <seb128> lut oSoMoN didrocks
[06:10] <oSoMoN> salut seb128, ça va?
[06:10] <seb128> lut, nickel, et toi ?
[06:10] <oSoMoN> ça va :)
[07:51] <flexiondotorg> Morning desktopers
[07:52] <flexiondotorg> Or should I say, morning France.
[07:54] <oSoMoN> bonjour flexiondotorg!
[07:54] <oSoMoN> (from Spain)
[07:54] <didrocks> hey flexiondotorg
[07:55] <flexiondotorg> oSoMoN: What part of Spain?
[07:55] <oSoMoN> near Barcelona
[07:56] <flexiondotorg> Catalonia, my favourite part of Spain.
[07:57] <flexiondotorg> Used to live and work in Tossa De Mar.
[07:57] <oSoMoN> cool
[07:58] <oSoMoN> was the company located there, or did you work remotely?
[07:59] <flexiondotorg> I was a chef ☺️
[07:59] <flexiondotorg> My first career.
[07:59] <oSoMoN> oh wow
[08:00] <oSoMoN> flexiondotorg is cooking for us in NYC!
[08:01] <oSoMoN> didrocks, do you happen to have nvidia hw handy? I could use some help in understanding and fixing https://forum.snapcraft.io/t/gl-applications-using-desktop-helpers-dont-work-on-nvidia/1825
[08:01] <flexiondotorg> No one cooks in NYC 😉
[08:01] <didrocks> oSoMoN: no, only Intel here, sorry
[08:01] <didrocks> oSoMoN: my old nvidia laptop is RIP since 2012 :p
[08:01] <flexiondotorg> I have nvidia.
[08:02] <oSoMoN> flexiondotorg, would you have a bit of time to help me debug that issue?
[08:03] <flexiondotorg> I can.
[08:03] <oSoMoN> iirc popey said it's not just the chromium snap, others are affected too
[08:03] <oSoMoN> awesome
[08:03] <Laney> ahoy
[08:03] <flexiondotorg> I have a meeting this morning. Then I can help.
[08:03] <oSoMoN> hey Laney
[08:03] <flexiondotorg> Morning Laney
[08:04] <oSoMoN> flexiondotorg, excellent, in the meantime I’ll try to come up with ideas to give you things to try
[08:04] <flexiondotorg> oSoMoN: I think this issue affects other snaps so I'm keen to figure out the issue.
[08:05] <oSoMoN> I wonder if it's missing pieces (stage packages) inside the snap, or if really the desktop helpers magic is to blame
[08:05] <didrocks> hey Laney
[08:05] <oSoMoN> well I guess if the former then it's also something that can be fixed by the desktop helpers
[08:06] <oSoMoN> it would be interesting to compare that chromium snap to another one that is known to work with hw acceleration on nvidia
[08:06] <oSoMoN> popey, do you know of any snap that works with hw acceleration on nvidia?
[08:07] <oSoMoN> (preferably one that uses the desktop helpers)
[08:08] <didrocks> oSoMoN: chromium isn't a classic snap, correct?
[08:08] <oSoMoN> correct, it's strictly confined
[08:08] <didrocks> ok, not what I thought of (missing export of LD_LIBRARY_PATH as snapcraft doesn't do it for you)
[08:14] <Laney> hey oSoMoN didrocks flexiondotorg
[08:14] <Laney> what up
[08:16] <jibel> didrocks, salut, how do I force a wayland session without the option in gdm?
[08:18] <didrocks> jibel: salut ! Maybe changing the session in account-services? That's the part I'm not terribly familiar with and don't have the time to look at, that's why seb128 asked Robert to have a look at all those session selection bug (I didn't find any code in gdm for this, hence I think it's account-services)
[08:19] <didrocks> Trevinho: apparently, the new indicator extension has some "double click" behavior (to activate some menus), can you look at disabling this or putting an option? It's not really cohesive with the rest of the Shell UI
[08:19] <didrocks> (double-clicking on the dropbox icon to activate it)
[08:19] <jibel> didrocks, I changed the session in /var/lib/AccountsService/<user> and apparently it worked. Thanks
[08:20] <jibel> hmmm, and now gdm proposes a selection of sessions ....
[08:20]  * jibel reinstalls again
[08:20] <Trevinho> didrocks: yeah...
[08:20] <Trevinho> All in my list
[08:21] <didrocks> jibel: there is still the question of selecting a default session
[08:21] <didrocks> (gdm hardcodes "gnome")
[08:31] <jibel> and now I cannot log into X anymore, meh :(
[08:33] <seb128> hey Laney
[08:34] <seb128> jibel, didrocks, I didn't have slots to spend on that gdm/accountsservice issue, is there a bug registered?
[08:34] <seb128> sessions are correctly listed here
[08:38] <jibel> seb128, bug 1712287 and bug 1712504
[08:38] <jibel> seb128, let me do another install with today's iso
[08:38] <jibel> seb128, and now I've a new bug, I'm logged into wayland whichever session I select
[08:39] <jibel> stuck in wayland and cannot use VMs
[08:39] <jibel> ...
[08:41] <seb128> thanks
[08:42] <Laney> hey seb128
[08:42] <jibel> seb128, I'll file another one for the default install, I cannot find it
[08:47] <seb128> thx
[09:02] <jibel> seb128, after an upgrade from Z should I expect ubuntu, ubuntu on xorg and unity? or just ubuntu and ubuntu on xorg?
[09:02] <jibel> in gdm that is
[09:02] <didrocks> IIRC, I wrote that in the trello cards at the time, you should expect the 3 session, with "ubuntu" being the default
[09:04] <jibel> k, found your comment
[09:05] <jibel> didrocks, but it is not clear. THere is "maybe a wayland/Xorg choice, but that's it"
[09:05] <jibel> didrocks, is it still a maybe?
[09:08] <didrocks> jibel: it's not anymore, it should be wayland by default, and xorg as optional
[09:09] <didrocks> (basically it's "default install" + unity on upgrade)
[09:09] <jibel> didrocks, okay, so after an upgrade I'm expecting: "ubuntu", "ubuntu on xorg", "unity" correct?
[09:10] <didrocks> correct
[09:10] <jibel> and "ubuntu" being the default which should start a wayland session
[09:10] <didrocks> exactly
[09:10] <jibel> good
[09:19] <jibel> seb128, bug 1714203
[09:46] <seb128> jibel, thanks
[09:48] <Laney> O_O
[09:48] <Laney> I upgraded to gnome-shell from proposed and ended up in Classic
[09:48] <Laney> probably some session selection thing too
[09:59] <didrocks> for the theme, I'm puzzled about the best strategy
[10:00] <didrocks> I was first doing a lot of sed regexp, but there are a lot of special case, in context (yes, we can do this with more complex regexp expressions)
[10:00] <didrocks> also, the issue with regexp is that if one entry becomes invalidated (because like upstream changed one source color), we won't notice it
[10:00] <didrocks> as "not applying is ok"
[10:00] <ricotz> hey desktopers!
[10:00] <didrocks> the other solution would be to make a python script
[10:01] <didrocks> but meh
[10:01] <ricotz> chrisccoulson, hi, please see PM
[10:01] <didrocks> another one is to make a patch
[10:01] <didrocks> however, new version of the Shell, hard to rebase, hard to look at new entries
[10:01] <didrocks> another idea is just to ship a copy of the theme and rely on a 3 way merge at each Shell update to look at the diff of upstream css
[10:02] <didrocks> any thoughts?
[10:11] <didrocks> jbicha: that concerns you as well I think ^
[10:14] <jbicha> didrocks: you didn't do your theme work last week with GNOME Shell 3.25.90?
[10:14] <didrocks> jbicha: did we have GNOME Shell 3.25.90 in the archive? how could we test it?
[10:15] <Laney> didrocks: can't you make an ubuntu.scss which includes the gnome one and overrides the modified bits?
[10:15] <jbicha> GNOME3 Staging PPA
[10:15] <didrocks> jbicha: as told, if you didn't update it, we had to do with 3.24
[10:15]  * Laney doesn't know much about sass / scss but that sounds more maintainable than sedding or patching (patching the output at least)
[10:15] <didrocks> jbicha: but no, and not really the current topic (as the css diff is minimal anyway)
[10:15] <jbicha> didrocks: I mean I could have crammed it into artful-proposed but it wasn't going to go to artful until gjs/armhf was fixed
[10:15] <didrocks> Laney: not really possible, most of the colors are hardcoded and not in sass
[10:16] <Laney> where do they come from?
[10:16] <jbicha> it just seems like you made more work for yourself…
[10:16] <didrocks> Laney: I meant, they are not "in context", like it's not just replace all colors from X to Y
[10:16] <didrocks> or we need to remove some stenzas as well
[10:16] <didrocks> jbicha: rebasing again is easy
[10:16] <didrocks> the question is: how do we make that maintainable?
[10:17] <didrocks> (which was why I wanted to raise this here ^)
[10:18] <didrocks> I think a separate css file is maybe the best approach first, rather than patch/sedding and doing a 3-way merge on shell update?
[10:18] <didrocks> then, if it's not sustainable, we can revisit (I hope to make the Shell more customizable upstream in the meantime)
[10:18] <jbicha> GNOME Classic uses a separate css file and it sounds like it's easy for us to make more changes that way
[10:18] <jbicha> of course, we might not want *too* many changes :/
[10:19] <didrocks> yeah, it just asks when we do update to download the old css to compare the changes
[10:19] <didrocks> which, I think, is fine for a first approach
[10:19] <didrocks> jbicha: the main issue is that a lot of colors are "blue grey" and it's a mismatch
[10:19] <didrocks> we need "orange grey"
[10:19] <didrocks> so, same changes on multiple colors all over the place
[10:21] <Laney> show what you've got maybe?
[10:21] <didrocks> you want the diff against 3.24?
[10:21] <didrocks> http://paste.ubuntu.com/25437780/
[10:21] <didrocks> here you go ^
[10:23] <Laney> k, and where do those values come from?
[10:23] <didrocks> ? the hackfest ?
[10:23] <Laney> you made them up?
[10:23] <didrocks> some from unity
[10:23] <Laney> or they are the output of some algorithm or?
[10:23] <didrocks> some from our ubuntu keys
[10:23] <didrocks> some, we had to made them up, in the hackfest
[10:24] <roger-roger> hi, qq... running 17.10, fully up to date, using ubuntu session, used to have 'dash to dock' extension which i've uninstalled and can't get the new ubuntu dock to show - in https://extensions.gnome.org/local/ it says "ERROR" against ubuntu dock - can anyone please point me to how/where can i find logs to find what's going on so i can submit a bug report?
[10:25] <didrocks> roger-roger: "journactl /usr/bin/gnome-shell" should have this output
[10:25] <didrocks> Laney: how does it impact the diff?
[10:25] <jbicha> roger-roger: one way is to run
[10:25] <jbicha>  gsettings get org.gnome.shell enabled-extensions
[10:25] <jbicha> then
[10:25] <jbicha> gsettings reset org.gnome.shell enabled-extensions
[10:25] <jbicha> and go back and enable the extensions you want after that
[10:26] <jbicha> but please file a bug report too
[10:27] <roger-roger> ok found it - "Extension "ubuntu-dock@ubuntu.com" had error: TypeError: dockManager is undefined"
[10:27] <didrocks> interesting
[10:27] <roger-roger> if i submit bug report, any other useful bits to include other than the gsettings get and journalctl output?
[10:27] <didrocks> just put that in ^
[10:28] <didrocks> that should  be enough
[10:28] <roger-roger> ok cool, thanks
[10:28] <Laney> didrocks: what I'm getting at is that these are generated files from upstream, and in particular the colours you're replacing are generated using functions
[10:28] <Laney> I think any approach that is working on the generated code is going to be difficult
[10:29] <didrocks> Laney: indeed, but look at the diff again
[10:29] <didrocks> Laney: it's not a one to one mapping
[10:29] <didrocks> some values are different in context
[10:29] <didrocks> (and that's because they actually corresponds to other pieces of UIs)
[10:29] <didrocks> where one value in the upstream theme makes sense, less in other case
[10:30] <didrocks> same for instance in the border removals
[10:30] <Laney> so the upstream in those cases could define a new variable but give it the same content
[10:30] <didrocks> exactly
[10:30] <Laney> and ubuntu.scss would give it different content
[10:30] <didrocks> and that's what we want to do for next cycle
[10:30] <didrocks> get it better themeable
[10:30] <didrocks> upstream
[10:30] <Laney> I thought that's what you were asking about now
[10:31] <didrocks> no, right now, I'm trying to figure out what would work for you guys for this cycle
[10:31] <didrocks> as the maintaince burden will be for everyone updating G-S (hopefully, we won't have huge css change thus)
[10:31] <didrocks> that's why I'm about shipping a css file as they do for GNOME classic
[10:32] <Laney> ok then, I understood 'strategy' to mean a long term thing
[10:32] <didrocks> and have the maintainer updating doing a 3 way merge
[10:32] <Laney> W 65
[10:32] <Laney> oops
[10:32] <didrocks> 65 buffers? crazy ;)
[10:32] <Laney> this is a low day
[10:33] <jbicha> didrocks: for this cycle, GNOME Shell is supposed to be at UI Freeze with Hard Code Freeze on Monday…
[10:33] <didrocks> yeah, we will supposively have the transparency change
[10:33] <didrocks> but apart from that, I think it's safe to ship the css
[10:34] <didrocks> just to whoever update it, remember to at least diff old gnome-shell.css to new one
[10:34] <didrocks> I guess it's the sanest for now
[10:35] <Laney> right, I don't envisage big reworking for 3.26 at this point
[10:35] <Laney> just checking it should be ok
[10:35] <didrocks> let's do this
[10:35] <didrocks> need to update to g-s 3.25.9x first
[10:36] <didrocks> but mutter doesn't want to… hum, /me looks
[10:38] <jbicha> didrocks: oh, it's silly Debian-packaged gnome-shell extensions with a max gnome-shell version, I'll do some uploads for it
[10:38] <didrocks> jbicha: yeah, saw that, thanks! :)
[10:38] <roger-roger> ubuntu dock bug report --> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1714219
[10:39] <didrocks> thanks roger-roger! Unsure yet how this code is triggered, mind retargetting it to gnome-shell-extension-ubuntu-dock?
[10:39] <didrocks> (I bet it's a null vs undefined thingy)
[10:40] <amano> jbicha, will gnome-games-app stay on 3.24?
[10:40] <roger-roger> sure
[10:40] <jbicha> amano: probably not, but I didn't want to do 2 retro-gtk library transitions
[10:41] <didrocks> are we sure the top transparency is going to be reverted btw?
[10:41] <didrocks> I wonder if I shouldn't let the top bar transparent for now and apply our change to maximized one
[10:41] <didrocks> and then we'll revisit
[10:42] <amano> 2 retro-gtk transitions? What is the other one?
[10:44] <jbicha> amano: one for 0.11 and one for 0.12 and https://bugzilla.gnome.org/785307
[10:45] <jbicha> upstream library handling is odd
[10:45] <amano> Ah ok, now i get it ;) thanks, Jeremy!!
[10:45] <jbicha> it's a library with only one user so upstream can get away with it I guess
[10:51] <amano> Timi Aaltonen just landed the xdiagnose fixes (moved the apport hooks to x).
[10:57] <amano> Typo: Timi --> Timo
[11:41] <flexiondotorg> oSoMoN: Will 17.10 do for testing snap with nvidia?
[11:51] <oSoMoN> flexiondotorg, I think so
[11:53] <flexiondotorg> Ok. I'll get everything setup.
[11:54] <oSoMoN> cheers
[11:58] <seb128> jibel, I just did a daily artful/amd64 install and I can't confirm your bug, the cog lists ubuntu/ubuntu on xorg with ubuntu selected and login gives me a wayland session by default
[12:00] <jibel> seb128, in a VM or hardware?
[12:01] <seb128> jibel, VM
[12:01] <seb128> using virtualbox, unsure if that makes a difference
[12:01] <jibel> seb128, i'm finishing an upgrade from gnome 17.04 to 17.10 and will go back to this bug
[12:01] <seb128> why, are you issue specific to VM and some configs?
[12:01] <jibel> seb128, I'm on qemu
[12:01] <seb128> k
[12:01] <seb128> so maybe gdm decides your config can't do wayland
[12:01] <jibel> seb128, yeah sometimes, graphics driver mainly
[12:01] <seb128> which is why it defaults to xorg and doesn't list your several sessions
[12:02] <jibel> seb128, right, i'd like to test with another driver
[12:02] <seb128> in which case NOTABUG?
[12:06] <oSoMoN> flexiondotorg, according to https://uappexplorer.com/snap/ubuntu/krita, « due to a bug in Ubuntu, this snap doesn't work with proprietary video drivers, e.g. for NVidia », do you know if there are details on that "bug in Ubuntu", could it be the same issue?
[12:08] <flexiondotorg> oSoMoN: Could be the same issue.
[12:09] <didrocks> oh, the close button changed to be all blue
[12:09] <flexiondotorg> oSoMoN: So running a Razer Core with nvidia 1080Ti and nouveau drivers.
[12:09] <seb128> didrocks, ^ btw for the sessions
[12:09] <flexiondotorg> Chromium snap works but these denials are encountered
[12:09] <flexiondotorg> http://paste.ubuntu.com/25438140/
[12:10] <didrocks> seb128: yeah, I think what you tell makes sense. I thought jibel was using kvm (gnome-boxes uses kvm and so wayland is available)
[12:10] <oSoMoN> flexiondotorg, and are you getting actual hw acceleration?
[12:10] <didrocks> seb128: well, at least on the "no wayland session one", there is still wrong session randomly selected + no default session set
[12:10] <flexiondotorg> oSoMoN: Is there an acid test for that?
[12:11] <seb128> didrocks, I think the "wrong session" bugs are when session files change on disk and gdm isn't restarted
[12:11] <seb128> the index gets out of sync with the ondisk files
[12:11] <jbicha> didrocks: do you think you'll be able to work on updating your Dock patch for g-c-c 3.26 this week?
[12:12] <oSoMoN> flexiondotorg, just browse to chrome://gpu
[12:12] <jbicha> packaging is at https://code.launchpad.net/~ubuntu-desktop/gnome-control-center/326
[12:13] <didrocks> seb128: hum, could be
[12:13] <flexiondotorg> oSoMoN: http://paste.ubuntu.com/25438158/
[12:13] <didrocks> jbicha: not this week, want to tackle that next one
[12:13] <jbicha> otherwise, does it make sense to update to g-c-c 3.25.91 with that patch temporarily disabled?
[12:13] <seb128> didrocks, and there is a default session set here afaik (there is a dot in the cog list next to the ubuntu one)
[12:13] <didrocks> seb128: yeah, but are we sure it's selecting it reliably? I think it's just taking the first good wayland session
[12:14] <jbicha> didrocks: it feels like you have a better sense of the code since you just wrote it recently ;)
[12:14] <flexiondotorg> oSoMoN: I'm guessing anything that is software i because nouveau doesn't support it yet.
[12:14] <seb128> didrocks, jbicha, I wanted to have a look at updating that patch but I keep getting interrupted by other things landing on my plates, maybe tomorrow ... and -1 on landing the update without those settings
[12:14] <jbicha> ok
[12:14] <didrocks> jbicha: the "want to tackle" was "I want to tackle" ;)
[12:14] <didrocks> yeah, -1 landing without it
[12:14] <didrocks> is the network panel all done now?
[12:15] <didrocks> I remember you told it needed some updates as well
[12:15] <seb128> didrocks, anyway, I'm going to test a bit more but it's not as buggy as those reports were suggesting, they are just mostly consequence of wayland not working under qemu it seems
[12:15] <jbicha> our proxy patch is broken too
[12:15] <didrocks> seb128: let's cross fingers that's the case :)
[12:15] <seb128> that one is probably less important
[12:15] <jbicha> but in good news, Captive Portal fully landed yesterday
[12:15] <seb128> :-)
[12:15] <seb128> well done on that
[12:15] <didrocks> are we going to drop the proxy one if we have the other one updated?
[12:16] <didrocks> also, do you know where the toggles are in the Shell UI?
[12:16] <didrocks> I bet it was on the accessibility panel or something like that
[12:16] <jbicha> and GNOME Shell is landing now… :)
[12:17] <didrocks> not sure what the condition to display it though
[12:17] <flexiondotorg> oSoMoN: Shall I move on a test the proprietary drivers?
[12:17]  * didrocks sees some upstream icon changes to blue, need to test to confirm first
[12:17] <didrocks> ah, settings in g-c-c
[12:17] <seb128> yes
[12:17] <didrocks> ok, I need to change those as well
[12:18] <didrocks> maybe can be done at build time
[12:18] <didrocks> and refers to those
[12:18] <didrocks> also, if I can fix at the same time the 0.2s showing up (before the Shell zoom) of the grey background
[12:22] <didrocks> high contrast will default to adwaita + upstream G-S high contrast theme, sounds ok?
[12:24] <seb128> didrocks, wfm, we never did work to have an ambiance based high contrast anyway
[12:25] <didrocks> yeah, so, let's do that (I see it needs to be <mod-name>-high-contrast.css)
[12:25] <jbicha> High Contrast looks nice in GNOME :)
[12:25] <didrocks> I'll just copy upstream one at build-time
[12:26] <didrocks> and it defaults to adwaita
[12:26] <didrocks> hum, that one will be a little bit more annoying:
[12:26] <didrocks>         let file = Gio.File.new_for_uri('resource:///org/gnome/shell/theme/noise-texture.png');
[12:26] <didrocks> (hardcoded in some js)
[12:26] <didrocks> will see what I can do with it :p
[12:39] <alexarnaud> Hello all :) !
[12:40] <flexiondotorg> alexarnaud: o/
[12:41] <alexarnaud> jbicha: FYI, due to bug 1704847 it's no longer possible to use Orca on Ubuntu.
[12:41] <alexarnaud> I've detailed why on this comment : https://bugs.launchpad.net/ubuntu/+source/gnome-orca/+bug/1704847/comments/9
[12:41] <alexarnaud> flexiondotorg: how are you?
[12:42] <flexiondotorg> alexarnaud: Good thanks.
[12:42] <oSoMoN> flexiondotorg, please do (sorry I had to pop out for a moment)
[12:42] <oSoMoN> the output of chrome://gpu with nouveau looks correct
[12:43] <flexiondotorg> oSoMoN: OK.
[12:43] <jibel> didrocks, for ubuntu gnome, after upgrade, in gdm, I should have entries for ubuntu and gnome and users should be migrated to the ubuntu session by default according to your comment?
[12:44] <flexiondotorg> alexarnaud: That is useful feedback about Orca.
[12:45] <jbicha> alexarnaud: orca works here…
[12:46] <alexarnaud> jbicha: remove the folder ".local/share/orca" if you've it.
[12:46] <alexarnaud> ~/.local/share/orca/
[12:47] <alexarnaud> I explain why the issue appears on my comment and the log provided by another person is explicit. Orca search for a GSettings backend that it doesn't find.
[12:48] <jbicha> ok
[12:48] <didrocks> jibel: no, right now, the expected behavior is them to stay on the gnome session
[12:48] <alexarnaud> jbicha: Let me know if I could help :).
[12:48] <didrocks> if the ubuntu gnome team wants to do otherwise, they will be migrated, but codes need to be written
[12:52] <jibel> didrocks, understood, so your comment about g-session to u-session means IF we want to do that THEN we need to write a patch ?
[12:54] <didrocks> jibel: indeed, and I think that's up to the ubuntu GNOME team to decide that (I strongly think that people using Ubuntu GNOME in the past should stay on the vanilla session, which is the current state)
[12:56] <jibel> didrocks, okay got it. Just wanted to be sure what the test cases should be.
[12:56] <jibel> thanks
[12:57] <didrocks> yw!
[13:01] <ogra_> oSoMoN, just for an extra datapoint http://paste.ubuntu.com/25438360/
[13:01] <ogra_> (krita)
[13:02] <ogra_> (starts and runs fine here it seems)
[13:05] <ogra_> (chromium (beta) still just gives a black window here)
[13:06] <oSoMoN> ogra_, nouveau or proprietary nvidia driver?
[13:06] <ogra_> proprietary
[13:07] <ogra_> aha
[13:07] <ogra_> [1565116.357216] audit: type=1400 audit(1504184681.478:68574783): apparmor="DENIED" operation="open" profile="snap.chromium.chromium" name="/etc/chromium-browser/policies/managed/" pid=17669 comm="chromium-browse" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[13:07] <ogra_> and
[13:07] <ogra_> [1565118.178999] audit: type=1326 audit(1504184683.302:68574789): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=17907 comm="SGI_video_sync" exe="/snap/chromium/13/usr/lib/chromium-browser/chromium-browser" sig=31 arch=c000003e syscall=133 compat=0 ip=0x7f4f0f6bfcad code=0x0
[13:08] <ogra_> thats the syscall for mknod
[13:08]  * ogra_ tires devmode 
[13:08] <ogra_> *tries
[13:10] <didrocks> jbicha: did you need any hint to make g-s transition or all tests passed flawlessly?
[13:10] <didrocks> (to know what to expect on my future uploads ;))
[13:10] <ogra_> oSoMoN, works fine with devmode ...
[13:12] <jdstrand> ogra_: note that the mknod should be fixed with newer snapd
[13:12] <ogra_> oSoMoN, http://paste.ubuntu.com/25438398/ the "ALLOWED" output from a --devmode run
[13:13] <ogra_> "/etc/chromium-browser/" does definitely smell wrong
[13:14] <oSoMoN> oh, indeed
[13:14] <oSoMoN> although if that works confined under nouveau, that one shouldn't be the actual problem
[13:15] <ogra_> yeah, it hangs at the mknod without --devmode ... the /etc issues are befoere that
[13:16] <ogra_> jdstrand, how new? i run core from edge here
[13:16] <ogra_> snap    2.27.5+git352.186fdc0~ubuntu16.04.1
[13:16] <ogra_> snapd   2.27.5+git352.186fdc0~ubuntu16.04.1
[13:16] <ogra_> (this mornings build from master)
[13:22] <oSoMoN> ogra_, thanks for pointing out the denials on /etc/chromium-browser, I filed bug #1714244 to track theme
[13:22] <oSoMoN> s/theme/them/
[13:23]  * ogra_ me too's
[13:26] <oSoMoN> ogra_, would you mind running chromium from the snap under strace to get more info on that mknod call that fails?
[13:27] <ogra_> oSoMoN, well, jdstrand indicated it is a snapd thing and fixed in new versions
[13:28] <oSoMoN> yes, but your earlier comment seems to indicate it's not really fixed yet
[13:28] <jdstrand> ogra_: that should be new enough
[13:28] <jdstrand> ogra_: grep mknod /vaar/lib/snapd/seccomp/bpf/snap.chromium.chromium.src
[13:29] <ogra_> i guess i need to ln -s /vaar /var first :P
[13:30] <ogra_> mknod - |S_IFREG -
[13:30] <ogra_> mknodat - - |S_IFREG -
[13:30] <ogra_> mknod - |S_IFIFO -
[13:30] <ogra_> mknodat - - |S_IFIFO -
[13:30] <ogra_> mknod - |S_IFSOCK -
[13:30] <ogra_> mknodat - - |S_IFSOCK -
[13:30] <jdstrand> heh
[13:30] <oSoMoN> http://paste.ubuntu.com/25438475/ here
[13:30] <jdstrand> yeah, so unless chromium is trying to create a char or block device, it should be fine
[13:30] <ogra_> oSoMoN, apt versions are meaningless use "snap version"
[13:30] <oSoMoN> $ snap version
[13:30] <oSoMoN> snap    2.27.5+17.10
[13:30] <oSoMoN> snapd   2.27.5+17.10
[13:30] <oSoMoN> series  16
[13:30] <oSoMoN> ubuntu  17.10
[13:31] <oSoMoN> kernel  4.12.0-11-generic
[13:31] <flexiondotorg> oSoMoN: I've hit a road block. My nvidia GPU is external, Thunderbolt 3. Prime support is broken in 17.10.
[13:31] <jdstrand> ogra_: do you have /var/lib/snapd/seccomp/profiles/snap.chromium.chromium?
[13:31] <flexiondotorg> I'll have to install 16.04...
[13:31] <popey> @flexiondotorg i can test here
[13:31] <popey> i am on 16.04 and nvidia onboard
[13:32] <ogra_> jdstrand, not atm, but i'm running in devmode
[13:32] <jdstrand> ogra_: that is the old seccomp profile, if you don't have it, that's fine
[13:32] <ogra_> k
[13:33] <jdstrand> if someone is going to strace, strace in devmode mode cause you won't see the call in strict since it is killed before it can be traced
[13:33] <jdstrand> ogra_: it is also possible that your .src file didn't have the updates, but when you went into devmode, the policy was regenerated to have it
[13:34] <jdstrand> ogra_: in other words, if you go back to strict, what happens?
[13:36] <oSoMoN> flexiondotorg, thanks, I think we’re covered with ogra_ and popey already testing
[13:41] <ogra_> jdstrand, http://paste.ubuntu.com/25438535/
[13:41] <ogra_> and a blackish window
[13:42] <ogra_> (funnily you can actually interact with the app menu in the window frame ... despite being blacked out)
[13:43] <oSoMoN> I wonder if that mknod call that fails could be https://cs.chromium.org/chromium/src/third_party/libdrm/src/xf86drm.c?q=mknod&sq=package:chromium&l=362&dr=C
[13:44] <ogra_> S_IFCHR ... hmm
[13:46] <oSoMoN> ogra_, mind giving a go at strace?
[13:47] <ogra_> well, /var/lib/snapd/seccomp/bpf/snap.chromium.chromium.src doesnt list S_IFCHR
[13:47] <ogra_> jdstrand, how would i add that ? ^^^^
[13:48] <Laney> waaaaah
[13:48] <Laney> I should rebind printscreen (if that's possible)
[13:48]  * Laney hits it by mistake many times a day
[13:48] <Laney> then I have to go in and delete the image since it just saves them directly
[13:53] <jdstrand> ogra_: so add it to the file like the others, then do: sudo /usr/lib/snapd/snap-seccommp compile /var/lib/snapd/seccomp/bpf/snap.chromium.chromium /var/lib/snapd/seccomp/bpf/snap.chromium.chromium.bin
[13:54] <jdstrand> however, it shouldn't be trying to do that since it shouldn't have the permissions to do that
[13:54] <jdstrand> oSoMoN: ^
[13:55] <jdstrand> oSoMoN: I suspect the real prolem is that the char device it wants isn't there (or otherwise accessible)
[13:55] <ogra_> hmm, i have no snapd-seccomp
[13:56] <oSoMoN> jdstrand, yes, so we need to figure out which device it wants, and understand why it's not ther
[13:56] <oSoMoN> there
[13:56] <jdstrand> ogra_: snap-seccomp
[13:56] <jdstrand> sorry
[13:56] <jdstrand> oh, I typed it right :)
[13:56] <ogra_> yeah, i mistyped it here
[13:57] <jdstrand> ogra_: oh, but I missed typed the first file
[13:57] <jdstrand> ogra_: it should have .src at the end
[13:57] <jdstrand> ogra_: basically, snap-seccomp compile <infile> <outfile>
[13:57] <ogra_> ogra@anubis:~/datengrab/test$ ls /usr/lib/snapd/snap*
[13:57] <ogra_> /usr/lib/snapd/snap-confine  /usr/lib/snapd/snapd  /usr/lib/snapd/snap-discard-ns  /usr/lib/snapd/snap-exec  /usr/lib/snapd/snap-update-ns
[13:57] <ogra_> no seccomp ...
[13:58] <jdstrand> ogra_: I guess you are in reexec territory here
[13:58] <ogra_> most likelyx my debian package is old
[13:58] <ogra_> yeah
[13:58] <jdstrand> ogra_: look in /snap/core/current/usr/lib/snapd
[13:59] <ogra_> yep, thjat works
[13:59] <ogra_> and chromium starts immediately
[13:59] <oSoMoN> cool, we're making progress!
[14:01] <jdstrand> oSoMoN: it is technically possible to add the access to the browser-support interface when allow-sandbox is true, but I'd like to understand what is going on before considering that
[14:01] <oSoMoN> jdstrand, absolutely agreed, let's get to the bottom of this before punching more holes
[14:01] <ogra_> well, it looks like it searches /dev/dri https://cs.chromium.org/chromium/src/third_party/libdrm/src/xf86drm.c?q=mknod&sq=package:chromium&dr=C&l=349
[14:02] <ogra_> #define DRM_DIR_NAME  "/dev/dri"
[14:02] <ogra_> #define DRM_DEV_NAME  "%s/card%d"
[14:02] <ogra_> (in xf86drm.h)
[14:03] <oSoMoN> ogra_, the denial might come from a different place though, that was just a wild guess from searching through chromium's code base
[14:10] <oSoMoN> popey, are you seeing the same seccomp denial on mknod with the chromium snap?
[14:10] <popey> @oSoMoN which snap specifically?
[14:11] <ogra_> popey, chroimium
[14:11] <ogra_>  audit: type=1326 audit(1504186791.952:68574841): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=23052 comm="SGI_video_sync" exe="/snap/chromium/13/usr/lib/chromium-browser/chromium-browser" sig=31 arch=c000003e syscall=133 compat=0 ip=0x7f49dd998cad code=0x0
[14:11] <ogra_> Download as text
[14:11] <ogra_> heh
[14:11] <ogra_> ignore the download hint :)
[14:11] <popey> http://paste.ubuntu.com/25438661/
[14:11] <popey> thats what I got when i ran snap run chromium
[14:12] <ogra_> yep 4th line
[14:12] <popey> so yes oSoMoN :)
[14:12] <ogra_> but yours starts ?
[14:12] <popey> define "starts"
[14:13] <ogra_> dunno, mine stops any DENIALS after that one ...
[14:13] <ogra_> you seem to get more
[14:13] <popey> i get a window appear which is not rendered correctly - an empty window, which goes grey immediately
[14:13] <ogra_> jdstrand, oSoMoN i wonder if this is related https://github.com/snapcore/snapd/pull/3833/files
[14:13] <ogra_> popey, ah, same as me then
[14:14] <oSoMoN> ogra_, that might be indeed
[14:14] <jdstrand> oh, good find
[14:14] <ogra_> well, it landed while we talked :)
[14:15] <oSoMoN> let's ask zyga
[14:15] <oSoMoN> he commented on the PR that "this is only affecting master, 2.27 is correct"
[14:16] <jdstrand> oSoMoN: but ogra_ has edge
[14:16] <ogra_> yeah
[14:16] <ogra_> and i cant switch because of a bug :/
[14:16] <oSoMoN> popey, what version of snapd are you running?
[14:16] <jdstrand> ogra_: you can modify /etc/udev/rules.d for that
[14:16] <popey> @oSoMoN 2.26.14
[14:16] <ogra_> - Run refresh hook of "core" snap if present (internal error: no registered handlers for hook "refresh")
[14:16] <ogra_> ogra@anubis:~/datengrab/test$
[14:16] <ogra_> *sniff*
[14:17] <ogra_> jdstrand, outside of core ?
[14:17] <jdstrand> ogra_: yeah. there are files in there that snapd creates
[14:17] <jdstrand> ogra_: just like the apparmor and seccomp policy
[14:17] <jdstrand> ogra_: there will be one for chromium in there
[14:18] <jdstrand> ogra_: modify it and then do 'sudo udevadm trigger'
[14:18] <jdstrand> (udevadm may not strictly be needed)
[14:19] <jdstrand> for context, if the opengl udev rule is wrong, the device won't be in the device cgroup
[14:19] <ogra_> hmm, nope
[14:19] <ogra_> ogra@anubis:~/datengrab/test$ sudo vi /etc/udev/rules.d/
[14:19] <ogra_> 51-android.rules         70-persistent-cd.rules   70-persistent-net.rules  70-snap.core.rules
[14:20] <jdstrand> that is curious
[14:20] <jdstrand> ogra_: is opengl interface connected?
[14:20] <ogra_> yeah, and i have snaps using it actuively
[14:21] <oSoMoN> popey, any chance you can try 2.27 ?
[14:21] <popey> sure, how?
[14:21] <oSoMoN> it's in -proposed
[14:21] <popey> xenial-proposed?
[14:22] <oSoMoN> [all supported releases]-proposed, apparently
[14:22] <jdstrand> I wonder if reexec is causing trouble
[14:22] <popey> hm
[14:22] <popey> ok
[14:23] <oSoMoN> popey, and before you do that , can you try snap run --shell chromium, and see if you can see /dev/dri/card0 ?
[14:23] <popey> alan@hal:/home/alan$ ls -l /dev/dri/card0
[14:23] <popey> crw-rw----+ 1 root video 226, 0 Aug 26 10:47 /dev/dri/card0
[14:24] <jdstrand> ogra_: if you 'snap run --shell chromium.chromium' what is in /dev?
[14:24] <oSoMoN> ok, let's see if 2.27 makes things better
[14:24] <jdstrand> ah
[14:24] <popey> ok
[14:24] <jdstrand> ok, oSoMoN is doing the same as me
[14:24]  * jdstrand stops
[14:24] <oSoMoN> :)
[14:25] <ogra_> ogra@anubis:/home/ogra/datengrab/test$ ls -ld /dev/dri/*
[14:25] <ogra_> crw-rw----+ 1 root video 226,   0 Aug 31 15:38 /dev/dri/card0
[14:25] <ogra_> crw-rw----+ 1 root video 226, 128 Aug 31 15:38 /dev/dri/renderD128
[14:25] <ogra_> looks all correct
[14:28] <popey> oSoMoN: i have no difference in experience on 2.27.5
[14:29] <oSoMoN> popey, mind using strace on chromium to get more insight on that mknod call ?
[14:29] <popey> got a specific strace command line I need to run
[14:29] <popey> ?
[14:30] <oSoMoN> I successfully used https://forum.snapcraft.io/t/stracing-snap-commands/1433 the other day on libreoffice
[14:30] <oSoMoN> try: sudo strace -u $USER -f -D -vv  /snap/bin/chromium
[14:31] <popey> ok
[14:33] <oSoMoN> jdstrand said earlier: "if someone is going to strace, strace in devmode mode cause you won't see the call in strict since it is killed before it can be traced"
[14:34] <popey> ok
[14:34] <popey> doing both
[14:34] <oSoMoN> ah, you might need to pass those additional params to strace: -e '!select,_newselect,clock_gettime'
[14:36] <jdstrand> yes, please see https://forum.snapcraft.io/t/stracing-snap-commands/1433
[14:36] <jdstrand> man oSoMoN is ahead of me on everything
[14:36] <jdstrand> I shouldn't be in 3 conversations at once
[14:36] <ogra_> well
[14:37] <ogra_> 3 conversations are fine, just dont spread them across 3 channels :)
[14:39] <jdstrand> that's the problem indeed :)
[14:59] <popey> oSoMoN: http://paste.ubuntu.com/25438868/ - chromium devmode trace
[15:06] <didrocks> jbicha: how much did you test g-s 3.25.91? I see a lot of issues in both gdm/session startup at user login (with multiple users)
[15:06] <didrocks> not sure if you saw that
[15:07] <didrocks> like current users being logged out
[15:07] <didrocks> when you switch to another one
[15:09] <ogra_> popey, i think you rather want that in strict mode to see the line where it hangs
[15:10] <popey> i have a trace in non-devmode
[15:14] <popey> but you guys said do it in devmode, so, what do you need from me?
[15:16] <oSoMoN> popey, what does the trace look like with strict confinement?
[15:17] <popey> big, so uploading to people.c.c
[15:20] <popey> oSoMoN: http://people.canonical.com/~alan/chrommium.trace
[15:22] <oSoMoN> popey, thanks!
[15:22] <oSoMoN> 32547 stat("/dev/nvidia0", 0x7fd7ffffdb10) = -1 EPERM (Operation not permitted)
[15:22] <oSoMoN> 32547 mknod("/dev/nvidia0", S_IFCHR|0666, makedev(195, 0) <unfinished ...>
[15:22] <oSoMoN> that looks like it might be our problem
[15:22] <popey> Yay
[15:22] <popey> (I think)
[15:26] <didrocks> jbicha: confirming that any user switching makes the shell crashing
[15:27] <didrocks> both gdm screen and the user's session one
[15:28] <oSoMoN> popey, can you see /dev/nvidia* nodes inside snap run --shell chromium?
[15:28] <popey> in devmode or not?
[15:29] <didrocks> bah, gcc-7 preventing me to report the bug
[15:29] <oSoMoN> popey, in strict mode
[15:29] <doko> didrocks: I thought reportbug was implemented in python3 ;p
[15:30] <didrocks> doko: I meant, the message "please check your deps because you don't know what you do" kind of prevention ;)
[15:31] <popey> oSoMoN: I can see it, yes
[15:31] <oSoMoN> popey, what are the permissions on it/them?
[15:31] <popey> http://paste.ubuntu.com/25438987/
[15:35] <oSoMoN> popey, and /dev/nvidiactl ?
[15:35] <popey> alan@hal:/home/alan$ ls -l /dev/nvidiactl
[15:35] <popey> crw-rw-rw- 1 root root 195, 255 Aug 26 10:47 /dev/nvidiactl
[15:36] <oSoMoN> mmm, I wonder why it's trying to mknod it if it already exists and is readable
[15:40] <oSoMoN> jdstrand, any idea why the snap fails to access /dev/nvidia0 and thus tries to mknod it?
[15:40] <oSoMoN> 32547 stat("/dev/nvidia0", 0x7fd7ffffdb10) = -1 EPERM (Operation not permitted)
[15:40] <oSoMoN> 32547 mknod("/dev/nvidia0", S_IFCHR|0666, makedev(195, 0) <unfinished ...>
[15:40] <oSoMoN> 32547 +++ killed by SIGSYS +++
[15:40] <jbicha> didrocks: I've been using GNOME Shell 3.25.90 for a few weeks, we couldn't really delay landing it any later if we wanted it in 17.10
[15:41] <didrocks> jbicha: correct, but did you see/tried those kind of issues?
[15:41] <ogra_> .... 0666 ....
[15:41] <ogra_> oh my
[15:42] <oSoMoN> popey, inside the snap shell, what’s the output of "stat /dev/nvidia0" ?
[15:43] <popey> http://paste.ubuntu.com/25439032/
[15:43] <jbicha> didrocks: I saw the userswitch issue once recently and can confirm it now; it's not something I do very often
[15:44] <didrocks> jbicha: mind reporting this bug upstream if you can? I'm looking at some other issues
[15:44] <popey> jbicha: out of interest is ppa:gnome3-team/gnome3-staging the right place to get latest gnome shell for testing?
[15:44] <popey> (I'm running 3.25.91 from there on my spare laptop)
[15:44] <jbicha> popey: no, latest gnome-shell is in artful directly today
[15:44] <popey> oooh
[15:45] <didrocks> popey: just don't do user switching :p (see above ^)
[15:46] <didrocks> also, on the "fun list", can't boot my laptop (boot hangs) if I'm on wifi (need a wired eth cable, I guess hang in the network stack)
[15:46] <jbicha> popey: not much left in the staging ppa now https://launchpad.net/~gnome3-team/+archive/ubuntu/gnome3-staging/+packages?field.series_filter=artful
[15:47] <popey> yay, updating!
[15:47] <popey> the new control panel is a bit odd
[15:48]  * didrocks tries to get more logs on the boot issue
[15:48] <jbicha> popey: use it long enough and the old one becomes odd too :|
[15:49] <popey> odd as in strange ux
[15:50] <jbicha> I wish they had enabled it sooner in the dev cycle, GNOME is nearly at final code freeze now so I think the layout is pretty final for 3.26
[15:50] <popey> it remembers selections you haven't applied, across reboots, which is quite bizarre
[15:51] <kenvandine> jbicha, my intel laptop is no longer giving me a wayland session
[15:51] <kenvandine> gdm is using wayland
[15:51] <popey> e.g. change display settings, but don't apply them, then reboot and you still have a cancel/apply button, remembering the unapplied change you made before rebooting
[15:51] <kenvandine> not seeing any indication why my session isn't
[15:51] <popey> very odd
[15:52] <kenvandine> jbicha, any pointers to debug?
[15:52] <popey> kenvandine: logout, switch back and forth in the selector between ubuntu and ubuntu on xorg, then login
[15:52] <popey> that sometimes unsticks it
[15:52] <kenvandine> i even tried with a new user
[15:52]  * kenvandine gives it a shot
[15:53] <popey> fwiw i am fully up to date and have a wayland session on intel
[15:53] <popey> oh
[15:53] <didrocks> cyphermox: xnox: it seems that the boot hanging up is really related to networking…
[15:53] <cyphermox> on the desktop daily image?
[15:54] <didrocks> cyphermox: current up to date (installed)
[15:54] <kenvandine> popey, OMG... that did it
[15:54] <kenvandine> popey, is there a bug filed for that?
[15:54] <oSoMoN> popey, I updated https://forum.snapcraft.io/t/chromium-snap-doesnt-work-with-the-nvidia-proprietary-driver/1825/6 with our findings so far
[15:54] <didrocks> cyphermox: just using wifi, and hanging is "fixed" once I wire an eth cable
[15:54] <popey> didrocks: is there a bug for the wayland session not starting, that you have to flip back/forth in the login screen?
[15:54] <popey> (you mentioned it last friday)
[15:55] <Beret> jbicha, I still see the dpi issue unless and until I open up the gnome tweak tool
[15:55] <cyphermox> didrocks: ok, will try shortly
[15:55] <Beret> jbicha, could there be a preference that I've set that's sabotaging myself?
[15:55] <didrocks> popey: the selection, yeah, there are some, I saw a lot of duplicates being closed, jibel can point to the current one
[15:55] <cyphermox> didrocks: are you trying with UEFI or not (not that it should matter)
[15:56] <jbicha> Beret: could be, could you file a bug? your tweak tool comment is very confusing
[15:56] <cyphermox> maybe I need to re-setup my laptops for release testing by now :)
[15:56] <didrocks> cyphermox: no UEFI, just booting up, relying on wifi for my connexion. some journal logs: http://paste.ubuntu.com/25439101/
[15:57] <didrocks> cyphermox: you can see that the boot is hanging until I plug my ethernet cable
[15:57] <didrocks> (at 17:51:35)
[15:57] <didrocks> then, I can unplug and live on, just not boot :p
[15:58] <kenvandine> didrocks, my boot was hanging this morning too
[15:58] <kenvandine> waiting for dhcp discovery, seemed related to a bridge interface
[15:58] <didrocks> kenvandine: wireless?
[15:58] <kenvandine> yes
[15:58] <didrocks> sounds similar
[15:58] <kenvandine> i removed libvirt and friends
[15:58] <kenvandine> and it went away
[15:58] <didrocks> hum
[15:58] <didrocks> I need libvirt :p
[15:58] <didrocks> testing a lot with gnome-boxes
[15:58] <kenvandine> i just installed it yesterday :)
[15:59] <kenvandine> yeah, i installed gnome-boxes yesterday
[15:59] <kenvandine> and today it was taking ages to reboot
[15:59]  * didrocks tries
[15:59] <didrocks> kenvandine: well, I have gnome-boxes for months here, without any issue until today :p
[15:59] <didrocks> let me try a reboot with it removed, to help cyphermox
[15:59] <kenvandine> yeah, maybe the NM change?
[15:59] <didrocks> yeah, I think
[15:59] <jbicha> didrocks: the short answer on whether hints were needed for g-shell transition is no (beyond the s390x removal)
[16:00] <didrocks> jbicha: excellent! thanks :)
[16:00] <jbicha> bye
[16:01] <kenvandine> it looked like dhcp had to time out because wifi wasn't connected yet, and the bridge interface was connecting wlan0
[16:02] <kenvandine> didrocks, it looked like dhcp had to time out because wifi wasn't connected yet, and the bridge interface was connecting wlan0
[16:02]  * kenvandine tries installing it again
[16:02] <didrocks> cyphermox: kenvandine: not libvirt related to me
[16:02] <didrocks> still having the hang without it
[16:02] <didrocks> let me try now that I disabled systemd-network-d
[16:02] <didrocks> networkd*
[16:02]  * didrocks reboots
[16:04] <didrocks> cyphermox: kenvandine: yep, better with systemd-networkd disabled
[16:04] <didrocks> xnox: you might want to have a look at this discussion: boot hanging up (see my pastebin) with your systemd-networkd change
[16:04] <Beret> jbicha, filed at https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1714295
[16:04] <didrocks> (wifi only, keeps hanging until an ethernet cable is wired)
[16:05] <kenvandine> didrocks, i reinstalled gnome-boxes and it doesn't hang my boot anymore
[16:06] <didrocks> yeah, I guess you are hit by something else as I am (but reliably)
[16:06] <jbicha> Beret: are you using Wayland or X? and are you sure? (because there may be some session bugs still)
[16:06] <didrocks> xnox: cyphermox: keep me posted if you want a bug report on tihs
[16:06] <Beret> jbicha, wayland
[16:07] <Beret> jbicha, and Xwayland is running
[16:08] <jbicha> I believe gdm uses xwayland too so that's not 100% proof
[16:08] <jbicha> Beret: what scaling factor in tweak tool are you talking about? the primary Windows> scaling factor was removed this cycle
[16:09] <Beret> jbicha, the one in the fonts section
[16:10] <jbicha> Beret: I think GNOME Shell ignores font settings since it doesn't actually use gtk itself
[16:10] <Beret> yeah, that's fine
[16:10] <Beret> I just want the scaling working again :)
[16:11] <Beret> someone asked me if I had messed with the scaling in tweak tool
[16:11] <jbicha> didrocks: I can try filing the bug but I'm not very good at debugging gnome-shell crashes
[16:11] <jbicha> I had https://bugzilla.gnome.org/786660 but I've not heard any one else complain about it
[16:15] <cyphermox> didrocks: please file one anyway
[16:16] <didrocks> cyphermox: systemd?
[16:16] <didrocks> or n-m?
[16:21] <didrocks> cyphermox: kenvandine: xnox: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1714301
[16:21] <didrocks> jibel: you may want to add it to your list of things to track ^
[16:26] <jibel> didrocks, okay
[16:36] <kenvandine> didrocks, that's different than i saw, weird we had such a similar symptom on the same day though :)
[16:37] <kenvandine> i had 2 minutes of DHCPDISCOVERY messages logged until it timed out
[16:38] <kenvandine> didrocks, i can't find this gdm bug, the one where i had to switch to the xorg session and back in order to get a wayland session
[16:39] <didrocks> kenvandine: see with jibel, I lost track of all those bugs with the number of duplicates for the canonical one :)
[16:39] <didrocks> are you working on this?
[16:40] <kenvandine> jibel, ^^
[16:40] <kenvandine> didrocks, no, i was just trying to test the wayland interface and realized i was no longer running wayland :)
[16:50] <jibel> kenvandine, let me file one, I've the same issue on my laptop.
[16:50] <muktupavels> didrocks: any news about per-desktop overrides?
[16:51] <muktupavels> didrocks: also there is updated patch for glib-compile-schemas...
[16:51] <didrocks> muktupavels: from Allisson? Didn't get any recent news
[16:51] <kenvandine> jibel, cool, thanks
[16:51] <didrocks> Allison*
[16:51] <didrocks> muktupavels: yeah, I'm currently building it even if I started working 10h ago :p
[16:51] <didrocks> actually 12h ago now
[16:51] <didrocks> :(
[16:51] <didrocks> I'll give it some light testing tonigh
[16:52] <didrocks> and if all ok, upload tomorrow
[16:52] <muktupavels> ok.
[16:52] <jibel> kenvandine, there was bug https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1712287 but after investigation it's due to the graphics driver. I'll file a separate report
[16:52] <jibel> (it's duplicate actually)
[16:53] <jibel> kenvandine, didrocks note than now I've the opposite bug, ubuntu-xorg starts wayland
[16:54] <didrocks> I guess there is no "wayland" or "xorg" bug
[16:54] <didrocks> it's just gdm mixmatch the sessions
[16:54] <kenvandine> weird
[16:57] <jibel> how do I switch to a VT? If I start a byobu sesssion during a graphical session, it's killed when I close my session
[17:05] <jibel> kenvandine, didrocks bug 1714312
[17:06] <didrocks> jibel: I don't reproduce that same case, it seems fuzzy
[17:06] <didrocks> like "Ubuntu" doesn't always starts a X11 session
[17:06] <didrocks> if I click on the cog and select ubuntu, I have wayland
[17:06] <didrocks> there is clearly a bug, in some cases, but I don't think the reproduceable test case is that one
[17:12] <jibel> didrocks, as I said, in some cases "ubuntu on xorg" starts wayland
[17:13] <didrocks> yeah, just sad that we don't have an easy reproducible test case
[17:13]  * jbicha renames the session to "Ubuntu on Xorg … maybe"
[17:14] <flocculant> :)
[17:14] <didrocks> fixed
[17:14] <didrocks> :)
[17:15] <didrocks> way enough for today anyway
[17:15]  * didrocks ends
[17:15] <jibel> same
[17:15] <jibel> good night everyone
[18:42] <oSoMoN> nighty-night