[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!


[07:45] <lotuspsychje> nice bionic article: https://thishosting.rocks/ubuntu-18-04-new-features-release-date/


 Welcome @vovannn235
 Thank you) Hi all testers) (re @philipz: Welcome @vovannn235)
 Forwarded from RikMills:
 welcome @wimpress
 its been to long
 reminder to put out the ubuntupodcast tweet, as i wasn't able to quote tweet it today :D
 @popeydc any luck with getting the ubuntu twitter account to tweet out the discourse link
 Yeah, we will.
 It will be better to post next week
 oh okay
 He does the Dart stuff-yaru.dart and the new installer (re @philipz: are you part of the ubuntu desktop team?)
 I've PR'd a few times, so we sort of know eachother.
 https://twitter.com/ubuntupodcast/status/1375464151707947015 (re @philipz: reminder to put out the ubuntupodcast tweet, as i wasn't able to quote tweet it today :D)
 Where should I direct people to get involved with QA week?
 https://discourse.ubuntu.com/t/ubuntu-21-04-testing-week/21519
 Welcome @geekyBoogiepop
 Ubuntu mate did put out an announcement https://ubuntu-mate.community/t/ubuntu-mate-21-04-testing-week-april-1-april-7/23385 (re @wimpress: Where should I direct people to get involved with QA week?)
 Thank you, hope you're having a good day.
 That's what I'm after 👍 (re @popeydc: https://discourse.ubuntu.com/t/ubuntu-21-04-testing-week/21519)
 Might live stream some QA later. If not tonight then tomorrow.
 There's a market for that? I could've been famous this whole time!
 There is. You're late to the party. Also, Hello you! 😁
 You're already a legend in your own lunchbox. (re @cwayne: There's a market for that? I could've been famous this whole time!)
 @ubuntuunofficialsupport
 Me, Maik, Tobiyo and Rudra are in it.  If you want to join our Friendship Network, you are all welcome.
 Not too late to cash in and make a Twitch account :) (re @cwayne: There's a market for that?


[06:34] <oSoMoN> good morning desktoppers
[06:34] <zpercussionist> good morning!
[06:36] <duflu> Morning oSoMoN and zpercussionist
[06:42] <oSoMoN> hey duflu & zpercussionist
[07:05] <jibel> Good morning all
[07:10] <duflu> Hi jibel
[07:13] <jibel> Hi duflu
[07:19] <oSoMoN> salut jibel
[07:51] <jibel> Salut oSoMoN
[08:02] <didrocks> good morning
[08:03] <duflu> Hi didrocks
[08:03] <marcustomlinson> morning oSoMoN zpercussionist duflu jibel didrocks
[08:03] <duflu> 'lo marcustomlinson
[08:04] <didrocks> hey duflu, marcustomlinson
[08:28] <jibel> hi marcustomlinson
[08:53] <oSoMoN> good morning didrocks & marcustomlinson
[08:54] <didrocks> salut oSoMoN
[09:02] <Laney> happy snow morning!
[09:02] <duflu> Laney, happy not raining (it did all weekend)
[09:02] <duflu> At least it wasn't a cyclone anymore
[09:02] <didrocks> hello Laney
[09:05] <Laney> hey duflu didrocks
[09:05] <Laney> apparently this is wind and snow from ukraine
[09:07] <seb128> goood morning desktopers
[09:07] <oSoMoN> salut seb128
[09:07] <oSoMoN> happy sleighing Laney
[09:08] <seb128> lut oSoMoN, comment ça va ?
[09:08] <duflu> Hi seb128
[09:08] <seb128> hey duflu
[09:08] <oSoMoN> seb128, à peu près reposé et bien deconnecté, et toi?
[09:09] <didrocks> salut seb128
[09:09] <jibel> salut seb128
[09:09] <seb128> lut didrocks
[09:09] <seb128> lut jibel
[09:10] <seb128> oSoMoN, fatigué mais sinon ça va
[09:11] <Laney> hey seb128 oSoMoN
[09:12] <marcustomlinson> morning Laney and seb128
[09:13] <Laney> hey marcustomlinson
[09:13] <Laney> how's the snow there?
[09:13] <seb128> hey marcustomlinson
[09:14] <seb128> we got snow here as well this night
[09:14] <seb128> we were supposed to drive yesterday but delayed our return trip due to the conditions
[09:14] <marcustomlinson> Laney: just a little icing on the top here :)
[09:18]  * duflu assumes Scotland is made of cake
[09:24] <Laney> black bun yes dundee cake no NO
[09:24] <marcustomlinson> well my daughter seems to like the way the ground tastes
[10:06] <seb128> Laney, I don't have edit rights I think on https://discourse.ubuntu.com/t/hirsute-hippo-release-schedule ... could you update it for us to note that GNOME 40 we are only going to get some limited components?
[10:06] <seb128> Laney, also we had new glib on january marked, wdyt about syncing 2.67 from experimental?
[10:11] <Laney> ok, and go for it
[10:11] <Laney> get popey to add you to that category imho
[10:11] <Laney> work to fix that ticket has been assigned for a couple of months now, no movement yet
[10:12] <Laney> want to put wayland in one of the weeks?
[10:18] <seb128> sounds like an idea yes, probably this one?
[10:18] <seb128> Trevinho, what's the status of turning pipewire on in the packages?
[10:27] <Laney> it is in
[10:37] <seb128> Laney, speaking about schedule edit or replying to the pipewire question?
[10:38] <seb128> I guess editing since I don't see the uploads, thanks :-)
[10:40] <Laney> yes
[10:41] <Laney> I dunno about the upload part
[10:44] <cpaelzer_> didrocks: good morning, it would be great if you could discuss https://bugs.launchpad.net/ubuntu/+source/marisa/+bug/1914808 in the team before tomorrows MIR meeting
[10:47] <didrocks> cpaelzer_: will do
[10:48] <didrocks> seb128: once you are around ^^
[10:49] <seb128> didrocks, I'm around
[10:49] <seb128> what needs discussing?
[10:49] <didrocks> so, any opinion of taking ownership of marisa?
[10:50] <didrocks> (due to opencc dep)
[10:53] <seb128> well I don't think we have much of a choice
[10:53] <seb128> so yes, we should accept it
[10:53] <seb128> do you want me to edit the description to be more 'standard' at least in formating and sections?
[10:55] <didrocks> seb128: that would be appreciated
[11:00] <seb128> didrocks, k, will do
[11:02] <didrocks> thx!
[11:33] <seb128> what's the page again that list debian uploads you did for someone?
[11:35] <Laney> seb128: https://udd.debian.org/sponsorstats.cgi ?
[12:20] <cpaelzer_> didrocks: I see you want the package, I'd be able to squeze in a review now - or did you already start on it?
[12:26] <didrocks> cpaelzer_: oh please grab it away! I was scheduling it for tomorrow, but if you have time, feel free :)
[12:42] <seb128> Laney, thanks
[13:12] <Beret> xnox, btw, my problem on friday was a network-manager update that recreated the default ethernet device, therefore nuking my configured bridge
[13:13] <Beret> I guess that's what I get for using a desktop as a pseudo-server, but it was annoying nonetheless
[13:58] <Trevinho> seb128: yeah, sooo... I'm doing some further testing
[14:05] <seb128> Trevinho, hey, did you spot any issue or just making sure things are working?
[14:05] <seb128> cpaelzer_, https://launchpadlibrarian.net/521448373/buildlog_ubuntu-hirsute-amd64.marisa_0.2.6-3~exp2ubuntu1_BUILDING.txt.gz
[14:05] <Trevinho> seb128: not big problems so far but need to test the remote part
[14:06] <seb128> cpaelzer_, if you search for 'make  check-TESTS'
[14:06] <seb128> [14:06] <seb128> Testsuite summary for marisa 0.2.6
[14:06] <seb128> [14:06] <seb128> # TOTAL: 5
[14:06] <seb128> # PASS:  5
[14:06] <seb128> oh, I see GunnarHj comment that on the bug
[14:07] <seb128> Trevinho, even if it's not working it's not going to be a regression over not having it so no point delaying enabling?
[14:07] <Trevinho> noted
[14:30] <ItzSwirlz> racb: Just noted that LP #1901344 is still sitting around. I remember looking at it from earlier that it applies with groovy (both patches)
[14:34] <Trevinho> seb128: there may need few things to do though https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1406#note_935033
[14:35] <Trevinho> I think daniel already linked that eraly
[14:36] <seb128> Trevinho, yes, that's on our trello board and we discussed those in the hangout, I will handle the settings change when you upload
[14:36] <Trevinho> earlier*
[14:36] <Trevinho> yes yes
[14:36] <Trevinho> I was just cross checking in the board we had them all
[14:36] <seb128> k, I think we have those
[14:39] <ItzSwirlz> whoops, wrong room
[14:50] <cpaelzer_> seb128: I was distracted by the full page of no-tests after dh_auto_test , but you are right
[14:50] <cpaelzer_> thanks
[15:02] <seb128> cpaelzer_, np!
[19:57] <rbasak> Is it intended that all 20.04 desktops move on to the HWE kernel? Because one of mine hasn't, which puzzled me until I realised that it's probably because it was upgraded up to Focal, so hasn't got the different metapackage.
[20:24] <oSoMoN> rbasak, according to https://discourse.ubuntu.com/t/improvements-for-hardware-support-in-ubuntu-desktop-installation-media/20606 that happens only when you installed 20.04 afresh, not after upgrading
[20:26] <rbasak> I'm puzzled by the rationale if it isn't intended to put 18.04 upgraders on the same path.
[20:29] <oerheks> one can, with the HWE tutor
[20:37] <xnox> rbasak:  in the past, we did sunset people on the next lts. i.e. installations of 18.04.2+ & 18.10+ would land on generic 20.04. Hence the hwe package was named hwe-18.04 which parks on generic.
[20:37] <xnox> rbasak:  our reasoning was, that this what the contract was when people installed those repsective series.
[20:38] <xnox> rbasak:  with 20.04, generic & hwe-20.04 are everlasting tracks. Hence even 20.10/21.04/21.10 installers install and track hwe-20.04 track. Which will rollover to hwe-22.04 in 22.04 and stay hwe.
[20:39] <xnox> rbasak:  hence yes, there is difference between desktop fresh install of 20.04 or later; vs upgrade to 20.04 or later. But that is the last barrier.
[20:39] <xnox> from now on, there shouldn't be any different.
[20:39] <xnox> rbasak:  does above sound reasonable?
[20:40] <xnox> rbasak:  ie. when upgrading from xenial -> bionic; if one had hwe, one ends up with bionic. Effectively no kernel change as latest hwe in xenial is the bionic kernel.
[20:41] <xnox> rbasak: and if one wanted to keep hwe, one had to switch to hwe track after every lts jump.
[20:41] <xnox> rbasak:  22.04 lts will be the first time where turning hwe on again will not be needed.
[20:41] <xnox> (if one already was on hwe prior to the upgrade to 22.04)
[21:01] <rbasak> xnox: I think I follow, but as you say, "last barrier". Isn't that the majority of Ubuntu users though, who keep upgrading up through releases?
[22:11] <ItzSwirlz> hey kenvandine, question about yaru.dart, want to move to dms, or would you prefer here?
[22:11] <ItzSwirlz> (its about yaru theme branch for cinnamon de)


