[00:13] c-lobrano: hey, about the pngs, how did you generate those? [01:23] duflu: hey, could you review some theme MPs I've? [01:24] otherwise I'm self-approving as they're there since some time xD [01:24] Trevinho, I'll try to have a look today [01:24] hey btw :) [01:35] Trevinho, btw if you're marking bugs Fix Released then it's best to include the changelog entry showing where it's fixed. Or a comment mentioning where [01:36] duflu: for some of them they where already mentioned (I closed the upstream bug only) [01:36] while for one I didn't really know when xD [01:39] duflu: as for https://bugs.launchpad.net/ubuntu-themes/+bug/1762465 I should only change the code involving selection and mouse hover, right? [01:39] Ubuntu bug 1762465 in ubuntu-themes (Ubuntu) "Nautilus sidebar theming is confusing" [Medium,Confirmed] [01:40] Trevinho, not mouse hover. I think the goal is to make the label backgrounds always match the icon backgrounds [01:41] Because they look like tabs [01:41] which is incorrect [01:42] mh, I think is too late for such change. it might break screenshots or such [01:43] I'm fine with changing the hover effect, but that was approved by design [01:45] Trevinho, yeah I understand [01:45] I'll revisit it a bit, but not everything probably [01:48] I know it's too late to change 18.04, but suspect we'll hear a few duplicate bug reports after release so think about it for 18.10 [02:26] Trevinho, heh. I noticed bionic felt smoother... didn't know you got the master clock change in [06:03] is it a known bug where some gtk windows seem as somewhat transparent, and when they're moved the contents get messy [06:04] gedit for one [06:04] I just upgraded and rebooted, thought this would've been fixed but no [06:05] hm, doesn't happen on my laptop [06:08] huh, it's some user setting messing things up [06:19] good morning [06:25] Good morning [06:25] salut didrocks [06:32] good morning desktoppesr [06:32] desktoppers* [06:32] and happy Friday! [06:45] hey jibel, oSoMoN! [06:47] salut didrocks, jib [06:47] jibel* [06:47] slow fingers today… [06:49] tjaalton, yeah Saviq reported that bug. Lemme find it [06:50] tjaalton, bug 1760818 [06:50] bug 1760818 in ubuntu-themes (Ubuntu) "gedit and gnome-calculator transparency/graphics corruption issue" [Undecided,New] https://launchpad.net/bugs/1760818 [06:50] ooh, thanks [06:50] Morning didrocks, jibel, oSoMoN [06:54] good morning desktopers [06:55] During the 1st run wizard I tried to setup livepatch but I couldn't authenticate. It kept asking for the 2nd factor. Is it a known issue? [06:56] not reported on https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bugs at least [06:56] and andyrock is off today [06:56] if that helps to feel better about the issue only canonical accounts are configured to use 2fa so it's not going to hit "normal users" [06:57] but the code is supposed to handle the 2fa, unsure why it doesn't work for you [06:58] and the only message is a successful authentication [06:59] didrocks, where do you store the telemetry data? [06:59] :/ [06:59] is there anything interesting in the journal? warnings/errors? [07:00] no [07:00] didrocks, I've this message for my gpu "couldn't get GPU info: couldn't find any line matching ^.* 0300: (.*) \$rev .*\$$" [07:14] jibel: ~/.cache/ubuntu-report/ubuntu.18.04 [07:15] if it's ignore, you shouldn't have the field [07:15] the question is what is your lspci -n output? [07:16] Trevinho: hi :), no I didn't generate the .pngs, Mads did that, but I said it won't probably been able to generate the svg from there :( [07:17] and, good morning to all :) [07:18] hey c-lobrano! [07:18] hi didrocks :) [07:20] didrocks, I filed bug 1765614 [07:20] bug 1765614 in ubuntu-report (Ubuntu) "Incorrect regex for GPU info" [Undecided,New] https://launchpad.net/bugs/1765614 === pstolowski|afk is now known as pstolowski [07:20] jibel: ah perfect! I guess that will wait for a SRU, correct? [07:20] I'll add a test case for this in the tests as well [07:22] didrocks, sure it can wait [07:22] jibel: thanks for debugging! [07:23] Morning seb128 [07:23] Hey duflu, how are you? [07:23] I spent more time on ubiquity and understand things even less :/ [07:23] https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L736 [07:24] the gtk frontend does set some gsettings using the python bindings [07:24] seb128, I'm not feeling great today, but I think I am making some real progress on totem performance. Only a day after I said I was giving up [07:24] You seb128? [07:24] duflu, I'm tired, stayed up too late looking at ubiquity :/ [07:25] the frontend does gsettings call to disable e.g screensaver or power management from gsd [07:25] but the code is root [07:25] and those services are user ones [07:25] so I don't understand how that can work [07:25] seb128: check for the euid to get under what user this part of code is running: print(os.geteuid()) [07:25] also if I gsettings get they seem to have the correct value [07:25] as ubiquity is doing a lot of raise/drop priviledges [07:25] but like I use the session 15s/try activate the screen reader [07:25] and they all are back to the default value [07:26] not the ones set from ubiquity [07:26] hum [07:26] are they delayed keys by any chance? [07:26] delayed? [07:26] (and not committed for any reason?) [07:26] seb128: https://developer.gnome.org/gio/stable/GSettings.html#g-settings-delay [07:27] there is no mention of "delay" in the file [07:27] didrocks, code is like https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L589 [07:28] I also don't understand why those previous/etc checks [07:28] if the function is disable why not just set to false? [07:30] yeah, this looks cryptic :/ [07:30] can you attach some dbus monitor, or maybe a shell watching for the key? [07:30] to see when it's set/unset [07:33] yeah, I can try [07:34] that diff http://paste.ubuntu.com/p/fMSsYjYWDv/ is [07:34] - boot in installer mode [07:34] - go to a vt [07:34] - gsettings list-recursively > boot [07:34] - go back to vt1/ubiquity [07:34] - super,alt,s to try to activate the screen reader [07:35] - back to vt, gsettings list-recursively > screen [07:35] diff the 2 files [07:36] so, all keys are set to what you expect, correct? [07:36] shortcuts, toolkit-accessibility to true… [07:37] well it's resetting all the changes ubiquity is doing [07:38] org.gnome.settings-daemon.plugins.media-keys screenreader should still be '' [07:38] it's disabled explicitly in ubiquity [07:38] same for the terminal [07:38] well, that's what that diff is [07:39] all the things ubiquity set are reverted to their default [07:39] yeah, is gnome-shell resetting the keys somehow? [07:40] ahhhhhhhh, got you know [07:40] now* [07:42] seb128, at the end of run in bin/ubiquity-dm there is this [07:42] for gs_schema, gs_key, gs_value in gsettings_keys: [07:42] subprocess.call( [07:42] ['gsettings', 'reset', gs_schema, gs_key], [07:43] that's after the greeter exit though [07:45] the other reset is in unset() of gsettings.py but it is never called [07:47] morning [07:48] jibel, didrocks, it's not ubiquity, in fact those get reset on first gsettings write [07:48] I did a gsettings set of the screen-reader key manually [07:48] and everything did reset [07:49] hey Nafallo [07:49] hum… this is weird [07:49] so [07:49] better doing your gsettings set manually [07:49] hey Nafallo [07:49] you should maybe try a dconf dump? [07:50] yes [07:50] I tried to strings ~/.config/dconf/user [07:50] the changes are in the db [07:50] similar :) [07:50] in the db before being reverted? [07:50] at least it references the keys that are modified [07:50] yes [07:50] even more surprising… [07:50] I though that maybe it has in memory status not commited on disk or something [07:50] but no :/ [07:50] yeah, exactly… [07:50] hence my question on dconf dump [07:50] brrrr [07:51] also there are 2 dconf-service active for the user with different dbus session address [07:51] but I tried to kill the 2 and it's not making a difference [07:51] can you try gsettings set on something completely unrelated to GNOME? [07:51] like a key for one of our service [07:51] to see if that still reverts [07:51] let me see [07:51] can be something listening on GNOME schemas and reverting on any :change [07:56] morning all [07:56] how is it Friday already? [07:56] hey willcooke [07:56] puzzling friday it is [07:57] trying to understand the ubiquity ways [07:57] jibel, have you test UEFI installs recently? [07:58] hey willcooke [07:58] hi willcooke [07:58] jibel, ignore, this laptop is in UEFI mode, and works fine [08:00] didrocks, it's any key, I tried settings com.ubuntu.update-notifier something [08:00] didrocks, it doesn't revert if I kill dconf-service :/ [08:01] and let a new one be spawned [08:01] well, that makes sense at least [08:01] moin [08:01] you have the two trying to write, and one with the old memory mapping [08:01] hey Laney [08:01] so, the question is why 2 are launched I guess [08:02] Hello, 12 days ago I created Bug 1762200, nobody answered yet. I think it's important before final release. can you take a look at this? [08:02] bug 1762200 in xorg (Ubuntu) "[xorg.conf missing]nvidia detects 2 screen but there is no 2 screen" [Undecided,New] https://launchpad.net/bugs/1762200 [08:02] or do you only have an old one? You told that 2 were running, but that was maybe after you set the key already? [08:02] (so maybe 2 session bus or address?) [08:03] it doesn't make sense [08:03] seb128: why? my guess is that: [08:04] the second one from the env is a sudo process on a gsettings set command to set volumes-visible [08:04] I guess the ubiquity code is just fucked [08:04] it try to do set with the wrong context [08:04] already in the existant code [08:04] seb128: look at /proc/$pid/environ for the 2 dconf process [08:05] I did [08:05] to see what env is incorrect and why a second is spawn [08:05] same? [08:05] no, what I just wrote [08:05] there is the normal one [08:05] and one resulting from a sudo gsettings set on that nautilus key [08:05] but env variables are exactly the same in the 2? [08:05] (which was my question) [08:05] no, the normal has the right address [08:05] the run/uid from the user [08:06] the other one has a random long checksum [08:06] let me pastebin those [08:07] yeah, have you tried to simply remove the code where ubiquity spawn that second process? (from line 406 in bin/ubiquity-dm) [08:07] http://paste.ubuntu.com/p/bNQRS6MMmt/ [08:08] vs [08:08] http://paste.ubuntu.com/p/rY8Tyk89St/ [08:08] SUDO_COMMAND=/usr/bin/gsettings set org.gnome.nautilus.desktop volumes-visible false [08:08] DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-B1qg1YXAql,guid=24adb17fe5a37f790451a8405ad99f91 [08:08] indeed, different session bus [08:09] yeah, so I think what happens: [08:09] - gsettings from ubiquity contact one of the 2, it writes the settings -> ok [08:09] good idea for the ubiquity-dm dconf spawn [08:09] - something else set a key outside, contact the first one -> it doesn't have the new key -> write what he has in memory [08:10] right [08:10] willcooke, morning, yes on a real laptop and it worked why? [08:10] the second one shouldn't exist [08:10] I'm worrying that actually ubiquity-dm is trying to only contact dconf-write on this "private bus" [08:10] yeah [08:10] but worth a try [08:10] willcooke, the only thing that doesn't work is users installing in bios mode on uefi hardware [08:11] the only code that writes that key is https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L636 [08:11] well, "only" ... [08:11] seb128: oh, it seems ubiquity tries to reuse the session bus [08:11] so, it's weird it's setting a new one [08:11] didrocks, I'm going to check some uid checks as well, thanks for the help, I'm coming back once I get a bit more debug info/context [08:11] do you have the process hanging around? [08:11] no, I just closed, I need to reboot [08:11] seb128: yeah, just try to check ubiquity proc environ [08:11] ok [08:11] next time :) [08:11] I'm going to add debug prints and restart [08:11] line 398 FYI [08:11] this sounds like fun [08:12] thx [08:12] Laney, it is :p [08:13] k, on that note I'm moving back to my desk, no point starting a new debug session from here and my battery is almost empty [08:13] be back in 10 min or so [08:15] jibel, I saw someone on the hub saying it was broken, but in my testing it wasn't. What's the use case for bios mode on UEFI? Is that something people actually need to do, or are they holding it wrong? [08:17] willcooke, they don't need to and there is a warning when they try to do so but if they continue grub installation fails [08:17] jibel, not a release blocker then? [08:17] willcooke, IIRC there is a bug report to completely block this path because it cannot work [08:17] willcooke, no [08:18] jibel, thx [08:18] who fixed google calendar online account integration? thanks for that. it's so useful to see my meetings again in shell :) [08:19] willcooke, this post https://community.ubuntu.com/t/grub-efi-amd64-signed-failed-to-install/5274 ? [08:19] there is not much info [08:20] I'll check anyway to make sure nothing broke [08:22] jibel, yeah that's the one. It's fine, I just tested it, it worked [08:22] it = normal install on UEFI [08:29] back [08:54] Good morning all! [08:54] hey GunnarHj [08:54] how are you? [08:54] A question, since I'd like to understand: The seeded snaps, are they on the ISO? [08:54] yes [08:54] seb128: have you seen that misc.py only looks at PKEXEC_UID and gsettings.py only looks at SUDO_USER? [08:54] hey GunnarHj [08:55] hey GunnarHj [08:55] seb128: The purpose is not ISO space optimizing, I suppose. ;) [08:55] GunnarHj, no, it's to get on with modern technologies [08:56] Laney, no, I didn't, in fact I didn't notice before now that gsettings.py was changing user/using sudo, that explains things [08:57] that part seems unusual to say the least [08:57] I'd think that dropping privs alone should be enough [08:57] yeah [08:58] but misc.py needs to use SUDO_UID too otherwise it doesn't work from the live session [08:58] that desktop file uses sudo not pkexec [08:59] well or change that part I guess [08:59] Is it intentional that gnome-initial-setup runs after initial install and relogin? [08:59] I wonder if we could just misc.drop_privileges_save() and use the gsettings binding rather than the wrapper? [08:59] juliank, what do you mean "and relogin"? [08:59] seb128: Installed upgrades, logged out, and back in again. [08:59] you go in 2 sessions in a row? [08:59] got it* [09:00] Ran through gnome-initial-setup, it picked up my current keymap and deleted the others. [09:00] apart from that it did not seem harmful [09:00] seb128: probably apart from keeping the API [09:00] like this one lets you just try setting keys on schemas that aren't installed [09:00] gsettings is a bit opinionated about you trying that :-) [09:01] haha [09:01] juliank, you had a screen about locale/keyboard? [09:01] "a bit" [09:01] juliank, what session do you use? [09:01] juliank: Thought that the keymap part of gnome-initial-setup was hidden. [09:02] I didn't see any locale/keyboard page when I upgraded this morning [09:02] they are not displayed in Ubuntu sessions [09:02] but maybe juliank is using a GNOME session [09:03] oh yes I am [09:03] are we supposed to show g-i-s there? [09:03] * juliank thinks it makes sense on first install, but not on upgrades [09:03] robert didn't change the behaviour for !Ubuntu [09:04] well, even on first install [09:04] I guess it could be called upstream experience :p [09:04] well upgrades would be fine too if it did not delete additional keymaps [09:04] it needs integrating with the upstream install experience then [09:04] I don't have really an opinion on that, out of that fact that it duplicates ubiquity questions [09:04] I have an opinion that it shouldn't be run [09:05] sounds fair enough [09:05] we need to fix that then [09:06] Laney, seb128: Selecting language from g-i-s won't reasonably not work well, if the code hasn't been tweaked similar to g-c-c. [09:06] now you have to break the upstream g-i-s experience :/ [09:06] well we don't have the installer side so it's broken anyway on Ubuntu [09:07] If someone's using our g-i-s package [09:07] sil2100, kbd pre-selection is fixed on today's iso. Thanks! [09:07] Laney, you mean? [09:07] We remove the desktop file or whatever [09:07] it is in any case, it duplicates ubiquity questions [09:08] Some derivative that is using g-i-s gets that update [09:08] oh look, their gis is now broken [09:08] as we have per-session XDG_CONFIG_DIRS, we can maybe ship the autostart there? (but it means, shipping for xorg, wayland, communitheme xorg, communitheme wayland) [09:09] it's about turning it off for other sessions though [09:10] Basically it's taking a package which was working if you wanted to use it and making it not work [09:10] Can't see another way though [09:10] well, hypotetical derivative needs an override then, that's part of being a derivate to need to adapt [09:10] for what it's worth I don't know of any using it atm [09:10] so I don't think it's a big deal [09:11] ok, Ubuntu archive Ubuntu packages to do whatever we want with [09:11] for what it's worth I don't think it is/was in a working state [09:11] as GunnarHj said that needs at least to be made to work with how we do translations [09:12] anyway, I agree it's suboptimal [09:12] and wrong in theory [09:12] I'm just saying that in practice it shouldn't be a disaster [09:13] juliank: would you mind filing a bug please? [09:13] I'll probably get this too if I restart but I didn't yet [09:14] Laney, so going back to ubiquity, I'm a bit lost [09:14] sure [09:15] Laney, you think that gsettings.py is doing something wrong with SUDO handling? [09:15] In the ubiquity-dm session as far as I know ubiquity is started via pkexec [09:15] in the *live* session it is started by sudo [09:15] you get PKEXEC_* variables in the first case and SUDO_* ones in the second [09:15] which tell you which user you came from [09:15] that's what ubiquity is using to know who to drop back down to [09:16] I'm in ubiquity-only and I dump the env from gtk_ui.py around the gsettings calls to disable screensaver [09:16] but the code is checking different ones in different places [09:16] and the env has SUDO_USER=ubuntu [09:16] and no PK env [09:16] so if it's using SUDO then the misc.drop_all_privileges thing doesn't work [09:17] it doesn't make sense why it's not creating issues in other places if that's the case :/ [09:18] Laney: https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1765644 [09:18] Ubuntu bug 1765644 in gnome-initial-setup (Ubuntu) "After install, runs in gnome session after logging in again, deletes alternate keymaps" [Undecided,New] [09:19] the title is too long [09:19] thx [09:19] I must say I liked the experience of g-i-s [09:19] Laney, http://paste.ubuntu.com/p/vn4tKc9S73/ is a print(os.environ) after self.disable_screen_reader() in gtk_ui.py [09:20] apart from that thing [09:20] juliank, we don't intend to use it [09:20] it looked nice [09:20] :) [09:20] at least not this cycle [09:20] we built on it for the ubuntu welcome wizard in ubuntu session [09:20] we are going to look at include some of the upstream screens next though [09:20] like online accounts config [09:20] that one seemed actually useful [09:21] keyboard setting not so much :) [09:21] though just having a Welcome screen is kind of nice too :) [09:22] Laney, oh, there is a PKEXEC_UID as well which I didn't notice earlier, I guess pkexec just set SUDO_USER as well [09:23] k, I think I'm going to do the same as yesterday, early lunch and then I try to rip off that sudo use see if it's really needed [09:24] alright [09:24] how do you get a tty from the only ubiquity sessions? [09:24] thought that was fixed [09:24] it is [09:24] oh yeah [09:24] I can switch to a vt using the normal ctrl-alt-fn [09:24] it just takes like 10 seconds [09:24] right [09:28] seb128: https://paste.ubuntu.com/p/TBPv8pD254/ that's what I can see from /proc/ubi/environ [09:48] bug 1765651 should probably be fixed for the release ? [09:48] bug 1765651 in gnome-initial-setup (Ubuntu) "Do not run gnome-initial-setup during OEM preparation stage" [Undecided,New] https://launchpad.net/bugs/1765651 [09:49] probably fixing julian_k's would fix that too [09:49] IMHO they could be nominated / assigned but it's not really up to me :-) [09:50] seb128, willcooke ^^ WDYT? [09:53] didrocks, I think telemetry data should include information about OEM installation and the end user setup. For example if I do an OEM install in English and the end user setup in French, it just tells me the installation is in english not the settings selected by the end user. [09:58] jibel, yeah, sounds sensible [10:00] Wimpress, mwilson-e: can you test the new nvidia-prime, please? (when it's built) https://launchpad.net/~albertomilone/+archive/ubuntu/deleteme-nvidia [10:02] tseliot: Will do. [10:02] thanks [10:19] tseliot: Tested on 1 unit so far with MATE and it works. :D [10:21] mwilson-e: that's good. I can't reproduce the problem here either with the new package [10:21] I suppose all the other Ubuntu flavours use lightdm, that's why it was failing [10:22] tseliot: Sure thing. [10:22] thanks [10:51] tseliot: I'm encountering some issues here. [10:52] I've purged all *nivia* paackages from the system. [10:52] *nvidia packages [10:53] Which also mean nvidia-prime is not installed. But your testing ppa is enabled. [10:54] Ah, found the issue. [10:54] I still had the graphics-drivers PPA enabled. [10:58] Wimpress: issues with nvidia-prime? [10:58] I'm retesting again now. [11:01] I purge all nvidia packages, which means nvidia-prime is not installed and rebooted. [11:01] Install nvidia 390 drivers via Additional Drivers UI. Rebooted. [11:02] The display manager still works, but nvidia-prime was not installed and libnvidia-compute-390:i386 is a broken package. [11:03] did you purge libnvidia-compute-390:i386 manually before reinstalling? [11:03] Yep [11:04] neither ginggs nor I managed to reproduce that [11:04] maybe try reinstalling libnvidia-compute-390:i386 [11:05] I'm going to test again and make sure no cached packages exist. [11:08] jibel: good point! g-i-s is runing after the OEM welcome user session, correct? [11:08] jibel: so, using the current user language can be an option, no? [11:08] (current == session) [11:09] the location isn't an issue I guess as we are taking the user's session one [11:18] didrocks, yes it does. current user settings would work [11:18] didrocks, I reported bug 1765672 [11:18] bug 1765672 in ubuntu-report (Ubuntu) "Add information about OEM installation and end user setup" [Undecided,New] https://launchpad.net/bugs/1765672 [11:21] jibel, Laney, robert_ancell is off next week so better not count on him to fix those issues before release [11:21] hey desktopers [11:21] hey ricotz [11:21] is someone able to test a firefox package on s390x? [11:21] seb128, hey [11:22] ricotz, try asking xnox maybe [11:22] Laney, right, your pastebin env is similar to the one I pastebined a bit earlier [11:23] wb seb128 [11:23] yes no SUDO stuff there [11:23] thx [11:23]