[06:12] <lordievader> Good morning
[13:43] <coreycb> jamespage: does this look ok to you? https://paste.ubuntu.com/p/Pqf9JCsrRJ/
[13:50] <jamespage> coreycb: you could just wildcard that
[13:51] <jamespage> I'd be +1 on that approach
[13:53] <coreycb> jamespage: ok I'll wildcard it, thanks
[14:24] <jamespage> coreycb: I have a pacific point release for a CVE to upload to hirsute - want to wrap that in to my upload?
[14:24] <coreycb> jamespage: sure, that'd be great, thanks
[14:25] <jamespage> ok just dealing with that now so will do
[14:58] <jamespage> coreycb: I suspect me dumping a new ceph into hirsute and the insane amount of time some archs take to build is not going to happen pre-release
[14:58] <jamespage> so you might want to add that patch into the backport-o-matic for the UCA for now
[14:59] <coreycb> jamespage: ok, yeah .. I'll do that today


[01:33] <apol_> ovidiu-florin: I'll have to send you some candy, in exchange to the kdevelop praise ;)
[01:45] <nobull> Is the show still live. I have a topic.
[03:11] <ahoneybun> sgclark: https://docs.google.com/document/d/1A_7y3TszgqsGRjFR_N0NkmcOqTHJt4K3o3IxyWckP6I/edit
[03:12] <sgclark> ahoneybun: had to request access
[03:13] <ahoneybun> let me do that
[03:16] <ahoneybun> so you can't see it sgclark?
[03:16] <sgclark> nope
[03:16] <ahoneybun> maybe cuz Sick_Rimmit made it
[03:16] <ahoneybun> it will be simple questions
[03:17] <ahoneybun> who you are, how did you get involved with Kubuntu... and so on
[03:18] <sgclark> hmm okies
[03:18] <sgclark> pretty sure I did that interview though!
[03:19] <ahoneybun> not on the podcast lol
[03:19] <sgclark> lol ok
[03:20] <ahoneybun> XD
[05:53] <ahoneybun> valorie: I'll get this to work tonight/morning lol
[05:56] <ahoneybun> got it!
[05:56] <ahoneybun> valorie: http://<IP_ADDRESS>/
[05:56] <ahoneybun> Rick_Timmis: Riddell_ http://<IP_ADDRESS>/
[05:59] <ahoneybun> btw valorie that theme is mobile friendly
[06:04] <valorie> very cool!
[06:05] <ahoneybun> :)
[06:06] <ahoneybun> I just tried it on my OnePlus One
[08:06] <lordievader> Good morning.
[08:29] <soee_> hiho
[08:30] <lordievader> o/
[10:45] <BluesKaj> Hiyas all
[10:46] <murthy> lordievader: hi
[10:46] <murthy> BluesKaj: hi
[10:46] <BluesKaj> Hi murthy
[10:49] <murthy> https://bugs.kde.org/show_bug.cgi?id=339536
[10:50] <murthy> I would like to file a bug report in kubuntu, how can I do that?
[10:56] <santa_> murthy: don't worry, I'm going to send a patch to kubuntu-devel about the topic soon. would you test a modified ark package?
[10:57] <murthy> santa_: Just file a bug report. By modified a patched one?
[10:58] <lordievader> Hey murthy
[10:58] <murthy> https://bugs.launchpad.net/ubuntu/+source/ark/+bug/1466439
[10:58] <lordievader> murthy: Why? Is it a package bug?
[10:58] <murthy> lordievader: https://bugs.kde.org/show_bug.cgi?id=339536
[10:58] <murthy> lordievader: you better read the last comment
[10:58] <murthy> in the bug reporty
[10:59] <santa_> murthy: yes
[10:59] <lordievader> Ah, I see.
[10:59] <santa_> I have been investigating the issue
[10:59] <murthy> santa_: give me
[11:00] <murthy> santa_: where is the problem ? in libarchive or ark or kerfufle?
[11:00] <santa_> murthy: I don't have it yet, but if you stick around today I will try to give you something for wily
[11:00] <santa_> the problem is in debian XD
[11:00] <murthy> santa_: but file-roller works
[11:01] <murthy> santa_: that uses libarchive
[11:01] <santa_> I don't know, but that's not the only issue
[11:01] <murthy> santa_: you have the patch?
[11:02] <santa_> murthy: I know the solution, just give me some time, I need to finish something
[11:02] <murthy> santa_: ok
[11:04] <murthy> santa_: also is this related to receiving corrupted files through kdeconnect?
[11:04] <santa_> I don't think so
[11:10] <clivejo> murthy: KDE Connect corrupts files for me too
[11:10] <clivejo> running Wily 64bit here
[11:11] <murthy> clivejo: it happens when you send a file from your phone memory?
[11:11] <clivejo> yup
[11:11] <clivejo> I take photos on S5 and it wont send them to my Wily desktop
[11:12] <clivejo> Ive unpaired and removed both apps, still broken
[11:12] <murthy> you are not even able to receive the file?
[11:13] <clivejo> it recieves it, but the file is corrupt
[11:13] <murthy> clivejo: right that what happening to me too
[11:14] <clivejo> any idea whats wrong?
[11:15] <murthy> clivejo: no not yet
[11:16] <clivejo> is it just a wily issue?
[11:16] <murthy> BluesKaj: do you know about the kde frameworks?
[11:16] <murthy> clivejo: no, its also in vivid
[11:20] <BluesKaj> murthy, the KF5 ?
[11:20] <clivejo> is this the source ? - https://github.com/albertvaka/kdeconnect-kde
[11:21] <murthy> BluesKaj: ya, what is the current version?
[11:23] <BluesKaj> 5.3.1 here
[11:23] <BluesKaj> Wiky
[11:23] <BluesKaj> err Wily
[11:24] <murthy> 5.3.1 is based on which version of qt?
[11:28] <murthy> I was looking at this bug https://bugs.kde.org/show_bug.cgi?id=344638   and it was a bug in qt and they have fixed it(I am not sure of that) https://codereview.qt-project.org/#/c/95219/    when will this change reach kubuntu?
[11:41] <BluesKaj> murthy, Qt5 from what I can see in muon
[11:44] <mitya57> murthy: according to that codereview the fix will land in Qt 5.5
[11:44] <mitya57> (we are going to have 5.5 in wily)
[11:51] <clivejo> BluesKaj: do you use kdeconnect?
[11:56] <clivejo> need to reboot
[11:56] <clivejo> brb
[12:25] <BluesKaj> claydoh, no, I don't have a smartphone
[12:26] <BluesKaj> sorry claydoh , meant clivejo
[13:09] <mparillo> ricktimmis: ovidiu-florin, ahoneybun: Thanks for the first Kubuntu podcast. Kubuntu Wire is back up: http://wire.kubuntu.org/?p=330 and that should automagically feed the KDE and Ubuntu Planets later today.
[15:30] <Tm_T> so I got Meizu MX4 from Ubuntu Insiders program today
[15:30] <Tm_T> first thing? Installing Kate
[15:31] <Tm_T> I'll try and see how much of Kubuntu stuff I can run on this before I go and factory reset and start over
[15:40] <ahoneybun> thanks mparillo!
[15:49] <genii> Tm_T: Good luck! :D
[15:54] <Tm_T> genii: thanks, I need it
[15:54] <Tm_T> thus far, nothing visual
[15:59] <ricktimmis> ahoneybun: Do you have access to last nights show notes ?
[16:00] <ricktimmis> ahoneybun: Any chance you could post them to mparillo so he can add them to Kubuntu Wire article
[16:00] <ricktimmis> I can't access them from work ;-)
[16:01] <ahoneybun> ricktimmis: yea give me a min'
[16:02] <ahoneybun> mparillo: here are the show notes: http://pastebin.ubuntu.com/11736043/
[16:11] <BluesKaj> http://www.kubuntu.org/getkubuntu has typo if you choose the 15.04 link , the next page has a typo saying 15.04 is LTS
[16:12] <ricktimmis> ahoneybun: Thanks, awesome and efficient as ever ;-)
[16:12] <ahoneybun> :)
[16:33]  * ricktimmis dives off...
[16:33] <ricktimmis> heading home, woo hoo !
[16:33] <ahoneybun> Riddell_ http://<IP_ADDRESS>/
[17:12] <ahoneybun> Sick_Rimmit: we are on the UWN
[17:17] <mparillo> BluesKaj: I think I can fix that. Let me try.
[17:17] <mparillo> ahoneybun: I will try to add. Not sure if the change will then flow through the planets.
[17:37] <ahoneybun> mparillo: its good, next time if not
[17:38] <mparillo> ahoneybun: How long did you ask the pastebin to last?
[17:38] <ahoneybun> um not sure
[17:38] <ahoneybun> did you need me to post it again?
[17:43] <ahoneybun> mparillo: https://paste.kde.org/pdvbsefbr
[17:47] <mparillo> No, I was just wondering if somebody clicks on the link next month, would the pastebin still work?
[17:48] <ahoneybun> oh well that one from kde is for a week
[17:57] <mparillo> BluesKaj: You have some eagle eyes. I think I found it and fixed launchpad bug 1466593. Could you check to make sure it was the one you well spotted?
[18:17] <soee> BluesKaj: ping
[18:26]  * soee jumping to Wily from Vivid ... :)
[18:29] <clivejo> soee: how did it go?
[18:29] <soee> clivejo: dunno yet, packages downloading
[18:34] <clivejo> hummm JOSM is being very slow today
[18:35] <clivejo> using over a 1GiB for some reason
[19:17] <BluesKaj> soee, pong
[19:21] <soee> brb rebooy
[19:24] <soee> i'm back
[19:24] <soee> on Wily now :)
[19:25] <soee> there was one error during upgrade from Vivid related to Virtualbox and upstart
[19:31] <clivejo> soee: do you use kdeconnect?
[19:32] <soee> clivejo: yes
[19:32] <clivejo> can you send a file from phone to computer?
[19:35] <soee> i have transfer finished message but file isint send i think
[19:35] <soee> brb, reboot
[19:35] <soee> and probably fixing nvidia driver
[19:38] <soee> oh interesting nvidia driver 352 from xorg edgers ppa works with wily
[19:38] <soee> but the nvidia-settings window is completely missing styles
[19:55] <soee> BluesKaj: on Wily kubuntu-desktop will be removed with latest updates no ?
[20:09] <BluesKaj> soee, yes afraid so , I don't have it installed. I tried to install it, but due to dependency problems it won't install due to ksysguard not going to be installed
[20:09] <soee> yup
[20:10] <soee> brb
[20:15] <clivejo> Hi Rick
[20:15] <clivejo> not sick today!
[20:25] <Rick_Timmis> clivejo: Much improved today, thanks
[20:29] <clivejo> good good
[22:06] <sitter> ScottK: any meeting time slot on the 26th that is better or worse for you?
[22:26] <ScottK> That's Friday, right?
[22:26] <ScottK> I can do Friday.
[22:41] <sitter> ok thanks
[22:42] <sitter> ximion: pick any slot you like
[23:56] <ximion> sitter: ah, thanks, I was going to ask who will pick the date anyway ;-)
[23:57] <ximion> Friday 26. looks like the best date so far, where most people can attend :)
[23:57] <ximion> I'll be travelling the next few days, will send a mail when I have internet again
[23:57] <ximion> (and I must book my flight to Akademy soon...)