[01:48] <pitti> hello
[01:54] <Hobbsee> hi pitti
[01:54] <Keybuk> mvo, MacSlow, Mithrandir: ping ?
[01:55] <Keybuk> (I suddenly realise that an interestingly large portion of my team begins their nickname with "M")
[01:55] <kwwii> I picked kwwii just so I would have a K, like you :p
[01:55] <Mithrandir> good morning
[01:56] <Keybuk> Mirco just lost power
[01:56] <Mithrandir> we should just name the team reporting-to-Scott-team to avoid any confusion
[01:57] <Hobbsee> heh
[01:57] <mvo> hey Keybuk
[01:57] <DrPepperKid> test 1..2..3..
[01:57] <Keybuk> Hobbsee: it's the meeting of the team that's a subset of both :p
[01:58] <Keybuk> DrPepperKid: that was quick!
[01:58] <Hobbsee> Keybuk: right then :P
[01:58] <Mithrandir> Keybuk: and some others. :-P
[01:58] <DrPepperKid> Keybuk, I'll see how long it lasts
[01:58] <DrPepperKid> *sigh*
[01:58] <pitti> DrPepperKid: pedal faster!
[01:58] <Keybuk> I did send out a quick mail about an hour ago for agenda items
[01:58] <Keybuk>  * Update on compiz decision from TB
[01:58] <Keybuk>  * Compiz bug update from mvo and Mirco
[01:58] <Keybuk>  * Herdy planning
[01:59] <Keybuk> did anyone have anything to add to that?
[01:59] <pitti> does 'herdy planning' involve some sponsoree issues?
[02:00] <pitti> (invited people for UDS)
[02:00] <Keybuk> pitti: it can do, depending on what you want to discuss?
[02:00] <Keybuk> if particular people are involved, it may be better to raise that privately since this is a public meeting
[02:00] <pitti> just an update how we should proceed
[02:00] <DrPepperKid> I just got the "short term" announce... power will be off for an hour or so... *sigh*
[02:01] <Keybuk> pitti: let's discuss that afterwards
[02:01] <pitti> 'k
[02:02] <mvo> is MacSlow here yet
[02:02] <mvo> ?
[02:02] <Keybuk> mvo: he came and went
[02:02] <Keybuk> mvo: but please do give us a quick update on how compiz is going
[02:03] <ogra> mvo, he was hiding behind DrPepperKid :)
[02:03] <Keybuk> now that the Technical Board have agreed to ship with compiz
[02:03] <mvo> ok
[02:03] <mvo> the bug situation is not too bad currently. upstream is very active and helpful
[02:03] <mvo> especially danny baumann and amaranth (thanks!)
[02:04] <mvo> we may have to blacklist nvidia if the xserver problem does not get sorted (patch 132 breaks the 1.3 abi)
[02:04] <mvo> we may have to blacklist mga (or g450) because its too slow
[02:05] <Keybuk> how is video playback going?
[02:06] <Keybuk> I saw that Mez blogged about it not working, was that related or unrelated?
[02:06] <pitti> yesterday, ati was blacklisted; is there any video driver besides intel which is still enabled, btw?
[02:06] <Keybuk> (with xine, at least)
[02:06] <mvo> pitti: there will be another upload today that just blacklists rs480
[02:06] <pitti> mvo: ah, cool
[02:06] <mvo> I have not seen mez blog post yet
[02:07] <pitti> mvo: and the ABI change cannot be accounted for in the sourceful part of nvidia?
[02:07] <mvo> but video works for most people, but *not* for intel on i965
[02:07] <mvo> #111257
[02:07] <mvo> bug #111257
[02:07] <ubotu> Launchpad bug 111257 in xserver-xorg-video-intel "totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver" [High,Confirmed]  https://launchpad.net/bugs/111257
[02:07] <Keybuk> mvo: do we know what causes that?
[02:08] <Keybuk> is there a fix likely?
[02:08] <mvo> now I though I had fixed that with the xf86VFillKeyHelperDrawable patch, but that seems to be not the case
[02:08] <mvo> but I do not have hardware myself to test so its a bit difficult for me currently
[02:08] <mvo> pitti: apparently not, patch 132 is important for ubuntu-mobile but breaks nvidia
[02:09] <mvo> Keybuk: I honestly don't know yet
[02:09] <pitti> mvo: right, I meant changing the nvidia driver itself to adapt to the new API
[02:09] <Keybuk> mvo: do we know anyone with that hardware?
[02:09] <mvo> I will try to find someone
[02:09] <mjg59> Xv will not work for 965 under compiz if XAA is used. We discussed that at TB.
[02:10] <mvo> worst case is blacklisting this pciid
[02:10] <Mithrandir> mvo: 132 is important for upstream gtk too, since what it does is enabling inter-widget compositing.  At least, AIUI, from talking with seb.
[02:10] <mjg59> Choices are either (a) don't use compiz on 965, or (b) use EXA
[02:10] <Keybuk> mjg59: what's the downside to using EXA?
[02:11] <pitti> hi Amaranth, good to have you here!
[02:11] <Amaranth> i really need to start using some calendar software
[02:11] <Keybuk> (tangent: I really need that SoC guy to finish the evolution google calendar backend :p)
[02:11] <mjg59> Keybuk: Significantly less well tested, very different codepaths
[02:12] <mvo> mjg59: you went to XDS, right? what were the opionions about compiz-by-default there?
[02:12] <pitti> Amaranth: import the fridge calendar into evo
[02:13] <mvo> Amaranth: anything you want to add about the bug situation in compiz?
[02:13] <mjg59> mvo: On aiglx? That it wasn't sensible yet
[02:13] <Amaranth> i don't think so
[02:13] <Amaranth> same as the TB meeting
[02:13] <Amaranth> other than driver issues (which we can work around or blacklist) it's mostly little things
[02:14] <mvo> macslow is working on the workspaces layout bug currently
[02:14] <mvo> that is hopefully fixed soon too
[02:15] <Keybuk> ok, thanks
[02:15] <Amaranth> Keybuk: that's your pet bug, no?
[02:15] <Keybuk> Amaranth: I have lots of pet bugs
[02:15] <Amaranth> hehe
[02:15] <Keybuk> sometimes I forget to feed them
[02:16] <pitti> that one is one of my favourite's, too :)
[02:16] <mvo> use a flat layout!
[02:18] <mvo> Keybuk: we hope to attack more bugs on the compiz sprint next week
[02:18] <mvo> and we also hope for more user feedback/bugreports
[02:18] <Keybuk> indeed
[02:18] <mvo> now that its "offical"
[02:18] <Amaranth> man i got a lot of comments on my blog for that
[02:18] <Amaranth> so there is obviously interest :)
[02:18] <Keybuk> Amaranth: what kind of balance?
[02:19] <Amaranth> all negative :P
[02:20] <Amaranth> mostly asking if this means their pet driver bug will be fixed
[02:20] <Amaranth> or what happens for people with unsupported hardware
[02:20] <Amaranth> http://www.realistanew.com/2007/09/12/compiz-by-default-in-ubuntu-710/#comments
[02:21] <Keybuk> cool
[02:21] <mjg59> It wouldn't surprise me if r300 isn't especially stable
[02:21] <Keybuk> mvo: before the sprint, if you could check over the bug list and find those that are most user-affecting, etc.  that would be great
[02:22] <Keybuk> anyway, Herdy
[02:22] <Amaranth> Keybuk: i already did that
[02:22] <mvo> Keybuk: I plan to do that, yes
[02:23] <mvo> but Amaranth did great work already
[02:23] <Keybuk> 8.04 will be an LTS, in some form or other
[02:23] <mvo> is there more than one form ;) ?
[02:24] <pitti> so, no crazy new stuff? :)
[02:24] <Keybuk> the general thought is that new development is fine if it fixes problems
[02:24] <Keybuk> or improves usability, etc.
[02:25] <Keybuk> we want to tackle problems that matter most to our users as well, mdz is looking at some digg-like way of collecting the top problems
[02:25] <pitti> one thing I had in mind for hardy was an application for guided bug filing (decision-tree based); I guess stuff like this is appropriate?
[02:26] <pitti> (we already had that spec for gutsy, but it didn't get very far)
[02:26] <Keybuk> potentially; Henrik's new Desktop QA Developer will certainly help with that kind of thing :)
[02:27] <Keybuk> since we're especially looking at what users want, it's worth everyone going through things like:
[02:27] <Keybuk>  * https://wiki.ubuntu.com/IdeaPool
[02:27] <Keybuk>  * https://wiki.ubuntu.com/UsabilityWishlist
[02:27] <Keybuk>  * https://blueprints.launchpad.net/ubuntu
[02:27] <Keybuk> and seeing if there's any items in there that interest you
[02:27] <pitti> and maybe the long list of specs that users created
[02:28] <pitti> . o O { a sensible backup solution! }
[02:28] <Mithrandir> I need to come up with a list of development issues for UME, which is kinda on the side of what Ubuntu Desktop does.
[02:28] <mvo> backup++
[02:29] <pitti> mvo++; more time for bug fixing
[02:30] <Keybuk> so please, over the next week put together a list of problems to tackle
[02:30] <Keybuk> and then we'll discuss everyone's lists at the team meeting
[02:30] <Mithrandir> Keybuk: to what extent do you expect me to have complete lists for UME?
[02:30] <Keybuk> Mithrandir: I'm not sure, check with mdz :)  at least a partial list will be good though
[02:30] <Keybuk> he expressed some urgency to the planning
[02:31] <Keybuk> UME is more interesting simply because it's still in development
[02:31] <Keybuk> I'm not sure whether it's being considered for LTS or not
[02:32] <Mithrandir> I think we want to LTS it, simply because we'll have devices with it on in the field for quite a while.
[02:32] <Amaranth> stupid router
[02:32] <Mithrandir> and I don't think we'll have people doing dist-upgrades of their MIDs
[02:32] <Mithrandir> urgency> yes, everything about UME is urgent.  :-)
[02:33] <Keybuk> urgency to general planning, in fact
[02:34] <Keybuk> is there any other business?
[02:34] <Mithrandir> I don't have anything
[02:35] <pitti> let's go squash bugs
[02:35] <Amaranth> \o/
[02:35] <Keybuk> ok thanks all
[02:35] <pitti> 11 down, 3 to go \o/, so I might be able to help with the unassigned beta bugs soon, too
[02:36] <Keybuk> pitti: I expect you're glad we have a full time release manager starting on Monday :p
[02:36] <Amaranth> pitti: feel free to fix all the compiz bugs :)
[02:36] <pitti> indeed I am \o/
[02:36] <pitti> Amaranth: *cough*
[02:36] <pitti> Amaranth: in fact I am about to go to a shop and take a look at some shiny new laptops now :)
[02:36] <pitti> so that I can actually test it
[02:37] <pitti> Keybuk: although I guess that we'll do the beta release together, for mentoring?
[02:37] <Keybuk> I imagine so
[04:34] <ArneGoetje> @now
[04:34] <ubotu> Current time in Etc/UTC: September 13 2007, 14:34:08 - Next meeting: IRC Council in 3 days
[05:03] <dholbach> hey mvo :)
[05:03] <heno> Suggested agenda item: Tribe 6 and Beta bug status
[05:03] <ogra> @now
[05:03] <ubotu> Current time in Etc/UTC: September 13 2007, 15:03:26 - Next meeting: IRC Council in 3 days
[05:03] <asac> hi
[05:03] <pitti> hi
[05:04] <calc> hi
[05:04] <dholbach> It's not really an agenda item, but please all have a look at http://daniel.holba.ch/sponsoring - there are bugs which I might have assigned to you - please try to get back to patch authors
[05:04] <calc> pitti: btw i will look into fixing the office bean issue with the next upload of OOo
[05:04] <pitti> calc: thank you! appreciated
[05:04] <pitti> calc: when is that scheduled? IOW, when can we expect to have testable CDs again?
[05:05] <calc> pitti: oh it completely breaks the CD *wince* :\
[05:05] <evand> hi
[05:05] <pitti> calc: well, not completely break (VMWare testing is fine), but you cannot burn them
[05:05] <calc> pitti: i had hoped to do it after 2.3.0 is released on Monday but I can try to push that to sooner
[05:06] <pitti> calc: and TBH I have no idea how to free 12 MB on them
[05:06] <Mithrandir> just remove OOo? :-P
[05:06] <pitti> there are almost no langpacks left to remove (which is a pity on itself)
[05:06] <calc> pitti: will dropping office bean by itself be enough to fix the problem or should i look to some other things?
[05:06] <pitti> Mithrandir: ! why didn't I think about *that*?
[05:07] <heno> Could everyone please look at bugs on https://bugs.launchpad.net/ubuntu/+bugs?field.milestone:Alist=473 assigned to them and try to give an updated ETA? (then we can move on to beta)
[05:07] <pitti> calc: should be fine, it pulls in java-gcj-compat and that big libgcj8-jar
[05:07] <Amaranth> do we use -Os when building?:)
[05:07] <Keybuk> heno: if only that view showed who they were assigned to <g>
[05:07] <calc> pitti: ok
[05:07] <pitti> heno: shouldn't we move all of those to beta straight away?
[05:08] <heno> pitti: we should I just though we could do a Tribe 6 wrap-up first
[05:08] <evand> CDs> As of yesterday they still have serious unionfs issues anyway
[05:08] <heno> our non-release milestone :)
[05:08] <mathiaz> for bug 120085, isn't it too late in the release cycle to introduce such a change ?
[05:08] <ubotu> Launchpad bug 120085 in sysklogd "Various problems running syslogd with "-u syslog" option" [Medium,Triaged]  https://launchpad.net/bugs/120085
[05:09] <pitti> heno: hm, I don't think that all tribe6 bugs are really more important than the beta ones
[05:09] <pitti> heno: that hasn't been very consistent in the past, bugs were just dragged from tribe to tribe and eventually to beta
[05:09] <pitti> heno: unless you have different experiences?
[05:09] <heno> pitti: no, it's just a subset. should we instead to High priority bugs from both lists?
[05:10] <pitti> (is a verb missing here?)
[05:10] <calc> my two bugs are done :)
[05:10] <heno> ... instead look at ....
[05:10] <ogra> mathiaz, its a regression fix, no ?
[05:10] <mathiaz> ogra: yes. A regression that was introduce in edgy
[05:11] <ogra> sounds to me like it should go in
[05:11] <mathiaz> then if a core-dev could have a look at the debdiff I've attached and comment, it would be great
[05:12] <evand> my bugs are done with workarounds, prettier fixes are still being investigated
[05:12] <pitti> heno: that's why I think we should just merge them into one list and adjust priorities
[05:12] <pitti> I'm down to three restricted-manager bugs for beta, rest is done
[05:13] <mvo> the compiz/g-screensaver issue is still under investiagation
[05:15] <heno> after moving the last tribe bugs we'll have ~200 open bugs milestoned for beta. how does that compare with previous releases at this stage?
[05:15] <heno> Mithrandir: ^
[05:15] <Mithrandir> that's quite a bit more, I believe
[05:16] <Mithrandir> but then, we have a much more active server team, for instance.
[05:16] <heno> making more bugs :)
[05:16] <heno> we still need to do a critical review of that list though
[05:17] <heno> pitti: shall we do that some time next week?
[05:18] <pitti> heno: agreed; or tomorrow, fine for me
[05:18] <heno> for bug 132320 I was wondering whether we should just leave tracker indexing off by default anyway
[05:18] <ubotu> Launchpad bug 132320 in tracker "Tracker consumes more then 90% of CPU even when indexing is disabled" [Critical,Confirmed]  https://launchpad.net/bugs/132320
[05:18] <heno> pitti: ok, tomorrow is good
[05:19] <heno> and activate it the first time someone goes to search
[05:19] <asac> heno: the bug claims that it consumes cycles even if indexing is disabled? how would disabling it help?
[05:20] <heno> asac: I mean, not run the deamon at all
[05:21] <Amaranth> compiz/g-screensaver is annoying hard to figure out
[05:22] <Amaranth> heno: tracker uses that much CPU by design
[05:22] <Amaranth> heno: it uses 100% cpu but nice level 19 so as soon as something wants CPU time tracker gets pushed out
[05:23] <heno> Amaranth: which is a good argument for turning it off. I would guess only a fraction of users actually use desktop search
[05:23] <Amaranth> heno: but it's not a bug
[05:23] <Amaranth> and it's not a problem
[05:23] <calc> Amaranth: using 100% cpu for prolonged time period on laptops is an issue... right?
[05:23] <Amaranth> calc: it's going to not do anything when running on battery
[05:23] <calc> Amaranth: ah ok
[05:24] <Amaranth> well, jamie said we could expect that soon
[05:24] <heno> it's bad for the environment even on desktops :)
[05:24] <asac> Amaranth: soon enough for gutsy?
[05:24] <Amaranth> asac: yes
[05:24] <Amaranth> before beta even, i guess
[05:24] <asac> Amaranth: you know jamie?
[05:24] <heno> seriously, using that much CPU is bad form
[05:24] <calc> so why does it use 90%+ cpu when apparently not doing anything?
[05:24] <Amaranth> asac: sort of
[05:24] <asac> Amaranth: ok fine then.
[05:25] <heno> and most users don't want it (is my humble guess)
[05:25] <asac> i must admit that i was a bit annoyed by it
[05:25] <pochu> calc: When it's 90+ it's indexing
[05:25] <calc> when it is actually doing indexing it causes the system to basically grind to a halt until it is done due to disk iowait
[05:25] <asac> it indexed for two days or so when i upgraded to gutsy
[05:25] <Amaranth> well you could throttle it
[05:25] <Amaranth> then it uses less % but runs longer
[05:25] <Amaranth> so same cpu time in the end
[05:26] <heno> asac: and how often have you used desktop search since then?
[05:26] <calc> pochu: the bug report mentioned above said it was at 90%+ even with indexing disabled, whether that is actually the case I don't know
[05:26] <dholbach> also having ~1G of indexing data in .cache/tracker annoyed me a bit
[05:26] <asac> heno: actually i tried it ... e.g. to find things in mozilla source
[05:26] <Amaranth> we are not the target audience
[05:26] <asac> heno: i think i would use it if I could dump updatedb completely in turn
[05:26] <pedro_> dholbach: i seconded that.
[05:26] <pochu> calc: I think there's another bug saying it didn't stop to index when it was told to, so probably it was indexing :)
[05:26] <Amaranth> we keep track of things on our filesystem
[05:26] <asac> but afaik i cannot search for filenames
[05:26] <calc> pochu: oh ok
[05:27] <heno> the target audience use firefox, an mp3 player and skype. that's it :)
[05:27] <Amaranth> my grandfather can't remember where he puts anything
[05:27] <asac> heno: yeah ... but the target audience doesn't have a home with zillions of fileitems either ;)
[05:27] <dholbach> asac: you don't know my sister :)
[05:28] <calc> i haven't looked into this but how do you disable tracker normally?
[05:28] <asac> heno: so indexing shouldn't take so long ;)
[05:28] <heno> right they keep their pictures in their gmail acct and search that
[05:28] <calc> its depended on by ubuntu-desktop so shouldn't actually be completely removed
[05:28] <mvo> its a recommends, no?
[05:28] <calc> oh yea just recommends, recommends gets autoinstalled I forgot about that
[05:28] <asac> well i think its rare that there are picture folders with as many files as a mozilla source copy ;)
[05:28] <heno> no, it's just that the deamon should be set to not run until the user tries their first search
[05:29] <jdstrand> calc: I used Sessions
[05:29] <asac> heno: the backdraft would be that the first search wouldn't yield any results right? so people will never try again :)
[05:29] <Amaranth> heno: then their first search is worthless and they stop using it
[05:29] <asac> ack
[05:30] <bdmurray> Maybe we should ask people instead of speculating?
[05:30] <asac> bdmurray: yeah ... forum vote ;)
[05:30] <heno> or their first experience into Ubuntu is slooooow and they stop using _that_
[05:30] <pedro_> asac: it could show a message "your files are not indexed with tracker do you want to start blabla bla?" ok/cancel
[05:30] <heno> we should take it to the list
[05:30] <heno> pedro_: +1
[05:30] <jdstrand> heno: perhaps a notice telling the user that the first index isn't complete would work
[05:30] <pedro_> agreed.
[05:30] <asac> pedro_: right ... i agree that things can be improved ... but we have to chew on it i guess
[05:31] <heno> Windows help used to do this, so people are used to that
[05:32] <heno> it would make the two top tracker bugs no longer Critical
[05:32] <Amaranth> in OS X they just made it the default. new installs are no problem because there are no files to index and upgrades have maybe one day of pain then they're fine
[05:32] <heno> (though they should still be fixed)
[05:32] <Amaranth> so maybe on by default for new installs only?
[05:33] <asac> Amaranth: +1 (when combined with heno/pedro_ suggestion for existing installs)
[05:33] <heno> it still takes CPU cycles, RAM and disk space for the 90% who will never use it
[05:33] <heno> (my random guess)
[05:34] <Amaranth> it uses almost no RAM so...
[05:34] <heno> Amaranth: do you have numbers?
[05:34] <Amaranth> and people have 400GB hard drives so that's not a big deal
[05:34] <pitti> erm, laptops don't
[05:34] <pedro_> well not all the people
[05:35] <heno> some people have 30GB drives and 256MB RAM
[05:35] <dholbach> I have 40G in my laptop
[05:35] <mvo> I would not mind if it would stop indexing if the space gets tight
[05:35] <pedro_> same here
[05:35] <heno> and we want to support them as well
[05:35] <Amaranth> heno: it uses no (noticeable) CPU
[05:35] <Amaranth> heno: because it only uses idle cycles
[05:35] <jdstrand> what about default off, with a note on first login about how to enable it?
[05:36] <heno> but that still makes the machine noisy, both on laptops and desktops
[05:36] <heno> and will be seen as a regression
[05:36] <asac> jdstrand: i think these kind of popups are usually just ignored by users
[05:36] <jdstrand> asac: I ignore tracker anyway :)
[05:36] <illovae> hello o/
[05:36] <mvo> asac++
[05:36] <heno> jdstrand: if we start down that path we'll soon have 10 pop-ups at boot :)
[05:37] <sourcercito> Amaranth, sure you don't live in south america or africa
[05:37] <Amaranth> heno: so throttle it
[05:37] <Amaranth> sourcercito: you can't even _install_ with 256MB
[05:37] <sourcercito> most people here don't have hard drives that big
[05:37] <sourcercito> yes, i've a 5gb partition to ubuntu, but still
[05:37] <Amaranth> sourcercito: and the size of the index is relative to the size of the stuff on your computer
[05:37] <jdstrand> asac, heno: I see your point, but question that there is a sane default.  It is indeed useful for some of our users, but not others.
[05:38] <Amaranth> so if you have a small HD you have a small index
[05:38] <kwwii> Amaranth: not if I had lots of small files, or?
[05:38] <pitti> mvo's proposal of stopping indexing when space gets tight is good IMHO
[05:38] <jdstrand> asac, heno: could default off with an entry in Ubuntu Help Center
[05:38] <heno> jdstrand: riht, but I think the notice on first search makes more sense
[05:38] <Amaranth> kwwii: well it's not a linear thing
[05:38] <asac> don't we have other features already that are enabled/disabled based on hardware profiles?
[05:38] <pitti> asac: yes, compiz
[05:38] <BenC> laptop mode comes to mind
[05:38] <pitti> asac: and gnome-power-manager
[05:39] <jdstrand> heno: ah-- so it is default off, then when they try to use it the first time, turn it on?
[05:39] <asac> so in case lots of people complain in beta we might wanna think about extending this for tracker?
[05:39] <heno> what about making the checkbox to turn off indexing actually stop the deamon from running?
[05:39] <heno> jdstrand: right
[05:39] <Amaranth> asac: compiz is easier
[05:39] <pedro_> heno: yes please.
[05:39] <Amaranth> asac: it's just a matter of checking features, not performance
[05:39] <asac> another idea would be to show up a tray icon that shows "now indexing" .. which you could right click and say "stop this" ?
[05:40] <mvo> also checking performance before starting compiz would be useful too
[05:40] <jdstrand> heno: I think an 'are you sure' type of thing with a warning about CPU and disk space might be a good idea to think about
[05:40] <jdstrand> heno: on that first try
[05:40] <Amaranth> mvo: afaik all the hardware it actually is capable of running on is fast enough to run it somewhat decently
[05:40] <Amaranth> mvo: i used it on a Radeon 7500
[05:40] <popey> asac: +1, I'd love to be able to stop/pause trackerd when I am playing a game for example
[05:40] <mvo> Amaranth: true, I the slowest I have is a i830 and even that is okish
[05:41] <Amaranth> popey: other than the kernel bug with io scheduling you should not need to
[05:41] <heno> I don't want it to run somewhat decently, I want my desktop to *always* be super-responsive :)
[05:41] <popey> "hah"
[05:41] <Amaranth> popey: it is explicitly designed to use only what is idle
[05:41] <heno> Linux should be able to deliver that
[05:41] <popey> my core2duo 2.6GHz gets murdered by trackerd
[05:41] <Amaranth> popey: in feisty it worked fine :)
[05:41] <heno> unless we shoot ourselves in the foot
[05:41] <Amaranth> popey: like i said, it uses all available _idle_ cpu
[05:41] <Amaranth> popey: so if you play a game it scales down
[05:42] <popey> Amaranth: I understand the theory, but practically it doesn't work like that, it slows down every machine I own, all over 2GHz, most multicore
[05:42] <Amaranth> only the IO is a problem here
[05:42] <heno> a problem is a problem, no matter what the technical reason
[05:42] <Amaranth> this is apparently only a problem with upgrades
[05:42] <popey> indeed, and I'd still like to be able to pause it :)
[05:42] <mvo> and it seems to be something new that was introduced by 2.6.22
[05:43] <Amaranth> so hopefully we'll figure out why
[05:43] <heno> ok, cool. on that note, let's take it to the mailing list
[05:43] <asac> cool
[05:43] <heno> shall swe look at the other Critical beta bugs?
[05:43] <asac> can we take a look at bug 139403
[05:44] <ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/139403
[05:44] <asac> i would like to know if anyone has any hard reasons not to do that?
[05:44] <asac> pleaes read summary
[05:45] <pitti> provided that u-m removes auto/dhcp interfaces from /e/n/i on upgrades, and the installer does not write the stanzas for desktop isntallations
[05:45] <heno> that does seem to be causing a lot of bug reports
[05:45] <asac> pitti: look at bug
[05:45] <asac> pitti: the new suggestion is to make postinst do that
[05:46] <asac> (not u-m)
[05:46] <pitti> asac: urgh
[05:46] <asac> so people that now use network manager for auto dhcp will still use it
[05:46] <calc> another suggestion, have network manager not kill connections on upgrade... (not sure if that is known and/or fixed yet)
[05:46] <asac> while those that have n-m uniinstalled won't see a regression
[05:46] <pitti> asac: 3. needs to be extended to '... for desktop installations'
[05:47] <pitti> asac: since we do want it on servers, CLI, or expert installations
[05:47] <asac> pitti: 3. desktop installer should not add auto dhcp interfaces.
[05:47] <asac>       ^^^
[05:47] <asac> its already in there ... isnt it?
[05:47] <pitti> asac: right, but it should do that for above cases
[05:47] <pitti> oh, *only* ubiquity?
[05:47] <asac> pitti: ok but it shouldn't install nm for those as well
[05:47] <pitti> fine then
[05:47] <asac> pitti: no idea ... i think it should depend on whether nm is installed or not
[05:48] <pitti> right
[05:48] <pitti> then we just need to make damn sure that n-m actually works and always brings up eth0 on boot
[05:49] <asac> i have not many bugs about wired
[05:49] <pitti> asac: what's your experience with that so far?
[05:49] <asac> usually wired works ... if wired doesn't work ifupdown mostly fails as well
[05:49] <mvo> what people with two interfaces? that is not supported by n-m, right? so this needs to be carfully checked
[05:49] <pitti> asac: when I trawled over the n-m bugs the last time, there were a lot of that kind, but I guess this was often due to the 'tears down ifaces on startup' but
[05:49] <pitti> s/t$/g/
[05:49] <asac> pitti: right
[05:50] <pitti> mvo: those need an e/n/i entry mostly AFAICS
[05:50] <asac> what we see now is either "tears down" ... or now ingutsy "nm shows some random interface because we have to active, managed connections"
[05:50] <pitti> mvo: e. g. my secondary interface has static configuration
[05:50] <mvo> right, so the thing that removes stuff needs to check for this, right?
[05:50] <calc> a lot of nvidia based desktop motherboards have two nics on them, btw
[05:50] <Zic> @schedule Paris
[05:50] <ubotu> Schedule for Europe/Paris: 17 Sep 14:00: IRC Council | 18 Sep 18:00: Kernel Team | 19 Sep 14:00: Edubuntu | 19 Sep 22:00: Xubuntu Developers | 20 Sep 14:00: Desktop Team Development | 21 Sep 14:00: MOTU Team
[05:50] <asac> pitti: and if people don't have a network they most likely go to network-admin ... and once they configured the interface there it will be just ifupdown
[05:51] <asac> which doesn't work atm because if you configure just dhcp there, network manager will still manage it
[05:51] <pitti> good point
[05:51] <pitti> asac: but with that, you'll lose the possibility to switch to a wifi, don't you?
[05:51] <asac> no
[05:51] <asac> thats the good thing
[05:52] <asac> you go to network-admin .. configure eth as dhcp ... then you still can use nm for wireless
[05:52] <pitti> asac: but I don't see how "don't touch ifupdown connections" and "use wifi although there is an eth configured" mix?
[05:52] <asac> unless you configure wirelss as "not-roaming" there as well
[05:52] <asac> pitti: please rephrase :) ?
[05:52] <pitti> ok, I plug my laptop into my ethernet and have auto eth0/dhcp
[05:53] <pitti> (in /e/n/i)
[05:53] <asac> yeah
[05:53] <pitti> then I unplug it, and want to use my wifi
[05:53] <pitti> but since n-m doesn't manage eth0 any more, the default route won't be torn down for eth
[05:53] <pitti> (and neither the dhclient)
[05:53] <pitti> i. e. everyone who every uses network-admin will be stuck there
[05:54] <pitti> oh, you can switch it back to 'roaming'
[05:54] <asac> what happens if you have two default routes?
[05:54] <asac> for me it worked
[05:54] <pitti> asac: you lose
[05:54] <pitti> asac: it's a race condition, from my experience
[05:54] <pitti> sometimes it works, sometimes you lose all packets
[05:55] <pitti> it's bit of a corner case, yes, but so far these cases were handled pretty well because n-m actually understood /e/n/i
[05:55] <pitti> I know, choosing between two evils :/
[05:55] <asac> pitti: understood is a bit exaggerated
[05:55] <asac> it broke ifupdown :)
[05:56] <pitti> IOW, once someone configures "dhcp" in network-admin for eth0, n-m will just go to 'static configuration' and not do anything any more
[05:56] <pitti> might be a bit confusing
[05:56] <asac> he?
[05:56] <ogra> who?
[05:56] <asac> it will not go to static ... it will just stop to manage it
[05:57] <pitti> asac: right, but it won't switch interfaces either because you have a manual configuration
[05:57] <asac> can't dhclient listen to hal events?
[05:57] <pitti> unless, of course, n-m continues to actually parse and interpret /e/n/i, but I thought you wanted to get rid of that
[05:57] <pitti> asac: in what way?
[05:58] <asac> remove/add route?
[05:58] <pitti> after all, dhclient *is* the bit that actually configures routes...
[05:58] <asac> i don't mean dhclient .. i mean ifupdown mechanism
[05:58] <ogra> asac, you could use route directly :)
[05:59] <pitti> asac: there's no ifupdownd or something that could do that; what should it do?
[05:59] <ogra> pitti, he wants to remove the defaultroute for that interface if i understood right
[05:59] <ogra> but keep the interface as is
[05:59] <pitti> asac: if we want n-m to override ifupdown routes, then we could make ifupdown use defualtroutes with metric 1
[06:00] <asac> pitti: how would that look like?
[06:00] <pitti> and keep n-m use metric 0 routes
[06:00] <pitti> so that n-m's routes win
[06:00] <asac> yes that sounds reasonable then
[06:00] <pitti> asac: just "metric 1" option
[06:01] <pitti> asac: just think about it as 'priority'
[06:01] <asac> yeah ... were would such a feature be added?
[06:01] <pitti> the lower one wins
[06:01] <heno> We've been going for an hour; let's declare the meeting done and continue this wherever
[06:01] <heno> Thanks everyone
[06:01] <asac> pitti: ok i will add that to the bug and subscribe you
[06:02] <mvo> thanks
[06:02] <pitti> thanks everyone
[06:02] <mathiaz> thanks
[06:02] <dholbach> thanks - see you tomorrow
[06:03] <kwwii> bye


