[08:11] <mandel> morning all!
[08:28] <JamesTait> Happy Monday, everyone! :-D
[11:12] <gatox> good morning!
[11:37] <mandel> gatox, morning!
[11:37] <mandel> gatox, I have a question for you!
[11:37] <mandel> :)
[11:37] <gatox> mandel, shoot
[11:38] <mandel> gatox, I'm fixing bug #1065513
[11:38] <mandel> gatox, it seems to happen because one of the overlays (don't know which) is drawn at the wrong position or something, that is, if you set the lodaing overlay to be a singleton you won't get the second one
[11:39] <mandel> gatox, why do we have server overlays? could we have used a single one and hide and show according to the tab?
[11:40] <gatox> mandel, i'm not sure i understand what you mean.... we are showing the overlay in each tab when the user press in some tab and the info need to be refreshed
[11:41] <mandel> gatox, yes, but we are creating 10 instances of the overlay
[11:41] <mandel> gatox, one for the folderspanel, other for the share links panel, devices etc...
[11:42] <mandel> gatox, the question is, why do we create one for each panel, should we use a single one and use a ref to it to tell it to be shown or not?
[11:42] <gatox> mandel, let me recheck the code
[11:43] <mandel> gatox, the code imports UbuntuOneBin (which I have no clue of what it does) in several places, which is what instantiates the overlay
[11:44] <gatox> mandel, yes... i see it
[11:45] <mandel> gatox, which means that the overlay has more than one sintance and is shown per tab, could mean that the double overlay we see in other systems (I cannot get it on ubuntu) is because of that
[11:45] <mandel> gatox, the ideal way would be to have a single overlay that is shown or not as per request of the tab
[11:46] <gatox> mandel, can you show me a screenshot of the double overlay?
[11:46] <mandel> gatox, sure, give me a sec
[11:46] <nessita> gatox, mandel: I can help with that, if you want
[11:46] <mandel> nessita, one sec, uploading pict so that we all can see the problem :)
[11:47] <nessita> gatox, mandel: if it's what I think it is, "is not a bug is a feature" :-)
[11:48] <nessita> every request that hits the "network" or syndaemon has to show feedback to the user that we're fetching data that may take a while
[11:48] <gatox> nessita, i don't think is a bug either..... but i want to see what mandel means too
[11:48] <nessita> so, when opening the control panel, we fetch 2 different pieces of info
[11:48] <gatox> yes
[11:48] <nessita> the account info, which shows a "global" overlay, covering the whole window
[11:49] <nessita> and the folder info, which shows an overlay only on top of the folder tab
[11:49] <nessita> unifying those could be a little (a lot) complicated
[11:49] <mandel> it is a bug because it looks like this: http://ubuntuone.com/73sN9YTCoGkv4wEIMpsGG3
[11:49] <nessita> cuz each piece of info can arrive a very different times
[11:50] <gatox> mandel, that is exactly what nessita explain
[11:50] <nessita> mandel: yes, is not a bug
[11:50] <nessita> does not look ideal
[11:50] <nessita> but is not a bug
[11:50] <nessita> mandel: each overlay is referrring to different info
[11:50] <mandel> nessita, gatox, is a bug, if there is loading info we should not show redundant information, we should ensure that if the loading overlay is shown we don't show it again
[11:51] <nessita> mandel: that's very very hard to do
[11:51] <mandel> you could have a singlenton in yo which you can register as a timed operation, and you removed yourself when done
[11:51] <mandel> overlay gets the signal I'm done, and if all are done gets out of the way
[11:51] <mandel> nessita, yes, I know it is a lot of work
[11:52] <nessita> mandel: ok, what I care the most if that you don't remove it without understanding why there is 2
[11:52] <nessita> FYI, this is only happening when the account info is retrieved
[11:53] <nessita> then we never show more than one overlay
[11:53] <gatox> mandel, yes........ but you will have a parentship problem if you want a single overlay....... where it can blocks the ui, so when something is loading you can't press other buttons.....  and to avoid that you need to add it in each widget, so you can set the parent and resizeEvent properly
[11:53] <nessita> mandel: also, is worth noting that you should not block the whole ui when fetching info for  single tab
[11:53] <gatox> nessita, ^
[11:53] <nessita> gatox: exactly (what I just also said)
[11:53] <gatox> nessita, yep!
[11:53] <mandel> nessita, yes, that is why if the tab is not visible should be taken into account
[11:54] <nessita> mandel: not sure what that means
[11:54] <mandel> nessita, as in, if a ui element that requires certain info to be ready is not visible do ignore it and do not show the overlay
[11:56]  * mandel hopes he makes sense
[11:57] <nessita> mandel: yes, and that's currently the case
[11:57] <nessita> mandel: if your screenthost, the 2 elements that are showing an overlay are visible:
[11:58] <nessita> the account section, and the folders tab
[11:58] <Chipaca> dobey: ralsina: ping
[11:59] <mandel> nessita, exactly, which repeats the information an adds redundancy that is not needed, a single overlay should be shown in this case for any possible combination, that is account is there and tab is not or the otherway around
[11:59] <nessita> mandel: I agree that a bug is worth reporting to design a proper solution...
[11:59] <mandel> nessita, has been reported already and ralsina pushed it my way, that is why I'm asking the reasoning from doing it like it is done :)
[12:00] <nessita> mandel: reasoning: was the not extremely complex way of doing it
[12:00] <mandel> nessita, ack
[12:00] <nessita> mandel: other ways are pretty complex. If you have any proposal for solving this, I would love to read it and help you decide if it will solve the problem
[12:01] <mandel> nessita, I'll write something about my toughs about it
[12:01] <nessita> mandel: let me know :-)
[12:13] <gatox> mandel, if you have a moment, could you review this one? (small) https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215
[12:17] <mandel> gatox, yes, will do asap
[12:17] <gatox> mandel, thx
[12:19] <mandel> gatox, nessita, a small idea on how to possible change the current implementation: http://paste.ubuntu.com/1280969/
[12:20] <mandel> gatox, nessita, the signal I mention does not have to have an overlay specific name, maybe currentWorkLoad or something like that is better
[12:21] <nessita> mandel: did you read the message I wrote before about not blocking the whole ui when fetching info for a single panel?
[12:21] <mandel> gatox, nessita we might want to talk with lissette to consider how to show the loading oeverlay, may be being over the entire ui is as bad as having two
[12:21] <mandel> nessita, yes, with this idea you will just do so in the first case..
[12:22] <nessita> mandel: how come? if we hav a single instance, that instance will be as big as the whole window, no?
[12:22] <mandel> nessita, we can have two overlays and one do not show the message if the other is (I'm more interested in the idea of using signals to do it)
[12:22] <nessita> or perhaps I'm missing something?
[12:22] <mandel> nessita, yes, you are right, there I did not consider that case
[12:23] <mandel> nessita, could have a single instance for all tabs and one for the account into
[12:23] <gatox> mandel, you can't one instance for all the tabs
[12:23] <mandel> nessita, the one in the account info will show the loading message only if the other overlay is hidden
[12:23] <mandel> gatox, why?>
[12:23] <nessita> mandel: well, the instance for the tabs needs to leave the tabs "out" so the can be clicked
[12:23] <gatox> mandel, because the overlay has as it parent the content of the tabs..... not the qtabwidget
[12:24] <nessita> gatox: so, when fetching shares links info, the user needs to be able to click on devices
[12:24] <gatox> which avoid having the problem nessita mention
[12:24] <nessita> sorry, mandel I meant :-)
[12:24] <nessita> mandel -> so, when fetching --for example-- shares links info, the user needs to be able to click on devices
[12:24] <nessita> so we can't have an overlay per the whole tab group
[12:25] <gatox> and that's why you can't use singleton either
[12:25] <mandel> nessita, gatox, hm... then maybe same number of instances, make the tab overlay instances be in-sync with the accounts overlay via signals
[12:25] <mandel> gatox, I hate singletons in most use cases :)
[12:25] <mandel> nessita, gatox, so that account info overlay instance know when to show or not the loading message
[12:26] <nessita> mandel: not sure how that solution would be implementable...
[12:26] <nessita> mandel: any chance you outline the specifics a little more?
[12:27] <mandel> nessita, sure, fancy to talk over mumble, I think we would agree faster :)
[12:27] <gatox> mandel, yep..... i would like to mumble..... i have some questions about that
[12:27] <nessita> mandel: I'm at the phone right now, could be in mumble in 15'...
[12:28] <nessita> mandel: but you can mumble with gatox, he understands the issue :-)
[12:28] <nessita> * I think * :-P
[12:28] <mandel> nessita, I'll mumble with gatox and then  I'll take some of you time after my lunch hehe
[12:28] <nessita> go ahead
[12:28] <mandel> gatox, to the mumble cave!!!
[12:28] <mandel> nananana
[12:35] <ralsina> good morning!
[12:35] <gatox> ralsina, hi
[12:38] <ralsina> nessita, mandel: what we need is all overlays to be in the exact same place. That way, if we have the window-overlay, we don't see two ;-)
[12:39] <ralsina> but that is mostly a cosmetic fix
[12:39] <mandel> ralsina, wet think we have a better approach
[12:39] <mandel> ralsina, join mumble :)
[12:39] <ralsina> mandel: can't, sorry
[12:39] <mandel> ralsina, fuuuu
[12:39] <ralsina> mandel: but I am all for better approaches ;-)
[12:39] <mandel> ralsina, ok, so, they can't all be in the same place because they don't know about each other
[12:40] <ralsina> mandel: nah, it's trivial
[12:40] <ralsina> mandel: so, I don't believe you ;-)
[12:40] <mandel> ralsina, gatox and I were thinking of removing the one from the account panel and add a loading gif to the name and siable the button
[12:40] <mandel> ralsina, then add the name and th enable the button when done
[12:40] <mandel> super simple
[12:40] <mandel> and no hack needed
[12:40] <ralsina> "button"?
[12:40] <gatox> the connect/disconnect
[12:40] <alecu> hello, all!
[12:41] <ralsina> mandel: is that the only bit that blocks the whole window?
[12:41] <ralsina> mandel: if yes,  +1 and remove the global overlay
[12:41] <mandel> ralsina, for the accounts, yes
[12:41] <nessita> gatox: no need to disable the connect.disconnect button
[12:41] <mandel> nessita, me, right :)
[12:41] <gatox> nessita, ah..... true
[12:41] <nessita> mandel: ^ since is not related to fetching account info
[12:41] <mandel> nessita, even better!
[12:42] <mandel> nessita, ralsina, gatox we just do it for the name and done :)
[12:42] <gatox> so, easier.... just replace the name label
[12:45] <mandel> sounds like a great way to solve it then
[12:45] <mandel> I'll speak with lisette after lunch about it
[12:46] <mandel> now, time for me to have food :)
[12:47] <gatox> dobey, let me know when you are here please..... now i can access tarmac.... but it seems it can do bzr branch there....... this thing hates me
[12:47] <gatox> it can't
[12:50] <dobey> gatox: ssh -A
[12:50] <gatox> dobey, checking.... thx
[12:50] <dobey> Chipaca: hey, what's up?
[12:51] <dobey> gatox: but i pulled your branch on that instance and ran the tests, and they passed
[12:52] <gatox> dobey, what?!....... why is failing then?!
[12:52]  * gatox cries
[12:52] <dobey> i have no idea
[12:52] <gatox> :(
[12:53] <Chipaca> dobey: hey. Nothing, in the end.
[12:53] <Chipaca> dobey: crises averted.
[12:53] <dobey> great
[12:53] <ralsina> hello dobey, welcome back!
[12:54] <gatox> dobey, ah! and welcome back! :D
[12:54] <dobey> thanks
[12:57] <gatox> ralsina, so..... i'm running the tests manually in tarmac..... and they all pass!!.... but i have u1-cp branches bouncing on launchpad.... should i try to re-accept them again or that is the definition of insane?
[13:12] <ralsina> gatox: that's very strange. Locale?
[13:13] <ralsina> gatox: also it doesn't look like a timing issue at all... perhaps something in the PYTHONPATH is different in tarmac?
[13:13] <gatox> ralsina, locale??..... but i'm running them on tarmac too.... and they pass for me and dobey when i execute the tests manually
[13:13] <dobey> gatox: no, tarmac runs with en_US.UTF-8
[13:14] <gatox> dobey, that no was for me or ralsina ?
[13:14] <dobey> gatox: for you, it's not the locale
[13:14] <gatox> ah yes.... i suppose it's not
[13:14] <dobey> and it's almost certainly not the PYTHONPATH either
[13:15] <gatox> i just tried to re approve the branch....... crazy things happend....
[13:15]  * gatox finger cross
[13:16] <dobey> gatox: i did that on your previous branch it failed again with the same errors, so i'm not sure that will help
[13:16] <gatox> dobey, nop..... it didn't work again......
[13:17] <gatox> this is driving me crazy
[13:20] <gatox> quick errand....... brb
[13:28] <dobey> gatox_brb: well, one branch just merged ok
[13:30] <dobey> gatox_brb: and why did you delete https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/shares-broken/+merge/128108 ?
[13:36] <dobey> gatox_brb: though i think i see why your branch is failing; not sure exactly the cause, but i think i know what change is triggering it
[13:37] <gatox_brb> back
[13:38] <gatox> dobey, i deleted that branch.... because it was a workaround for the mac release..... and didn't land on trunk before i proposed the proper solution for the issue... so it's not actually needed anymore having the other branch
[13:39] <ralsina> gatox: don't delete branches, reject them
[13:39] <gatox> ralsina, ack
[13:39] <dobey> gatox: what ralsina just said; deleting them is discourteous
[13:41] <ralsina> gatox: on tarmac, are you just branching your code, or branching trunk and merging it?
[13:41] <gatox> ralsina, branching my code...... i'll try merging
[13:43] <gatox> ralsina, same result
[13:43] <ralsina> gatox: so, it passes?
[13:43] <gatox> ralsina, yes
[13:43] <ralsina> gatox: ok, we can do a nasty thing :-)
[13:43]  * gatox accepts anything
[13:43] <ralsina> gatox: you could add some prints in your branch and try to merge again
[13:44] <gatox> ralsina, why?
[13:44] <gatox> why some prints i mena?
[13:44] <ralsina> gatox: because it's failing with first argument of unbound method must have type 'QThread'
[13:44] <ralsina> gatox: and I want to know exactly what thing it believes is an unbound method
[13:44] <gatox> ralsina, ahhhhh you mean to debug it
[13:44] <ralsina> gatox: exactly
[13:45] <gatox> ralsina, ack..... i'll do that!
[13:45] <ralsina> gatox: worst case, it merges with a print and dobey hunts you down ;-)
[13:45] <gatox> jejeje
[13:46] <dobey> the merge *could* be broken
[13:48] <dobey> nope
[13:48] <dobey> passes merged for me
[13:48] <dobey> so probably timing
[13:48] <gatox> dobey, yep.... for me too
[13:48] <gatox> passed i mean
[13:49] <gatox> mande|lunch, after lunch, review this one too if you can: https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/pointing-hand/+merge/129502
[13:50] <dobey> gatox: i don't quite understand what the changes in test_share_links_search.py have to do with the rest of the branch
[13:51] <dobey> gatox: and i suspect those changes are what's breaking this
[13:53] <gatox> dobey, that is actually fixing a timing issue that we used to have....... and making sure that the QThread is not executed as a thread
[13:55] <dobey> gatox: can you file a separate bug for that issue, remove those changes from that branch, and put them in a new branch for the new bug?
[13:55] <gatox> dobey, of course..... will do that
[13:55] <dobey> thanks
[13:56] <dobey> gatox: please ping me when u1-cp-publishapi branch is updated to not have those changes, and we'll try to merge without them
[13:56] <mandel> gatox, ok
[13:57] <gatox> dobey, ack
[13:57] <gatox> mandel, thx
[13:58] <dobey> anything else blow up while i was away? or just gatox's branch?
[13:59] <mmcc> hi folks, welcome back dobey! hope you had a good break
[14:01] <dobey> thanks; and eh, it was not as good as was planned; weather failed me
[14:06] <ralsina> dobey: just gatox's
[14:06] <ralsina> good morning mmcc
[14:06] <ralsina> mmcc: how hard would it be to make a separate build for 32 bit macs?
[14:06] <dobey> hrmm
[14:06] <dobey> u1cp windows tests seem to be failing
[14:07] <mandel> gatox, here: https://code.launchpad.net/~diegosarmentero/ubuntuone-client/deflated-size/+merge/129215 why changing the name from size to deflated_size ??
[14:07] <briancurtin> dobey: there are failures on a bunch of windows projects, mostly because jenkins has been down recently so they snuck in
[14:07] <briancurtin> dobey: and jenkins doesnt actually work right now (working on it)
[14:08] <dobey> briancurtin: this seems to be like it's got a messed up checkout or something
[14:08] <mmcc> ralsina: I'm not sure. Definitely requires some tweaking on the fsevents daemon to get it 32-bit compatible - it uses objc language features that are only in the 64-bit runtime…
[14:08] <gatox> mandel, check the bug description: https://bugs.launchpad.net/ubuntuone-client/+bug/1062729
[14:09] <dobey> briancurtin: but i'll leave it to you then :)
[14:09] <briancurtin> dobey: i'm probably going to rebuild the setup since it has some out-of-date stuff and should be on the same setup we're running on dev boxes
[14:09] <dobey> briancurtin: sounds good
[14:10] <ralsina> mmcc: ack, it's worth investigating
[14:10] <ralsina> mmcc: we got one request for the 32-bit version at least
[14:10] <briancurtin> all: i'm going to post my standup done/todo now because i need to head to a doctor's appointment (bad time choice, i know). i came early and will stick around late depending on how long this takes
[14:10] <briancurtin> DONE: adjusted the sso bin-finding branch to work with the u1client branch, so now u1cp on windows works fine. two small branches to review: https://code.launchpad.net/~brian.curtin/ubuntuone-client/correct-subprocess-args/+merge/129506 and https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442
[14:10] <briancurtin> TODO: look at jenkins (done a bit this morning) because it still isn't running the tests, but it executes a bunch of pre-test steps. review a few branches that have backed up
[14:12] <briancurtin> (ammendment to the TODO - probably just rebuilding the jenkins setup to make it easier)
[14:12] <mmcc> ralsina: ok. I'll see if there are any other issues for 32.
[14:12] <ralsina> mmcc: at least knowing what needs to be done
[14:13] <mmcc> ralsina: ok
[14:25] <mandel> gatox, oh, ok
[14:26] <mandel> gatox, both reviews done
[14:27] <gatox> mandel, thx..... approved or need fixing?
[14:27] <mandel> gatox, both +1
[14:27] <gatox> mandel, awesome! thx
[14:41] <gatox> dobey, the branch has been modified
[14:49] <mmcc> ok, just sent an email about using PyObjC for the menu. In short, I think it's a good idea (and it's working in code). But I'm sensitive to the fact that it's adding to the number of languages & frameworks we need to know to maintain the code…
[14:51] <ralsina> mmcc: how does it affect binary size? It's a very minor concern.
[14:51] <ralsina> mmcc: also, does it add any packaging complexity?
[14:52] <chaselivingston> mmcc: you can probably kill this bug report, asked the user to submit a ticket in support. https://bugs.launchpad.net/ubuntuone-client/+bug/1066920
[14:54] <mmcc> ralsina: good questions… binary size - negligible. just a few K for PyObjC python code, no new frameworks (just loads the AppKit that's already there, and that's OK to do.)
[14:55] <mmcc> ralsina: packaging complexity, not really. need to tweak things around to have the menu be a separate process anyway, this would roll into that
[14:55] <ralsina> mmcc: ok, so no new concern there
[14:55] <ralsina> mmcc: I don't expect it to be a complex program, as long as the reactor and pyobjc get along
[14:55] <ralsina> mmcc: not much more than current systray.py at least
[14:56] <mmcc> chaselivingston: that's a dupe, I'll find the orig. It sounds like maybe we need to add a FAQ about where the logs are on osx -- the reporter was looking in ~/.cache, but they're in ~/Library/Caches/ubuntuone
[14:56] <mmcc> ralsina: it's about the same, yeah.
[14:57] <ralsina> mmcc: so +1 from me, and better now than later
[14:57] <chaselivingston> mmcc: right, my script can get those if you want to tell them about that as well
[14:57] <mmcc> ralsina - oh I forgot something in the email: I haven't tried this yet - of course :) - but I do think we can use trial to test this thing, so we don't have to adopt a new test framework
[14:57] <ralsina> mmcc: good one ;-)
[14:58] <dobey> ralsina: do we actually need a reactor in the process though?
[14:58] <ralsina> dobey: yes for the IPC
[14:58] <dobey> oh, right :-/
[14:59] <ralsina> dobey: on mac/win we pretty much always need a reactor
[15:00] <thisfred> me?
[15:00] <gatox> me
[15:00] <dobey> me
[15:01] <alecu> me
[15:01] <mmcc> me
[15:02] <thisfred> DONE: wrap u1db TODO: ?? BLOCKED: no NEXT: gatox
[15:02] <dobey> gatox: hah, and your branch merged without those changes. so that set of changes is triggering another issues it seems :)
[15:02] <gatox> DONE:
[15:02] <gatox> Proposed a couple of branches for control panel. A lot of ssh configurations and fights trying to connect to tarmac. Tested bouncing branches there. Refactor bouncing branch and updated. Working in another branch for the qthread problem.
[15:02] <gatox> TODO:
[15:02] <gatox> Proposed a fix for the race condition with qthread.  Worked on bug 1065513 with nessita and gatox, talk with lisette on the design ideas.
[15:03] <mandel> TODO: Organize possible travels, get bug 1065513 fixed. 1-1
[15:03] <mandel> BLOCKED: no
[15:05] <ralsina> gatox: wha? it merged?
[15:05] <mmcc> oh I forgot one more thing about PyObjC: method names like "NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_" make the pep8 checker go nuts. :|
[15:06] <mmcc> (or pyflakes, I forget which. line length, anyway)
[15:06] <gatox> ralsina, yes..... i'm proposing another branch with the qhtread thing to avoid the race conditionn
[15:06] <alecu> mmcc, ralsina: while we are on the pyobjc discussion, let's keep in mind that it's a bit undermaintained, and that support for python 3 is hacky at best: http://blog.pythonaro.com/2012/08/how-to-compile-pyobjc-for-python-3-on.html
[15:07] <mandel> mmcc, you can always tell it to ignore a file (pep8 I guess is the one complaining)
[15:08] <mandel> mmcc, if this is in ubuntuone-client is pyflakes in the others is pylint
[15:08] <mandel> mmcc, in pylint you can use a # pylint: disable=#NUMBER
[15:08] <mmcc> alecu: yes, good point - ronald is the only person actively working on it. py3 support is what he's most actively working on, though. And the website is so far behind that I actually volunteered to help fix it
[15:09] <alecu> mmcc: nice
[15:09] <mmcc> mandel, in my case it's emacs highlighting lines from the result of both pyflakes and pep8.py, so still :|
[15:09] <dobey> mandel: the long line thing is probably pep8
[15:09] <mandel> dobey, I think so too
[15:10] <mandel> mmcc, well, that is a diff story, but if you ignore them tarmar will let you merge the branch, else it will be blocked
[15:10] <mmcc> alecu: and despite low # of active committers, people do use pyobjc for real shipping things. I'm not sure if that means it'd get picked up if ronald stopped, but it's something.
[15:10] <dobey> mandel: i guess this isn't in a branch yet exactly?
[15:11] <mandel> mmcc, why not using ctypes?
[15:12] <mmcc> mandel because ctypes is for C. calling ObjC with a C interface would mean reimplementing PyObjC, basically
[15:12] <mandel> oh, ok
[15:12] <mmcc> every message send in objc boils down to a C call to objc_msgsend(), so I'd need to wrap that, depythonify data structures, etc etc, boom I've rewritten pyobjc, badly :)
[15:12] <alecu> :-)
[15:14] <ralsina> alecu: keep in mind that we will stay py2 on windows for a long time, so probably makes no difference to stay py2 on mac as well
[15:15] <dobey> ralsina: it would be nice to consider dropping python 2.6 (and with it, the classic non-GIR gobject bindings) at this point though
[15:15] <ralsina> dobey: that only affects lucid, right?
[15:15] <dobey> lucid is the only active ubuntu version that uses 2.6, yeah
[15:15] <alecu> ralsina: right, I just want us to have in mind the limitations of pyobjc. And it would be nice having the possibility of switching everything to 3 when we have the chance.
[15:16] <dobey> and the only reason we still support 2.6 in the client at all really, is for some of the tests that run on the server which is still on lucid
[15:16] <mmcc> something else I forgot about - I think this might be best done as a separate project, if only because of the different test requirements (i.e., shouldn't have tarmac block on pep8 errors)
[15:17] <mmcc> but I'm not sure it needs to be separate, it just seemed simpler…
[15:17] <alecu> dobey: right, gatox had to do some fixes very recently because of the server running on lucid.
[15:17] <dobey> mmcc: it should probably be a separate project just because it doesn't have any proper direct relation to the others
[15:17] <ralsina> dobey: yes, we can't drop 2.6 until the end of this cycle because of the server tests
[15:17] <dobey> ralsina: until 12.10 or until 13.04?
[15:18] <ralsina> 13.04
[15:18] <mmcc> dobey: well, it imports from all of them, but yeah, it is a distinct thing.
[15:18] <dobey> mmcc: it imports from things other than u1-client?
[15:19] <ralsina> facundobatista: the timeline for switchng the servers to precise is 13.04 right?
[15:20] <mmcc> dobey: it imports strings from control panel and syncdaemontool from u1-client, which ends up getting credentials from sso
[15:21] <gatox> ok..... lunch here
[15:21] <mmcc> brb
[15:22] <dobey> mmcc: hrmm, the menu strings? i thought u1client had those strings as well?
[15:25] <mmcc> dobey: maybe it does. I didn't look… I'll make a note
[15:27] <dobey> mmcc: i think it does, as the strings for the menu on ubuntu are in u1-client
[15:27] <dobey> we probably need to fix control panel to import them from u1-client instead of having copies
[15:31] <mandel> ralsina, gatox_lunch I'm aiming to get this as per design: https://docs.google.com/a/canonical.com/presentation/d/13LMJQfBA3NgbRZ82j4Il1lkutg0mR03WpJA87epw1j4/edit#slide=id.g20c9f360_0_37
[15:31] <mandel> is more work, but is better to get it done the right way
[15:37] <alecu> mmcc: oh, I'm just reading your email, and it already addresses my pyobjc concerns. Doh :-)
[15:39] <dobey> ok, need to get lunch; bbiab
[15:42] <ralsina> mmcc: looking...
[15:42] <ralsina> that was for mandel. So, mandel... how? ;-)
[15:43] <mandel> ralsina, add an extra layout for the entire things that depends on the content of the name, leave the account pane with no layout
[15:43] <mandel> ralsina, the rest works the same
[15:43] <ralsina> mandel: ok, want to see it
[15:43] <ralsina> mandel: so go ahead :-)
[15:44] <mandel> ok
[15:44] <mandel> ralsina, that sounded like a challenge hehe
[15:50] <briancurtin> back after 1:45 complete waste of time
[16:10] <alecu> briancurtin: what happened?
[16:11] <briancurtin> "oh, you have an appointment? we don't do monday appointments since they doctors aren't here today" - "oh..." - "who set your appt up?" - "cathy" - "that's me"
[16:12] <briancurtin> so i guess the real appointment is now thursday if i can trust them
[16:12] <alecu> mandel: there's one catch with that design
[16:12] <mandel> alecu, tell me
[16:13] <alecu> mandel: when starting, the "getting information" bubble will move at some point, when the account info is retrieved, but the folder info is not yet.
[16:13] <alecu> mandel: so, it will appear to "jump".
[16:13] <mandel> alecu, true
[16:13] <mandel> alecu, and that is not good at all
[16:14] <mandel> lisettte, ^^
[16:14] <alecu> mandel: my opinion is that it should remain in a fixed place, and yes, the tabs and the top could be "unobscured" when the account info is available.
[16:15] <lisettte> alecu, mandel: depending on what the 'jump' looks like, it seems better for users to have all the functionality they can have in the shortest possible time
[16:15] <mmcc> yeah, let's please not make it jump around. even the font resizing when the quota percentage is finally drawn is annoying enough.
[16:16] <lisettte> alecu, mandel: what exactly is going to jump?
[16:16] <alecu> lisettte: the "getting information bubble"
[16:16] <mandel> lisettte, it will move down a little
[16:16] <alecu> lisettte: in slide 5 the bubble is many pixels below, compared to slides 3 and 4
[16:17] <lisettte> alecu, mandel: we should see how this works in reality, but it seems we need the partial cover anyway: right now it shows me the waiting animation briefly every time i move to a different tab
[16:18] <mandel> lisettte, yes, that is because it does a request for every tab change
[16:18] <lisettte> alecu, mandel: i am not sure it is a huge problem for it to move down
[16:18] <mmcc> might be a big change, but can we fix this instead by storing locally the username and quota and just not displaying the loader for the account info? Seems crazy to wait 10 seconds to see my name.
[16:18] <alecu> mmcc: your name comes free when we request the available space
[16:18] <lisettte> alecu, mandel: the alternative is to cover it until everything is available, which was my first choice, but then we would still need the partial cover for moving between tabs?
[16:19] <mandel> is just that the name is the most notizable pieze of info
[16:19] <alecu> mmcc: and the quota should be updated when we start, right?
[16:19] <lisettte> alecu, mandel: which would be 4 states
[16:19] <mandel> lisettte, alecu, yes, if you want to move between tabs that is the issue, if you add an overlay on top the tabs wont be clickable
[16:20] <mmcc> alecu: the name comes free but slow!  the quota could be out of date for a few seconds, or just display a dash instead of the actual percentage…
[16:20] <lisettte> mandel: can you show us how irritating the jump is? it seems the least of all evils
[16:20] <mandel> lisettte, sure, I'll have that done by tom and we can see how bad it is
[16:21] <mandel> I'm close to my EOD
[16:21] <lisettte> mandel: awesome!!!!! :)
[16:21] <alecu> mandel: I see what lisette proposes now: when starting, let's keep everything occluded until the folder info is retrieved
[16:21] <mandel> alecu, lisettte, I'll do both options and will record a video so we can choose
[16:22] <mandel> is better to see it
[16:22] <lisettte> mandel: saweet!
[16:22] <alecu> mandel: that means having some logic in the first tab to know this is the starting, and not the switching...
[16:22] <mmcc> alecu: and the first tab could be any tab
[16:22] <mandel> alecu, mmcc, is not the first tab, but the main widget
[16:22] <mandel> which is diff
[16:22] <mmcc> ko
[16:22] <mmcc> er ok
[16:22] <alecu> mmcc: I believe that it was chosen not to cache the name, because it was something that could be changed on the website.
[16:23] <gatox> mandel, so..... is going to be the option with the whole overlay?
[16:23] <alecu> mmcc: but yes, I agree that it's slow, and ugly
[16:23] <mmcc> hmmm.
[16:24] <alecu> mmcc: perhaps we can poke nessita to explain the reasons not to cache the name and total available quota in the control panel (at least until they are updated by the first webcall to the account api)
[16:24] <mmcc> not caching the quota makes some sense, since the cached quota could be wrong often, but the cached name would never be wrong for almost everyone...
[16:25] <alecu> gatox: not with the whole overlay. The whole overlay when starting, the per-tab overlay when switching tabs.
[16:25] <gatox> alecu, yes.... that's what i mean
[16:25] <alecu> gatox: I understand that. mandel can confirm.
[16:26] <mandel> alecu, exactly, use a global overlay for the first time, use tab overlays later..
[16:26] <mandel> is not a simple solution though ..
[16:28] <mandel> I'm nearly done with the first solution, I'll continue tom and we can decide then
[16:28] <mandel> now, I need to EOD
[16:28] <mandel> catch you all tom!
[16:29] <alecu> mmcc: bybye!
[16:30] <gatox> alecu, mmcc is not leaving :P
[16:30] <alecu> I meant mandel, sorry :P
[16:30] <mmcc> gatox: shhhh, I was making brunch plans
[16:31] <mandel> lol
[16:31] <alecu> mmcc: so, checking the code, it seems that the account webcall is used to get the subscription plan details. Then a different call is used for the quota, but the results are returned together.
[16:32] <alecu> my guess is that the quota webcall might be taking significantly longer.
[16:32] <alecu> (because of server processing)
[16:32] <alecu> but I better test irl.
[16:33] <alecu> also, we are doing the quota call only once, when starting. So while the control panel is started, the quota info won't ever be changed.
[16:34] <mmcc> so if you click on the button to get more storage and get more storage, the quota will be wrong? hmm… be nice to update that
[16:36] <mandel> alecu, mmcc, it should as updated as possible
[16:36] <alecu> mmcc: also, if you run out of u1 space, you get a popup warning you about that, but you look at the control panel and it says otherwise.
[16:39] <ralsina> alecu: we do need to make that a looping call. That it's never updated is a linux-ism since there u1cp is not a persistent process, but something that starts/stops every time the user looks
[16:40] <alecu> ralsina: yes, absolutely.
[16:40] <mandel> ralsina, but if the user does have the control panel opened for longs periods you will have the same problem
[16:41] <alecu> mandel: yes, but it's much more frequent on win/mac, since even when the user closes the window, the process persists.
[16:41] <ralsina> alecu, mandel: so, gather that info in sd and signaling out to u1cp and the indicator?
[16:41] <mandel> ralsina, alecu, it does make sense that this is more on the sd side... since it is all the time running for sure
[16:41] <ralsina> mandel: exactly
[16:42] <ralsina> same pattern as we are using for the sync menu, more or less
[16:42] <dobey> hmm
[16:42] <alecu> interesting tidbit: when starting u1cp, these webcalls are done *twice* :P
[16:42] <alecu> account call: 1.9406189918518066
[16:42] <alecu> account call: 2.4485630989074707
[16:42] <alecu> quota call: 0.28434205055236816
[16:42] <alecu> quota call: 0.3152000904083252
[16:43] <mmcc> alecu, yep I've noticed that too… I think one of them gets cached now, since I added a deferred lock around them (or was that just the credentials?)
[16:43] <ralsina> alecu: Measure twice, cut once?
[16:44] <mmcc> hm, maybe I'm thinking about getting the credentials, never mind.
[16:44] <alecu> mmcc: is that on trunk?
[16:44] <mmcc> alecu: yeah, it's from a while back, let me look
[16:45] <dobey> meh
[16:46] <mandel> mmcc, I think is the creds
[16:46] <mmcc> yeah, I was thinking of this one: https://code.launchpad.net/~mikemc/ubuntuone-control-panel/fix-credentials-race
[16:47] <mandel> that code is a little messy
[16:47] <mandel> well, I really need to go now
[16:47] <mandel> laters all!
[16:48] <mmcc> huh, so this is weird - this is merged, but doesn't have a MP: https://code.launchpad.net/~mikemc/ubuntuone-client/guard-ipc-connect
[16:49] <dobey> mmcc: you probably had the changes included in another branch
[16:49] <gatox> anyone else is having problems trying to push code to launchpad?
[16:50] <dobey> gatox: wfm
[16:50] <gatox> mm..... i'll reconnect
[16:51] <mmcc> dobey: that makes sense, but I can't guess which branch it'd be… oh well
[16:53] <dobey> mmcc: http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/revision/1302#ubuntuone/platform/ipc/ipc_client.py
[16:55] <mmcc> dobey: indeed. thanks
[16:57] <gatox> need to restart
[16:58] <briancurtin> ralsina: in order to fix jenkins i think i'd like to redo its setup to be based on buildout. i never got around to doing that, partly since it worked via the old "install everything globally" way it was done before. however, now it needs buildout. the question is: can i create a new project in LP to house the scripts/devsetup folder of windows-installer, especially since its now sufficiently cross-platform?
[16:58] <nessita> alecu: hi, just saw your ping
[16:59] <dobey> briancurtin: the plan was to just rename windows-installer to something more amiable to what we actually do with it
[16:59] <dobey> briancurtin: so i'd say just keep it in there, and we'll rename it when we get the chance
[16:59] <briancurtin> dobey: well it does have some code for windows installer stuff
[16:59] <nessita> alecu: no reason for caching other than not having the infrastructure in place within the project (meaning there is no current caching, so you need to persist the info somehow)
[16:59] <dobey> briancurtin: yes, and mac 'installer' stuff
[17:00] <dobey> mostly that project is 90%+ buildout though
[17:00] <dobey> the windows-specific actual installer bits are very minimal
[17:02] <ralsina> briancurtin: I don't see a reason for another project, besides the bad naming
[17:02] <ralsina> briancurtin: so, let's keep it there
[17:08] <alecu> lunch and bank time for me.
[17:12] <gatox> just a heads up....... my connection is working like crap today
[17:20]  * ralsina lunches
[17:20] <gatox> did you get my message about my connection being crap?
[17:20] <gatox> anyone?
[17:20] <dobey> no
 just a heads up....... my connection is working like crap today