[00:15] <sprite> hi
[00:15] <sprite> all
[00:16] <sprite> i have got 50gb account
[00:17] <sprite> but i would like just 20gb
[10:41] <duaneipho> morning all
[14:09] <shane4ubuntu> ok, I tried syncing Tomboy, of which it sync'ed some of my notes and refuses to work.  Google and launchpad turn up no hope, and tomboy refuses to let me change my sync options, how do I un-sync tomboy from U1?
[14:10] <shane4ubuntu> And once I un-sync, how do I delete the notes from U1? I didn't see any way to delete them on the web.
[14:14] <shane4ubuntu> Ohh, I found how to delete notes on web, however the tomboy sync'ing is a mess, any help, pointers, ideas, thoughts would be appreciated.
[14:31] <duanedesign> hello shane4ubuntu
[14:32] <duanedesign> shane4ubuntu: if you click on the Tomboy Applet and select Preferences
[14:33] <duanedesign> shane4ubuntu: the 'Synchronization' tab has a 'Clear' button
[14:34] <duanedesign> that will remove Tomboy from syncing with U1
[15:25] <shane4ubuntu> duanedesign, I must be blind!  Thanks a bundle for that.
[15:26] <mahen> hi
[15:28] <mahen> duanedesign: just got your message on launchpad : actually this bug was not solved (n° 666942)
[15:32] <duanedesign> oh ok
[15:33] <duanedesign> bug 666942
[15:33] <ubot4> duanedesign: Bug 666942 on http://launchpad.net/bugs/666942 is private
[15:34] <duanedesign> mahen: looks like jdobrien caught it
[15:34] <duanedesign> mahen: thank you for letting me know though
[15:35] <mahen> duanedesign: you're welcome. Thanks to you :)
[15:35] <duanedesign> there were a couple of you in that day I must of gotten you confused with someone else :)
[15:36] <duanedesign> could someone in ubuntuone hackers mark bug #665915  as Wont Fix, thank you.
[15:36] <ubot4> Launchpad bug 665915 in ubuntuone-client "Folders starting with '#' not uploaded (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/665915
[20:29] <shane4ubuntu> duanedesign, ok, after un-linking Tomboy with U1, I reconnected U1, and now tomboy refuses to start! :(  any ideas?  remove it and reinstall it?  where are it's config files
[20:31] <duanedesign> shane4ubuntu: try launching it from the Terminal and see if it tells you anything interesting
[20:31] <shane4ubuntu> did that, it just sits there and hangs doesn't do anything, and tomboy doesn't come up
[20:33] <shane4ubuntu> ok, and when I ps aux | grep tomboy I get Tomboy.exe showing up, I kill the pid with kill -9 pid and then run tomboy and nothing again, odd.
[20:34] <shane4ubuntu> really odd, because I was using my notes, then, I thought, oh I never started U1 back up, so I started that back up, and tomboy (tb) when crazy
[20:34] <shane4ubuntu> if any ideas come to you let me know I'm here working away
[20:38] <shane4ubuntu> duanedesign, ahh, got it, stopped U1. ;) now tomboy is working again.  that is odd.
[20:40] <duanedesign> that is odd
[20:40] <shane4ubuntu> I guess U1 has a selfish problem if U1 can't have my notes, than no one can. :)
[20:40] <duanedesign> shane4ubuntu: so did you do u1sdtool -q or Disconnect from the Preferences to get Tomboy to launch?
[20:41] <shane4ubuntu> u1sdtool -q
[20:41] <duanedesign> ok
[20:41] <shane4ubuntu> probably need to restart the service since I unlinked tomboy or something
[20:42] <duanedesign> shane4ubuntu: are these the instructions you used to setup our notes? https://wiki.ubuntu.com/UbuntuOne/Tutorials/Notes
[20:45] <shane4ubuntu> duanedesign, I think so, I don't know that I followed really any instructions, just saw that I could do that, and did it.  It worked and synced my notes, so I did the same on the laptop (don't think it sync'ed right though)
[20:45] <shane4ubuntu> and that was it, didn't sync after, made changes on my notes, and it didn't update on the web or the other computer.


