[06:12] <didrocks> good morning
[06:15] <jibel> salut didrocks , ça va?
[06:17] <didrocks> ça va jibel, et toi ?
[06:17] <jibel> bien bien
[06:38] <jibel> 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] <didrocks> jibel: no, we couldn't do it, unfortunately
[06:39] <didrocks> (because ubiquity marks 2 levels deep as manually installed or something like that)
[06:39] <didrocks> so in the end, to generate the list, it's a manual removal + a manual autoremove
[06:40] <didrocks> and ensuring that the last is updated
[06:40] <didrocks> unsure if people who updated the list follow it though (but the blacklist file used to have a comment for this)
[06:40] <jibel> okay, after installation there 93MB of such packages installed including 2 fonts from bug 1844689
[06:42] <jibel> so these 3 package must be seeded into minimal and -emoji removed from the removal list
[06:42] <jibel> it won't increase the size of the iso because there are already there
[06:42] <jibel> by dependency
[06:56] <oSoMoN> good morning desktoppersr
[06:57] <jibel> didrocks, do you remember if there was any reason to have fonts-noto-color-emoji on the removal list?
[06:57] <jibel> there is no special comment in the seed
[07:16] <seb128> goooood morning desktopers!
[07:16] <didrocks> jibel: I think size/non seen as essential
[07:16] <didrocks> hey oSoMoN, seb128
[07:17] <seb128> lut didrocks oSoMoN jibel, comment ça va aujourd'hui ?
[07:17] <oSoMoN> salut didrocks, seb128, jibel
[07:17] <oSoMoN> ça va bien, et toi seb128 ?
[07:17] <didrocks> seb128: ça va, et toi ?
[07:18] <seb128> en forme, j'ai bien dormi :-)
[07:21] <seb128> oSoMoN, so enigmail is working now, well done!
[07:22] <oSoMoN> seb128, yeah, I'm cleaning up my changes and testing again, I should have something ready for upload during the morning
[07:23] <seb128> great
[07:23] <oSoMoN> 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] <oSoMoN> I've submitted the patch to debian, but we probably want to upload it before they do, to speed things up
[07:24] <oSoMoN> it's a bit annoying that their master branch is protected, I can't submit a merge request targetting it
[07:25] <seb128> right
[07:25] <seb128> oh, why do they do that?
[07:26] <oSoMoN> no idea
[07:26] <oSoMoN> they didn't anticipate than someone outside the webext-team would want to contribute, maybe?
[07:28] <seb128> weird thinking :)
[07:32] <jibel> anyone could review this https://code.launchpad.net/~jibel/ubuntu-seeds/+git/ubuntu/+merge/373181 ?
[07:34] <didrocks> done
[07:35] <didrocks> let's refresh -meta once we have zfs seeded?
[07:35] <didrocks> (as we are in freeze anyway)
[07:35] <jibel> Thank you
[07:42] <willcooke> morning all
[07:42] <oSoMoN> good morning willcooke
[07:43] <didrocks> jibel: updated the FFe, added ubuntu-meta and changed the description as zsys won't be seeded
[07:43] <didrocks> hey willcooke
[07:48] <seb128> hey willcooke, how are you today?
[07:49] <willcooke> hey oSoMoN didrocks seb128
[07:49] <willcooke> Doing ok, it's been raining for days and I like it
[07:49] <seb128> same here, keep raining and the forecast has solid rain for the next 10 days ...
[07:52] <marcustomlinson> morning!
[07:54] <willcooke> hi marcustomlinson
[07:54] <seb128> hey marcustomlinson!
[07:54] <willcooke> seb128, my grass will turn green again
[07:55] <seb128> which means you need to start mowing it again!
[07:56] <willcooke> :) I quite like it really
[08:02] <Laney> yo
[08:02] <willcooke> what up Laney
[08:02] <willcooke> Fun discovery.. the "GNOME Shell locked up on login" issue.    How goes?
[08:04] <clobrano> hey willcooke, I'm fine, how about you? Raining days I read :)
[08:04] <willcooke> yay!
[08:05] <willcooke> Had thunder and lightning yesterday too, always good.
[08:05] <clobrano> :D cool
[08:07] <seb128> hey clobrano!
[08:07] <didrocks> hey Laney
[08:08] <didrocks> & clobrano
[08:08] <clobrano> hey seb128 :)
[08:08] <clobrano> didrocks, :)
[08:08] <Laney> moin willcooke seb128 clobrano didrocks
[08:10] <willcooke> 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] <Laney> want some eyes on the maybe-ubiquity bug?
[08:33] <jibel> yes please
[08:34] <Laney> oh didn't notice seb128 isn't here
[08:35] <Laney> he was looking at it yesterday
[08:40] <ricotz> hello desktopers :)
[08:40] <willcooke> hi ricotz
[08:40] <seb128> hey Rico, how are you?
[08:41] <ricotz> willcooke, seb128, hey
[08:41] <Laney> seb128: did you want some help on the maybe-ubiquity thing?
[08:42] <ricotz> seb128, good, thanks :)
[08:42] <ricotz> seb128, do you have an opinion whether to sync libcloudproviders?
[08:43] <ricotz> pretty safe while there are no rdepends in the archive
[08:45] <oSoMoN> hi ricotz
[08:46] <oSoMoN> 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] <ricotz> oSoMoN, hey
[08:49] <seb128> Laney, yes please, I don't really know how to debug it...
[08:52] <Laney> ok
[09:07] <Trevinho> morning!
[09:13] <oSoMoN> good morning Trevinho
[09:13] <Trevinho> hi oSoMoN
[09:17] <seb128> 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] <seb128> oSoMoN, looking
[09:18] <seb128> hey Trevinho, how are you? so made it back without issue despite french transport rebelions? ;)
[09:19] <ricotz> seb128, don't worry, https://bugs.launchpad.net/ubuntu/+source/libcloudproviders/+bug/1845299
[09:19] <Trevinho> 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] <seb128> ricotz, k, so it's to enable 3rd party softwares?
[09:21] <ricotz> seb128, yes, it is to re-introduce the vala bindings which are available in bionic and dropped with an update
[09:21] <seb128> 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] <seb128> 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] <ricotz> seb128, it is an application in elementary-os
[09:22] <seb128> k
[09:23] <seb128> you should perhaps put that in the ffe rational, might help convincing it has an useful/real case
[09:29] <ricotz> thanks
[09:44] <Laney> seb128: https://paste.debian.net/1102492/ fixes it for me
[09:45] <Laney> except I can't actually interact with the ubiquity that gets launched
[09:45] <Laney> or the rest of the shell, not sure if that's that other bug
[09:45] <Laney> I don't have any really elite tricks though, just that there was a failure of gsd-xsettings in the journal
[09:54] <seb128> 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] <Laney> no you can just restart ubiquity.service from another vt
[09:55] <seb128> Laney, I guess the work/fail race was depending on whether ubiquity-dm would beat the systemd unit in starting it?
[09:56] <seb128> ah
[09:56] <Laney> interesting, I never saw it being racy
[09:56] <seb128> I tried to spawn the ubiquity-dm vt1 :0 ... command and that always worked
[09:56] <seb128> well it's not "racy"
[09:56] <seb128> but it was buggy on the daily iso last week on tuesday
[09:56] <seb128> and worked on the daily from wednesday
[09:56] <seb128> for jibel and for me
[09:57] <Laney> how bizarre
[09:57] <seb128> but on a same iso it would constently work or fail
[09:57] <Laney> don't understand that
[09:57] <seb128> indeed :/
[09:57] <seb128> anyway, I picked the wrong testing command by starting ubiquity-dm rather than the systemd service
[09:57] <seb128> Laney, good work, thanks a lot for stepping in!
[09:58] <Laney> you want to try it and see if it works for you?
[09:58] <seb128> sure, doing that now
[09:58] <Laney> thanks
[09:58] <Laney> it's not really good enough until the shell itself works mind you
[09:59] <seb128> yeah, one step at the time though
[09:59] <seb128> Trevinho, ^ we might need you at this point
[09:59] <seb128> Laney, does the lock look similar to the one willcooke and popey were reporting?
[10:00] <Laney> think so
[10:03] <seb128> 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] <Laney> I was just restarting it
[10:17] <seb128> Laney, sorry stupid VM frozen and then crashed but I'm getting there...
[10:18] <willcooke> thanks for packaging the wallpaper oSoMoN
[10:22] <seb128> 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] <seb128> (that's without having applied the patch yet)
[10:24] <oSoMoN> 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] <seb128> k, got the error this time...
[10:25] <willcooke> oSoMoN, will test
[10:27] <seb128> 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] <seb128> that's in virtualbox
[10:27] <seb128> shell menus also are working
[10:28] <seb128> so yeah, sucess, that's an improvement
[10:29] <Laney> cool
[10:29] <seb128> *no* lock* (sorry)
[10:30] <seb128> those who got the lock, is that qemu/kvm?
[10:30] <seb128> or did anyone got it on real hardware?
[10:31] <seb128> (still needs to be fixed but could hint if it's really a lower stack/driver problem)
[10:32] <Laney> qemu/kvm yes
[10:34] <seb128> k, let me grab some lunch and I do a real hardware try on the inspiron
[10:36] <jibel> i get the same behaviour than Laney with his patch
[10:36] <jibel> the UI starts but is not responsive
[10:44] <willcooke> oSoMoN, there are some 5's left in the contest xml
[10:44] <willcooke> oh
[10:44] <willcooke> ignore
[10:45] <willcooke> thats the transition
[10:56] <oSoMoN> 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] <oSoMoN> deleting my repo and forking it again means I'm now able to submit merge requests
[11:25] <Trevinho> willcooke: you have been able to reproduce that lockup only doing reboots right? not with lock / unlock | logout / relogin?
[11:26] <willcooke> Trevinho, I didnt try lock unlock, I will try it now
[11:29] <Trevinho> willcooke: maybe more login/logout though
[11:29] <Trevinho> 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] <ogra> and try to wiggle the cable too !
[11:30] <Trevinho> well, until the problem isn't in the dri driver ofc
[11:31] <Trevinho> that would... lead to #notforus
[11:37] <Trevinho> oSoMoN: oh, werid... It didn't allow you to MR even doing it manually?
[11:37] <Trevinho> https://salsa.debian.org/osomon-guest/<foooo-project>/merge_requests/new
[11:45] <oSoMoN> Trevinho, nope, it wouldn't allow me to select a target branch outsite my repo
[11:45] <oSoMoN> but deleting the repo and forking it properly fixed it
[11:49] <Laney> 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] <Trevinho> Laney: "cool" :)
[11:51] <Laney> well
[11:51] <Laney> I think it's that bug anyway ¬_¬
[11:51] <Trevinho> Laney: do you have a deb I can use to quickly test that?
[11:52] <Trevinho> or well, is that applied to the iso already?
[11:53] <Laney> no to both
[11:53] <Laney> just install vim and hack /usr/bin/ubiquity-dm, it's only two lines
[11:54] <Trevinho> Laney: okkk, I login, apply, re-login and bug?
[11:55] <Laney> apply, then systemctl restart ubiquity
[12:12] <willcooke> oSoMoN, wallpapers all look good
[12:17] <seb128> oSoMoN, ah, good to know
[12:24] <oSoMoN> willcooke, thanks for testing
[13:31] <oSoMoN> 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] <oSoMoN> I *think* I'm allowed to push to lp:ubuntu-wallpapers, but before I do I wouldn't mind a review
[13:33] <oSoMoN> and I can't upload, so someone will have to sponsor it
[13:42] <Laney> oSoMoN: ok, will look in a bit
[13:42] <seb128> Laney, do you want me to do taht one?
[13:43] <seb128> I think you are busy enough on other things, I'm happy to do that review
[13:43] <Laney> if you know how it's normally done, sure
[13:43] <seb128> I knew but I can refresh that memory by looking at it I think :)
[13:45] <Laney> okey dokey
[13:45] <seb128> cool
[13:48] <seb128> 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] <seb128> oh, but oSoMoN said he could upload so I don't need to be the one merging
[14:06] <Trevinho> willcooke: Laney's reproducer is indeed the same bug, so we've a reproducer
[14:06] <willcooke> woot!
[14:07] <willcooke> I cant get it to fail atm
[14:07] <Trevinho> not so handy to be honest as it needs from live,
[14:09] <seb128> oSoMoN, looks fine to me me, feel free to commit/upload
[14:11] <oSoMoN> seb128, I'll commit but I can'
[14:11] <oSoMoN> can't upload
[14:12] <seb128> weird permissions set
[14:13] <seb128> 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] <Trevinho> sooooooooooooo... The hang, isn't an hang xD
[14:13] <Trevinho> it's a grab somehwere I suppose
[14:14] <Trevinho> now if X11 was so nice to tell us which one...
[14:15] <hellsworth> good morning all
[14:15] <Trevinho> hi hellsworth
[14:15] <seb128> hey hellsworth, how are you today?
[14:16] <seb128> did you manage to fix your laptop/have working wifi again?
[14:27] <hellsworth> i'm ok. just finished reading the backlog :)
[14:27] <seb128> Laney, unping for ubuntu-wallpapers, not needed anymore for good
[14:27] <Laney> thanks!
[14:27] <hellsworth> 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] <seb128> hellsworth, you read IRC day backlog on start of day? brave you!
[14:28] <hellsworth> it's not *that* long
[14:28] <seb128> right
[14:29] <hellsworth> 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] <seb128> 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] <seb128> hellsworth, looks similar
[14:29] <Trevinho> hellsworth: yeah, we got a reproducer now :)
[14:29] <hellsworth> 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] <hellsworth> yeah ok that's great to hear there's a fix!
[14:29] <Trevinho> something is grabbing the screen, and I don't think is the shell though
[14:29] <Trevinho> no fix...
[14:30] <Trevinho> just a way to get it consistently
[14:30] <hellsworth> oh sorry.. reproducer
[14:30] <Trevinho> the sad thing is that I can get only in a temporary vm... so... :/
[14:31] <hellsworth> and you need it on hw? i am happy to try and reproduce on my laptop
[14:31] <seb128> Trevinho, did you try to install ubiquity and start ubiquity.service on a real system?
[14:31] <Trevinho> 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] <Trevinho> seb128: that's what I was trying right now
[14:32] <Trevinho> no luck so far but...
[14:32] <hellsworth> ah ok if you need another person to test, please let me know
[14:32] <seb128> well, it's still unclear but seems report are only from qemu/kvm
[14:32] <seb128> I had no hang in virtualbox
[14:33] <seb128> so maybe need to do a full install in a vm and try then?
[14:33] <Trevinho> seb128: have you tried to follow the reproducer in vbox?
[14:33] <seb128> yes
[14:33] <seb128> it didn't hang
[14:33] <Trevinho> seb128: I mean the l_aney's reproducer
[14:34] <seb128> restarting ubiquity service?
[14:34] <popeycore> willcooke: had that hang again. I was clicking something in chrome, and had lxd building a snap
[14:34] <seb128> or did he get another one?
[14:34] <Trevinho> seb128: yeah, fixing the service, restarting it
[14:34] <popeycore> willcooke: and checked the clock - didnt update at all. it's properly wedged
[14:34] <seb128> yes
[14:34] <seb128> Trevinho, yes, as said no hang in virtualbox
[14:34] <seb128> well I tried only once, but I could click on the installer button
[14:34] <seb128> and do next
[14:34] <seb128> and open shell menus
[14:35] <willcooke> popeycore, ok, might still be related.  T_revinho is working on that atm
[14:35] <seb128> sounds different though, the one from Marco is a grab and the shell isn't frozen
[14:35] <seb128> but who knows
[14:36] <jibel> seb128, Trevinho I can reproduce the issue on bare metal, so it is not specific to qemu
[14:36] <Trevinho> seb128: I'm getting frozen shell on input side only
[14:36] <seb128> jibel, k, good to know
[14:37] <seb128> so it's racy I guess
[14:37] <oSoMoN> Trevinho, I have an eoan VM in virtualbox where I'm frequently seeing the hang on reboot
[14:37] <Trevinho> jibel: sure, sure... Thje problem is not *where*, but how the place is workable/debuggable easier :)
[14:37] <oSoMoN> if I can help
[14:37] <jibel> qemu it is then
[14:37] <seb128> oSoMoN, you got pinged on #ubuntu-release about enigmail btw
[14:37] <Trevinho> 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] <Trevinho> I mean, we're on the same issue
[14:38] <Trevinho> that is a grab causing impossibility to interact with the shell, but it does repainting
[14:38] <seb128> popey's one is probably different since the panel clock isn't updating for him
[14:38] <Laney> one at a time eh
[14:38] <seb128> indeed
[14:38] <Trevinho> :)
[14:38] <seb128> Trevinho, let's focus on the installer one
[14:39] <Trevinho> yep, that's what I'm in
[14:39] <Trevinho> which is also Will's one
[14:39] <seb128> let's fix that and then see if we still have issues
[14:39] <willcooke> good plan
[14:39] <seb128> jibel, what bug did you reproduce on real hardware/how btw?
[14:40] <seb128> just to make sure we are on the same page
[14:40] <popeycore> :+1:
[14:40] <Trevinho> popeycore: anyway just try to see if you can open anything on display from a tty when you get that
[14:41] <jibel> seb128, ubiquity-dm not starting then I cannot even boot to the live session
[14:41] <popeycore> Trevinho: will do next time
[14:41] <popeycore> thanks
[14:41] <popeycore> (I think it's unlikely, looks like it's triggering something deeper like i915 here, so maybe unrelated)
[14:41] <seb128> 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] <seb128> 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] <oSoMoN> 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] <Trevinho> oSoMoN: ok, cool. Yeah, same grabbing issue
[14:45] <Trevinho> if we just had X to let us know who's grabbing...
[14:45] <oSoMoN> Trevinho, let me know if I can help debugging, I can reproduce it fairly reliably
[14:45] <Trevinho> oSoMoN: by luck no Alt+f2 working right? (same for willcooke)
[14:46] <oSoMoN> 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] <Trevinho> seb128: so, running ubiquity in an installed machine doesn't work... As it doesn't if you launch the live from qemu
[14:46] <Trevinho> seb128: maybe using the same kernel option would start though...
[14:47] <Laney> if it's the same as the one I had with the 'is not responding' dialog then you can trigger those easily
[14:47] <Trevinho> Laney: yes it is
[14:47] <Laney> so just make that happen, that breaks the shell for me
[14:48] <Trevinho> 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] <Laney> and I got a bit of a better backtrace on the issue
[14:48] <Trevinho> and.... now I'm out of space :(
[14:48] <Trevinho> Laney: yeah, I also got, but it's definetely not a thread hanging issue
[14:48] <Trevinho> everything is waiting on poll, so all good
[14:49] <Laney> https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607
[14:49] <Laney> different bt there
[14:50] <Trevinho> ah, didn't see that, although might be different
[14:51] <oSoMoN> Trevinho, just reproduced the hang, what do I do to provide useful info?
[14:57] <Trevinho> oSoMoN: well, alt+f2 works in that situation for you?
[14:57] <oSoMoN> Trevinho, nope
[14:57] <oSoMoN> both keyboard and mouse are grabbed, it seems
[14:58] <Trevinho> 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] <Trevinho> test
[14:59] <Trevinho> which is not how i like to work :)
[15:00] <seb128> Trevinho, why don't you debug it with the non-responsive-dialog case on your normal desktop?
[15:00] <oSoMoN> yeah, that's painful, I sympathize
[15:00] <Trevinho> seb128: mh, not sure is the same
[15:00] <Laney> you just said it was
[15:01] <Trevinho> Laney: I said it was the same of your *qemu* reproducer
[15:01] <Trevinho> not that one (which I wasn't either aware of)
[15:01] <Trevinho> till you linekd
[15:01] <Laney> ok, I said "'is not responding' dialog" though
[15:01] <seb128> k, so back at "one at the time, and hopefully they are all fixed with the same change" :)
[15:02] <Laney> I bet 10€ that it is the same one
[15:02] <Trevinho> I wish too, but don't want to play the luck :)
[15:03]  * oSoMoN sees 10€ notes flying left and right
[15:06] <willcooke> ;D
[15:07] <oSoMoN> 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] <Trevinho> oSoMoN: yeah, so the shell does own that...
[15:51]  * Trevinho dances with the guiltyyyy
[15:51] <Trevinho> found what it is at least here
[15:52] <Trevinho> anyone with hanging system here?
[15:53] <Laney> got a VM if that's useful
[15:53] <Trevinho> Laney: at login or as I have?
[15:54] <Laney> the try / install screen
[15:54] <Trevinho> ah ok same as me then
[15:54] <Laney> can SIGSTOP something to get the bad dialog
[15:54] <Trevinho> I think that's another case though
[15:55] <Trevinho> here isn't the shell grabbing
[15:55] <Laney> what's grabbing to display that modal dialog?
[15:56] <Laney> describe the thing you were going to ask someone to do and I'll try it, then we know
[15:56] <Trevinho> Laney: do this xwininfo -root -tree -int when yuo've the grabbed state
[15:57] <Trevinho> we should definetely make ubiquity log with journalctl though instad of using that file...
[15:58] <Laney> ffs
[15:58] <Laney> how often does the window get pinged
[15:58] <Trevinho> iirc  quite often, but don't remmeber the number, altough first time might take a while before alerting you
[15:59] <Trevinho> 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] <Laney> https://paste.ubuntu.com/p/trhPT9TyG6/
[16:00] <Trevinho> Laney: what about alt+f2, super+v?
[16:01] <Laney> run works but it's really slow
[16:01] <Laney> due to shell spamming the cpu I guess
[16:01] <Trevinho> Laney: so yeah, another bug indeed
[16:01] <Trevinho> in that case the shell has the grab, while here anther client has it
[16:08] <Laney> there is no active grab according to XF86LogGrabInfo
[16:08] <Laney> interesting
[16:11] <Trevinho> 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] <Trevinho> willcooke, oSoMoN: I killing ibus-x11 should fix your hang
[16:12] <willcooke> Trevinho, cool, I still cant get it to hang, but I'm still trying
[16:12] <willcooke> yesterday it was 1 in 5, today < 1 in 40
[16:12] <sarnold> 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] <Trevinho> sarnold: doesn't look like that
[16:14] <Trevinho> 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] <sarnold> 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
[16:28] <Laney> gnome-shell did get some changes around restarting ibus this cycle
[16:28] <Laney> and in ubiquity-dm we are starting it before starting gnome-shell
[16:45] <Laney> this bug doesn't happen if you remove starting ibus from ubiquity-dm
[16:45] <Laney> and ibus does still get started
[16:45] <Trevinho> Laney: indeed is a such race, but... that would not fix the case for the desktop
[16:46] <Trevinho> Laney: so we should be better at handling ibus in shell
[16:46] <Trevinho> I've some more progresses, but need to check more
[16:46] <Laney> you think we should continue to start ibus externally?
[16:47] <Trevinho> 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] <Laney> ok, sounded like pushing back on my suggestion, just wanted to clarify
[16:48] <Trevinho> Laney: sure, in the session side though, we also launch it externally these days?
[16:48] <Laney> see bin/ubiquity-dm
[16:49] <Trevinho> 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] <Laney> not that I know, but maybe I don't know
[16:50] <Laney> in my systemd-cgls here it's all from gnome-shell
[16:50] <Trevinho> 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] <Trevinho> ok, so ... well I think what we have in ubiquity is a good test case :)
[16:52] <Trevinho> and.... I think I just saw what's wrong
[16:52] <Laney> very good
[16:53] <Laney> I'm still going to stop ubiquity-dm from doing it, but feel free to supply additional protections
[16:55] <Trevinho> 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] <Laney> only thing I can see is if it gets dbus activated before the shell starts it
[16:57] <Trevinho> which might happen when any other gtk app arrives before
[16:58] <Laney> could do, I'm not sure how early in the sequence gnome-shell is doing this
[16:59] <Trevinho> 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] <Laney> like I say, feel free to fix it
[17:00] <Laney> it'd be good if you are right, because the fix I'm doing doesn't explain the bugs others are seeing
[17:04] <Trevinho> of coruse I'm right :-D
[17:05] <Laney> :-)
[17:13] <Laney> ok, night, got to go hit some sticks with some other sticks
[17:24] <Trevinho> anddddd... fixed :)
[17:40] <Trevinho> willcooke: confirmed your bug is the same I reproduced in the VM... as that is ^
[17:40] <willcooke> \m/
[17:40] <willcooke> Nice work Trevinho
[17:41] <willcooke> I've given up trying to reproduce it
[17:41] <Trevinho> not the same as popey's though :(
[17:41] <Trevinho> that looks more related to the card
[17:41] <willcooke> yeah, his has something to do with lxd IMO
[18:02] <Trevinho> Laney: for tomorrow... https://gitlab.gnome.org/GNOME/gnome-shell/issues/1710
[18:37] <willcooke> Trevinho, I have it in the stuck state
[18:38] <willcooke> alt-f2 doesnt do anything
[18:38] <Trevinho> willcooke: you can free it by tty/ssh to it and killall ibus :)
[18:38] <willcooke> Trevinho, as my normal user?
[18:38] <Trevinho> willcooke: yep
[18:39] <willcooke> $ killall ibus
[18:39] <willcooke> ibus: no process found
[18:39] <willcooke> test@test-Inspiron-3137:~$ ps aux | grep ibus
[18:39] <willcooke> test      1852  0.0  0.2 384588  8288 ?        Sl   19:04   0:00 ibus-daemon --panel disable -r --xim
[18:39] <willcooke> test      1860  0.0  0.1 236476  7148 ?        Sl   19:04   0:00 /usr/lib/ibus/ibus-dconf
[18:39] <willcooke> test      1862  0.0  0.7<PHONE_NUMBER>2 ?        Sl   19:04   0:01 /usr/lib/ibus/ibus-extension-gtk3
[18:39] <willcooke> test      1870  0.0  0.6<PHONE_NUMBER>4 ?        Sl   19:04   0:00 /usr/lib/ibus/ibus-x11 --kill-daemon
[18:39] <willcooke> test      1875  0.0  0.1 236316  7360 ?        Sl   19:04   0:00 /usr/lib/ibus/ibus-portal
[18:39] <willcooke> test      3330  0.0  0.0   9032   980 pts/0    S+   19:38   0:00 grep --color=auto ibus
[18:39] <willcooke> Trevinho, ibus-x11 ?
[18:39] <Trevinho> ibos-daemon
[18:39] <willcooke> kk
[18:39] <willcooke> Trevinho, yay! worked!
[18:39] <Trevinho> willcooke: :)
[18:39] <willcooke> Trevinho, nice one! \m/
[18:39] <Trevinho> I'm proposing the fix upstream right now
[18:39] <Trevinho> well the issue first
[18:40] <willcooke> ace!  Thanks a lot Trevinho
[18:40] <Trevinho> but the code fixing it is already in my diffs
[18:40] <willcooke> and with that, I can call it a night!
[18:40] <Trevinho> :)
[18:40] <willcooke> see you tomorrow gang, when we will no doubt fix another bug :)
[18:40] <Trevinho> we've sooooo many... :-D
[18:41] <willcooke> hehe
[18:41] <willcooke> job for life :)
[18:41] <willcooke> night all
[19:27] <oSoMoN> Trevinho, I know I'm late to the party, just back at the keyboard… one more data point: when I reproduce the grab, killing ibus-daemon seems to indeed release it, but it's not instantaneous, it takes a few secs for it to be released
[19:28] <Trevinho> oSoMoN: yeah, might be because of reloading, but I've just pushed the fix upstream
[19:28] <Trevinho> well proposed upstream
[19:28] <Trevinho> oSoMoN: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/743/diffs
[19:28] <Trevinho> not sure if making a PPA for testing
[19:28] <seb128> oSoMoN, Trevinho, haha, I told Gunnar/here the other day that I was blaming ibus since it started soon after we updated it (and there were some ibus warning in the journal from the first reports)
[19:28] <seb128> Trevinho, well done!
[19:29] <Trevinho> thanks :)
[19:29] <oSoMoN> Trevinho, congrats man, that was a tricky one, and yes a test PPA would be welcome
[19:30] <oSoMoN> I can definitely reproduce reliably the hang, so I could confirm the fix if there were test packages
[20:57] <Trevinho> ok, way time to stop... bug squashed, good night
[21:17] <seb128> Trevinho, 'night!
[21:45] <hellsworth> I need to take off just a bit early today to run an errand before picking up my daughter so see you lovely folks tomorrow!


