[05:01] morning [05:31] Hey [05:31] mborzecki: mvo asked for release reviews today [05:32] zyga: hey, ok [05:33] zyga: do you know what's the status of https://github.com/snapcore/snapd/pull/5845 ? iirc it was waiting for a review from jdstrand mostly [05:35] It also needs a new name from Gustavo [05:37] I need to take Bit to the vet for surgery today but that should take a moment [05:37] I’ll be in the office shortly [06:17] zyga: https://paste.ubuntu.com/p/3ZwGpF6ZyT/ something i found on the laptop [06:17] zyga: lrwxrwxrwx 1 root root 13 10-23 08:15 /var/lib/lxd -> /mnt/data/lxd [06:18] since we test for access() removing the symlink makes it work [06:48] Hmmm [06:57] Yeah, the error message need improvements === pstolowski|afk is now known as pstolowski [07:04] mornings [07:18] zyga: can you take another look at https://github.com/snapcore/snapd/pull/6023 ? [07:24] pstolowski: pedronis left a suggestion in https://github.com/snapcore/snapd/pull/6027 [07:25] yep, looking [07:34] Ok [07:34] Dog at vet [07:34] Two hours after surgery for pickup [07:34] Fingers crossed it goes well [07:35] mborzecki: two, in 2 minutes, just going home [07:39] pani, VCERA SME PREMESKALI MEDZINARODNY DEN CAPS LOCKU! [07:39] re [07:39] uh? [07:39] mborzecki: looking now [07:40] yday was the national day of cap lock? [07:41] oh sry, wrong channel :D [07:42] mborzecki: thank you for the link about Khan's Algorithm [07:42] I wasn't aware of it, cool [07:42] jdrab: nie szkodzi [07:42] :) [07:42] ahaha :) [07:46] zyga: yeah, and it's surprisingly simple once you understand it [07:49] hey there [07:49] $ snap changes [07:49] ID Status Spawn Ready Summary [07:49] 1462 Doing 4 days ago, at 09:21 CEST - Auto-refresh snaps "core", "core18", "gnome-logs" [07:49] is that "4 days ago" normal? [07:49] or is snapd stucked in some way? [07:49] pstolowski: ^^ [07:50] seb128: snap version? [07:50] $ snap version [07:50] snap 2.36~pre2+git965.966c1d4~ubuntu16.04.1 [07:50] snapd 2.36~pre2+git965.966c1d4~ubuntu16.04.1 [07:50] series 16 [07:51] pstolowski, ^ [07:51] pstolowski: you think that could be auto-connect? [07:51] seb128: ok, and snap change 1462? [07:52] that takes a bit... [07:53] pstolowski, http://people.canonical.com/~seb128/log [07:54] about that [07:54] I think we could use RW locks on state [07:54] so snap changes is fast [07:54] unless I misunderstand and the delay is because of the volume of data [07:55] crazy thought, but should we try to detect that stuff is getting retried indefinitely and perhaps log && abort? [07:55] I think we do that in a way [07:55] seb128: thanks. so yes, it's a known bug we've right now in master/edge, fix is being reviewed [07:55] very old tasks get aborted [07:55] or perhaps we meant to [07:56] I'm not super familiar with that code [07:57] seb128: as a workaround you can snap abort the change, and then remove all unused revisons of gnome-logs (snap remove --revision=....) to only leave one. alternatively, switching core to stable (after aborting the change) might help [07:58] mborzecki: I will follow up with a validator for topological sorting in the mount backend [07:58] at least we must detect cycles [07:58] zyga: ping me for review [07:58] with pleasure :) [07:58] pstolowski, ok, thanks, I didn't even remember that I changed the core to a non stable channel on that box :) [08:02] kyrofa, WRT --destructive-mode, it seems it currently only works if you don't pass a comand to snapcraft? if I try to "snapcraft prime --destructive-mode" it tries to use multipass [08:02] is that expected? [08:04] zyga: pstolowski: if i'm reading that right, the task would be auto aborted after 7 days [08:04] that's about right [08:04] it's a lot of time but it was meant to be conservative [08:04] seb128: which is good, thanks to one other report about this we avoided releasing it (it happens under specific circumstances) [08:05] mborzecki: zyga, right, we will not eat cpu indifinately or anything... but the problematic change will keep re-appearing and will never succeed (auto-refresh in this case) [08:06] yeah [08:06] we may have a fallback mode [08:06] eat cpu and fill up the state [08:06] if we fail to refresh and abort after 7 days [08:06] we could do something special, like just refresh core - if installed, or snapd - if installed [08:06] and nothing else [08:06] iff we do healtchecks, this could be part of it [08:09] seb128: so, thanks for using of edge, please switch back to it if possible after the fix lands, you guys have more interesting use cases than anyone else, so better chances of finding potential problems [08:09] if nobody minds i can push the fixes to https://github.com/snapcore/snapd/pull/5727 that jdstrand requested [08:10] mborzecki: +1 [08:10] pstolowski, np, thx for replying/getting me unstuck, your step worked [08:14] zyga: yes, this sounds like a good idea [08:27] mborzecki: can we land ? https://github.com/snapcore/snapd/pull/5346 [08:34] zyga: let me finish with the changes for breakpad and i'll take another look at it [08:34] it's +2 and green [08:34] breakpad? [08:34] ah [08:34] mozilla [08:34] sure [08:35] damn, hate running tests in snap-seccomp [08:35] (assuming that GH behaves again i un-quietened mup again) [08:43] mborzecki: on your laptop? [08:44] zyga: anywhere, it's making the modules for all those crazy AF_* loaded [08:44] ah right [08:50] zyga: looking at the snap:// pr [08:50] I wonder if it's ok to just merge [09:00] morning Chipaca [09:00] morning zyga [09:02] PR snapd#5985 closed: overlord/many: cleanup use of snapName vs. instanceName [09:15] need to go to get the dog from the vet [09:15] surgery over [09:15] brb [09:15] zyga: hmm, interesting issue from popey on the forum, 'snap interfaces' and conns state has the connection, but gnome snaps complain about lack of it; i've vague memory of something similiar before, do you remember? [09:16] zyga: and it's 2.35.4 [09:17] zyga: was there something about profile generation you were investigating some time ago? [09:18] it's https://forum.snapcraft.io/t/cant-connect-interfaces-so-cant-run-snaps/8123 [09:18] PR snapd#5346 closed: cmd/snap: gnome-software install via snap:// handler [09:24] update sequencing makes my head hurt, still [09:28] mborzecki: the snapcraft static suite doesn't like spread-shellcheck :-( [09:29] mborzecki: I reformatted it with black, which passed the first hurdle, but now its flake8 is saying it's all too complicated [09:30] zyga: at what point are cmd/snap-confine/spread-tests/ run? [09:33] Never, those are the old ones from split repo [09:33] Probably more stale than ever [09:33] pstolowski: still afk at vet, will be home in 10 min [09:34] Chipaca: heh, we can feed spread-shellcheck to snapcraft, have them fix it to be nice python, and merge it back [09:34] mborzecki: *cough* snapcraft#2381 *cough* [09:34] PR snapcraft#2381: tools: copy in spread-shellcheck from snapd [09:34] pstolowski: can you please ask for mount profiles [09:34] Current and desired [09:36] btw. are we having any talks about ubuntu core & snaps at ELC? [09:37] Chipaca: heh, checkfile is too complex, it's the cyclic complexity check right? [09:37] mborzecki: "aaah this is too complicated i give up" [09:37] mborzecki: I imagined flake8 slamming the program printing down and going off in a huff [09:37] Chipaca: i have some expierience working around gocyclo :P [09:38] wonder if that applies to python too [09:38] Chipaca: probably dropping some ifs would help [09:38] mborzecki: I was going to just leave it there and see if snapcrafters would push a fix :-) [09:39] Chipaca: hm ther's if > for > for > if sequence [09:40] i'm going to have to figure out why flake8 locally complains about everything, making it pointless, aren't i [09:40] sigh [09:40] * Chipaca remembers the snapcraft venv, and tries that [09:41] mborzecki: got it [09:41] mborzecki: i'll fix [09:42] Chipaca: heh, it's fun when you apply an artificial metric and thresholds and then workaround to meet the them :) [09:48] popey: allright, i'll ask you to collect a bunch of other info in a moment [09:49] pstolowski: ok [09:50] re [09:50] dog safely home, still numb. but alive :) [09:51] zyga: are the *fstab files from the host os useful, or only those from the mount namespace? [09:52] pstolowski: we want a pair of files: /var/lib/snapd/snap.$SNAP_NAME.fstab and /run/snapd/ns/snap.$SNAP_NAME.fstab [09:53] mborzecki: http://paste.ubuntu.com/p/6hmN9bKR6j/ [09:54] zyga: k, thanks [09:55] thank you, let me know if you get more data [10:00] Chipaca: does that bring the complexity count down? [10:03] mborzecki: it brings it down to 9, apparently [10:03] no, 10 [10:03] Chipaca: lgtm [10:03] mborzecki: from 12 or 14 that it was [10:04] 12 [10:04] mborzecki: ok, i'll push it [10:04] of course now black doesn't like it [10:04] :-) [10:08] pstolowski: the .fstab files are available in all namespaces [10:08] you don't need to be in a specific spot to read them [10:09] zyga: yep, i figured by md5'suming them just to be sure ;) [10:29] popey: ty! zyga, all the info there [10:30] is there a way to make firefox in a snap to use the same mouse pointer as system-wide? [10:32] popey, pstolowski: responded [10:32] thresh: kenvandine would know I suspect [10:33] you can surely fake it if you ship the cursor theme and force theme defaults for your app [10:33] zyga: thanks, interesting (whether the script does the right thing) [10:33] but thats indeed only making it a look-alike and only works as long as the default of the system has not been changed [10:35] pstolowski: fyi. I just did ctrld to exit that thing you had me enter. The second I did that something segfaulted and I lost my entire desktop [10:35] popey: !! [10:35] woot [10:35] can you please collect some logs [10:35] I saw something similar on my machine once [10:35] I was inside a mount namespace entered via nsenter [10:35] well, me being on KDE and using breeze/dark will only make it more complex with firefox being a gtk app [10:36] I hit exit and my desktop blinked [10:36] I was surprised because as far as we're concerned that's just bash quitting [10:36] but at least having the mouse pointer scaled 2x would already help [10:36] popey: sorry! unintended and unexpected [10:36] popey: are you on Wayland? [10:36] thresh, well, my suggestion above would also not scale it ... just set a shipped default so you dont end up with the x11 pointer [10:37] No. X11 [10:37] hmmm [10:37] collect logs please, let's try to understand what crashed [10:38] ogra: thresh mouse cursors are on kenvandine radar [10:38] (though you could probably write a complex wrapper, read the dpi, force the theme up in scale etc etc ... but thats super hackish and pretty overkill) [10:38] (pretty much what ken will eventually do in a clean way as popey says :) ) [10:39] gotcha [10:39] thanks! [10:39] We shouldn't work around this but fix it [10:39] popey, we should ... since 2 years :P [10:39] if only the day had more hours [10:39] http://paste.ubuntu.com/p/sQtP7vmXPY/ [10:39] :D [10:39] Dmesg from my exploded session [10:40] some things crashed on X [10:41] but I suspect X disconnected [10:41] and those things died as a consequence [10:41] popey: can you look for logs of X [10:41] not sure how yet [10:41] Yeah [10:42] pstolowski, hey, [10:42] TBH I'm not sure how X is started or managed nowadays [10:42] hey cachio ! [10:42] pstolowski, did it work the change [10:42] could you try it? [10:43] cachio: I think it didn't, i'm just giving it another try [10:43] for instance it _seems_ that gdb runs everything [10:43] gdm then has gdm-session-worker as a child [10:43] pstolowski, do you have the command line you used to start the vm? [10:44] then gdm-x-session [10:44] perhaps X is hidden there [10:44] cachio: yes i've. let's talk in a private channel [10:44] but no idea really [10:44] popey: can you work with someone from the desktop team to help us understand this, if you can reproduce this the better [10:44] popey: do you have Nvidia drivers? [10:44] I do [10:45] http://paste.ubuntu.com/p/VxM3bjHq3K/ [10:45] Syslog [10:45] popey: I see [10:45] Need to reboot to actually do some work [10:46] Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (**) Option "fd" "84" [10:46] Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (II) event3 - Power Button: device removed [10:46] I think this is udev input triggering [10:46] but no idea why it would happen [10:47] do interfaces still call udevadm tigger ? [10:47] iirc we had some doing that [10:48] Oct 23 11:30:39 hal org.gnome.Shell.desktop[2197]: Window manager warning: last_focus_time (773055215) is greater than comparison timestamp (773055214). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around... [10:48] then all hell breaks loose it seems [10:48] ogra: regardless of what happens in udev - in this case we were not using interfaces [10:48] popey just closed bash [10:48] ouch, ok [10:48] well, i closed the command I had opened in bash [10:49] popey: right [10:49] it should not have happened [10:49] btw, I have the same mouse :) [10:49] :) [10:49] Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) NVIDIA(GPU-0): Failed to acquire modesetting permission. [10:49] this is interesting [10:50] but TBH I think the X + Nvidia combo is something someone needs to look into [10:50] * zyga has no nvidia [10:50] popey: do you think it would help if I had a GPU at home? [10:50] I could stick it into my test desktop for cases like that :/ [10:50] 🤷‍♂️ [10:50] what what nvidia? [10:50] popey: Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information. [10:50] do you still have that log files? [10:50] perhaps X log has more fun stuff [10:51] Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (WW) NVIDIA(0): - Setting a mode on head 0 failed: Insufficient permissions [10:51] Oct 23 11:30:47 hal nautilus[13429]: nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :1. [10:51] so my theory is as follows: [10:51] something is broken in the desktop session and your ctlr+d went to X [10:51] X got nuts and went belly up [10:52] apps died making lots of noise when X disconnected [10:52] I think a test case is to: [10:52] open bash just like you had befor [10:52] (nsenter and such) [10:52] and ctrl+d [10:52] perhaps open the same apps [10:52] not sure if there's a catalyst that makes this happen [10:52] remember when ctrl-c was killing gdm? [10:53] because overzealous input somewhere [10:53] popey: what did you do? [10:54] good question [10:55] PR snapd#6030 opened: cmd/snap: tweak `snap services` output when there is no services [10:55] popey: i mean, what command did you run? i don't see it in the log [10:56] sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt [10:56] so you were root [10:56] and now I have rebooted, the snaps that didn't work, now work [10:56] zyga, popey https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637 [10:56] (not that it would explode because you were root and wrote ctrl+d) [10:56] i cant see that ogra [10:57] * zyga can [10:57] but that was fixed in 2017 [10:57] that was the "ctrl+c (or +d) kills gdm" bug [10:57] that's the bug where Ctrl-c goes to the wrong place [10:57] but [10:57] popey: I'll add you there [10:57] can you read the last few comments [10:58] done [10:58] there's a command [10:58] wait [10:58] 503 [10:58] :/ [10:58] still 503 [10:58] heh, pefect timing [10:59] zyga: btw. that PR ^^ hopefuly Chipaca and degville can help come up with a message that makes sense :) [10:59] popey: ok, as a quick reproduce test [10:59] Note, I haven't restarted my system for 15 days before this happened [10:59] I seem to see all these odd issues because I have "long" uptimes [10:59] stuff seems to get itself well wedged as a result [11:00] popey: run as root: udevdm trigger; udevadm settle --timeout=10 [11:00] this _may_ trigger bad stuff [11:00] so mind the abyss [11:00] then try the nsenter thing again [11:01] I have a feeling we should stop using udev rules for tagging [11:01] and use croups [11:01] cgroups [11:01] croups ? [11:01] moronic spellchecker [11:01] croutons ? [11:01] :) [11:01] cre^p du kernel ;) [11:02] :D [11:02] Yes [11:02] That did bad things [11:02] Desktop exploded [11:02] perfect [11:02] package this in a bug report [11:02] Thanks [11:02] along with system version, the driver you had (version) and perhaps the make of the card [11:03] we will take it from there [11:03] Against gdm3? [11:03] and I'm very sorry for the inconvenience this is causing [11:03] Or snapd [11:03] against snapd first [11:03] Kk [11:03] so that we can alter the status [11:03] we can affect others as we discover [11:03] Will do [11:03] woot! [11:03] Nice one [11:04] * zyga inserts mental model of a plane falling on fire with two engineers watching from the ground, congratulating each other, one saying "woot, you were right, it was the fuel injection pump" [11:04] This is separate from the original issue though, right :) [11:04] "reproduced" [11:04] I think so [11:05] popey: I don't have recent enough hardware but I will see if this happens without nvidia [11:05] and then buy a card for testing [11:05] and upcoming chunk of Nvidia work anwy [11:10] wooot [11:10] reproduced like hell [11:10] popey: no nvidia neede [11:10] we need to get off of udev [11:10] touching udev is bad [11:11] here's my login screen [11:11] I think willcooke is on a sprint now, right? [11:12] https://bugs.launchpad.net/snapd/+bug/1799433 [11:12] Bug #1799433: GNOME desktop on nvidia crashes when exiting nsenter [11:12] popey: funny, in my case something crashed, desktop blinked but my programs were intact [11:12] I logged in and it was back [11:12] hah [11:12] but it's clearly broken [11:12] I am happy for you :) [11:13] OT https://github.com/features/actions [11:14] zyga: see my comment re that problem [11:16] pstolowski: replied [11:16] zyga: ah, sorry, let me remove this not to bring confusion [11:21] zyga: it does not reproduce here, i mean udevadm trigger && settle and nsenter [11:23] zyga: popey: nope, maybe i'm doing something wrong [11:28] mborzecki: we're talking in the #ubuntu-desktop channel as well [11:28] same, I cannot reproduce it again [11:28] maybe I was just very lucky [11:28] (that one time) [11:31] zyga: popey: i'm looking through my irc logs, but i recall we discussed a similar case when udevadm trigger with nvidia would bring down the whole session [11:31] yeah [11:31] mborzecki: note, I was not on nvidia [11:31] this is familiar [11:32] popey: do you remember what that was? [11:32] not without grepping logs [11:33] https://forum.snapcraft.io/t/weird-udev-enumerate-error/2360/9 [11:33] popey: heh, grepping is what i do, i really wish i had that indexed by xapian or sth === chihchun is now known as chihchun_afk [11:50] * zyga lunches [11:52] popey: zyga: i think last time we discussed this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104 [11:52] Bug #1760104: Xorg crashed with SIGSEGV in InputReady() from ospoll_wait() from InputThreadDoWork()

