[23:07] <bluelight> Hi everyone  I'm new and I don't know anything, so I don't know what to ask. What is the first thing I should ask ?


[03:52] <fabbione> doko: ping?
[03:53] <fabbione> bash completion in 3.1 is broken
[03:53] <fabbione> ssh trised: -e expression #1, char 20: unterminated `s' command
[03:53] <fabbione> der-g7
[03:53] <fabbione> that's the result of ssh tri<tab>
[03:53] <fabbione> that completes to trider-g7


[00:00] <mwhudson> thumper: it's all implemented but as up until the rollout, branches deleted on production would create deletion jobs scheduled for right now, it's not running yet
[00:01] <thumper> mwhudson: so what should we mark the spec?
[00:01] <thumper> done?
[00:01] <mwhudson> thumper: i guess the "deployment" status it's in is about right
[00:01] <mwhudson> thumper: move it to 2.2.8 and i'll set it to implemented when the cronscript is set up?
[00:02] <thumper> ok
[00:07] <mthaddon> anyone able to review https://code.edge.launchpad.net/~mthaddon/lp-production-configs/bug-287304-staging-logrotate/+merge/9097 for me?
[00:09] <pkern> All those private branches ;-)
[00:10] <wgrant> Indeed :(
[00:10] <wgrant> Fortunately all new ones are public.
[00:10] <Chauncellor> Congrats on the open source! :)
[00:11] <Chauncellor> I'm very happy
[00:13] <mwhudson> pkern: a lot of the old branches are stacked on old-format versions of trunk, and as they're mostly merged anyway, they're probably not very exciting
[00:13] <mwhudson> and yes, you're not getting to see our production config :)
[00:14] <mwhudson> mthaddon: done
[00:14] <mthaddon> thx mwhudson
[00:24] <blueyed> Is Karmic supported soon as a dev platform? I've gotten various errors while doing the rocketfuel-setup.
[00:25] <lifeless> thumper: I think you may be confused about bug 390563
[00:25] <ubot3> Malone bug 390563 in bzr "overly large delta creation when fetching from 2a repositories" [Critical,In progress] https://launchpad.net/bugs/390563
[00:25] <wgrant> blueyed: LP needs Python 2.4, which Karmic doesn't love. A port to newer Pythons is in progress.
[00:25] <thumper> lifeless: probably
[00:25] <lifeless> thumper: its not affecting lp any more, not since you cherrypicked the first stage fix weeks ago
[00:25] <thumper> lifeless: ok, so fix released for us then
[00:26] <lifeless> there will be a follow on patch, but its corner cases, not common, and you can just wait for a release for that.
[00:33]  * mwhudson wonder if there's anything we can really do to make 'make schema' less of a hog
[00:33] <wgrant> mwhudson: Please please please.
[00:45] <Daviey> I was _more_ suprised how much the bzr co process took more tbh
[00:45] <Daviey> On both RAM and cpu
[00:46] <lifeless> thats a bug
[00:47] <lifeless> and filed as such
[00:47] <lifeless> (in bzr)
[00:47] <Daviey> oh :)
[00:48] <lifeless> bzr does much better streaming, but the expected load was high so we made lp checkouts use http for the release period
[00:48] <lifeless> mwhudson: speaking of which, should we disable the hot spot now?
[00:49] <mwhudson> i guess so
[00:49] <wgrant> The HTTP checkout really didn't work too well.
[00:51] <lifeless> wgrant: it did
[00:51] <lifeless> wgrant: we had a single component in the DC fail, but that was the same as failed saturday so was fast to fix
[00:51] <wgrant> It lightened the load, sure.
[00:51] <wgrant> But I mean for the users.
[00:51] <lifeless> wgrant: and after that we spiked up to *time times* our normal request rate
[00:51] <lifeless> s/time/ten/
[00:51] <wgrant> It's reasonable that you did it.
[00:52] <wgrant> Not bad.
[00:52] <lifeless> now, many of those are probably due to the [major] bugs in bzr to do with 2a and http
[00:52] <lifeless> *I* think we would have handled it on bzr+ssh with no problems
[00:53] <lifeless> but, that wasn't load tested,and we had load tested http
[00:54]  * wgrant will be interested to see how swift a checkout is over bzr+ssh.
[00:58] <mwhudson> it took me ~an hour last time i did it
[01:00] <Daviey> wget + tarball would be even quicker :)
[01:00] <mwhudson> thumper: after all that, i'm not sure stub's concerns are valid
[01:00] <thumper> mwhudson: really?
[01:00] <lifeless> mwhudson: an hour? that seems long
[01:00] <mwhudson> (but i've beefed up my tests)
[01:01] <thumper> mwhudson: stub's concerns seemed entirely reasonable to me, and I'd be kinda surprised if they were off
[01:01] <mwhudson> lifeless: i was getting ~40 kbytes/s
[01:01] <thumper> I think that the tests may have problems duplicating multiple database connections
[01:01] <mwhudson> thumper: i'm surprised too
[01:01] <mwhudson> thumper: the default isolation level is READ COMMITTED for scripts though
[01:02] <mwhudson> thumper: and given that i don't write to the db, i fail to see how that is different from AUTOCOMMIT
[01:02] <mwhudson> the storm cache issue i'm less clear on, but i can't make anything break because of it
[01:03] <thumper> hmm
[01:03] <mwhudson> thumper: actually, it's clear the storm cache doesn't matter
[01:03] <thumper> I'm going to have to defer to stub on the connection stuff
[01:03] <mwhudson> thumper: we never create a Branch object
[01:03] <thumper> ah ha
[01:03] <thumper> cunning plans
[01:03] <mwhudson> well
[01:03] <mwhudson> lucky
[01:06] <mwhudson> also
[01:06] <mwhudson> 2009-07-24 00:06:32 INFO    '/~sabdfl/applets/wabble/' -> 'http://localhost:8080/~sabdfl/applets/wabble/' (0.001703s, cache: MISS)
[01:06] <mwhudson> 2009-07-24 00:06:39 INFO    '/~sabdfl/applets/wabble/' -> 'http://localhost:8080/~sabdfl/applets/wabble/' (0.000180s, cache: HIT)
[01:07] <mwhudson> so not sub ms for hits, but not bad
[01:07] <mwhudson> grr, not sub ms for misses
[01:07] <mwhudson> (will be a bit slower in the dc i guess)
[01:07] <thumper> mwhudson: still better than 100 or 500ms
[01:07] <mwhudson> thumper: yes, definitely
[01:08] <mwhudson> also, in main.log:
[01:08] <mwhudson> [2009-07-24 12:06:32.534 NZST] branch-rewrite@launchpad_dev LOG:  statement: SELECT Branch.id, Branch.unique_name FROM Branch WHERE Branch.unique_name IN (E'~sabdfl', E'~sabdfl/applets', E'~sabdfl/applets/wabble', E'~sabdfl/applets/wabble/') AND Branch.private = false
[01:08] <mwhudson> which is nice an minimal, i think
[01:12] <lifeless> mwhudson: so thats 320kbits, whats your link capable of?
[01:13] <mwhudson> lifeless: what?
[01:13] <mwhudson> oh
[01:14] <mwhudson> most isps in nz don't limit you, it's determined by distance to exchange
[01:14] <mwhudson> i get 1 megabyte/s to nz.archive.ubuntu.com on good days
[01:14] <mwhudson> never internationally though
[01:14] <lifeless> so
[01:14] <lifeless> not today
[01:14] <lifeless> but we need to debug this
[01:15] <lifeless> the python DVCS eval had issues too, and we didn't figure it out
[01:15] <mwhudson> lifeless: maybe i'm just pessimistic, i don't really expect to get much more than that to london
[01:15] <mwhudson> (on good days i do, but not every day)
[01:17] <lifeless> mwhudson: it streams
[01:17] <mwhudson> lifeless: i meant, over any link
[01:17] <mwhudson> not bzr+ssh specicif
[01:18] <mwhudson> spm: guess what!  jelmer rebased dulwich again :)
[01:18] <lifeless> mwhudson: We should find out why you get that behaviou
[01:18] <lifeless> r
[01:18] <mwhudson> ok
[01:18] <mwhudson> not now though
[01:19] <spm> mwhudson: do you think it'd be abuse of power if I suspend jelmer's launchpad account? just asking. no reason. hypothetically.
[01:20] <lifeless> jelmer: ^ :P
[01:25] <mwhudson> launchpad/bzr.dev builder seems to be working, yay
[01:31]  * mwhudson lunches
[01:31] <jelmer> spm: (-:
[01:32] <spm> jelmer: I was joking? :-P
[02:11] <matsubara> bug 666
[02:11] <ubot3> Malone bug 666 in malone "can't file a bug on Ubuntu" [Medium,Invalid] https://launchpad.net/bugs/666
[02:11] <mup> Bug #666: can't file a bug on Ubuntu <Launchpad Bugs:Invalid> <https://launchpad.net/bugs/666>
[02:11] <mup> Bug #666: can't file a bug on Ubuntu <Launchpad Bugs:Invalid> <https://launchpad.net/bugs/666>
[02:11] <mup> Bug #666: can't file a bug on Ubuntu <Launchpad Bugs:Invalid> <https://launchpad.net/bugs/666>
[02:12] <thumper> we shouldn't have two bots here :)
[02:12] <mwhudson> haha
[02:12] <matsubara> yeah, I vote for keeping mup and let ubot3 go
[02:56] <mars> mwhudson, we are on AMI launchpad-ec2test11 now?
[02:56] <mwhudson> mars: i think so
[02:57]  * mars watches the script blow up again
[02:57] <mars> we really need a library for this stuff
[02:59] <EdwinGrubbs> jml: ping
[02:59] <mars> EdwinGrubbs, I think he is on leave today
[03:01] <EdwinGrubbs> mars: that's sad
[03:01] <EdwinGrubbs> thumper: ping
[03:02] <thumper> EdwinGrubbs: hi
[03:03] <mwhudson> yes, jml shouldn't be allowed to go on leave
[03:03] <EdwinGrubbs> thumper: hi, I was wondering if you knew if people use the feature of the BranchPopupWidget where it will create a mirrored branch if you enter in a url with the hostname?
[03:04] <thumper> EdwinGrubbs: it was asked for, and implemented
[03:04] <thumper> personally I'm not a big fan of it
[03:05] <EdwinGrubbs> thumper: I'm in the process of converting all instances of the PopupWidget to use the ajax Picker, and I wanted to verify that I had to keep that functionality.
[03:06] <thumper> EdwinGrubbs: yes, I'd say keep it for now
[03:08] <mars> thumper, btw, found a bug in the Popup widget that links branches to bugs
[03:08] <mars> thumper, it returns a launchpad.dev URL from the AJAX request
[03:08] <thumper> mars: please file a bug :)
[03:08] <mars> besides that, works beautifully :)
[03:11] <EdwinGrubbs> thumper: do you know if there are any existing tests that exercise that feature? All the +linkbranch pagetests that I found just pass in the identifier for an existing launchpad branch.
[03:12] <thumper> EdwinGrubbs: the code team is very fond of unittests :)
[03:12] <thumper> EdwinGrubbs: I'm certain it'll be tested somewhere
[03:15] <mars> ironic that I just timed out three times in a row trying to view jml's branches page
[03:19] <mars> thumper, bug 403839
[03:19] <ubot3> Malone bug 403839 in launchpad-code ""Link to a bug report" feature returns a launchpad.dev URL" [Undecided,New] https://launchpad.net/bugs/403839
[03:19] <mup> Bug #403839: "Link to a bug report" feature returns a launchpad.dev URL <ui> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/403839>
[03:19] <mup> Bug #403839: "Link to a bug report" feature returns a launchpad.dev URL <ui> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/403839>
[03:19] <mup> Bug #403839: "Link to a bug report" feature returns a launchpad.dev URL <ui> <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/403839>
[03:19] <mars> eeewww
[03:19] <mars> bot barf
[03:21] <thumper> heh
[03:21] <thumper> mars: ta
[03:37]  * wgrant boggles.
[03:37] <wgrant> RC changes aren't having much luck this release.
[03:38] <wgrant> db-devel r8318 has another extra unintended change.
[03:38] <mars> another one?
[03:38] <wgrant> Yes.
[03:38] <wgrant> rocketfuel-get is broken again.
[03:40] <mars> odd, db-devel isn't listed on https://code.edge.launchpad.net/launchpad
[03:41] <mars> ah, it's just the mainline
[03:41] <wgrant> Right.
[03:42] <mars> as are you - that is two this release
[03:42] <wgrant> Yes. That doesn't normally happen, does it?
[03:42] <mars> thumper, ^ should we rc-unbreak rocketfuel-get?
[03:43] <mars> wgrant, no, this is quite odd
[03:43] <wgrant> I can't find an MP for that branch, so I am wondering if it showed up in the diff or not.
[03:44] <ajmitch> great, so I managed to popular bin/ by removing the i18n section in buildout.cfg which was giving me version conflicts on hardy
[03:45] <ajmitch> how is rocketfuel-get broken today?
[03:45] <wgrant> ajmitch: Same as last time.
[03:45] <mars> the same glitch as before snuck into a release-critical landing
[03:45] <wgrant> The fix was accidentally RC-reverted.
[03:46]  * ajmitch doesn't know what broke it last time
[03:47] <thumper> what's broken?
[03:47]  * wgrant kicks loggerhead.
[03:47] <wgrant> Ah, there we go.
[03:48] <mars> thumper, rocketfuel-get, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8318
[03:48] <wgrant> thumper: Observe http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8318
[03:50] <thumper> how'd that happen?
[03:50] <mars> no idea
[03:50] <mwhudson> wgrant: woops
[03:50] <mars> that is the second one I've seen this release though
[03:50]  * thumper shakes his head
[03:50] <thumper> I'm pleased I don't use the rocketfuel scripts :)
[03:51] <mars> both issues came in via db-devel rc landings
[03:51] <mars> which is quite strange
[03:51] <mwhudson> that's reverting the fix from http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8304
[03:51] <wgrant> mwhudson: Right.
[03:51] <mwhudson> i guess bong merge conflict resolution again?
[03:52] <mars> mwhudson, ?
[03:52] <mwhudson> mars: someone merged from trunk, got conflicts in rocketfuel-get and resolved them incorrectly?
[03:52] <mwhudson> it's a theory
[03:53] <mars> ah
[03:54] <mars> the other one killed some app links in sourcecode/, but it appears the test suite somehow missed it.
[04:15] <ajmitch> victory, I have launchpad running on the laptop even with a hacked buildout
[04:16] <wgrant> ajmitch: Why did it need hacking?
[04:17] <ajmitch> because there was some version conflict in getting z3c.recipe.i18n, so I thought I'd see how far I'd get by disabling that
[04:17] <ajmitch> to my surprise I've got it running
[04:17] <thumper> ajmitch: did you have a copy of lp-launchpad-dependancies as ./download-cache?
[04:17] <ajmitch> thumper: yes
[04:17] <thumper> hmm...
[04:17] <mwhudson> wee, basically all the codehosting tests fail with bzr.dev
[04:17] <thumper> mwhudson: I saw that there were some failures
[04:18] <thumper> mwhudson: what's changed this time?
[04:18] <mwhudson> 50 failures, 19 errors
[04:18] <mwhudson> not sure yet
[04:18] <mwhudson> argh, of course it's the acceptance tests so the failures are useless
[04:19] <mwhudson> oh
[04:19] <mwhudson> argh!
[04:19] <ajmitch> thumper: I won't pretend to know why buildout failed, apart from that I'm running on hardy, not jaunty
[04:20] <ajmitch> & that I'd rsynced branches from my desktop previously
[04:20] <mwhudson> because these tests weren't run out of an actual egg, there is no file at /home/buildbot/slaves/launchpad/bzr/build/bzr.dev/EGG-INFO/scripts/bzr
[04:20] <mwhudson> grump
[04:20] <thumper> :(
[04:21] <lifeless> eggs are such a heinous invention
[04:27] <wgrant> The new license headers in current(-dev).sql have to be added manually and make 'make lint' whine. Should newsampledata be fixed to add them, or should they be removed?
[04:27] <mars> lifeless, so you are a pip fan then?
[04:29] <lifeless> mars: I'm a deb an
[04:29] <lifeless> *fan*
[04:29] <lifeless> deb and source
[04:29] <lifeless> either install normally
[04:38]  * thumper hurls
[04:38] <thumper> I've just seen a truely (sp?) ugly page
[04:39] <thumper> and the worst bit is - I think I wrote it
[04:39] <thumper> :(
[04:39] <wgrant> There are a few around.
[04:39] <mwhudson> thumper: truly
[04:40] <thumper> mwhudson: I was tossing up whether or not to add the "e"
[04:40] <thumper> but neither looked right to me
[04:40] <thumper> I just suck at spelling
[04:40] <mwhudson> english is ridiculous
[04:45] <mwhudson> thumper: want to review a branch that will work better at this?
[04:45] <thumper> better at what?
[04:45] <mwhudson> testing against bzr.dev
[04:46] <thumper> mwhudson: sure
[04:46] <thumper> here's an unrelated question
[04:46] <thumper> when "fixing" a bug on a page
[04:46] <thumper> and you notice something "wrong"
[04:46] <thumper> how hard should I resist fixing the "wrongness"?
[04:48] <mwhudson> almost always better to do it in another branch, i'd say
[04:48] <lifeless> thumper: if you have time for yak shaving, shave the yak
[04:49] <lifeless> thumper: I'd do it in a separate thing to be reviewed, to be nice to the reviewers
[04:49] <thumper> hmm...
[04:49] <thumper> ok
[04:52] <mwhudson> thumper: https://code.edge.launchpad.net/~mwhudson/launchpad/bzr.dev-help/+merge/9234
[05:31] <lifeless> how do you unassign via email
[05:32] <spm> "dear losas, pls to be doing XYZ. kthxbye" ???
[05:32] <wgrant>   assignee nobody
[05:32] <thumper> hah
[05:32] <thumper> thanks wgrant
[05:33] <lifeless> wow
[05:33] <lifeless> I so want to create an account nobody now
[05:33] <ajmitch> it's not a reserved name?
[05:33] <lifeless> wgrant: you're sure about this?
[05:33] <lifeless> https://help.launchpad.net/Bugs/EmailInterface needs an update if True
[05:34] <wgrant> lifeless: It's there...
[05:34] <lifeless> oh ugh
[05:34] <wgrant> There was a Person named nobody ages ago.
[05:34] <wgrant> But it got renamed.
[05:34] <lifeless> there are two sections on assignee
[05:34] <lifeless> ><
[05:35] <lifeless> https://help.launchpad.net/Bugs/EmailInterface#Assigning%20and%20targeting%20the%20bug <- seems very confused
[05:36] <wgrant> lifeless: It's shown in the reference, but not the short introduction. Seems reasonable.
[05:36] <lifeless> wgrant: the short intro links to 'affects' not 'assignee'
[05:36] <lifeless> which makes one think that the short intro is all there is
[05:37] <lifeless> thanks though
[05:43]  * thumper just deleted two page templates \\o/
[05:45] <thumper> mwhudson: want to review a branch where I clean up the codereviewcomment +fragment and +macro views to use services/comment +render?
[05:45] <thumper> mwhudson: it is pretty boring
[05:45] <thumper> mwhudson: good for a friday afternoon :)
[05:46] <thumper> mwhudson: I'm just running all the branches stories to make sure I didn't break anything
[05:46] <thumper> mwhudson: tested locally :)
[05:47] <mwhudson> thumper: boring sounds good
[05:47] <thumper> oh FFS
[05:48] <thumper> _someone_ keeps playing with sample data
[05:48] <thumper> grr
[05:48] <mwhudson> conflicts?
[05:49] <thumper> no, just a failure since I've not done "make schema" in a while and someone added Sample Person to another team
[05:51] <mwhudson> ah
[05:51] <mwhudson> that's sucky
[05:51]  * wgrant finds a bug in the malone email interface, thanks to lifeless' "assignee nobody" email.
[05:54] <lifeless> ?
[05:56] <wgrant> lifeless: It didn't announce in the email or activity log that you had added a launchpad-code task. Very odd.
[05:56] <lifeless> heh
[05:57] <lifeless> I _really_ want a 'change what this task affects'
[05:57] <lifeless> rather than adding a task
[05:57] <lifeless> if you do that, Jelmer and I will be extremely happy
[05:57] <sanxiyn> Maybe a bit late, but congrats on open source!
[05:57] <spiv> sanxiyn: it's never too late to be loved!
[05:58] <wgrant> lifeless: That doesn't seem too hard. I wonder if it would be better to have a command that takes two args, or a command to follow the 'affects' that reassigns the current task.
[05:58] <sanxiyn> Now I can stop evangelizing how evil Launchpad is and how bad Canonical is. Thanks.
[05:58] <sanxiyn> (Been doing that for last couple years.)
[05:59] <lifeless> wgrant: reaffect <new product.
[05:59] <lifeless> or someting
[05:59] <ajmitch> affects instead
[05:59] <wgrant> lifeless: retarget?
[05:59] <lifeless> yeah
[05:59] <wgrant> Although I guess that's not the UI term.
[05:59] <lifeless> it should be:P
[06:00] <wgrant> Indeed.
[06:00] <wgrant> It's in the webservice API.
[06:01] <thumper> mwhudson: I'm just pushing the branch up now
[06:01] <thumper> mwhudson: although I'm about to EOD
[06:01] <thumper> mwhudson: shall I bother to assign the review to you?
[06:01] <thumper> mwhudson: or just wait till Monday
[06:02] <mwhudson> thumper: oh assign it to me
[06:02] <mwhudson> thumper: it might wait until monday, but i'll probably slog through it
[06:02] <thumper> bzr sending now
[06:10] <thumper> mwhudson: sent
[06:14] <thumper> sanxiyn: so you like Launchpad now?
[06:15] <sanxiyn> thumper: I should try it, and then I would be able to tell :)
[06:15] <sanxiyn> thumper: I like e.g. tracking of bugs in remote bug trackers. (That's why I am a contributor to Debian's bts-link.)
[06:16] <thumper> :)
[06:16] <thumper> bts?
[06:16]  * thumper doesn't know much about debian
[06:16] <sanxiyn> thumper: http://bts-link.alioth.debian.org/
[06:17] <wgrant> The BTS is the Debian Bug Tracking System
[06:17] <thumper> ah
[06:17] <sanxiyn> And bts-link is a component of that system that can track remote Bugzilla, Trac, GForge, RT, whatever.
[06:17] <thumper> anyway...
[06:17]  * thumper EODs
[08:04] <wgrant> noodles775: Hi.
[08:05] <noodles775> Hi wgrant :), Congrats on getting your MP approved!
[08:05] <wgrant> noodles775: Thanks.
[08:05] <wgrant> noodles775: Are there any designs for the new DSP page with its version listing yet? Bug #144620 would probably be fixable in the redesign.
[08:05] <ubot3> Malone bug 144620 in soyuz "Some displayed sourcepackagerelease changes files don't have attribution" [High,Triaged] https://launchpad.net/bugs/144620
[08:05] <mup> Bug #144620: Some displayed sourcepackagerelease changes files don't have attribution <Soyuz:Triaged> <https://launchpad.net/bugs/144620>
[08:05] <mup> Bug #144620: Some displayed sourcepackagerelease changes files don't have attribution <Soyuz:Triaged> <https://launchpad.net/bugs/144620>
[08:05] <mup> Bug #144620: Some displayed sourcepackagerelease changes files don't have attribution <Soyuz:Triaged> <https://launchpad.net/bugs/144620>
[08:05] <wgrant> Oh dear.
[08:07] <noodles775> wgrant: Only what's in those images attached to the blueprint... I think bigjools is keen for us to work on the DSP refactoring asap...
[08:07] <noodles775> wgrant: I'm just looking at the new 3-0 style refactoring (and having a go at applying it to the archive-index)
[08:08] <wgrant> noodles775: I also don't really like the elimination of the D(S)BP(R) pages. They're very useful for looking at the sometimes complicated histories.
[08:08] <noodles775> wgrant: The idea (which may not be clearly expressed) is that the pages would still exist, but not be needed when the user has JS on.
[08:09] <wgrant> noodles775: Ah, I see. That is fine, then.
[08:09] <noodles775> wgrant: ie. that info would be available on the DSP page (after drilling down), but would still need to be there for non-js browsers.
[08:09] <noodles775> Cool!
[08:09] <wgrant> Some of the info isn't appropriate for the DSP page.
[08:10] <wgrant> (eg. BPRs with the same name but from a different source)
[08:10] <noodles775> Why would a BPR that wasn't from that source be displayed on the page?
[08:11] <noodles775> ah, I see
[08:11] <wgrant> noodles775: It wouldn't, which is a good reason for the DASBP page to exist. Otherwise I can't find the history of what the name mapped to.
[08:12] <noodles775> wgrant: Hmm... it'd be great to capture these as stories on the spec, could you add one?
[08:12]  * noodles775 checks the (practically empty) spec
[08:12] <wgrant> noodles775: Under Use Cases?
[08:12] <noodles775> wgrant: yep
[08:12] <noodles775> Thanks!
[08:13] <noodles775> wgrant: just add any positive or negative use cases, we can evaluate them when we've collected lots.
[08:14] <wgrant> noodles775: Sure.
[08:19] <adeuring> good morning
[08:19] <noodles775> Morgan adeuring
[08:19] <adeuring> hi noodles775!
[09:21] <mrevell> Morning :)
[09:27] <bigjools> morning all
[09:28] <wgrant> Morning bigjools.
[09:28] <bigjools> hey wgrant
[10:00] <henninge> Hi!
[10:00] <henninge> what is that page again that shows all of the used icons on launchpad?
[10:01] <wgrant>  /+graphics
[10:01] <henninge> wgrant: cheers
[10:14] <jtv1> mrevell: morning!
[10:14] <mrevell> hey jtv1!
[10:15] <mrevell> jtv: I'll just get a cup of tea, if that's ok
[10:15] <bigjools> thunderstorm alert here, I might go netless any time
[10:15] <mrevell> bigjools: really?
[10:15] <jtv> mrevell: sure, I'll have one too thanks
[10:16] <bigjools> mrevell: yes, my power goes out usually
[10:16] <mrevell> bigjools: Wow but I'd still rather live in Kempsey, heh
[10:17] <bigjools> mrevell: the house next door is up for sale :)
[10:17] <mrevell> bigjools: interesting -- PPA and Soyuz help whenever I want it :)
[10:18] <bigjools> mrevell: I have guard dogs, barbed wire and feral children
[10:18] <mrevell> :) I bet I have more dogs
[10:20] <bigjools> i used to be able to say I had more children :)
[10:22] <mrevell> heh
[10:22] <mrevell> jtv: Skype or IRC sir?
[10:23] <jtv> mrevell: I think irc for this one, since it's all in writing... good way to throw notes at each other :)
[10:23] <mrevell> jtv: sounds great
[10:23] <jtv> mrevell: I sent you an email with the text I have.
[10:23] <mrevell> jtv: I have it here, I'll read it then PM you
[10:23] <jtv> mrevell: perfect
[10:23]  * jtv reaches for coffee
[11:02] <deryck> Morning, all.
[11:39] <bigjools> I'm really sad that my new Dell Mini 10v, with Ubuntu pre-installed, has got a key with a Windows logo on it :/
[11:44] <noodles775> bigjools: wierd?
[11:44] <bigjools> crass
[11:44] <noodles775> Maybe canonical could provide Dell with similar keys?
[11:56] <andrea-bs> adeuring, Hi! May I ask you a question?
[11:56] <adeuring> andrea-bs: sure :)
[11:57] <andrea-bs> adeuring, thanks for your review for my branch "blueprint-whiteboard-diffs"; what should I put instead of 72 for get_unified_diff()?
[11:58] <adeuring> andrea-bs: nothing ;) As Björn pointed out, my question about the diff formatting was a a bug in the review.
[11:59] <andrea-bs> adeuring, oh, sorry... I should read all the comments before asking :)
[11:59] <adeuring> andrea-bs: no prblem ;)
[12:00] <wgrant> Who owns canonical.zeca?
[12:02] <bigjools> good question, cprov-afk  do you know?
[12:03] <cprov-afk> wgrant: foundations, I guess
[12:03] <cprov-afk> wgrant: ideas ?
[12:04] <cprov-afk> wgrant: or bugs ?
[12:04] <stub> Isn't that the GPG thingy used by Soyuz?
[12:04] <stub> I don't think anyone in foundations has ever messed with it...
[12:05] <wgrant> cprov-afk: I needed a keyserver.launchpad.dev, so I patched it to work properly. Previously IGPGHandler would be unable to re-get keys from it. http://williamgrant.id.au/f/1/2009/zeca-get-key-id.diff is the ugly patch, and I wonder what to do.
[12:05] <stub> Or knows enough Portuguese to even understand what the name means :-P
[12:05] <wgrant> cprov-afk: it works fine for tests, because the IGPGHandler survives for the whole test.
[12:06] <wgrant> But that patch makes it work for real stuff as well.
[12:09] <cprov-afk> wgrant: the patch is fine, why do you need zeca on a production-like environment ?
[12:11] <wgrant> cprov-afk: I needed a local keyserver to verify signatures (process-upload, CoC), and zeca is close enough that it was easier than setting up a proper one.
[12:12] <cprov-afk> wgrant: right, but it would only work for a fixed set of keys
[12:13] <wgrant> cprov-afk: No. It accepts uploads.
[12:14]  * mrevell is off to grab some lunch
[12:15] <cprov-afk> wgrant: jeez, it does !! I wrote it...
[12:15] <wgrant> cprov-afk: Haha.
[12:15] <wgrant> It has been a while, I imagine.
[12:17] <cprov-afk> wgrant: the patch is okay. Doesn't hurt, really, but you need tests. I can help you in one hour or so.
[12:19] <wgrant> cprov-afk: I was going to write tests, but I couldn't work out how to run the existing ones.
[12:23] <cprov-afk> wgrant: `./bin/test -vv -t canonical.zeca`
[12:25] <wgrant> cprov-afk: Ah. I missed the -t - lp.* don't need it :(
[12:25] <wgrant> cprov-afk: Thanks.
[12:25] <cprov-afk> wgrant: np
[12:29] <bigjools> cprov-afk: jeez that is an old file
[12:41]  * gmb => afk for a bit.
[12:46] <bigjools-afk> wgrant: your config change is affecting the tests for some reason, tests that refer to keyserver.ubuntu.com are failing
[12:48] <wgrant> bigjools_: Oh, blah. I see testrunner's conf extends development's.
[12:48] <bigjools_> right
[12:48]  * wgrant overrides it in testrunner's conf.
[12:49] <wgrant> bigjools_: Which tests were they?
[12:50] <bigjools_> I wish I had a complete list, I just had a power outage after running the test suite for 2.5 hours >:(
[12:50] <bigjools_> but grep is your friend
[12:50] <bigjools_> gpghandler.txt and foaf/xx-person-rdf.txt
[12:50] <bigjools_> at least
[12:50] <bigjools_> and xx-ubuntu-ppas.txt
[12:51] <wgrant> Yep. Rerunning tests mentioning keyserver.ubuntu.com now...
[12:51] <bigjools_> ta
[13:00] <bigjools> wgrant: I am going to lunch, comment on the MP when you're done
[13:00] <wgrant> bigjools: Pushing now.
[13:00] <wgrant> bigjools: All those tests pass now.
[13:08] <maxb> rocketfuel-setup configures a "merge_target" line in ~/.bazaar/locations.conf - I cannot find any mention of this configuration item in the Bazaar User Reference, nor in google. Is it a typo?
[13:27] <allenap> maxb: I think it's for the lpreview plugin. Which I don't use and don't really remember anything about, but it's probably safe if you leave it or remove it.
[13:27] <bac> good morning sinzui.  when you get a chance could you look at https://answers.edge.launchpad.net/launchpad-registry/+faq/567.  the last sentence of the second paragraph is confusing to the point i don't know what you're saying.
[13:28] <sinzui> yes that is awkward
[13:32] <sinzui> bac: Did I fix it?
[13:32] <sinzui> reload the page
[13:35]  * bac looking
[13:38] <bac> sinzui: yes that is better.  i understand what you are saying but not why.  the trusted team is set up to not get any email.  are you saying the team will miss legitimate, non-bug email sent to the team?
[13:40] <bac> maxb: i do use the lpreview plugin and i have my merge_target set the same as my submit_branch.
[13:41] <sinzui> I am saying that launchpad developers are idiots. They made mailing lists impossible to to use, then they turned subscriptions into teams. Setting up this recipe requires EVERY user to get his subscription setting right. The project owner most certainly get complaints.
[13:44] <bac> sinzui: ah, i see.
[13:45] <sinzui> bac, Should I put that into the FAQ too?
[13:45] <bac> sinzui: was the way i characterized it a suitable subset of what you really meant?
[13:45] <bac> i think, perhaps, we should not include your real version.  :)
[13:49] <sinzui> bac: I am sorry, this recipe is a little different than I recall. since we are not relying on a list, I think the sentences can be dropped
[13:49] <bac> ok
[13:50]  * sinzui updated the FAQ again and drinks more coffee
[13:50] <bac> sinzui: i wish we could grow an option for the team to just not get email rather than providing a legitimate but unused one.
[13:53] <sinzui> bac: we need to take a hammer to teams and subscriptions to ensure their are no ambiguities in how they are used. Each may exist for access-control or communication, but neither works well if it is used for both purposes.
[14:00] <thekorn> how can I reset the database of my launchpad instance to the default values?
[14:01] <wgrant> thekorn: make schema
[14:01] <thekorn> ok, I thought there is something simpler than this
[14:05] <salgado> thekorn, there is
[14:05] <salgado> thekorn, createdb -E UNICODE --template=launchpad_dev_template launchpad_dev
[14:06] <salgado> first you'll need a dropdb launchpad_dev, though
[14:06] <thekorn> ok, cool, noted for the next time
[14:06] <bac> salgado: hmm, that doesn't look simpler...
[14:07] <salgado> bac, good point, but it's a hundred times faster. :)
[14:07] <thekorn> it depends on the definition of "simpler"
[14:07] <bac> oh, well,yeah.
[14:18] <mrevell> abentley: Hi, I see you were the last person to edit https://dev.launchpad.net/DatetimeUsageGuide -- there's a similar but longer document here -- https://launchpad.canonical.com/DatetimeUsageGuide ---- is there anything on the old launchpad.c.c wiki version that should be on the dev.lp.net version, in your view?
[14:21] <mars> good morning launchpad!
[14:24] <abentley> mrevell: I'm not sure how this happened.  I think the canonical.com version is more useful.
[14:24] <mrevell> thanks abentley
[14:27] <mars> thekorn, if you are curious and want to play with the db, check database/schema/Makefile
[14:28] <mars> there are targets in there for doing things like creating the launchpad_empty database, and 'make diagram'
[14:29] <BjornT_> mars: can i get your opinion on this patch? https://pastebin.canonical.com/20291/
[14:29] <barry> abentley, mrevell i haven't looked closely, but the c.c version should be merged into the l.n version
[14:29] <BjornT_> mars: or tell me who's the best person to review it
[14:30] <sinzui> barry, bac, Edwin, salgado: standup in 2 minutes
[14:30] <BjornT_> mars: it's to prevent the bug page from temporarily showing the 'subscribe someone else' picker when loading, causing the beginning of the page to be focused
[14:30] <mars> BjornT_, hmm, I'd refer you to sinzui or noodles775
[14:30] <BjornT_> mars: ok, no worries
[14:31] <mars> BjornT_, that is an interesting way to fix it then
[14:31] <BjornT_> sinzui, noodles775: can you take a look at this patch? https://pastebin.canonical.com/20291/
[14:31]  * noodles775 looks (just on phone)
[14:31] <mars> is that even a valid value for 'visible'?
[14:31] <BjornT_> mars: i think it should be ok, since there's a hide() further down, so it should be hidden. i assumed 'visible' should be a boolean, shouldn't it?
[14:32] <sinzui> visibility: <visible|hidden>
[14:33] <sinzui> BjornT_: Are you using an unsupported value to take advantage of a CSS engine's weeknes?
[14:33] <BjornT_> sinzui: i'm not passing a CSS value there. it's an JS attribute
[14:34] <mars> oh!
[14:35] <sinzui> BjornT_: I see, thank you for clarifying this
[14:35] <mars> BjornT_, sorry, it didn't click in.  You'll have to test it
[14:35] <mars> at the Berlin sprint, we found some strange interactions with the 'visible' attribute
[14:35] <mars> if it works, then cool
[14:36] <bac> hi mrevell
[14:36] <mrevell> hi there bac
[14:36] <bac> mrevell: if you don't need my help on feedback moderation any more could you remove me from the owners?
[14:36] <BjornT_> mars: it doesn't seem to be causing any problems. do we use the picker anywhere else, apart from on the bug page?
[14:36] <BjornT_> sinzui: ^^^
[14:37] <mrevell> bac sure thing, gimme a mo
[14:38] <noodles775> BjornT_: I've used the person picker for archive subscriptions (/~user/+ppa/name/+archivesubscriptions)
[14:38] <noodles775> BjornT_: I'll send you a script that will set one up for you.
[14:39] <BjornT_> noodles775: cool
[14:41] <mrevell> bac sorted
[14:42] <gmb> Ooh, pretty.
[14:42]  * gmb just discovered bin/test -c by accident
[14:44] <mars> gmb, ever tried '-D' ?
[14:44] <gmb> mars: No, what happens then? Does it Dance?
[14:45] <bac> gmb:  wow, -c gives me limegreen on my blue background.  u-g-l-y
[14:45] <mars> no, it just dumps you into a pdb console at the exact point where the test raised an exception or failure.
[14:45] <gmb> Nice.
[14:45] <gmb> Except it's a pagetest, so maybe not so much.
[14:45] <gmb> bac: Eww.
[14:45]  * gmb has a traditional black background with white text as standard.
[14:46] <mars> a bit more annoying for pagetests.  You need to up-frame a bit
[14:46] <mars> 'u<ret><ret><ret>' at the prompt
[15:17] <gmb> BjornT_: Question: w.r.t removing +filebug-advanced (or at least making it redirect to +filebug) there are tests that ensure that clicking on 'Advanced bug reporting options' on a +filebug page will maintain any blob tokens passed to +filebug. Those tests are obviously not relevant now, but are there any cases in which a blob token would be submitted to +filebug-advanced? Should I worry about tokens when redirecting to +filebug?
[15:19] <BjornT_> gmb: no, that shouldn't be an issue. afaik, nothing is linking to +filebug-advanced passing along a blob token
[15:19] <gmb> BjornT_: Cool.
[15:19] <BjornT_> noodles775: did you send that script?
[15:19]  * gmb like excising tests
[15:20] <noodles775> BjornT_: sorry, not yet (just replying to an email). I'll have it in 3 mins :)
[15:20] <BjornT_> noodles775: ok, no worries :)
[15:25] <noodles775> BjornT_: http://pastebin.ubuntu.com/230555/
[15:29] <sinzui> kiko: jml added it some time ago. We did not have a rule to link lp: to a bug, so there was no conflict for him to see
[15:29] <bac> hi salgado
[15:29] <kiko> sinzui, that's fine, as long as it actually works
[15:29] <kiko> sinzui, and I think there's no conflict -- if it's lp:3213 then it's a bug; if it's lp:foo then it's a project branch
[15:29] <salgado> hi bac
[15:30] <sinzui> kiko: right. I was going to file a bug to the affect that the linker needs more specific rule
[15:35] <bac> hi kiko:  the branh i landed yesterday with your RC accidentally reverted a small fix to rocketfuel-get.  you can see it here:  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/8318
[15:36] <bac> kiko:  do you want me to correct that in db-devel now or wait until PQM opens and fix it in devel?
[15:36] <BjornT_> noodles775: thanks. the ppa page still works :) can i get an r=you for that patch?
[15:37] <bac> matsubara: when are we doing the re-roll-out?
[15:38] <noodles775> BjornT_: So it's just the lp widget using visible=False as a default right? And you've grepped/tested any other uses of the widget in LP? If so, r=me
[15:39] <noodles775> BjornT_: actually, why does the default for the widget need to be set to false? Why can't the bugs page that uses it create the widget passing in false? (maybe I missed that before?)
[15:39] <kiko> sinzui, sounds perfect
[15:39] <ursula_> sinzui, hi
[15:39] <barry> losa ping
[15:39] <sinzui> hi ursula_
[15:39] <kiko> bac: why did your branch revert that?!
[15:40] <BjornT_> noodles775: well, we would basically need to pass it as false everywhere it's used, no?
[15:40] <Ursinha> sinzui, I'm not able to access +milestones page, it's timing out consistently on edge and lpnet
[15:40] <matsubara> bac, don't know yet
[15:40] <bac> kiko:  i did a merge before submitting and it must've come from the wrong branch
[15:40] <Ursinha> sinzui, I just filed a bug for it, bug 404120, could you take a look, please?
[15:40] <ubot3> Malone bug 404120 in launchpad-registry "Timeout in +milestones page" [Undecided,New] https://launchpad.net/bugs/404120
[15:40] <mup> Bug #404120: Timeout in +milestones page <timeout> <Launchpad Registry:New> <https://launchpad.net/bugs/404120>
[15:40] <mup> Bug #404120: Timeout in +milestones page <timeout> <Launchpad Registry:New> <https://launchpad.net/bugs/404120>
[15:40] <mup> Bug #404120: Timeout in +milestones page <timeout> <Launchpad Registry:New> <https://launchpad.net/bugs/404120>
[15:40] <Ursinha> hahaha
[15:40] <Ursinha> someone need to tell ubot3 to leave
[15:41] <matsubara> sinzui, can you fix that timeout for the re-roll?
[15:41] <sinzui> Ursinha: matsubara: no
[15:42] <kiko> bac, hmph, please read your diffs carefully before you submit, that's pretty bad
[15:42] <kiko> Ursinha, matsubara: does anybody else have an RC branch to land?
[15:42] <matsubara> kiko, it'd be nice to have that timeout fixed ^
[15:42] <sinzui> matsubara: Ursinha: well, I cannot fix the page, but I can look into not showing bug counts. like we did on the +series page. They are expensive to get since there is a privacy check for each one
[15:43] <kiko> sinzui, you could load the bug counts via ajax like the bugs page does, maybe even reusing that code?
[15:43] <matsubara> mthaddon, when's the deadline to submit code for the re-roll?
[15:43] <sinzui> kiko: indeed that is why I said no at first. I engineered the templates to let me do it via AJAX., but I need more time to write a script that uses it
[15:43] <kiko> mthaddon, I don't think we will re-roll at all unless I see good reason
[15:44] <noodles775> BjornT_: I thought most call-sites created it with visible=false for that reason... I'm just not sure whether there is a YUI standard default for visible.
[15:44]  * noodles775 looks
[15:44] <kiko> matsubara, ^^
[15:44] <matsubara> kiko, are we not going to re-roll 8314..8319?
[15:44] <sinzui> kiko: I will stop what I am doing and looking to an immediate solution to the page and create a bug about the long term solution
[15:45] <kiko> sinzui, just remove the information for now
[15:45] <BjornT_> noodles775: well, the ppa page has the same issue as the bug page. i can't see it shown, but it grabs focus, so that you can't use Page Up and Page Down to scroll
[15:45] <kiko> matsubara, if mthaddon wants to, but then I'd rather just land sinzui's branch and re-roll
[15:46] <kiko> sinzui, if you are going to prepare a branch, please include the patch that bac reverted
[15:46] <matsubara> kiko, sounds like a good plan
[15:46] <kiko> sinzui, just show it to me and I'll r/rc
[15:46] <sinzui> okay
[15:46] <kiko> mthaddon, do you feel like trying to update the librarian?
[15:46] <BjornT_> noodles775: and considering hide() is called in create(), i don't see a reason not to pass in visible: false
[15:47] <noodles775> BjornT_: +1, if that's the case!
[15:48] <mars> bigjools, Ursinha, ping, is it a known issue that filtering the PPA package list using unicode characters causes an OOPS?
[15:49] <Ursinha> mars, not in that specific field, afaik, but will check for a bug #
[15:49] <bigjools> not heard of that
[15:50] <BjornT_> noodles775: thanks! i've grepped for other uses, and it's ok.
[15:50] <noodles775> BjornT_: great :)
[15:50] <mars> bigjools, OOPS-1300A556 and OOPS-1300G2888 both come from the same thing
[15:50] <ubot3> https://devpad.canonical.com/~jamesh/oops.cgi/1300A556
[15:50] <ubot3> https://devpad.canonical.com/~jamesh/oops.cgi/1300G2888
[15:51] <mars> and I know too little about storm to tackle that error efficiently
[15:52] <mars> someone with better knowledge about how storm and BatchNavigator interact would be able to make quick progress
[15:52] <BjornT_> kiko: what do you think of fixing bug 392138 and bug 404088 for the re-rollout?
[15:52] <mup> Bug #392138: Broken keyboard navigation on bug pages <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/392138>
[15:52] <ubot3> Malone bug 392138 in malone "Broken keyboard navigation on bug pages" [High,In progress] https://launchpad.net/bugs/392138
[15:52] <mup> Bug #404088: Overlay temporarily shown when loading the bug page <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/404088>
[15:52] <mars> Ursinha, you'll probably kill a number of OOPses on search pages by fixing that issue
[15:52] <mup> Bug #392138: Broken keyboard navigation on bug pages <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/392138>
[15:52] <ubot3> Malone bug 404088 in malone "Overlay temporarily shown when loading the bug page" [Medium,In progress] https://launchpad.net/bugs/404088
[15:52] <mup> Bug #392138: Broken keyboard navigation on bug pages <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/392138>
[15:52] <mup> Bug #404088: Overlay temporarily shown when loading the bug page <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/404088>
[15:52] <mup> Bug #404088: Overlay temporarily shown when loading the bug page <Launchpad Bugs:In Progress by bjornt> <https://launchpad.net/bugs/404088>
[15:52] <bigjools> botfight
[15:52] <mars> more bot barf!
[15:52] <BjornT_> kiko: the fix is simple, but it's js, so it might be a bit risky anyway: https://pastebin.canonical.com/20291/
[15:53] <Ursinha> gee
[15:53] <Ursinha> ubot3, owner
[15:53] <ubot3> This bot is owned by jussi01 - Questions about ubottu should be asked in #ubuntu-bots
[15:53] <Ursinha> can we remove ubot3 from here?
[15:54] <bigjools> Ursinha: can you file a bug about that unicode issue please, if there isn't one
[15:54] <Ursinha> bigjools, doing now
[15:55] <Ursinha> bigjools, do you know how to fix that?
[15:55] <bigjools> no
[15:55] <bigjools> but I have a suspicion
[15:58] <abentley> kiko: I've introduced a bug for Revision emails where the merge proposal has an outstanding review request, that causes them to oops.  I have a two-line fix.  Can I get an RC? https://pastebin.canonical.com/20301/
[15:59] <kiko> BjornT_, abentley: looking
[16:02] <Ursinha> bigjools, bug 404144
[16:02] <ubot3> Malone bug 404144 in soyuz "UnicodeDecodeError when using unicode chars filtering PPA packages" [Undecided,New] https://launchpad.net/bugs/404144
[16:02] <mup> Bug #404144: UnicodeDecodeError when using unicode chars filtering PPA packages <oops> <Soyuz:New> <https://launchpad.net/bugs/404144>
[16:02] <mup> Bug #404144: UnicodeDecodeError when using unicode chars filtering PPA packages <oops> <Soyuz:New> <https://launchpad.net/bugs/404144>
[16:02] <mup> Bug #404144: UnicodeDecodeError when using unicode chars filtering PPA packages <oops> <Soyuz:New> <https://launchpad.net/bugs/404144>
[16:02] <Ursinha> aww
[16:03] <bigjools> please get him to get rid of ubot3
[16:03] <mars> who's channel op?
[16:03] <bigjools> or mup, I  don't care which
[16:03] <mars> mup is easier
[16:03] <mars> at least ubot3 does OOPS reports
[16:03] <bigjools> thanks for filing it Ursula
[16:04] <kiko> BjornT_, how bad is the problem? if that breaks things further on lpnet, will it be worse than the current situation?
[16:04] <bigjools> mars: with the wrong url!
[16:04] <matsubara> isn't it a dupe of 44919?
[16:04] <matsubara> Ursinha, ^
[16:04] <mars> bigjools, good point
[16:04] <kiko> abentley, yes, rc=kiko for that, but I'd try and land that close to sinzui's patch to avoid having to do multiple buildbot runs
[16:05] <Ursinha> matsubara, I don't think so, but will check again
[16:05] <Ursinha> bug 44919
[16:05] <ubot3> Malone bug 44919 in launchpad-foundations "UnicodeDecodeError while POSTing forms with non-ascii characters." [High,Triaged] https://launchpad.net/bugs/44919
[16:05] <mup> Bug #44919: UnicodeDecodeError while POSTing forms with non-ascii characters. <infrastructure> <oops> <Launchpad Foundations:Triaged by bjornt> <https://launchpad.net/bugs/44919>
[16:05] <mup> Bug #44919: UnicodeDecodeError while POSTing forms with non-ascii characters. <infrastructure> <oops> <Launchpad Foundations:Triaged by bjornt> <https://launchpad.net/bugs/44919>
[16:05] <mup> Bug #44919: UnicodeDecodeError while POSTing forms with non-ascii characters. <infrastructure> <oops> <Launchpad Foundations:Triaged by bjornt> <https://launchpad.net/bugs/44919>
[16:05] <sinzui> kiko: I am close to a patch. It breaks a few tests that I need to reconcile
[16:05] <abentley> kiko: I haven't run the test suite against it yet.
[16:06] <kiko> abentley, coordinate with sinzui
[16:06] <kiko> sinzui, abentley: thanks a lot for handling these, you guys rock
[16:06] <mars> matsubara, I'm not sure if that is the same issue
[16:06] <abentley> kiko, np
[16:07]  * mars check the stack trace
[16:07] <Ursinha> matsubara, the problem seems a little different
[16:07] <mars> yes, that is different
[16:07] <abentley> sinzui: I'm running the full test suite against my branch, started a minute ago.  I'll let you know when I'm done.
[16:07] <BjornT_> kiko: it's an annoyance, but nothing serious. with javascript even simple fixes can break things badly, so i'm inclined to land it when pqm opens up. i just wanted to see if you had another opinion.
[16:07] <mars> matsubara, the issue we were looking at is Storm + BatchNavigator + Unicode = boom!
[16:07] <sinzui> bac: can you advise me about how to restore the rocketfuel-get change that was reverted
[16:08] <bac> sinzui: undo this: https://pastebin.canonical.com/20303/
[16:09] <bac> sinzui: in other words, restore line 8
[16:09] <sinzui> bac: thank you
[16:09] <matsubara> mars, ok
[16:09] <mars> matsubara, and this appears to be a problem with the user's requested language encoding - in the other OOPSes, the browser does accept en-us
[16:09] <bac> sinzui: thanks to you for including it
[16:10] <kiko> BjornT_, no, I agree with you that it's better to put it on edge and let users cry
[16:12] <mars> sinzui, would you or salgado have a moment to fix -61171?
[16:12] <mars> it is a one or two line fix
[16:13] <mars> but the test is beyond me
[16:13] <salgado> mars, is that a bug?
[16:13] <mars> salgado, yes, I don't want the bots to get it
[16:13] <salgado> why? I do
[16:13] <mars> bug 61171
[16:13] <ubot3> mars: Bug 61171 on http://launchpad.net/bugs/61171 is private
[16:13] <salgado> oh, bot*s*
[16:14] <Ursinha> hm, mup ignored the bug because it's private?
[16:14] <mars> perhaps, but I don't think that is a scalable solution to bot-fights :)
[16:16] <Ursinha> :)
[16:16] <mars> salgado, mwhudson managed to reproduce the bug yesterday, but for some reason you have to match the OOPsing string specifically
[16:16] <mars> so we couldn't come up with a general test case
[16:22] <mars> salgado, would you even bother with a test case here?  Or would you just fix it to get rid of the OOPS?
[16:22] <Ursinha> mars, salgado, do you think it can make it for the re-roll?
[16:23] <mars> Ursinha, tbh, not if I wrote it - that is why I asked salgado and sinzui
[16:23] <salgado> Ursinha, mars, I'm OCR today
[16:23] <mars> salgado, I'm CHR :)
[16:24] <Ursinha> uhoh
[16:25] <Ursinha> well, ok then
[16:25] <Ursinha> salgado, can you fix that on Monday then?
[16:26] <salgado> Ursinha, I haven't had a look at the bug yet, so I have no idea how much work is involved
[16:27] <Ursinha> salgado, let me change the question then, can you take a look at the bug on Monday? :)
[16:28] <salgado> hell, yeah.  that's for sure
[16:30] <Ursinha> thanks salgado :)
[16:30] <Ursinha> and mars for investigating that :)
[16:35] <allenap> kiko: About that lp:~allenap/launchpad/bugs-without-tasks-bug-403182 branch I asked you about this morning, Bjorn noticed a few other cases that needed to be taken care of. They're done and adeuring has reviewed them. A diff from this morning to now <https://pastebin.canonical.com/20297/>. Full diff against db-devel <https://pastebin.canonical.com/20309/>. It's still a small code change. Please could you take a look and give your blessing, then I'll
[16:35] <allenap> get it into db-devel asap?
[16:36] <kiko> allenap, is the last hunk in handlers.py a sort of assertion -- in other words, is that the only place where we actually decide to create the bug and commit?
[16:36] <kiko> allenap, my question is whether or not an assertion or oops would make sense
[16:37] <allenap> kiko: Off the bottom of that diff the same check is done, before notify()ing the bug_event. I just did the same thing.
[16:38] <allenap> kiko: It's better to check then the user gets an email saying what they did wrong, rather than an assertion which just blows up.
[16:40] <kiko> allenap, sure. but I think you're telling me that there is no single location that we can add this check to, which suggests you're right in wanting to refactor this code. am I right?
[16:40] <kiko> allenap, I'm saying r/rc=kiko regardless
[16:40] <kiko> allenap, coordinate with sinzui and abentley so we don't get stuck waiting for two buildbot runs
[16:41] <allenap> kiko: Yeah, that's it.
[16:41] <allenap> kiko: Thanks, I'll talk to them.
[16:43] <kiko> allenap, i raised my eyebrow to the change in the second file in the patch, but it's harmless and correct
[16:43] <allenap> kiko: :)
[16:43] <sinzui> kiko: I need to make another change. my fix need to be more comprehensive than just project-groups. I need another 30 minutes
[16:45] <mrevell> Is kfogel due online today or is he still OSConing?
[16:47] <kiko> the latter I believe
[16:53] <allenap> sinzui: When your change is ready to submit (to db-devel I assume), could you merge my lp:~allenap/launchpad/bugs-without-tasks-bug-403182 branch so that it all goes through the same buildbot run?
[16:54] <allenap> abentley: ^ is your change ready too?
[16:54] <sinzui> allenap: I do not use buildbot
[16:54] <sinzui> allenap: sorry
[16:54] <sinzui> I am an idoiot
[16:54] <allenap> sinzui: You read ec2test? :)
[16:54] <abentley> allenap: My change has not passed a test run yet.
[16:54] <sinzui> allenap: I do not use ec2test.
[16:55] <abentley> sinzui: me neither.
[16:55] <allenap> abentley: kiko mentioned (in another channel) that we should just get our changes into db-devel together so that they have a buildbot run together. If it succeeds, re-roll, else we get to pick up the pieces for a CP on Monday.
[16:55] <sinzui> allenap: if your branch is tested, all is cool
[16:56] <abentley> allenap: I saw that.
[16:56] <allenap> sinzui: I'm testing a limited subset of it locally.
[16:57] <allenap> abentley: Ah, do you mean that it fails a test run and you're working to fix it, or are you waiting for a run to complete?
[16:57] <allenap> Where "it" is "your branch".
[16:57] <abentley> allenap: I am waiting for a run to complete.
[16:57] <allenap> Okay.
[16:58] <abentley> allenap: I just restarted the test because salgado asked for some tweaks.
[17:01] <allenap> abentley, sinzui: I'm running as much of the test suite as I can locally, but I have to go in about 30 minutes. Could whoever of you ends up submitting to db-devel please include my branch? Don't worry if it's problematic. It's not totally critical, and we have to do some clean-up anyway so a CP on Monday will be fine.
[17:02] <abentley> allenap: I feel uncomfortable landing code that has not been fully tested.
[17:03] <sinzui> allenap: I hope to start testing in 15 minutes
[17:03] <allenap> abentley: Okay, that's fine, it'll have to go in on Monday.
[17:04] <abentley> allenap: I could merge your branch and sinzui's now, and restart the tests.
[17:04] <abentley> sinzui: Or is your branch still being written?
[17:04] <sinzui> I am still writing it
[17:04] <allenap> abentley: I would love it if you could run the tests for my branch and land it assuming it's good. I really really hope it's good.
[17:05]  * sinzui is struggling to keep the changes to a template and one group of tests
[17:05] <abentley> allenap: Okay, URL?
[17:05] <allenap> abentley: lp:~allenap/launchpad/bugs-without-tasks-bug-403182
[17:22] <sinzui> kiko: This is my fix for the +milestone pages and the rocketfuel fix: https://pastebin.canonical.com/20322/
[17:24] <sinzui> kiko: I should add that the template, view , and test has not changed since I landed the update to +milestone page last week. We know this is the only test that must change.
[17:24]  * sinzui prepares to start a test run
[17:27] <sinzui> allenap: that is a pretty deep change. Did you run all the tests for lp.bugs?
[17:28] <allenap> sinzui: Yes, they all pass. Why is it so deep?
[17:29] <sinzui> It is lower than pagetests. That is all I meant. I would test everything from zopeless to pagetests
[17:29]  * sinzui cannot remember if bugs has pagetests that test email
[17:32] <sinzui> allenap: I'll merge your branch into mine and play it on my hardy box.
[17:32] <allenap> sinzui: Okay, thanks. abentley is also running the full test suite with it merged too. Thanks guys :) I have to go now, but I'll check back later (probably much later).
[17:33] <sinzui> allenap: abentley: then I think I just need to verify my changes
[17:35] <abentley> sinzui: Well, I haven't started running allenap's tests, because I'm still downloading his branch.
[17:36] <allenap> abentley: Really? Its diff against db-devel is a bit over 200 lines.
[17:37] <abentley> allenap: I've downloaded 160 M so far..
[17:37] <allenap> Unfortunately I really have to go now :(
[17:37] <allenap> abentley: That's not right! Abandon it, it can wait for Monday. Get your stuff in.
[17:40] <sinzui> abentley: okay. I will merge his and play lp.bugs
[17:40] <abentley> sinzui: roger.
[17:40]  * maxb views https://dev.launchpad.net/Releases/2009Calendar and wonders why the version numbers jump immediately from 3.0 to 3.1.x
[18:01] <bigjools> bye all, have a nice weekend
[18:24] <mrevell> Okay guys,have a good weekend
[18:46] <sinzui> barry: ping
[18:58] <bac> hi sinzui
[18:58] <sinzui> hi
[18:59] <bac> sinzui: the problem stu is having is b/c he is trying to add a private membership team (~canonical) to a public team, which we disallow via the ValidTeamMemberVocab
[19:00] <sinzui> bac: as I thought
[19:00] <sinzui> did you update the team
[19:00] <bac> sinzui: i can relax that constraint to allow private teams to join public
[19:00] <bac> sinzui: update which team?  we do not allow PMT or Private teams to join others as it is now.
[19:00] <sinzui> Why not change all the teams involved to private teams as we planed
[19:01] <bac> so converting ~canonical to private now won't help
[19:01] <sinzui> bac: then we need to land a fix as we talked about. Gustavo is also looking for this fix
[19:02] <bac> sinzui: agreed
[19:02] <sinzui> I think all the users who want this are edge users so we can settle this in good pace
[19:03] <sinzui> bac: I did not see a bug for this, though we have discussed it. Create a bug if you cannot find one
[19:13] <barry> losa ping
[19:13] <mthaddon> barry: hi
[19:14] <barry> mthaddon: hi.  i have a script that will help us regenerate all the mailing list archives.  are you up for giving it a try?
[19:14] <mthaddon> barry: sure
[19:14] <barry> mthaddon: cool.  we can try one or two lists first, and then the whole shebang
[19:14] <barry> mthaddon: can you grab the lp-dev-utils branch?
[19:15] <mthaddon> barry: lp:lp-dev-utils ?
[19:15] <barry> mthaddon: lp:~launchpad/lp-dev-utils/trunk
[19:18] <barry> mthaddon: once you grab that branch, look for the archiveregen.py script
[19:18] <mars> btw, why does lp-dev-utils not have a trunk/ set?
[19:18] <barry> mars: dunno.  i guess nobody ever set it.  jfdi man! :)
[19:19]  * mars shrugs
[19:19] <barry> mthaddon: we need to copy that script onto forster and then ping me for a test run
[19:19] <mars> ok
[19:20] <mthaddon> barry: ok, I have it on forster
[19:21] <barry> mthaddon: double check the paths at the top of the file, and comment out the second BASE_PATH setting
[19:21]  * barry is not positive the first one is correct
[19:21] <mthaddon> barry: done
[19:22] <mthaddon> barry: it is the right path
[19:22] <barry> mthaddon: cool, now we'll convert first the haibunku list and see how it goes
[19:22] <barry> mthaddon: thanks
[19:22] <barry> so...
[19:22] <barry> mthaddon: ./archiveregen.py haibunku
[19:23] <mthaddon> barry: some success I think?
[19:23] <mars> hmm, usability FAIL for setting the default branch for lp-dev-utils, exactly as bzr says I should
[19:23] <mars> the word 'Default branch' doesn't appear anywhere in the UI from what I can see
[19:23] <barry> mthaddon: total success i think :)
[19:23] <mars> let alone something to convey the idea that I might set it
[19:23] <mthaddon> barry: ./archiveregen.py --all ?
[19:24] <barry> mthaddon: let's cross our fingers and jfdi
[19:24] <mars> beuno, ^ any thoughts on the 'Default branch' thing?
[19:25] <barry> mars: :(
[19:25] <beuno> mars, I lack context
[19:25] <beuno> even after reading the back log
[19:26] <beuno> want to fill  me in?
[19:26] <mars> beuno, I try this in the UI:
[19:26] <mars> $ bzr co lp:lp-dev-utils
[19:26] <mars> bzr: ERROR: Invalid url supplied to transport: "lp:lp-dev-utils": Launchpad Developer Utilities has no default branch.
[19:26] <mars> err, at the command line
[19:26] <barry> mars: i just set "code for this branch is devleoped in lp"  dunno if that helps
[19:27] <mars> beuno, so I go to the lp-dev-utils code page, see that it has a 'trunk/', and a development focus, but nothing to say what is wrong with bzr lp:
[19:27] <beuno> mars, barry, I assume that project is privatae
[19:27] <beuno> so lp: doesn't resolve
[19:27] <barry> it is private
[19:27] <beuno> exactly what *used* to happen with Launchpad  :)
[19:28] <beuno> lp: uses a public xmlrpc to figure that out
[19:28] <mars> then why does it work if you give it the full branch URL?
[19:28] <beuno> so it means no lp: shorcuts for private projects
[19:28] <mars> ah, so lp:foo-bar doesn't work
[19:28] <mars> but a full lp: url does
[19:28] <mars> because it just has to substitute the transport?
[19:28] <beuno> mars, because that doesn't do any guessing, it just converts "lp:" into "http://bazaar.launchpad.net/"
[19:29] <mars> ok
[19:29] <beuno> yes, and uses ssh if you have you lp=login set as well
[19:29] <beuno> it doesn't do anything server-side
[19:29] <beuno> I'm not saying this is the right solution
[19:29] <beuno> just filing you in on it
[19:37] <barry> mthaddon: still running?
[19:37] <mthaddon> barry: yep
[19:38] <barry> coolio
[19:52] <mthaddon> barry: done
[19:53] <barry> mthaddon: fab.  let me see if i can find a mailing list to look at
[19:53] <barry> (that wasn't already converted)
[19:54] <barry> mythbuntu-documentation looks good
[19:55] <barry> mthaddon: i think we're good.  thanks!
[19:55] <mthaddon> barry: cool
[20:07] <barry> sinzui: would you like to talk about this lazr.restful test?
[20:08] <sinzui> yes
[20:08] <barry> skype?
[20:11] <barry> sinzui: skype?
[20:11] <sinzui> barry: yes. I am ready
[20:43] <sinzui> kiko: My test run of my branch + allenap's + bac's rocketfuel patch is complete. Do you want me to land my branch with abentley's
[20:53] <kiko> sinzui, the branches can land separately as long as they all fit into the same BB run
[20:54] <sinzui> understood
[21:21] <kiko> abentley, yours is ready too right?
[21:21] <abentley> kiko: Yes.
[21:22] <kiko> sinzui, abentley: let's land them?
[21:22] <abentley> kiko: Okay, submitting now.
[21:25]  * sinzui submits
[21:26] <EdwinGrubbs> bac: ping
[21:26] <bac> EdwinGrubbs: hi
[21:26] <EdwinGrubbs> bac: did you see that email from salgado to us about rocketfuel-get?
[21:27] <bac> EdwinGrubbs: yes.  that's "bac's rocketfuel patch" referenced in sinzui's message up there ^.
[21:27] <bac> EdwinGrubbs: it was my blunder as i got confused moving between devel and db-devel
[21:27] <sinzui> EdwinGrubbs: bac: I am waiting for a success message from pqm now
[21:28] <EdwinGrubbs> bac: ok, I wanted to make sure that I was the only one ignoring that email.
[21:29] <bac> EdwinGrubbs: i'm not sure why you were included in the mess.  collateral damage.
[21:30] <salgado> bac, I CCed EdwinGrubbs because he was in the list of authors of that revision.  such list looks like a new feature of LP
[21:30] <bac> salgado: yeah, but i'm not sure why he was.
[21:31] <bac> salgado: 8318 was all mine:  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/revision/8318
[21:32] <bac> i'm also confused as to why i don't get db-devel  landing messages even though i'm subscribed to the branch
[21:34] <salgado> bac, are you subscribed to revision notification on that branch?  I've had problems with that too, but it was because my subscription was not properly configured
[21:34] <BjornT_> bac: you merged in some of edwin's revisions in r8318, thus it wasn't all yours
[21:35] <bac> BjornT_: ah, that's right.
[21:36] <bac> salgado: i just checked.  i have 'branch and revision notifications' turned on, send entire diff, and email all changes.
[21:37] <maxb> Hmm. Would you expect len() on a storm ResultSet to return<PHONE_NUMBER> ?
[21:50] <sinzui> abentley: my branch is in
[21:50] <abentley> sinzui: Mine is in PQM./
[21:59] <maxb> Hi - I'm trying to figure out why calling len() on an object which *claims* to be a storm ResultSet is returning 2**32-1 despite the fact that a storm ResultSet doesn't implement len
[22:00] <maxb> Can anyone suggest if the LP code is likely to have thrown a proxy around it, and how I might detect that? repr(x) and x.__class__ just say storm.store.ResultSet
[22:07] <sidnei> maxb: try from zope.proxy import isProxy
[22:07]  * maxb tries
[22:09] <maxb> yup, it's a zope proxy
[22:09] <maxb> thanks
[22:11] <maxb> bingo, looks like it's the int vs. Py_ssize_t issue as you said in #storm
[22:12] <sidnei> maxb: yeah, the proxy is written in C, so the version being used by launchpad probaby does not contain  the fix for that
[22:12] <sidnei> maxb: http://pypi.python.org/pypi/zope.proxy
[22:13] <sidnei> maxb: the version launchpad is using is roughly what was shipped as zope.proxy 3.4.0
[22:13] <maxb> Aha.
[22:14] <sidnei> maxb: luckily, gary is working on making launchpad use the eggified version of the zope.* dependencies, so it should be trivial to upgrade that after the fact. or you could submit a patch to the zope3 branch launchpad is using with that fix.
[22:17] <abentley> kiko: I got conflicts because my branch was not based on db-devel, so I missed the landing.
[22:17] <barry> sinzui: ping
[22:17] <sinzui> hello
[22:18] <kiko> abentley, it's okay, fix it up and land it for CPing
[22:18] <barry> sinzui: hi.  stepping back, i have a very simple test of just the traverseName() behavior that i need.  yay for simpler unit tests.
[22:18] <abentley> kiko: Okay.
[22:18] <barry> sinzui: how'd you like to review the branch?
[22:18] <sinzui> I would
[22:18] <barry> sinzui: cool, thanks.  i'll push and mp it to you
[22:20] <barry> sinzui: well, if code stops timing out on me ;)
[22:23]  * barry cries
[22:30] <barry> sinzui: https://code.edge.launchpad.net/~barry/lazr.restful/387487-subordinate/+merge/9263
[22:31]  * sinzui waits for diff
[22:31] <sinzui> run launchpad run
[22:31] <barry> launchpad sez: i think i can, i think i can...
[22:43] <bac> abentley: i messed up too b/c my branch was based on devel but i had to submit to db-devel.  what is the correct way to make that happen?
[23:40] <BBHoss> hey is there a serious problem with the bzr server?  I've been trying for the past three days to setup launchpad for my project (locally, on my server) and it always locks up about halfway through with the message "Fetching revisions:Inserting stream ", after a day it times out.  Is this just capacity or something else?
[23:41] <sinzui> BBHoss: If there was a problem, it was not that serious. several users have completed setup and are submitting patches.
[23:42] <BBHoss> sinzui: hmm, well i keep trying to run it, its locked up right now, just sitting there
[23:45] <sinzui> BBHoss: I think there is a network issue between you and the server. I Just pulled devel and db-devel for updates. I got changes pretty quickly. I also ran a rocketfuel-get on a machine that was two weeks stale.
[23:47] <sinzui> BBHoss: The initial pull was about 40 minutes when the repo was updated to 2a
[23:47] <mars> BBHoss, you installed bzr 1.16.1+?
[23:49] <BBHoss> mars: Bazaar (bzr) 1.17
[23:50] <BBHoss> sinzui: hmm this is in a datacenter
[23:50] <BBHoss> i'll try installing my ssh keys to see if it helps
[23:50] <mars> BBHoss, there are a few alternative ways to get the branch then
[23:52] <mars> BBHoss, you can try 'cd ~/launchpad/lp-branches'
[23:52] <mars> then "bzr branch nosmart+http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel"
[23:53] <BBHoss> alright
[23:53] <BBHoss> i'll try that after adding the ssh keys
[23:53] <BBHoss> when it asks me for the username, what does it want, my email address?
[23:54] <mars> Alternatively, you can grab the source tarball posted on the /Getting page; untar to launchpad/devel; cd launchpad/devel; bzr pull; cd ~; rocketfuel-setup again
[23:54] <mars> it wants your Launchpad username
[23:54] <BBHoss> got it
[23:55] <mars> 90% sure, I haven't logged out of bzr lp in over a year :)
[23:55] <sinzui> mars: how do you logout?
[23:56] <mars> sinzui, you probably have to tell bzr launchpad-login to use a different username
[23:57] <BBHoss> it seems to be downloading really slow
[23:57]  * sinzui nods
[23:57] <BBHoss> like 5kB/s
[23:57] <mars> BBHoss, which transport method?
[23:57] <BBHoss> most sites i download at at lest 3MB/s
[23:57] <BBHoss> this is using the rocketfuel script still
[23:57] <mars> bzr+ssh?
[23:57] <mars> ok
[23:57] <BBHoss> if it fails again i'll try the ways you suggested
[23:58] <BBHoss> every once it a while it jumps to 800kB/s
[23:58] <sinzui> BBHoss: I think I normally see about 200kB/s
[23:58] <BBHoss> i know about the buffer limitation to ssh, i hate it
[23:58] <BBHoss> but its not even getting close to that speed