[02:28] <zykotick9> as an alternative to the current !piracy factoid (which avoids the use of the word "piracy") i propose the following alternative.
 Discussion of copyright infringement and other questionably legal practices are not welcome in the Ubuntu channels. Please take this discussion elsewhere or abstain from it altogether. This includes linking to copyright protected software, music, and video. Also see !guidelines and !o4o
[02:30] <EvilResistance> zykotick9, i think if that were to be used...
[02:31] <EvilResistance> you'd first need to address that if i linked to something like the website for a paid, copyright protected software, saying "YOu need to purchase this in order to get certain functionality you want." then "linking to copyright protected software" is therefore ambiguous
[02:31] <EvilResistance> because the hypothetical situation i just stated would be linking to non-pirated stuff
[02:32] <EvilResistance> !piracy
[02:33] <zykotick9> EvilResistance: your arguing above my proposed change(s) - which is to remove the propaganda terms "piracy" and "pirated"
[02:34] <EvilResistance> i'm going to paste a line in my scrollbacks that pretty much has what i agree with coming from an IRCC member's mouth:
[02:34] <EvilResistance> AlanBell> [02/21/12 13:44:55] zykotick9: I agree with you in principle, but in practice I think the current wording is more useful
[02:35] <EvilResistance> now, i may not be on the IRCC, but i don't see how removing the word "piracy" or "pirated" from the factoid makes it any better
[02:35] <EvilResistance> (all principles aside)
[02:38] <zykotick9> EvilResistance: using "piracy" may infact be more clear to the general public, but being inside this community we should discourage it's use.  piracy on wikipedia (non-disambiguous) is theft on the high seas.
[02:39] <EvilResistance> what about this:
Piracy is the theft or distribution of copywritten, protected software, music, and video, for free use purposes.  Discussion about piracy, and other questionably legal practicies, are not welcome in the Ubuntu channels.  Please take this discussion elsewhere, or abstain from it altogether.  This includes linking to pirated software, music, and video.  Also, see !guidelines and !o4o
[02:40] <EvilResistance> erm...
Piracy is the theft or distribution of copywritten software, music, and video, for free use purposes.  Discussion about piracy, and other questionably legal practicies, are not welcome in the Ubuntu channels.  Please take this discussion elsewhere, or abstain from it altogether.  This includes linking to pirated software, music, and video.  Also, see !guidelines and !o4o
[02:40] <EvilResistance> that even.
[02:40]  * EvilResistance saw an extra comma and 'protected' got into the first one
[02:41] <zykotick9> EvilResistance: as soon as you re-introduce "piracy" you're missing my point entirely.
[02:44] <EvilResistance> zykotick9, oh btw, you know !warez is an alias to !piracy right?  If we redo the entire factoid, the factoid trigger, !piracy, would also need to be changed, no?
[02:53] <zykotick9> EvilResistance: well, as a compromise why not implement changes to the reply, and simply leave !piracy as an alias?  That way one could call !warez, and the word piracy would never be visible.
[02:54] <EvilResistance> we could instead reverse this...
[02:54] <EvilResistance> have your changes be !warez, and have !piracy be an alias to warez
[02:55] <zykotick9> EvilResistance: that would be great, but that's a larger change then i'd initially suggested
[03:06] <EvilResistance> well given this:
[03:06] <EvilResistance> !-warez
[03:06] <EvilResistance> i think that if the aim is to get rid of the word piracy, then removing piracy as the primary factoid is worthwhile
[03:08] <pangolin> all the software in the repos is copyright protected, is it not?
[03:09] <EvilResistance> pangolin, open source stuff is copyrighted?
[03:09] <pangolin> that would make "This includes linking to copyright protected software" in your suggested edit a valid argument to anyone saying you can't link to anything in the ubuntu repos
[03:10] <EvilResistance> that's also a good point
[03:10] <pangolin> open source means you can use/modify/share but it is still owned by someone
[03:10] <EvilResistance> pangolin, you need to check this channel more often :/  you make extremely valid points :P
[03:10] <pangolin> I have moments of lucidity
[03:11] <pangolin> I agree that the current factoid although not perfect is the "best" way to describe the intent of the factoid.
[03:12] <EvilResistance> pangolin, and for argument sake, what about my revision suggestion above, which includes defining piracy in context?
[03:13] <pangolin> Remember we aren't lawyers. We are regular folks trying to protect each other from breaking laws.
[03:13] <EvilResistance> ;P
[03:13] <pangolin> the easiest way is to make it simple to understand
[03:14] <pangolin> this is my personal opinion
[03:31]  * cprofitt blinks
[03:32] <cprofitt> what did I just get in to by reading this
[03:33] <EvilResistance> cprofitt, discussion about how IRC factoids are :P
[03:34] <cprofitt> phew
[03:34] <cprofitt> thought is was a copyright discussion
[03:35] <EvilResistance> cprofitt, nah, but reading your scrollbacks might prove useful
[03:35] <EvilResistance> or checking the logs for the channel
[03:36] <cprofitt> just finished that
[03:37] <cprofitt> was not going to do that if you guys said it was a copyright discussion
[03:37] <cprofitt> in common parlance warez is equated with piracy
[03:38] <cprofitt> I would probably have the same factoid for both
[03:38] <EvilResistance> which is why warez is aliased to piracy
[03:38] <EvilResistance> cprofitt, whatever we do will impact both factoids :/
[03:38] <cprofitt> ture
[03:38] <cprofitt> true
[03:39] <cprofitt> hmm...
[03:39] <cprofitt> wondering how to best word that...
[03:40] <pangolin> common parlance < I like that
[03:41] <cprofitt> I do not think we are actually prohibiting a discussion on copyright infringement
[03:41] <cprofitt> which is what the current factoid says according the scroll back
[03:42] <cprofitt> I also assume linking to copyrighted software is not an issue
[03:42] <cprofitt> the real issue is discussion how to circumvent software copyrights and protections
[03:42] <cprofitt> or rather any copyright or protection for digital content
[03:42] <cprofitt> music, movie or software
[03:45] <cprofitt> can I paste suggested language in here?
[03:45] <cprofitt> or would you prefer a pastebin?
[03:49] <cprofitt> pangolin: http://pastebin.ubuntu.com/852195/
[03:49] <cprofitt> went the safer route
[03:53] <cprofitt> EvilResistance: is that something like what you were looking for?
[03:54] <EvilResistance> ask zykotick9, he started the discussion :P
[04:14] <z3x334u> hey
[04:16] <pangolin> cprofitt: looks ok but I would like to wait to see what the rest of the IRC team thinks.
[04:32] <cprofitt> pangolin: I agree... was just throwing it out there
[04:34] <pangolin> yup :)
[05:17] <tjaalton> hey there, #ubuntu-x is missing ubotu, we'd like it back
[05:19] <pangolin> tsimpson: can you look into this ^
[05:19] <pangolin> tjaalton: when tsimpson wakes up or comes back to life he will fixorz
[05:20] <tjaalton> pangolin: ok, thanks
[07:42] <jussi> jpds: thats ubot4 thats missing
[07:43] <jussi> tjaalton: Ill put ubottu there for now, please alert me or tsimpson when ubot4 comes back (and feel free to boot/quiet ubottu)
[07:43] <jussi> ubottu: join #ubuntu-x
[07:44] <tjaalton> jussi: thanks
[07:54] <Tm_T> hi tj
[08:10] <dholbach> good morning
[16:23] <AlanBell> what
[16:23] <pangolin> bot fight!
[16:24]  * pangolin puts $5 on meetingology
[17:12] <zykotick9> [this will be the last time i suggest this, promise] I think the contents of the !pirate factoid should be changed.  For background as to why, see GNU's List of Words to Void at http://www.gnu.org/philosophy/words-to-avoid.html#piracy  What I'm specifically suggestings: 1) leave !pirate as the factoid's main name 2) leave the various aliases unchanged 3) only change the contents of the factoid to NOT include "pirate" or a conju
[17:13] <zykotick9> Revised_v2
 Discussion of copyright infringement and other questionably legal practices are not welcome in the Ubuntu channels. Please take this discussion elsewhere or abstain from it altogether. This includes linking to copyright infringing software, music, and video. Also see !guidelines and !o4o