[17:20] <briancurtin> gatox: i got it
[17:20] <dobey> lol
[17:20] <briancurtin> :)
[17:20] <gatox> jeje thx
[17:20] <gatox> dobey, troll
[17:20] <gatox> jeje
[17:21] <mmcc> I only see gatox's vowels
[17:21] <dobey> haha
[17:24] <alecu> beats seeing gatox's bowels
[17:25] <gatox> dobey, so now we should try to land this one :P https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[17:25] <gatox> alecu, ^
[17:26] <dobey> gatox: it will fail
[17:26] <gatox> dobey, ok..... i'll do here what roberto suggest..... and put a couple of prints so i can debug it when it fails
[17:28] <dobey> gatox: i've needs fixing it. can you please document in the bug report description the actual failure cases when the race occurs?
[17:29] <gatox> dobey, ok
[17:44] <dobey> muahahahah
[17:44] <gatox> dobey, what happend?
[17:44] <dobey> i think i fixed the overzealousness of "redefinition of unused var" in pyflakes
[17:45] <gatox> dobey, thank you :'D jeje
[17:54] <dobey> i have no idea how to propose the change to upstream though, or how to run their test suite
[17:55] <dobey> but presumably i also have to fix some tests
[17:59] <gatox> mmcc, ping
[18:00] <mmcc> pong gatox
[18:01] <gatox> mmcc, sorrry to bother you again with this.... i had the tab opened with the change to remember, but firefoxx decided that my tabs weren't important.... can you  remind me again the line in u1-cp that should be commented in order to run the testts please?
[18:01] <mmcc> gatox: sure, np. just a sec
[18:01] <gatox> mmcc, thx
[18:04] <mmcc> gatox http://paste.ubuntu.com/1281605/
[18:04] <gatox> thx
[18:07] <dobey> ugh
[18:13] <gatox> dobey, please let me know if this is ok for you: https://bugs.launchpad.net/ubuntuone-control-panel/+bug/1066894
[18:18] <dobey> gatox: those failures happen consistently on osx?
[18:19] <gatox> dobey, yes for me
[18:19] <gatox> dobey, running just that script.... i've seen it pass sometimes
[18:19] <gatox> but few
[18:20] <dobey> hrmm
[18:20] <gatox> dobey, i have a really slow machine for osx
[18:22] <dobey> gatox: can you run the tests with QTHREAD_MAX_IO_WORKERS=0 to see if they pass then? or maybe QTHREAD_AFFINITY="no"?
[18:23] <dobey> these failures are quite odd indeed
[18:23] <gatox> dobey, sorry.... where i should add that?
[18:23] <dobey> gatox: those are environment vars
[18:24] <gatox> ack
[18:24] <dobey> i think they work with qt4 anyway
[18:24] <dobey> of course, this may be a completely different qthread library i'm looking at documetnation for
[18:25] <dobey> indeed i am
[18:25] <dobey> so nevermind those vars :(
[18:25] <dobey> with
[18:25] <dobey> err
[18:25] <dobey> sigh
[18:25] <dobey> so i don't know
[18:25] <dobey> i guess just try the prints then :-/
[18:26]  * dobey also wonders how to get details for import aliases in python _ast
[18:28] <gatox> dobey, but the failures makes sense.... the patching is happening after the function is called..... so it executing everything in a thread instead as part of the same flow.....
[18:29] <gatox> and the branch fix that..... but for some reason is failing in launchpad..... so i'll need to debug that with lots of prints
[18:31] <dobey> ok
[18:31] <briancurtin> ugh. i think im going to try and remove all dependence on windows batch files. they are constant pain and we have python right in front of us...
[18:32] <dobey> briancurtin: do it! :)
[19:21] <gatox> dobey, should we try to land this branch? https://code.launchpad.net/~diegosarmentero/ubuntuone-control-panel/u1-cp-qthread/+merge/129722
[19:21] <gatox> dobey, or should we ask for reviews?
[19:21] <gatox> s/we/i
[19:22] <dobey> i don't know
[19:22] <gatox> ralsina, ping
[19:23] <dobey> gatox: i guess i'll try to land it
[19:23] <dobey> since it will almost certainly fail
[19:23] <gatox> dobey, please....... so i can check the prints
[19:23] <gatox> dobey, because the fix is right....
[19:24] <dobey> well, not entirely i guess
[19:24] <gatox> dobey, maybe..... or maybe launchpad is crazy somehow
[19:24] <ralsina> gatox: pong
[19:24] <dobey> it has nothing to do with launchpad
[19:24] <dobey> or how crazy it might be
[19:25] <gatox> ralsina, nothing..... it was to ask you if we could try to land the branch that has the qthread tests fix and is causing problems.... but dobey already said that he will try to land it.... so we can see the prints
[19:35] <ralsina> gatox: ack
[19:39] <dobey> also ugh for last minute critical bug that we should have caught a year ago :-/
[19:40] <mmcc> looks like my connection is patchy here, probably because I'm testing upload progress bars IRL.
[19:45] <dobey> gatox: ah i see what's wrong
[19:45] <gatox> dobey, with mmy branch?
[19:45] <dobey> gatox: well i think the problem was already there, and your branch just exposes it finally
[19:45] <gatox> dobey, tell me please
[19:47] <dobey> gatox: actually, this branch seems to have two problems now
[19:47] <dobey> gatox: the old problem seems to be that _thread_explore is not yet initialzed when you try to start the thread from the patched method
[19:48] <dobey> gatox: and the new problem seems to be that self.ui is None in some cases
[19:48] <dobey> SearchBoxTestCase has the problem of self.ui being None
[19:49] <gatox> mmmmm
[19:49] <gatox> dobey, so..... probably this is not the proper solution..... and it is necessary to refactor a couple of things..... am i right?
[19:49] <dobey> gatox: possible. i don't really know anything about QThread, but looking at the traceback and the code, it seems there is still a race there
[19:50] <dobey> gatox: but your current branch seems to have isolated the race to be a consistent issue
[19:50] <gatox> dobey, ok....... i'll try to thing this carefully..... specially because i'm not being able to see it fail here....... and propose a branch fixing those stuff....... sounds ok?
[19:51] <dobey> gatox: interesting
[19:52] <dobey> gatox: so the new SearchBoxTestCase failures are failing for me as well, in your branch
[19:52] <gatox> dobey, what i say? or did you find something else?
[19:52] <dobey> the other QThread issues are still passing for me when i run the tests though
[19:52] <dobey> gatox: so fix the SearchBoxTestCase failure first, i think
[19:53] <dobey> it might be related to your addition of prints
[19:53] <dobey> though not sure how exactly :)
[19:53] <gatox> dobey, ack....... i'll do that! i'll check the race condition of ui being None sometimes
[19:53] <gatox> that is the root of some problems
[19:53] <dobey> great
[19:54] <gatox> awesome..... thx dobey
[19:55] <dobey> sure; let me know when you have an update to the branch and i'll run the tests again
[19:55] <gatox> dobey, yap
[20:10] <gatox> ok....... eod here..... i'll keep fixing the qthread tomorrow
[20:10] <gatox> bye peopleeeeeee..... see you tomorrow1
[20:19] <ralsina> dobey: I feel so guilty about that qthread code... it started as "the simplest solution" for the problem. Looks like it wasn't :-/
[20:20] <dobey> eh, at least it's not bug #1066943
[20:20] <ralsina> well, yes, that's true
[20:21] <dobey> for which i just proposed https://code.launchpad.net/~dobey/ubuntuone-client/grrrrr-gir/+merge/129754
[20:21] <ralsina> dobey: looking
[20:22] <ralsina> dobey: we are still packaging trunk for lucid, but noone is actually using it, right?
[20:22] <ralsina> dobey: also, how did that ever work and/or pass tests?
[20:22] <dobey> no, we are only packaging nightlies for 11.04+
[20:23] <dobey> it won't build on lucid
[20:23] <ralsina> dobey: yes, noticed that :-)
[20:23] <dobey> it's in the scripts, which don't have tests
[20:23] <ralsina> but really, where was that getting glib from?
[20:25] <ralsina> dobey: +1
[20:25] <dobey> python-zeitgeist maybe?
[20:26] <ralsina> so, random dependency chain...
[20:26] <dobey> in nightlies ubuntuone-control-panel was still depending on it for some reason
[20:26] <dobey> but i fixed that just now
[20:27] <alecu> dobey: +1
[20:27] <dobey> thanks guys
[20:34] <dobey> i hope there aren't any other bugs i need to fix in quantal today
[20:42] <ralsina> dobey: fingers crossed!
[20:43] <dobey> oh, crap
[20:43] <dobey> final release is thursday; so i guess this has to be an SRU and rel-noted
[20:44] <ralsina> dobey: it should not happen in the default install, right?
[20:44] <dobey> i'll have to check the manifest
[20:45] <dobey> ralsina: yeah, python-gobject is part of the default install
[20:45] <dobey> so maybe i should change it to high instead of critical
[20:45] <ralsina> dobey: so SRU is more than ok
[20:45] <ralsina> dobey: right
[20:46] <ralsina> dobey: this happened to this guy because he did a "minimal" install, if it happened in default I would have noticed
[20:46] <ralsina> by the bug report flood ;-)
[20:46] <dobey> or even mediaum
[20:47] <dobey> yeah; true
[20:48] <ralsina> high is ok to justify the SRU
[20:53] <dobey> eh, justifying the SRU is easy, for this one anyway
[20:55] <dobey> also
[20:55] <dobey> _ast is hard to use
[20:57] <ralsina> dobey: you are not supposed to use _ast directly
[20:58] <ralsina> also, IIRC gatox knows a ton about ast because of ninja
[21:02] <elopio> pedronis: dobey. is u1lint also used on the web projects ?
[21:02] <elopio> sorry pedronis.
[21:03] <elopio> wrong key :)
[21:03] <dobey> elopio: on servers? i think it is not right now
[21:03] <elopio> dobey: got it, thanks.
[21:04] <elopio> beuno: do you use some kind of style checker?
[21:04] <beuno> elopio, I'm using ninja-ide which does pep-8 checking by default, yes
[21:04] <dobey> elopio: servers has a similar wrapper around pylint
[21:05] <elopio> beuno: I meant, is it enforced by jenkins or tarmac?
[21:05] <beuno> elopio, no, not at the moment
[21:05] <beuno> will be soon
[21:06] <elopio> beuno: awesome. Can I be involved when you are doing it?
[21:10] <dobey> alright, well i think it's time for me to call it a day
[21:10] <dobey> have a good evening all!
[21:10] <ralsina> Time to take a long break now.
[21:10] <elopio> bye dobey, have a good evening.
[21:10] <ralsina> post review reqs etc here!
[21:11] <elopio> bye ralsina, have a good long break.
[21:13] <mmcc> client tests so so slow
[21:23] <mmcc> here's a brief review request for ralsina after his good long break: https://code.launchpad.net/~mikemc/ubuntuone-client/fix-dummy-sync-menu-again/+merge/129767
[21:24] <briancurtin> mmcc: review trade? mine's easy: https://code.launchpad.net/~brian.curtin/ubuntuone-windows-installer/remove-lazr-mentions/+merge/129765
[21:25] <mmcc> briancurtin: sure. you'd be a good review for mine, since it fixes something that probably broke windows syncdaemon too
[21:27] <mmcc> briancurtin: +1 on code review only, I killed those in setup-mac early on.
[21:28] <briancurtin> mmcc: i had them killed in setups where i had been building the installers from, but apparently hadn't proposed the branch
[21:29] <mmcc> briancurtin: been there!
[21:30] <mmcc> ok, lunch time
[21:48] <briancurtin> mmcc: my u1client tests aren't currently passing, but your branch has no overall effect on the fail/error count
[21:50] <mmcc> briancurtin: another test is to see if syncdaemon starts for you with/without the branch…
[21:57] <briancurtin> mmcc: ah, shows up IRL
[21:58] <briancurtin> i also realized a stupid mistake i checked in with those bin finding branches...two three-char changes if you can squeeze them in your schedule
[21:58] <briancurtin> (after your lunch, of course)
[22:33] <mmcc> briancurtin: I'm back, what's the deal? I actually haven't reviewed those branches yet, sorry…
[22:34] <briancurtin> mmcc: i approved your branch. i was looking at the changes i made and one branch got merged that needs to be adjusted (https://code.launchpad.net/~brian.curtin/ubuntuone-client/take-first-element/+merge/129779) and the other doesn't have any reviews yet (https://code.launchpad.net/~brian.curtin/ubuntu-sso-client/correct-subprocess-args/+merge/129442) - it's all related to the python at the front of the path problem, should
[22:34] <briancurtin> be quick
[22:40] <mmcc> briancurtin - aha, ok. I'll look at those later today. have to run for a few hours now, will be back later.
[22:40] <briancurtin> mmcc: cool, thanks


[03:26] <imnichol> What's the procedure for upgrading to 12.10Alpha?
[03:26] <LordOfTime> they havent even released an alpha yet
[03:27] <imnichol> Oh, well then
[03:28] <nhaines> imnichol: edit /etc/apt/sources.list and change 'precise' everywhere to 'quantal'
[03:28] <nhaines> Then run 'sudo apt-get update && sudo apt-get upgrade'
[03:28] <imnichol> nhaines, that's it?  I thought there was something with update-manager or something
[03:29] <nhaines> imnichol: not until there's a milestone release.
[03:29] <nhaines> imnichol: after that, 'update-manager -d' will do it.
[03:29] <imnichol> Ok
[03:29] <wilee-nilee> imnichol, So this is a OS that you want to upgrade that can go south and that is okay?
[03:29] <imnichol> When is the first milestone release?
[03:29] <imnichol> wilee-nilee, yeah I know the risks
[03:29] <wilee-nilee> cool
[03:30] <nhaines> imnichol: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
[03:30] <imnichol> Nevermind, looks like Alpha1 drops June 7
[03:30] <imnichol> nhaines, thanks, just found that myself
[03:30] <imnichol> ;)
[03:30] <nhaines> imnichol: beat the rush.  ;)
[03:30] <imnichol> hahah
[03:30] <wilee-nilee> Mine has been running great
[03:30] <imnichol> Thanks everyone
[03:31] <nhaines> Precise ran really, really stable all cycle.  I was impressed.
[03:31] <wilee-nilee> I had a few hiccups with precise but it was the hardware really needed some patches in the OS is all.
[03:33] <imnichol> What's the goal for Quantal besides a new icon theme?
[03:34] <imnichol> Seamless boot/shutdown or something?
[03:38] <wilee-nilee> not sure really
[03:38] <wilee-nilee> unquestionable love?
[03:38] <wilee-nilee> for unity
[13:27] <BluesKaj> Hey all
[19:37] <yofel> oh, gimp 2.8 was uploaded, hurray \o/
[19:43] <trism> nice, time to test another rebuild, wonder if we can get a backport, going to need babl and gegl too though
[19:44] <micahg> trism: if you're willing to do the testing (look at the requestbackport output)
[20:07] <trism> micahg: would I need to make requests for babl and gegl first? (since gimp 2.8 won't build without the versions in quantal)
[20:08] <micahg> trism: yes, and unfortunately, this means we're blocked on a launchpad bug ATM
[20:33] <MrChrisDruif> yofel; yes, looks indeed pretty sweet (gimp 2.8)
[20:33] <MrChrisDruif> And hey BluesKaj
[20:35] <BluesKaj> hi MrChrisDruif
[20:35] <MrChrisDruif> How's it going?
[20:39] <BluesKaj> ok , was actually going to install windows to do some audio editing , but I think I'll do some research and find a suitable linux app
[20:40] <BluesKaj> brb , gotta fix some partitons on this drive
[20:40] <MrChrisDruif> <_<"
[22:05] <GRMrGecko> When booting 12.10 daily live cd for PowerPC on my PowerMac G4, it shows the loading screen which says Ubuntu 12.10 with dots and then the displays turns off and disk seems like it's reading the interface of Gnome. Would this be an issue with Ubuntu choosing an unsupported resolution/refresh rate for my display?
[22:05] <GRMrGecko> This is a CRT display
[22:09] <GRMrGecko> The displays supports 640x480/60/75/85/90/95, 640x640/60/75, 800x600/60/75/85, 1024x768/60 (WxH/Hertz)
[23:05] <GRMrGecko> Please mention my name when someone can try to help me with this PowerPC issue.


[21:49] <flexiondotorg> tsimonq2, wxl, teward Hi. Just wondering if Lubuntu are going for 16.10 Alpha 1?
[21:55] <wxl> flexiondotorg: planning on it
[21:55] <flexiondotorg> wxl, Thanks.
[21:56] <flexiondotorg> Are you swithing up to LXQt?
[21:56] <wxl> not yet
[21:56] <wxl> still a lot of work to do, especially when you consider getting rid fo gtk appsz
[21:56] <flexiondotorg> OK, is that on the cards for this cycle?
[21:57] <wxl> as far as i can tell, no
[21:57] <wxl> which makes me wonder if it won't just be delayed until 17.10
[21:57] <flexiondotorg> OK
[21:57] <flexiondotorg> Shame. I'm really looking forward to it :-)
[21:58] <flexiondotorg> So far Ubuntu MATE and Lubuntu are in for Alpha1. Xubuntu are probably not. Waiting on confirmation. Kubuntu are not. Waiting to hear from Ubuntu GNOME.
[21:58] <wxl> i know xubuntu is not
[21:58] <wxl> but please don't take that from me
[22:10] <flexiondotorg> Xubuntu have confirmed they are not.
[22:10] <Unit193> (He's in there too.)


[06:19] <zyga> good morning
[06:20] <zyga> arnatious: hey, can you tell me how you created the container and where is it running?
[06:20] <zyga> arnatious: host info, lxd version, container info, etc
[06:21] <mvo> hey zyga
[06:21] <zyga> :)
[06:21] <zyga> how are you doing?
[06:22] <zyga> mvo: back to fighting that user test?
[06:22] <zyga> mvo: meanwhile: https://github.com/snapcore/snapd/pull/7337 is simple and green
[06:22] <mup> PR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
[06:23] <zyga> if you agree it is simple, that is :)
[06:23] <mvo> zyga: yeah, that and one more flaky one
[06:23] <Aavar> Where is my config stored when using irssi as a snap?
[06:24] <zyga> I had a look at the two leaking lets that are on core
[06:24] <zyga> Aavar: most likely in ~/snap/irssi/current/.irssi
[06:24] <mvo> zyga: looking at the prs now
[06:24] <zyga> mvo: and one of them was very puzzling, the one I pasted last night
[06:24] <zyga> but I'll re-read that with fresh minnd
[06:24] <zyga> *mind
[06:24] <zyga> the pastebin is https://paste.ubuntu.com/p/Pdx9qmqbdH/
[06:26] <zyga> mvo: btw, one surprise from yesterday is ordering of prepare calls
[06:26] <zyga> mvo: prepare-project-each is before prepare-suite-each
[06:26] <zyga> I was somewhat assuming that prepare-project-each is like prepare-task-each which doesn't exist
[06:27] <zyga> mvo: in that pastebin I linked to the part I don't understand is where did the revision 1001 and 1002 come from
[06:27] <zyga> where normally the revision map shows 36 and similar numbers
[06:31] <mvo> zyga: from our fake store maybe?
[06:31] <mvo> zyga: just guessing at this point, we setup a fake store for some tests
[06:33] <zyga> Ahhh, interesting. That must be it! Thank you
[06:48] <zyga> hey pedronis
[06:48] <zyga> I'm just looking at unit test failure in one of your PRs
[06:48] <zyga> https://www.irccloud.com/pastebin/CKcptuEn/
[06:48] <zyga> I've seen this a few times recently
[06:50] <pedronis> weird error, I wonder why is not deterministic
[06:50] <pedronis> anyway I'm working in that area
[06:50] <zyga> thanks :)
[06:50] <pedronis> so don't think you should spend time on it
[06:50] <zyga> ok
[06:50] <zyga> I'll focus on review
[06:51] <zyga> pedronis: https://github.com/snapcore/snapd/pull/7329 can land, I think
[06:51] <mup> PR #7329: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>
[06:51] <mup> PR snapd#7329 closed: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7329>
[06:59] <pstolowski> hello
[07:00] <zyga> good morning :)
[07:00] <mvo> hey pstolowski - goooood morning :)
[07:09] <mup> PR snapd#7340 closed: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7340>
[07:14] <mvo> zyga: 7338 has conflicts
[07:14] <mup> PR snapd#7339 closed: tests: don't look for lxcfs in mountinfo <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7339>
[07:16] <zyga> mvo: on it
[07:16] <zyga> done
[07:17] <mup> PR snapd#7335 closed: tests: add check for snap_daemon user/group <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7335>
[07:19] <zyga> pedronis: https://github.com/snapcore/snapd/pull/7323 is something you should review I think
[07:19] <mup> PR #7323: features, overlord: make parallel-installs exported, export flags on startup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7323>
[07:19] <zyga> it deals with feature flags and startup behavior
[07:20] <pedronis> added to my list
[07:20] <pedronis> zyga: that failing test is weird
[07:21] <pedronis> it's broken by design
[07:21] <pedronis> but a bit unsure why it fails only rarely
[07:21] <zyga> those kinds are most interesting :)
[07:25] <pedronis> pstolowski: did you add the MissingBase test to first boot stuff?
[07:27] <pstolowski> pedronis: checking
[07:30] <pstolowski> pedronis: yes, TestPopulateFromSeedMissingBase
[07:30] <pedronis> pstolowski: something is odd with it
[07:30] <mvo> zyga: 7336 should be an easy review
[07:30] <pedronis> pstolowski: unasserted goes into seed.yaml, not the snap
[07:30] <pedronis> but is working anyway, most of the time
[07:30] <pedronis> but sometimes it fails
[07:30] <zyga> mvo: mhm
[07:30] <pedronis> trying to understand why
[07:31] <pedronis> pstolowski: anyway, mostly pointing out that unasserted: true is in the wrong place
[07:31] <zyga> mvo: +1
[07:31]  * zyga reviews https://github.com/snapcore/snapd/pull/7313
[07:31] <mup> PR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
[07:34] <pstolowski> pedronis: hmm, sorry about that, shall i investigate?
[07:35] <pedronis> pstolowski: no, I'm looking into it
[07:40] <pstolowski> ok, thanks
[07:43] <Aavar> thank you zyga ;)
[07:47] <zyga> Aavar: for what? :)
[07:51] <pedronis> pstolowski: here's the cleanup/fix, fyi:  https://github.com/snapcore/snapd/pull/7341/commits/709e0bd10c78fc74334d7660c7549647d04d5232
[07:51] <mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
[07:56] <pedronis> pstolowski: it was creating variant of local both unasserted and asserted (under the foo* stuff), and sometimes they diverged (not sure why)
[07:57] <pedronis> pstolowski: anyway, a bit of confusion all around there :)
[07:58] <pstolowski> pedronis: aaah i see
[08:12] <mup> PR snapcraft#2688 closed: Build base types <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>
[08:13] <zyga> pedronis: https://github.com/snapcore/snapd/pull/7313#pullrequestreview-280011112
[08:13] <mup> PR #7313: many:  add the start of Core 20 extensions support to the model assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/7313>
[08:15] <zyga> mvo: hey
[08:15] <zyga> mvo: look at this:
[08:15] <zyga> + getent passwd snap_daemon
[08:15] <zyga> snap_daemon:x:584788:584788::/nonexistent:/usr/bin/false
[08:15] <zyga> mvo: full log https://api.travis-ci.org/v3/job/576917244/log.txt
[08:15] <zyga> 2019-08-27 07:47:28 Error restoring google:arch-linux-64:tests/main/system-usernames-illegal :
[08:16] <zyga> also suspicious there
[08:16] <zyga> + snap remove test-snapd-illegal-system-username
[08:16] <zyga> snap "test-snapd-illegal-system-username" is not installed
[08:16] <zyga> typo?
[08:16] <zyga> mvo: this was in https://github.com/snapcore/snapd/pull/7316
[08:17] <mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
[08:17]  * zyga reviews https://github.com/snapcore/snapd/pull/7341
[08:17] <mup> PR #7341: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
[08:21] <mup> PR snapd#7344 opened: snapstate: use strutil.VersionCompare() in checkVersion() <Created by mvo5> <https://github.com/snapcore/snapd/pull/7344>
[08:22] <mup> PR snapd#7333 closed: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7333>
[08:24] <mup> PR snapcraft#2689 opened: schema: kernel and snapd types do not use bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2689>
[08:24] <mvo> zyga: nice, thanks, let me check
[08:24] <mvo> zyga: so the catcher of the test thing did find something
[08:24] <zyga> indeed
[08:24] <zyga> look at the log in detail, I'm sure there's something there that's useful
[08:25] <mvo> zyga: yeah, look
[08:25] <sergiusens> xnox: mvo does `type: kernel` always require a base or will any kernel snap work with any base?
[08:27] <sergiusens> mvo: pedronis and from last week, do we want the `type: snapd` to NOT specify a base or do we want it to specify a base (even if none or bare)? (unrelated to using a build-base)
[08:29] <mvo> sergiusens: I think we do not need a base for snapd, its self contained
[08:29] <mvo> sergiusens: the kernel is tricky, if it uses hooks it needs a base so that we know how to run the hooks
[08:30] <mvo> hey Chipaca, good morning!
[08:30] <Chipaca> mvo: 👋 !
[08:30] <mvo> Chipaca: can I pester you with a question already?  I got:
[08:30] <mvo> $ snap switch test-snapd-assumes --edge
[08:30] <mvo> "test-snapd-assumes" switched to the "edge" channel
[08:30] <mvo> Channel edge for test-snapd-assumes is closed; temporarily forwarding to candidate.
[08:30] <mvo> Chipaca: today which is a bit odd because the edge channel is open (and was open at the time of this message). does that ring any bells?
[08:31] <Chipaca> mvo: was this in a spread test, or somewhere you have debug logs?
[08:32] <Chipaca> huh
[08:32] <mvo> Chipaca: I ran this manually, was doing some exploring about "assumes:" this morning
[08:32] <Chipaca> it's reproducible
[08:32] <mvo> cool!
[08:33] <mvo> zyga: this is a fun issue, the logs show that the snap_daemon user is added *before* test-snapd-illegal-system-username is POSTed to the daemon. very puzzling
[08:34] <zyga> POSTed?
[08:34] <zyga> as in installed?
[08:34] <zyga> whaat?
[08:34] <zyga> :D
[08:34] <zyga> mvo: I'll be back soon, let me make some tea
[08:35] <mvo> zyga: yeah, at least if the journald logs are in order
[08:35] <mvo> zyga: yeah, no worries, just wanted to share my puzzlement
[08:36] <Chipaca> mvo: is 381b45e27773eff87bca4f8ed9b96d027bfb8ee5 part of 2.41~pre1 ?
[08:36] <Chipaca> mvo: i suspect that's the issue
[08:38] <mvo> zyga: found the issue, its "fun"
[08:38] <mvo> Chipaca: let me check
[08:39] <mvo> Chipaca: it is part of 2.41 it seems :/
[08:39] <Chipaca> mvo: maybe we should back that out until we have time to fix it
[08:39] <mvo> Chipaca: could we just revert it in 2.41?
[08:40] <mvo> Chipaca: yeah, I think that makes sense
[08:40] <zyga> mvo: oh
[08:40] <zyga> mvo: tell me :)
[08:42] <mvo> zyga: pr will be up shortly but its easy once spotted
[08:42] <pedronis> zyga: I tried to answer to some of your model assertion comments
[08:42] <zyga> pedronis: thanks, let me look
[08:44] <sergiusens> mvo: so for kernel we will require a base for now (it can be bare)
[08:44] <zyga> pedronis: I replied to some but it all makes sense
[08:45] <zyga> pedronis: LGTM and iterate or iterate and LGTM, as you prefer :)
[08:50] <mup> PR snapd#7345 opened: overlord/devicestate,seed:  small step introduce seed.LoadAssertions and use it from firstboot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7345>
[08:51] <mup> PR snapd#7346 opened: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>
[08:51] <mvo> zyga: ^- thats the one
[08:51] <zyga>  /o\
[08:53] <zyga> mvo: did we ship this?
[08:53] <mvo> zyga: yeah, also kind of annoying that we overlooked this in the code review
[08:53] <mvo> zyga: well
[08:53] <zyga> :E
[08:53] <mvo> zyga: its in beta
[08:54] <zyga> mvo: should such usernames be made at the time the snap is linked?
[08:54] <zyga> mvo: I'm looking at this now and it's unclear when this runs
[08:55] <pedronis> it runs early but this usernames are shared
[08:55] <pedronis> so they will end up staying around either way
[08:55] <pedronis> in many cases
[08:55] <zyga> pedronis: that's okay, I worry that the sequence now is [check-foo, check-users, check-bar]
[08:56] <zyga> and that check-bar fails but we already acted a little on the system, which feels wrong
[08:56] <pedronis> as I said, for the current one support user is ok
[08:56] <pedronis> but when we add more we need to revisit this
[08:56] <pedronis> it probably merits a TODO in that PR though < mvo
[08:56] <zyga> mvo: how is the patch making things better tough
[08:56] <zyga> it's unclear to me
[08:57] <pedronis> we either create all users or none
[08:57] <pedronis> we might still fail to install the snap
[08:57] <pedronis> later
[08:57] <zyga> ah, indeed
[08:57] <pedronis> but given that the one support user
[08:57] <pedronis> is shared
[08:58] <pedronis> it's not too bad
[08:58] <pedronis> but it might be worth revisiting at some point
[08:58] <mvo> pedronis: indeed, let me add this todo
[09:17] <mup> PR snapd#7347 opened: gadget: do not error on gadget refreshes with multiple volumes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7347>
[09:19] <zyga> mvo: multi volume as in multi partition?
[09:19] <zyga> mvo: or multiple disks
[09:20] <mvo> zyga: multiple disks
[09:20] <zyga> mvo: do we have customers using that?
[09:20] <zyga> or is this just a precaution?
[09:20] <mvo> zyga: we have customers using this and this is breaking ondra
[09:20] <zyga> +1
[09:20] <zyga> thanks for explaining
[09:22] <zyga> mvo: left a suggestion, +1 anyway
[09:44] <popey_> zyga: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500#10
[09:44] <mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
[09:44] <zyga> popey_: looking
[09:44] <popey_> is that comment still accurate?
[09:44] <zyga> ah that one
[09:45] <zyga> it didn't move forward, we discussed accepting partial confinement with actual apparmor enabled but it was nacked for existing distributions
[09:46] <zyga> as we don't have the time to deal with regressions if that broke people
[09:46] <zyga> that's what the state of this is now
[09:46] <popey_> Worth updating the bug?
[09:46] <zyga> it's not a great message but yeah
[09:46] <zyga> if only updating bugs in debian didn't involve email
[09:51] <pedronis> mvo: approved #7346 with a comment
[09:51] <mup> PR #7346: snapstate: validate all system-usernames before creating them <Created by mvo5> <https://github.com/snapcore/snapd/pull/7346>
[09:54] <mvo> pedronis: thanks, looking in a wee bit
[10:05]  * Chipaca takes a break
[10:05] <arnatious> zyga: Container created on Ubuntu 18.04, LXD stable/3.16 snap, container config https://paste.ubuntu.com/p/JrcC89rwN2/
[10:16] <mup> PR snapd#7348 opened: snapstate,store: check assumes early before downloading the snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
[10:25] <mvo> Chipaca: bad news, it seems like reverting 7204 still gives the same error message, I can bisect
[10:26] <Chipaca> mvo: rats
[10:26] <Chipaca> mvo: is it actually a regression?
[10:26] <mvo> Chipaca: not sure, let me try
[10:27] <mvo> Chipaca: aha, I think I'm a muppet, hold on, let me retest this
[10:29] <Chipaca> mvo: Rowlf?
[10:29] <mvo> Chipaca: that sounds about right
[10:30] <mvo> Chipaca: maybe "beaker" just needs to be renamed to "breaker"
[10:33] <mup> PR snapd#7349 opened:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/7349>
[10:33] <mvo> pstolowski: your input here would be great :)
[10:35] <Chipaca> mvo: https://www.youtube.com/watch?v=VnT7pT6zCcA
[10:37] <pstolowski> mvo: oh :( interesting, saying 'stable' instead will be confusing as well
[10:45] <mvo> pstolowski: aha, this is latest/stale vs stable? the new default-channel stuff?
[10:45] <mvo> Chipaca: lol - this is great - his expression matches my mood perfectly
[10:46] <pstolowski> mvo: yes... and with this revert we'll be showing *wrong* (imprecise/misleading) information when the snapd-side logic of keeping the track kicks in
[10:47] <cachio> zyga, hey, when you have time could you please take a look to #7110
[10:47] <mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
[10:47] <cachio> zyga, hope last one
[10:48] <mvo> pstolowski: meh, ok
[10:48] <mvo> pstolowski: so we need something else I guess :/
[10:48] <mvo> pstolowski: there is a spread test in there that might be useful
[10:48] <mvo> pstolowski: the other parts can probably be removed then
[10:51] <pstolowski> mvo: thanks, +1 and i'll work on this soon
[10:55] <mvo> pedronis: I updated 7346 with a unit test, thanks for the suggestion!
[10:55] <zyga> cachio: in an hour
[10:55] <cachio> zyga, sure, thanks
[11:08] <mvo> pedronis: would love your opinion on 7348 too :) but no rush
[11:09] <pedronis> mvo: finishing lunch break
[11:10] <mvo> pedronis: yeah, no rush, I will soon have lunch too - I was just surprised how small it was
[11:17] <pedronis> mvo: commented
[11:19] <mup> PR snapd#7350 opened: tests: clean snap_daemon user and group on system-usernames-illegal test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7350>
[11:47] <mup> PR snapd#7351 opened: tests: retry checking until the written file on desktop-portal-filechooser <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>
[11:52] <xnox> sergiusens:  at the moment, `type: kernel` works with any bases, but which base is used matters. As initramfs.img is build with binaries from the base. Thus one should be specified, and it does matter if it's core16, core18, or core20 cause then the initramfs.img has libc6 and etc. from those matching releases xenial / bionic / $devel
[11:58] <zyga> re
[12:07] <pedronis> xnox: the plan is that kernels should use/specify build-base:  not a base:
[12:09] <xnox> pedronis:  yes, that is good. initramfs.img is self contained / can be used by anyone...... but it matters what it is built out of. More like "Built-Using: bionic" in "dpkg speak", despite having no "Depends:".
[12:20] <mup> PR snapd#7346 closed: snapstate: validate all system-usernames before creating them <Test Robustness> <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7346>
[12:37] <mup> PR snapd#7352 opened: tests: always say 'restore: |' <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7352>
[12:38] <zyga> are draft branches visible by default?
[12:39] <zyga> I meant draft PRs
[12:44] <zyga> https://github.com/snapcore/snapd/pull/7337 needs a 2nd review
[12:44] <mup> PR #7337: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
[12:45] <pstolowski> jdstrand: hey, one correction to what i said yesterday: i was wrong when i said 'snap connect' could also be optimized for multiple connections at once like i did with automatic connections, i misremembered the code that resolves plug/slot names for connect (was thinking we can resolve multiple plugs/slots if you omit connect arguments, but we only resolve a single plug/slot if you omit them)
[12:52] <ijohnson> has anyone seen debian-sid-64 fail to prepare like this: https://pastebin.ubuntu.com/p/GQjg4jK4rw/ ?
[12:53] <ijohnson> I've seen it fail to prepare on numerous builds now and it doesn't look like a transient error
[12:53] <mup> PR snapd#7353 opened: tests: simplify interfaces-account-control test <Simple 😃> <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7353>
[12:55] <mup> PR snapd#7354 opened: tests: rename fuse_support to fuse-support <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7354>
[13:00] <mup> PR snapd#7355 opened: [RFC] interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
[13:01] <Chipaca> augh, 2fa
[13:04] <mup> PR snapd#7110 closed: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
[13:55] <jdstrand> pstolowski: thanks. it sounded like an exciting feature that I missed :)
[14:11] <pstolowski> jdstrand: :)
[14:14] <mup> PR snapd#7352 closed: tests: always say 'restore: |' <Simple 😃> <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7352>
[14:17] <zyga> why does it have to be so hot
[14:27] <mup> PR snapcraft#2674 closed:  file_utils: introduce link_or_copy_files <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2674>
[14:46] <mup> PR snapd#7203 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7203>
[14:48] <pstolowski> Chipaca: i'm working on a fix for the confusing snap switch message ("Channel %s for %s is closed; temporarily forwarding to..) caused by my #7204; i don't understand the logic of this temporary forward meesage but i assume it's fine to simply skip it for op = "switch" in showDone(), this will basically make "switch" behave as before, modulo the new track/risk behavior that will be shown correctly (thanks to
[14:48] <pstolowski> showDone)
[14:48] <mup> PR #7204: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7204>
[14:48] <pstolowski> Chipaca: sounds sensible?
[14:48] <Chipaca> pstolowski: sounds like the quickest way forwards yes
[14:48] <Chipaca> the logic probably assumes 'refresh'
[14:51] <pstolowski> Chipaca: ok, thamks
[14:51] <pstolowski> *thanks
[14:53] <mup> PR snapd#7356 opened: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7356>
[14:57] <zyga> pstolowski: could you please do a pass over the three simple PRs I have
[14:57] <zyga> they are all tiny and I'd love to merge them
[15:01] <pstolowski> zyga: sure
[15:01] <zyga> thanks
[15:01] <zyga> there's one -0,+0 PR :D
[15:01] <mup> PR snapd#7357 opened: Fix snap switch message <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7357>
[15:03] <pstolowski> zyga: which one?
[15:04] <zyga> pstolowski: 7354
[15:06] <mup> PR snapd#7358 opened: Rename die() -> die_reboot() to fix build failures with LTO enabled <Created by dcermak> <https://github.com/snapcore/snapd/pull/7358>
[15:10] <zyga> Chipaca: can you look at that, it looks good-ish but I'm worried about it slightly
[15:11] <Chipaca> zyga: the switch one?
[15:11] <zyga> no, the die one above
[15:12] <pstolowski> zyga: did two others, not sure if these were the ones you wanted first. let me know if you need any more
[15:12] <zyga> pstolowski: that's great, thank you
[15:18] <Chipaca> zyga: the intention was to use the same die from the lib, wasn't it?
[15:25] <zyga> Chipaca: original intention or one in this PR
[15:25] <cachio> zyga, when you have time, could you please atke a look to #7159
[15:25] <zyga> Chipaca: the original die is not flexible enough
[15:25] <mup> PR #7159: tests: add functions to make an abstraction for the snaps <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
[15:25] <zyga> Chipaca: I'm looking at fixing that
[15:26] <cachio> zyga, and this one also #7256 please
[15:26] <mup> PR #7256: tests: adding retry command and use it to delete $XDG directory <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7256>
[15:30] <zyga> cachio: ok
[15:30] <cachio> thanks
[15:31] <zyga> cachio: does retry argument parsing really work correctly?
[15:31] <zyga> cachio: "$@" is expanded once
[15:31] <zyga> and it contains all the stuff
[15:31] <zyga> you can look at "${1:-}", and while that is not empty parse arguments
[15:31] <zyga> the problem with this method is that it just zooms through all the arguments, shifting some (not the one looked at)
[15:32] <zyga> ignoring things it doesn't handle
[15:32] <cachio> checking
[15:32] <zyga> cachio: please
[15:32] <zyga> cachio: perhaps it's time to use python :)
[15:32] <zyga> cachio: there it's trivial
[15:34] <cachio> zyga, works well
[15:34] <cachio> zyga, https://paste.ubuntu.com/p/R9mrmSBq65/
[15:35] <zyga> cachio: what happens when you pass call retry rm foo --max-attempts 2
[15:36] <cachio> fails
[15:36] <zyga> cachio: but that's not how it was supposed to work
[15:36] <cachio> seq: unrecognized option '--max-attempts'
[15:36] <zyga> cachio: the command was not supposed to be quoted
[15:36] <zyga> cachio: you call it as retry rm -rf "$XDG"
[15:36] <zyga> but your example is different
[15:36] <zyga> I'm not super happy about the parser, I can fix it tomorrow morning
[15:37] <cachio> that works
[15:37] <cachio> what fails is when you use --xx at the end
[15:38] <cachio> zyga, see that https://paste.ubuntu.com/p/XGNy3ZJRgx/
[15:40] <zyga> cachio: what does shift shifts from?
[15:41] <zyga> cachio: when you are mid-iteration in that for loop
[15:41] <zyga> cachio: I thought that shift shifts from the left of the "$@" array
[15:43] <pedronis> pstolowski: Chipaca: it was very weird that this was landed withotu spread tests: https://github.com/snapcore/snapd/pull/7199/files
[15:43] <mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>
[15:43] <pedronis> pstolowski: Chipaca: we should add some
[15:43] <pedronis> both for refresh and switch
[15:46] <pstolowski> pedronis: ok, i can work on it
[15:47] <pedronis> pstolowski: I'm adding a card
[15:47] <cachio> zyga, don't get you
[15:47] <zyga> cachio: what's the semantics of shift
[15:47] <zyga> cachio: and how does it impact the loop
[15:47] <zyga> cachio: if you have a loop that goes over 1 2 3 4 5 6
[15:48] <zyga> cachio: and you are at 3
[15:48] <zyga> cachio: what does shift do?
[15:48] <pedronis> pstolowski: https://trello.com/c/6oPPAjLD/312-add-spread-tests-for-https-githubcom-snapcore-snapd-pull-7199-for-both-switch-and-refresh
[15:48] <zyga> cachio: does it remove "3" or "1"
[15:48] <zyga> cachio: I think the loop and the parser is incorrect
[15:48] <cachio> zyga, ok, let me check that
[15:49] <zyga> cachio: I'm not sure if that's "standard" but when I'm doing shell parsing I'd using a while loop
[15:49] <zyga> cachio: checking to see if there are more arguments in "$@"
[15:49] <zyga> cachio: looking at the one up front
[15:49] <zyga> cachio: handling it, shifting it away
[15:49] <zyga> cachio: terminating argument parsing (typically on --)
[15:49] <zyga> cachio: or reporting an error
[15:50] <zyga> cachio: there are some helpers like getopt as well but those don't always have the right precision
[15:51] <cachio> zyga, https://paste.ubuntu.com/p/C94tCPm6F7/
[15:52] <zyga> Chipaca: now swap retry argument order
[15:52] <zyga> er, cachio ^
[15:52] <zyga> cachio: the parser is wrong because it shifts something else than it is looking at
[15:53] <zyga> cachio: it shifts "$@" - aka the magic array
[15:53] <zyga> cachio: it looks at an item out of a snapshot of that array
[15:54] <cachio> zyga, I dont see in which case it could fail
[15:54] <cachio> when we change the order of the parameters?
[15:54] <zyga> cachio: yes, but it's more fundamental, it's just not right in what it is doing
[15:55] <mvo> pstolowski: with 7357 - should I close 7349 ?
[15:56] <cachio> zyga, to fix that I should create another array and remove items instead of shift?
[15:56] <zyga> cachio: I think you can use shift but you must look at the first element at all times
[15:56] <zyga> cachio: not at the i-th element
[15:56] <pstolowski> mvo: if we are happy about resolution, yes
[15:56] <zyga> cachio: but honestly, you can just drop the parsing entirely and hard-code those
[15:56] <zyga> cachio: or just use python
[15:57] <zyga> cachio: where such things are easier
[15:57] <cachio> zyga, rightin python is much easier
[15:57] <mvo> pstolowski: I close mine for now then, I'm not sure I understand all the implications yet but it looks like your changes are small and targeted so hopefully
[15:57] <mvo> pstolowski: hopefully all fine
[15:58] <cachio> zyga, I'll try that
[15:58] <mup> PR snapd#7349 closed:  snap: revert PR#7204 as breaks `snap switch` output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7349>
[15:58] <cachio> zyga, thanks for reviewing the change!
[15:59]  * cachio lunch
[15:59] <zyga> cachio: sure
[16:00] <mup> PR snapd#7356 closed: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext (2.41) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7356>
[16:04]  * zyga breaks to rest until the call later today
[16:05] <mvo> zyga: thanks for holding the fort later!
[16:07] <zyga> :)
[16:25] <pedronis> cachio: this could land https://github.com/snapcore/snapd/pull/7259 but probably needs a master merge to get green
[16:25] <mup> PR #7259: tests: just build snapd commands on go-build test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
[16:28] <mup> PR snapd#7260 closed: tests: add a runtime scripts generation to generate scripts to call functions <Created by sergiocazzolato> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7260>
[16:28] <mup> PR snapd#7338 closed: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7338>
[16:28] <mup> PR snapd#7353 closed: tests: simplify interfaces-account-control test <Simple 😃> <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7353>
[16:39] <cachio> pedronis, merged, waiting for test results in green
[16:40] <cachio> pedronis, thanks
[16:42] <mup> PR snapd#7354 closed: tests: rename fuse_support to fuse-support <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7354>
[17:43]  * ijohnson lunches, bbiab
[17:44] <mup> PR snapd#7359 opened: overlord/snapstate: check channel names on install <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7359>
[18:11] <mup> PR snapd#7337 closed: tests: re-enable mount-ns test on classic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7337>
[18:30] <mup> PR snapd#7259 closed: tests: just build snapd commands on go-build test <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7259>
[19:28] <mup> PR snapd#7360 opened: snap: use deterministic paths to find the built deb <Created by sergiusens> <https://github.com/snapcore/snapd/pull/7360>
[19:29] <sergiusens> mvo: https://github.com/snapcore/snapd/pull/7092#issuecomment-525448848
[19:30] <mup> PR #7092: packaging: use snapd type and snapcraft 3.x <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
[19:30] <sergiusens> mvo: cachio I added a link to a built snapd there ... a comment yay or nay on the snapcraft PR mentioned there would be grand.
[19:32] <cachio> sergiusens, ok, thanks
[20:31] <mup> PR snapcraft#2690 opened: remote-build: error when --user is required <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2690>
[21:03] <mup> PR snapd#7361 opened: tests: enabling ubuntu 19.10-64 on spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7361>
[21:13] <mup> PR snapd#7362 opened: cmd: unify die() across C programs <Created by zyga> <https://github.com/snapcore/snapd/pull/7362>
[21:17] <mup> PR snapd#7363 opened: cmd/snap-confine: fix group and permission of .info files <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/7363>


