[07:06] good morning desktoppers [07:06] Morning oSoMoN [07:15] morning all [07:20] Hi jibel [07:25] hey duflu, salut jibel [07:28] tkamppeter: I gave some feedback on your CUPS thread here: https://forum.snapcraft.io/t/interface-request-cups-control-on-cups-snap-and-including-d-bus/15233/12?u=jamesh [07:44] good morning [07:46] Hi didrocks [07:49] hey duflu [08:25] salut didrocks [08:26] hello oSoMoN [09:02] yo yo yo [09:06] hey Laney [09:10] goood morning desktopers! [09:11] moin didrocks seb128 [09:13] hey Laney, how are you today? [09:15] alright, I stood outside in the sun for five minutes this morning [09:15] next door's cat came to say hi [09:16] this is life atm [09:16] you? [09:18] Morning Laney and seb128 [09:19] hey Laney, salut seb128 [09:22] Laney, I'm good, just adventured a trip to the local supermarket to get some stock [09:22] hey duflu, how are you? [09:22] oSoMoN, salut, en forme ? [09:22] guten morgen duflu und oSoMoN [09:22] good morning seb128 [09:22] indiana seb128 jones with that trip [09:23] seb128, dazed by a few windowing regressions in 3.36.0 that came from the icon fade fix. Just doing final testing of the new fix now though [09:23] Laney, :) [09:23] lut didrocks [09:23] duflu, :-/ [09:23] duflu, I guess you didn't have time for plymouth then? [09:24] seb128, that's less of a priority but it will be this week [09:24] didrocks, do you remember how you used the fsck mock in systemd? [09:24] I tried (bionic and focal) to sudo plymouthd --no-daemon --debug [09:24] and sudo ./fsck [09:25] but the splash screen doesn't display anything [09:25] I wonder if that was already broken in bionic? [09:25] or that way to start plymouth manually in debug is different from the boot mode [09:25] but it's weird because it shows the same screen and displaying message or the ask password entry works... [09:36] seb128, ça va, et toi? [09:36] oSoMoN, ça va bien :) [09:39] Morning desktoppers o/ [09:42] hey Wimpress, how are you? [09:45] All fine here. [09:45] Morning Wimpress [09:45] Typically, wonderful weather now we're confined to quarters. [09:45] duflu: Hi [09:46] Any luck debugging Plymouth? [09:46] Wimpress, no time for that today. Had to fix some issues in the new gnome-shell [09:46] morning Wimpress [09:46] But will get back to plymouth this week [09:47] duflu: Understood. [09:47] OSoMoN o/ [09:47] How is everyone? All well? [09:51] doing well indeed! [09:52] Wimpress, did you have a chance to try if you could see the fsck integration working? I tried on bionic with a force check and the mock didrocks pointed me at and it doesn't work here, I wonder if that's a local issue or if that has been not working for several cycles now [10:03] Laney: ping [10:04] chihchun: eeeeek sorry [10:04] I'll be with you in a minute! [10:07] seb128, one thing I did not try yet was an older release than eoan [10:07] Although I should get dinner sorted instead of restarting on plymouth [10:08] duflu, hey, enjoy your evening! I tried on bionic without luck so far :-/ [10:09] Oh that is odd [10:09] seb128: IIRC, I was replacing the binary on the system and just call it via systemd-fsckd or directly on boot [10:10] calling directly fsck won’t work because you miss the part which forward to plymouth [10:10] didrocks, ah. What do you mean by "call it via systemd-fsckd"? do you remember how one does that? [10:11] seb128, the only visual evidence I can find of it working last (Google Images) was 10.04 :) [10:11] been some years, I don’t remember, let’s look at systemd autopkgtests [10:12] (debian/tests/systemd-fsckd) [10:12] the autopkgtests install fsck [10:12] and reboots [10:12] Make that 12.10 and 14.04 [10:13] which is the easiest way to test [10:13] didrocks, I'm reading that autopkgtest as well now [10:13] I remember to have run it directly while iterating [10:14] but I don’t remember anymore how to do it easily, it was tricky because plymouth itself wasn’t showing the splash reliably at the time [10:14] yeah, plymouthd --no-daemon --debug doesn't work on my xenial [10:14] it sends me to a vt [10:15] works fine nowadays, on bionic/focal though [10:15] seb128: maybe vm + reboot it easiest? [10:15] however, I see now that we have /run/initramfs/fsck-root [10:16] and I have it on my systemd [10:16] system* [10:16] didrocks, it's slow iteration if you need to login, open text editor again, etc for each try [10:16] someone added: [10:16] if os.path.exists('/run/initramfs/fsck-root'): [10:16] print('SKIP: root file system is being checked by initramfs already') [10:16] sys.exit(0) [10:16] to the tests [10:16] so maybe we are now running fsck on the initramfs without user feedback? [10:16] (for the root at least) [10:17] that would explain why I'm not seeing anything on plymouth when I do a /forcefsck and reboot [10:17] yeah [10:17] I’m sure I didn’t write that, so it’s post our implementation [10:18] I don’t remember to have seen fsck moving in the initramfs being announced anywhere [10:18] or the impact to not have feedback discussed [10:18] tkamppeter, hey, printer discovery stopped working in focal and I get this crash https://bugs.launchpad.net/bugs/1868944 [10:18] Ubuntu bug 1868944 in cups-pk-helper (Ubuntu) "cups-pk-helper-mechanism crashed with signal 5" [Medium,New] [10:20] (this was only for dracut at the time and we didn’t have it) [10:20] I think one way would be at least to try with a vm with 2 disks [10:20] (and the mock) [10:21] at least to remove the "only one disk is skipped" idea [10:21] didrocks, it's unclear to me what the mock is useful for on that case/how to use it? [10:21] seb128: it’s slowing down the fsck [10:21] so that you have the time to see it [10:21] didrocks, just forcing a disk check should make it display the events on plymouth through normal system integration? [10:22] ah [10:22] well slowing down by emulating what fsck prints [10:22] but yeah, you need to force a check with multiple disks [10:23] didrocks, so how to I set up the mock? replace the systemd binary with the fsck from the test dir? [10:24] seb128: not the systemd binary, your system fsck [10:24] ah [10:24] /sbin/fsck [10:24] thx, let me try [10:25] but yeah, 2 disks at least + /forcefsck [10:33] didrocks, so yeah, the skip was added in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782522 [10:33] Debian bug 782522 in systemd "Skip file system check if already done by initramfs" [Important,Fixed] [10:33] by Debian [10:34] ack, so at least if you have multiple disks, the message should still be there [10:34] for secondary ones [10:35] ./whois Laney: [10:35] ha [10:35] Laney: What do you want to do with oem-qemu-meta? [10:37] :D [10:37] FourDollars: We need a corresponding upload to Ubuntu to point the sources.list to the new archive layout [10:39] Laney: OK. What is the next step I can do? [10:39] Laney: Make a merge proposal? [10:40] FourDollars: diff / PPA package to upload [10:40] I guess you want to import this into your own vcs too [10:41] Laney: OK. Let me import it, make the change and then upload to my Launchpad Git repo. [10:42] thanks! [10:42] np [10:46] FourDollars: BTW you don't need to add "XB-Ubuntu-Kernel-Flavour: oem", that is the default [10:47] Laney: We want to make it clearer. Will it cause any problem? [10:47] bit of extra space used in the Packages file which is downloaded by everyone [10:48] but not hugely [10:55] OK. I will discuss it with others. [10:59] Laney: https://code.launchpad.net/~fourdollars/+git/oem-qemu-meta/+ref/master [11:01] great, thanks, I will look soon [11:14] seb128: Wimpress: the fsck integration does work with the ubuntu-logo theme..... i can trigger it correctly with e.g. plymouth-x11 in userspace. I guess i need to record videos. [11:18] xnox, would help if you were giving us steps how to test it it, would help also working on fixing spinner [11:19] xnox, same for casper, if you have any debug hint on how to get in an env to be able to hack/iterate [11:19] xnox, also looks like / and /usr checks are done in initramfs nowadays and not showing on plymouth? [11:20] Trevinho: hey, would that be an issue with the app indicator, or gnome-shell itself https://github.com/canonical/multipass/issues/1444 ? [11:20] canonical issue 1444 in multipass "Difficult to navigate to Shell in long list of VMs" [Bug, Open] [11:20] seb128: yeah, one needs like separate /home [11:21] seb128: indeed checks for / and /usr are done in the initramfs, but for those too we should have pretty plymouth integration [11:21] * xnox is sad [11:21] xnox, 'should' like would be nice to add or like should be working today? [11:21] seb128: bah =) "should one day" =) [11:21] because touch /forcefsck and reboot displays no fsck integration on bionic for me [11:21] k [11:22] xnox, so that integration is not working in most cases, I wouldn't consider the regression rc [11:22] seb128: it should be there for the initrd-less boot right [11:22] * xnox ponders things [11:22] seb128: but the casper one should work. [11:22] yes [11:22] the theme does support messages [11:22] seb128: cause the casper integrety check uses the same fsck:*status messages [11:22] if I plymoutd --no-daemon --debug [11:22] which are not shown in spinner theme [11:22] and ssh to the box use plymouth --message it does display the string [11:23] one can run casper thing from userspace without booting anything, on a devel laptop, I'll take some videos [11:23] xnox, do you have any debugging hint how to test the fsck/md5 integration? [11:23] like start plymouth by end [11:23] ssh [11:24] and start the casper script? [11:25] pull-lp-source casper; make in casper-md5sum; mount iso in /cdrom, and execute ./casper-md5sum /cdrom /cdrom/md5sum.txt => without plymouth that will be just text output [11:25] xnox, thx, that's useful [11:25] if one starts X11 plymouth, and controls it from a separate tty, does show spash, and execute casper-md5sum again it would show all the pretty stuff with three lines of messages [11:26] one line with fsck progress, one line with keycodes for skipping the check, and another one for any other messages / final message. [11:26] xnox, is plymouth x11 needed/more useful that real plymouth? [11:26] doing sudo plymouth --no-daemon --debug starts plymouth on a VT [11:27] with a ssh prompt that seems to work fine for debugging [11:27] unsure what else x11 provides? [11:27] seb128: i like x11 plymouth, as i run it direct on my development laptop / host, without booting any VMs. [11:27] one can do all of that in a VM too using "real" plymouth, and like stopping gdm/gnome-shell over ssh first [11:27] if one prefers to have separate thing. [11:28] xnox, well, what I just described seems to do the same [11:28] i guess preference =) and how one did it first =) [11:28] I do that on my real laptop [11:28] or does x11 does windows mode in session? [11:28] if casper-md5sum can ping plymouth, it will push fsck messages to plymouth, but it doesn't do show-splash byitself, so any connection to any plymouth which is showing splash is good. [11:29] i find x11 backend a bit crap, compared to the DRM one. There is smething with clock synchronisation, one kind of has to wiggle mouse for it to progress. [11:29] besides this. [11:30] seb128: is there any other patches/updates that i can test? i.e. have there been any gdm / shell / plymouth changes that improve any aspects of flickerness already? I saw some comment updates, but not sure if they are in teh Archive yet. [11:31] xnox, not at this point, only a new logo with better resolution in the archive [11:31] seb128: cool, and the logo is in gdm, plymouth, or both? [11:31] gdm and plymouth [11:31] nice =) [11:31] * xnox should upgrade & reboot [11:32] seb128: any more visual direction from design/ux/yaru? or more of do whatever? [11:32] xnox, not yet, but Wimpress has a catchup with design tomorrow [11:32] cool cool [11:33] xnox, good, your md5sum testing hint with [11:33] (need to sudo start it though) [11:33] it's going to make easier to debug [11:33] bah [11:34] xnox, doing that it shows the md5 messages on spinner/bgrt as well... [11:35] xnox, https://people.canonical.com/~seb128/plymouth/checksum.jpg [11:36] xnox, could it be also a case of files missing from the cache in casper like shutdown? [11:41] xnox, also https://people.canonical.com/~seb128/plymouth/new.jpg [11:41] seb128: that's incomplete [11:41] there should be three lines [11:42] xnox, I saw the 3 lines earlier [11:42] "checking filepath" "Fsck in progress 1 of 1 (40% complete" "Press S to skip" [11:42] xnox, still it does show one line at least locally so I wonder why on the ISO it doesn't? [11:42] and the first two should smoothly update [11:43] one should always see the correct % progress, the filepath names scrolling, and the keycode message for how to skip if one got bored. [11:43] right, at least it makes easy to test/fix that [11:43] still the liveCD doesn't display anything [11:43] so there is another bug on that env ... any idea how to debug that one? could be missing cache in casper? [11:45] well fsck is on boot; so there shouldn't be anything missing from cache; things might be missing from the initrd. As if incomplete spinner theme copied into the casper initrd or somesuch?! [11:45] i guess again, we need to boot with debug plymouth log to see what is happening. [11:45] plus doesn't spinner theme like "delay" showing splash on boot? or is that a fedora only thing? [14:16] seb128, debian bug 954885 [14:16] Debian bug 954885 in libmtp-common "/dev/bus/usb/*/* device file of printers assigned to "audio" group" [Important,Open] http://bugs.debian.org/954885 [14:16] tkamppeter, hey, I saw, you Cc-ed me on the email :) [14:17] seb128, OK, hope they will answer soon. [14:18] tkamppeter, if not I will upload to Ubuntu this week, ok? [14:18] seb128, OK, thanks. [14:19] good morning desktopers [14:25] good morning hellsworth [14:26] hi didrocks ! [14:34] seb128: hi! what regressions were you seeing with webkit2gtk that required the ppc64el fix? I'm wondering if I need it for eoan and bionic too [14:35] mdeslaur, hey, the rendered just segfaulted on ppc64el, couldn't display any page in the MiniBrowser [14:35] mdeslaur, which got caught by the ruby-gnome autopkgtest failing [14:36] mdeslaur, https://bugs.webkit.org/show_bug.cgi?id=209236 [14:36] bugs.webkit.org bug 209236 in JavaScriptCore "REGRESSION(r249808): [GTK] Crash in JSC Config::permanentlyFreeze() on architecture ppc64el" [Normal,Resolved: fixed] [14:37] seb128: ah! I think I'm hitting that autopkgtest failure too, thanks for the info! [14:37] mdeslaur, np! [15:02] hey folks, after an update from focal-proposed this morning, I can no longer scale my monitors using Settings, when I try to hit Apply, gnome-control-c in the system journal complains with `Config not applicable: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Logical monitors overlap` and reverts back to 100% after the timeout (and my monitors are blank during this time) [15:03] is this a known bug, or is there something I can do to set the scaling for my monitors some other way? all my text is now very small :-) [15:09] (and if it helps I'm on x11 with default gnome window manager) [15:23] ijohnson: are you using experimental x11 scaling? [15:23] Trevinho: yes I was [15:23] well still am, it's just not scaled at all due to the issue I mentioned [15:24] ijohnson: yeah... Ok thanks, I'll look into this, there was a rewrite on the xrandr code that may have changed some aspect I wasn't aware of. [15:24] need to retry again in multimonitor the [15:24] need to retry again in multimonitor then [15:24] ijohnson: I suppose it works for you in single mode right? [15:24] Trevinho: not sure, let me check [15:25] ijohnson: also, do you have some logging from `journalctl /usr/bin/gnome-shell -b0` that may help? [15:25] Trevinho: nope still reverts to 100%, even with only one monitor connected [15:25] Trevinho: sure one moment I can pastebin it [15:29] Trevinho: https://pastebin.ubuntu.com/p/Pwyn7b9gHc/ [16:19] ijohnson: that's weird as I've it working with one monitor locally... mhmhm [16:20] Trevinho: also if it makes a difference I am using proprietary nvidia drivers [16:21] ijohnson: it might, but it used to work fine with them as well [16:21] so... not sure [16:21] looks more a logic issue than driver one [16:22] happy to provide more debugging info if needed, I'm a bit busy right this moment, but will be more available in an hour or so [16:22] ijohnson: this looks to be the issue in your log Failed to read monitors config file '/home/ijohnson/.config/monitors.xml': Logical monitors not adjacent [16:22] ijohnson: no worries, open a bug once you've a sec [16:22] Trevinho: do you want that file ? [16:22] what project should I file the bug against ? [16:23] ijohnson: mutter [16:23] in ubuntu only though [16:25] Trevinho: ack running `apport-bug mutter` now [16:25] thanks [16:26] oSoMoN: hey, firefox re-enabled TLS v1.0/v1.1 because of governments not supporting v1.2 for covid-19 information; have we done that in our firefox now as well? and if not, can we get that uploaded? [16:29] Trevinho: reported as https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1869042 [16:29] Ubuntu bug 1869042 in mutter (Ubuntu) "all monitor scaling fails due to overlapping monitors" [Undecided,New] [16:34] xnox, I'm not seeing any new builds of firefox 74, i wonder how that revert works [16:34] xnox: what governments are that? [16:35] oSoMoN: let me find that. [16:36] JanC: i don't know, but Chrome & Firefox rolled back and enabled TLSv1.0/v1.1 [16:36] *re-enabled [16:36] maybe they'd better offered help to those governments to fix their servers... :-/ [16:37] ijohnson: I've just tried in my focal system with various configurations though, and it all works fine there.... [16:37] quite weird then, *might* be somewhat related to nvidia but can't be sure [16:37] hmm, do you want that monitors.xml file ? [16:37] xnox, that appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=1623534 [16:37] Mozilla bug 1623534 in Security: PSM "Remote pref override to re-enable TLS 1.0" [Normal,Resolved: fixed] [16:37] yeah, could help [16:37] ijohnson: weird that apport didn't attach that [16:38] ijohnson: also your gnome-control-center version may make a difference [16:38] I'll put it in the bug actually [16:38] xnox, if this is using Normandy, then there's nothing needed on our side, the pref is applied remotely [16:40] Trevinho: how do I check the gnome-control-center version ? [16:40] (also attached the monitors.xml in the bug) [16:42] ijohnson, dpkg -l | grep gnome-control-center [16:43] thanks seb128, Trevinho looks like I have `1:3.36.0-0ubuntu3` [16:43] ijohnson, also a known issue is that sometime the monitors do overlap on the graphical view of the settings panel, did you try to move them to make there they are snapped/correctly aligned? [16:43] seb128: yes I tried to move them around to make them snap together/correctly aligned [16:43] (in the settings window that is) [16:43] k [16:46] oSoMoN: I think, yes. [16:46] oSoMoN: what is Normandy? =) [16:46] oSoMoN: i thought there was code fix too on tip, for when normandy is not involved, such that we can out of the box be correct too. [16:48] xnox, https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout [16:52] hm [16:52] oSoMoN: I'm reading this https://github.com/mozilla/gecko-dev/commit/506fbc64931400548cfaa88b552cbe1d99562fdd [16:52] so it set security.tls.version.min to 3 only in nightly builds; but it remained as 1 in release builds? [16:53] such that switch to v1.2 as minimum, in release, was only done via Normandy, and reverted in Normandy, right? [16:54] oSoMoN: because in our firefox, I see that: pref("security.tls.version.min", 3); in ./modules/libpref/init/all.js meaning we have tls v1.0/v1.1 disabled [17:01] xnox, no, it was set to 3 in release builds, and that's the default value we ship, but normandy overrides it with 1 [17:01] just tested in a bionic VM, the value is initially 3, but gets overridden to 1 [17:02] (use about:config to inspect the value) [17:07] oSoMoN: it should be initially 1 [17:07] oSoMoN: can we patch that? (i.e. such that if one cannot talk to normandy, but can talk to whitlisted gov.* websites, tls v1.0/v1.1 is enabled, and it works correctly) [17:08] oSoMoN: shall i file a bug for it? [17:11] xnox, normandy is an essential component of firefox's preferences system, if one cannot talk to it that's bad luck but I don't think that warrants rebuilding firefox and pushing updates for everyone [17:12] at the very least this would require a report of such a thing actually happening in the wild [17:20] oSoMoN: we will rebuild firefox right? so how can this change be staged for the next rebuild of firefox? [17:20] i'll open a bug report. [17:22] xnox, we will rebuild if there's a new point release, or when 75 is released, but we shouldn't change the default value from upstream, because if/when they decide to switch it back via normandy, the default value should match with their expectation [18:00] oSoMoN: ok. I wonder if i can find the source code for the 74 branch, to see what they have committed upstream. === ijohnson is now known as ijohnson|lunch [18:13] oSoMoN, hi, I have pushed the firefox branches [18:13] oSoMoN, the python3 port should be good for 76 [18:14] oSoMoN, did we agree on targetting nasm 2.14 for 75 already? I haven't transitioned bionic yet, this can be done with beta 9 [18:39] ricotz, yeah, that's fine by me [18:41] good night all === ijohnson|lunch is now known as ijohnson [20:14] hellsworth: amd64 build of gnome-3-34-1804-sdk is in candidate