[00:04] <duanedesign> #startmeeting
[00:04] <meetingology> Meeting started Wed Sep 14 00:04:13 2011 UTC.  The chair is duanedesign. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[00:04] <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
[00:07] <pleia2> o/
[00:07] <duanedesign> Me and SilverFox have been reviewing chaarles wiki page outlining Beginners Team changes
[00:08] <duanedesign> [LINK] https://wiki.ubuntu.com/cprofitt/sandbox
[00:09] <pleia2> it seems we're a bit stalled on this, some direction from the council would be helpful
[00:10] <duanedesign> #link https://wiki.ubuntu.com/cprofitt/sandbox
[00:10] <duanedesign> I agreee
[00:10] <duanedesign> I am working on an email
[00:11] <duanedesign> what do you think of the ides about the Focus Group changes?
[00:11] <duanedesign> User: This group is for new users making the transition to Ubuntu
[00:11] <duanedesign> Contributor: This group is for non-developers looking to contribute and includes areas such as documentation, bug triage and quality assurance.
[00:12] <duanedesign> Developer: This group is for people hoping to become core Ubuntu or application developers.
[00:12] <pleia2> I think as little structure as possible is best, BT is essentially a mentoring organization and too much structure can be just as bad as too little
[00:13] <duanedesign> i like the idea of making thr core team open
[00:14] <duanedesign> if you want to join the docs team you should not have to join BT first
[00:15] <pleia2> yeah
[00:15] <duanedesign> their is no easy solution on meetings and the different time zones
[00:16] <duanedesign> One thing that is not on Charles sandbox is tncorporating the mailing list more
[00:16] <duanedesign> incorporating*
[00:16] <pleia2> the best you can do is post the logs/minutes after the meeting and encourage feedback on the list
[00:16] <duanedesign> Similar to what the Bug Squad is doing
[00:17] <duanedesign> assigning a mentor to every mentee is a difficult task
[00:18] <duanedesign> encouraging the use of a mailing list can help
[00:20] <duanedesign> #ACTION send an email to the mailing list outlining the suggested changes and timeline for those changes
[00:20] <meetingology> ACTION: send an email to the mailing list outlining the suggested changes and timeline for those changes
[00:21] <duanedesign> ok i need to fix my borked oneiric install. If nobody has anything else....
[00:22] <pleia2> thanks duanedesign
[00:22] <duanedesign> thank you pleia2
[00:22]  * starcraftman is little late but here for a change. :)
[00:22] <duanedesign> hello starcraftman
[00:22] <pleia2> oh! one thing real quick
[00:22] <starcraftman> evening duanedesign :)
[00:22] <pleia2> we're still looking for some https://wiki.ubuntu.com/UserDays instructors
[00:23] <pleia2> it's next Saturday, the 24th, need some instructors for some basic applications classes
[00:23] <starcraftman> pleia2: still short huh? Sad, want me to do a second session?
[00:23] <pleia2> starcraftman: maybe, I'll still try to fill them before askign you :)
[00:23] <duanedesign> pleia2: that is right. I had someone ask me and I agrreed to do an Ubuntu One class.
[00:24] <starcraftman> hi Unit193
[00:24] <Unit193> starcraftman: Hello sir
[00:24] <pleia2> duanedesign: oh good, can you have a look at the schedule on the wiki when you have a chance and let me know what time?
[00:24] <starcraftman> pleia2: Ok, I don't mind too much.
[00:24] <duanedesign> pleia2: I will
[00:24] <pleia2> much appreciated
[00:24] <starcraftman> Unit193: pshhhhhhhhhhhhh, don't call me sir, gonna make me feel old >.>.
[00:25] <Unit193> starcraftman: That was the idea ;)  Just noticed meeting here
[00:25] <duanedesign> #LINK https://wiki.ubuntu.com/cprofitt/sandbox
[00:25] <starcraftman> Unit193: thou art evil, sir. I like :)
[00:27] <duanedesign> starcraftman: not sure when you came in but we just need to start moving foward on charles ideas
[00:29] <starcraftman> duanedesign: reading up now, you can carry on as I speed read. Don't want to hold up meeting.
[00:29] <duanedesign> the council has discused the ideas and is putting together an email so we can moce forward
[00:29] <duanedesign> starcraftman: no worries that was really all i had
[00:29] <starcraftman> quite the series of changes, seems good so far. Always thought too much formality was slowing us down a bit.
[00:30] <duanedesign> true, pleia thought the same
[00:30] <highvoltage> win 22
[00:30] <JoseeAntonioR> Hi!
[00:31] <philipballew> hello
[00:31] <duanedesign> hello
[00:31] <JoseeAntonioR> I am willing to assist with the UserDay if I can
[00:31] <philipballew> arnt we all?
[00:32] <duanedesign> JoseeAntonioR: great. I think pleia2 or nigelb  are who you want to talk to
[00:32] <JoseeAntonioR> pleia2 mentioned some basic applications classess.. what do you refer with basic applications?
[00:33] <starcraftman> duanedesign: question related to plan, are we mostly on track with written timeline?
[00:33] <duanedesign> https://wiki.ubuntu.com/UserDays
[00:33] <JoseeAntonioR> Then, pleia2, nigelb, are you here?
[00:33] <pleia2> JoseeAntonioR: you'd give an intro do an application and answer questions about it, like if you wanted to do thunderbird you'd explain what it is, how to set up your email, maybe how filters work
[00:33] <duanedesign> starcraftman: no the timeline needs to move forward
[00:33] <pleia2> JoseeAntonioR: you can join us in #ubuntu-classroom-backstage to discuss if you want :)
[00:34] <JoseeAntonioR> Going there!
[00:34] <starcraftman> duanedesign: ok, I'll hopefully be around more going forward, I'm planning/scheduling stuff. It's unthinkable.
[00:34] <duanedesign> starcraftman: so we can change June to Sept
[00:34] <duanedesign> starcraftman: great!
[00:34] <starcraftman> duanedesign: ah, I see. :)
[00:34] <philipballew> is there anything I can help with here?
[00:36] <duanedesign> Ok I will work on getting the email to the Beginners Team Mailing List and if their is no other Begnners Team matters I will end the meeting'
[00:36] <philipballew> sounds good
[00:36] <starcraftman> duanedesign: ok.
[00:36] <duanedesign> philipballew: what did you want to help with? Beginners Team or User Day?
[00:36] <philipballew> duanedesign, both!
[00:37] <duanedesign> :) great
[00:37] <philipballew> thats why i am here at the meeting duanedesign
[00:37] <philipballew> :)
[00:37] <duanedesign> The Beginners Team channel is #ubuntu-beginners-team
[00:38] <philipballew> i am aware. I provide tech support on there. Lately its been at night
[00:38] <duanedesign> our wiki page https://wiki.ubuntu.com/BeginnersTeam
[00:38] <philipballew> lets trade duanedesign  :) https://wiki.ubuntu.com/philipballew
[00:39] <duanedesign> philipballew: we are working on some changes to make jjoining the Beginners Team easier
[00:40] <philipballew> I know. I have wanted to become a "member" for a little while and figured id joun the meeting here to see if it was gonna change about how i did so
[00:42] <duanedesign> philipballew: if you want you can join our mailinglist to keep up on the upcoming changes https://lists.ubuntu.com/mailman/listinfo/ubuntu-beginners
[00:42] <duanedesign> ok i need to run. #endmeeting
[00:43] <Unit193> Newline
[00:43] <duanedesign> #endmeeting
[00:43] <meetingology> Meeting ended Wed Sep 14 00:43:18 2011 UTC.
[00:43] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-14-00.04.moin.txt
[00:43] <duanedesign> Unit193: thank you :)
[00:43] <philipballew> awesome!
[00:43] <Unit193> duanedesign: Anytime :)
[00:44] <duanedesign> philipballew: thank you for attending
[00:45] <philipballew> no worries :)
[15:01]  * slangasek waves
[15:01] <ev> hiya
[15:01] <mvo> hello
[15:01]  * stgraber waves
[15:02] <bdmurray> hi
[15:02] <barry> hiya
[15:02] <jhunt> o/
[15:02] <slangasek> #startmeeting
[15:02] <meetingology> Meeting started Wed Sep 14 15:02:26 2011 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[15: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
[15:02] <slangasek> [TOPIC] lightning round
[15:02] <slangasek> $ echo $(shuf -e cjwatson barry doko stgraber jhunt mvo ev bdmurray slangasek)
[15:02] <slangasek> stgraber doko barry bdmurray cjwatson ev slangasek jhunt mvo
[15:02] <slangasek> stgraber: heya
[15:02] <stgraber> hey!
[15:03] <stgraber> - IPv6
[15:03] <stgraber>  - Made some progress on automated testing. I now have scripts generating all the needed networks, configurations and LXC containers (router and tester).
[15:03] <stgraber>  - Did some manual testing of the DUID changes by cyphermox (bug 849994)
[15:03] <stgraber>  - Will run a batch of manual tests of netcfg as automating them is taking longer than expected (I really need to find a way of running d-i in a LXC container ;))
[15:03] <stgraber> - iSCSI
[15:03] <stgraber>  - Made some progress on bug 838809. The problem is that open-iscsi is now being started at boot time ;)
[15:03] <stgraber>  - Need to spend more time finding a way of starting iscsid without disconnecting existing sessions.
[15:03] <stgraber>  - An easy workaround would be to "exit 0" when open-iscsi detects that we have run iscsistart in the initrd. This would restore the old behaviour.
[15:03] <stgraber>  - Problem with the workaround (and the pre-Oneiric open-iscsi) is that we only mount one lun from initramfs (the one needed for /), any other luns defined in /etc/iscsi aren't getting connected.
[15:03] <stgraber> - friendly-recovery
[15:03] <stgraber>  - With the suggestions of James and Colin, got a bunch of debdiffs attached to bug 575469
[15:03] <stgraber>  - This moves friendly-recovery out of /usr, add a read-only mode and splits recovery and single-mode into two different things. Currently waiting for the FFe and UIFe.
[15:03] <stgraber> - TODO
[15:03] <stgraber>  - Figure out how we want to fix that open-iscsi bug
[15:03] <stgraber>  - Do a last seed review and update for Edubuntu, possibly dropping at least Gnome Nanny (doesn't seem to work...)
[15:03] <stgraber>  - Finish the automated IPv6 testing and push the code somewhere
[15:03] <stgraber>  - Still need to spend more time trying to get TPM working in a PPA
[15:03] <mvo> \o/ 575469
[15:04] <doko> - NBS, http://people.canonical.com/~ubuntu-archive/nbs.html looks mucher nicer now ;)
[15:04] <slangasek> stgraber: what's the status of getting the ipv6 automated testing handed off to qa?
[15:04] <slangasek> do we expect that in place between now and release?
[15:05] <stgraber> slangasek: I'm first trying to get it working here ;) I'll have it running daily on a box of mine and will send the scripts to QA
[15:05] <stgraber> slangasek: I don't expect we'll have working IPv6 in DC very soon so it may take a while until it's running on QA infrastructure
[15:05] <slangasek> hmmm, ok
[15:06] <stgraber> at least the current implementation runs on LXC so I can get it running on anything that I have around and has ipv6 connectivity.
[15:06] <slangasek> doko: nbs> yay!
[15:07] <doko> - and FTBFS 7x24
[15:07] <doko> ..
[15:07] <stgraber> from what we discussed at the sprint, it seemed unlikely we'd be allowed to get an IPv6 tunnel or native connectivity from the QA infrastructure, at least not quickly.
[15:07] <doko> who did want to look at indicator-applet?
[15:07] <slangasek> stgraber: maybe the test configs should include a router with a tunnel?
[15:07] <slangasek> hmm
[15:08] <slangasek> doko: surely that should be flagged to the desktop team to clear up?
[15:08] <cjwatson> I thought it had been and they kind of stalled
[15:08] <doko> I'll assign it
[15:09] <slangasek> doko: thanks
[15:09] <stgraber> slangasek: I guess I could have the router act as a DNS server and HTTP proxy which might be enough to install and run some tests when we don't actually have public ipv6 connectivity
[15:09] <slangasek> doko: anything else?  Perhaps something you were working on during day 8 of the week, or hours 25-26 :)
[15:09] <doko> ohh, it is, bug 829491
[15:10]  * cjwatson gets slangasek a moon on a stic
[15:10] <cjwatson> *stick
[15:10] <doko> no, only openjdk-7 update, fortran rebuild, and some unrelated bug fixes
[15:10] <cjwatson> http://www.chiark.greenend.org.uk/~sgtatham/moon-on-stick.jpeg
[15:10] <slangasek> deep-fried, I trust
[15:10] <slangasek> haha
[15:10] <barry> :)
[15:10] <barry> i guess i'm up then...
[15:11] <barry> bug 407862; bug 839588; bug 621242; bug 831102; bug 835001; bug 770882; python bug 11715 (multiarch on kubuntu); python27 for lucid work (not totally given up yet, but close :).  done.
[15:11] <cjwatson> stgraber: could use tayga and totd to do NAT64 :-)
[15:11] <cjwatson> maybe
[15:11] <bdmurray> branch and merge proposal for apport to add the apport version to apport bug reports
[15:11] <bdmurray> branch and merge proposal for ubiquity apport source package hook changes
[15:12] <bdmurray> merge proposal / upload for dkms apport hook fixing bug 816199
[15:12] <barry> hmm, i thought i uploaded the fix for 839588
[15:12] <bdmurray> review and merging of bugpattern branchs from Vadim
[15:12] <bdmurray> review of bug patterns merge proposal(s) from RedSingularity
[15:12] <bdmurray> wrote, tested and added a bzr plugin for bug pattern commits
[15:12] <bdmurray> blog post regarding bugpattern_written bzr plugin
[15:12] <bdmurray> porting of patch subscription script to bug bot, modification of process to add a comment and subscriber ubuntu-sponsors to debdiff attachments
[15:12] <bdmurray> research into using bug_supervisor advanced search parameter in the web user interface
[15:12] <bdmurray> modified / updated launchpad greasemonkey tagging script to work again (been broken for about a year)
[15:12] <bdmurray> ubuntu bug day no package bug participation
[15:12] <bdmurray> ubuntu bug squad meeting
[15:12] <bdmurray> done
[15:13] <cjwatson> FTBFS; 40+ so far this week.
[15:13] <cjwatson> Repeated attempts to get an ubuntu-defaults-image build to work on the livefs buildds.  Finally succeeded today so am unblocked on dealing with the publishing scripts; that's my next task.
[15:13] <cjwatson> Firefighting eglibc/apt breakage yesterday due to C.UTF-8 collation order change.
[15:13] <cjwatson> Arranged for oem-config et al to be on the USB images again.
[15:13] <cjwatson> Waiting for RT#47856 resolution to complete multiarch-translations.
[15:13] <cjwatson> ..
[15:13] <ev> - Very short week; at Linux Plumbers and vacation on Tuesday.
[15:13] <ev> - Catching up on emails. Coordinating installer testing with Gema of QA.
[15:13] <ev> - Slideshow merges.
[15:13] <ev> - Fixes to the wireless networking page when an AP disappears.
[15:13] <ev> - Progress on setting the wallpaper in the GDK3 world.
[15:13] <ev> (done)
[15:14] <stgraber> cjwatson: oh, indeed, nat64 could do the trick. I'll need to poke at it once I get the rest of the test setup working :)
[15:15] <slangasek> short week for me, what with being on vacation through Monday
[15:16] <slangasek> proposed an FFe for plymouth to get flicker-free boot enabled with lightdm; one-liner change, but could use some more testing from folks with different video hardware
[15:16] <mvo> I can test it with the free ati drivers if that helps
[15:16] <slangasek> (bug #849954)
[15:16] <slangasek> mvo: that would be most welcome!
[15:17] <slangasek> also spent some time on a plane hacking on a startpar-upstart bridge, so that we can push a usable upstart into Debian
[15:17] <slangasek> ...and working on email backlog
[15:18] <slangasek> that's about it :)
[15:18] <slangasek> jhunt:
[15:18] <jhunt> Still finishing tests for Upstart job logging (necessitated 122 *new*
[15:18] <jhunt> tests so far!). Would be beneficial to have access to a system with NFS
[15:18] <jhunt> home directories. Merged code into Ubuntu branch and updated my
[15:18] <jhunt> "upstart-testing" PPA. Works, but with caveats: display manager doesn't
[15:18] <jhunt> initialize (who needs a GUI right? :), and there are minor problems with
[15:18] <jhunt> dbus and getty (currently investigating). One of the new tests has found
[15:18] <jhunt> a kernel bug. I've whipped up a test case and the fix looks relatively
[15:18] <jhunt> easy so I might have a go at that soon. Recreated problem on bug
[15:18] <jhunt> 818177. Tested with new kernel but no change. Trying to better
[15:18] <jhunt> understand the problem, but will need to talk to slangasek/cjwatson on
[15:18] <jhunt> this one.
[15:18] <jhunt> ❖
[15:18] <cjwatson> I'm afraid the last time I had NFS home directories anywhere was at job-2
[15:18] <cjwatson> (and good riddance)
[15:18] <jhunt> hey, me too! :)
[15:19] <mvo> vacation last week!
[15:19] <mvo> this week:
[15:19] <mvo> lots and lots and lots of mail catchup
[15:19] <mvo> aptdaemon: new bzr fixes snapshot reviewed/tested/uploaded
[15:19] <mvo> command-not-found-data update
[15:19] <mvo> software-center: debug database corruption issue again and hopefully fix threading race via thread specific xapiandb, review/merge lp:~mmcg069/software-center/submit-review-fixes, add simple get_title_from_html helper for the exhibits html, fix single item exhibits, show non-apps in exhibit lists as well, reenable plugins, add conflict for old oneconf, update example plugin, load plugins from the homedir as well, debug/fix exhibits banner re
[15:19] <mvo> ndering bug, include new default banner
[15:19] <mvo> apt: branch merges, cherry pick fix for sbuild breakage (lp: #816155), debug apt-ftparchive hang and fix it in lp:~mvo/apt/lucid-apt-ftparchive, cherry pick r2171 from lp:~donkult/apt/sid, fix double delete (thanks to cjwatson mostly) and upload new version
[15:19] <mvo> update-manager: debug/fix incorrect way of calling --with=python2, upload new version, branch merges
[15:19] <mvo> (EOF)
[15:19] <nullcore> i have an NFS system if you need access to it
[15:19] <nullcore> i use it for SELinux development, but i have a pristine setup as well that i could give you an account on
[15:19] <nullcore> sorry for interrupting
[15:20] <jhunt> nullcore: thanks - np :)
[15:21] <barry> sadly i still use nfs on my nas
[15:21] <slangasek> I have plenty of NFS here, but homes? yick
[15:22] <jhunt> well, nfs root would be good to start with.
[15:22]  * jhunt wants a netapp :)
[15:22] <slangasek> heh, not sure nfs root is where I would start :)
[15:22] <slangasek> considering it's been in varying states of disrepair since upstart was introduced, I think
[15:23]  * stgraber is glad LTSP switched away from nfs root a while ago ;)
[15:23] <slangasek> [TOPIC] burndown chartz
[15:23] <slangasek> [LINK] http://status.ubuntu.com/ubuntu-oneiric/canonical-foundations.html
[15:24] <slangasek> looks like we've got some accounting to do :)
[15:24] <slangasek> I'm going through this week to postpone workitems that we know should be postponed; please do the same for your own workitems
[15:25] <slangasek> so the release manager doesn't worry about all those features we're landing the day before release
[15:25] <slangasek> I may come knocking on doors individually to discuss workitems as needed
[15:25] <slangasek> [TOPIC] AOB
[15:25] <slangasek> anything else on your minds?
[15:26]  * barry thanks cjwatson for the pointer to chdist
[15:26] <ScottK> Yes.
[15:26] <bdmurray> On a funny note I found some unity bugs filed about dash
[15:26] <ScottK>  libnet-dns-perl apparently doesn't support IPv6.
[15:26] <ScottK> There's a patch on http://lists.amavis.org/pipermail/amavis-users/2011-June/000462.html
[15:26] <slangasek> bdmurray: errr?
[15:27] <bdmurray> well isn't party of unity called dash? ;-)
[15:27] <bdmurray> or the dash
[15:27] <slangasek> oh, heh
[15:27] <ScottK> Neither upstream nor the Debian maintainer are very active, so I was wondering if someone with a bit of Perl foo might see if we should get that in.
[15:27] <ScottK> (related to foundations-o-ipv6-healthcheck)
[15:27] <ScottK> ..
[15:27] <cjwatson> that looks like libnet-server-perl rather than libnet-dns-perl?
[15:28] <ScottK> Yes, sorry.
[15:29] <slangasek> any takers for a bit of perl?
[15:29] <cjwatson> I can take it
[15:29] <cjwatson> https://rt.cpan.org/Public/Bug/Display.html?id=33289
[15:29] <cjwatson> apparently it's already been applied in Debian svn
[15:29] <cjwatson> https://rt.cpan.org/Public/Bug/Display.html?id=67305
[15:29] <slangasek> [ACTION] cjwatson to get libnet-server-perl fixed for ipv6
[15:29] <meetingology> ACTION: cjwatson to get libnet-server-perl fixed for ipv6
[15:29] <slangasek> cjwatson: thanks
[15:29] <ScottK> cjwatson: Thanks.
[15:29] <cjwatson> so that's just "upload from svn" which is easy
[15:30] <ScottK> That's not what Debian Git users tell me.
[15:30] <ScottK> ;)
[15:30]  * cjwatson used svn for long enough that he doesn't have that particular prejudice :)
[15:31]  * slangasek has used git for long enough that he doesn't have that prejudice either ;)
[15:31] <cjwatson> heh, that too
[15:31] <slangasek> anything else?
[15:32] <slangasek> #endmeeting
[15:32] <meetingology> Meeting ended Wed Sep 14 15:32:05 2011 UTC.
[15:32] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-14-15.02.moin.txt
[15:32] <slangasek> thanks, all!
[15:32] <mvo> thanks
[15:32] <stgraber> thanks
[15:32] <jhunt> thanks
[15:32] <barry> thanks!
[15:33] <doko> thanks
[15:33] <ev> thanks
[16:46] <gema> QA meeting in 15 mins!
[17:00] <gema> Hi everyone, I will be chairing today's QA team meeting, I hope we are ready to get started
[17:00] <gema> #startmeeting QA Team meeting
[17:00] <meetingology> Meeting started Wed Sep 14 17:00:53 2011 UTC.  The chair is gema. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[17: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
[17:01] <gema> So, let's start with the previous actions
[17:01] <gema> [TOPIC] Previous Actions
[17:01] <gema> nuclearbob: were there any actions from last meeting?
[17:01] <nuclearbob> nope
[17:01] <gema> good, next topic
[17:01] <gema> [TOPIC] Community Efforts/Testing
[17:02] <gema> does anyone have an update on community efforts ?
[17:02]  * gema reminds you she is still not familiar with the usual players, so if anyone is meant to speak, please do so
[17:03] <gema> 3
[17:03] <gema> 2
[17:03] <gema> 1
[17:03] <gema> [TOPIC] Automated/Systems Testing
[17:03] <gema> I have been working on putting together a set of test cases that will need to be automated at some point
[17:04] <gema> we are still working on the test analysis and will publish it for review soon
[17:04] <gema> that's all from me
[17:04] <gema> ..
[17:04] <gema> any other update?
[17:05] <gema> 3
[17:05] <gema> 2
[17:05] <gema> 1
[17:05] <gema> moving on, then
[17:05] <gema> [TOPIC] Engineering Team Bug Status
[17:06] <gema> any updates on bug status, hggdh ? are you around?
[17:06] <bdmurray> \o
[17:06] <gema> bdmurray: go for it :)
[17:06] <bdmurray> There has been lots of activity around writing bug patterns recently with quite a few community contributions
[17:06] <bdmurray> Which is a huge help
[17:07] <bdmurray> Yesterday, I fixed the greasemonkey script that allows easier tagging of bug reports
[17:07] <bdmurray> This is currently in the bzr branch and I'll add it to the firefox extension shortly
[17:08] <bdmurray> Oh, I also wrote a bzr plugin that modifies bug reports that have had a bug pattern written for them when you are pushing the branch with the bug pattern
[17:08] <bdmurray> This saves quite a few steps
[17:08] <Ursinha> cool!
[17:09] <bdmurray> And I rewrote a Launchpad bug with patches tool to be run by my bug bot and behave differently if the patch is a debdiff
[17:09] <bdmurray> that's all folks
[17:10] <gema> thanks, bdmurray
[17:10] <gema> excellent week, you had :)
[17:10] <gema> any other update ? Ursinha ?
[17:10] <Ursinha> after bdmurray it's hard to look I've been working :)
[17:11] <Ursinha> I've been working on things that aren't noticiable for now, organizing the server packages and have list of bugs given their priorities to improve triage
[17:11] <Ursinha> nothing much reportable :)
[17:11] <Ursinha> ..
[17:12] <gema> good, thanks
[17:12] <gema> moving on to the next topic unless someone has anything else :)
[17:12] <gema> [TOPIC] Other Topics
[17:13] <gema> anything else you'd like to let us know? any other business to be discussed? any suggestion?
[17:13] <gema> any volunteers to review a test analysis?
[17:13] <charlie-tca> What's involved in that?
[17:14] <gema> reading the document and sending comments (such as , I think you are missing this, or that, or I would do this differently)
[17:14] <charlie-tca> I am terrible at that kind of thing
[17:14] <gema> the document itself is for generating testing for Ubiquity, the installer
[17:14] <gema> ok, charlie-tca , not a problem :)
[17:15] <charlie-tca> If no one else speaks up, I can try, though
[17:15] <gema> go ahead :)
[17:15] <gema> ok, I will speak to you about it off the meeting , thanks!
[17:16] <charlie-tca> okay
[17:16] <hggdh> \o
[17:16] <gema> go ahead, hggdh
[17:17] <hggdh> just a reminder, Beta 2 is coming -- we would like as much help as possible in testing the ISOs
[17:17] <hggdh> ..
[17:17] <gema> thanks
[17:17] <gema> [TOPIC] Chair Selection
[17:17] <gema> any volunteers to chair the meeting next week?
[17:18] <gema> ok, let's shuffle it then!
[17:18] <hggdh> yeah!
[17:18] <gema> Ursinha, it seems to be your turn
[17:18] <gema> are you happy with that?
[17:18] <hggdh> yes!
[17:18] <Ursinha> sure :)
[17:18] <charlie-tca> Yay!
[17:19] <gema> cool!
[17:19] <gema> [ACTION] Ursinha to chair next meeting
[17:19] <meetingology> ACTION: Ursinha to chair next meeting
[17:19] <Ursinha> \o/
[17:19] <darkcharl> (a late hurray!)
[17:19] <gema> #endmeeting
[17:19] <meetingology> Meeting ended Wed Sep 14 17:19:37 2011 UTC.
[17:19] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2011/ubuntu-meeting.2011-09-14-17.00.moin.txt
[17:19] <gema> ok, so now it is done
[17:19] <charlie-tca> gema: thank you for chairing
[17:20] <gema> not a problem! now I don't know how to get the logs on the wiki
[17:20] <Ursinha> thanks!
[17:20] <gema> I found it, no problem :D
[17:21] <hggdh> thank you gema
[17:22] <gema> hggdh: will the minutes appear automatically on https://wiki.ubuntu.com/QATeam/Meetings ? in previous meetings?
[17:23] <hggdh> well, it _could_, be we have been copying it in the w.u.c space manually -- it is saved on the bot's home by default, outside Ubuntu
[17:23] <hggdh> and we wanted to be sure it would always be available within Ubuntu
[17:24] <gema> you speak a very confusing language for me x)
[17:24] <gema> w.u.c?
[17:26] <Ursinha> gema, wiki.ubuntu.com, I guess
[17:28] <gema> Ursinha: I like your thinking, it is too late for me in the day to be seeing those things x)
[17:28] <gema> thanks
[17:28] <Ursinha> no problem :)