[09:51] <jibel> stgraber, bug 800561 regressed on latest daily.
[09:51] <ubot2`> Launchpad bug 800561 in libxklavier "No way to add other keymap than english on Live CD" [Wishlist,Confirmed] https://launchpad.net/bugs/800561
[12:28]  * ogra_ bangs his head against the oem-config colorchange
[12:37] <ogra_> its so weird, if i run it manually i get proper colors from oem-config-remove ...
[12:43] <ogra_> hmm, i wonder if we actually run the debconf version of oem-config-remove or if we get into a weird gtk/aptdaemon fallback mode
[13:26] <stgraber> jibel: hmm, how did it regress exactly?
[13:26] <stgraber> jibel: currently you should only get the keyboard indicator when in greeter mode
[13:26] <stgraber> jibel: as all the other modes went through gfxboot and we don't want to loose the selection the user made back then
[13:27] <ogra_> hmpf ... so setting DEBIAN_FRONTEND=text in oem-config-remove makes the install hang completely after it shows 50% on serial
[13:31]  * stgraber grabs current daily to check exactly what's happening with the keyboard layout
[13:46] <jibel> stgraber, for example, select french in the greeter, the indicator lists french layout (fr, ca, ...) but no other layout can be added, 'us' for example, the '+' button is disabled.
[13:51] <stgraber> jibel: ah right, that's normal
[13:51] <stgraber> jibel: you need to remove some before you can add some more
[13:51] <stgraber> jibel: X can only support 4 layouts at a time
[13:52] <stgraber> jibel: the change I pushed yesterday was to implement that limit properly
[13:52] <stgraber> jibel: before that you'd see all of them but only the first 4 could be selected
[13:52] <stgraber> which was even more confusing
[13:53] <stgraber> so I now added some kind of logic to try and guess a good list of 4 entries for each language, we'll have to live with that for now until we can somehow get statistical data on layout usage to instead use the top-4 layouts for a given language
[13:53]  * jibel re-reads the bug report
[13:55] <stgraber> so currently the expected (from my point of view) behaviour is to only see the indicator in greeter mode, selecting a language will give you a maximum of 4 layouts and if you need some more, you'll need to remove one of them in the preferences and add another one
[13:55] <stgraber> I agree that the dialog isn't that good at explaining the limitation though, might be worth a bug for the desktop team to improve that a bit :)
[13:55] <jibel> stgraber, ok that's bad UI of gnome-control-center
[13:57] <stgraber> yeah, that's an old X limitation that gnome chose to respect (they probably could have done their own thing and not use the alternate layout xatoms) but didn't make clear to the user in their UI...
[14:02] <jibel> yep, I refreshed my memory with comment #11. UI improvement but low prio IMO.
[14:05] <stgraber> jibel: can you file a bug against gnome-control-center for the UI improvement? I don't feel like reusing the current bug report as we've been using for multiple bugs already ;)
[14:59] <GrueMaster> stgraber: Bug 567200 is still valid if the slideshow shows openoffice/libreoffice.
[14:59] <ubot2`> Launchpad bug 567200 in ubiquity-slideshow-ubuntu "On Netbook Edition installer shows apps that are not installed" [Undecided,Invalid] https://launchpad.net/bugs/567200
[15:00] <stgraber> ogra_: ^ :)
[15:01] <ogra_> we dont even have had the "netbook edition" in several releases
[15:01] <ogra_> and we use the same slideshow (if at all) that x86 uses
[15:02] <ogra_> i'm 100% sure its gone
[15:04] <stgraber> right, I'll make it clear that the slideshow is gone so there isn't anything to fix :)
[15:06]  * ogra_ roars in direction of oem-config
[15:08] <GrueMaster> I didn't know slideshow was gone (I know the netbook edition is).
[15:09] <ogra_> GrueMaster, even if it isnt, we use the same one x86 uses
[15:09] <ogra_> there is no separate package for it or anything ... (in netbook there was iirc)
[15:10] <GrueMaster> No there wasn't.  But if we are using the same slides as x86, and it contains images of LibreOffice, then it is wrong (hence my point).
[15:12] <ogra_> why, you can always install LibO
[15:15] <GrueMaster> I thought the slideshow was supposed to reflect apps on the image?
[15:17] <GrueMaster> To be honest, I rarely pay attention to the slideshow anymore.  Too busy multitasking.
[15:17] <GrueMaster> And I don't even see it in the current manifest, so nevermind.
[15:18] <GrueMaster> It is in the x86 images though.
[15:19] <GrueMaster> (maybe that should be a bug?)
[15:39] <pgraner> stgraber, do you have any idea of how to use the $resumemethod{} from a preseed to preserve an existing partition?
[15:46] <stgraber> pgraner: I only had to do it once, in this preseed http://www.stgraber.org/download/preseeds/rl-desktop-home.seed
[15:46] <stgraber> pgraner: in that example, the /home partition won't be formated and will be mounted in the target system
[15:46] <stgraber> using method{ keep }
[15:48] <pgraner> stgraber, thx let me see if I can get this working!
[15:48] <stgraber> I'm not really familiar with partman's internals but I wrote that preseed for a customer before I joined Canonical and AFAIK they're still using it and it didn't eat any of their /home yet
[15:49] <pgraner> stgraber, I have to preserve a vfat partition for arm since the bootloader and other goodies are there
[15:49] <pgraner> and it has to be the first on the disk
[15:50] <ogra_> pgraner, we used to have partman-uboot for that ... but NCommander never got to port it to panda afaik
[15:51] <ogra_> but thats exactly hoding the reciepe for keeping the first partiton intact
[15:51] <pgraner> ogra_, yea I'm trying to keep from having to install to a USB stick as /dev/sda1 and then munging the kernel and initrd on the mmc, then undoing it all so it will pxe boot when I'm done testing
[15:51] <ogra_> pgraner, though i know that GrueMaster worked out proper preseeds (he is really good at that) for netboot installs on pandas
[15:52] <ogra_> that also work withough the partman-uboot package
[15:52] <pgraner> ogra_, ack
[15:53] <ogra_> for the PXE stuff you can just dump a script into d-i's late_command that mangles your bootloader setup btw
[15:54] <GrueMaster> Actually, the partman fat bug still exists.  It can probably be worked around in preseeding, but I have dedicated usb-sata disks for my test systems (far faster anyways).  I use the SD card for u-boot and kernel only (and yes, I can fully pxe boot at will).
[16:00] <GrueMaster> Here's my preseed:  http://paste.ubuntu.com/886494/ .  Note that it points to my local mirror, but that is trivial.  It also installs openjdk-6-jre-headless for jenkins to take control on reboot.
[18:13] <stgraber> jibel: your installer terminal not updating is overlayfs' fault
[18:13] <stgraber> jibel: I duped it to bug 882147 and added a comment for that other inotify use case
[18:13] <ubot2`> Launchpad bug 882147 in linux "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147
[18:16] <jibel> stgraber, ack, that was my guess too.
[18:16]  * jibel wonders about the usefulness of this terminal
[18:17] <stgraber> well, I think it's mostly useful to show we're doing something
[18:17] <stgraber> so at the moment it's more than useless as it makes the installer look ineficient :)
[21:45] <GrueMaster> skaet: Do you have everything you need for the release manifest for armadaxp?  afaik, we are only doing a netboot armhf+armadaxp with 5yr support under ubuntu server (which is listed on the wiki).
[21:47] <stgraber> bdmurray: I just finished rewriting the lp-integration script, should be much easier to understand and change now
[21:47] <stgraber> bdmurray: I'm doing a last run, then will replace the old one in the branch
[21:47] <stgraber> (that's the launchpad integration script for the ISO tracker)
[21:50] <darien> My company has been using an unattended Ubuntu 8.04 LTS ISO for a year (which I built); I've now built a 10.04 LTS ISO as well, and included some custom packages and updates into it; however, one package I added yesterday is causing a dependency error which, near as I can tell, shouldn't happen.
[21:50] <darien> Specifically, there's no reason I can tell why it would try to install mysql-common, but in the installer syslogs it gives me 'percona-server-common: conflicts with mysql-common', even though I've never specified mysql-common to be installed and nothing that I can see depends on it
[21:51] <darien> so my question is, where can I dig more into what it's actually trying to install (and why) during the install-packages phase of the installation?
[21:52] <darien> most of the actual installer documentation (from an end-user customization point of view) is out of date, or doesn't provide any detail into the actual inner workings of the installer, which I feel like I need to understand in order to debug this
[23:41] <stgraber> bdmurray: one change is that I'm no longer looking for comments from the qatracker account in the history as that wouldn't work with multiple tracker instances as we now have
[23:42] <stgraber> bdmurray: instead I'm posting the comment before tagging the bug, if multiple tags are associated with a tracker instance, the bot will post if any tag is missing
[23:42] <stgraber> bdmurray: so the current way of avoiding the bot messing with a bug is to add bot-stop-nagging and then do any change you want to the bug