[09:55] <lifeless> gmb: hi
[09:55] <lifeless> since you're here...
[09:55] <gmb> Morning lifeless. What can I do for you?
[09:55] <lifeless> your timeout bug for prod
[09:55] <lifeless> is it ready to CP ?
[09:56] <gmb> lifeless, I believe so; let me check...
[09:57] <lifeless> have you seen the hourly oops graph :P
[10:00] <gmb> lifeless, So yes, it's been merged, but into db-devel (I must've chosen the wrong target for the mp), which is annoying. So:
[10:00] <gmb> 1) I need to prepare a branch to merge it into devel
[10:00] <lifeless> yes, yes you do :)
[10:00] <gmb> 2) I need to do the same for production-stable
[10:00] <gmb> (Or whatever our CP target is these days)
[10:01] <lifeless> have you checked on staging too see if its faster ?
[10:01] <lifeless> thats the really interesting thing for me
[10:01] <gmb> lifeless, It's not on staging yet. We'll have to cowboy it there. I'll grab mthaddon in a few minutes and get that done.
[10:02] <lifeless> \o/
[10:08] <gmb> lifeless, Oh, hang on. It *is* in devel. I guess LP gets confused by the auto-merge from devel to db-devel.
[10:08] <gmb> So, that's a win.
[11:56] <jml> review wanted: https://code.edge.launchpad.net/~jml/launchpad/remove-interface-import/+merge/30375
[11:59] <leonardr> jml, i got it
[12:00] <jml> leonardr, thanks.
[12:00]  * jml off to lunch. back soon.
[12:07] <jtv> gmb, leonardr: time for this one?  Just extracting something to a file of its own.  https://code.edge.launchpad.net/~jtv/launchpad/xpi-dtd-parser/+merge/30383
[12:08] <leonardr> jtv, i'm here all day
[12:08] <jtv> leonardr: great, thanks
[12:33] <leonardr> jtv, just to satisfy my curiosity, what do we use the xpi dtd parser for?
[13:06] <leonardr> jtv, r=me
[13:21] <jtv> leonardr: thanks for the review
[13:21] <leonardr> np
[13:55] <rockstar> Anyone around for a review?
[13:55] <rockstar> gmb, leonardr?
[13:56] <lifeless> rockstar: yo
[13:57] <rockstar> lifeless, you want to do a review?
[13:58] <lifeless> I've done 25 or so in the last 24 hours
[13:58] <rockstar> lifeless, https://code.edge.launchpad.net/~rockstar/launchpad/unsupported-series-recipe-api/+merge/30397
[13:58] <lifeless> so why not :P
[13:58] <lifeless> rockstar: check the +activereviews page :)
[13:59] <rockstar> lifeless, that's funny, because I've been thinking of changing the way I do reviews.
[13:59] <lifeless> is 400 the right error to return ?
[14:00] <rockstar> lifeless, that's what everything else returns.
[14:00] <lifeless> oh!
[14:00]  * lifeless adds that to the list of things to look at
[14:00] <rockstar> I don't even know what 400 is.
[14:00] <rockstar> Ah, Bad Request, I think that's right.
[14:00] <lifeless> 'The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications'
[14:00] <lifeless> its not malformed syntax
[14:01] <rockstar> lifeless, hm, maybe.  I guess REST does try and re-use HTTP descriptions for itself, so I can see the reasoning there.
[14:02] <lifeless> 409/412 maybbe
[14:02] <lifeless> anyhow
[14:02] <lifeless> you're following the pattern
[14:02] <lifeless> thats fine
[14:03] <rockstar> 412 makes more sense than 409
[14:03] <rockstar> Also, it's funny that if I google for "http 40x" the fourth item returned is xkcd...
[15:02] <jtv> gmb, leonardr: I need a taker for a cleanup branch that's over twice the review limit.  Any volunteers?
[15:02] <jtv> https://code.edge.launchpad.net/~jtv/launchpad/test-cruft-soyuz/+merge/30407
[15:02] <leonardr> jtv, i'll look at it
[15:02] <jtv> Great, thanks.  It's basically lint.
[15:02] <jtv> Just lots of it.
[15:02] <rockstar> jtv, out of curiosity, why didn't you do them in small increments?
[15:03] <rockstar> (I've been thinking about proposing a lower limit to review diff sizes, so I'm trying to find out the cause of outliers)
[15:03] <jtv> rockstar: it went rather faster than I expected—first you remove some boilerplate from the tests, then you run "make lint"...
[15:03] <jtv> ...and suddenly you're at 1,400 lines & growing.
[15:03] <rockstar> jtv, have you used bzr-pipes at all?
[15:03] <jtv> This is rather atypical I hope.
[15:04] <rockstar> jtv, yeah, but I think what sinzui talked about in his lightning talk is probably also the secret to my small amount of success.
[15:04] <jtv> Once or twice, but I was scared off by two things: one was some kind of version skew that broke the plugin for me locally, and the other was that I need to look up how it works every time—and then Aaron tells me what I find in the documentation isn't actually how it should be done.
[15:04] <rockstar> So maybe saying "No branch more than 500 lines of diff" would be helpful for everyone's velocity.
[15:05] <sinzui> That is what U1 did
[15:05] <rockstar> jtv, I'm happy to sit down with you and show you how I do it.  It's a lot easier than one might think.
[15:05] <rockstar> sinzui, really?  That's interesting.
[15:05] <sinzui> barry fixed his productivity by timeboxing.
[15:05] <rockstar> sinzui, I'm curious to know what you think about my idea.
[15:06] <jtv> rockstar: I know—I've done it.  But I don't do it _quite_ frequently enough to know that I won't screw it up next time.  If you could go over the online docs and make sure they're correct, that would be more valuable IMHO
[15:06] <rockstar> jtv, yeah, that's probably a good idea.
[15:06] <jtv> I think the limit of 800 was very helfpul, though sometimes you do just have to go over.
[15:06] <rockstar> jtv, yeah, I'm curious if those "you just have to" situations really could be avoided more if we planned for it.
[15:07] <sinzui> 2/4/6 hours should be enough to produce something valuable. also. I have take 2 hours to make 2000 lines of change moving something to lp.registry. The time was the correct limit
[15:07] <rockstar> sinzui, yeah, although I'd contend that 6 hours might be a little high for most cases.
[15:07] <rockstar> I divide my days up into 3 hour increments.
[15:08] <sinzui> I use 2 hours, and I get nervous when I reach 4. I start looking for ways to end the branch immediately
[15:09] <rockstar> sinzui, yeah, but I've noticed that if I'm doing anything that might touch soyuz stuff, it takes a bit longer, because I don't know all of their gotchas just yet.
[15:09] <rockstar> (I know all the code gotchas, and how to avoid them)
[15:09] <bigjools> rockstar: *we* don't know all of the gotchas yet
[15:10] <sinzui> rockstar, I factor that into getting something ready to code, and I use that time to refactor code so that it is clear. tech-debt amounts to a lot of bugs in Lp.
[15:11]  * bigjools is going to have a 1200 line branch soon.  No way around it.
[15:11] <rockstar> sinzui, huh.  That's interesting as well.  A prep branch to go before the actual branch.
[15:12] <sinzui> Salgado does a lot of them. He seems to use it to make the real task easier to do, or at least to remove any distractions from his primary task
[15:14] <rockstar> sinzui, yeah, it's the distraction thing that annoys me.
[15:14] <rockstar> sinzui, I've been performing an experiment with my branch workflow, and my biggest patch is ~450 lines, so I think we really can break them up more.
[15:15] <leonardr> jtv, does lint really complain that there should be a space in ('foo',) ?
[15:15] <leonardr> i never knew that
[15:15] <jtv> leonardr: yup... I discussed with sinzui who confirmed that PEP8 wants it that way.
[15:15] <jtv> (it surprised me as well :-)
[15:15] <sinzui> Maybe this is a conversation for the review's meeting. smaller branches or shorter development time.
[15:15] <rockstar> jtv, I've ignored that (it's stupid...)
[15:16] <sinzui> rockstar, you should submit a patch to pep8.py them
[15:16] <rockstar> sinzui, yeah, before I brought it to the reviewer's meeting, I wanted my own experiment.
[15:16] <sinzui> then
[15:17] <rockstar> Usually, the reviewer's meeting can turn into yak shaving/bikeshedding, so I wanted actual facts (similar to your lightning talk)
[15:27] <leonardr> jtv, the blank line on line 627 of your patch looks strange. is it correct?
[15:28] <jtv> leonardr: looking...
[15:29] <leonardr> jtv: ditto for line 811
[15:29] <jtv> leonardr: yeah... those are how "make lint" wants them.
[15:30] <leonardr> jtv: blank line before any function definition?
[15:30] <jtv> Yes, looks like.
[15:32] <leonardr> jtv, r=me
[15:32] <jtv> leonardr: thanks!  I'll try to bother gmb for the next one, because this just ain't fair.  :-)
[15:33] <gmb> Yes.
[15:47] <leonardr> jtv, for the record i got some test failures when i ran the soyuz tests, but they kind of look like a problem with my larger setup. i can paste them if you want
[15:48] <jtv> leonardr: if they're MissingCelebrityErrors, that's a devel change and "make schema" will help.
[15:48] <leonardr> jtv: no, it started as a GpgmeError ("unknown error code") and then cascaded from there
[15:49] <jtv> leonardr: I think I had those a bit longer ago, and rocketfuel-{setup,get} or something made it go away.
[15:49] <jtv> Do you get them in devel?
[15:49] <leonardr> jtv: i don't know. sorry--i'm fighting another fire and don't want to context-switch unless this is really important to you
[15:50] <jtv> leonardr: not particularly—ec2 will be my judge
[15:50] <leonardr> ok
[15:50] <jtv> gmb: here's one I'd like to ask your review for: https://code.edge.launchpad.net/~jtv/launchpad/exportstorage-cleanup/+merge/30418
[15:52] <gmb> jtv, Righto
[15:52] <jtv> fab
[15:56] <gmb> jtv, Is the VWS on line 61 really necessary?
[15:56] <jtv> gmb: make lint says so
[15:59] <gmb> jtv, Garh.
[15:59] <gmb> Okay.
[15:59] <gmb> I'm not wholly sure the new linter isn't a bit crackful.
[15:59] <jtv> It's a lot stricter—which by and large is a good thing, I think
[16:00] <gmb> jtv, True.
[16:00] <gmb> jtv, Anyway, r=me.\
[16:00] <jtv> \o/ thanks
[19:15] <jtv> leonardr: it's still highly unfair that your co-reviewer buggered off before I could be as demanding with him as I was with you...  got room for a few more?
[19:15] <jtv> I have one small lint cleanup: https://code.edge.launchpad.net/~jtv/launchpad/pre-export-cleanup/+merge/30445
[19:17] <leonardr> jtv, i see a conflict in potemplate.py
[19:17] <jtv> leonardr: thanks...  I'll update my branch & re-push.  Hang on.
[19:22] <jtv> leonardr: to keep you updated: I pushed a while ago but am still polling for the diff to update.  Will let you know.
[19:23] <jtv> leonardr: it's updated.
[19:28] <leonardr> jtv, r=me
[19:28] <jtv> leonardr: cool, thanks
[19:28]  * leonardr will be back in a couple hours in case no one else wants to do reviews
[19:29] <jtv> I'll ask around.  Thanks for all the reviews today!