[11:52]

[11:53] off to pick up the kids [11:53] indeed [11:53] interesting [12:21] * pstolowski lunch [12:31] Hi greyback, may I ask if you found the time to identify the cause for the rotation issue in chromium-mir-kiosk (https://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424/87) when rotating mir-kiosk to portrait mode (https://community.ubuntu.com/t/display-configuration-for-mir-kiosk/7815/3)? I'm currently building the snap with an altered i3 config which sets default_orientation = vertical. Does not seem to help, [12:31] except I get a short i3 nagbar “you have an error in your configuration file”, but I cannot figure out what the error is. [12:32] dot-tobias, did you try shipping xrandr and use its rotation feature ? [12:32] dot-tobias: hey, my apologies but I've been focused elsewhere. [12:32] alternatively i think you would actually need a mir config to force the rotation [12:33] https://community.ubuntu.com/t/configuring-mir-kiosk-a-masterclass/8150 [12:33] ogra's idea is worth a try, but I suspect it is i3 itself that isn't dealing with the X display rotation [12:33] alan_g looked into it and it did appear that Xwayland was being correctly told by mir that the display had rotated [12:33] ogra: Not yet, was hoping I could achieve this through config files. Adding a layout for mir-kiosk rotates just fine, but chromium-mir-kiosk (which uses i3) does not pick up on it. [12:33] ouch [12:34] dot-tobias: as (lousy) workaround, could you make i3 size the chromium window in pixels at the size you desire? [12:34] i'll hit that myself soon, working on https://snapcraft.io/magicmirror to build a pre-configured appliance image :) [12:35] greyback: Yeah, that workaround is building right now on my Pi 😊 But good to hear that would actually work. [12:35] uh, you build on your pi ? [12:35]