[08:23] <tepsipakki> hi bryce
[08:43] <bryce> heya tepsipakki!
[08:58] <bryce> tepsipakki: I'm making a last pass through bugs that need uploaded and reviewed for gutsy final
[09:02] <tepsipakki> cool
[09:02] <tepsipakki> I've been busy at work, but took this week off
[09:02] <tepsipakki> so maybe I can take a look at them too
[09:27] <bryce> tepsipakki: do you have a moment to do a couple uploads for me?
[09:40] <ubotu> New bug: #152859 in xorg (main) "ati xorg.conf dualscreen" [Undecided,New]  https://launchpad.net/bugs/152859
[09:44] <bryce> tepsipakki: nevermind; dholbach got them
[09:45] <tepsipakki> ah, good
[10:12] <ubotu> New bug: #152648 in xorg (main) "gdm_slave_xioerror_handler: Fatal X error" [Undecided,New]  https://launchpad.net/bugs/152648
[10:15] <ubotu> New bug: #152867 in linux-restricted-modules-2.6.22 (restricted) "fwlanusb driver doesn't play nicely with hal / network-manager" [Undecided,New]  https://launchpad.net/bugs/152867
[10:41] <soren> Er... There's a bug in the new xresprobe upload.
[10:41] <soren> It reads:
[10:42] <soren> if [ -z "$RES" ]  && [ ! $"x$DRIVER" = "xintel" ] ; then
[10:42] <soren>                         ^
[10:50] <soren> tepsipakki: ^^
[10:52] <bryce> oh $&*#
[10:52] <bryce> that's my fault
[10:52] <bryce> thanks for catching that so quick
[10:54] <soren> np :)
[10:54] <soren> I knew it was your doing, I just assumed you'd be asleep at this hour :)
[10:55] <bryce> I probably should be ;-)
[10:56] <bryce> soren, can you upload this for me?  http://people.ubuntu.com/~bryce/Uploads/
[10:58] <soren> bryce: will do.
[10:59] <soren> bryce: done
[10:59] <bryce> thanks
[10:59] <soren> np :)
[10:59] <bryce> no idea how that slipped in
[11:00] <bryce> btw, any idea if the RM's picked up on that bug yet? I've not received a reply so far
[11:01] <soren> no clue.
[01:36] <ubotu> New bug: #130665 in linux-restricted-modules-2.6.22 (restricted) "madwifi fails to load: ath_pci: Unknown symbol _ath_hal_attach" [Undecided,Confirmed]  https://launchpad.net/bugs/130665
[02:40] <ubotu> New bug: #134897 in linux-restricted-modules-2.6.22 (restricted) "[Gutsy Tribe 5]  MacBook Rev.A, Gutsy Live CD fails to load X" [Undecided,New]  https://launchpad.net/bugs/134897
[03:50] <ubotu> New bug: #152200 in xserver-xorg-video-intel (main) "system freeze when closing a laptop lid when using totem with compiz" [Medium,New]  https://launchpad.net/bugs/152200
[04:48] <ubotu> New bug: #152111 in xserver-xorg-video-i810 (main) "contrast set to zero" [Medium,New]  https://launchpad.net/bugs/152111
[05:33] <ubotu> New bug: #151188 in linux-restricted-modules-2.6.22 (restricted) "Rhythmbox crashes X if in visualization mode" [Medium,New]  https://launchpad.net/bugs/151188
[10:59] <ubotu> New bug: #153007 in linux-restricted-modules-2.6.22 (restricted) "PowerPlay worked in Feisty, no longer works in Gutsy" [Undecided,Incomplete]  https://launchpad.net/bugs/153007
[11:01] <ubotu> New bug: #152985 in ubuntu "vga monitor switches to standby on install (dup-of: 150302)" [Undecided,New]  https://launchpad.net/bugs/152985
[11:35] <ubotu> New bug: #153073 in linux-restricted-modules-2.6.22 (restricted) "nvidia restricted drivers freeze the computer" [Undecided,New]  https://launchpad.net/bugs/153073