[00:37] <kgunn> robert_ancell: on the reporting stuff...here http://unity.ubuntu.com/mir/component_reports.html
[00:37] <kgunn> so lttng obviously needs lttng
[00:37] <kgunn> but for handlers "log"
[00:38] <kgunn> does that just get written out to a file ?
[00:39] <robert_ancell> kgunn, I think you need to run it with --glog for the logs to go to glog then you can set --glog-stderrthreshold to have them go to stderr or --glog-log-dir to change where the log files go
[00:39] <robert_ancell> I haven't mastered the logging commands yet though
[00:40] <kgunn> robert_ancell: yeah...it says you can define an envrion variable
[00:40] <kgunn> to turn it on...which i assume means like "export MIR_SERVER_DISPLAY_REPORT=log"
[00:41] <robert_ancell> kgunn, you can set any of the flags to mir by using MIR_SERVER_* environment variables, e.g. MIR_SERVER_GLOG_LOG_DIR=/tmp/logs
[00:41] <robert_ancell> yep, that would be the equivalent of --display-report=log
[00:41] <kgunn> robert_ancell: can that be post server launch ?...or will i need to reboot ?
[00:42] <robert_ancell> kgunn, env variables need to be defined before server launch
[00:42] <robert_ancell> kgunn, you can set them in /etc/environment if you want them universally applied
[00:42] <kgunn> like in a pref file ?
[00:42] <kgunn> oh...
[00:43] <robert_ancell> kgunn, or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf and set unity-compositor-command as you like if you're testing the whole stack
[00:56] <kgunn> robert_ancell: huh...so i tried to alter envirnonment on the nexus4...but no matter what nano just won't write out the change
[00:56] <kgunn> ever experienced anything like that on n4 ?
[00:56] <kgunn> i root shell...
[00:56] <kgunn> oops/i/i am
[00:57] <robert_ancell> write out what change?
[00:57] <robert_ancell> oh, editing the file?
[00:57] <robert_ancell> what does mount say?
[00:57] <kgunn> robert_ancell: correct...trying to add GLOG.... & MIR_....
[00:58] <kgunn> robert_ancell: mount says a bunch...so i guess it depends...
[00:58] <robert_ancell> try 'touch /etc/blah' and see if it throws an error
[00:58] <kgunn> alot of "rw"'s
[01:00] <kgunn> robert_ancell: touch worked...chmod worked....
[01:00] <robert_ancell> kgunn, nano fail?
[01:00] <robert_ancell> try cat > /etc/...
[01:00] <robert_ancell> :)
[01:02] <kgunn> weird...so "cat > /etc/environment" just sat there...
[01:02] <kgunn> no output
[01:03] <kgunn> but i definitely see the file when i open with nano
[01:03] <robert_ancell> kgunn, that overwrites the file
[01:03] <kgunn> and i can ctl-O to write out...but then, it prompts what file name to save under...and it simply won't accept "enter"
[01:03] <robert_ancell> then type the contents and press ctrl+d to end
[01:39] <RAOF> robert_ancell: Morning.
[01:39] <robert_ancell> RAOF, hey
[01:44] <RAOF> Hrm. Why doesn't that hit the assert()
[01:49] <kgunn> RAOF: hope bkfst was good (something unhealthy like eggs and bacon)
[01:49] <RAOF> It did include bacon, yes :)
[01:49] <RAOF> Pan-baked eggs with bacon and sausage and onion and such.
[01:53] <kgunn> yum
[02:10] <robert_ancell> RAOF, so what's the plan? Are there some specific bugs you are working on?
[02:11] <RAOF> So, at least one of the bugs is that we're not updating what Intel thinks the front buffer is.
[02:11] <RAOF> That's causing at least *some* of the crashes after resolution change.
[02:11] <robert_ancell> RAOF, this is in Mir?
[02:11] <RAOF> This is in XMir.
[02:12] <RAOF> My plan is to work on XMir + Intel until I can do resolution & layout changes and it doesn't crash.
[02:14] <robert_ancell> ok
[03:09] <kgunn> robert_ancell: well...i added MIR_SERVER_GLOG_LOG_DIR=/tmp/logs & MIR_SERVER_DISPLAY_REPORT=log....but nothing showing up in /tmp/ ?
[03:09] <robert_ancell> kgunn, did you do MIR_SERVER_ENABLE_GLOG=1?
[03:10] <robert_ancell> kgunn, rather MIR_SERVER_GLOG=1?
[03:10] <kgunn> doh!
[03:17] <duflu> That sounds quite overcomplicated to me
[03:17] <kgunn> hmm  still no joy
[03:18] <kgunn> robert_ancell: actually would it be MIR_SERVER_GLOG_LOG=1 ?
[03:19] <robert_ancell> kgunn, mir_demo_server --help shows it is '--glog', so it should be MIR_SERVER_GLOG
[03:19] <robert_ancell> kgunn, have you tried setting MIR_SERVER_GLOG_MINLOGLEVEL?
[03:19] <robert_ancell> I had the same frustrations using the logging myself
[03:20] <kgunn> robert_ancell: actually...that's a good idea...i should get familiar on pc first before phone
[03:20] <robert_ancell> though --help seems to imply minloglevel is set to a valid default
[03:20] <duflu> Hmm, if Mir is logged to unity-system-compositor.log already, why don't we start logging useful stuff by default?
[03:22] <duflu> ... I mean at least "Mir has started successfully and is using these monitors with resolutions... Listening on socket /tmp/mir_socket"
[03:24] <RAOF> That would be moderately useful, yes.
[03:24] <kgunn> robert_ancell: duflu RAOF ....i think i'm gonna go to bed early...and get up really early...like 4 or 5 am
[03:24] <robert_ancell> kgunn, later
[03:24] <robert_ancell> duflu, that would be super useful
[03:25] <kgunn> just not sure when everyone plans to eod...but if it all ends before i get on...can the last man standing write a handoff email....where we're at, what's worthy to test, what the balance of problems is etc.
[03:25] <duflu> kgunn: OK, later
[03:27] <robert_ancell> kgunn, sure
[03:31] <RAOF> kgunn: See you later.
[03:37] <duflu> Wow, qa-testing is better now. Just with ugly frame scheduling/damage glitches
[03:44] <duflu> I'm not even sure how it's possible to get the kind of small horizontal line artefacts I see though
[03:54] <duflu> Actually there seem to be some frame scheduling problems in qa-testing2, just much less often
[04:05] <robert_ancell> duflu, have you found anything in the bypass branch that may be causing problems?
[04:05] <duflu> robert_ancell: Nothing bypass-specific yet. All the bugs I've seen happen on qa-testing2 (just take longer)
[04:08] <duflu> robert_ancell: It's extra hard to test things when a recent MM commit broke fingerpaint :/
[04:09] <duflu> Maybe fingerpaint is to blame. Don't know
[05:10] <RAOF> Bah. The xf86 cursor code would really like HW cursor stuff.
[05:27] <duflu> Why does MM look so flawless for demo_server_client? Where are the bugs that XMir triggers?... :(
[05:27] <duflu> *demo_server_shell
[05:28] <robert_ancell> ok, I'm calling it a night - duflu, RAOF, please remember last one here to send out an email update. Thanks!
[05:35] <duflu> RAOF: When you talk about receiving buffer fd's from the server, that's in-protocol, right? Not on the side channel...
[05:45] <RAOF> duflu: Correct
[05:52] <tvoss_> duflu, ping
[05:52] <duflu> tvoss_, pong
[05:55] <duflu> RAOF: Sanity check: qa-testing{,2} are different in that "2" has no bypass, right?
[05:59] <RAOF> duflu: qa-testing might be a couple of Xserver revisions behind, too.
[06:00] <RAOF> I've only been pushing to qa-testing2
[06:01] <duflu> Except this morning, which is why I tested qa-testing
[06:01] <RAOF> Yeah, accidentally :)
[06:02] <tvoss_> RAOF, are you using swap_buffer_sync or swap_buffer nakedly?
[06:02] <RAOF> tvoss_: swap_buffer nakedly.
[06:02] <tvoss_> interesting, sam reports issues with that
[06:05] <RAOF> Oh, really? What issues?
[06:06] <duflu> RAOF: https://bugs.launchpad.net/bugs/1216337
[06:06] <RAOF> Ah, that one.
[06:07] <duflu> RAOF: Ooooh, doing native GBM you have a hardware buffer being swapped using the software swap_buffers call I guess. I wonder if we handle that correctly
[06:07] <RAOF> Oh, no. A new appearance of the same symptom.
[06:07] <RAOF> software swap_buffers call?
[06:08] <duflu> RAOF: Yes mir_surface_swap_buffers* is usually for software only surfaces
[06:08] <RAOF> It's also what EGL uses to implement eglSwapBuffers, though.
[06:08] <RAOF> It's the only way to get a frame to Mir.
[06:09] <duflu> RAOF: Yeah should be. Just theorizing
[06:56] <RAOF> Woot!
[06:56] <RAOF> We have a successful layout change with gnome-control-centre
[06:57] <duflu> RAOF: "We" ? :)
[06:58] <RAOF> I
[06:58] <RAOF> Ok, that's really weird.
[06:58] <RAOF> Mir has stuck the surface in the wrong place :)
[07:02] <RAOF> tvoss_: Huh. Looks like it was indeed just the software cursor code being hateful.
[07:10] <duflu> OK, my brain is fried and I'm also out of essentials such as... food. So I'm off to the supermarket for a while.
[07:10] <RAOF> duflu: Have fun.
[07:10] <RAOF> You might be able to test something that works when you return.
[07:10] <RAOF> At least on the XMir side.
[07:10] <RAOF> And for values of "works" equal to "doesn't crash horribly as soon as you touch the layout"
[07:13] <tvoss_> RAOF, \o/, uploaded to the ppa, yet?
[07:14] <RAOF> xserver MM11 just uploaded.
[07:14] <tvoss_> RAOF, does that require an updated intel driver?
[07:14] <RAOF> Yes, if you want it to work.
[07:15] <tvoss_> RAOF, ack, I guess mm11 needs to finish compiling first
[07:15]  * tvoss_ grabs a quick breakfast
[07:15] <RAOF> Yup.
[07:32] <tvoss_> RAOF, the xserver build for i386 hangs on xfvb
[07:32] <RAOF> Grr.
[07:32] <RAOF> Someone's going to have to work out what's happening there.
[07:34] <RAOF> tvoss_: Build retried.
[08:32] <tvoss_> RAOF, the 64bit build in the ppa hangs again
[08:36] <tvoss_> quick restart
[08:49] <tvoss_> RAOF, would it make sense to just disable the xvfb test in the ppa for now?
[08:50] <RAOF> Yeah, it probably would.
[08:50] <tvoss_> RAOF, hitting refresh to check the build is a bit tedious
[08:52] <tvoss_> RAOF, does mm12 require a new intel driver?
[08:53] <RAOF> Nope.
[08:53] <RAOF> It just fixes the crash on startup in mm11 that I introduced by testing a subtly different change locally.
[08:54]  * RAOF prepares to crash his unity-system-compositor by unplugging his HDMI output
[08:55] <RAOF> Huh. Didn't crash (yet)
[08:56] <duflu> RAOF: Yeah the Mir server seems to survive hotplugging fine. Even if you don't get to use the new monitors
[09:01] <RAOF> mlankhorst: I don't suppose you're seeing the xvfb-run test hang all the goddamned time in the xserver builds you're doing?
[09:03] <tvoss_> RAOF, just remove it from the ppa version for now
[09:04] <RAOF> Yeah, done in mm13
[09:05] <tvoss_> RAOF, ack, moving over to the new house, back in a few minutes
[09:07] <duflu> RAOF: Does XMir use buffer age?
[09:07] <RAOF> Yes
[09:08] <duflu> I wonder if we're messing that up somehow
[09:08] <duflu> ... in the server
[09:10] <mlankhorst> RAOF: only 50% of the time
[09:11] <RAOF> mlankhorst: Yeah :/
[09:21] <kgunn> hey fellas
[09:21] <mlankhorst> RAOF: might fail on virt only though
[09:21] <RAOF> kgunn: Good morning. Sleep well?
[09:22] <RAOF> mlankhorst: Yeah, maybe. I haven't been tracking that.
[09:22] <duflu> kgunn: Hi. You could sleep more :)
[09:22] <kgunn> uh-oh
[09:22] <RAOF> Well, until https://launchpad.net/~mir-team/+archive/qa-testing2/+build/4904608 finishes building.
[09:22] <kgunn> :)
[09:23] <kgunn> time enough to make a coffee
[09:24] <duflu> I have real food I can cook tonight. Wonder if I will get to...
[09:25]  * RAOF is just eating some real food.
[09:25] <duflu> Oooh, Sam reports similar lag issues and apparently also relies on buffer age
[09:38] <duflu> RAOF: If we get as far is the frame scheduling being the _only_ problem, can you try ignoring buffer age?
[09:38] <duflu> *as far as
[09:38] <RAOF> Yes
[09:38] <RAOF> (radeon and nouveau already do)
[09:38] <RAOF> Or, rather, fail to act on it.
[09:39] <duflu> ... because the only two clients which use buffer age are the only two clients reporting lag/ordering problems
[09:39] <RAOF> Heh.
[09:39] <RAOF> Huzzah!
[09:39] <duflu> Maybe
[09:40] <RAOF> qa-testing2 now has all the things!
[09:40] <duflu> Cool
[09:43] <kgunn> cool....
[09:47] <duflu> Oooh, gnome-control-centre multi-monitor joy without crashes :)
[09:48] <RAOF> Yay!
[09:48] <RAOF> I shall now do some much-delayed housework in the form of some washing up.
[09:50] <tvoss_> RAOF, duflu back
[09:51] <kgunn> hey tvoss_
[09:51] <kgunn> RAOF: sweet....i just hdmi hotplugged/connect-disconnect 8 times....survived all....just once it didn't scale right
[09:52] <kgunn> getting somewhere :)
[09:55] <tvoss_> kgunn, please try layout changes, too
[09:55] <tvoss_> via the control center
[09:56] <duflu> It seemed to work, but then bug 1216522
[09:56] <kgunn> woooo-hoooo!!! was just doing that...hdmi extended desktop working & hotplugged
[09:57] <kgunn> wooohoo....and dropping the built-in display  off works!
[09:58] <tvoss_> duflu, for https://code.launchpad.net/~vanvugt/mir/distinguish-crtc-exceptions/+merge/181947
[09:58] <tvoss_> duflu, are we sure that the type is usable as an array index? cannot tell from the mp
[09:59] <duflu> tvoss_: Yes copied from the header where they are #defined 0 .. 14
[09:59] <tvoss_> duflu, ack
[09:59] <tvoss_> duflu, which header is that?
[09:59] <tvoss_> want to note it down in my review comment
[10:00] <duflu> tvoss_: It's mentioned in the proposal diff , but /usr/include/xf86drmMode.h
[10:01] <tvoss_> duflu, top-approved
[10:04] <kgunn> tvoss_: RAOF duflu ok...this is really robust...i've not been punted t to the greeter at all....i used hdmi, then i switched to vga, hotplugging all the way, mirror/extended/dropped builtin display....all of works
[10:05] <kgunn> even moved the 2nd display virtually
[10:05] <duflu> kgunn: Yeah it's better but I hung X pretty quickly. Meanwhile USC kept running smoothly
[10:06] <kgunn> duflu: :(
[10:06] <RAOF> duflu: Stop trying to rotate :)
[10:07] <duflu> RAOF: I did no such thing
[10:08] <kgunn> RAOF: i tried to rotate actually....didn't work...but x did not crash
[10:09] <kgunn> trying reboot scenarios now
[10:09] <RAOF> Yeah, I haven't hooked up any of the shadow alloc stuff that's necessary for rotation.
[10:09] <RAOF> If I understand it correctly that *shouldn't* be hard.
[10:10] <kgunn> RAOF: we can survive CFT w/o that...i'm sure some one somewhere relies on it...but hey..this is prebeta baby
[10:10] <RAOF> …having just spent a weekend finding that the goddamned software cursor code dies if you don't dance around it perfectly.
[10:12] <kgunn> RAOF: yeah...now i see how folks like you become experts in x...lots..& lots of scar tissue
[10:12] <duflu> OK, I need to get some proper food sorted. Till tomorrow...
[10:12] <kgunn> duflu: later
[10:12] <RAOF> duflu: Eat well!
[10:12] <tvoss_> duflu, till tomorrow
[10:20] <kgunn> RAOF: tvoss_ nice work guys....this is so robust...i'm gonna upgrade on my primary machine...
[10:20] <kgunn> it has display port...so technically one more phys connector type
[10:21] <kgunn> was just telling voss....i've only managed  to crash x one time....and i'm being pretty damn mean to it
[10:22] <kgunn> probably would've crashed in standalone x
[10:24] <kgunn> robotfuel: there's no way your on...but if you're gonna do some work on sunday afternoon, qa-testing2 worthy of a run on the anointed 8 or 9
[10:26] <RAOF> As long as they're all intel - patches for nouveau & ati are pending :)
[10:26] <kgunn> RAOF: i'm all intel....all the time baby
[10:28] <kgunn> RAOF: so was duflu on nouveau (when he managed to "crash his x pretty quickly")
[10:28] <kgunn> ...having a hard time seeing crashing it quickly...
[10:29] <kgunn> ok...bbiab/rebooting to mm
[10:40] <mlankhorst> kgunn: might depend on graphcis card
[10:46] <kgunn> mlankhorst: ack that
[10:53] <kgunn> RAOF: tvoss_ ...so this is intersting....i'm on displayport/hdmi...extended desktop, i put my console in 2nd display...i run openarena...
[10:54] <RAOF> ...and?
[10:54] <kgunn> first i noticed...its totally unhinged...both high & low res going about 100fps
[10:55] <kgunn> i'm guessing its cpu or shader limited (obviously not pixels:)
[10:55] <kgunn> second thing....it takes me out of extended mode....but correctly changes the settings too....i need to test on standalone X
[10:55] <kgunn> maybe this is correct behavior
[10:56] <RAOF> Yeah, openarena is going to try and set the mode (if you're running it fullscreen)
[10:56] <RAOF> Nice that it works :)
[10:57] <kgunn> what was nice...after loading qa-testing2...i had some old display settings (extended & 2nd screen on left hand side instead of right)
[10:58] <kgunn> and it just worked!
[10:58] <kgunn> i can't wait for ancell to load this into the anointed machines in lexington
[10:59] <kgunn> RAOF: why does openarena become unhinged from vsync here ?
[11:00] <RAOF> kgunn: Because that's unimplemented; it's always been unhinged from vsync
[11:01] <kgunn> RAOF: not so my friend....when i disconnect the cable...i drop back down to ~60fps
[11:01] <kgunn> i just did it
[11:01] <RAOF> And you're running XMir?
[11:01] <kgunn> RAOF: hmmm....could it be in mirror mode...
[11:01] <RAOF> Are you sure?
[11:02] <kgunn> that the game has 2 buffers to draw into...so for ~every frame in single screen mode...he's counting 2 ?
[11:03] <kgunn> RAOF: damn it...rookie...i know for sure it was xmir on the second machine...i just took it for granted on this one...
[11:04] <kgunn> RAOF: even tho its X....that's still weird
[11:04] <kgunn> unless my theory of 2 fb being available in one frame render is why...
[11:05] <kgunn> RAOF: at least i know how X should behave :)
[11:05] <RAOF> Hm, don't know :)
[11:06] <tvoss_> kgunn, details, perhaps we can file a bug about it
[11:06] <kgunn> tvoss_: yep..something to chase up with michael
[11:06] <tvoss_> kgunn, michael?
[11:07] <kgunn> ok...rebooting to mm for reals (michael=phoronix)
[11:13] <kgunn> RAOF: tvoss_ ...any of you see the return of the lag?... or kind of, its not global... extended desktop irc in one display..terminal in the other
[11:13] <kgunn> irc has no lag...but terminal does
[11:13] <kgunn> lag=typing letter showing up
[11:13] <RAOF> kgunn: Yeah, duflu was also seeing that (as am I) - https://bugs.launchpad.net/bugs/1216337
[11:35] <tvoss_> kgunn, RAOF duflu had the idea that it might be related to buffer age
[11:39] <kgunn> ok...so for sure i'm xmir-mm...re-ran openarena....
[11:39] <kgunn> if i'm extended desktop...it treats the 2 displays like 1 surface (i see some render no one screen and some of the other)
[11:40] <kgunn> and it runs at like 25 fps
[11:40] <kgunn> if i go to mirror mode....it runs at like 125 fps
[11:41] <kgunn> and if i turn off one monitor....the benchmark tries to run, but complains about the video mode and "ends prematurely"
[12:00] <kgunn> RAOF: pastebin.canonical.com/96338/....x crash while turning off second display & going between mirror/extended
[12:00] <kgunn> EQ overflow (event queue ?)
[12:03] <kgunn> actually this is consistent...have hdmi connected, extended desktop, turn off the second display via settings...x crash
[14:29] <robotfuel> kgunn: are you around? did you want me to start a test run on qa ppa2 now?
[17:56] <xnox> I am using intel graphics, yet when switching to mir, lightdm crashes and I have to comment out "#type=unity"
[17:56] <xnox> is there any way i can fix that?
[22:56] <robert_ancell> thomi, is there a way to know who started a jenkins job?
[22:57] <thomi> robert_ancell: in the job run page, it says "started by <username>"
[22:57] <thomi> robert_ancell: in the private server anyway, I think that information is stripped on the public instance
[22:58] <robert_ancell> thomi, right, so on http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/1/ where would I see that?
[22:58]  * thomi looks
[22:58] <robert_ancell> thomi, ah I got it
[22:58] <thomi> yeah, it was started by an upstream job
[22:58] <robert_ancell> because that job was started by the main job I needed to click that
[22:58] <robert_ancell> It was started by Chris
[22:58] <thomi> right, was started by chris
[22:59] <robert_ancell> They all failed, I'm just wondering if I should be worried by that or it was some sort of test run to check the config was working
[23:04] <RAOF> kgunn: Hm. Your “EQ overflow” crash is because Mir isn't responding to a message (again ☹)
[23:33] <RAOF> Has anyone tested qa-testing2 against nouveau or radeon? I'm just interested to know if my patches work :)
[23:35] <robert_ancell> RAOF, what's the focus next? ati/nouveu or the lag issue?
[23:37] <RAOF> Fixing the client-buffer-tracker MP, then probably lag. I don't have the hardware available to test MM on ati or nouveau.
[23:40] <kgunn> RAOF: robert_ancell can run it against the boston 8
[23:41] <robert_ancell> kgunn, it's running qa-testing2 now
[23:41] <kgunn> RAOF:also that EQ overflow only happened once that i caught
[23:41] <kgunn> every other time....the xorg log just ends....are post-config
[23:41] <kgunn> but no error complaint
[23:41] <kgunn> robert_ancell: ack
[23:41] <kgunn> fingers crossed
[23:42] <robert_ancell> thomi, it looks like a failure, but I'm not deciphering the build log - http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/2/console
[23:42] <RAOF> In my experience the Xorg log just ending tends to be unity-system-compositor dying, and one of the mirclient threads noticing then throwing an exception.
[23:42]  * thomi looks
[23:42] <RAOF> Of course, because it's on a thread it gets logged nowhere.
[23:42] <robert_ancell> "Build step 'Execute shell' marked build as failure"
[23:43] <robert_ancell> 2013-08-25 23:18:32,372 ssh DEBUG: SSH command (/usr/share/utah/client/utah-done.py) failed with return code: 4
[23:43] <robert_ancell> this might be it
[23:43] <thomi> robert_ancell: right, it looks to me like the actual test failed
[23:43] <thomi> no
[23:44]  * thomi curses utah
[23:44] <robert_ancell> oh, is it just polling utah - nasty!
[23:45] <thomi> robert_ancell: if you look at how it's configured, it runs:
[23:45] <thomi> run_utah_tests.py -d -m physical --name "$machine" -i "$ISO" -p "$PRESEED_FILE" -l $WORKSPACE master.run || RETCODE=1
[23:45] <thomi> in the log you can see "RETCODE=1"
[23:45] <thomi> so run_utah failed
[23:46]  * thomi tries to find out why
[23:52] <thomi> robert_ancell: it's odd - it looks like the tests are running, because I can see FPS results from the openarena run, but something else is failing
[23:52] <thomi> but utah is frustratingly useless - gah
[23:59] <thomi> robert_ancell: the nearest I can make out, the final command in the test script is failing, that is:
[23:59] <thomi> xrandr | grep -i xmir
[23:59] <thomi> which I assume is there to make sure we're running xmir
[23:59] <thomi> so possibly that's the issue here