[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00.   May not get too many from my team.
[15:03] <danilos> me
[15:04] <bac> i know we have a lot of people missing today due to sprints, so let's move on.
[15:04] <henninge> bac: jtv is sprinting
[15:04] <bac> [topic] agenda
[15:04] <MootBot> New Topic:  agenda
[15:04] <bac> yay, mootbot is not case sensitive!
[15:04] <gary_poster> heh
[15:04] <bac>  * Roll call
[15:04] <bac>  * Action items
[15:04] <bac>  * Limit doctests to 200 lines [allenap]
[15:04] <bac>  * Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
[15:04] <bac>  * Cleaning up ImportFascist warnings [bac,sinzui]
[15:04] <bac>  * Peanut gallery (anything not on the agenda)
[15:04] <allenap> me
[15:04] <intellectronica> me
[15:05] <danilos> allenap, (a nice trick to get pinged through agenda ;)
[15:05] <bac> [topic] outstanding actions
[15:05] <MootBot> New Topic:  outstanding actions
[15:05] <bac> [topic] * intellectronica to draft guidelines for drive-by cleanups
[15:05] <MootBot> New Topic:  * intellectronica to draft guidelines for drive-by cleanups
[15:06] <intellectronica> sorry, haven't done that. please keep it on the list and i'll get it for our next meeting
[15:06] <bac> intellectronica: excellent, thanks!
[15:06] <bac> [topic] invite other teams to do lazr-js code reviews? (See if this was sent to the ML.) [mars/bac]
[15:06] <MootBot> New Topic:  invite other teams to do lazr-js code reviews? (See if this was sent to the ML.) [mars/bac]
[15:06] <bac> i searched through the ML's and did not see it had been discussed
[15:06] <bac> mars did you have some thoughts on the topic?
[15:07] <mars> bac, I'm going to add it to the agenda for the lazr-js taskforce call tomorrow
[15:07] <bac> mars: ok, so you can report back here next week.
[15:07] <mars> bac, you can keep it on the list here if you would like to see a wrapup item next week
[15:07] <bac> [action] mars to report on outcome of lazr-js review discussion
[15:07] <MootBot> ACTION received:  mars to report on outcome of lazr-js review discussion
[15:07] <mars> yeah :)
[15:07] <bac> great, moving on to new items
[15:08] <bac> [topic] Limit doctests to 200 lines [allenap]
[15:08] <MootBot> New Topic:  Limit doctests to 200 lines [allenap]
[15:08] <bac> gavin, take it away
[15:09] <allenap> Right,
[15:09] <allenap> Because of the accumulation of state in doctests
[15:09] <allenap> I think it would be good to limit new doctests to 200 lines or less.
[15:10] <allenap> gmb wrote a new doctest last week of just under 200 lines and it was still perfectly comprehensible.
[15:10] <allenap> So that's where the number comes from.
[15:10]  * gmb notes that it got changed into a unittest anyway during the review process...
[15:10] <danilos> I don't think that'd be right for large classes and corresponding doctests, 200 sounds as artificially low limit
[15:11] <allenap> Although manuel (?) adds a reset-globs directive whihc might make this moot.
[15:11] <flacoste> and there is an alternative to the state problem
[15:11] <danilos> perhaps large classes are the problem, but we do have them
[15:11] <flacoste> exactly, reset-globs in manuel
[15:11] <gary_poster> agree with danilos.  Also, agree with allenap's observation of manuel
[15:11] <sinzui> allenap: I have thought about breaking many registry doctests into smaller themes
[15:11] <flacoste> manuel also adds the option of running specific section of a doctest
[15:11] <sinzui> allenap: but my motivation it to control the layer the test is run on.
[15:12] <intellectronica> i think limiting the length is not the best way to handle this. instead i suggest dividing tests thematically
[15:12] <mars> I agree, I don't see the problem as much with larger narratives as it is with naughty test code state.
[15:12] <danilos> sinzui, I think the problem with existing doctests is that we don't have a good structure of tests in general (oh, I'd like to clean most of translations ones as well)
[15:12] <intellectronica> that is, stop and start a new file when you're really testing something new (with new state and so on)
[15:12] <bac> intellectronica: i agree
[15:13] <allenap> The main problem I have is trying to understand the object and database state by the end of the test. That can't really be fixed by reset-globs or manuel as I understand it.
[15:13] <danilos> intellectronica, +1, basic doctests (those which are usually large) should be basic class documentation; specific tests should be unit test
[15:13] <allenap> intellectronica: The limit is an incentive to split :)
[15:14] <allenap> intellectronica: But I agree.
[15:14] <danilos> allenap, I see the point, but artificial limit would have to be broken in so many valid cases
[15:14] <intellectronica> allenap: yes, i understand that, but somehow it feels a bit too artificial to me. are you concerned that without a hard limit developers/reviewers won't bother?
[15:14] <bac> allenap: it is a good point but i'd rather see us have smaller, more themed tests as a guide rather than adopting a limit
[15:14] <gary_poster> We do have a "800 line limit for reviews" that is a guideline but often breached
[15:15] <intellectronica> also, i'll play sinzui and ask: who's going to split all the existing test? ;)
[15:15] <danilos> how about instead spreading a rule "enforce corner-case testing through unit tests" among reviewers instead? those tend to make doctests harder to read
[15:15] <mars> instead of a hard limit, can we call it a "refactor point"?  As in, over X lines, the reviewer should look for a possible refactoring
[15:15] <allenap> Okay, sounds good. Is there a way to measure or have more concrete guidelines, or is it at developer/reviewer discretion?
[15:15] <mars> it's ok if they do not find such a point
[15:15] <mars> kind of like review lint
[15:16] <intellectronica> allenap: there is a measure. variables shouldn't be recycled
[15:16] <danilos> mars, I still believe that those complex doctests should really be turned into unittests, and that's exactly where you can't reuse variables :)
[15:16] <allenap> intellectronica: I don't think we should split the existing tests... until it is no longer possible to not split them.
[15:16] <allenap> intellectronica: I like that :)
[15:16] <allenap> intellectronica: There's still a problem of db state.
[15:16] <mars> danilos, well, if they are over 800 lines, then you would recommend the refactoring, wouldn't you? :)
[15:17] <intellectronica> allenap: if we adopt this as a policy we will eventually have to split the tests, if only so that they don't serve as a negative example for new contributors
[15:17] <allenap> danilos: +1
[15:17] <mars> danilos, or 400, or whatever
[15:17] <sinzui> intellectronica: One line that creates a file or email message requires that the test be run on a different layer. In many cases the test is actually moving to a new theme and I think it is easier to read the that aspect of the test separately.
[15:17] <allenap> intellectronica: Good point.
[15:17] <intellectronica> allenap: i guess it's the same for db state. don't rely on db state unless it's either set in the sample data or in the prologue to your test
[15:18] <danilos> mars, well, reviewers should always look for points of refactoring, so I just feel such "rule" wouldn't really make any difference, but sure :)
[15:18] <allenap> intellectronica: I agree, and I don't know of a way to make it less vague than that. I suppose that's what I was looking for.
[15:18] <gary_poster> I find the stories that doctests tell valuable.  The stories are often long--and in fact, I often wish they were *better* connected, not less, from a narrative standpoint.  That viewpoint would make me want to see manuel a preferred option, or perhaps Sphinx involved for tying together story chunks, but that is maybe herder.
[15:18] <intellectronica> sinzui: so what you're saying is that we should split tests if we're required to run the test in a lower layer because of a change in the middle of the test?
[15:18] <danilos> mars, even when the diff you are looking at is 10 lines, as a reviewer, you should wonder if the code is sitting in the right place
[15:19] <gary_poster> and means that it doesn't help for reading text files, only processed files
[15:19] <mars> danilos, well, I don't think of it as a rule, just a recommendation for reviewers.  Kind of a warning, or code advice.
[15:19] <gary_poster> s/herder/harder/
[15:19] <mars> danilos, right
[15:19] <danilos> anyway, it seems this is a hot topic
[15:20] <danilos> allenap, bac, shall we move it to the mailing list or try to come up with a conclusion here?
[15:20] <gary_poster> I think a lot of people talking about dividing things up are coming from the perspective of (1) expertise and (2) testing.
[15:20] <sinzui> intellectronica: yes. In the exampled I am thinking about, registiry object deletion, email notification, these themes are different from the core uses of the object.
[15:20] <allenap> danilos: Mailing list I think. There are many threads of conversation and this isn't going to end here anyway ;)
[15:21] <gary_poster> they are valuable, but these are narratives.
[15:21] <intellectronica> sinzui: yes, i think that's a good guideline
[15:21] <danilos> allenap, right, I think the general consensus is that we don't want 200 as the limit, so it's best to discuss other solutions to the problem you observe on list
[15:21] <bac> danilos: yes, let's move the discussion to the mailing list.  allenap will you start the discussion there?
[15:21] <allenap> bac: Sure.
[15:21] <mars> gary_poster, good point
[15:21] <gary_poster> :-) thank you mars
[15:21] <bac> [action] allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
[15:21] <MootBot> ACTION received:  allenap to start discussion on the ML about doctest size, refactoring, moving corner cases to unittests, etc
[15:22] <bac> [topic] Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
[15:22] <MootBot> New Topic:  Security checks: ``try:...except UnauthorizedError:...`` vs. canView [gary]
[15:22] <gary_poster> OK I almost have the conversation pastable but not quite.
[15:22] <gary_poster> I was talking with EdwinGrubbs about a security check.  He was checking whether a user had a specific permission on an object.  He was using a utility in the LP tree that I forget.
[15:22] <gary_poster> I said that my top preference would be try:...except UnauthorizedError:... and my next preference would be canAccess and canWrite from zope.security.checker.
[15:22] <gary_poster> canView is nicer because you do not specify the permission, which is fragile.
[15:22] <gary_poster> The try/except approach uses the basic security machinery directly.  It is of course the basic mechanism that Zope provides.
[15:22] <gary_poster> Edwin pointed out that this was not a pattern in the LP tree.  He was also afraid it would be slower.
[15:22] <gary_poster> I'm pretty sure it will not be slower than calling a Python function, but can verify with a timeit test.
[15:23] <gary_poster> So, I suppose I have these thoughts:
[15:23] <gary_poster> 1) I'd like to make sure that we generally agree that we don't want to specify permissions unless we have to
[15:23] <gary_poster> (that is, my main suggestion from the story above)
[15:24] <gary_poster> 2) I'd like people to consider using the try/except approach, and for it to be a reasonable/approved one.  If we want me to construct a timeit test to verify I can.
[15:24] <gary_poster> That's it.
[15:25] <gary_poster> s/conversation pastable/introduction pastable/ ;-)
[15:25]  * danilos reads
[15:25] <intellectronica> gary_poster: i also think that using try/except is clearer
[15:25] <gary_poster> cool
[15:26] <bac> i think a lot of us have heard the "wisdom" that try/except is slower.  i think a timeit test to disprove that would be useful.
[15:26] <danilos> I know we are using checkPermission for these things
[15:26] <gary_poster> EdwinGrubbs: are you around to say remind me what the utility was that you used at first?
[15:26] <gary_poster> Maybe it is checkPermission
[15:26] <EdwinGrubbs> yes, it was check_permission()
[15:27] <danilos> from canonical.launchpad.webapp.authorization import check_permission
[15:27] <gary_poster> ah ok, looking
[15:27] <danilos> bac, +1
[15:27] <flacoste> it's a wrapper around checkPermission
[15:27] <intellectronica> bac: why is performance an issue here? usually you don't call these in loops
[15:27] <gary_poster> flacoste: oh ok
[15:27] <danilos> example: check_permission('launchpad.Edit', pofile)
[15:27] <flacoste> and i think actually the try: except: is what is used under the hood by check_permission anyway
[15:27] <EdwinGrubbs> you do call them in loops if you are displaying a list of objects
[15:27] <gary_poster> so generally, I don'y think we should use check_permission (or checkPermission) again, if at all possible.  That's my #1,
[15:28] <gary_poster> canAccess and canWrite are less fragile
[15:28] <gary_poster> I'm happy to do the timeit check.  I still think that try/except will be faster than a Python function, but I think that's interesting information, so I can do that and report back to the list.
[15:28] <henninge> gary_poster: Is this in view or in model code?
[15:29] <EdwinGrubbs> view code
[15:29] <bac> intellectronica: it may be in a loop.  if some timing tests can show it is a myth then i think that's useful.
[15:29] <henninge> good
[15:30] <intellectronica> bac: knowing is definitely useful, but i think that even if we find that it is slower, we should still consider using try/except in cases where it doesn't affect performance _drastically_
[15:30] <flacoste> hmm, right
[15:30] <flacoste> canAcess / canWrite uses try: except
[15:30] <flacoste> whereas checkPermission uses the checker information
[15:30] <bac> intellectronica: well, a lot of these cases are in vocabularies, IIRC.  many of those do have performance issues
[15:31] <intellectronica> bac: yes, where we do it iteratively we definitely should optimize for performance
[15:32] <danilos> the reason I don't like try...except is that (especially with API), we will get a lot of cases where we'll have multiple conditions we are checking for
[15:32] <danilos> so, nested try..excepts sound ugly to me
[15:32] <gary_poster> If try:except is faster, as I suspect, then we do not have to have the theoretical discussion.  suggested resolution for now: I'll do the timeit test and report back to the list.  If there is a clear answer in favor of try/except for performance as well, then that's easy.  ...except for danilo's case...
[15:33] <gary_poster> danilo, can you send me an example to look at?
[15:33] <danilos> gary_poster, I am not even sure it's a valid example, but there are cases where we do an OR of multiple permission checks
[15:34] <gary_poster> danilos: right, I'd like to see if it is valid; if it is not, we should know what a preferred spelling us
[15:34] <danilos> but that's probably just bad design where objects are not properly security-wrapped
[15:34] <bac> [action] gary to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again next week.
[15:34] <gary_poster> is
[15:34] <MootBot> ACTION received:  gary to do timing tests for try/except, examine current usage of check_permission, and we'll discuss again next week.
[15:34] <gary_poster> cool thanks
[15:34] <bac> thanks for bringing it up gary
[15:35] <bac> [topic] Cleaning up ImportFascist warnings [bac,sinzui]
[15:35] <MootBot> New Topic:  Cleaning up ImportFascist warnings [bac,sinzui]
[15:35] <bac> jml's fix to the import fascist revealed lots of places where we have problems
[15:36] <bac> we need to drive those warnings back to zero or we'll continue to expand the problem
[15:36] <danilos> gary_poster, sure, why don't you ping me later and we can take a look (basically, lp.translations.browser.distroseries.DistroSeriesLanguagePackView has an example)
[15:36] <bac> sinzui has a branch that accomplishes a lot of it but has reported new code is  introducing more problems
[15:36] <bac> sinzui where did you find the bulk of the offenders to be?
[15:36] <gary_poster> danilos: awesome thank you
[15:37] <sinzui> Most were explicit import from _schema_circular_imports which were not needed
[15:37] <sinzui> They were easy to remove
[15:37] <bac> sinzui: does your branch solve the problem for LP or just registry?
[15:37] <sinzui> LP, but there are two new ones in the last 12 hours
[15:38] <bac> ah, cool.  so once this branch lands we can go back to zero tolerance as reviewers, no?
[15:38] <sinzui> BranchJobDerived BranchJobType are not in BranchJob.__all__, but are imported by translationtemplatesbuildjob and translationtemplatesbuildjob
[15:38] <gary_poster> should we make them errors?
[15:39] <gary_poster> I thought that was an option
[15:39] <sinzui> I could add these two classes to __all__, but I think the code team and translations team need to coordinate
[15:39] <danilos> sinzui, if it has happened during last 12h, it's something that's happening during a sprint in Wellington
[15:40] <sinzui> correct
[15:40] <danilos> sinzui, and I don't really overlap with them, so I'd appreciate if you mention it to jtv when he shows up and I am sure he'll be happy to fix the issue or find someone who will :)
[15:40] <sinzui> I will
[15:40] <danilos> sinzui, thanks
[15:41] <bac> so we're in agreement to get this cleaned up over the next week and then keep it under control?
[15:41] <danilos> sinzui, and thanks for spending the effort to fix it everywhere else as well, I hope we didn't have many issues in translations since we shouldn't be able to import stuff if we do (because we are not using global imports either)
[15:41] <danilos> bac, +1
[15:42] <bac> [action] sinzui to land a import cleanup branch and then reviewers will enforce zero tolerance for introducing new issues.
[15:42] <MootBot> ACTION received:  sinzui to land a import cleanup branch and then reviewers will enforce zero tolerance for introducing new issues.
[15:42] <bac> that's it for agenda items
[15:42] <danilos> sinzui, bac: just to confirm, this will also be part of lint checks?
[15:42] <bac> [topic] peanut gallery
[15:42] <MootBot> New Topic:  peanut gallery
[15:42] <sinzui> landing is challenging since we are in phantom testfix
[15:42] <danilos> (i.e. easy to spot)
[15:43] <danilos> sinzui, js buildbot?
[15:43] <bac> danilos: i'm not sure.  sinzuie?
[15:43] <bac> er, sinzui?
[15:43] <sinzui> danilos: importfacist has never been a part of lint since the testrunner has alwyas reported them
[15:43] <bac> thanks
[15:43] <sinzui> danilos: I thought I saw rockstar land a reversion to get us out of testfix
[15:44] <flacoste> sinzui: it's not phantom
[15:44] <flacoste> db_lp has three failures
[15:44] <bac> moving on, does anyone have an issue that is not on the agenda?
[15:44] <flacoste> related to code hosting
[15:44] <flacoste> i have
[15:44] <bac> flacoste: go
[15:44] <flacoste> but it's not related to reviewers :-)
[15:44] <bac> hmm
[15:44] <flacoste> but would like the opportunity that we have a lot of attention :-)
[15:44] <flacoste> we need a volunteer to fix the db_lp failures
[15:44] <bac> flacoste: ok, reminding you we're at 45 minutes
[15:45] <flacoste> that's all
[15:46] <flacoste> bac: you can cloase the meeting
[15:46] <bac> flacoste: let's try to resolve that outside the meeting
[15:46] <bac> #endmeeting
[15:46] <MootBot> Meeting finished at 09:46.
[15:46] <bac> thanks everyone for coming
[15:46] <gary_poster> thanks bac
[15:47] <mars> thanks bac
[15:47] <flacoste> these are the errors:
[15:47] <flacoste> Tests with errors:
[15:47] <flacoste>    lp.code.model.tests.test_branchjob.TestRevisionsAddedJob.test_getMergedRevisionIDs
[15:47] <flacoste>    lib/canonical/launchpad/ftests/../../../lp/bugs/doc/bug-set-status.txt
[15:47] <danilos> thanks bac
[15:47] <flacoste>    lp.code.model.tests.test_codeimport.TestCodeImportDeletion.test_deleteIncludesJob
[15:47] <bac> flacoste: what about the other two?
[15:47] <sinzui> LayerIsolationError
[15:47] <bac> oh, nm
[15:47] <sinzui> for all of them
[15:48] <flacoste> indeed
[15:48] <sinzui> I suspect the test env, not the test
[15:48] <flacoste> well
[15:48] <flacoste> test_deleteIncludesJob
[15:48] <flacoste> is an Unauthorized error
[15:49] <sinzui> sorry, I did not see that
[15:49] <flacoste> well, no
[15:49] <flacoste> layerIsolationError are problems with the test
[15:49] <flacoste> it means that an object created by the test cannot be garbaged collected
[15:51] <sinzui> The bug test has not change in 6 months, and before that 2 years ago
[15:53] <flacoste> right
[15:53] <flacoste> the problem is that these layerIsolation might not be directly associated with the test
[15:53] <flacoste> but it sure comes from some kind of changes
[15:54] <flacoste> looking at the garbage left, it seems to be bzrlib objects
[15:54] <sinzui> I saw this happen when the order of tests changed
[15:54] <sinzui> I had to set the dirty db flag in some tests to fix the issue
[15:55] <flacoste> was the garbage related to bzr in that case?
[15:56] <flacoste> should we simply revert these revisions?
[15:56] <sinzui> No. two or three years ago I discovered that many unit tests were creating objects. I had to modify the tearDown(). The error was only observed by testing the layer
[15:56] <flacoste> is the Unauthorized error reproducible locally at least?
[16:01] <sinzui> No it does not fail
[16:13] <flacoste> sinzui: should we simply trigger a rebuild?
[16:15] <sinzui> flacoste: I was tempted.
[17:24] <sinzui> mars: do you have a script that scores new users yet?
[21:46] <sinzui> losas ping
[21:56] <jml> sinzui, what's your boggle?


[00:52] <bazhang> [Druid-] (~quassel@xdsl-31-165-100-45.adslplus.ch): selsper
[00:53] <bazhang> I seem to recall some issues with him
[11:07] <bazhang> is yankdownunder offering up some quality advice of late
[18:39] <elky> bazhang: what have you tried to get them more focussed?
[23:35] <bazhang> yankdownunder seems to just make things up as support