[00:58] <cprofitt> hello everyone
[00:58] <cprofitt> we will begin the Ubuntu Friendly meeting in roughly two minutes
[00:59] <SergioMeneses> hi all!
[01:00] <cprofitt> #startmeeting ubuntu-friendly
[01:00] <meetingology> Meeting started Wed Feb  6 01:00:17 2013 UTC.  The chair is cprofitt. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[01:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[01:00] <cprofitt> #meetingtopic welcome back
[01:00] <cprofitt> hello all -- and welcome to the Ubuntu Friendly meeting
[01:01] <cprofitt> can everyone that is here for the meeting just let me know you are in the room
[01:02] <SergioMeneses> o/
[01:02] <phillw> o/
[01:02] <cprofitt> thanks for coming everyone
[01:02] <cprofitt> our agenda is:
[01:02] <pleia2> o/
[01:03] <cprofitt> hexr, wiki cleanup, how to improve parts of the Ubuntu Friendly system
[01:03] <cprofitt> your questions and any advice/ideas you all have
[01:03] <cprofitt> baloons are you here?
[01:03] <SergioMeneses> #link https://wiki.ubuntu.com/UbuntuFriendly/Meetings
[01:04] <cprofitt> alright... I might have baloons take over if he comes in, but let me tell you a bit about hexr
[01:04] <cprofitt> #meetingtopic hexr
[01:05] <cprofitt> #link https://launchpad.net/hexr
[01:06] <cprofitt> hexr, from my understanding, will potentially make use of the same data Ubuntu Friendly does, but it will do so to see what harware components have been tested
[01:06] <cprofitt> so it will seek to find out of a specific Nvidia card has been tested or a specific wireless card
[01:07] <cprofitt> and not look at systems, but components
[01:07] <cprofitt> #link https://launchpad.net/~hexr-dev/+members#active
[01:07] <cprofitt> the developers are listed on that page
[01:08] <cprofitt> I think knowing that could help Ubuntu Friendly add some more functionality to the site -- where people might be able to sort systems based on a desired video card or wireless card...
[01:08] <cprofitt> for now it is just something for us to know as we move forward
[01:09] <cprofitt> #topic wiki clean up
[01:09] <cprofitt> how many of you have had time to look at the wiki page for UF?
[01:09] <cprofitt> #link https://wiki.ubuntu.com/UbuntuFriendly/
[01:10] <cprofitt> would anyone  be willing to take on reviewing the pages to ensure that they are up-to-date?
[01:11] <SergioMeneses> cprofitt, we can put some icons
[01:11] <SergioMeneses> cprofitt, I can do it
[01:11] <cprofitt> #action SergioMeneses will review the Ubuntu Friendly wiki
[01:11] <meetingology> ACTION: SergioMeneses will review the Ubuntu Friendly wiki
[01:11] <cprofitt> thanks SergioMeneses
[01:11] <cprofitt> please feel free to ask for help from others as you do that
[01:12] <cprofitt> if anyone else knows of pages that need updates please let SergioMeneses or me know
[01:12] <SergioMeneses> cprofitt, ok
[01:12] <chilicuil> ok =)
[01:12] <cprofitt> #topic improvements
[01:13] <cprofitt> I know from personal experience we have some things to improve moving forward
[01:13] <cprofitt> phillw: did you want to discuss some of the thoughts you had?
[01:13] <cprofitt> anyone else?
[01:14] <cprofitt> #subtopic submissions
[01:14] <phillw> cprofitt: just to mention that you and laptop team are quite similar and I hope there is a good flow of informations between you both :)
[01:14] <cprofitt> phillw: I would hope so as well.
[01:15] <cprofitt> One of the things that got me involved was submissions
[01:15] <cprofitt> right now it is my understanding that submissions are not getting in to UF
[01:15] <cprofitt> but I am not sure why that is
[01:15] <pleia2> phillw: hm, I thought the laptop testing team was for testing Ubuntu on laptops for upcoming releases, not reporting on how well supported laptops are in current releases
[01:16] <SergioMeneses> Im totally agree with pleia2,
[01:17] <phillw> pleia2: ergo, one a release is out, that information is available to what is then the 'current' release?
[01:17] <phillw> *once*
[01:18] <cprofitt> I would like to see two things done to improve in regards to submissions
[01:18] <pleia2> phillw: but it would be results for when it was in development, so maybe the graphics card for that one laptop finally did end up working once the release happened, the results would be from when it wasn't working :\
[01:18] <pleia2> for example
[01:18] <phillw> i see, I'll have a chat with the laptop team :)
[01:18] <cprofitt> pleia2: I agree.. the results from pre-release could would not be invluded in Ubuntu Friendly
[01:19] <pleia2> they're both valueable and needed projects, for sure, I just thing they provide different data to different audiences
[01:19] <pleia2> s/thing/think
[01:19] <cprofitt> but the laptop testing team could, upon release, be a group of people who ran the tests for UF
[01:19] <pleia2> cprofitt: indeed!
[01:20] <cprofitt> and from my understanding the database we are pulling from might actually be the same -- but with different criteria for what information is included
[01:20] <cprofitt> and also differences in how it gets displayed
[01:20] <pleia2> it makes sense for both projects to test the same things
[01:20] <cprofitt> but I would need one of the developers to give me more information on that
[01:20] <cprofitt> I would like to see two things done to improve in regards to submissions
[01:21] <cprofitt> 1.  some system be put in place to make it easy for those submitting results to know that the results were processed
[01:21] <cprofitt> if the result was invalid - let them know why
[01:22] <cprofitt> as a person who has submitted results and never saw my results in UF I know how that can cause someone to lose interest in contributing
[01:22] <pleia2> +1
[01:23] <cprofitt> 2.  I would also want to have a group of people that could look at invalid results to ensure that how the data is being processed is accurate -- that the automated system is not makring valid results as invalid
[01:23] <cprofitt> this is particularly important as hardware changes...
[01:23] <cprofitt> failure to test a card reader when there is no such device present should not invalidate results
[01:24] <cprofitt> any other comments in regards to submissions?
[01:24] <cprofitt> #subtopic checkbox
[01:25] <cprofitt> that brings me to one more idea
[01:25] <cprofitt> this one is not mine, but one that has been discussed in the qa channel
[01:25] <cprofitt> there may be a need to refine checkbox a bit to allow for a 'simple' test
[01:26] <cprofitt> or in the case of hexr a test of specific hardware
[01:26] <cprofitt> the simple test would be an abbreviated test to make sure that basic things like wireless work etc.
[01:27] <cprofitt> I also had cases when I tested where the automated test 'failed' itself, but I knew the device was working
[01:27] <cprofitt> I think there should be some sort of mechanism for making a note of that issue built in to checkbox so that changes can be addressed with those issues
[01:28] <cprofitt> having devices 'fail' a test when they are actually working undercuts people's faith in the process and the results.
[01:28] <cprofitt> any thoughts in that area?
[01:28] <roadmr> o/
[01:28] <cprofitt> yes, roadmr
[01:29] <roadmr> hello! first, if an automated test fails when the device is working, that means a bug that we'd like to get fixed
[01:29] <roadmr> I understand this adds a lot of friction to things, so maybe thinking of ways to make this more effortless may be worthwhile
[01:29]  * cprofitt nods
[01:29] <roadmr> second, the automated tests are in general more reliable but they are also quite valuable in high-volume environments
[01:30] <roadmr> if we assume that people can be trusted, we can potentially use manual test cases instead of automated ones that are most unreliable
[01:30] <roadmr> even so, it would be good to collect some information that can be automatically analyzed, maybe server-side
[01:30] <roadmr> this way we can potentially re-score a submission given the raw data, even after-the-fact
[01:30] <pleia2> admittedly there is some trust to an extent already in the testing (you can hear a sound, etc)
[01:30] <cprofitt> I too, would prefer to get the automated tests working... I think human interaction always introduces some potential for error
[01:31] <roadmr> this would however introduce a "we're collecting stuff and sending it up to canonical" factor that some people don't like
[01:31] <cprofitt> I do like rescoring a submission after the fact
[01:31] <roadmr> so this is an area for improvement but we always have the option of doing this manually
[01:31] <cprofitt> roadmr: in this case I think the 'collecting data' part is voluntary
[01:31] <cprofitt> at least with checkbox
[01:32] <roadmr> cprofitt: yes, well in order to determine what's going on, some extensive logs would need to be collected
[01:32]  * cprofitt nods
[01:32] <roadmr> cprofitt: but keeping the user in control would be the best
[01:32] <roadmr> pleia2: hehe, we sought to remove the human factor from that by adding an automated audio_test :) so the computer listens to itself
[01:32] <cprofitt> could that be an optional part of checkbox -- that a user would opt-in to collecting additional data?
[01:32] <roadmr> anyway, those are my ideas on this
[01:33] <pleia2> roadmr: does it work? I guess I haven't run it in a bit :)
[01:33] <cprofitt> I appreciate the feedback and information roadmr
[01:33] <roadmr> cprofitt: sure, with the current checkbox architecture it feels a bit complex to do, but we can always change that, we should bend the tool to the needs, not the other way around
[01:33] <roadmr> pleia2: as long as you have a microphone and speakers, it works and it's very reliable
[01:33] <pleia2> nice
[01:34] <cprofitt> roadmr: +1 we want to make it easy for people to collect data for this type of use -- improving user experience
[01:34] <cprofitt> roadmr: do you have any insight as to why results are not getting included in to Ubuntu Friendly or is that outside of your scope?
[01:35] <roadmr> cprofitt: I have a pretty good idea why, yes
[01:35] <cprofitt> could you go a bit in to that for us?
[01:36] <roadmr> cprofitt: two components are involved in this, the first is checkbox, which runs the tests, assembles a report and pushes that to launchpad
[01:36] <roadmr> the second is the UF website/application, which pulls the reports (submissions) from launchpad and adds the results to the friendly database (what you see in the website) - does the scoring, aggregation and such
[01:37] <roadmr> for a submission to appear at all, it needs to contain (and pass) all tests identified as "core"
[01:37] <roadmr> the basics for a computer to be usable, if any core tests are failed the submission will not appear in UF
[01:37] <roadmr> if it passes the "core" tests, it gets 3 stars, and any additional tests it passes increase its rating, up to 5 stars
[01:38] <roadmr> a 5-star rating means that all the components we test work perfectly
[01:38] <roadmr> so why would a submission not appear?
[01:38] <roadmr> some of the core tests are automated, and checkbox is not very good at 1) telling you one of them failed, and 2) letting you rerun/amend the results
[01:39] <roadmr> checkbox itself has no idea of core tests, so it can't tell you "hey, your card reader didn't work and that means you won't make it into UF - please rerun this before submitting"
[01:39] <cprofitt> is there currenlty anyway for a person who has submitted the test to see their submissions on launchpad?
[01:40] <roadmr> that's one reason, the second is that since the UF website needs some love, there may have been a bit of "drift" into the tests checkbox submits and performs, the UF site has not been updated as checkbox whitelists (sets of tests to run) change
[01:40] <roadmr> those would be the two main reasons
[01:40] <roadmr> cprofitt: there's a cryptic url that you an access to see your submissions, let me find it
[01:40] <cprofitt> so, it sounds like the key is giving the user some feedback as to if their device failed a core test... and also allowing for them to resubmit
[01:40] <roadmr> cprofitt: https://launchpad.net/~/+hwdb-submissions
[01:41] <roadmr> cprofitt: yep, again, something that's a bit difficult to do with the current checkbox architecture which is very linear :( think of the difference between linear and non-linear video editing
[01:41] <roadmr> in a sense, with checkbox we can only ffwd, rewind, and look at the results at the very end
[01:41]  * cprofitt nods
[01:42] <roadmr> with no/little chance of going back to a specific test.
[01:42] <cprofitt> exactly...
[01:42] <cprofitt> it is also my understanding there is no ability to 'pause' a test and come back and pick up where you left off
[01:42] <roadmr> there is, but it's very awkward heheh
[01:42] <cprofitt> roadmr: is there currently any team that reviews the failed submissions?
[01:43] <roadmr> what you do basically is murder checkbox, when you restart it does its best to pick up where it left off
[01:43] <roadmr> it gives you three choices: rerun the last test, skip to the next one (in case the last test outright crashed the system), or start anew
[01:43]  * cprofitt nods
[01:43] <roadmr> the message is quite terse and the choices are somewhat ambiguous, so most people are/will be confused by this
[01:44] <roadmr> cprofitt: reviewing failed submissions, not really, no. It can be done but pretty much the only person who can and knows how to do it is jedimike, by looking at how the UF results importer processed a submission
[01:44] <roadmr> he'd have more specifics on how to do it, but it's done on an ad-hoc basis
[01:45] <cprofitt> roadmr: thanks
[01:45] <roadmr> np :)
[01:45] <cprofitt> I asked because I saw that as part of the launchpad team description
[01:45] <cprofitt> does anyone else have any questions for roadmr?
[01:46] <cprofitt> I would like to set an initial priority for the team moving forward
[01:46] <cprofitt> I think that we have two high value items
[01:47] <cprofitt> 1.  Improving the UF website process so that there is some feedback to the person who submitted the system as to the fact the results were processed but failed
[01:47] <cprofitt> 2.  Documenting the current process - so others can understand it as we start to look at improving it
[01:47] <cprofitt> are there any other items people see?
[01:48] <cprofitt> roadmr: would you be willing to procude a flow chart of what you described that we could them use on the wiki?
[01:48] <cprofitt> just a rough outline of how the process currently flows?
[01:49] <roadmr> cprofitt: sure
[01:49] <roadmr> cprofitt: there's some documentation (an outline plus more detailed links) here: https://friendly.ubuntu.com/what-is-ubuntu-friendly/
[01:49] <cprofitt> #action roadmr will produce a flow chart of the current process
[01:49] <meetingology> ACTION: roadmr will produce a flow chart of the current process
[01:49] <cprofitt> #vote agree that improving feedback on submissions is important in moving foward
[01:49] <meetingology> Please vote on: agree that improving feedback on submissions is important in moving foward
[01:49] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (private votes don't work yet, but when they do it will be by messaging the channel followed by +1/-1/+0 to me)
[01:49] <cprofitt> +1
[01:49] <meetingology> +1 received from cprofitt
[01:50] <roadmr> +1 definitely heh
[01:50] <meetingology> +1 definitely heh received from roadmr
[01:50] <chilicuil> +1
[01:50] <meetingology> +1 received from chilicuil
[01:50] <SergioMeneses> +1
[01:50] <meetingology> +1 received from SergioMeneses
[01:50] <cprofitt> pleia2: ?
[01:50] <cprofitt> phillw: ?
[01:50] <phillw> +1
[01:50] <meetingology> +1 received from phillw
[01:51] <phillw> sorry wasnm't sure if i was to vote :)
[01:51] <cprofitt> #endvote
[01:51] <meetingology> Voting ended on: agree that improving feedback on submissions is important in moving foward
[01:51] <meetingology> Votes for:5 Votes against:0 Abstentions:0
[01:51] <meetingology> Motion carried
[01:52] <cprofitt> I think for now we should move towards that; after we get that feedback improved we need to look to make some improvements to checkbox as roadmr mentioned
[01:52] <cprofitt> any other topics, questions or thoughts?
[01:52] <roadmr> o/
[01:52] <cprofitt> yes, roadmr
[01:53] <SergioMeneses> when is our next meeting?
[01:53] <roadmr> hehe, one thing that we *can* potentially do with current checkbox is make it submit directly to a (possibly updated) UF application, so feedback is quicker
[01:53] <roadmr> this needs writing a "plugin" and an accompanying web application, so it would need some coordination
[01:53] <cprofitt> +1 roadmr that should be explored
[01:53] <roadmr> we're still on time to make that happen before Ubuntu Feature Freeze, but we'd have to start working soon
[01:54]  * cprofitt nods
[01:54] <roadmr> ideally we sould ask jedimike if there's a way to submit directly to the UF application, because we may not have a lot of manpower to come up with a new one
[01:54] <roadmr> sould/should
[01:54] <cprofitt> SergioMeneses: I would like us to meet again in two weeks -- I think to be fair to some of the UTC
[01:54] <roadmr> that may be a quick way to reduce the decoupling between submission and actual result processing
[01:55] <cprofitt> folks we should have the meeting earlier; though that would require a different person to chair the meeting
[01:55] <SergioMeneses> perfect
[01:55] <cprofitt> roadmr: I know jedimike has spoken to me about that so I will try to touch bases with him about that
[01:55] <cprofitt> are any of you in the UTC 0/+1 TZ?
[01:57] <phillw> 'im on utc
[01:57] <cprofitt> alright... I will send a message to the list and see if I can get a person in that TZ to chair a meeting.
[01:57] <roadmr> cprofitt: I'm EST (UTC-5)
[01:57] <cprofitt> phillw: would you be willing to chair a meeting on the 19th?
[01:57] <cprofitt> roadmr: I am on your TZ as well
[01:57] <phillw> I can if no one steps forward :)
[01:57] <SergioMeneses> Im UTC-5
[01:57] <cprofitt> phillw: ok, I will send the request to the list and you will be the fall back
[01:58] <cprofitt> #action next meeting February 19th UTC 17:00 - cprofitt will send a message to the list to get a chair
[01:58] <meetingology> ACTION: next meeting February 19th UTC 17:00 - cprofitt will send a message to the list to get a chair
[01:58] <phillw> what time on 19th are you thinking of?
[01:59] <phillw> yeah, 1700 utc would be okay if no one steps forward.
[01:59] <SergioMeneses> 17 utc
[01:59]  * cprofitt nods
[01:59] <cprofitt> yes, SergioMeneses so noon our time
[01:59] <SergioMeneses> cprofitt, it's not problem for me
[01:59] <cprofitt> thanks SergioMeneses phillw pleia2 chilicuil roadmr for attending. I think this has been very productive for an initial start
[02:00] <cprofitt> #endmeeting
[02:00] <meetingology> Meeting ended Wed Feb  6 02:00:04 2013 UTC.
[02:00] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-06-01.00.moin.txt
[02:00] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-06-01.00.html
[02:00] <pleia2> thanks for chairing :)
[02:00] <phillw> thanks for chairing
[02:00] <SergioMeneses> cprofitt, thanks to you
[02:00] <chilicuil> I'm looking forward for helping out, I'll see you in the ml =)
[02:00] <cprofitt> chilicuil: thanks
[02:00] <cprofitt> thanks again everyone
[02:01] <phillw> I'm off to bed! 2am here :)
[02:01] <SergioMeneses> phillw, good night
[02:01] <cprofitt> night phillw
[16:01]  * slangasek waves
[16:02] <slangasek> #startmeeting
[16:02] <meetingology> Meeting started Wed Feb  6 16:02:03 2013 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:02] <jodh> o/
[16:02] <slangasek> [TOPIC] Lightning round
[16:02] <slangasek> $ echo $(shuf -e barry doko stgraber jodh ev bdmurray slangasek ogra cjwatson xnox stokachu)
[16:02] <slangasek> barry bdmurray ogra slangasek doko cjwatson stokachu ev xnox jodh stgraber
[16:02] <barry> win!
[16:02] <barry> various ue sprint tasks.  file debian bugs 699491 and 699498 (adding -OO to py{,3}compile).  more possibly to come there.  reviewed stokachu's pytz merge and eventually syncpackaged it (bug 1116418).  submitted branch for bug 1112496, with updates to come.  worked on py3 whoosh and reached out to debian maintainer.  various upstream pypi security discussions.
[16:02] <barry> * foundations-r-python33: done.
[16:03] <barry> * foundations-r-python3-oauth: bug 1077094 marked invalid as the package is going away.  bug 1077087 bug 1077089 and bug 1077092 branches in various states of review.
[16:03] <barry> * foundations-r-python-versions: new python-imaging (pillow) package provides py3 support, but see above bugs for backward compatibility fixes needed.   in conversations about software-center and session-installer re: wtf to do about python-xapian.  we may not be able to replace it  :(
[16:03] <barry> done.
[16:03] <bdmurray> failed to recreate nexus7 bug 1092734
[16:03] <bdmurray> worked on an upstart job to watch for an hp printer to replace update-notifier job
[16:03] <bdmurray> removed unused firmware paths from uevent.c in update-notifier
[16:03] <bdmurray> investigation into bug 1112496 (since comix doesn't work :-()
[16:03] <bdmurray> investigation into and testing of bug 1096022
[16:03] <bdmurray> removed running-unity tag from the ubuntu general apport hook and upstream apport
[16:03] <bdmurray> verified P SRU for bug 984276
[16:03] <bdmurray> bug triage of update-manager bugs with ubuntu-release-upgrade-core symptom
[16:04] <bdmurray> improved the speed at which the user parameter works at errors
[16:04] <bdmurray> resovled an issue on errors where + in package names and versions wasn't being encoded for using in a url
[16:04] <bdmurray> worked on bucketsystems column family code
[16:04] <bdmurray> created a new canonistack environment for errors since my previous one had died
[16:04] <bdmurray> tested and modified bucketsystems column family code in canonistack
[16:04] <bdmurray> blueprint wise I am working on foundations-r-phased-updates
[16:04] <bdmurray> ✔ done
[16:04] <ogra_> done:
[16:04] <ogra_>  * various nx7 bugfixes
[16:04] <ogra_>  * worked with kernel team and diwic to make sound work on boot on the nx7
[16:04] <ogra_>  * worked with kernel team to quieten the massive dmesg noise the interactive governor causes
[16:04] <ogra_>  * held UDW talk about image build infrastructure (will start a wikipage with the notes as base for proper build system documentation)#
[16:04] <ogra_>  * hunting down livefs breakage (again)
[16:05] <ogra_> todo:
[16:05] <ogra_>  * port nx7 images to xz compression
[16:05] <ogra_>  * discuss livefs builder situation with infinity (carried over from last week, blocked on builder)
[16:05] <ogra_>  * fix plymouth vs console-setup racing somehow
[16:05] <ogra_> done
[16:05] <slangasek> barry: not able to replace python-xapian - hmm, have new requirements emerged, or are the alternatives proving to be inadequate?
[16:06] <slangasek> bdmurray: planning to upload that new update-notifier upstart job soon?
[16:06] <barry> slangasek: probably a conversation to have a bit later ;)
[16:07] <slangasek> xnox: speaking of which, is usb-creator getting an upload with the fixed job that's in bzr?
[16:07] <infinity> ogra_: It's been pointed out that, if you plan to use xz, depending on pxz and using that might make things slightly less painful.
[16:07] <xnox> slangasek: yes. today.
[16:07] <slangasek> xnox: yay :)
[16:07] <ogra_> infinity, like ... being able to use it on the panda itself ?
[16:08] <bdmurray> slangasek: well, I thought it should really go in hplip and haven't heard from til, additionally waiting for the user session work seems fine.
[16:08] <infinity> ogra_: Yeah.  It'll still be slower than gzip, but potentially acceptably so.
[16:08] <ogra_> infinity, what holds me back from the switch is that i have to re-work so much stuff for it on both sides if i want nusakan to do xz
[16:08] <slangasek> bdmurray: ah, ok
[16:08] <ogra_> infinity, great, i'll try it then
[16:08] <infinity> ogra_: Easy enough to take your rootfs tarball and do some local testing on a Panda.
[16:08] <ogra_> yep
[16:08] <infinity> ogra_: See if you can find a sweet spot.
[16:09] <ogra_> after i fixed the installer from being completely unusable
[16:09] <slangasek> ogra_: hunting down livefs breakage> are things currently broken, or currently working?
[16:09]  * ogra_ notes cjwatson isnt iun -desktop
[16:09] <ogra_> slangasek, not working since we dropped a tar option
[16:09] <ogra_> i just heard about it now
[16:09] <slangasek> ogra_: hmm. eta for fix?
[16:10] <ogra_> well, worst case i can roll that back immediately and we lose some memory gains cjwatson introduced
[16:10] <infinity> ogra_: Err, wait.  What?  The dropping of the tar option from the installer?
[16:10] <xnox> ac100-tarball-installer that is
[16:10] <infinity> ogra_: How did that "break" the livefs?
[16:10] <ogra_> infinity, droppiing of -m seems to make tar crazy
[16:11] <slangasek>  * systemd packaging: slow progress
[16:11] <slangasek>  * ovmf packaging nearly done; edk2 is clearly not structured with distributions in mind
[16:11] <slangasek>  * reviewing UbuntuKylin package submissions; will mail the TB to ask this to be an official flavor as soon as the core set is accepted
[16:11] <ogra_> i havent digged deeper yet (or seen it myself)... i know about it since the meeting started :P
[16:11] <slangasek> (done)
[16:11] <infinity> ogra_: Is there a bug or any sort of analysis?
[16:11] <xnox> well it worked without -m, but not "without -m and adding --warning=no-timestamp" or so the report says.
[16:11] <ogra_> infinity, only chat in #ubuntu-desktop yet
[16:13] <slangasek> doko: your turn
[16:13] <doko> - fix ftbfs for older gcc releases (changed kernel headers, missing struct siginfo)
[16:13] <doko> - llvm/clang updates
[16:13] <doko> - upload pillow for python3
[16:13] <doko> - openjdk security update
[16:13] <doko> - FOSDEM
[16:13] <doko> (done)
[16:13] <doko> will follow-up on FOSDEM later
[16:14] <ogra_> slangasek, oh, the "hunting down livefs breakage" from my report was supposed to be "hunting down livefs builder breakage" its unrelated to the current issue
[16:14] <ogra_> (was just a coincident that you asked while i was told its broken :) )
[16:15] <slangasek> ah, cjwatson is off this afternoon, so stokachu:
[16:15] <stokachu> ok
[16:15] <slangasek> ogra_: hmm!
[16:15] <stokachu> Followed up bug 1052038, awaits verification
[16:16] <stokachu> Need a little more information on bug 923876 if we are planning on applying this to precise and quantal? Or whats the overall consensus on removing old kernels on a system during upgrades?
[16:16] <stokachu> Did my first sync package request though im not sure how to tell if I got credit for the request or not other than looking at the bug itself.
[16:16] <stokachu> (done)
[16:16] <ogra_> slangasek, the builder was off for two days again this week ... thanks to elmo and infinity its back in business though
[16:17] <xnox> stokachu: https://launchpad.net/~adam-stokes/+synchronised-packages
[16:17] <ogra_> (it seems to always die on saturdays ... probably going out to party on weekends or so )
[16:17] <stokachu> xnox: ah ok sweet
[16:17] <infinity> ogra_: It's probably just cause it can't count: http://sourceware.org/ml/glibc-cvs/2013-q1/msg00115.html
[16:17] <ogra_> oha
[16:17] <ogra_> "Fix the value of TWO"
[16:18] <stokachu> xnox: there we go :D
[16:18] <ogra_> it couls just count one by one then :P
[16:18] <ogra_> *could
[16:18] <stokachu> re: apt removing older kernels is starting to make its way through internally so any thoughts on that would be appreciated
[16:19] <infinity> stokachu: Oh, crap.  So, yeah.  I was meant to backport the apt stuff last week, and got distracted by other work.
[16:20] <infinity> stokachu: I can still do that today, and maybe Colin will accept it.
[16:20] <ev> - Feedback to Martin's code review of the grouped reports branch of apport.
[16:20] <ev>   This, if you don't recall, is for showing system internal errors as part of
[16:20] <ev>   the next regular application error.
[16:20] <ev> - Code review for Brian.
[16:20] <ev> - Wrote a tool to bootstrap the postgres database for local copies of Errors.
[16:20] <ev> - Taught the prodstack-prep branches to talk to Swift natively when running on
[16:20] <ev>   canonistack/prodstack.
[16:20] <ev> - Added the bulk of the Canonical engineering teams to the ACL for stacktrace
[16:20] <ev>   access on errors.ubuntu.com. Added code to Errors and the prodstack charms to
[16:20] <ev>   manage further additions to the ACL with minimal code changes.
[16:20] <ev> - Big improvements to the average errors per calendar day graph over the
[16:20] <ev>   weekend. The text for the milestones and dates finally all fits. We now also
[16:20] <ev>   set the domain to (0, 0.4) so the difference between 12.04 and 12.10 should
[16:20] <ev>   be much more discernable. There's a few more improvements to be made that
[16:20] <ev>   I'll fit in while other work compiles or in the evening. I've also cleaned up
[16:20] <ev>   the call stack representation in the most common problems table.
[16:20] <ev> - More fixes to whoopsie. Trying to get a new build out, but the tests are
[16:20] <ev>   failing only in sbuild due to leaks detected by valgrind. Fixed one already,
[16:20] <ev>   so this new memcheck test addition is already proving useful.
[16:20] <ev>   - If we can move the connectivity check and inotify watch into upstart, we
[16:20] <ev>     save about 0.8 MB of memory in whoopsie (though admittedly whoopsie no
[16:20] <ev>     longer runs all the time and its memory usage becomes less important).
[16:20] <ev>   - Not pulling in CURL takes us down to running in 200K, but we kind of need
[16:20] <ev>     that :). I suspect its the SSL stuff taking up the lion's share.
[16:20] <ev> - More fixes to the prodstack charms. JuanJo is making good headway on getting
[16:20] <ev>   these deployed to stagingstack.
[16:20] <ev>   - Trying to build the universe to get a recent version of python-swiftclient
[16:20] <ev>     working in precise.
[16:20] <ev> (done)
[16:20] <stokachu> infinity: ok no worries i was just pinged internally about this yesterday so its not really heating up yet and your confirmation of it is good enough
[16:21] <stokachu> thanks
[16:21] <xnox> * Short week due to Fosdem Fri-Mon
[16:21] <xnox>   - loads of people met and conversations held
[16:21] <xnox>   - everyone is talking about aarch64
[16:21] <xnox>   - everyone is waiting for aarch64 hw
[16:21] <xnox>   - interesting talks on init systems & [e]udev
[16:21] <xnox>   - keysigning...
[16:21] <xnox> .
[16:21] <xnox> * Last week, poked pyo optimisation with barry a little.
[16:21] <xnox>   I want to run one last test (i think i didn't have everything
[16:21] <xnox>   without docstrings), but it looks likes on currently idle python
[16:21] <xnox>   processes there isn't much ram savings.
[16:21] <xnox> * Also gave a talk on making/fixing packages to cross-build. Need to
[16:21] <xnox>   convert to blog post / packaging guide section.
[16:21] <xnox> .
[16:21] <xnox> * Precise:
[16:21] <stokachu> infinity: will this be for quantal and precise?
[16:21] <xnox>   Uploaded SRU for 2 clustered LVM issues. Not critical for 12.04.2 as
[16:21] <xnox>   clvm is not on the server cds. bug #833368 and bug #988881 .
[16:21] <xnox> .
[16:21] <xnox> * foundations-r-arm-usb-creator-fastboot-support:
[16:21] <xnox>   udisks2 backend created a few sticks now. Porting/Testing last
[16:21] <xnox>   pieces in the -helper and then we can drop udisks from CD.
[16:21] <xnox> .
[16:22] <xnox> * foundations-r-software-raid
[16:22] <xnox>   mdadm initial merge ready, should upload by the end of the week.
[16:22] <xnox> (done)
[16:22] <infinity> stokachu: That's the general plan.
[16:22] <jodh> * blueprints
[16:22] <stokachu> ok sounds good
[16:22] <jodh>   - foundations-r-upstart-user-session-enhancements:
[16:22] <jodh>     - Merged lp:~jamesodhunt/upstart/setenv+getenv.
[16:22] <jodh>     - Finished and raised MP for lp:~jamesodhunt/upstart/event-prefixes.
[16:22] <jodh>     - Wrote and raised MP on
[16:22] <stokachu> ill relay that information
[16:22] <jodh>       lp:~jamesodhunt/upstart/remove-initctl-job+instance-options
[16:22] <jodh>     - Working on upstart shutdown.
[16:22] <jodh>   - foundations-r-upstart-roadmap: no progress
[16:22] <jodh>   - foundations-r-arm-ubiquity: no progress
[16:22] <jodh> * other:
[16:22] <jodh>   - FOSDEM 2013 (away Fri-Mon)
[16:22] <jodh>   - MP for restarting Upstart on libjson0 upgrade
[16:22] <jodh>     https://code.launchpad.net/~jamesodhunt/ubuntu/raring/json-c/restart-upstart/+merge/146868
[16:22] <jodh> Ꭸ
[16:22] <jodh>
[16:23] <slangasek> bah, ok, this is the second time since upgrading this machine to raring that the desktop has completely locked up for minutes at a time... not even the cursor moves
[16:23] <slangasek> anybody else seeing this?
[16:23] <stgraber> Feature work:
[16:23] <stgraber>  - Upstart (BLUEPRINT: foundations-r-upstart-user-session-enhancements)
[16:23] <stgraber>   - No progress done last week, planning on testing it this week.
[16:23] <stgraber>  - Container (BLUEPRINT: servercloud-r-lxc)
[16:23] <stgraber>   - libseccomp was promoted to main
[16:23] <stgraber>   - Worked on a fix for bug 1113821
[16:23] <stgraber>   - Code reviews.
[16:23] <stgraber>   - Preparing 0.9~alpha3 to be released next week.
[16:23] <stgraber>   - Discussed plan for container/security/lxc micro-conference at LPC2013
[16:23] <barry> slangasek: nope.  what h/w do you have?
[16:23] <stgraber>  - Networking (BLUEPRINT: foundations-r-networking)
[16:23] <stgraber>   - Still waiting on test results for the infiniband support, no other progress there.
[16:23] <stgraber> Other work:
[16:23] <stgraber>  - Networking
[16:23] <stgraber>   - Spent quite a bit of time getting Ofono to work with NetworkManager, slowly getting there.
[16:23] <stgraber>     (glib + gobject + dbus in NM can be the source of rather bad headaches...)
[16:23] <stgraber>  - QATracker
[16:23] <slangasek> stokachu: on the apt kernel autoremoval, I thought we already did backport that to precise+quantal, no?
[16:23] <stgraber>   - Helped setup some other internal instances of the tracker.
[16:23] <stgraber>  - Meetings/Talks
[16:24] <stgraber>   - Had an Ubuntu Development Hangout yesterday
[16:24] <stgraber>   - Will have an LXC IRC meeting tomorrow to present the user namespace work and discuss some of the next steps.
[16:24] <stgraber> TODO:
[16:24] <stgraber>  - Continue the ofono/NM work.
[16:24] <stgraber>  - Try to finish any LXC feature work for this cycle (1 item left).
[16:24] <stgraber>  - Prepare some upstart user session debs with all our patches and the initial Xsession scripts and upstart jobs.
[16:24] <stgraber> (DONE)
[16:25] <stokachu> slangasek: ill double check but tmk it wasn't
[16:25] <stgraber> if it was, it's not working ;)
[16:25]  * stgraber had to manually wipe a few kernels on a dozen machine over the weekend to clear some space in /boot
[16:26]  * barry too
[16:26] <bdmurray> heh, me too!
[16:26] <bdmurray> just one machine though
[16:28]  * xnox currently has 9 kernels on my machine in raring.... i thought i should have less.
[16:28] <slangasek> barry: hw> standard intel mobile graphics, I forget the model
[16:29]  * ogra_ has 12 on precise
[16:29] <slangasek> heh, ok - and infinity 'fessed up that it's still on his todo, so
[16:30]  * slangasek gets to the bottom of scrollback finally
[16:30] <stgraber> slangasek: if that's your x201, then it's first gen i7 graphics (Arrandale chipset with Ironlake graphics, product id 0046)
[16:30] <slangasek> yeah, that ;)
[16:30] <infinity> xnox: Before you go manually doing anything to those kernels, talk to me out of band.
[16:30] <slangasek> so there seem to be two entangled problems here
[16:31] <xnox> infinity: ack. My install is not typical by any means, so it could be of my wrong doing.
[16:31] <barry> slangasek: i've got a radeon
[16:31] <slangasek> one is that firefox is helpfully using 100% of a CPU; the other is that X is using 100% of a CPU and not responding interactively
[16:31] <slangasek> I guess I should file a critical bug, when I can get back to the desktop
[16:31] <xnox> stgraber: do you want to help out specing a machine for me?! =)
[16:32] <ogra_> you should definitely get more cores then ... one per app or so
[16:32] <slangasek> [TOPIC] work item
[16:32] <slangasek> [TOPIC] work items
[16:32] <slangasek> ogra_: X already has a core to itself, it's not doing anything *useful* with it :P
[16:32] <ogra_> heh
[16:33] <stgraber> xnox: hehe, I just happen to have used a pretty much identical laptop to slangasek's for the past two years and had some X problems in the past ;)
[16:33] <slangasek> so I was going to pull up some numbers to see how we're all doing individually wrt the burndown trend line
[16:33] <slangasek> but with my laptop being coy, those numbers are currently not at my fingertips
[16:33] <stgraber> xnox: now I'm on a x230 with a different set of problem (mostly caused by me only using displayport displays which apparently nobody does...)
[16:34] <slangasek> instead, I'll just say that you should all be checking your personal status.ubuntu.com page and making sure that you are below the trendline, as of *today*
[16:34] <slangasek> if you aren't, that doesn't mean you need to work overtime, it means you need to talk to me to figure out what we need to postpone or move around on the team
[16:34] <slangasek> the team's burndown is above the line, and realistically, we're going to be seeing demands on our time for work not shown on that chart (i.e., work to support the mobile effort)
[16:35] <slangasek> so we need to get our priorities squared away wrt the stuff from UDS, so that people know what we are actually delivering this cycl
[16:35] <slangasek> e
[16:35] <slangasek> any questions?
[16:35] <stgraber> slangasek: not sure if that also impacts the team's trendline, but I have 10 Edubuntu work items in my personal chart which if ignored makes me below the trendline
[16:35] <barry> slangasek: do in progress count? :)
[16:36] <slangasek> also, note that even with everyone on the team down below the trendline, we'll be above the trendline for the team as a whole because of workitems on our blueprints that are assigned to people not on the team
[16:36] <doko> tex-common at version 3.15? that looks wrong ...
[16:36] <ev> should we add workitems for things that have come up? For example, I wasn't expecting to do all this prodstack stuff.
[16:37] <slangasek> so if you're the assignee for a blueprint that has external workitems, please be sure to check with those folks on how they're doing and if they'll still deliver this cycle
[16:37] <slangasek> ev: no, burndown charts shouldn't be an exercise in paperwork to make us look productive :)
[16:37] <slangasek> barry: no ;)
[16:37] <infinity> doko: Wrong, how?
[16:37]  * xnox ponders what to do with Low and Undefined priority specs which was mostly community/nice-to-haves
[16:37] <slangasek> stgraber: it does impact the team's trendline, but I'll mentally subtract
[16:38] <doko> doesn't approach Pi anymore
[16:38] <infinity> Hahaha.
[16:38] <slangasek> stgraber: so don't worry about faking up the state just to make the trendline happy
[16:38] <xnox> infinity: it's not hahaha, but a real problem. it should never been 3.15.
[16:38] <stgraber> slangasek: good ;)
[16:38] <infinity> doko: There's a 4.xx in experimental, if you really want to be sad about the versions inflating.
[16:38] <xnox>  /o\ did TeX community go crazy?!
[16:39] <slangasek> xnox: realistically, they should probably be postponed; if you run out of todo work items early, you can always rescue them from the postponed pile
[16:39] <slangasek> any other qs?
[16:40] <slangasek> [TOPIC] Bugs
[16:40] <slangasek> bdmurray: what news?
[16:40] <bdmurray> I believe this is our top error at the moment
[16:40] <bdmurray> https://errors.ubuntu.com/bucket/?id=/usr/bin/apturl-gtk:AttributeError:parseArgs:parse:%3Cmodule%3E:main:parseArgs
[16:41] <stgraber> oh nice, .decode() on a python3 string, that won't quite work ;)
[16:42] <xnox> bdmurray: so we should check latest apt-urls posted on OMGubuntu to find the culprit =)
[16:42] <barry> ouch ;)
[16:42] <xnox> ev: we don't have server side hooks yet to query what sting is failing?!
[16:43] <bdmurray>
[16:43] <bdmurray> /usr/bin/python3 /usr/bin/apturl-gtk /home/whoever/Downloads/MediaPlayerClassic_RocketFuelInstaller (1).exe
[16:43] <ev> xnox: I am but one man, busy getting everything ready for the cloud.
[16:43] <bdmurray> I guess we could look at the proccmdlines?
[16:44] <barry> is the str.decode() bug filed?
[16:44] <xnox> ev: True. prodstack is a lot of "prod" in it.
[16:44] <bdmurray> barry: no
[16:44] <ev> :)
[16:44] <bdmurray> oh, maybe its because apturl is being used with local files?
[16:45] <slangasek> oh this is special
[16:45] <slangasek> killall -9 firefox, and it keeps going
[16:45] <ogra_> lovely
[16:45] <barry> slangasek: i saw a lot of ineffective kill -9s on the nexus
[16:45] <ogra_> sudo harder :)
[16:45] <xnox> bdmurray: not quite. it looks like some browser extension went crazy cause all files are (a) local (b) in download or .cache locations
[16:45] <slangasek> barry: !
[16:45] <ogra_> barry, bug # ?
[16:45] <ogra_> :)
[16:46] <slangasek> sounds like we need to file a critical bug against the kernel for that, too
[16:46] <ogra_> nx7 is a different kernel though
[16:46] <xnox> bdmurray: but apt-url should handle that fine, but it won't help if browser has now defaulted to open everything with apt-url instead of other mime-handlers.
[16:46] <barry> yeah, you know which kernel i'm talkin' 'bout.   i wasn't shaving the yak that day though
[16:46] <ogra_> (which doesnt say much, might be present since before the nx7 kernel, who knows)
[16:46] <stgraber> well, kill -9 can be ineffective if the process is stuck in I/O wait (D state)
[16:47] <stgraber> now the source of the I/O wait is usually the bug (and in some cases it's a kernel bug)
[16:47] <bdmurray> xnox: you seem to be knowledgeable about this and in a good position to look at...
[16:47] <slangasek> stgraber: it's not in I/O wait, it's actively consuming my CPU
[16:48] <xnox> bdmurray: ok. I'll chat with -desktop folks and try to investigate it.
[16:48] <stgraber> slangasek: hmm, ok, that's really special then ;)
[16:48] <slangasek> xnox: assign the bug to yourself?
[16:48] <slangasek> (er, if there is a bug yet)
[16:49] <slangasek> bdmurray: any other bugs/crashes you're worried about?
[16:49] <bdmurray> ev: oh maybe there should a create bug link on the bucket page
[16:49] <ev> bdmurray: yes, definitely
[16:49] <bdmurray> ev: because you'd have to go to ?package=apturl and then find the right bucket
[16:50] <bdmurray> slangasek: the rls r tracking bugs are looking a bit long
[16:50] <bdmurray> there are 3 critical ones
[16:50] <bdmurray> bug 1066480
[16:50] <bdmurray> bug 1013798
[16:50] <slangasek> bdmurray: sorry, can you pass the link to the report too?
[16:50] <bdmurray> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html
[16:51] <bdmurray> and bug 1084063
[16:53] <ogra_> yeah, thats a bad one, i think colin took a look but we didnt talk about it yet
[16:53] <slangasek> 1084063 is already on ogra's todo list, AIUI
[16:53] <ogra_> yeah
[16:53] <slangasek> stokachu: any luck with bug #1013798?
[16:53] <slangasek> xnox: can you take bug #1066480?
[16:53] <xnox> bug 1066480 is on me. but can be worked on post ff.
[16:54] <xnox> The solution is to correctly try and call existing partman-crypto api call that colin pointed out to me previously.
[16:54]  * slangasek assigns
[16:55] <bdmurray> I looked at some of the ubiquity ones yesterday and also noticed that bug 1080701 is still getting regular metoos
[16:55] <slangasek> already assigned to xnox - are you missing any information to be able to work on that one?
[16:56] <xnox> bdmurray: there are two hang fixes in os-prober I uploaded. Which needs to be uploaded as part of ubiquity.
[16:56] <xnox> it is random for me and I cannot reliable reproduce it with debugging on to see what hangs.
[16:57] <slangasek> [TOPIC] AOB
[16:57] <slangasek> anything else to discuss?
[16:58] <slangasek> #endmeeting
[16:58] <meetingology> Meeting ended Wed Feb  6 16:58:46 2013 UTC.
[16:58] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-06-16.02.moin.txt
[16:58] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-02-06-16.02.html
[16:58] <slangasek> thanks everyone!
[16:58] <ogra_> thanks !
[16:58] <barry> thanks!
[16:58] <jodh> thanks
[16:59]  * slangasek goes back to kicking this krazy kernel
[17:00]  * barry reboots his world
[17:00]  * ogra_ goes to give the cat her daily shot (worst part of my day)


[00:42] <Laney> nacc: it should retry until it gets an allocation
[00:42] <nacc> Laney: ok, that's what I figured
[00:42] <Laney> some tests require m1.large instances, and it's possible for others to sneak in underneath them
[00:43] <nacc> Laney: sure
[00:43] <Laney> AFAIK the linux failures are real ones
[00:43] <nacc> Laney: yeah, I don't think they are strictly related to the packages in question, but it does seem to be a real failure
[00:45] <Laney> Mmm - I think that it was allowed in at some point and now it continues to fail when triggered by other things
[00:45] <Laney> Or something like that
[00:46] <nacc> Laney: sounds about right
[01:26] <xnox> nacc i am confused about it too
[01:29] <Unit193> xnox: I don't suppose you'd care to comment on LP 643623?
[01:47] <jbicha> pitti: it looks like you can drop the badtest hint for gjs/armhf, no idea what's not working with s390x
[01:48] <jbicha> (gjs 1.47.90 was broken until -0ubuntu3)
[04:00] <doko> rbasak, caribou: that most likely comes from -O3. either adjust the symbols files, or force to build with -O2 on ppc64el
[09:34] <Unit193> in src:gocryptfs, disable the first patch and you fix the ftbfs.


[01:39] <sarnold> hello; does launchpad do anything to influence how pageup and pagedown function? when viewing a long bug report, pageup always jumps to the very top of the bug report and then appears to try to go higher; pagedown will jump to the very top of the bug report and then go downwards. I've got launchpad.net set to trusted in noscript, privacy badger doesn't appear to be blocking anything, and I've got
[01:39] <sarnold> tridactyl installed but it seems pretty well behaved..
[01:39] <sarnold> eg a bug report where pageup and pagedown down work as I expect: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980
[01:39] <sarnold> and a very long page elsewhere that works as I expect: http://sled.rs/perf.html
[01:40] <sarnold> firefox 81.0+build2-0ubuntu<IP_ADDRESS>
[01:44] <sarnold> (yes, I could use ^U or ^Y or ^B thanks to tridactyl, but on web pages I'm more accustomed to pageup and pagedown)
[09:56] <cjwatson> sarnold: I've noticed that and it drives me nuts because I cannot work out what's causing it
[09:56] <cjwatson> sarnold: in the past when I've tried to debug it it's gone away
[17:54] <sarnold> cjwatson: argh :) I hate bugs that go away when you try to look at them; it happens often enough for me that I'd even suspect it happens all the time. I'm happy to help debug remotely, such as I can, but it'd really require a lot of hand-holding, I'm very unfamiliar with anything beyond about html 1.1
[21:01] <cjwatson> sarnold: Yeah, I think the main problem was that it went away when I tried to reproduce _with devtools switched on_
[21:01] <cjwatson> But it was a while ago
[21:02] <sarnold> cjwatson: hmm, if that fixes it.. :)
[21:07] <cjwatson> Maybe something to do with https://git.launchpad.net/launchpad/tree/lib/lp/app/templates/base-layout-macros.pt#n150
[21:09] <cjwatson> Or not, doesn't seem to be called
[21:10] <cjwatson> It does feel like a focus bug though
[21:10] <sarnold> focus feels right, half the time I need to click into the page to use pgdown in the first place
[21:10] <cjwatson> Right, exactly
[21:10] <cjwatson> Happens on merge proposals too
[21:11] <cjwatson> At some point I may get cross enough with it to have another go
[21:11] <sarnold> :)
[21:12] <cjwatson> But it may be possible to work it out by seeing if you can get it to reproduce with devtools and setting breakpoints on all the something.focus() calls
[21:13] <sarnold> just skimming this function .. what happens if there's no elements with the name (and thus no focus() calls)? what happens if there's two or more? Should there be a 'break;' after that node.focus()?
[21:14] <sarnold> oh, well, there kind of is. hmm.
[21:14] <cjwatson> Yeah I'm not going to debug it at 10pm esp when I don't think it's called here
[21:14] <sarnold> :D
[21:14] <sarnold> thanks cjwatson, have a good night
[21:15] <cjwatson> :)
[21:55] <tomreyn> have you considered to raise the anti bot measures bar a little? it feels like you must be reverting spam bot edits 50% of your every day at work.
[21:57] <cjwatson> tomreyn: Hardly, I spend a few minutes a day on it
[21:58] <cjwatson> tomreyn: You only see what slips through
[21:58] <tomreyn> to the latter, that's what i was thinking, yes
[21:59] <sarnold> it's bursty, most days I never see anything, and then once in a while I'll see two or three in one day
[21:59] <tomreyn> i'd still get annoyed having to spend some minutes on it every day, but i'm glad you're more relaxed. ;-)
[21:59] <sarnold> compared against email, it's pretty staggeringly good :)
[22:00] <tomreyn> ok, i rest my case then ;)
[22:00] <cjwatson> It's not ideal, but there are always tradeoffs
[22:00] <cjwatson> (I don't think comparing against email is much of a bar though)
[22:01] <tomreyn> let's quickly fix e-mail once and for all, then we can get to launchpad.
[22:01] <sarnold> well, the other comparison that comes to mind is irc, which is also super bursty... some months, nothing, and then one day last week I spent half an hour cleaning up after hundreds of bots...
[22:01] <cjwatson> I find it more interesting to improve API facilities to make it easier to deal with various categories of spam, which is a thing we do from time to time
[22:01] <cjwatson> Usually when one of us gets annoyed at workarounds for lack of same :)
[22:02] <sarnold> hehe