[00:00] <lifeless> any reason we can't run it right after ?
[00:01] <wgrant> It'd run into the 0902 run, so that wouldn't happen.
[00:03] <lifeless> wgrant: can has review?
[00:03] <wgrant> lifeless: Sorry, missed that. Will look in a sec.
[00:03] <wgrant> Just fixing test failures from yesterday's largish branch series.
[00:23] <wgrant> lifeless: Could you do the sort of query that jtv asked for https://code.launchpad.net/~jtv/launchpad/bug-613823/+merge/75773?
[00:23] <wgrant> lifeless: The approver is cronned on staging.
[00:23] <lifeless> wgrant: hmm ?
[00:24] <wgrant> lifeless: There are QA instructions in that MP.
[00:24] <wgrant> I don't have staging DB access.
[00:24] <lifeless> sorry to be a nuisance, but can you translate to sql ?
[00:25] <wgrant> SELECT * FROM translationimportqueueentry WHERE error_output IS NOT NULL AND status = 5 ORDER BY date_status_changed DESC LIMIT 10;
[00:25] <lifeless> 0
[00:26] <wgrant> That's upsetting. I guess I will check it with hloeung later.
[00:29] <wgrant> lifeless: Does oops-timeline really only lose us two lines of code?
[00:30] <lifeless> wgrant: yes, but it saves duplication for other folk glueing them together
[00:30] <wgrant> Two lines of duplication?
[00:31] <lifeless> about 10
[00:31] <wgrant> stsly?
[00:31] <lifeless> duplication has never been about size of code though
[00:31] <wgrant> srsly?
[00:35] <wgrant> lifeless: Do our consumers cope with the s/db_statements/timeline/?
[00:36] <mwhudson> https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc/+merge/75673 if anyone is bored...
[01:09] <lifeless> wgrant: oops-tools is a version locked buildout project.
[01:10] <lifeless> wgrant: it uses datedir-repo which this change doesn't affect, because its not a labelled key in the rfc822 format
[01:11] <lifeless> wgrant: that said, I have a branch for it which updates-and-corrects
[01:12] <lifeless> wgrant: that also needs a review :) - code.launchpad.net/~lifeless/oops-tools/timeline/+merge/75941
[01:15] <lifeless> mwhudson: ping
[01:16] <mwhudson> lifeless: hello
[01:17] <lifeless> want to talk (you know, by airwaves) about branch access?
[01:18] <mwhudson> ah sure
[01:18] <mwhudson> lifeless: mumble/skype/pots
[01:18] <mwhudson> ?
[01:18] <lifeless> the second door
[01:18] <poolie> mwhudson, just a random idea
[01:19] <poolie> is it cleaner to pass a dict that can contain a username and possibly other stuff?
[01:19] <poolie> i don't know if that will be easier to evolve or not
[01:19] <mwhudson> poolie: what would the values in the dictionary be?
[01:19] <lifeless> objects!
[01:19] <poolie> username='mbp' client_ip='<IP_ADDRESS>'
[01:19] <poolie> etc
[01:19] <mwhudson> ah
[01:19] <poolie> bzr_version='2.4.4'
[01:19] <mwhudson> lifeless: haha, this is xmlrpc
[01:23] <poolie> #quotes
[01:27] <wgrant> lifeless: Ahh, so it doesn't actually make a difference in the serialised format?
[01:34] <lifeless> right
[01:59] <lifeless> wgrant: were you going to review the oops-tools one too ?
[02:01] <wgrant> lifeless: Done.
[02:05] <StevenK> Oh look, pocketlint deals with JS.
[02:05] <StevenK> If only I knew that on Friday.
[02:05] <nigelb> heh
[02:06] <nigelb> What happened on Friday?
[02:06] <nigelb> Also, I thought pocketlint dealing with JS was one of its biggest advantages.
[02:07] <StevenK> I was dealing with the same JS branch, but I had broken the JS badly so Firefox didn't love me and refused to render the page
[02:07] <nigelb> Ouch.
[02:07] <nigelb> Didn't firebug help?
[02:07] <StevenK> No, it just told me I had a syntax error on line 68,000 something
[02:08] <StevenK> Which wasn't very handy
[02:08] <nigelb> Yeah.
[02:08] <nigelb> I like how firebug throws a weird bug when you make a mistake in JSON.
[02:08] <nigelb> I spent about 20 minutes for that, until I discovered jsonlint helps.
[02:09] <nigelb> StevenK: But if you click on the error it should take you to that line, letting you debug it.
[02:09] <nigelb> Not like that's easy either.
[02:09] <StevenK> Anyway, pocketlint has solved my issue.
[02:10] <nigelb> :)
[02:10] <nigelb> I hope noone stabs me for the number of revisions I've made undeployable.
[02:11] <wgrant> You've only made 13 undeployable, which is probably the least I've seen from non-APAC breakage.
[02:11] <wgrant> I get stabby when it gets above 50.
[02:11] <nigelb> non-APAC?
[02:12] <StevenK> APAC is Asia-Pacific
[02:12] <wgrant> US/EU breakage often gets nasty.
[02:12] <nigelb> "technically" I live in APAC
[02:12] <wgrant> Well, yeah.
[02:12] <wgrant> Just!
[02:12] <lifeless> easily
[02:12] <lifeless> asia goes -way- west
[02:12] <wgrant> Shh.
[02:13] <nigelb> Middle east is west of me.
[02:13] <nigelb> So, i'm not "just" Asia :P
[02:14] <lifeless> isn't it to the bosphorus?
[02:14] <nigelb> Yeah
[02:14] <lifeless> beautiful river
[02:15] <nigelb> lifeless: At some point I need to pick your brain further re:js-oopsd
[02:15] <nigelb> But at a later point when I'm not sleep deprived!
[02:18] <wgrant> reprocess-hwdb-submissions is doing well for itself.
[02:18] <wgrant> 90272 None: None
[02:19] <lifeless> nigelb: ok
[02:22] <wallyworld___> lifeless: can you tell me the code that gets invoked when serving loggerhead pages like to http://bazaar.launchpad.net/~johndoe/project/files
[02:22] <wgrant> wallyworld___: You're trying to add the privacy overlay thing?
[02:22] <wallyworld___> yes
[02:22] <wgrant> Run away.
[02:23] <wgrant> We have no loggerhead customisation story these days :/
[02:23]  * wallyworld___ starts running
[02:23] <wgrant> Which means we have to copy the LP-specific template and JS into the loggerhead tree. And have it there polluting everyone's installations.
[02:23] <wgrant> Even though it's only relevant to us.
[02:23] <wgrant> And our theme.
[02:23] <wallyworld> yuck
[02:23] <nigelb> Can't fork it?
[02:24] <wgrant> Forking it is not a good option.
[02:24] <nigelb> Like have a branch with launchpad changes, and keep merging trunk into it.
[02:24] <wgrant> We should have an alternate theme.
[02:24] <wgrant> Well.
[02:24] <wgrant> Really we should use LH as a service.
[02:24] <lifeless> erm
[02:24] <wgrant> And import it into the LP UI.
[02:24] <lifeless> right
[02:24] <mwhudson> if request is a ILaunchpadRequest, what is request.principal?
[02:24] <wgrant> But that may happen in three decades.
[02:24] <lifeless> the ideal thing is to make LH a background service.
[02:24] <wgrant> Until then we need something better.
[02:24] <wgrant> mwhudson: *probably* an IAccount.
[02:24] <lifeless> in the mean time, we a) maintain loggerhead, b) deploy trunk.
[02:24] <wgrant> mwhudson: Or it may have an adapter to IAccount.
[02:25] <nigelb> AH
[02:25] <lifeless> Guest73189: your nick is bust :)
[02:25] <Guest73189> yeah :-(
[02:25] <Guest73189> keeps happening
[02:25] <nigelb> So logggerhead won't actually show files form a private branch?
[02:25] <wgrant> nigelb: It does.
[02:25] <wgrant> nigelb: It just doesn't say that it's private.
[02:25] <nigelb> AHH.
[02:26] <mwhudson> wgrant: ah, it's a ILaunchpadPrincipal
[02:26] <nigelb> Stupid question - Isn't loggerhead already a service?
[02:26] <mwhudson> (well, if it's not unauthenticated)
[02:26] <wgrant> mwhudson: Does that handle stuff like IWeaklyAuthenticatedPrincipal?
[02:27] <wgrant> (which should really be INotActuallyAuthenticatedAtAllPrincipalButSomePeopleApparentlyCannotHandleEmailSigningBecauseTheyLikeToUseGmail, but that's a bit long)
[02:27] <nigelb> heh
[02:28] <mwhudson> wgrant: basically
[02:28] <mwhudson> i have a request
[02:28] <mwhudson> i want a person, or None
[02:28] <nigelb> I remember doing this elsewhere.
[02:28] <lifeless> nigelb: it is but it displays a web UI of its own
[02:29] <lifeless> nigelb: using different templates, middleware, and web stack.
[02:29] <lifeless> nigelb: its not a *backend* service that the LP web app can consume
[02:29] <nigelb> AHH.
[02:29] <lifeless> nigelb: its just a sibling website that happens to be themed the same way
[02:29] <nigelb> That means loggerhead should first expose such a service in trunk and then we need to grab that and use that?
[02:29] <lifeless> it has a bit of such a service
[02:29] <lifeless> it needs more
[02:30] <lifeless> and it needs to be -much- faster
[02:30] <nigelb> Agree on that one.
[02:30] <lifeless> its fast-path is tolerable but its slow path needs to be two orders of magnitude faster
[02:34] <lifeless> interesting  https://www.facebook.com/notes/facebook-engineering/making-facebook-self-healing/10150275248698920
[02:34] <mwhudson> (fwiw, i think IPerson(request.principal, None) is what i want)
[02:38] <StevenK> wallyworld__: Can I force an overlay to the top?
[02:38] <wallyworld__> StevenK: you mean so that it always stays on top?
[02:39] <StevenK> wallyworld__: Give me a tick, preparing screenshots
[02:39] <wallyworld__> ok
[02:41] <StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popup.png
[02:41]  * wallyworld__ looks
[02:42] <StevenK> wallyworld__: That's the "before" shot -- it's a private bug and I've clicked the "subscribed to all notifications" link for the popup
[02:42] <wallyworld__> and the confirm overlay appears beneath?
[02:42] <StevenK> wallyworld__: http://people.canonical.com/~stevenk/Subscribe-popunder.png
[02:42] <nigelb> Needs z-index magic :-)
[02:42] <wallyworld__> StevenK: overlays have a zIndex propety
[02:42]  * wgrant invokes mpt.
[02:42] <wallyworld__> StevenK: default is 0
[02:43] <StevenK> Oh no, I've angered wgrant.
[02:43] <wgrant> Nested overlays... this doesn't seem right.
[02:43] <wallyworld__> StevenK: http://yuilibrary.com/yui/docs/overlay/
[02:43] <StevenK> wallyworld__: Higher is on top, or lower is?
[02:44] <wallyworld__> StevenK: ummmm. higher i *think*
[02:45] <nigelb> Higher.
[02:45]  * nigelb helpfully links to http://www.w3schools.com/cssref/playit.asp?filename=playcss_z-index&preval=2
[02:45] <wallyworld__> StevenK: sort of agree with wgrant though. i'd like to see the click in the "remove" link result in the confirmation exapnding out below the link via an animation
[02:45] <wgrant> Right.
[02:45] <wallyworld__> sort of like for the stuff i did for confirming bug assignees
[02:45] <wgrant> The dialog mutate by expanding, or using a second step.
[02:45] <wgrant> s/mutate/should mutate/
[02:46] <StevenK> You two suck, or something.
[02:46] <wgrant> Dialogs are bad the best of times.
[02:46] <wallyworld__> you've been peeking in my window again haven't you
[02:46] <nigelb> Actually, I'll agree with them as well.
[02:46]  * wallyworld__ needs to close the curtains
[02:46] <StevenK> s/two/three/
[02:46] <nigelb> So, StevenK wasted 2 days of JS hacking only to be mpt'd :P
[02:47] <StevenK> Not really
[02:47] <StevenK> Since there are two callsites
[02:47] <wgrant> I always expect a few days of hacking on a new technology to have to be thrown out at least a couple of times.
[02:48] <wgrant> And while feature squads seem to like introducing tech debt and terrible UI, I think we should try to do this at least vaguely properly.
[02:48] <nigelb> what's tech debt? I see that used in tags.
[02:49] <wgrant> Launchpad.
[02:49] <nigelb> Heh.
[02:49] <wgrant> Launchpad is mostly tech debt.
[02:49] <wgrant> http://c2.com/cgi/wiki?TechnicalDebt
[02:50] <lifeless> wgrant: I've seen worse.
[02:50] <wgrant> lifeless: Huh?
[02:50] <wgrant> Where?
[02:50] <wgrant> COBOL doesn't count.
[02:50] <nigelb> Ah.
[02:50] <wallyworld__> wgrant: minestar
[02:50] <lifeless> wgrant: Micropay
[02:50] <wgrant> OK, software that isn't meant to be enterprisey?
[02:50] <lifeless> wgrant: .... unlike LP ?
[02:51] <wallyworld__> wgrant: win32 api :-)
[02:51] <nigelb> Isn't LP the enterprisey codehosting website? ;-)
[02:51] <wgrant> LP isn't meant to be enterprisey, I don't think. It is, but I don't think it was meant to be.
[02:51] <lifeless> wgrant: and yeah, a few things do come to mind that rival LP for 'wants refactoring soooo bad'
[02:51] <nigelb> It may not be meant to be enterprisey, but some of the best features are enterprisey.
[02:51] <nigelb> (lp)
[02:51] <lifeless> wgrant: see rule #1: all software sucks.
[02:52] <wgrant> lifeless: We just have no way to make it not suck.
[02:52] <wgrant> Because nobody wants to reduce tech debt.
[02:52] <nigelb> Delete more code. That's code that's guaranteed to not suck :-)
[02:52] <wgrant> Maintenance squads can't fix it, and feature squads won't.
[02:52] <wgrant> => we are fucked
[02:52] <wgrant> :)
[02:52] <StevenK> Everything will be better when we have no criticals.
[02:52] <StevenK> OH WAIT
[02:52] <wgrant> Hahahahahahahhaa
[02:53] <nigelb> Bwahaha
[02:53] <StevenK> I could not help myself ...
[02:53] <wgrant> Speaking of which,.
[02:53] <nigelb> 390 bugs with tech-debt :/
[02:53] <wgrant> nigelb: And that's mostly just the really bad stuff.
[02:54] <StevenK> Bleh, still 260.
[02:54] <StevenK> We are going *backward*
[02:54] <nigelb> wgrant: Some seem to be not very had.
[02:54] <nigelb> *hard
[02:54] <wgrant> nigelb: Some aren't, no.
[02:54] <wgrant> nigelb: And even the big stuff is not hard.
[02:54] <wgrant> I spent a few hours yesterday and very nearly disposed of Zopeless.
[02:54] <StevenK> wgrant: How did that turn out?
[02:55] <wgrant> StevenK: Some test failures in the last branch in the series.
[02:55] <wgrant> Which removes ZTM's commit/abort/begin methods, and initZopeless' return value.
[02:55] <wgrant> Leaving ZTM to be moved into DBConfig in the next branch.
[02:55] <wgrant> Still have to strip out Zopeless mail somehow.
[02:56] <wgrant> But it's all pretty well detangled now.
[02:56] <lifeless> great
[02:56] <wgrant> initZopeless' callsites are limited to core base classes and buildd-manager.
[02:56] <wgrant> Which means we can finally untangle the damned dbuser handling.
[02:56] <wgrant> Which is roughly quadruplicated at the moment.
[02:57] <mwhudson> poolie: is there a reason that there are scopes team:foo but server.edge?
[02:57] <wgrant> And it also means the Zopeless layers can die, which simplifies things a bit.
[02:57] <mwhudson> i.e. ':' vs '.'
[03:01] <poolie> mwhudson, i don't think there's any really good reason
[03:01] <poolie> you could look at it as 'server_edge=True' vs 'server=edge
[03:03] <lifeless> o/ 90K hwdb exceptions
[03:04] <wgrant> Yup, the reprocessing seems to be going well...
[03:04] <lifeless> 181 AttributeError: 'LaunchpadTimeoutError' object has no attribute '__traceback__' looks suspect
[03:04] <wgrant> lifeless: I pointed that out last week, yeah. The attempted reraising is bad.
[03:04] <wgrant> __traceback__ was added in 2.7, wasn't it?
[03:04] <lifeless> wgrant: did you file a bug ?
[03:04] <wgrant> Maybe even 3.x.
[03:04] <wgrant> No.
[03:04] <lifeless> wgrant: or reopen it ?
[03:04] <wgrant> I had three production breakages.
[03:04] <lifeless> I'm not criticising
[03:05] <lifeless> I'm asking so I don't duplicate work.
[03:05] <wgrant> You should have been :P
[03:05] <wgrant> I haven't, no.
[03:05] <wgrant> Well, really I wanted to see if anyone else would pick it up.
[03:05] <lifeless> IIRC benji worked on it ?
[03:05] <wgrant> I think that's right.
[03:05] <wgrant> lifeless: So, for science, I'd like to leave it a couple of days and see if a maintenance squad notices.
[03:06] <lifeless> well
[03:06] <lifeless> I've mailed benji
[03:07] <wgrant> :(
[03:07] <StevenK> SUCCESS!
[03:07] <StevenK> My confirmationoverlay works for +subscriptions
[03:08] <StevenK> wallyworld__: *prod*
[03:08] <wallyworld__> StevenK: ouch!~
[03:08] <wallyworld__> StevenK: excellent
[03:09] <wallyworld__> StevenK: you are now a yui expert :-)
[03:09] <nigelb> Trapped! :P
[03:09] <wallyworld__> and i'll assign all the js bugs to you!
[03:09] <StevenK> wallyworld__: Suggestions about how to break up the form_content in http://pastebin.ubuntu.com/692723/ ?
[03:09]  * wallyworld__ looks
[03:09] <nigelb> wgrant: Deploying today?
[03:10] <wallyworld__> StevenK: you can use a join
[03:10] <wallyworld__> give me a sec and i'll find an example
[03:10] <wgrant> nigelb: Funny you should ask.
[03:10] <wgrant> 13:09:58 < wgrant> hloeung: We need to do a nodowntime rollout today so we can turn gina on.
[03:10] <wgrant> nigelb: So, you weren't quite perfectly timed, but 'tis acceptable.
[03:10] <nigelb> wgrant: Almost immediately? :-)
[03:11] <nigelb> what channel was that? Canonical IRC?
[03:11] <wgrant> Maybe. Some preparation to do, and we are down to one LOSA this week.
[03:11] <StevenK> nigelb: Yes, a private one.
[03:11] <wgrant> Yeah, that was #launchpad-ops on the Canonical network.
[03:11] <lifeless> mwhudson: don't you hate all the boilerplate glue to say 'this code at that endpoint' ?
[03:11] <mwhudson> lifeless: YES
[03:11] <nigelb> StevenK: ah, I have an example of join somewhere I think.
[03:11] <mwhudson> i used a bit less boilerplate than some though
[03:11] <wallyworld__> StevenK: search for join('') or join("") in js
[03:11] <wallyworld__> there's quite a few places
[03:12] <mwhudson> some endpoints have the xml-rpc methods in a view on the application endpoint object
[03:12] <wallyworld__> StevenK: you can use string concat if it's only 2-3 lines.
[03:12] <mwhudson> i just put the methods on the application endpoint object
[03:12] <nigelb> StevenK: ['foo', 'bar'].join('')
[03:12] <wallyworld__> but any longer, a join is recommended
[03:12] <nigelb> where foo and bar are 50 to 70 chars each.
[03:13] <nigelb> wgrant: I'm technically a jQuery person more, but YUI is quite neat :-)
[03:13] <nigelb> err
[03:13] <nigelb> wallyworld__: ^
[03:14] <wallyworld__> nigelb: ?
[03:14] <nigelb> wallyworld__: I played around a lot with it for that bug title fix. Its different, but now I think in a better way.
[03:16] <wallyworld__> nigelb: oh, you mean you like yui. it's not too bad actually. i think it's 2nd most popular framework behind jQuery
[03:16] <StevenK> wallyworld__, nigelb: Fixed, thanks.
[03:16] <nigelb> StevenK: \m/
[03:17] <StevenK> I think I need to revert bug_subscription_portlet changes while I work out how to expand it
[03:17] <StevenK> Perhaps I'll do the changes in two branches
[03:18] <lifeless> mwhudson: I've done a review
[03:19] <lifeless> mwhudson: its probably a bit opaque. Two key things - please don't duplicate code (team: magic string handling), and a bit fuzzier one that you may want to ping me on
[03:19] <mwhudson> lifeless: you have?  i don't see a review
[03:19] <lifeless> mwhudson: process-incoming.py
[03:19] <mwhudson> ah
[03:19] <mwhudson> lifeless: did you see my response to poolie's comments?
[03:20] <StevenK> wallyworld__: I'll grab you after lunch on how to test this thing?
[03:20] <wallyworld__> StevenK: ok
[03:20] <nigelb> YUI tests! Fun! :-)
[03:20] <StevenK> wallyworld__: No promises on where I'll grab you
[03:20] <lifeless> yes, I think dict for scopes was confusing (because scopes are containers), but coming from the same place I am
[03:20] <StevenK> :-P
[03:20] <wallyworld__> oh, one can only hope
[03:21] <lifeless> mwhudson: docs are in docstrings.
[03:22] <mwhudson> lifeless: were you under the impression that i know what you're talking about?
[03:23] <lifeless> mwhudson: yes!
[03:23] <lifeless> mwhudson: poolie pointed you at docs, you found an empty file.
[03:23] <mwhudson> well, i still don't know what needs to be _updated_
[03:23] <lifeless> mwhudson: I believe they are in module docstrings instead
[03:23] <mwhudson> all the code i added has docstrings
[03:23] <lifeless> yes, but nothing points at your code; thats the point I think.
[03:24] <mwhudson> ah oik
[03:24] <lifeless> __init__.py
[03:27] <mwhudson> lifeless: were you reviewing the originally proposed version, or r13974 ?
[03:27] <lifeless> mwhudson: the mailed out version
[03:27] <mwhudson> lifeless: ok, look again please
[03:29] <lifeless> much better
[03:45] <lifeless> mwhudson: back to you :)
[03:46] <mwhudson> lifeless: lol, guess what my working copy looks like
[03:47] <mwhudson> default_scopes = (DefaultScope(),)
[04:00] <lifeless> mwhudson: :)
[04:02] <mwhudson> lifeless: back to you (hopefully not much more of this)
[04:04] <lifeless> mwhudson: your example is missing a :
[04:04] <lifeless> 'codehosting.use_forking_server', ['user:' + user_name])
[04:04] <lifeless> ->
[04:04] <lifeless> 'codehosting.use_forking_server', ['user:' + user_name]):
[04:05] <mwhudson> ah
[04:05] <mwhudson> ok
[04:07] <mwhudson> lifeless: thanks
[04:08] <mwhudson> i wonder if i can still land code ...
[04:08] <lifeless> should be able to
[04:08] <lifeless> have I put you in the emeritus team yet ?
[04:08] <mwhudson> don't think so
[04:09] <lifeless> want me to?
[04:09] <mwhudson> lifeless: are you aware of a bug report about this?
[04:09] <lifeless> about what?
[04:09] <lifeless> oh
[04:09] <lifeless> uhm
[04:09] <lifeless> there may be one
[04:09] <mwhudson> lifeless: what impact does being the emeritus team have?
[04:09] <mwhudson> ok, i'll search
[04:09] <lifeless> you'll get review mail which we don't [yet] have a good offswitch for
[04:10] <lifeless> you get bugcontrol privs, and push privs to ~canonical-launchpad-branches
[04:10] <lifeless> mwhudson: ah you are in it
[04:10] <mwhudson> oh ok
[04:10] <lifeless> https://launchpad.net/~canonical-launchpad-emeritus
[04:10] <mwhudson> i don't get review mail...
[04:10] <StevenK> No PQM access?
[04:11] <mwhudson> (which i am happy with, before you do anything about that :p)
[04:11] <lifeless> mwhudson: its not fully setup up :)
[04:11] <lifeless> mwhudson: the intent is to get you review privs, which currently implies mail.
[04:11] <lifeless> mwhudson: [sorry]
[04:11] <mwhudson> lifeless: i appear to be able to approve merge proposals
[04:12] <mwhudson> i am still in ~launchpad mind
[04:12] <lifeless> mwhudson: ah, well then :P
[04:12] <lifeless> mwhudson: its moot till you leave that
[04:12] <mwhudson> ok
[04:14] <lifeless> StevenK: yes, if pqm is integrated with LP (which it was till the code decided their old automation design was wrong)
[04:15] <StevenK> lifeless: Right, so the intent is that canonical-launchpad-emeritus members continue to have PQM?
[04:16] <lifeless> StevenK: the intent is that emeritus devs lose nothing if they are still @ canonical, and lose write-to-deployed-branches only, if they are not.
[04:16] <lifeless> e.g. be as close to an open source project as we can with our current constraints
[04:19] <StevenK> wallyworld__: *grab*
[04:19] <StevenK> wallyworld__: Let me just get some tea
[04:19] <wallyworld__> StevenK: oooh. a little hiher
[04:19]  * StevenK goes to scrub his hands with solvol and steel wool
[04:28] <wallyworld__> StevenK: so you got your tea?
[04:29] <StevenK> wallyworld__: Indeed. Ready when you are.
[04:30] <wallyworld__> StevenK: ok, so you want to write a yui test for your confirmation overlay functionality?
[04:30] <StevenK> wallyworld__: Yup. I'm on mumble if that makes it simpler.
[04:30] <wallyworld__> StevenK: ok. i'll just grab my headset. one of the kids has nicked it
[04:31] <StevenK> Hah
[04:42] <wgrant> Ah, finally.
[04:42] <wgrant> ~jans has added their OpenPGP key.
[04:43] <wgrant> They've uploaded 18 packages this morning.
[04:43] <wgrant> Over several hours.
[04:43] <wgrant> Causes lots of process-upload cronspam :(
[04:43] <StevenK> Hah
[04:43] <wgrant> But maybe it will stop now.
[04:50] <nigelb> wgrant: Don't you have filters for that sort of thing?
[04:52] <wgrant> nigelb: That's one of the few user errors that still generates emails.
[04:53] <wgrant> nigelb: I tried to fix it one day, but then found terrible security holes and never visited that code again.
[04:54] <wgrant> Ah, I see that sinzui had a productive anti-tech-debt Sunday as well.
[04:58] <nigelb> :)
[04:58] <StevenK> wgrant: Oh?
[04:58] <wgrant> StevenK: You might recall I was talking about pagetitles last week on the call.
[04:58] <wgrant> StevenK: sinzui deleted much of it.
[04:59] <StevenK> Neat
[05:05] <mwhudson> wgrant: can you talk to sinzui about blueprints next?
[05:05] <wgrant> Heh
[05:05] <StevenK> Haha
[05:05] <nigelb> Just delete the folder?
[05:05] <nigelb> I can do that. :P
[05:05] <StevenK> mwhudson: You want blueprints deleted?
[05:05] <wgrant> Damn, ZTM will probably fall tomorrow. Then I'll need to find another target for my wrath :(
[05:06] <StevenK> wgrant: lib/canonical
[05:06] <wgrant> StevenK: canonical.lp no longer exists in devel... will that do?
[05:06] <nigelb> WHAT
[05:06] <nigelb> !!
[05:07] <wgrant> canonical.lp, not canonical.launchpad :(
[05:07] <nigelb> Ah!
[05:07] <mwhudson> wgrant: actually, talk to him about ILaunchBag
[05:07] <nigelb> I did wonder if I patched something in canonical.launchpad only for you to delete it.
[05:07] <wgrant> mwhudson: I've tried to rip out bits of that myself, but it's not easy :(
[05:08] <wgrant> ZTM was pretty easy, just very involved and tedious.
[05:08] <StevenK> ILaunchBag needs to die
[05:08] <nigelb> Wait ILaunch*Bag*?
[05:08] <nigelb> I first read it as Bug and I was WTF.
[05:08] <wgrant> It's like a global variable, except more subtly hidden.
[05:08] <mwhudson> wgrant: s/getUtility(ILaunchBag).user/IPerson(get_current_browser_request(), None)/ should do a bunch of it
[05:09] <mwhudson> but you might get a million tests to fix
[05:09] <wgrant> mwhudson: Also doesn't catch non-browser users.
[05:09] <wgrant> eg. the email interface uses LaunchBag in places.
[05:09] <wgrant> Because why not.
[05:09] <mwhudson> ah, this relates to that other bug
[05:09] <mwhudson> scripts don't do participations rite
[05:10] <wgrant> Scripts do a lot of things not right.
[05:10] <wgrant> I need to talk to Zope people about zope.app.testing.functional.FunctionalTestSetup, too.
[05:10] <wgrant> Or maybe just replace FunctionalLayer with ZopelessLayer and see what blows up.
[05:10] <mwhudson> https://bugs.launchpad.net/launchpad/+bug/623199
[05:10] <_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
[05:10] <wgrant> Ah
[05:16]  * mwhudson evaporates
[05:17]  * wgrant gets the condensor.
[05:30] <StevenK> wallyworld__: How can I determine what to put in Y.one() for the overlay?
[05:30] <wallyworld__> StevenK: Y.one('#id') where id is the overlay id if you know it
[05:30] <wallyworld__> StevenK: or Y.one('.yui3-overlay-xxxx') where xxx is the class
[05:31] <StevenK> Yes, my question is how to determine the overlay id, since I don't
[05:31] <wallyworld__> StevenK: you can set the id. give me a minute to check
[05:33] <wallyworld__> StevenK: you have a content_box which you create -eg Y.Node.create("<div #id='foo'></div>")
[05:33] <wallyworld__> StevenK: then you can create the overlay, telling it to use this content_box
[05:34] <wallyworld__> see picker_patcher.js around line 54
[05:34] <wallyworld__> this creates an Activator but the concept is the same I think
[05:36] <StevenK>         var co = Y.one('.yui3-overlay-confirmationoverlay');
[05:36] <StevenK>         Y.Assert.isNull(co);
[05:36] <StevenK> wallyworld__: ^
[05:36] <wallyworld__> StevenK: are you saying the asset fails? or passes?
[05:37] <StevenK> I'm not saying either yet, I'm saying that the code I have at the moment.
[05:37] <wallyworld__> or that's what you are proposing
[05:37] <wallyworld__> ?
[05:37] <wallyworld__> ah. that will work if there's only one confirmation overlay
[05:38] <wallyworld__> otherwise you will need to set the content box
[05:38] <wallyworld__> in the initialisation params
[05:38] <wallyworld__> of the overlay
[05:39] <StevenK> If the subscription js is creating two confirmation overlays, that is news to me
[05:40] <wallyworld__> StevenK: i mean on the page. so long as the node used as the root for .one() is correctly set it will work
[05:40] <wallyworld__> ie use can use Y.one() which is for the whole page or
[05:41] <wallyworld__> node.one() which just looks at children of the node
[05:41] <StevenK> No failures
[05:41] <StevenK> Let me break it
[05:53] <StevenK> wallyworld__: So I get failures, but none about my code
[05:53] <wallyworld__> StevenK: what sort of failures?
[05:54] <StevenK> http://pastebin.ubuntu.com/692789/
[05:55]  * wallyworld__ looks
[05:58] <wallyworld__> StevenK: the test invokes test_unsubscribe_with_warning_action which clicks the link and looks at the mocked io values
[05:58] <wallyworld__> StevenK: so with the confirmation dialog there, it doesn't get to do the expected io
[05:58] <StevenK> wallyworld__: Right, so that's fine that it fails -- but test_on_unsubscribe_updates_info doesn't fail
[05:58] <wallyworld__> but since your test is failing, it may be that the Y.one(.xxxx) is wrong
[05:58] <StevenK> My test is failing to fail
[05:58] <wallyworld__> i would use firebug to inspect the css class used
[05:59] <wallyworld__> for the confirmation overlay
[05:59] <StevenK> class="pretty-overlay-window yui3-widget yui3-overlay yui3-pretty-overlay yui3-lazr-formoverlay yui3-lp-app-confirmationoverlay yui3-widget-positioned yui3-widget-stacked"
[05:59] <StevenK> That bit?
[06:00] <wallyworld__> yep, use 'yui3-lp-app-confirmationoverlay'
[06:00] <StevenK> With no dot?
[06:00] <wallyworld__> sorry, with a dot
[06:01] <wallyworld__> StevenK: to be pedantic, you could use Y.one('.yui3-overlay .yui3-lp-app-confirmationoverlay')
[06:01] <wallyworld__> which will require both classes to be present
[06:01] <wallyworld__> but try the simple case first
[06:19] <StevenK> wallyworld__: Which still doesn't fail how I want
[06:20] <wallyworld__> StevenK: how does it fail now?
[06:20] <StevenK> wallyworld__: The same way
[06:20] <StevenK> Which means Y.Assert.isNull(co) is true
[06:21] <wallyworld__> StevenK: and you are sure the overlay is always being created
[06:21] <StevenK> wallyworld__: Well, I'd like to debug this somehow, but I have NFI how
[06:22] <wallyworld__> StevenK: you open the html harness in chrome and use firebug
[06:22] <wallyworld__> or firefox
[06:22] <wallyworld__> but for yui tests, chrome seems to work better
[06:22] <wallyworld__> run the tests one to load the scripts, then switch to the test_xxxx.js script and set a breakpoint
[06:22] <wallyworld__> and hit refresh
[06:29] <poolie> o/ wallyworld__
[06:29] <wallyworld__> hi poolie
[06:33] <wallyworld__> StevenK: i may have mislead you. to test for both classes, you use Y.one('.foo.bar') <- without the space, slip of the fingers
[06:34] <wallyworld__> poolie: how can i help?
[06:36] <poolie> just saying hi
[06:37] <wallyworld__> poolie: just checking, just in case :-)
[07:01] <jtv> hi mrevell!
[07:01] <mrevell> Morning!
[07:02] <jtv> mrevell: we just rolled out a small but hopefully helpful Translations change that may be worth announcing.
[07:02] <jtv> Any suggestions for how/where I ought to do that?  I haven't kept track.
[07:03] <mrevell> jtv, I'd always favour a blog post. We can then reference that elsewhere.
[07:04] <lifeless> wgrant: closing in on u1; up for 2 tiny reviews in the same theme ?
[07:04] <mrevell> Top notch, btw.
[07:04] <jtv> thanks mrevell
[07:05] <rvba> wgrant: Hi, if you haven't (re-)reviewed my branch yet, I'll split the changes like you suggest.
[07:06] <wgrant> rvba: That would be great -- as it stands it's pretty impractical to see what's what, as I'm sure you've found.
[07:06] <wgrant> lifeless: Possibly. Links?
[07:06] <lifeless> https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
[07:06] <rvba> wgrant: Indeed. I'll do that this morning.
[07:26] <lifeless> wgrant: ^
[07:27] <poolie> wallyworld__, hey thanks for grabbing bug 696954, that has bothered me in the past
[07:27] <_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
[07:27] <wallyworld__> poolie: np. it's on the disclosure todo list :-)
[07:28] <poolie> hm
[07:29] <poolie> kinda seems like some scope creep there
[07:29] <poolie> but i'm happy it's getting done
[07:29] <poolie> i think there may be dupes or near dupes of it
[07:29] <poolie> no need to find them now i guess
[07:29] <wallyworld__> poolie: disclosure covers who has access to information just as much as who doesn't
[07:30] <wallyworld__> i'll try and see that any dupes are linked to this bug
[07:32] <lifeless> wallyworld__: you'll need to be very careful about query changes - lots of room for foot-gun on performance in this area; OTOH brad snuck some of it in already before the re-org, so we may be lucky.
[07:33] <wallyworld__> lifeless: the accepted pattern seems to be union of sub queries. i've put up a mp this afternoon along those lines and was going to do something similar here
[07:33] <lifeless> wallyworld__: its not so much a matter of patern, as bug queries being right on the cliff face of timeouts
[07:34] <lifeless> wallyworld__: so adding more work to them has a high probability of pushing them over the cliff
[07:34] <poolie> wallyworld__, so it's kind of a beer conversation but it kind of seems like tackling every bug kinda related to the feature may cause features to run long and starvation of other areas
[07:34] <lifeless> wallyworld__: -> need to make it as much faster as the extra work you are asking it to do.
[07:34] <poolie> but i am really happy to see this one fixed
[07:34] <lifeless> wallyworld__: I'd allow several days for dealing with performance impacts alone
[07:35] <poolie> wallyworld__, oh the one i filed was bug 746887
[07:35] <_mup_> Bug #746887: private bugs get stuck invisible to developers <disclosure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/746887 >
[07:35] <poolie> which is a direct dupe of yours, i'd say
[07:35] <poolie> but now duped against bug 696973
[07:35] <_mup_> Bug #696973: There are no roles that can see all private artifacts in (public or private) projects <disclosure> <projects> <teams> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/696973 >
[07:36] <wallyworld__> lifeless: recently, bug task assignee was added to the allowed viewers of private bugs. i've taken the same approach for https://code.launchpad.net/~wallyworld/launchpad/pillar-owners-private-bug-visibility-702429/+merge/75961 i can give you some sql to run on staging if you want
[07:37] <wallyworld__> poolie: i'll see if yours is a dup and link it
[07:37] <lifeless> wallyworld__: its not that simple :) - you'll find you need to look at prod (because its in the grey area), and compare bug search timeout counts before/after you go live, and see if there is a regression, and if so toggle it off.
[07:38] <wallyworld__> lifeless: actually, i can optimise it a bit - only do the sql depending on which pillar is not none
[07:39] <wallyworld__> lifeless: ok. i'll make the optimisation before i land. and gather some stats as you suggest
[07:39] <lifeless> wallyworld__: how? (We have queries that cover all pillars - site wide bug queries)
[07:39] <lifeless> wallyworld__: one big thing you can do to make this safer is feature-flag the new query.
[07:39] <lifeless> easy to do, big rewards, I mean.
[07:40] <wallyworld__> lifeless: yes ok. optimisation not feasible as you say. but i will do a ff
[07:41] <wallyworld__> actually, i could do the project roles work as per 969793 behind the same ff perhaps
[07:41] <lifeless> bug 969793
[07:42] <lifeless> no mup?
[07:42] <wallyworld__> um, 696954
[07:42] <wallyworld__> sorry
[07:42] <wallyworld__> wrong bug
[07:42] <lifeless> bug 696954
[07:42] <_mup_> Bug #696954: Allow persons in project roles to access private bugs <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/696954 >
[07:49] <lifeless> wallyworld__: cool; if you need specific stuff tested, yes I'd be happy to help.
[07:50] <lifeless> wallyworld__: we can only get pretty gross results from staging as I mentioned though :( - clearly good and clearly bad, but its poor on 'maybe'
[07:50] <wallyworld__> lifeless: thanks. i guess i'll need you if it all blows up on prod and we have to turn off the ff :-)
[07:51] <lifeless> wallyworld__: trivial queries will always be fine. You'll have trouble, if you do, on: project queries (e.g. launchpad-project), and Ubuntu queries, and site-wide queries.
[07:53] <wallyworld__> lifeless: well fingers crossed. if you are interested, https://pastebin.canonical.com/52955/ the unions after bug task assignee are the new ones
[08:04] <adeuring> good morning
[08:09] <rvba> wgrant: I know you're busy right now and this is not urgent at all, but I've refactored the branch: the first one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy/+merge/74769 and the second one is https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-credit-copy-2/+merge/74958
[08:25] <bigjools> lifeless: are you around in about 20 minutes to talk about python-oops?
[08:25] <lifeless> I think so
[08:26] <bigjools> thanks, just need to do my team call
[08:30] <lifeless> wgrant: sorry to be a nag, was that yes or no to the reviews?
[08:30] <wgrant> lifeless: Sorry, unexpectedly busy. I can look tomorrow (I'm OCR), but I guess you want to toss them at someone else.
[08:31] <lifeless> I'm nearly EOD too, I may just nab you in the morn
[08:31] <lifeless> I need to finish the storm component before it all becomes relevant.
[08:31] <lifeless> thats nearly done
[08:46] <bigjools> lifeless: hi
[08:46] <bigjools> skype?
[08:47] <lifeless> sure
[08:49] <cjwatson> ok, what the heck does https://launchpad.net/ubuntu/+source/clang/2.9-11ubuntu1/+build/2792745 mean
[08:49] <cjwatson> "Currently building" "Finished 7 hours ago (took 18 hours, 12 minutes, 50.6 seconds)"
[08:50] <cjwatson> definitely still going, still getting build output
[08:50] <bigjools> it's a bug
[08:50] <thumper> cjwatson: confused
[08:50] <thumper> hi bigjools
[08:50]  * bigjools looks up the bug
[08:50] <bigjools> yo thumper
[08:50] <wgrant> cjwatson: Yeah, came upon that earlier... it finished on celbalrai, but then $something happened and it was redispatched. I haven't seen that happen for 18 months...
[08:51] <wgrant> cjwatson: It is building now, and should upload as normal in ~22 hours, at which time it will look sensible again,.
[08:51] <bigjools> I think it's part of bug 717969
[08:51] <_mup_> Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <Launchpad itself:Triaged> < https://launchpad.net/bugs/717969 >
[08:51] <cjwatson> ah, ok, I wouldn't have been able to find that bug :)
[08:51] <wgrant> That's a possibility, yes.
[08:51] <wgrant> It's not a case of that bug that we've seen before, but it is a similar sort of thing.
[08:51] <bigjools> the bug title needs to change
[08:52] <bigjools> might it have been to do with the FDT?
[08:52] <wgrant> bigjools: No, this was hours ago.
[08:52] <wgrant> The initial issue was 6 or 7 hours ago.
[08:52] <cjwatson> should I add a screenshot or something to that bug?  The evidence will go away in the near future
[08:52] <bigjools> ok
[08:53] <wgrant> cjwatson: That would probably be useful. Also useful is the API representation of the build: add /api/devel to the start of the path to get that.
[08:53] <cjwatson> OK
[08:53] <bigjools> lifeless: ok ready when you are, can't see you on skype
[08:55] <lifeless> I'm rbtcollins
[08:56]  * bigjools blind dials
[09:58] <danilos> lifeless, hi, where's the code for ppr pages? I assume it process launchpad appserver log files, right?
[09:58] <danilos> s/process/processes/
[10:02] <mpt> StevenK, whatever it was I did, I apologize
[10:03] <lifeless> danilos: ztrace files yes
[10:03] <lifeless> danilos: its in the lp tree
[10:05] <danilos> lifeless, oh right, thanks
[10:07] <danilos> lifeless, btw, how would you feel if we add the request duration to the apache log files as well?
[10:08] <lifeless> danilos: no particular opinion; I thought apache log format had that anyeway
[10:09] <danilos> lifeless, it doesn't, unfortunately, common format only lists request *end* time afaict
[10:09] <danilos> lifeless, ok, I'll bring it up with LOSAs since this may affect our log processing scripts as well
[10:11] <danilos> and actually it's the time request was received, some stale reference for my previous claim :)
[10:18] <mpt> StevenK, fwiw, I can't see what's in the "Unsubscribe" overlay on that screenshot, but it looks reasonably probable that fixing bug 795180 would make it unnecessary.
[10:30] <StevenK> mpt: I'm fixing a seperate bug -- if a user is unsubscribing themselves from a private bug, they should be warned.
[10:32] <mpt> StevenK, oh, then I'll have to agree with wgrant then. :-) That warning could be indented under the one of those three commands that deprives you of access.
[10:33] <StevenK> mpt: I've already been convinced. I just need more JS knowledge.
[10:34] <mpt> k
[10:51] <wgrant> Ah, good, so I invoked mpt correctly, and shall not incur too much of his wrath.
[11:49] <jtv> stub: I wonder if garbo should report how many iterations and “items” a job got through before being killed.  Nice to know if we're making progress, and whether a job is still needed.
[11:50] <stub> jtv: Sounds useful. Would need to be in DBLoopTuner but that is fine.
[11:51] <jtv> Yeah.
[11:51] <wgrant> stub: Can we abolish database/schema/pending?
[11:53] <matsubara> danilos, hey there, the script that loads oops into the oops-tools database caught up during the weekend and those SMS oopses should now be available for viewing
[11:55] <stub> wgrant: Replacing it with what?
[11:57] <wgrant> stub: Well, it seems to have been used roughly twice in the last two years.
[11:57] <stub> wgrant: I guess it can go - nothing in there at the moment that is useful
[11:57] <wgrant> It should at least be emptied out.
[11:58] <wgrant> Nothing in there is useful now, and I don't really think there's much of a case to put stuff in there.
[11:58] <stub> wgrant: yer. Will need to find somewhere for templates etc. for data migration type scripts. That is going to happen more and more with fastdowntime.
[11:58] <wgrant> That's true.
[11:58] <lifeless> jamesh: https://code.launchpad.net/~lifeless/storm/wsgi closes the loop
[11:58] <wgrant> Nothing in there deserves to stay, but I'm not sure if the directory itself should...
[12:01] <danilos> matsubara, cool, thanks
[12:02] <matsubara> danilos, you're welcome
[12:21] <wgrant> rvba: I think those two branches look fine.
[12:21] <wgrant> rvba: It's hard to say for sure, but the test changes look pretty sane.
[12:21] <rvba> wgrant: Okay.  Thanks for looking at it again.
[12:40] <wgrant> stub: Do you recall why our store names include the config section name? We never change it outside tests...
[12:42] <wgrant> I guess it may have been a WHUI attempt to permit usage of multiple concurrent configs.
[12:43]  * wgrant deletes it to see what breaks.
[12:44] <wgrant> Ah, of course. It's the only way to get the section name into LaunchpadDatabase.
[12:44] <wgrant> Unless I just fix it to always use canonical.config.dbconfig...
[12:44] <wgrant> Which it already does, because the other case is WHUI.
[12:51] <jtv> hey benji—I've got a gigantic lint branch up for review.  Not expecting anyone to read it in full, but since I don't see how it could be Q/A'ed, I'd prefer not to make it self-reviewed as well.
[12:51] <benji> jtv: sure, I'll take a look
[12:51] <jtv> thanks
[12:53] <wgrant> cjwatson: There are some complexities to exporting changeOverride, sadly.
[12:53] <wgrant> cjwatson: Permissions are one difficult bit.
[12:53] <wgrant> Another is getting the same source+binaries behaviour.
[12:58] <cjwatson> I looked at permissions and that part looked OK; launchpad.Edit permissions on SPPH/BPPH already look sane
[12:58] <cjwatson> i.e. basically archive owner with a few warts
[12:58] <stub> wgrant: I suspect the code you are looking at was assembled (I won't say 'designed') before canonical.config.dbconfig existed.
[12:59] <adeuring> bigjools, wgrant: I want to create a set of BinaryPackageBuilds for all possible values of BuildStatus. When I then create a +builds view, the resultset of the view is sometimes empty: http://paste.ubuntu.com/693006/ I get empty results set for the statuses built, building, pending. Any suggestions?
[12:59] <cjwatson> wgrant: and surely the source+binaries behaviour could be handled by the caller?
[12:59] <cjwatson> I would've thought lib/lp/soyuz/scripts/changeoverride.py could basically be transmogrified into an API script
[12:59] <wgrant> cjwatson: Probably, yes, assuming the relevant methods on SPPH are exposed.
[13:00] <wgrant> SPPH.getPublishedBinaries or whatever it is.
[13:00] <wgrant> cjwatson: The API's SPPH.requestDeletion does source+binary implicitly, but that makes less sense for overrides, as they may differ.
[13:01] <cjwatson> requestDeletion's implicit behavior is annoying; it's too constrained to implement lp-remove-package.py over the API
[13:01] <cjwatson> we need to do things like deleting individual NBS binaries, deleting only a source package when its binaries have been taken over by another package, ...
[13:01] <wgrant> stub: Possibly. Since nothing seems to use LaunchpadDatabase or a DBPolicy with anything other than the current section, I'm hoping this ec2 run will succeed. Then I can move ZTM's remaining user handling crap into DBConfig, and it can finally die.
[13:02] <wgrant> cjwatson: Indeed.
[13:02] <wgrant> cjwatson: I forget if we expose BPPH.requestDeletion.
[13:02] <cjwatson> and yes, only being able to overrides for everything in a source package at once would be so limiting as to be useless
[13:02] <wgrant> cjwatson: But do you ever want to delete a source without deleting binaries from that source?
[13:02] <cjwatson> *do overrides
[13:03] <cjwatson> wgrant: only if those binaries have been taken over by some other source.  I'm never sure whether LP will notice that correctly on removal
[13:03] <benji> did the +activereviews page change?  The organization looks different -- and less useful :(
[13:03] <cjwatson> lp-remove-package normally does seem to, admittedly
[13:03] <wgrant> cjwatson: We identify BPPHs for BPRs that were built from a build for the SPR that's being deleted.
[13:03] <cjwatson> the other use case for deleting binaries is when they fail to build (even if they aren't actually NBS) and we don't want to ship unsupportable stuff
[13:03] <wgrant> cjwatson: Names aren't used at all.
[13:04] <cjwatson> OK, that would be safe
[13:04] <wgrant> Yeah, deleting binaries I can understand, and is easily supportable.
[13:04] <wgrant> Deleting sources without their binaries would require slightly more creative API construction.
[13:04] <cjwatson> I can see why you might not want to expose API methods that produce orphaned BPRs
[13:04] <wgrant> Exactly.
[13:05] <benji> oh! it's because it doesn't know who I am, I need to log in
[13:06] <jtv> benji: those are two independent statements, there should be no comma, between, them, how are you, I am fine?
[13:07] <benji> jtv: this is true; my IRC copy editor is on vacation today so you'll have to deal with small imperfections
[13:07] <deryck> Morning, all.
[13:08] <jtv> benji: I see.  Now compare your case to deryck's, who seems to be verbless at the moment.
[13:08] <jtv> Hi deryck.  :)
[13:08] <deryck> hi
[13:08] <benji> jtv: I guess he accidentally a word.
[13:08] <deryck> Not sure I get the verbless comment. ;)
[13:10] <jtv> deryck: I was being a pedantic prick with benji, and when he made up a semi-plausible excuse, I started using you as a bad example instead.  :)
[13:10] <jtv> The “verbless” refers to the absence of verbs in “morning, all.”
[13:11] <deryck> ah
[13:11] <cjwatson> Ah, that invented Victorian grammar. :-)
[13:12] <deryck> Arguments about language on the Internet always end well. ;)
[13:13] <cjwatson> I'll just cite http://languagelog.ldc.upenn.edu/nll/?p=3338 and leave it at that :-)
[13:15] <deryck> heh
[13:30] <deryck> abentley, hi.  we're back to mumble this week.
[13:37] <jml> cjwatson: I stopped reading Language Log ages ago when it went through a period of being a blog about how badly the BBC do science reporting. I'd forgotten how good it can be.
[14:51] <jcsackett> sinzui: available to mumble?
[14:51] <sinzui> yes.
[14:52] <jcsackett> excellent.
[15:10] <abentley> deryck: chat?
[15:10] <deryck> abentley, sure.  let me grab coffee and then meet you in mumble.
[15:10] <abentley> deryck: cool.
[15:17] <lifeless> sinzui: morning.
[15:17] <sinzui> hi lifeless
[15:18] <lifeless> sinzui: did you see the rollback of subscription-changes-on-toggling-private-flag-in-bugs ?
[15:18] <sinzui> I did.
[15:18] <lifeless> sinzui: there is some confusion about whether a) wallyworld was confused or b) I was confused about the design
[15:19] <sinzui> I told wallyworld that OEM has direct subscriptions removed so I thought he did the right thing
[15:19] <lifeless> sinzui: I promised him I would touch base with you directly to clear things up
[15:19] <lifeless> sinzui: do you mean they do the following with the old code: a) make private; b) remove the resulting direct subscriptions ?
[15:19] <sinzui> We can cut that feature and land the structural subscription part only. OEM can report a bug if they believe the behaviour is still broken
[15:20] <sinzui> lifeless, OEM removes anyone they do not know to be associated with their projects
[15:20] <sinzui> It has nothing to do with direct/indirect. It is simply a matter of disclosing info
[15:21] <lifeless> sure, but the indirect-become-direct behaviour is a part of the story
[15:21] <lifeless> in that it requires an explicit act to become a subscriber without that
[15:21] <lifeless> [for a non-project-person]
[15:23] <lifeless> sinzui: anyhow, the result of ditching -all- direct subscribers is that we can't have symmetrical code as we designed : we would have to special case according to increasing or decreasing sensitivity
[15:23] <sinzui> Sure, but disclosing private/secure information costs millions, and users who cannot see who is subscribed (api/email) are trusting Lp to do the right thing
[15:24] <lifeless> agreed on the result of a mistake, but we're talking about the case of taking a bug that was open, private, which clearly means that the info in it was public at one point.
[15:25] <lifeless> such super sensitive things should be created private to start with, so there is no chance of disclosure, and the transition code becomes irrelevant
[15:25] <sinzui> But the subsequent private conversation was never public
[15:25] <sinzui> This case might better be solved by bug linking
[15:25] <lifeless> the transition code flow we discussed was designed for dealing with private-security becomes private-non-security, and vice verca.
[15:26] <lifeless> yes, I think a private discussion about a bug reported by a person outside the project should be done with a lnked private bug
[15:27] <lifeless> is there an option to say 'bugs on this project cannot be filed open' ?
[15:27] <sinzui> As I wrote to wallyworld, we will only deal with structural subscriptions (remove the direct changes) so that the common case works as users expect (and Lp claims to do)
[15:27] <lifeless> ok
[15:28] <lifeless> I think I know what that means, and will look over someones shoulder when v2 of it goes up :)
[15:28] <lifeless> to make sure I understand, so I have a clue and don't trigger a late rollback :)
[15:29] <sinzui> lifeless,  was also cut the unsubscribe-security-contact-bug-supervisor rule when a bug because public/non-security because there was disagreement. I just want to land what we agree solves most of the problem
[15:30] <lifeless> sinzui: oh, thats surprising.
[15:30] <lifeless> sinzui: I agree on landing the uncontentious bits
[15:30] <lifeless> sinzui: but am also curious what the disagreement was
[15:31] <sinzui> wgrant believed the security contact may want to follow the conversation after the issue was made non-security, or even choose to re-secure it if it is decided the change was a mistake
[15:31] <lifeless> btw, I have a sneaking suspicion we might be able to address some performance issues if we materialize subscriptions (like we do teamparticipation). IMBVW
[15:32] <sinzui> wgrant, is planing for that :)
[15:32] <lifeless> sinzui: (re-securing - a test that they receive the 'it is now public' notification would cover that (and be a solid expectation too))
[15:32] <lifeless> sinzui: following-the-conversation : tough. :)
[15:33] <lifeless> sinzui: they can subscribe when they get the notification that says 'xyz is now public and you are no longer subscribed'
[15:33] <bigjools> lifeless: 1. wth are you still doing awake, and 2. any objections to me throwing the management rabbit  plugins in the LP PPA?
[15:33] <sinzui> lifeless,  yes, ensuring notification may be the correct way to handle this.
[15:33] <lifeless> bigjools: 1. Cynthia. 2. No objections.
[15:33] <bigjools> copy!
[15:35] <lifeless> bigjools: btw, I think one of the bugs confused you
[15:35] <bigjools> quite possibly
[15:35] <bigjools> write better descriptions then :)
[15:35] <lifeless> bigjools: the ..139 bug is about snarfing issues from *rabbit*, not longpoll
[15:35] <lifeless> the ...136 bug is about issues from longpoll.
[15:36] <bigjools> I realised that much
[15:36] <lifeless> so how is 136 a pre-req for 139 ?
[15:36] <bigjools> did I get them the wrong way around?
[15:36] <lifeless> they are unrelated
[15:36] <bigjools> hmm
[15:37] <lifeless> two separate services, both need tell-us-what-went-wrong integration of some sort, to avoid a human going and looking at log files.
[15:38] <bigjools> yer right, I'm confused. My bad.
[15:38] <lifeless> no worries :)
[15:38] <bigjools> the management interface is quite neat BTW
[15:38] <lifeless> cool
[15:38] <bigjools> I am poking messages through and the web page updates almost instantaneously :)
[15:53] <lifeless> james_w: https://launchpad.net/testr_recipe is a 404
[15:53] <lifeless> james_w: the url is on your pypi page
[15:57] <bigjools> looks interesting that
[15:59] <james_w> well where did that go then?
[15:59] <james_w> I wonder if I ever actually registered it
[15:59] <james_w> ah https://launchpad.net/testr-recipe
[16:13] <stub> lifeless: https://code.launchpad.net/~wallyworld/launchpad/branch-privacy-trigger/+merge/75189 might interest, as it is a DB patch that should land with code changes (the tests for the trigger behaviour)
[16:48] <gmb> jtv: Could you take a look at https://answers.launchpad.net/launchpad/+question/171451 for me? I don't know the answer.
[16:48] <gmb> this one, also: https://answers.launchpad.net/launchpad/+question/171450
[16:49] <bigjools> where do I set the default reviewer for a project?
[16:49] <bigjools> well, trunk branch
[16:50] <bigjools> nm found it eventually
[17:36] <sinzui> jcsackett, do you have a moment to discuss http://pastebin.ubuntu.com/693202/ on mumble?
[17:37] <jcsackett> sure.
[17:58] <timrc> off hand is there an easy way to get get a bug object via a .getBugByURL()-like API call :)?
[18:07] <sinzui> timrc, the lp object has a top-level bug collection. You only need the id from the URL
[18:08] <sinzui> lp.bugs[284141] will get bug #284141 regardless without need of knowing the projects it affects
[18:08] <_mup_> Bug #284141: PPA upload permissions should be decoupled from its team membership. <lp-soyuz> <ppa> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/284141 >
[18:08] <timrc> sinzui, okay that can work
[18:08] <timrc> sinzui, thanks
[18:37] <nigelb> jtv: Hey, do you know why your MP (the one linked on your blog post) turns up with an empty diff?
[18:37] <nigelb> s/your/Launchpad
[18:37] <nigelb> That's probably going to be confusing for everyone who clicks through :)
[18:55] <nigelb> sinzui: Heh, after much fun with regressions, I finally fixed the bug title feature :-)
[18:55] <nigelb> s/fun/fail/g works as well.
[18:57] <sinzui> nigelb, I saw. Thank you for following up
[18:58] <nigelb> sinzui: Embarassing mistakes. But learned YUI testing well now :-)
[18:59] <sinzui> nigelb, You have nothing to be embarrassed about. Now wrongly closing 10,00 bugs in production does cause some embarrassment.
[18:59] <nigelb> ...wow
[19:23] <flacoste> nigelb: yes, now 4 years since that event, but sinzui is still talking about it :-)
[19:23] <sinzui> I was traumatised
[19:25] <sinzui> When I am described as "legendary", I think "what? Who knows me?", then I remember the 10,000 bugs.
[19:35] <nigelb> haha
[19:37] <nigelb> sinzui: I was traumatised with nightmares of wgrant stabbing me for making a bunch of revs undeployable :P
[19:39] <sinzui> nigelb, :)
[19:45] <nigelb> sinzui: I think someone new has more "fame" now with the accidental auto-sync that happened this cycle :P
[19:45] <sinzui> :)
[20:20] <lifeless> flacoste: hi; will be with you soon
[20:21] <flacoste> lifeless: no worries, working on the QBR stuff
[20:29] <lifeless> james_w: ah, should be simple to fix the pypi ref then :)
[20:30] <james_w> lifeless, already done
[20:30] <lifeless> james_w: I wanted to look at the code to see if you setup a run --parallel config
[20:30] <lifeless> james_w: but IIUC you use the .testr.conf in the tree, so thats still manual ?
[20:30] <james_w> it also has code to generate .testr.conf
[20:31] <lifeless> cool!
[20:31] <lifeless> does it setup a parallel conf or the older run-without-knowing style?
[20:40] <james_w> it's old
[20:48] <lifeless> if you have a look at testtools .testr.conf, or even testrepositories itself, you can see the changes quite easily.
[20:48] <lifeless> should I file a bug ?
[21:49] <james_w> lifeless, go ahead
[21:52] <jelmer> 'morning lifeless
[21:53] <nigelb> morning... wait a minute.
[21:53] <nigelb> jelmer: aren't you somewhere in Europe? :)
[21:54] <jelmer> lifeless: you approved one of my bzr-search branches and spoke the ever legendary word "doit", but you own lp:bzr-search; is there any chance you can merge it for me or change ownership to ~bzr/~bzr-search?
[21:54] <lifeless> jelmer: no I don't :)
[21:55] <jelmer> lifeless: :-) thanks
[21:56] <jelmer> nigelb: Yeah :-) I think it's evening for both of us, right?
[21:56] <nigelb> I've passed the point where I can call it evening ;)
[21:57] <nigelb> I still haven't slept so I'll claim evening :P
[21:58] <poolie> sleep well, nigel
[21:58] <poolie> and sleep enough
[21:58] <nigelb> :)
[21:59] <nigelb> Thanks poolie!
[23:22] <lifeless> wgrant: reviews plox
[23:56] <lifeless> wgrant: https://code.launchpad.net/~lifeless/python-oops-wsgi/timeline/+merge/75960 https://code.launchpad.net/~lifeless/python-timeline/wsgi/+merge/75959
[23:58] <wgrant> lifeless: Sorry, on a call right now.
[23:58] <lifeless> kk


