[09:17] <Saviq> tsdgeos, fyi: I've a surprise National Holiday today ;)
[09:18] <tsdgeos> Saviq: cool!
[09:18] <tsdgeos> surprsise holidays ftw!
[09:18] <tsdgeos> enjoy :-)
[09:19] <tsdgeos> mzanetti: you back today or tomorrow?
[09:23] <Saviq> mzanetti, tomorrow
[09:23] <Saviq> tsdgeos, rather ↑
[09:23] <tsdgeos> oka
[09:23] <tsdgeos> tx
[09:44] <nic-doffay> tsdgeos, commented back https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
[09:46] <tsdgeos> nic-doffay: null doing what/when¿
[09:54] <nic-doffay> tsdgeos, if you remove that alias searchHistory doesn't get passed through properly to the page header.
[09:55] <tsdgeos> nic-doffay: hwo do i test it?
[09:59] <nic-doffay> tsdgeos, if you remove that ill alias you'll see in the output...
[09:59] <nic-doffay> It will complain about the "count" variable in the PageHeader
[10:00] <dednick> Is jenkins down?
[10:00] <tsdgeos> may be
[10:00] <tsdgeos> read somewhere about "friday issues"
[10:00] <tsdgeos> or something
[10:02] <tsdgeos> nic-doffay: i din't see any count warning when searching and that line removed
[10:02] <tsdgeos> nic-doffay: can you be a bit more precise on what you do exactly and what exactly you get as warning?
[10:08] <nic-doffay> tsdgeos, I get this when I remove that line and attempt a search from the Apps http://pastebin.ubuntu.com/6398871/
[10:10] <tsdgeos> right
[10:10] <tsdgeos> silly me
[10:11] <tsdgeos> need to try in the apps scope if want to test dashapps code :D
[10:13] <nic-doffay> tsdgeos, at first I assumed the same as you about this. What would be the need for the alias?
[10:21] <tsdgeos> nic-doffay: looks like a Qt bug to me, maybe related to https://bugreports.qt-project.org/browse/QTBUG-30493
[10:22] <tsdgeos> nic-doffay: can you add acomment saying "FIXME this shouldn't be neeed but without it the property is not correctly propagated to the PageHeader, check with newer Qt if it can be removed"
[10:22] <tsdgeos> or something like that?
[10:23] <nic-doffay> tsdgeos, sure
[10:25] <mzanetti> Saviq: tsdgeos: tomorrow
[10:25] <tsdgeos> mzanetti: oka, enjoy!
[10:26] <mzanetti> tsdgeos: meh... have to drive from italy to germany today :/ not too much fun
[10:29] <tsdgeos> dednick: yeah according to #ubuntu-ci-eng "All services are down" :D
[10:30] <dednick> tsdgeos: ah :)
[10:47] <tsdgeos> dednick: about https://code.launchpad.net/~nick-dedekind/unity8/lp1249369/+merge/194540
[10:47] <tsdgeos> can the if (searchContainer.popoverShouldOpen) { searchContainer.openPopover(); } checks move to inside openPopoever itself?
[10:51] <dednick> tsdgeos: no, because we want calls to openPopover to always open it.
[10:51] <dednick> tsdgeos: the check is only for the delay caused by the animation.
[10:51] <tsdgeos> i see
[10:52] <dednick> tsdgeos: otherwise if we call something that causes the open animation to run, then explicitly call closePopover, it will close and the open again once the animation is coplete
[10:52] <tsdgeos> looks a bit prone to breaking, like we may forget the check when it's needed somewhen
[10:52] <tsdgeos> but we have the unittests to catch that hopefully :D
[10:53] <dednick> tsdgeos: hm. let me check if i can make it better. Maybe explicitly stop the open animation when calling close
[10:53] <tsdgeos> dednick: nah it's ok
[10:53] <tsdgeos> dednick: though this is a bit confusing though
[10:53] <tsdgeos> if (!searchContainer.popoverShouldOpen) { searchContainer.closePopover(); }
[10:54] <dednick> tsdgeos: yeah, i know.
[10:54] <tsdgeos> in my mind a variable named "popoverShouldOpen" shouldn't control the closing :D
[10:55] <tsdgeos> dednick: maybe a simple comment may help on why those are needed there?
[10:55] <tsdgeos> or?
[11:22] <dednick> tsdgeos: would you prefer to flags? popoverShouldOpen/popoverShouldClose ?
[11:23] <dednick> s/to/two
[11:23] <tsdgeos> dednick: probably nto since they would have the same value all the time, no?
[11:23] <dednick> it's somewhat more accutate
[11:23] <dednick> tsdgeos: opposite values
[11:24] <tsdgeos> hmmm
[11:24] <tsdgeos> don't know tbh
[11:25] <dednick> tsdgeos: ok. i'll sort it out. actually i dont think they will always be opposite, so may be best to have both.
[11:25] <tsdgeos> oki ;.)
[11:25] <tsdgeos> tx
[11:26] <tsdgeos> sorry for being a bit obnoxious
[11:26] <dednick> tsdgeos: :) np
[12:00] <dednick> tsdgeos: you're LVWPH bug man right? :)
[12:00] <tsdgeos> that's what they say
[12:01] <dednick> tsdgeos: https://bugs.launchpad.net/unity8/+bug/1237942
[12:02] <tsdgeos> let me see if i can repro
[12:03] <tsdgeos> meanwhile i'm waiting on 6 reviews
[12:03] <tsdgeos> if anyone could take one...
[12:03] <tsdgeos> https://code.launchpad.net/~aacid/unity8/killApplicationsFilterGrid.qml/+merge/194511 should be easy
[12:03] <tsdgeos> same for https://code.launchpad.net/~aacid/unity8/noModelInSignal/+merge/194672
[12:03] <nic-doffay> Can anyone confirm if jenkins is having issues?
[12:03] <dednick> it's actually fairly easy to see the bug in the code, but it's a bit complicated just for me to jump into without most likely breaking it ;)
[12:04] <tsdgeos> nic-doffay: it's down yes
[12:06] <tsdgeos> dednick: well m_firstVisibleIndex should never be 0 if m_visibleItems is empty
[12:06] <tsdgeos> seems like that is the case in your backtrace
[12:06] <dednick> tsdgeos: yep
[12:11] <tsdgeos> dednick: and of course i can't reproduce
[12:12] <dednick> tsdgeos: http://pastebin.ubuntu.com/6399365/
[12:12] <dednick> growDown=true, so m_firstVisibleIndex does not get set to -1
[12:12] <tsdgeos> meh
[12:12] <tsdgeos> ok let's read the code if i can't repro
[12:14] <tsdgeos> dednick: does this help? http://paste.ubuntu.com/6399373/
[12:16] <tsdgeos> probably not
[12:17] <dednick> tsdgeos: nope
[12:17] <tsdgeos> dednick: http://paste.ubuntu.com/6399392/ ?
[12:18] <tsdgeos> that one oughta be better
[12:20] <dednick> tsdgeos: yeah, that worked
[12:20] <dednick> tsdgeos: can remove the check above to set -1.
[12:20] <tsdgeos> ok now we need a test case :D
[12:20] <tsdgeos> dednick: which check? the one in the other function?
[12:20] <dednick> oh right you did.. nvm
[12:21] <tsdgeos> ah the one a few lines above
[12:21] <tsdgeos> yeah i did
[12:38] <tsdgeos> dednick: ?
[12:38] <dednick> eh?
[12:38] <tsdgeos> what you mean with single line commit message
[12:38] <dednick> i'm sure we were asked to only use a single line for commit?
[12:38] <tsdgeos> nope
[12:38] <tsdgeos> we were asked to use a "git-like" commit message
[12:38] <tsdgeos> i.e.
[12:38] <tsdgeos> single line
[12:38] <tsdgeos> empty line
[12:38] <tsdgeos> longer stuff if we need it
[12:39] <dednick> Oh. right
[12:41] <tsdgeos> dednick: can you do a quick test? can you uncomment the //     qDebug() << "ListViewWithPageHeader::onModelUpdated" << changeSet << reset;
[12:41] <tsdgeos> in ListViewWithPageHeader::onModelUpdated to make sure you are getting the removes and the insert at the same time?
[12:42] <tsdgeos> dednick: you may need to comment changeset since it is silly and doesn't know how to print it even if the header says it knows
[13:01] <dednick> tsdgeos: nope. different
[13:03] <dednick> tsdgeos: not sure i enjoy your cavalier usage of first() without checks ;)
[13:03] <dednick> it makes me sweat
[13:58] <tsdgeos> dednick: well, there *is* a check ;-)
[13:59] <tsdgeos> that is the m_firstVisibleIndex :D
[14:14] <tsdgeos> dednick: i need you to add a few more debugs
[14:14] <tsdgeos> dednick: can you help me?
[14:19] <tsdgeos> dednick: i need to know why growDown is true, is it that item is null or that item is culled?
[14:30] <tsdgeos> dednick: standtup?
[14:38] <MacSlow> nic-doffay, your mumble working
[14:41] <tsdgeos> Cimi: ok, while dednick doesn't come back with the info let's have a look at that inversemousearea thing
[14:41] <tsdgeos> Cimi: what's the problem exactly
[14:41] <tsdgeos> Cimi: i.e. what do i do to repro?
[14:41] <Cimi> tsdgeos, apply that pastebin
[14:41] <Cimi> tsdgeos, run an app
[14:41] <Cimi> tsdgeos, ener termination mode
[14:41] <Cimi> *enter
[14:42] <Cimi> tsdgeos, tap anywhere inside the running applications grid and you see "pressed" on console
[14:42] <Cimi> tsdgeos, tap outide - nothing
[14:44] <tsdgeos> Cimi: do you have something that can be tested on the desktop?
[14:44] <MacSlow> Cimi, tsdgeos, dandrader: did the IP of s-jenkins change again?
[14:44] <Cimi> tsdgeos, you can test that
[14:44] <tsdgeos> MacSlow: it's dead jum
[14:44] <MacSlow> tsdgeos, *sigh* thx
[14:44] <tsdgeos> s/jum/jim
[14:44] <Cimi> tsdgeos, you need xdv dirs
[14:44] <tsdgeos> MacSlow: well not dead, they're moving the metal it seems
[14:45] <MacSlow> tsdgeos, ok
[14:45] <tsdgeos> Cimi: ¿?
[14:45] <Cimi> tsdgeos, hodl on
[14:45] <Cimi> tsdgeos, XDG_DATA_DIRS=tests/mocks/data/:$XDG_DATA_DIRS ./run
[14:45] <Cimi> tsdgeos, then click on the camera app
[14:46] <tsdgeos> ok tx
[14:54] <dednick> tsdgeos: sorry, got caught in some traffic during lunch. I'll take a look
[14:54] <tsdgeos> Cimi: do you know where's the IMA documentation?
[14:58] <tsdgeos> in the sourcecode...
[15:00] <dednick> tsdgeos: item has been culled
[15:00] <tsdgeos> dednick: that's weird on its own
[15:00] <tsdgeos> being just one item on the list
[15:00] <dednick> tsdgeos: if you say so. don't know what culled it
[15:00] <dednick> *is
[15:00] <tsdgeos> it should be visible
[15:00] <tsdgeos> culled = non visible
[15:00] <dednick> clipped ;)
[15:00] <tsdgeos> i don't know what it really means either
[15:01] <tsdgeos> it's just the term qt uses here
[15:01] <Cimi> tsdgeos, sorry I'm in a call
[15:01] <dednick> ok
[15:01] <Cimi> tsdgeos, yeah ask zsombi
[15:04] <mhall119> thostr_: mhr3: in http://developer.ubuntu.com/scopes/tutorial/ if you scroll down to "The scope file" there is a field: RemoteContent=false
[15:04] <mhall119> it's not documented in the tutorial what that does, and I don't think it's documented anywhere else either
[15:05] <mhall119> can you tell me what it's for?
[15:05] <mhall119> and what uses it
[15:06] <dednick> tsdgeos: i'm getting shed loads of glib-critical log messages when clearing the search field for the second search.
[15:06] <dednick> from dee
[15:06] <mhr3> mhall119, it's the "this scopes does internet"
[15:06] <tsdgeos> dednick: mhr3's your man for that :D
[15:06] <mhall119> mhr3: what uses that?
[15:07] <mhr3> mhall119, so if internet searches are disabled, the scope is disabled
[15:07] <mhall119> I thought if internet searches were disabled, only default scopes were used
[15:07] <tsdgeos> dednick: tbh at this stage i'm not sure i can easily create a testcase that reproduces what you're doing :-/
[15:07] <mhr3> mhall119, you thought wrong :)
[15:07] <tsdgeos> basically you have a list that has just one item and that item is created but somehow not visible
[15:07] <tsdgeos> that's a bug by itself
[15:07] <tsdgeos> and then when you remove that item
[15:07] <mhall119> so in the given example, it should be true not false
[15:07] <tsdgeos> it crashes
[15:07] <tsdgeos> that's also a bug
[15:08] <tsdgeos> i can easily fix that second one but it is technically a workaound for the first one
[15:08] <dednick> tsdgeos: hm. ok. maybe i'll do some more debugging and try figure out where the culled item is comming from
[15:08] <tsdgeos> not sure if i make sense
[15:08] <tsdgeos> dednick: appreciated :)
[15:08] <mhr3> mhall119, right, it talks to the internet, doesn't it?
[15:08] <mhall119> yeah
[15:09] <mhall119> mhr3: so if online search is disabled, the smart scopes service won't be used, right?
[15:09] <mhr3> right
[15:10] <mhall119> so then nothing is making scope recommendations to the dash, how does it select which scopes to use?
[15:10] <mhr3> it just queries the ones it always queries
[15:10] <mhr3> apps, files
[15:10] <mhall119> so the default ones
[15:10] <mhr3> music?
[15:11] <mhall119> that's what I thought
[15:11] <mhall119> so then what does this field do?  Not allow the user to set a remote scope as a default scope when they have online search disabled?
[15:12] <mhr3> it disallows communication to that scope if searching internet is disabled
[15:13] <mhall119> communication that isn't likely to happen in the first place, since it won't be recommended to use the scope
[15:14] <mhall119> not to be argumentative, just making sure I understand this so I can explain it to community folks
[15:14] <mhr3> it could still be queried if it was a subscope of the always-search scopes
[15:14] <mhall119> do we have any that are like that?
[15:14] <mhr3> gdrive
[15:14] <mhall119> that's a default scope?
[15:14] <mhr3> yes
[15:15] <mhall119> ah, ok
[15:15] <mhr3> and it's files subscope
[15:15] <mhall119> thanks mhr3, that puts it all together for me
[15:15] <mdeslaur> ah, thanks mhall119, mhr3: that clears up some mystery :)
[15:19] <mhr3> np
[15:21]  * mhr3 waves hand @dednick there are no bugs in dee
[15:21]  * mhr3 waves hand @tsdgeos there are no bugs in dee
[15:22] <dednick> mhr3: if you wave your hands like that you might attract some attention... you want to be hiding.
[15:22] <mhr3> my jedi powers fail me
[15:22]  * mhr3 hides
[15:22] <dednick> tsdgeos: the first visible item's position is somewhat out of page...
[15:22] <dednick> when it does layout() it's setting to culled even though there is only 1 item.
[15:23] <tsdgeos> that is weird :S
[15:23] <tsdgeos> let me re-read the code
[15:24] <tsdgeos> right layout just assumes the first item will be correctly positioned
[15:24] <tsdgeos> doesn't try to fix it if it isn't
[15:24] <tsdgeos> i wonder why i can't reproduce it
[15:25] <tsdgeos> dednick: so you searrch "test", wait for search to finish, clear and search "test" again?
[15:25] <tsdgeos> and it crashes?
[15:26] <dednick> tsdgeos: search "test", expand "files and folders", clear search, enter "test" search again
[15:26] <tsdgeos> dednick: you wait for the search to finish or not?
[15:26] <dednick> tsdgeos: it's the cat expansion that does it
[15:26] <dednick> tsdgeos: yeah
[15:26] <dednick> i do wait
[15:26] <tsdgeos> so search, wait, expand, clear, search again
[15:29] <tsdgeos> dednick: ↑ ?
[15:30] <dednick> tsdgeos: yep
[15:30] <mhall119> mhr3: follow up question, if a .scope has no RemoteContent field, what does it default to?
[15:30] <tsdgeos> dednick: on the phone? or in the pc?
[15:30] <dednick> tsdgeos: desktop
[15:30] <mhr3> mhall119, unfortunately false :/
[15:31] <mdeslaur> mhr3, mhall119: hrm, can we file a bug on that and change the default?
[15:31] <mhall119> thanks again
[15:31] <tsdgeos> dednick: defenitely not happening here :(
[15:31] <mdeslaur> mhr3, mhall119: or would that break backwards compatibility or something?
[15:31] <mhall119> mdeslaur: or make it a mandatory field
[15:31] <dednick> tsdgeos: what categories do you have in default home?
[15:31] <mdeslaur> mhall119: even better, yeah
[15:32] <mhr3> mdeslaur, btw i wouldn't mind breaking stuff, this default sucks
[15:32] <tsdgeos> dednick: apps and files and folders
[15:32] <mdeslaur> mhr3: what package should we file the bug against for that?
[15:32] <mhr3> mdeslaur, libunity
[15:32] <mdeslaur> mhall119: I'll file the bug
[15:32] <mhall119> defaulting to remote doesn't make sense either, there isn't a "sensible" default thinking about it from a non-privacy point of view
[15:32] <mdeslaur> yeah, making it mandatory is better
[15:33] <mhall119> can we do that mhr3
[15:33] <mhall119> ??
[15:33] <mhr3> well, that would break even more scopes
[15:33] <mhall119> yes, but it would break them in expected ways early on
[15:33] <dednick> tsdgeos: it's because when the category is expanded, there is only one listitem, and you clear the seach, the other categories are inserted, with the application category above it, but it's culled because it's position is above. Maybe it's not updating it's position when an item above it is removed.
[15:35] <tsdgeos> dednick: i just can't see the difference between the first time you search test and the second
[15:35] <dednick> tsdgeos: i mean when an item lower
[15:35] <tsdgeos> i mean the LVPWH is just the same, no?
[15:35] <mdeslaur> mhall119, mhr3: bug 1250134
[15:35] <mhall119> IMO, having scopes break early and often is better than wondering why your local Virtual Machine scope doesn't return results when you have online search disabled, because the developer didn't provide an explicit value
[15:35] <dednick> tsdgeos: the category expand
[15:35] <tsdgeos> but the category exapnd gets reseted after you reset search
[15:36] <tsdgeos> ah wait
[15:36] <tsdgeos> it doesn't
[15:36] <tsdgeos> maybe you just have more files & folders than me
[15:36] <tsdgeos> i have 7
[15:36] <tsdgeos> you have enough so that they fill the home when no search is there?
[15:37] <mhr3> mhall119, that's the problem, from end user pov it'll be the same - the scope won't work
[15:37] <mhall119> mhr3: but the scope developer will see it and fix it
[15:38] <mhall119> and either way I think we'll need to go through all of the scopes we ship by default and check/fix them
[15:38] <mhr3> even for the developer it's hard to see, it's the loader that will complain and you don't usually see its output
[15:38] <mhall119> mhr3: we can compromise and just throw a nasy warning at the developer when it's run from the terminal?
[15:39] <dednick> tsdgeos: i dont know. when i expand the category when i havent got a search present, I get multiple list items, but only one when i do have a search.
[15:39] <dednick> tsdgeos: multiple "visible items" i mean
[15:39] <mhall119> or will running it from the terminal while testing it by-pass the part that would check the .scope file?
[15:39] <tsdgeos> i'm lost
[15:40] <tsdgeos> dednick: your default home files and folders, how many items are there if you expand it?
[15:40] <mhr3> mhall119, running a scope yourself won't show anything, the scope file is not necessary for that
[15:40] <mhall119> ok..
[15:41] <mhall119> well then, I'm +1 for just changing the default to true and checking the scopes we ship to make sure they are explicit
[15:41] <dednick> you mean scope results? if under search, about 100, if not about 30
[15:42] <mhr3> dednick, you're fixing the issues when reordering is enabled?
[15:42] <mhr3> or this is unrelated to that?
[15:42] <tsdgeos> dednick: so your default home "files and folders" fills the height when expanded and no search is there
[15:42] <dednick> mhr3: no
[15:42] <dednick> tsdgeos: yeah.
[15:43] <tsdgeos> ok, mine doesn't
[15:43] <tsdgeos> that probably makes a difference
[15:43] <tsdgeos> i need to get more stuff in there
[15:43] <tsdgeos> any ieda how to?
[15:43] <dednick> tsdgeos: you need more files ;)
[15:43] <dednick> i dont know actually
[15:43] <dednick> mhr3: ?
[15:44] <mhr3> files are coming from recently used
[15:44] <mhr3> which is coming from zg
[15:44] <mhr3> so just open stuff in gedit
[15:45] <mhr3> tsdgeos, i imagine you're using too many qt-ish apps that don't integrate with zg, right?
[15:45] <tsdgeos> most probably
[15:47] <tsdgeos> dednick: ok, got it now
[15:47] <dednick> tsdgeos: woo
[15:47] <tsdgeos> dednick: much better
[15:56] <mhr3> tsdgeos, so what is it that you're using the most and doesn't appear in zg?
[15:56] <tsdgeos> mhr3: not sure i get you
[15:57] <mhr3> tsdgeos, everytime you open a file it should be logged to zg, we have patches in gtk, kde libs... clearly something is missing
[15:57] <dednick> nobody does
[15:57] <mhr3> tsdgeos, or you're just on irc the whole day
[15:57] <mhr3> :)
[15:57] <tsdgeos> mhr3: yeah clearly the patch to kdelibs doesn't work
[15:58] <tsdgeos> mhr3: i'm using kate for my file editing
[15:58] <mhr3> hm, someone should check the patch
[15:59] <mhr3> volunteers? :)
[15:59] <tsdgeos> oyu mean like someone that knows how kdelibs works?
[15:59] <dednick> you were  waving earlier
[15:59] <dednick> pretty sure that means you!
[15:59]  * tsdgeos points at mzanetti ¬.~
[16:00] <tsdgeos> mhr3: i guess the patch is at the ubuntu level, right? don't remember any "proper" kdelibs code with zg
[16:00] <mhr3> dednick, my waving is very complex, is has implied pre and post conditions etc...
[16:00] <mhr3> tsdgeos, right
[16:00] <dednick> mhr3: yeah, well nobody understands the syntax, so they just assume you're good to go :)
[16:01] <mhr3> dednick, one of the precondition is "if (mhr3.has_to_do_extra_work()) throw NoWayError("No way!");
[16:02] <dednick> heh
[16:02] <dednick> i should get one of those plugins
[16:03] <tsdgeos> mhr3: you sure there's a patch for that? can't see anything that mentionszeitgeist in  kde4libs-4.11.2/debian/patches
[16:03] <tsdgeos> Cimi: i think i may have found why the IMA doesn't work
[16:03] <tsdgeos> Cimi: the topmostItem thing doesn't seem to "understand" touch events
[16:03] <mhr3> tsdgeos, well it was implemented for precise iirc
[16:03] <tsdgeos> may have been dropped
[16:04] <mhr3> maybe
[16:04] <Cimi> tsdgeos, talk to zombi if you can
[16:04] <Cimi> tsdgeos, unless it's a bug in my patch
[16:04] <tsdgeos> he's gone eating brains
[16:04] <tsdgeos> will do tomorrow
[16:08] <tsdgeos> mhr3: talked to the kubuntu packagers, noone seems to remember or be able to find a zeitgeist patch for kdelibs, maybe it was in the plan but just never happened?
[16:08] <mhr3> hmm
[16:08] <mhr3> let me dig up old emails
[16:09] <Cimi> tsdgeos, thanks for helping
[16:10] <tsdgeos> Cimi: that's team work!
[16:10] <Cimi> tsdgeos, I can bring beers!
[16:11] <tsdgeos> he he :D
[16:21] <mhr3> tsdgeos, ok, checked it was never implemented in the kde libs, there's a dataprovider that is trying to read KRecentDocument by going over ~/.kde/share/apps/RecentDocuments
[16:23] <mhr3> but it doesn't use any k-APIs so maybe the reader part got out-of-sync from the writer in kde libs?
[16:23] <mhr3> or maybe the thing you're using doesn't use KRecentDocuments
[16:23] <tsdgeos> yeah
[16:24] <tsdgeos> that only gets filed if i open stuff with the open dialog
[16:24] <tsdgeos> but not if i do
[16:24] <tsdgeos> kate moo.cpp
[16:24] <tsdgeos> which may be a bug in kate if you think about it
[16:24] <mhr3> well, logging that is practically impossible
[16:25] <tsdgeos> well not really, goes through kio::open you could easily log that if you have a kdelibs patch
[16:25] <tsdgeos> anyway
[16:25] <tsdgeos> back to real work ;-)
[16:25] <mhr3> tsdgeos, you mean together with all the tmp files, dynamic modules and whatnot
[16:25] <mhr3> zg wants user actions
[16:26] <tsdgeos> sure
[16:32] <tsdgeos> dednick: still there?
[16:32] <dednick> tsdgeos: yo
[16:32] <tsdgeos> dednick: can you check if the fix in lp:~aacid/unity8/lvwph_bad_header_position_1240118 also fixes this bug for you?
[16:33] <tsdgeos> seems to fix it here
[16:33] <tsdgeos> but a second confirmation is better
[16:34] <dednick> tsdgeos: sure
[16:36] <dednick> tsdgeos: yeah, seems to do it
[16:41] <tsdgeos> dednick: ok, i'll link it there to that bug too
[16:43] <tsdgeos> dednick: though probably we still have a testcase about it
[16:43] <tsdgeos> dednick: thoughts?
[16:45] <dednick> tsdgeos: would be nice to have a testcase, but it's a bit of an edge...
[16:49] <dednick> tsdgeos: although the miraculous fix from that other branch seems a bit dubious...
[16:49] <dednick> It's all a bit "random events
[16:51] <tsdgeos> dednick: it's not dubious at al
[16:51] <tsdgeos> l
[16:51] <tsdgeos> it's just what needs to happen
[16:51] <tsdgeos> i've two people say "it's dubious"
[16:51] <dednick> trusting that this variable wont be the value because this other variable is this value when this happens... the problem is not the logic, but that we've caught all cases.
[16:51] <tsdgeos> when tbh, you guys know close to nothing on how the LVWPH works
[16:51] <tsdgeos> sure
[16:52] <tsdgeos> i agree to catch all the cases, that's why we unit test stuff
[16:52] <tsdgeos> to make sure we do not regress
[16:52] <dednick> :) ok, then we need a unit test
[16:56] <tsdgeos> yep
[17:00] <tsdgeos> will do tomrrow though, eod now! tomorrow more!