=== siel_ is now known as siel [06:12] good morning [06:15] salut didrocks , ça va? [06:17] ça va jibel, et toi ? [06:17] bien bien [06:38] didrocks, when doing an ubuntu-minimal installation, there is no autoremoval of packages marked as automatically installed and not required anymore at the end? [06:38] jibel: no, we couldn't do it, unfortunately [06:39] (because ubiquity marks 2 levels deep as manually installed or something like that) [06:39] so in the end, to generate the list, it's a manual removal + a manual autoremove [06:40] and ensuring that the last is updated [06:40] unsure if people who updated the list follow it though (but the blacklist file used to have a comment for this) [06:40] okay, after installation there 93MB of such packages installed including 2 fonts from bug 1844689 [06:40] bug 1844689 in ubiquity (Ubuntu) "Emoji fonts not included in the Desktop minimal installs" [High,New] https://launchpad.net/bugs/1844689 [06:42] so these 3 package must be seeded into minimal and -emoji removed from the removal list [06:42] it won't increase the size of the iso because there are already there [06:42] by dependency [06:56] good morning desktoppersr [06:57] didrocks, do you remember if there was any reason to have fonts-noto-color-emoji on the removal list? [06:57] there is no special comment in the seed === pstolowski|afk is now known as pstolowski [07:16] goooood morning desktopers! [07:16] jibel: I think size/non seen as essential [07:16] hey oSoMoN, seb128 [07:17] lut didrocks oSoMoN jibel, comment ça va aujourd'hui ? [07:17] salut didrocks, seb128, jibel [07:17] ça va bien, et toi seb128 ? [07:17] seb128: ça va, et toi ? [07:18] en forme, j'ai bien dormi :-) [07:21] oSoMoN, so enigmail is working now, well done! [07:22] seb128, yeah, I'm cleaning up my changes and testing again, I should have something ready for upload during the morning [07:23] great [07:23] seb128, note that this requires a fixed version of mozilla-devscripts that includes https://salsa.debian.org/osomon-guest/webext-devscripts/commit/7334f1e320269fc29cb23b47408466e14b4da019 [07:24] I've submitted the patch to debian, but we probably want to upload it before they do, to speed things up [07:24] it's a bit annoying that their master branch is protected, I can't submit a merge request targetting it [07:25] right [07:25] oh, why do they do that? [07:26] no idea [07:26] they didn't anticipate than someone outside the webext-team would want to contribute, maybe? [07:28] weird thinking :) [07:32] anyone could review this https://code.launchpad.net/~jibel/ubuntu-seeds/+git/ubuntu/+merge/373181 ? [07:34] done [07:35] let's refresh -meta once we have zfs seeded? [07:35] (as we are in freeze anyway) [07:35] Thank you [07:42] morning all [07:42] good morning willcooke [07:43] jibel: updated the FFe, added ubuntu-meta and changed the description as zsys won't be seeded [07:43] hey willcooke [07:48] hey willcooke, how are you today? [07:49] hey oSoMoN didrocks seb128 [07:49] Doing ok, it's been raining for days and I like it [07:49] same here, keep raining and the forecast has solid rain for the next 10 days ... [07:52] morning! [07:54] hi marcustomlinson [07:54] hey marcustomlinson! [07:54] seb128, my grass will turn green again [07:55] which means you need to start mowing it again! [07:56] :) I quite like it really [08:02] yo [08:02] what up Laney [08:02] Fun discovery.. the "GNOME Shell locked up on login" issue. I shut the lid on it last night, and opened it again this morning, and now Shell is ALIVE! [08:03] hey Laney, how is the rain going? [08:03] but bluetooth isnt working now [08:03] :/ [08:03] good morning everyone 0/ [08:04] hey clobrano! How goes? [08:04] hey willcooke, I'm fine, how about you? Raining days I read :) [08:04] yay! [08:05] Had thunder and lightning yesterday too, always good. [08:05] :D cool [08:07] hey clobrano! [08:07] hey Laney [08:08] & clobrano [08:08] hey seb128 :) [08:08] didrocks, :) [08:08] moin willcooke seb128 clobrano didrocks [08:10] Trevinho, in case this is useful... http://paste.ubuntu.com/p/dS6SmX5sFQ/ logs from waking up the machine this morning. Given that Shell came back to life, it does feel a bit like its something lower in the stack, like you said yesterday [08:27] want some eyes on the maybe-ubiquity bug? [08:33] yes please [08:34] oh didn't notice seb128 isn't here [08:35] he was looking at it yesterday [08:40] hello desktopers :) [08:40] hi ricotz [08:40] hey Rico, how are you? [08:41] willcooke, seb128, hey [08:41] seb128: did you want some help on the maybe-ubiquity thing? [08:42] seb128, good, thanks :) [08:42] seb128, do you have an opinion whether to sync libcloudproviders? [08:43] pretty safe while there are no rdepends in the archive [08:45] hi ricotz [08:46] seb128, uploads for mozilla-devscripts and enigmail are ready at https://people.canonical.com/~osomon/enigmail-2.1.2/, would you mind sponsoring them? [08:48] oSoMoN, hey [08:49] Laney, yes please, I don't really know how to debug it... [08:52] ok [09:07] morning! [09:13] good morning Trevinho [09:13] hi oSoMoN [09:17] ricotz, hey, sorry I was otp, no opinion on libcloudproviders, I don't even know where it's used and what the bindings would enable [09:17] oSoMoN, looking [09:18] hey Trevinho, how are you? so made it back without issue despite french transport rebelions? ;) [09:19] seb128, don't worry, https://bugs.launchpad.net/ubuntu/+source/libcloudproviders/+bug/1845299 [09:19] Launchpad bug 1845299 in libcloudproviders (Ubuntu) "FFe: Sync libcloudproviders 0.3.0-3 (universe) from Debian unstable (main)" [Undecided,New] [09:19] seb128: hey, all good... sure, sure... a part few protesters chants, at 18 I was already sitting to finish work at my desk :-) [09:20] ricotz, k, so it's to enable 3rd party softwares? [09:21] seb128, yes, it is to re-introduce the vala bindings which are available in bionic and dropped with an update [09:21] Laney, thx for proposing to help on the ubiquity thing, let me know if you find an angle to be able to debug, I'm interested to learn pro tricks :) (casper-bottom stop is kind of limited, I guess respinning an ISO with tweaked packages would give more debug info but is also non trivial/I don't know how to do that easily) [09:22] ricotz, right, but those have no rdepends in archive right ... I'm just curious what softwares use it outside Ubuntu? is that closed source ones? [09:22] seb128, it is an application in elementary-os [09:22] k [09:23] you should perhaps put that in the ffe rational, might help convincing it has an useful/real case [09:29] thanks [09:44] seb128: https://paste.debian.net/1102492/ fixes it for me [09:45] except I can't actually interact with the ubiquity that gets launched [09:45] or the rest of the shell, not sure if that's that other bug [09:45] I don't have any really elite tricks though, just that there was a failure of gsd-xsettings in the journal [09:54] Laney, good one, I saw the xsetting warning but didn't think it would make ubiquity-dm exit this way ... how did you test that the fix works? casper-bottom live hacking? [09:55] no you can just restart ubiquity.service from another vt [09:55] Laney, I guess the work/fail race was depending on whether ubiquity-dm would beat the systemd unit in starting it? [09:56] ah [09:56] interesting, I never saw it being racy [09:56] I tried to spawn the ubiquity-dm vt1 :0 ... command and that always worked [09:56] well it's not "racy" [09:56] but it was buggy on the daily iso last week on tuesday [09:56] and worked on the daily from wednesday [09:56] for jibel and for me [09:57] how bizarre [09:57] but on a same iso it would constently work or fail [09:57] don't understand that [09:57] indeed :/ [09:57] anyway, I picked the wrong testing command by starting ubiquity-dm rather than the systemd service [09:57] Laney, good work, thanks a lot for stepping in! [09:58] you want to try it and see if it works for you? [09:58] sure, doing that now [09:58] thanks [09:58] it's not really good enough until the shell itself works mind you [09:59] yeah, one step at the time though [09:59] Trevinho, ^ we might need you at this point [09:59] Laney, does the lock look similar to the one willcooke and popey were reporting? [10:00] think so [10:03] Laney, so going to a vt and doing a sudo systemctl restart ubiquity.service should be enough or do I need to tear down the previous session first in some way? [10:03] I was just restarting it [10:17] Laney, sorry stupid VM frozen and then crashed but I'm getting there... [10:18] thanks for packaging the wallpaper oSoMoN [10:22] or not, wth, one boot gave me a live session instead of the dm/error and next one gave me the gdm greeter [10:23] (that's without having applied the patch yet) [10:24] willcooke, yw! I haven't actually tested the package yet, it just finished building in https://launchpad.net/~osomon/+archive/ubuntu/eoan-wallpapers/+packages in case you want to try it yourself [10:25] k, got the error this time... [10:25] oSoMoN, will test [10:27] Laney, k, patches makes ubiquity start fine and I clicked 'install Ubuntu' which did bring me to the keyboard selection screen (so lock on that try apparently) [10:27] that's in virtualbox [10:27] shell menus also are working [10:28] so yeah, sucess, that's an improvement [10:29] cool [10:29] *no* lock* (sorry) [10:30] those who got the lock, is that qemu/kvm? [10:30] or did anyone got it on real hardware? [10:31] (still needs to be fixed but could hint if it's really a lower stack/driver problem) [10:32] qemu/kvm yes [10:34] k, let me grab some lunch and I do a real hardware try on the inspiron [10:36] i get the same behaviour than Laney with his patch [10:36] the UI starts but is not responsive [10:44] oSoMoN, there are some 5's left in the contest xml [10:44] oh [10:44] ignore [10:45] thats the transition [10:56] seb128, I figured out why I couldn't submit a merge request targetting webext-devscripts on salsa: I had pushed my branch directly under my osomon-guest login, instead of forking the repo first [10:57] deleting my repo and forking it again means I'm now able to submit merge requests [11:25] willcooke: you have been able to reproduce that lockup only doing reboots right? not with lock / unlock | logout / relogin? [11:26] Trevinho, I didnt try lock unlock, I will try it now [11:29] willcooke: maybe more login/logout though [11:29] so far I can't reproduce it in a vmware virtual machine (that using mesa stack, should not really much different from real hw) [11:30] and try to wiggle the cable too ! [11:30] well, until the problem isn't in the dri driver ofc [11:31] that would... lead to #notforus [11:37] oSoMoN: oh, werid... It didn't allow you to MR even doing it manually? [11:37] https://salsa.debian.org/osomon-guest//merge_requests/new [11:45] Trevinho, nope, it wouldn't allow me to select a target branch outsite my repo [11:45] but deleting the repo and forking it properly fixed it [11:49] Trevinho: I can make that bug happen every time using qemu if I boot an ISO and apply that proposed patch of mine to fix the session https://paste.debian.net/1102492/ [11:50] Laney: "cool" :) [11:51] well [11:51] I think it's that bug anyway ¬_¬ [11:51] Laney: do you have a deb I can use to quickly test that? [11:52] or well, is that applied to the iso already? [11:53] no to both [11:53] just install vim and hack /usr/bin/ubiquity-dm, it's only two lines [11:54] Laney: okkk, I login, apply, re-login and bug? [11:55] apply, then systemctl restart ubiquity [12:12] oSoMoN, wallpapers all look good [12:17] oSoMoN, ah, good to know [12:24] willcooke, thanks for testing [13:31] Laney, would you mind doing a quick sanity check on my ubuntu-wallpapers changes? https://code.launchpad.net/~osomon/ubuntu-wallpapers/eoan-community-wallpapers/+merge/373202 [13:32] I *think* I'm allowed to push to lp:ubuntu-wallpapers, but before I do I wouldn't mind a review [13:33] and I can't upload, so someone will have to sponsor it [13:42] oSoMoN: ok, will look in a bit [13:42] Laney, do you want me to do taht one? [13:43] I think you are busy enough on other things, I'm happy to do that review [13:43] if you know how it's normally done, sure [13:43] I knew but I can refresh that memory by looking at it I think :) [13:45] okey dokey [13:45] cool [13:48] Laney, well that's assuming you are busy, but if you are done with other things and want to sneak it in between because you know exactly what to look for that's fine too, just let me know [13:49] * seb128 stupidely underestimated the size of the vcs, I'm on 3g atm, looks like checkout is going to take a while :/ [14:05] oh, but oSoMoN said he could upload so I don't need to be the one merging [14:06] willcooke: Laney's reproducer is indeed the same bug, so we've a reproducer [14:06] woot! [14:07] I cant get it to fail atm [14:07] not so handy to be honest as it needs from live, [14:09] oSoMoN, looks fine to me me, feel free to commit/upload [14:11] seb128, I'll commit but I can' [14:11] can't upload [14:12] weird permissions set [14:13] Laney, I did the review but I'm on sucky internet, can you just do the bzr-buildpackage --source && dput step when you have some time? (or I do it later once I'm back to a faster connection) [14:13] sooooooooooooo... The hang, isn't an hang xD [14:13] it's a grab somehwere I suppose [14:14] now if X11 was so nice to tell us which one... [14:15] good morning all [14:15] hi hellsworth [14:15] hey hellsworth, how are you today? [14:16] did you manage to fix your laptop/have working wifi again? [14:27] i'm ok. just finished reading the backlog :) [14:27] Laney, unping for ubuntu-wallpapers, not needed anymore for good [14:27] thanks! [14:27] yeah so my laptop wifi works only on the 2.4GHz band. the strength is usable but not great (16Mb/s when it should be 250) [14:28] hellsworth, you read IRC day backlog on start of day? brave you! [14:28] it's not *that* long [14:28] right [14:29] also i think i've seen the lock/unlock bug.. or similar. i've noticed that sometimes when i boot my system and log in, my mouse works but i can't click anything and keyboard doesn't work - is this the same thing yall are talking about? [14:29] I sometime do read irclogs.ubuntu.com logs for the 10 past days when I'm back for holidays, that can take a while :) [14:29] hellsworth, looks similar [14:29] hellsworth: yeah, we got a reproducer now :) [14:29] well i'm also new, so it's helpful to see what everyone's chatting about to get a feel for the daily issues [14:29] yeah ok that's great to hear there's a fix! [14:29] something is grabbing the screen, and I don't think is the shell though [14:29] no fix... [14:30] just a way to get it consistently [14:30] oh sorry.. reproducer [14:30] the sad thing is that I can get only in a temporary vm... so... :/ [14:31] and you need it on hw? i am happy to try and reproduce on my laptop [14:31] Trevinho, did you try to install ubiquity and start ubiquity.service on a real system? [14:31] hellsworth: no, a vm is fine, but here I can get only in a vm that is run in live mode... so... a bit annoying [14:32] seb128: that's what I was trying right now [14:32] no luck so far but... [14:32] ah ok if you need another person to test, please let me know [14:32] well, it's still unclear but seems report are only from qemu/kvm [14:32] I had no hang in virtualbox [14:33] so maybe need to do a full install in a vm and try then? [14:33] seb128: have you tried to follow the reproducer in vbox? [14:33] yes [14:33] it didn't hang [14:33] seb128: I mean the l_aney's reproducer [14:34] restarting ubiquity service? [14:34] willcooke: had that hang again. I was clicking something in chrome, and had lxd building a snap [14:34] or did he get another one? [14:34] seb128: yeah, fixing the service, restarting it [14:34] willcooke: and checked the clock - didnt update at all. it's properly wedged [14:34] yes [14:34] Trevinho, yes, as said no hang in virtualbox [14:34] well I tried only once, but I could click on the installer button [14:34] and do next [14:34] and open shell menus [14:35] popeycore, ok, might still be related. T_revinho is working on that atm [14:35] sounds different though, the one from Marco is a grab and the shell isn't frozen [14:35] but who knows [14:36] seb128, Trevinho I can reproduce the issue on bare metal, so it is not specific to qemu [14:36] seb128: I'm getting frozen shell on input side only [14:36] jibel, k, good to know [14:37] so it's racy I guess [14:37] Trevinho, I have an eoan VM in virtualbox where I'm frequently seeing the hang on reboot [14:37] jibel: sure, sure... Thje problem is not *where*, but how the place is workable/debuggable easier :) [14:37] if I can help [14:37] qemu it is then [14:37] oSoMoN, you got pinged on #ubuntu-release about enigmail btw [14:37] basically to verify we're on the same page... from a tty/ssh just try run DISPLAY=:0 gedit if that opens works [14:37] I mean, we're on the same issue [14:38] that is a grab causing impossibility to interact with the shell, but it does repainting [14:38] popey's one is probably different since the panel clock isn't updating for him [14:38] one at a time eh [14:38] indeed [14:38] :) [14:38] Trevinho, let's focus on the installer one [14:39] yep, that's what I'm in [14:39] which is also Will's one [14:39] let's fix that and then see if we still have issues [14:39] good plan [14:39] jibel, what bug did you reproduce on real hardware/how btw? [14:40] just to make sure we are on the same page [14:40] :+1: [14:40] popeycore: anyway just try to see if you can open anything on display from a tty when you get that [14:41] seb128, ubiquity-dm not starting then I cannot even boot to the live session [14:41] Trevinho: will do next time [14:41] thanks [14:41] (I think it's unlikely, looks like it's triggering something deeper like i915 here, so maybe unrelated) [14:41] jibel, what happen when you can't boot to the live session? or do you get it but can't interact with the session? [14:42] jibel, the issue we are speaking about is after applying the ubiquity fix from L_aney which fixes the -dm loading, then you can't interact with the -dm dialogs/menus [14:44] Trevinho, I was testing the ubuntu-wallpapers update in that eoan VM earlier, I set the slideshow wallpaper and changed the duration to 5 secs for each wallpaper to better visualize it, and after a reboot of the VM mouse clicks and keyboard interaction didn't work, but the wallpapers were changing as expected, so repainting works as you stated [14:44] oSoMoN: ok, cool. Yeah, same grabbing issue [14:45] if we just had X to let us know who's grabbing... [14:45] Trevinho, let me know if I can help debugging, I can reproduce it fairly reliably [14:45] oSoMoN: by luck no Alt+f2 working right? (same for willcooke) [14:46] also, I think I left the VM running in the background for some time, so the lock screen kicked in, and unlocking worked and the grab was gone [14:46] seb128: so, running ubiquity in an installed machine doesn't work... As it doesn't if you launch the live from qemu [14:46] seb128: maybe using the same kernel option would start though... [14:47] if it's the same as the one I had with the 'is not responding' dialog then you can trigger those easily [14:47] Laney: yes it is [14:47] so just make that happen, that breaks the shell for me [14:48] Laney: sure, it does here as well, but to debug properly I preferred to have a consistent place instead that have to reload the machine [14:48] and I got a bit of a better backtrace on the issue [14:48] and.... now I'm out of space :( [14:48] Laney: yeah, I also got, but it's definetely not a thread hanging issue [14:48] everything is waiting on poll, so all good [14:49] https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607 [14:49] different bt there [14:50] ah, didn't see that, although might be different [14:51] Trevinho, just reproduced the hang, what do I do to provide useful info? [14:57] oSoMoN: well, alt+f2 works in that situation for you? [14:57] Trevinho, nope [14:57] both keyboard and mouse are grabbed, it seems [14:58] oSoMoN: yeah, same that happens here, so need to hack JS code to see where this is triggering, and that's what I'm doing here, but a bit slowly as I need to prepare things locally, upload to the VM and... [14:58] test [14:59] which is not how i like to work :) [15:00] Trevinho, why don't you debug it with the non-responsive-dialog case on your normal desktop? [15:00] yeah, that's painful, I sympathize [15:00] seb128: mh, not sure is the same [15:00] you just said it was [15:01] Laney: I said it was the same of your *qemu* reproducer [15:01] not that one (which I wasn't either aware of) [15:01] till you linekd [15:01] ok, I said "'is not responding' dialog" though [15:01] k, so back at "one at the time, and hopefully they are all fixed with the same change" :) [15:02] I bet 10€ that it is the same one [15:02] I wish too, but don't want to play the luck :) [15:03] * oSoMoN sees 10€ notes flying left and right [15:06] ;D [15:07] Trevinho, and I confirm that after letting the lockscreen kick in, the grab is gone [15:08] * oSoMoN goes to PTA meeting, laterz [15:08] oSoMoN: yeah, so the shell does own that... [15:51] * Trevinho dances with the guiltyyyy [15:51] found what it is at least here [15:52] anyone with hanging system here? [15:53] got a VM if that's useful [15:53] Laney: at login or as I have? [15:54] the try / install screen [15:54] ah ok same as me then [15:54] can SIGSTOP something to get the bad dialog [15:54] I think that's another case though [15:55] here isn't the shell grabbing [15:55] what's grabbing to display that modal dialog? [15:56] describe the thing you were going to ask someone to do and I'll try it, then we know [15:56] Laney: do this xwininfo -root -tree -int when yuo've the grabbed state [15:57] we should definetely make ubiquity log with journalctl though instad of using that file... [15:58] ffs [15:58] how often does the window get pinged [15:58] iirc quite often, but don't remmeber the number, altough first time might take a while before alerting you [15:59] Laney: when you've a grabbed dialog, see if alt+f2 works for you, but in any case tell me the of windows [16:00] https://paste.ubuntu.com/p/trhPT9TyG6/ [16:00] Laney: what about alt+f2, super+v? [16:01] run works but it's really slow [16:01] due to shell spamming the cpu I guess [16:01] Laney: so yeah, another bug indeed [16:01] in that case the shell has the grab, while here anther client has it [16:08] there is no active grab according to XF86LogGrabInfo [16:08] interesting [16:11] Laney: so what makes the grab in the installer case is ibus-x11, but still I don't know exactly what part of it [16:11] willcooke, oSoMoN: I killing ibus-x11 should fix your hang [16:12] Trevinho, cool, I still cant get it to hang, but I'm still trying [16:12] yesterday it was 1 in 5, today < 1 in 40 [16:12] Trevinho, I haven't got a clue what you're doing, but I'm wondering if this is related? https://usn.ubuntu.com/4134-2/ [16:13] sarnold: doesn't look like that [16:14] Laney: so... it's a compartecipation of shell and ibus, not making the shell to load ibus stuff doesn't cause the issue as well, so I supposeee.. that it's like we're running ibus too early whent the shell has not the grab control yet and ibus takes it... [16:14] Trevinho: alright, cool; good luck, happy bug hunting :) [16:15] * Trevinho is happy to be able to just do a rsync to test his shell changes at least :P === pstolowski is now known as pstolowski|afk [16:28] gnome-shell did get some changes around restarting ibus this cycle [16:28] and in ubiquity-dm we are starting it before starting gnome-shell [16:45] this bug doesn't happen if you remove starting ibus from ubiquity-dm [16:45] and ibus does still get started [16:45] Laney: indeed is a such race, but... that would not fix the case for the desktop [16:46] Laney: so we should be better at handling ibus in shell [16:46] I've some more progresses, but need to check more [16:46] you think we should continue to start ibus externally? [16:47] Laney: nope, I'm not saying this, we can indeed make the shell do it, but still the shell should be stronger if this doesn't happen, as few changes to the shell also make this not happen too [16:48] ok, sounded like pushing back on my suggestion, just wanted to clarify [16:48] Laney: sure, in the session side though, we also launch it externally these days? [16:48] see bin/ubiquity-dm [16:49] Laney: yeah, I saw that (and I had to hack it to my shell to run), but what I'm saying is that: are we running it externally also in normal sessions, right? [16:50] not that I know, but maybe I don't know [16:50] in my systemd-cgls here it's all from gnome-shell [16:50] cause this is definetely a race right now, so we need to make sure we handle the race in both cases, not assuming that we only run properly with no ibus [16:51] ok, so ... well I think what we have in ubiquity is a good test case :) [16:52] and.... I think I just saw what's wrong [16:52] very good [16:53] I'm still going to stop ubiquity-dm from doing it, but feel free to supply additional protections [16:55] Laney: indeed, that's fine, but I need it not to do it yet as I think it would fix the issue on session side [16:56] only thing I can see is if it gets dbus activated before the shell starts it [16:57] which might happen when any other gtk app arrives before [16:58] could do, I'm not sure how early in the sequence gnome-shell is doing this [16:59] Laney: consider that if we make react gnome-shell keyboard later to the ibus connection this issue disappear, so I mean... This is supposed not to happen anyways [16:59] like I say, feel free to fix it [17:00] it'd be good if you are right, because the fix I'm doing doesn't explain the bugs others are seeing [17:04] of coruse I'm right :-D [17:05] :-) [17:13] ok, night, got to go hit some sticks with some other sticks [17:24] anddddd... fixed :) [17:40] willcooke: confirmed your bug is the same I reproduced in the VM... as that is ^ [17:40] \m/ [17:40] Nice work Trevinho [17:41]