[07:23] <tjaalton> is there an ETA for the .27-3 kernel?
[14:32] <cropalato>  sorry for the newbie question. Where can some one get info about become a kernel developer?
[14:50] <CarlFK> smb_tp: amd64 - if i installed just that (so not apps/modules) would it help any?
[14:50] <CarlFK> i wouldn't have network, and maybe even no shell, so I wouldn't be able to upload logs
[14:51] <CarlFK> but I would be able to see if it pauses at the same point
[14:51] <smb_tp> CarlFK, It is just the same code just amd64 version for some others to test. So I don't expect a different behaviour.
[14:51] <CarlFK> figured as much
[14:52] <smb_tp> CarlFK, Sure you can try. If that works, then maybe there is a 32/64 bit problem lurking
[14:56] <CarlFK> smb_tp: cat /proc/cpuinfo model name	: AMD Turion(tm) 64 X2 Mobile Technology TL-60
[14:56] <CarlFK> dpkg: error processing linux-image-2.6.27-3-generic_2.6.27-3.3smb5_amd64.deb (--install):
[14:56] <CarlFK>  package architecture (amd64) does not match system (i386)
[14:56] <CarlFK> guessing it is looking at the current .. um... os
[14:58] <smb_tp> CarlFK, Oh yeah. It looks at you installed architecture. You can force it but all your binaries are 32 bit so this probably won't work
[14:59] <CarlFK> all we need is for it to boot, not ... um;  be usefull, right ?
[15:01] <smb_tp> CarlFK, At some point the ramdisk takes over and that would be 32bit stuff (i don't think there is biarch support), so it might not get very far...
[15:04] <CarlFK> um.. magic happend
[15:05] <CarlFK> carl@dv67:~$ uname -a
[15:05] <CarlFK> Linux dv67 2.6.27-3-generic #1 SMP Mon Sep 8 22:51:51 UTC 2008 x86_64 GNU/Linux
[15:05] <CarlFK> shell, network...
[15:05] <smb_tp> CarlFK, Oh right, should probably have more confidence in biarch support then. :)
[15:06] <CarlFK> [    0.000000] Command line: root=UUID=270934eb-b4c5-4f17-87e4-8ebea9d98ed3 ro highres=off nohz=off vga=6
[15:06] <CarlFK> no pauses - what params do you want ?
[15:06] <smb_tp> CarlFK, ok, that combination has worked with i386 kernel too
[15:07] <CarlFK> yes
[15:07] <smb_tp> CarlFK, without "highres=off nohz=off" with "apic=debug debug"
[15:08] <smb_tp> CarlFK, Only need to know whether this stops or not. Logs/dmesg only if it happens to _not_ pause
[15:08] <CarlFK> ok
[15:08] <CarlFK> what is this biarch support?
[15:09] <CarlFK> it paused. at least it isn't a surprise :)
[15:10] <smb_tp> Ok, so in this case i don't need anything more at the moment
[15:22] <doko> rtg, BenC: apparently neither gcc-4.1 and gcc-4.2 is needed to build kernels in intrepid on community ports. is this correct?
[15:24] <rtg> doko: dunno. I've yet to look at the community ports packages.
[15:24] <rtg> doko: Ben is on vacation this week.
[15:33] <timbba> Hello. I have Ubuntu Hardy kernel 2.6.24-21. This kernel is buggy and I know that > 2.6.25 kernels work with my machine. How can I get newer kernel to Hardy and all necessary packages (linux-ubuntu-modules, linux-headers and linux-image)? Some packages are missing from Intrepid and PPA  repositories..
[15:34] <CarlFK> timbba: not 'best' but good enough: wget http://people.ubuntu.com/~smb/bug254668/linux-image-2.6.27-3-generic_2.6.27-3.3smb5_i386.deb  dpkg -i <that>
[15:34] <rtg> timbba: try the kernel PPA at http://ppa.launchpad.net/kernel-ppa/ubuntu
[15:35] <timbba> I have tried already PPA kernels.. there are no ubuntu-modules packages, so my wifi isn't working
[15:36] <rtg> timbba: 2.6.27 has LUM folded into the package, so LUM is no longer needed.
[15:36] <timbba> So I can get kernel packages, but how about those modules for my wifi card (Zydas based)
[15:36] <rtg> timbba: if they aren't in the 2.6.27 package, then they are not supported.
[15:38] <timbba> oh god.. so nobody can't get Zydas wifi to work?
[15:38] <rtg> I can't remember. you'll have to look in the kernel source for 2.6.27-rc5
[15:39] <amitk> timbba: what card is it?
[15:40] <timbba> edup something :)
[15:41] <timbba> timbba@media-timbuktu ~ $ dmesg | grep zd
[15:41] <timbba> [   32.583130] zd1211rw 2-2:1.0: eth0
[15:41] <timbba> [   32.583145] usbcore: registered new interface driver zd1211rw
[15:41] <timbba> [  165.221220] zd1211rw 2-2:1.0: firmware version 4605
[15:41] <timbba> [  165.261183] zd1211rw 2-2:1.0: zd1211 chip 079b:004a v4330 high 00-60-b3 AL2230_RF pa0 g----
[15:41] <amitk> timbba: that doesn't help a lot
[15:41] <timbba> timbba@media-timbuktu ~ $ lsusb
[15:41] <timbba> Bus 002 Device 002: ID 079b:004a Sagem
[15:42] <amitk> timbba: is it in http://linuxwireless.org/en/users/Drivers/zd1211rw/devices?
[15:43] <timbba> yes it is: Sagem  	XG760A  	zd1211  	079b  	004a  	AL2230
[15:47] <amitk> timbba: then please file a bug in launchpad describing how the device is not working. From a quick glance, it looks like intrepid's 2.6.27-based kernel should have support for it. No separate modules needed.
[15:48] <timbba> it doesn't find the firmware.. that is the problem. The card itself is recognized
[15:49] <CarlFK> timbba: that would be the "describing how the device is not working"
[15:49] <timbba> ok :)
[15:49] <amitk> timbba: 'ls -l /lib/firmware'
[15:49] <timbba> how about copying firmware from previous kernel?
[15:50] <amitk> timbba: exactly... :)
[15:50] <timbba> oh.. I have already removed 2.6.27 kernel so there is just...
[15:50] <timbba>  ls -la /lib/firmware/
[15:50] <timbba> total 12
[15:50] <timbba> drwxr-xr-x  3 root root 4096 2008-09-09 17:21 .
[15:50] <timbba> drwxr-xr-x 15 root root 4096 2008-09-09 17:20 ..
[15:50] <timbba> drwxr-xr-x  3 root root 4096 2008-09-02 05:51 2.6.24-21-generic
[15:51] <timbba> but I will give it a try.. I'll copy the firmware after I have reinstalled the kernel... Let's see what happens
[15:52] <amitk> rtg: I forget why we moved from /lib/firmware/<kernel version>/* to /lib/firmware/*. And do our packages handle that transition?
[15:55] <rtg> amitk: Ben's contention was that firmware didn't change enough to bother keeping separate copies per ABI. For most drivers that's probably true. I assume upgrades are handled, but I've not a dist-upgrade in a bit (since FireFox didn't work on some web sites, I went back to Hardy)
[16:03] <amitk> probably a good idea
[17:01] <pgraner> Hello Everyone... I'm standing in for BenC today (he is on holiday) for the Weekly Kernel IRC Meeting.
[17:02] <pgraner> ogasawara: Can you tell us how we are looking wrt to 2.6.27?
[17:03] <pgraner> [Link Regressions https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=regression-2.6.27 ]
[17:03] <ogasawara> pgraner: from my point of view I think we are looking quite good with the move to 2.6.27
[17:04] <ogasawara> pgraner: there are the noted list of regressions (link above) but I have gotten good feedback from a handful of those bugs that they will be resolved with the next kernel we release
[17:04] <pgraner> Looks like we are sitting at about 30 regressions, with most of them having fixes upstream or plans to get them fixed soon.
[17:04] <ogasawara> pgraner: for example the suspend/resume issues should hopefully go away
[17:04] <pgraner> ogasawara: great
[17:05] <ogasawara> pgraner: some of the boot failures will look to also be resolved
[17:05] <pgraner> ogasawara: we are sitting at about 70 bugs fixed by 2.6.27
[17:05] <pgraner> [LINK https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.tag=fixed-2.6.27]
[17:05] <ogasawara> pgraner: yup, so if we stuck with 2.6.26 we'd have to consider most of those unresolved then
[17:06] <pgraner> So far the feeling of the kernel team is that there are no real show stoppers and that we are on track for GO decision on the 14th per [LINK https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan]
[17:07] <pgraner> rtg: is looking at RaLink RT2860 LP# 210725 issues
[17:07] <pgraner> s/rtg:/rtg/
[17:07] <tjaalton> when will -3 be uploaded?
[17:08] <rtg> tjaalton: as soon as -rc6 is in the can.
[17:08] <tjaalton> rtg: ah, thanks
[17:09] <pgraner> anyone from the kernel team have anything to add?
[17:09] <rtg> pgraner: I think it's Stefan thats looking inti the RaLink driver stuff. He built a DKMS package IIRC.
[17:10] <pgraner> rtg: ah, correct for some reason I had you down for it. I guess I'm trying to give you too much to do...
[17:10] <rtg> I'm going to start putting some of the DKMS packages on the kernel PPA, so that they are semi-official
[17:10] <pgraner> correction smb_tp will be looking at the RaLink RT2860 LP# 210725 issues
[17:11] <pgraner> Any questions?
[17:12] <pgraner> Ok I guess we'll call this meeting over for today. If anyone has questions or follow up questions you can post them here and I will answer or you can email me at<EMAIL_ADDRESS>[17:12] <pgraner> thanks!
[17:16] <johanbr> I've been bitten by a usb bug which has existed upstream since 2.6.25 and which prevents me from connecting to my Motorola phone. A patch exists, but is not yet accepted upstream. Is there any chance this patch could go in?
[17:16] <laga> johanbr: https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/263217 ?
[17:19] <johanbr> laga: Probably not. 2.6.24 works fine for me, but later kernels don't, which is the opposite of what's stated in that bug report.
[17:20] <johanbr> There's a discussion archived at http://permalink.gmane.org/gmane.linux.usb.general/8532
[17:21] <laga> there's a test PPA
[17:22] <laga> maybe you can try that kernel
[17:22] <laga> the problem sounds familiar ;)
[17:25] <johanbr> I doubt it'll work, but I could try.
[17:54] <Bor_Ed> evening. is it too late to request v4l-dvb/mantis driver to be included for intrepid yet? the driver gives ~270 dvb card and stick drivers available and builds currently without issues on 8.10
[17:58] <laga> 270 *new* dvb boards?
[17:58] <CarlFK> Bor_Ed: is 270 a count or a model number?
[17:59] <Bor_Ed> module count
[17:59] <Bor_Ed> including frontend, jingles and bells
[18:00] <laga> and how is it different from the v4l-dvb tree included in the current kernel?
[18:00] <Bor_Ed> doesn't support the dvb-c or dvb-t devices around europe that well
[18:01] <laga> so you're basically suggesting that the kernel devs should include regressions? ;)
[18:02] <Bor_Ed> well, I was pointed to here from #ubuntu-devel since the driver level stuff belongs to you guys (I heard, no pun)
[18:03]  * laga is not a kernel dev, just for the record
[18:03] <Bor_Ed> I read that mantis is getting to v4l-dvb kernel tree but not in time for release of 8.10
[18:03] <laga> but as one of the mythbuntu guys, i'm interested in better DVB support
[18:04] <Bor_Ed> I had to fetch and compile the mantis tree but it worked as a charm on first trial on stock intrepid with build-essential&the rest of the deal
[18:04] <laga> if it's not even in v4l-dvb yet then changes are probably slim
[18:04] <laga> maybe it'd be possible to cherry-pick certain (new) device drivers
[18:05] <laga> but that's just my opinion ;)
[18:05]  * Bor_Ed is long time linux user and spotted the lack of feat in current ubu... servers still stay on debian, sorry :D
[18:06] <Bor_Ed> afaik, mantis is getting merged to v4l-dvb at some point in the future, the prob is though that currently v4l-dvb kernel driver doesn't support much more than couple of dvb-s decoders
 and ati binary driver still refuses to build so I could have DRI </RANT>
[20:09] <BenB> hi... I'm trying to install the latest Linus kernel. I have the kernel compiled, but can't get an initrd generated.
[20:09] <BenB> I would really like to avoid make-kpkg and creating and installing deb packges. lacking another way that I knew of, I tried that, and it doesn't work....
[20:10] <BenB> first,  the -append-kernel-version freaks out on the -rc5 plus my -foo
[20:10] <BenB> so, I dropped that
[20:11] <BenB> second, it aborts with "arch/xen/ not found". well, yes, that dir does not exist in latest kernels. why does it have to try to build a Xen kernel? I just want an initrd!
[20:11] <BenB> so, I pass --arch "x86_64", but then it fails with "I do not know where the kernel image goes to [kimagedest undefined] ... Please specify a subarch, and try again.."
[20:11] <BenB> I am stuck
[20:12] <BenB> nevermind the last one. I accidentially passed "x86" as arch
[20:13] <BenB> it still trips over the -rc5, though, even without --append-kernel-version
[20:14] <BenB> I had to clean everything and rebuild from scratch. that'll take almost 1h *sigh*
[22:06] <BenB> is there any way to create an initrd without make-kpkg? that takes 20 minutes for me *without* any code or config changes. i.e. first make-kpkg takes 1h20m, second (directly afterwards) takes half an hour (!). creating in initrd takes seconds (e.g. on suse).
[22:07] <mjg59> BenB: mkinitramfs
[22:07] <BenB> mjg59: thanks!
[22:07] <BenB> (I wish I'd have known that 2 hours earlier)