[17:14] <Myrtti> you got cut off at "or a conj"
[17:15] <zykotick9> Myrtti: the 1st line ends with "... or a conjugation."  Did you get lines 2 & 3?
[18:16] <Myrtti> zykotick9: I assume so
[18:21] <AlanBell> there is something not quite right about the "copyright infringing software" bit
[18:22] <AlanBell> zykotick9: how about "This includes linking to unauthorised sources of software, music, and video." for that sentence
[20:59] <zykotick9> AlanBell: I think your "unauthorised sources" does sound/read better
[21:05] <AlanBell> !-warez
[21:05] <AlanBell> !-piracy
[21:05] <AlanBell> !piracy
 Discussion of copyright infringement and other questionably legal practices are not welcome in the Ubuntu channels. Please take this discussion elsewhere or abstain from it altogether. This includes linking to unauthorised sources of software, music, and video. Also see !guidelines and !o4o
[21:06] <AlanBell> thoughts on that people?
[21:11] <Fuchs> please not elsewhere on this network ;p
[21:20] <AlanBell> a fair point
[21:24] <marienz> well, "elsewhere" is fine imo
[21:25] <marienz> "not welcome in the Ubuntu channels" might be "not welcome on freenode", but I can see you preferring the current wording
[21:39] <Myrtti> yeah, sadly some of our users don't even know they're on IRC...
[21:39] <UdontKnow> or not welcome in the Ubuntu channels neither allowed by freenode policy
[21:39] <UdontKnow> lots of possible variations there
[21:50] <AlanBell> lets focus for now on the "piracy" terminology
[21:52]  * Fuchs throws Myrtti some yarn and marienz some cookies
[21:52] <marienz> omnomnom
[21:52] <Myrtti> ooo yarn
[23:13] <micahg> bot missing in #ubuntu-packaging
[23:42] <Unit193> jpds: ubot2` missing in #ubuntu-packaging
[23:43] <Unit193> micahg: Thanks for letting them know, hope you have one soon!


[16:30] <ratliff> #startmeeting
[16:30] <meetingology> Meeting started Mon Apr  2 16:30:59 2018 UTC.  The chair is ratliff. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:30] <meetingology> Available commands: action commands idea info link nick
[16:31] <ratliff> The meeting agenda can be found at:
[16:31] <ratliff> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:31] <ratliff> [TOPIC] Announcements
[16:31] <ratliff> Thanks to Simon Quigley (tsimonq2) for providing debdiffs for xenial-artful for atril (LP: #1759069) and
[16:31] <ratliff>  debdiffs for trusty-xenial for kdepim (LP: #1698180)!
[16:32] <ratliff> Thanks to Ray Link (rlink) for providint the debdiff for xenial for xmltooling (LP: #1752306)!
[16:32] <ratliff> or providing it, rather
[16:32] <ratliff> Your work is very much appreciated and will keep Ubuntu users secure.
[16:32] <ratliff> [TOPIC] Weekly stand-up report
[16:33] <ratliff> jdstrand: you're up (if you are around)
[16:33] <jdstrand> I'm here :)
[16:33] <jdstrand> This week I plan to work on:
[16:33] <jdstrand> - address conntrack deprecation issues in ufw for 18.04
[16:33] <jdstrand> - apparmor upload to 18.04 to fix webbrowser-app and mediascanner2 upgrades
[16:33] <jdstrand> - finish up miscellaneous updates branches for snapd
[16:33] <jdstrand> - pick up the snap/usn notification work as have time
[16:33] <jdstrand> that's it from me
[16:34] <ratliff> thanks, jdstrand! m_deslaur is on national holiday today
[16:34] <ratliff> sbeattie: you are up!
[16:34] <sbeattie> I'm in the happy place this week
[16:34] <sbeattie> I'm publishing openjdk packages this morning
[16:34] <sbeattie> There should be kernel USNs to publish later this week, I believe.
[16:35] <sbeattie> I'm still slowly making progress on my gcc retpoline backport for precise
[16:35] <sbeattie> Between that and catching up on a weeks worth of email, that'll probably consume my week.
[16:35] <sbeattie> that's it from me
[16:36] <sbeattie> sarnold: I think you're up?
[16:37] <sarnold> I'm on community this week; I'll start the MIRs with pysmi today, and keep on moving down the line
[16:37] <sarnold> I'm leaning towards accepting openjpeg2; it's still got a long way to go :( but it's come so far and is probably a better jpeg2000 library than what we're already using
[16:37] <sarnold> .. any comments about that would be welcome :)
[16:37] <sarnold> that's it for me, uh .. leosilva?
[16:38] <leosilva> I'm on bug triage
[16:38] <leosilva> I'm hunting this week and researching cves.
[16:38] <ratliff> tons of ruby CVEs about to land, leosilva
[16:38] <leosilva> ratliff: I believe it's back to yo
[16:38] <leosilva> \o/
[16:38] <ratliff> I'm in the happy place this week.
[16:39] <ratliff> My goal is to get the old kpi scripts checked into UCT along with some new kpi scripts and get all of the new kpis converted over to influx
[16:40] <ratliff> Also a ton of internal work.
[16:40] <ratliff> That's it for me.
[16:40] <ratliff> [TOPIC] Highlighted packages
[16:40] <ratliff> The Ubuntu Security team suggests that contributors look into merging Debian security updates in community-supported packages. If you would like to help Ubuntu but are not sure where to start, this is a great way to do so. See http://people.canonical.com/~ubuntu-security/d2u/ for available merges and https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details on preparing Ubuntu security updates. If you have any questions, feel
[16:40] <ratliff> free to ask in #ubuntu-hardened. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:41] <ratliff> [TOPIC] Miscellaneous and Questions
[16:41] <ratliff> Does anyone have any other questions or items to discuss?
[16:42] <ratliff> Quick meeting this week!
[16:43] <ratliff> We are seeing scattered reports of problems with the intel-microcode package. If you are experiencing any difficulties, please add your comments to LP #1760264
[16:45] <ratliff> jdstrand, sbeattie, sarnold, leosilva: Thanks!
[16:45] <ratliff> #endmeeting
[16:45] <meetingology> Meeting ended Mon Apr  2 16:45:13 2018 UTC.
[16:45] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2018/ubuntu-meeting.2018-04-02-16.30.moin.txt
[16:45] <leosilva> thanks ratliff
[16:45] <sarnold> thanks ratliff!
[16:45] <sbeattie> ratliff: thanks!
[16:46] <jdstrand> ratliff: thanks!


[10:49] <xnox> hws, hello
[16:47] <jamespage> rharper, hey - have 5 mins to help me debug a libvirt/qemu problem?
[16:47] <rharper> sure
[16:48] <jamespage> rharper, ok - so I nearly have instances booting under openstack - they do the normal startup -> paused whilst the networking is all being setup...
[16:48] <jamespage> but then nova unpauses them and they just go straight to shutdown - not quite sure how to debug what's going on
[16:49] <rharper> that's nova state saying shutdown ?
[16:49] <rharper> versus actual console log ?
[16:49] <jamespage> rharper, no that virsh list --all
[16:49] <rharper> libvirt will always start the guest in stop mode (-S); then when all devices are attached, libvirt will send the cont signal to start the qemu machine
[16:49] <jamespage> nova reflects that once it notices it
[16:50] <jamespage> rharper, so I see
[16:50] <jamespage>  -     instance-00000006              shut off
[16:50] <jamespage> type stuff from virsh
[16:50] <rharper> do we have the machine qemu.log file ?
[16:51] <jamespage> rharper, the qemu log file for the instance - 2016-04-08T16:42:22.595065Z qemu-system-s390x: terminating on signal 15 from pid 260989
[16:51] <rharper> that's likely to have info on why libvirt wants to shut it down
[16:51] <rharper> ah
[16:51] <jamespage> rharper, http://paste.ubuntu.com/15692628/
[16:51] <rharper> i bet it's misconfigured and qemu is aborting
[16:51] <rharper> can you enable libvirtd debugging and get a log from there?
[16:52] <jamespage> rharper, I have the daemon running with the -v flag
[16:52] <rharper> lemme get you a decent log config for libvirtd (less you have the qemu exec bits in our output)
[16:53] <rharper> is that paste from your debug output or the instance.log file from var/lib/libvirt/qemu/$machine_instance.log
[16:53] <rharper> I'm looking to see if qemu spit anything out on stderr
[16:55] <jamespage> rharper, from the instance log file
[16:55] <rharper> hrm, ok
[16:56] <rharper> jamespage: I'm playing with the command line invoccation on another s390x box to see what qemu says;
[16:57] <jamespage> rharper, okies - I can give you access to this one if you like
[16:57] <rharper> sure