[12:04] <mdz> SteveA_: stub didn't leave until <4 hours ago, so I don't expect he'll be back for a while
[12:09] <SteveA_> mdz: i have instructions from stu on how to do all this, although i haven't done it before
[12:09] <lifeless> I was going to say, how hard is it to run ?
[12:10] <SteveA_> so, i can do this, but then, i'll be going to sleep and pretty much offline until monday evening, london time
[12:10] <mdz> kiko-sms says: tell them not to touch my code
[12:10] <SteveA_> lifeless: kill gina, nuke tables, fix gina source with vim, run gina.  that ought to do it
[12:11] <lifeless> SteveA_: so, I suggest you do that, and forward me the instructions
[12:11] <SteveA_> mdz: did you tell him it was run-on sql syntax ?
[12:11] <mdz> steveA: I told him it looked like a typo
[12:11] <SteveA_> lifeless: do you have staging access?
[12:11] <lifeless> SteveA_: hopefully. machine is what asuka ?
[12:11] <SteveA_> yes
[12:11] <mdz> mdz: kiko-sms: seriously?
[12:11] <mdz> kiko-sms: of course not
[12:11] <SteveA_> need to su to launchpad
[12:12] <SteveA_> mdz: call him a 'fogado'
[12:12] <lifeless> magic 8 ball says yes
[12:12] <mdz> SteveA_,Kinnison: do we have a credible belief that this SQL error is the cause of the abiword traceback?
[12:13] <SteveA_> mdz: i have absolutely no idea.  but the sqlerror can't be good.  but... i don't see an sql error message in the output logs
[12:13] <SteveA_> so, either the resulting sql is valid yet incorrect
[12:13] <SteveA_> or it isn't being used
[12:14] <SteveA_> lifeless: forwarded you about cleaning out gina dud data
[12:15] <SteveA_> stub SteveA: The script I'm running is /srv/launchpad.ubuntu.com/gina.sh, and the logs are going into /srv/launchpad.ubuntu.com/gina-logs
[12:15] <SteveA_> lifeless: ^^^^
[12:15] <lifeless> danke
[12:16] <lifeless> are they synced to chinstrap for folk to read ?
[12:16] <SteveA_> no idea
[12:16] <lifeless> k
[12:17] <SteveA_> i'm going to sleep now.  i'll be around briefly in about 8-9 hours
[12:17] <lifeless> k
[12:18] <SteveA_> i hope you and/or stub will have things more sorted by then, though
[01:04] <lifeless> yah
[01:04] <lifeless> I'm a placeholder only :)
[01:09] <sivang> lifeless: you're a place holder? ;)
[01:14] <sivang> eh, launchpad is down?
[01:14] <sivang> eh, came back. weird
[01:20] <Kinnison> Sorry, I have no idea what the abiword traceback is/was
[01:56] <sivang> night all
[01:56] <Kinnison> night sivang 
[03:03] <sabdfl> lifeless: how are we looking for the MoveToBazaarNG?
[03:03] <lifeless> sabdfl: good I think
[03:04] <lifeless> I'm finishing the reuse-history stuff now, to make importing everyones archives much faster
[03:04] <sabdfl> ok. seems like there have been lots of glitches and bugs fixed this weekend.
[03:04] <lifeless> hct is running in bzr now
[03:04] <sabdfl> nice
[03:04] <lifeless> yes, lots of glitches -> lots of fixes.
[03:04] <sabdfl> so all of keybuk's bugs got fixed? that's the acid tesst
[03:04] <lifeless> for hct yes.,
[03:04] <lifeless> for sourcerer when he wakes up we'll see
[03:05] <lifeless> the only worrying thing is :
[03:05] <lifeless> 20460 robertc   18   0 2952m 2.7g 1536 R 38.9 76.0  35:35.89 python                                                                                             
[03:05] <ajmitch> still running?
[03:05] <lifeless> baz import seems a little resource hungry.
[03:06] <lifeless> ajmitch: yes
[03:32] <Kinnison> spiv: ping?
[03:35] <sabdfl> jamesh: fwiw i have added a SprintAttendance.needs_discussion with UI to change it. if that is True then we'll do the discuss + draft, otherwise its drafting sessions till the sucker is approved
[03:38] <sabdfl> night all
[03:57] <mdz> Kinnison: you don't know the cause of the traceback, or you don't have the traceback itself?
[03:58] <mdz> one of those I could fix
[03:59] <stub> Gina is still running
[03:59] <stub> Still running warty too
[04:01] <stub> Oh dear.
[04:01] <stub> There appears to be some dud SQL, but it isn't raising any exceptions (?)
[04:02] <stub> Shouldn't affect this initial run since the binarypackagereleases don't exist (the query appears to be trying to determine if the BPR exists or not)
[05:10] <spiv> Kinnison: pong?
[05:14] <jamesh> lifeless: would it be possible to convert your config-manager debs to noarch?
[05:15] <jamesh> ah.  there is a C version too
[05:18] <stub> $ baz merge stuart.bishop@canonical.com/launchpad--trivial--0
[05:18] <stub> Searching for best merge point
[05:18] <stub> ..failed to query archive:
[05:18] <stub>   name: scott@canonical.com--2005
[05:18] <stub>   location: sftp://stub@chinstrap.warthogs.hbd.com/home/warthogs/archives/scott@canonical.com--2005
[05:18] <stub>   revision: launchpad--newpackageclasses--0--patch-1
[05:18] <stub> Which is interesting because that archive exists, but doesn't contain a launchpad category (!)
[05:18] <jblack> jamesh: The old C version probably doesn't support bazaar-ng
[05:19] <jamesh> jblack: yeah.  I'm on an AMD64, so was wondering why the package was i386 when the program was in Python
[05:19] <jamesh> jblack: I guess the reason is that it also includes a binary version of the program
[05:24] <jamesh> jblack: btw, did you manage to work out the google maps code?
[05:29] <jblack> jamesh: I have the email here, but haven't read it yet.
[05:29] <jblack> I'll take a look now.
[05:32] <MagicFab_Mtl> Hello
[05:35] <jblack> Doesn't look so bad. I need to figure out that person object you're using. 
[05:35] <jblack> I presume that key= is gained by registering to use the google api
[05:36] <jamesh> yeah
[05:36] <jamesh> jblack: in createMarker(), person is just an XML node
[05:37] <jblack> Yeah. Just found it. 
[05:37] <jamesh> createMap() iterates through all the elements under the root element
[05:38] <jblack> Yeah. This  will be pretty easy to use. 
[05:38] <jblack> nice code, btw
[05:39] <jamesh> about a 3rd of the javascript comes from the google maps API examples
[05:40] <jblack> I think its about time that I revisit javascript. I wasn't aware it had grown up so much.
[05:40] <ajmitch> it's actually used for real sites now :)
[05:41] <jblack> I heard about AJAX, that it was very difficult to use. This isn't any worse than using athena. 
[05:41] <jamesh> in some ways it's like PHP: while there is a lot of crap code written in the language, the language itself isn't inherently bad
[05:42] <jblack> aka xaw
[05:42] <jamesh> ajax is just a marketing term for stuff people were already doing
[05:42] <ajmitch> I think one of the first popular examples of 'ajax' was outlook web access a few years ago
[05:43] <ajmitch> it is quite useful though, when done right
[05:44] <jblack> You may laugh at this, but did you know that launchpad is currently lynxable? 
[05:44] <jamesh> ajmitch: there are plans to rip off the ideas from "google suggests" at some point ...
[05:44] <ajmitch> jblack: good
[05:44] <ajmitch> jamesh: I was hoping that was the case. bugzilla is quite slow with the huge package list loaded on every page
[05:44] <jblack> Thats what I think.
[05:45] <ajmitch> jblack: it's good for accessibility :)
[05:45] <jamesh> ajmitch: we should be off bugzilla soon :)
[05:45] <ajmitch> yay
[05:45] <ajmitch> you've been working on the imports?
[05:45] <jamesh> yeah
[05:46] <jblack> 1.4 Appropriate Conduct and Prohibited Uses. The Service may be used only for services that are generally accessible to consumers without charge.
[05:46] <jblack> Darn. There goes using gmaps for tracking my pot stash.
[05:46] <ajmitch> I've had a few months to get used to malone, with universe
[05:47] <jamesh> ajmitch: what do you think, overall?
[05:49] <ajmitch> I think it's quite good, although I miss some of bugzilla's features
[05:49] <ajmitch> which I understand bradb will be working on
[05:49] <ajmitch> mainly searching & reporting
[05:50] <ajmitch> hopefully we'll get another session to list our complaints with him at UBZ
[05:50] <ajmitch> agreed, only updating the status field is restricting
[05:52] <jamesh> I can leave a comment before or after changing the bugtask, but that means double the bugspam
[06:08] <Lathiat> also people keep using the status notes for comments
[06:08] <Lathiat> something has to be done about that
[06:18] <jamesh> Lathiat: having a box marked "comment" would help
[06:22] <Lathiat> jamesh: :)
[07:57] <carlos> morning
[09:19] <stub> lifeless: I don't think the version of pybaz in /home/warthogs/source/rollouts/pybaz supports sftp.
[09:20] <lifeless> stub: pybaz ?
[09:20] <lifeless> baz provides the network support to pybaz, and baz supports sftp fo'sure.
[09:20] <stub> Yes. So config manager can't suck down baz archives from chinstrap via sftp when I'm building from source
[09:20] <stub> Hmm...
[09:21] <lifeless> for baz archives, use 'arch://rocketfuel@canonical.com/....'
[09:21] <lifeless> check that 'pybaz abrowse rocketfuel@canonical.com' works
[09:29] <stub> No handlers could be found for logger "paramiko.transport"
[09:29] <stub> <exceptions.NameError instance at 0xb7ada64c> global name 'NotBranchError' is not defined
[09:30] <stub> Traceback (most recent call last):
[09:30] <stub>   File "/home/stub/lp/rollout/bin/cm.py", line 24, in ?
[09:30] <stub>     main(sys.argv)
[09:30] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 196, in main
[09:30] <stub>     config.build(os.path.abspath(os.curdir))
[09:30] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 57, in build
[09:30] <stub>     entry.build(dir)
[09:30] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 144, in build
[09:30] <stub>     raise ValueError("unknown url type '%s'" % self.url)
[09:30] <stub> ValueError: unknown url type 'sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/hct/1/devel'
[09:30] <lifeless> ok
[09:31] <lifeless> what revno of config-manager do you have ?
[09:32] <stub> lifeless: looks like 126
[09:32] <lifeless> garh
[09:32] <lifeless> try:
[09:32] <lifeless> bzr log sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/hct/1/devel
[09:34] <stub> That appears to be working
[09:35] <lifeless> you can see output ?
[09:35] <stub> lifeless: argh... I think I know. I set PYTHONPATH instead of PYTHON_PATH
[09:36] <stub> which is correct... now t try that log again...
[09:37] <stub> env PYTHONPATH=lib/python PATH=./bin:$PATH bzr log sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/hct/1/devel
[09:37] <stub> ------------------------------------------------------------
[09:37] <stub> revno: 151
[09:37] <stub> committer: Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>
[09:37] <stub> timestamp: Sun 2005-10-23 16:52:12 +0100
[09:37] <stub> message:
[09:37] <stub>   [trivial]  test commit of doom
[09:37] <stub> hmm...
[09:37] <lifeless> ok
[09:37] <lifeless> that looks more like it :)
[09:53] <lifeless> stub: I want to disable pqm
[09:53] <lifeless> stub: it will let the current job pass
[09:53] <stub> ok
[09:53] <stub> Just for maintenance of a few days?
[09:54] <stub> No handlers could be found for logger "bzr"
[09:54] <stub> <bzrlib.transport.sftp.SFTPTransportError instance at 0xb5f5d62c> Unable to stat '/home/warthogs/archives/rocketfuel/hct/1/devel/.bzr/weaves/11/i_automatic-ChangeLog--scott@canonical.com--2004/hct--devel--0.weave'
[09:54] <stub> Traceback (most recent call last):
[09:54] <stub>   File "/home/stub/lp/rollout/bin/cm.py", line 24, in ?
[09:54] <stub>     main(sys.argv)
[09:54] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 196, in main
[09:54] <stub>     config.build(os.path.abspath(os.curdir))
[09:54] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 57, in build
[09:54] <stub>     entry.build(dir)
[09:54] <stub>   File "/home/stub/lp/rollout/lib/python/config_manager/__init__.py", line 144, in build
[09:54] <stub>     raise ValueError("unknown url type '%s'" % self.url)
[09:54] <stub> ValueError: unknown url type 'sftp://chinstrap.ubuntu.com/home/warthogs/archives/rocketfuel/hct/1/devel'
[09:54] <stub> Traceback (most recent call last):
[09:54] <stub>   File "rollout.py", line 128, in ?
[09:54] <lifeless> for upgrading sourcerer
[09:54] <stub>   File "rollout.py", line 118, in main
[09:54] <stub>     buildConfig(config)
[09:55] <stub>   File "rollout.py", line 105, in buildConfig
[09:55] <stub>     run(cmd)
[09:55] <stub>   File "rollout.py", line 18, in run
[09:55] <stub>     raise RuntimeError('Error %d: %s' % (returncode, ' '.join(cmd)))
[09:55] <stub> RuntimeError: Error 1: cm.py build configs/configs/canonical.com/launchpad/development
[09:55] <lifeless> unable to stat
[09:55] <lifeless> the integration branch is either not being used or is stale
[09:55] <lifeless> let me check
[09:56] <lifeless> yes
[09:56] <lifeless> old
[09:56] <lifeless> pull from rollouts/bzr.integration should fix it
[09:58] <stub> Is config manager long term or a temporary solution btw? I'm wondering if it is worth fixing a few ui things (feedback, destination directory already exists)
[09:59] <lifeless> temporary, but possibly long term
[09:59] <lifeless> the big question of where some bits of code and where other bits live is still open
[09:59] <lifeless> what is definate is that bzr will have the ui for this stuff inbuilt - though that could be done by importing config_manager
[10:00] <stub> ok. I have  nothing urgent so I'll let things solidify for a bit
[10:08] <sivang> Morning all
[10:10] <stub> sabdfl, mdz: https://staging.ubuntu.com/distros/ubuntu/warty/i386/+pkgsearch?name=python
[10:12] <sivang> stub: nice, does that mean that auto building is working?
[10:13] <sivang> eh, dumb question. Probably not yet..
[10:13] <stub> sivang: That is the result of the code that imports the warty, hoary and breezy distros. We will find out if auto building is working once we have run it for real and dapper opens.
[10:14] <sivang> stub: ah, nice. So there have been some progress since last night :)
[10:14] <stub> Gina is still running, but warty has finished.
[10:14] <sivang> Kool
[10:14] <stub> actually, hoary looks like it has finished too
[10:14] <sivang> wheee
[10:14] <sivang> :)
[10:15] <lifeless> why is mark porting lead for bicyclerepair ?
[10:15] <stub> oh... no it hasn't. That is last nights log.
[10:15] <sivang> stub: gina is a big shell script right?
[10:16] <stub> python script
[10:16] <sivang> stub: ah, how many lines?
[10:16] <stub> Although it would probably have worked better if we had hired someone called Gina to type it all in.
[10:16] <sivang> hehe
[10:16] <stub> Dunno. Our code tree is somewhat integrated.
[10:17] <stub> Gina calls hunks from the main code base - she isn't stand alone
[10:18] <sivang> Is she is repsonsible for importing from the "old" archive of source packages, into the new one, and then rebuild it there?
[10:19] <stub> Just importing the data into the database
[10:20] <stub> analyzing the distribution, extracting all the meta data, stuffing it into the database. Badly in roberts bicyclerepair example.
[10:21] <stub> lifeless: I think Mark is porting lead for everything. Busy boy.
[10:21] <lifeless> its python
[10:21] <lifeless> it does not NEED portin
[10:21] <lifeless> stub: 
[10:21] <lifeless> https://staging.ubuntu.com/distros/ubuntu/warty/i386/bicyclerepair/0.9-3
[10:21] <lifeless> *BOOM*
[10:22] <lifeless> (not logged in)
[10:27] <stub> Bug filed.
[10:37] <lifeless> heh
[10:39] <uws> yuck
[10:39] <uws> launchpad.net seems down!
[10:39] <lifeless> ?
[10:40] <uws> Is that planned?
[10:41] <uws> Hmmm
[10:41] <uws> seems like a local problam; it works fine from another box
[10:41] <lifeless> ah
[10:44] <Keybuk> heh
[10:44] <Keybuk> is it bad that a major reason to wipe and reinstall my laptop before UBZ is now that I can checkout launchpad fresh from bzr rather than trying to convert each branch one-by-one? :p
[11:46] <koke> hi all!
[11:47] <koke> I was wondering why there's no direct download for po files in rosetta?
[11:47] <jordi> there is
[11:48] <ajmitch> hi koke, jordi 
[11:48] <koke> jordi: by "direct" I meant direct, not through mail :)
[11:50] <mdke> i guess the primary reason is that it takes a few minutes to generate the files
[11:50] <jordi> koke: no
[11:50] <jordi> hello andrew
[11:50] <jordi> koke: all file downloads are done via librarian.
[11:50] <koke> I saw it at the url in the email
[11:50] <koke> :)
[11:51] <koke> but I'm not sure what does that mean
[11:51] <carlos> koke, as mdke points, it takes too much time to generate the .po file 
[11:53] <koke> but sometime ago it was possible
[11:54] <carlos> koke, we had to remove that feature because people thought the download was taking too much time and requested it again
[11:55] <carlos> and sometimes, if the .po file is big (like evolution) it would timeout before we were able to generate the export
[11:55] <koke> what about some caching?
[11:56] <carlos> koke, we do it atm
[11:57] <carlos> but the performance problem is still there for the first time the cached file is generated
[11:57] <koke> can I hope a search feature for rosetta? :)
[11:57] <carlos> koke, yes
[11:58] <carlos> koke, https://launchpad.net/products/launchpad/+specs
[11:58] <carlos> there is one spec about searching
[11:58] <carlos> it's a priority so should be implemented soon, but I cannot give you a concrete date
[12:03] <lifeless> stub: I presume you dont want gina twice : pqm.ubuntu.com
[12:04] <lifeless> I've removed the second one:0
[12:04] <stub> Hmm... the first one was submitted ages ago. Must have been stuck in a mailq somewhere (ages as in well before you took PQM down)
[12:06] <lifeless> :)
[12:09] <stub> $ bzr branch $brf/launchpad/devel tstlp <-- Sitting there for 10 minutes so far downloading stuff with no feedback
[12:16] <sabdfl> oops
[12:17] <sabdfl> morning all, what's news on the RoadToProduction?
[12:17] <ajmitch> morning sabdfl 
[12:18] <sabdfl> stub: i think we should process some uploads against the system on staging before opening dapper on it
[12:18] <stub> gina looks like she imported warty, died in the 'd's in hoary, and is still chewing on breezy
[12:19] <stub> sabdfl: Sounds sane, but I have no idea at this stage what is involved.
[12:20] <sabdfl> jamesh: did you see my comment around SprintAttendance getting some metadata? needs_discussion (boolean) and status (int: submitted, approved, declined)?
[12:21] <jamesh> sabdfl: yeah
[12:22] <sabdfl> stub: just involves setting up a buildd on staging, maybe even some other arch ones. Kinnison says that's a cynch (apt-get install new-buildd or something like that)
[12:23] <stub> ok
[12:24] <stub> Or even run them on mawson where they are already setup, talking to the staging database on asuka.
[12:24] <stub> Kinnison: ^^^
[12:25] <sabdfl> Znarl: do you think we can allow connections from asuka to three of the buildd's (one for each architecture)?
[12:26] <lifeless> stub: is your linkchecker branch in bzr yet ?
[12:26] <Lathiat> rm, has anyon noticed failures to login, often without erroring?
[12:26] <Lathiat> i've had a couple times in the last half hour gone to login, ende dup back were i was with no login
[12:26] <stub> lifeless: No. I ctrl-C'd when launchpad was being converted, remember? 
[12:27] <lifeless> stub: oh right.
[12:27] <lifeless> stub: the optimised import is ready.
[12:27] <stub> So I should do a full conversion now? ok.
[12:27] <lifeless> stub: (its on the wiki, short version is 'baz-import stubs-archive stubs-archive ../rocketfuel')
[12:27] <lifeless> note the new parameter at the end
[12:27] <stub> ok
[12:27] <lifeless> that tells it where to get bulk history from
[12:28] <Kinnison> stub: in lib/canonical/buildd you run "dpkg-buildpackage -rfakeroot -b" and that spits out a launchpad-buildd deb
[12:28] <Kinnison> stub: you install that on a box which you want to become a buildd
[12:28] <stub> Kinnison: Which I can't do since I can't install .debs. Need the elmster involved for that.
[12:28] <Kinnison> right, and the dogfood buildds are firewalled off
[12:29] <Znarl> sabdfl : No, but I'll create an RT job for elmo to do it.
[12:31] <stub> I'll move onto buildd once we are happy with Gina
[12:31] <Kinnison> gina dying in hoary in the ds isn't good
[12:31] <Kinnison> what happened there?
[12:32] <Kinnison> also, that BPR thing will break part of what we were trying to make sure wouldn't happen
[12:32] <Kinnison> I.E. replication
[12:32] <Kinnison> did you fix the SQL error, blow the contents away and restart it?
[12:41] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Gina fixes (patch-2711: stuart.bishop@canonical.com)
[12:45] <lifeless> who runs gina these days ?
[12:45] <Kinnison> stub
[12:45] <lifeless> stub: ping
[12:45] <stub> ?
[12:45] <lifeless> sorry
[12:46] <lifeless> dilys
[12:46] <lifeless> who runs dilys
[12:46] <lifeless> too many chicks.
[12:46] <lifeless> wheres 'roger' ?
[12:46] <stub> who you calling a chick rentboy?
[12:46] <lifeless> dilys and gina, lease-kid
[12:49] <Kinnison> dilys is a dog
[12:49] <Kinnison> ya daft antipodean
[12:49] <Kinnison> she's daf's IIRC
[12:54] <lifeless> yes
[12:54] <lifeless> but I have not seen daf in 3 months
[12:54] <lifeless> so I'm hoping *someone* can give dilys some bzr-log message love
[12:56] <carlos> lifeless, daf has dilys' code available, not sure if at chinstrap or at his personal archive
[12:56] <lifeless> k
[12:57] <lifeless> I'll mind that in bear
[01:04] <matsubara> good morning!
[01:11] <lifeless> stub: your config updates will probaby clash
[01:11] <lifeless> stub: merge in my branch to yours now:)
[01:12] <stub> lifeless: Those are launchpad.conf configs, not config-manager configs
[01:12] <lifeless> ah
[01:12] <lifeless> right
[01:12] <lifeless> robert, engage eyes
[01:12] <lifeless> hmm
[01:12] <lifeless> production 38 eh
[01:12] <lifeless> guess I should un-remove that
[01:13] <stub> I think my merge has hung :-(
[01:22] <cprov> hi lp-hackers
[01:23] <stub> Just tool 1 hr and 6 minutes to branch bazaar integration locally
[01:24] <stub> And 39 minutes to branch hct
[01:25] <Lathiat> is it just me or is that stupidly long...
[01:26] <sabdfl> stub: https://chinstrap.ubuntu.com/~dsilvers/paste/filewHrbtq.html
[01:26] <stub> Yup. Works great locally but the network operations need some tuning
[01:26] <sabdfl> comments too
[01:26] <Lathiat> stub: lots of back and forthing?
[01:27] <stub> Dunno
[01:27] <stub> sabdfl: So going for a NULL priority to mean not set? or n/a? or both?
[01:28] <sabdfl> not set
[01:29] <stub> sabdfl: ok. patch-25-45-0.sql
[01:30] <sabdfl> stub: i'm sure you gave that out last night
[01:30] <sabdfl> last time you gave me a patch number it conflicted, so i'm jumpy :-)
[01:31] <stub> kiko got 44
[01:31] <stub> Nothing on this channel log says 45 was taken...
[01:32] <sabdfl> ok
[01:32] <stub> You can have 46 instead if you like ;)
[01:33] <lifeless> Lathiat: latency figure * revision count overhead
[01:34] <lifeless> Lathiat: ok-big-O, but a bad constant multiplier for some folk.
[01:34] <lifeless> planned to fix for 0.7
[01:34] <stub> lifeless: Is it possible to train config-manager to fetch stuff using rsync?
[01:34] <stub> as a short term fix?
[01:34] <lifeless> stub: yes. The easiest way is to use the rsync
[01:35] <lifeless> transport for bzr
[01:35] <Lathiat> lifeless: cool
[01:35] <lifeless> stub: but full checkouts are a rarity, and push is rsync based.
[01:35] <stub> so change sftp://chinstrap.ubuntu.com/blah blah to rsync://chinstrap.ubuntu.com/blahblah ?
[01:35] <lifeless> thats the sort of thing we can do. the rsync: plugin needs some love though, its not currently effective
[01:36] <stub> lifeless: Until we have switch it will be common
[01:36] <lifeless> stub: we have switch, in two parts - push and pull --clobber
[01:36] <stub> ok.
[01:36] <lifeless> push to *there*, give me a branch from *there*
[01:36] <lifeless> soon to be pull --overwrite or something
[01:38] <stub> I think the fastest way for people to bootstrap though is to build the tree on chinstrap and rsync it down.
[01:38] <stub> Which would save everyone a few hours with their initial launchpad checkouts.
[01:41] <lifeless> works for me
[01:42] <mpt> Gooooood morning
[01:44] <sabdfl> hey mpt
[01:44] <mpt> hi Mark
[01:45] <mpt> The big switchover's happened?
[01:46] <lifeless> check out pqm.ubuntu.com
[01:47] <mpt> cool
[01:47] <mpt> ah, rocketfuel not till Wednesday
[01:47] <mpt> so I do need to rebuild my tree after all
[01:47] <lifeless> well
[01:47] <lifeless> if you are not going to land until after wednesday
[01:47] <lifeless> you can use bzr now
[01:48] <lifeless> and merge in the changes done between now and the final baz commit when I migrate them to bzr
[01:48] <lifeless> :)
[01:48] <lifeless> bbiab
[01:49] <mpt> hmmmmm, tempting
[01:49] <sabdfl> mpt: i would suggest letting others crack shins on it for the moment
[01:49] <sabdfl> tempting as it is :-)
[01:49] <sabdfl> there have been glitches
[01:50] <mpt> ok
[01:51] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  BinaryPackageFix for gina when running without --all (patch-2712)
[01:52] <mpt> BjornT: did you get my bug listings merged into your branch ok?
[01:52] <matsubara> lifeless: I've merged now and conflicted four files: CA  lib/hct
[01:52] <matsubara> CA  lib/psycopgda
[01:52] <matsubara> CA  lib/sourcerer
[01:52] <matsubara> CA  lib/sqlos
[01:52] <matsubara> . Do you know what that means?
[01:53] <BjornT> mpt: no, ran out of time on friday. it's merging now, though, so i'll probably land it today.
[01:53] <mpt> matsubara, there was a configs error or something so that the symlinks are pointing to the wrong place
[01:53] <mpt> you need to fix them manually
[01:54] <matsubara> how?
[01:54] <mpt> once you're in lib/
[01:54] <mpt> e.g. ln -s ../sourcecode/sqlos sqlos
[01:54] <matsubara> thanks
[01:54] <stub> Either change all the 'lib' strings to 'sourcecode' in configs/canonical.com/launchpad/development or migrate to the bzr dists tree
[01:54] <stub> oh... that is if you want to build a new tree
[01:56] <carlos> stub, not really, I'm using the bzr dists tree with bazaar
[01:56] <carlos> launchpad is bazaar, and dists is bzr
[01:56] <matsubara> what am I supposed to do with the .orig and .rej files?
[01:58] <matsubara> rename them with baz mv?
[02:00] <sivang> BjornT: I saw your specs about TicketTrackerEmailInterface, most of it should be applicable to SpecTracker, what do you think?
[02:07] <carlos> stub, around?
[02:07] <carlos> stub, I need some help with a DB constraint
[02:08] <BjornT> sivang: yeah, probably. for example, it'd be nice if review requests generated an email notification, and the reviewer simply could respond to the notification and give his review comments.
[02:10] <sivang> BjornT: opened a bug about that, too :)
[02:11] <BjornT> sivang: cool :)
[02:11] <stub> carlos: sure
[02:12] <carlos> stub I have this: CHECK ((productseries IS NULL) <> (distrorelease IS NULL) AND ((distrorelease IS NULL) = (sourcepackagename IS NULL)));
[02:12] <carlos> stub, and I want to update it to add an extra field 'fromsourcepackage'
[02:13] <carlos> stub, that should be NULL if distrorelease is NULL and could be anything else but 'sourcepackage' if distrorelease is not null
[02:14] <Kinnison> stub: I'm not sure what that gina error is about
[02:15] <matsubara> ls
[02:16] <carlos> stub, where I wrote distrorelease you can read sourcepackagename. And 'sourcepackage' means 'sourcepackagename', sorry 
[02:16] <stub> carlos: alter the existing check for the NULL -- CHECK (productseries IS NULL <> distrorelease IS NULL) AND (distrorelease IS NULL = sourcepackagename IS NULL = fromsourcepackage IS NULL)
[02:17] <carlos> stub, but that means that fromsourcepackage must be not null if sourcepackagename is not null and that's not true
[02:17] <stub> start again please?
[02:17] <carlos> ok
[02:18] <carlos> I have a new field 'fromsourcepackagename' that could get any value, from NULL to any integer, if sourcepackagename is NOT NULL
[02:18] <carlos> and it must be NULL if sourcepackagename is NULL
[02:20] <stub> ADD CONSTRAINT valid_fromsourcepackagename CHECK (sourcepackagename IS NOT NULL OR fromsourcepackagename IS NULL)
[02:21] <Kinnison> stub: well, doc-linux-hr definitely doesn't have a format statement in the Sources file
[02:21] <Kinnison> stub: interesting
[02:22] <carlos> stub, yeah, seems much more simple than adding it to the other constraint. Thank you
[02:22] <Kinnison> jennifer shouldn't have let it through
[02:22] <Kinnison> hmm, no elmo
[02:24] <lifeless> stub: can you please update wiki rfsetup and movtobazng pages as you find things to tune ?
[02:24] <lifeless> stub: I'm very close to it - blinded by the wall :0
[02:24] <stub> ok
[02:25] <salgado> stub, you got mail
[02:28] <carlos> see you later
[02:29] <stub> salgado: Any ideas?
[02:29] <salgado> stub, to workaround the problem or why it would happen only in staging?
[02:30] <stub> I assumed it was happening on staging due to a) new code landing and b) the timeout is deliberately set lower than production
[02:31] <stub> salgado: We need a workaround or we will start seeing it on production too
[02:31] <salgado> stub, can't it be caused only by the slower timeout on staging?
[02:32] <stub> salgado: The front page is too slow. If staging is triggering it most of the time, then we will see it some of the time on production
[02:33] <stub> Especially as table sizes increase. If it isn't new code on staging, it is because the datasets are growing and there is something nonscalable going on.
[02:34] <salgado> stub, is there a way to see what query is timing out?
[02:34] <salgado> the /errors page still not accessible on staging
[02:34] <stub> You get the tracebacks if you are logged in as an administrator
[02:35] <stub> I don't know if Steve organized mirroring of the logs - I haven't
[02:35] <lifeless> no
[02:35] <lifeless> erm
[02:35] <lifeless> for gina no
[02:35] <lifeless> for normal logs I think so
[02:36] <salgado> well, in production I get the tracebacks by being a member of launchpad. but in staging I get only that RequestExpired page
[02:37] <stub> Indeed :-(
[02:37] <stub> I'll pull it from the logs and paste
[02:37] <stub> SELECT Person.id, Person.defaultrenewalperiod, Person.postcode, Person.subscriptionpolicy, Person.merged, Person.displayname, Person.password, Person.name, Person.familyname, Person.datecreated, Person.calendar, Person.teamdescription, Person.givenname, Person.country, Person.addressline2, Person.addressline1, Person.city, Person.emblem, Person.hackergotchi, Person.phone, Person.teamowner, Person.defaultmembershipperiod, Person.timezone, Person.province, Perso
[02:38] <salgado> Person.province, Pers
[02:38] <salgado> nothing after that
[02:39] <stub> https://chinstrap.ubuntu.com/~dsilvers/paste/filePZs4nM.html
[02:39] <stub> No idea what would be doing that :-(
[02:41] <salgado> it must be the topPeople() method. but that has a "limit 5", which is not there
[02:41] <salgado> oh, no. it's not
[02:42] <salgado> that's a call to getByName(). it's retrieving the launchpad team to check if you're a member of it
[02:42] <sabdfl> stub: is there any way to get the binarypackagerelease.binarypackagename.name added to binarypackagerelease.fti?
[02:42] <sabdfl> without triggers?
[02:43] <sabdfl> and without duplicating the .name field on the bpr itself?
[02:47] <stub> sabdfl: No. Also that is a trick question, as the only way the fti columns get populated is by triggers.
[02:48] <sabdfl> oh. ok, and there's no way to make the trigger add the binarypackagename.name?
[02:48] <stub> sabdfl: It is just hidden as fti.py does all the heavy lifting and hides it from you
[02:48] <stub> sabdfl: Yes. It involves me rewriting fti.py
[02:49] <sabdfl> stub: ok, so i'll just leave that aside for now then
[02:49] <stub> Yup. Just query both tables - it is quick.
[02:50] <mpt> I'm too dumb
[02:58] <salgado> stub, so, it's always that query the one that times out?
[02:59] <salgado> stub, and btw, isn't that query supposed to run almost instantaneously?
[03:07] <stub> salgado: It is fast. Something else must be chewing up time before that query is run (eg. some really bad zpt), or it is being run a very large number of times.
[03:07] <stub> salgado: I suspect I will need to comment out sections of the front page to narrow down what is taking the time
[03:09] <salgado> stub, try commenting the +portlet-foaf line first
[03:10] <benpi> Hi
[03:11] <benpi> I've a question for wich I didn't found any answer either in Launchpad wiki or by googling around
[03:11] <benpi> Is Launchpad (and Malone/Rosetta/.. components) expected to be released as free software ?
[03:11] <benpi> If yes, is this publicly announced ?
[03:12] <benpi> or stated by a person of authority ?
[03:15] <makx> the form for shipit has tough constraints regarding the length of it's entries
[03:15] <makx> "Institut fr Informationswirtschaft" didn't fit in :-P
[03:15] <benpi> I'm reluctant to contribute without such an assurance about the software to be free...
[03:15] <makx> anyway i shorted the entry.
[03:18] <salgado> makx, that's a restriction imposed by the shipping company, so there's nothing we can do about that. :-(
[03:20] <makx> salgado: can't you add a third optional input element for the address?
[03:20] <makx> should be negociable :-P
[03:34] <kiko> benpi, yes, it is expected to be released as free software
[03:34] <kiko> benpi, it's still at a very conceptual stage and therefore needs a lot of design work and discussion
[03:35] <benpi> kiko : thanks for the answer
[03:36] <kiko> benpi, we're very much interested in external contribution, just haven't managed to deliver enough to provide what I consider architectural integrity and plausible promise
[03:37] <kiko> hey elmo, thanks for the staging work on saturday, much appreciated
[03:37] <kiko> stub?
[03:38] <Nafallo> kiko: is there an ETA on dapper? :-)
[03:38] <kiko> Nafallo, mdz and sabdfl are best to ask for that
[03:39] <Nafallo> kiko: ah, doesn't dep-wait gina then? :-)
[03:39] <sabdfl> kiko: what was the result of the staging run?
[03:39] <kiko> sabdfl, I don't know yet, but would like to
[03:39] <kiko> I don't have access to staging myself
[03:40] <kiko> I'd love to have the log to take with me on the plane
[03:40] <benpi> kiko : I can understand that, it's better to release with a relatively stable architecture/API, for contributors sake 
[03:40] <benpi> but is this aim stated by an authoritative person somewhere ?
[03:41] <kiko> benpi, yes, it is.
[03:41] <sabdfl> https://staging.ubuntu.com/distros/ubuntu/hoary/powerpc/+pkgsearch?name=camera
[03:41] <sabdfl> so, there are packages
[03:42] <sabdfl> but are they all there?
[03:42] <sabdfl> Kinnison: how can we certify the import as golden?
[03:42] <kiko> sabdfl, not all, definitely, but I want to see how many we failed, and why.
[03:42] <Kinnison> sabdfl: package counts would be a good start
[03:42] <Kinnison> sabdfl: gina reports what she fails to import
[03:42] <Kinnison> sabdfl: so that'd be good
[03:42] <Kinnison> plus making sure gina runs without reporting any errors
[03:42] <sabdfl> kiko, Kinnison: can we do a publish off of staging, and compare packages files?
[03:43] <sabdfl> i'd like to see if there are patterns in that data
[03:43] <Kinnison> Yep, we could
[03:43] <Kinnison> does staging have the disk to do it?
[03:43] <kiko> Kinnison, are you ordering the Sources and Packages files?
[03:43] <Kinnison> kiko: we sort the file lists by basename (in theory)
[03:43] <kiko> they were unordered when we checked on dogfood but I think that was old
[03:43] <kiko> Kinnison, mdz suggested the correct sorting was by package name and then by basename
[03:44] <Kinnison> well, elmo and I checked the source
[03:44] <Kinnison> we sort by basename
[03:44] <Kinnison> in both katie and CAP
[03:44] <kiko> okay, cool.
[03:44] <kiko> then that's fine
[03:44] <kiko> that was the thursday patch, right Kinnison?
[03:44] <kiko> btw
[03:44] <kiko> does anyone want anything from brazil?
[03:44] <Kinnison> the thursday patch?
[03:44] <kiko> last chance for a slow dance
[03:44] <kiko> yep
[03:44] <Kinnison> kiko: cachassa
[03:45] <kiko> a patch that landed thursday == the thursday patch
[03:45] <kiko> Kinnison, I'll see what I can do
[03:45] <Kinnison> kiko: and some of those milk sweets
[03:45] <kiko> Kinnison, doce de leite?
[03:45] <Kinnison> yeah, or perhaps tapoica
[03:45] <Kinnison> whatever you can bring
[03:46] <kiko> naked chicks perhaps
[03:46] <Nafallo> lol
[03:46] <Nafallo> I thought you were going to _work_ at UBZ? ;-)
[03:46] <Kinnison> unless they fold up real small
[03:46] <kiko> when they hatch they are small
[03:46] <Kinnison> true
[03:47] <sivang> kiko: can you bring Mel Lisboa with you?
[03:48] <sivang> ^^^^^^^
[03:48] <kiko> hmm
[03:48] <kiko> she would need folding
[03:48] <sivang> hehe
[03:48] <sivang> and a big coat
[03:51] <benpi> kiko : tanks for reassuring me
[03:56] <sivang> kiko: how do I change a spec name I created? specname/+admin ?
[03:56] <kiko> sivang, yes.
[03:57] <sivang>  Sorry, you don't have permission to access this page.
[03:57] <Nafallo> lol
[03:57] <sivang> ( Logged in as Sivan Greenberg)
[03:57] <Nafallo> sivang: you better file a bug ;-)
[03:57] <sivang> Nafallo: not sure, I don't think +admin is even documented in anywhere :)
[03:58] <Nafallo> sivang: so that makes it less of a bug? :-)
[03:59] <sivang> hehe, let's see what kiko says
[03:59] <sivang> kiko: specname=setup-snapshots
[04:00] <stub> I think my outgoing email is being delayed
[04:01] <stub> Kinnison, sabdfl, kiko: Gina logs are in chinstrap:~stub/gina-logs
[04:01] <kiko> woo thanks
[04:01] <stub> Summary is warty ran, hoary and breezy died with the same exception
[04:01] <Kinnison> Yeah, looks like bits of hoary/breezy lack Format: headers in the sources
[04:01] <kiko> stub, okay
[04:02] <kiko> Kinnison, I've fixed that already
[04:02] <Kinnison> kiko: aah right
[04:02] <kiko> it's in PQM
[04:03] <stub> I've also done a second run of gina, which ran quickly.
[04:03] <stub> Which is good ;)
[04:03] <sabdfl> kiko: when you look for the DSC, is that optional?
[04:03] <sabdfl> if you don't find it, it just leaves the Build.changes as NULL?>
[04:07] <sabdfl> Kinnison: can you and stub work on getting builders setup for staging, so we can run some test dapper builds?
[04:07] <sabdfl> also, what's the plot w.r.t. opening dapper - do we copy all the publishing records over from breezy so dapper starts out looking just like breezy?
[04:07] <kiko> sabdfl, the DSC is not optional, no.
[04:08] <sabdfl> kiko: looks like we don't have them in a bunch of places
[04:08] <kiko> a package without a DSC is AFAIK invalid
[04:08] <kiko> sabdfl, I'll look into that -- steve as saying the files were actually there
[04:08] <Kinnison> sabdfl: that was my plan, yes
[04:08] <sabdfl> Kinnison: do you have a script that does that?
[04:08] <sabdfl> i'd like to test it on staging now
[04:08] <Kinnison> sabdfl: No, I was just going to do some SQL
[04:09] <sabdfl> Kinnison: please scriptify
[04:09] <sabdfl> should be trivial
[04:09] <Kinnison> okay
[04:09] <sabdfl> but since it has to be done regularly, it should be possible to get it right
[04:09] <sabdfl> hmm
[04:09] <sabdfl> here's a suggestion
[04:09] <sabdfl> the distrorelease has a parentrelease
[04:09] <sabdfl> add a .initialiseFromParent method
[04:10] <sabdfl> that should (a) check if there are any packages published, and if so, quit
[04:10] <sabdfl>  (b) do the Right Thing w.r.t. copying over from the parent
[04:10] <sabdfl> i think it would be fine to ignore pockets
[04:10] <sabdfl> but do all architectures for which there is an architecture in the parent
[04:10] <Kinnison> I was told to anyway. I.E. only ever inherit the RELEASE pocket
[04:10] <sabdfl> sonds good
[04:11] <Kinnison> okay I'll start work on that right away
[04:11] <sabdfl> thanks
[04:11] <sabdfl> any word back from elmo or Znarl w.r.t. test buildd's for staging today?
[04:11] <stub> Kinnison: ping me when you are online tomorrow and we can hook up some buildds to asuka
[04:11] <Kinnison> stub: right, can-do
[04:12] <sabdfl> so, we are still on track to open on soyuz tomorrow (late-ish I imagine)
[04:12] <elmo> I closed the ticket an hour ago
[04:12] <elmo> sabdfl and stub were cc'ed
[04:13] <elmo> the buildds can see port 80 on asuka now, and asuka can see them
[04:13] <kiko> sabdfl, who is that question going out to? 
[04:13] <sabdfl> elmo: superb, thanks, stub / Kinnison will that cover the new-style buildd's?
[04:13] <stub> yer. I need to open Postgres up to the buildds but I will need details and I assume Kinnson is playing with other things right now.
[04:13] <sabdfl> kiko: all takers
[04:13] <Kinnison> stub: the buildds don't look at pgslq
[04:13] <Kinnison> stub: they only need librarian access and archive access
[04:13] <sabdfl> stub: it's an xmlrpc interface
[04:14] <stub> oh? Well that is all running then
[04:14] <sabdfl> Kinnison: what port does asuka need to see on the buildd's?
[04:14] <elmo> stub: err, say what now?
[04:14] <Kinnison> 8221
[04:14] <sabdfl> elmo: can you let asuka see port 8221 on the buildd's that you have provisioned, and install the newfangled build tools on them?
[04:15] <kiko> sabdfl, well, gina didn't even run completely on hoary and breezy. I need to check her logs, to see what I can fix in short notice. and I am concerned the archive will miss many packages.
[04:15] <sabdfl> kiko: i'm still running on your confidence from yesterday. i suspect a few common failure modes will account for the glitches
[04:15] <elmo> sabdfl: asuka can see port 8221; kinnison has 3 buildds of his own, surely that's enough for testing?
[04:15] <sabdfl> let's just keep iterating on gina
[04:16] <kiko> Kinnison, have you ever done a test uploading all breezy packages through the uploader and looking at the resulting archive?
[04:16] <sabdfl> elmo: 1 buildd on each arch is fine
[04:16] <Kinnison> kiko: I've verified that the uploader handles the uploads elmo produced as test-data for me
[04:16] <kiko> Kinnison, that's not what I asked -- the /whole/ breezy archive?
[04:16] <kiko> yeah, gina copes with those too
[04:17] <kiko> hmmm
[04:17] <Kinnison> it would be a seriously non-trivial thing to set up to run
[04:17] <sabdfl> guys, rolling new stuff to production is always hard, lets just keep plugging at it and i'm sure we will make good progress today and tomorrow
[04:17] <elmo> the whole breezy archive is available  to test upload on rockhopper
[04:17] <sabdfl> worst case, elmo, can we bring up dapper on katie?
[04:17] <elmo> sabdfl: in 5 minutes
[04:17] <kiko> quite a large chance of it blowing up when processing the real-world data
[04:19] <kiko> elmo, could I get access to staging so I can verify the archive? it seems to be missing files
[04:20] <elmo> kiko: done
[04:20] <sabdfl> Kinnison: can you set staging to do regular publishes of its archive, please?
[04:20] <kiko> thanks
[04:20] <Kinnison> sabdfl: sure
[04:20] <Kinnison> elmo: can i have access to staging too please?
[04:20] <sabdfl> so in theory, as gina improves, we see the archive converging on what's at archive.ubuntu.com
[04:20] <elmo> sigh
[04:20] <kiko> sabdfl, the problem with the dropped packages was exactly what I suggested: curl produces packages in both main and universe.
[04:20] <sabdfl> curl?
[04:21] <Kinnison> kiko: yes, this is a common occurrence
[04:21] <elmo> isn't great how our "minimal accounts" policy goes flying out the window as soon as we hit headless chicken mode
[04:21] <kiko> 09:18:43 ERROR   Error processing package files for libcurl3-gssapi
[04:21] <kiko>  -> http://librarian.staging.launchpad.net/1120840/1120873/cXgYtEtZOoaIjbnN5180ZKAj1nu.txt (File curl_7.14.0-2ubuntu1.1.dsc not in archive (/srv/archive.ubuntu.com/ubu
[04:21] <kiko> ntu/pool/universe/c/curl/curl_7.14.0-2ubuntu1.1.dsc))
[04:21] <Kinnison> elmo: natch.
[04:21] <kiko> sabdfl, we need a function to search for the dsc in all components
[04:21] <sabdfl> elmo: can you add "kick everybody off again" to the "reattach head to chicken" script?
[04:21] <Kinnison> given gina was importing fine before, what have you done which broke her?
[04:21] <elmo> Kinnison: done
[04:21] <sabdfl> Kinnison: she needed a little correction here and there
[04:22] <kiko> Kinnison, har har har
[04:22] <Kinnison> elmo: thanks
[04:22] <kiko> Kinnison, gina wouldn't have processed 1/3 of what she did this time
[04:22] <kiko> Kinnison, this isn't a case that made her blow up -- just failed to import a file.
[04:24] <kiko> stub, can you re-run gina with my latest patch?
[04:24] <Kinnison> how do I connect to the staging database?
[04:25] <kiko> I think you ran her with my first patch, which blows up with missing attributes (this is now tested)
[04:25] <kiko> stub, she will run through the whole archive most likely, with some ERRORs
[04:25] <kiko> stub, or wait for pqm
[04:25] <kiko> she's 3rd in queue
[04:26] <kiko> christian.reis@canonical.com--lozenge/launchpad--devel--0--patch-235
[04:26] <kiko> stub, all tests pass ;)
[04:28] <stub> kiko: You forgot to mirror I think
[04:28] <kiko> stub, doh
[04:28] <kiko> doing now
[04:29] <Kinnison> stub: How do I connect to the staging db ?
[04:30] <Kinnison> elmo: do I need sudo to something?
[04:30] <stub> launchpad user has access. I can give your normal user access if you need it.
[04:31] <Kinnison> I imagine I'll need to become the launchpad user
[04:31] <Kinnison> in order to set up and check the publishing
[04:31] <Kinnison> etc
[04:31] <stub> Gina's going again
[04:31] <kiko> thanks stub 
[04:32] <kiko> mirrorred
[04:32] <stub> kiko: way ahead of you
[04:32] <elmo> stub needs to ok people being able to sudo to launchpad, AFAIC
[04:33] <elmo> for who? :P
[04:33] <elmo> or just anyone...
[04:33] <Nafallo> mememe ;-)
[04:34] <stub> Kinnison: Do you just need database access or to mess with the source tree being used by launchpad/gina etc?
[04:36] <Kinnison> uhm, full access will stop me stumbling
[04:36] <Kinnison> in case anything hiccoughs
[04:38] <stub> elmo: Give kinnison sudo to launchpad.
[04:38] <elmo> done
[04:38] <Kinnison> thanks
[04:39] <stub> kiko: Are you going to cry if you don't get sudo access?
[04:39] <kiko> stub, nope.
[04:40] <stub> Gina's tearing through the archive
[04:41] <kiko> roxor
[04:41] <kiko> man
[04:42] <kiko> I can not find ONE small package to test this @#$!@!#@! multiple-component cruft
[04:42] <kiko> sigh
[04:48] <Kinnison> Right, I've added the lucille config
[04:48] <Kinnison> I'll attempt to publish to /srv/launchpad.ubuntu.com/staging-archive
[04:48] <Kinnison> okay?
[04:48] <stub> salgado: Good call. Commenting out the foaf portlet fixes the timeouts on the front page
[04:48] <kiko> rock on
[04:49] <salgado> stub, can you paste the PersonSet.topPeople() method we have running in production?
[04:50] <jamesh> kiko: firefox has stuff in main and universe, but I guess that doesn't count as small
[04:51] <Nafallo> kiko: curl isn't small enough? :-)
[04:51] <stub>     def topPeople(self):
[04:51] <stub>         """See IPersonSet."""
[04:51] <stub>         return Person.select('password IS NOT NULL', orderBy='-karma')[:5] 
[04:51] <Nafallo> kiko: xpdf? shorewall?
[04:51] <kiko> Nafallo, the smaller the better
[04:52] <sabdfl> stub: is pqm jammed on your request?
[04:52] <Nafallo> kiko: well, you got three rather small ones suggested now ;-)
[04:52] <kiko> shorewall!
[04:53] <kiko> shorewall didn't fail though, hmmm
[04:53] <salgado> stub, could you try to use this on staging (uncommenting the foaf portlet)? this is not what is running on staging now
[04:59] <stub> salgado: I can't test that now without killing other testing going on
[05:00] <kiko> use staging2 ;)
[05:01] <stub> kiko: I'll need another box or the extra CPU and ram back in this one first. Asuka is creaking except for its disk.
[05:01] <kiko> yeah
[05:01] <Kinnison> 1.3G published so far
[05:01] <elmo> you guys know about drescher right?
[05:01] <elmo> just like, checking
[05:02] <kiko> who's she
[05:02] <elmo> .5Tb, 2 CPU, 4 GB memory...
[05:02] <elmo> it was kind of designed for exactly this purpose, not sure why y'all are so insistent on last-minute-ing it on asuka ..
[05:03] <salgado> stub, this is probably the query that is causing the timeout on staging's front page: https://chinstrap.ubuntu.com/~dsilvers/paste/fileT0t89b.html
[05:04] <salgado> stub, is it possible to optimize it?
[05:04] <elmo> OTOH, if you want to continue, we can borrow CPU + memory from another machine, if that's going to be easier
[05:06] <stub> elmo: Never heard of it
[05:06] <kiko-fud> scripts/ftests/gina_test_archive$ du -s
[05:06] <kiko-fud> 11482	.
[05:06] <kiko-fud> aiee
[05:06] <kiko-fud> anyway, fud, bbiab
[05:08] <stub> salgado: Not that I can see
[05:15] <sivang> elmo: fran dreshcer ?
[05:18] <Kinnison> http://www.awi-bremerhaven.de/Polar/Drescher.html
[05:19] <sivang> Kinnison: nice
[05:20] <stub> salgado-lunch: I can get it faster by adding some indexes and dropping the 'name' from the sort order
[05:20] <sabdfl> stub: pqm?
[05:21] <stub> seems to be processing happily. Chinstraps load of 8 is slowing things down.
[05:26] <Kinnison> 11G of source published
[05:26] <Kinnison> preparing the binaries
[05:27] <Nafallo> Kinnison: no breakage yet? :-)
[05:28] <Kinnison> Nafallo: nup the publisher is paranoid
[05:28] <Kinnison> it'll stop the moment it hiccoughs
[05:28] <sivang> Kinnison: I take it it's looking good? :)
[05:29] <Nafallo> :-)
[05:32] <Kinnison> Well, it's not looking *bad* per-se :-)
[05:36] <sivang> Kinnison: I prepared some pasta and italia tomato sauce 
[05:37] <Kinnison> for me? how kind
[05:38] <Nafallo> :-)
[05:39] <Kinnison> stub: this import, is it multi-arch?
[05:39] <stub> Kinnison: yes
[05:39] <stub> The three majors
[05:42] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Production and staging config updates (patch-2713: stuart.bishop@canonical.com)
[05:46] <kiko-fud> finally
[05:47] <kiko-fud> stub, can you get me the logs for these runs when they succeed?
[05:47] <stub> kiko-fud: /srv/launchpad.ubuntu.com/gina-logs
[05:50] <kiko-fud> stub, ah, on asuka?
[05:50] <stub> yes
[05:53] <Kinnison> up to 22G on the publishing run
[05:55] <stub> Bed!
[05:56] <Kinnison> stub: when are you likely to be around?
[05:56] <stub> about 8 hours time
[05:56] <stub> ?
[05:59] <Kinnison> stub: rock on
[05:59] <Kinnison> stub: sleep well
[05:59] <kiko-fud> stub, Kinnison: is gina actually running?
[06:00] <kiko-fud> no log output is changing
[06:00] <stub> it is running. I think the publisher is holding a lock atm
[06:01] <kiko-fud> ah,ok.
[06:01] <Kinnison> initial publishing runs are a bit painful :-(
[06:01] <Kinnison> I ought to try and work out how to do it without holding a transaction locked
[06:05] <Kinnison> I guess I could alter it to do a pre-fetch without ever writing to the db, to ensure the transaction is short-lived
[06:07] <Kinnison> well, short-lived in the 5 minutes or so sense
[06:07] <Kinnison> urgh, publishing is hard
[06:08] <kiko-fud> I'm outta here to catch a plane, will check in late tonight
[06:08] <kiko-fud> montreal wednesday
[06:08] <kiko-fud> call me or sms me if you need me
[06:08] <kiko-fud> but you won't -- gina's golden! :)
[06:10] <Nafallo> yay!
[06:13] <Kinnison> CAP dominating
[06:14] <Kinnison> overriding...
[06:14] <Kinnison> collating file lists
[06:16] <Kinnison> kaboom
[06:16] <Kinnison> :-(
[06:18] <sivang> Kinnison: what's CAP ?
[06:19] <Kinnison> canonical archive publisher
[06:19] <Kinnison> I.E. launchpad's archive publishing tool
[06:19] <sivang> Kinnison: I see
[06:21] <mdz> Kinnison: how goes it?
[06:22] <Kinnison> mdz: well, it's publishing (running apt-ftparchive now)
[06:23] <Kinnison> I'm a little concerned that the archive is a bit small
[06:23] <Kinnison> but that's probably because gina hasn't finished yet
[06:24] <zyga> sabdfl: what is the approximate time of UVF for dapper?
[06:25] <Kinnison> mdz: I.E. so far there's only 30G of archive being output by CAP
[06:32] <koke> jordi: where did we talked about translating CoC??
[06:42] <mdz> Kinnison: are there components/architectures/bits of the archive which are finished publishing?
[06:43] <mdz> Kinnison: and where can I see it?
[06:44] <Kinnison> it's in /srv/launchpad.ubuntu.com/staging-archive on asuka
[06:45] <Kinnison> one sec
[06:45] <Kinnison> When in non-careful mode it won't write out configs for the frozen distroreleases
[06:45] <bradb> BjornT: Do you have time for a drive-by code review of a patch that does some serious +filebug cleanup? (16 files changed, 104 insertions(+), 173 deletions(-))
[06:45] <Kinnison> so we don't constantly recreate the Packages files for warty etc
[06:46] <BjornT> bradb: sure, send it to me
[06:49] <Kinnison> mdz: whatever the outcome of the current publisher run, I'll have to go and cook dinner in about 10 minutes tops
[06:50] <bradb> BjornT: cool, thanks, sent.
[06:50] <Kinnison> or I'll have ravenous hordes baying at me
[06:50] <mdz> Kinnison: I don't have access to askuka
[06:51] <Kinnison> mdz: aah
[06:51] <Kinnison> elmo: can we expose that archive over http ?
[06:51] <mdz> er, asuka
[06:52] <mdz> Kinnison: what was the outcome of the previous test?
[06:53] <Kinnison> mdz: which test?
[06:54] <Kinnison> when I was running on dogfood I was happy with the archives it was producing
[06:54] <mdz> Kinnison: the one which was running on staging the last time I was around
[06:54] <mdz> or is this still the same run?
[06:54] <mdz> since yesterday?
[06:55] <Kinnison> Uhm, do you mean gina or the publisher?
[06:55] <Kinnison> gina is running fresh
[06:55] <Kinnison> the publisher hasn't been tried on staging before
[06:55] <mdz> at the time I had to leave, gina hadn't finished yet, so the publisher hadn't run 
[06:56] <mdz> gina is running fresh because the previous one failed?
[06:56] <Kinnison> I'm not entirely sure
[06:56] <mdz> how about this: "what was the outcome of the most recently concluded test of the whole ball of wax?"
[06:56] <Kinnison> kiko and stub were talking about it
[06:57] <Kinnison> that gina was broken
[06:57] <mdz> ok
[06:57] <mdz> thanks
[07:00] <Kinnison> I'll know more in about 20 minutes
[07:05] <elmo> exposed as http://staging.archive.ubuntu.com/
[07:07] <Kinnison> elmo: thanks dude
[07:07] <Kinnison> sorry about this
[07:07] <mdz> Kinnison: {warty,hoary,breezy,dapper}/source are all empty
[07:07] <mdz> er, /main/source
[07:08] <Kinnison> mdz: yes, current publishing run is gonna fix that
[07:08] <Kinnison> mdz: apt-ftparchive is in-progress
[07:23] <bayr00t> carlos? jordi? you around?
[07:24] <bayr00t> can u help me by uploading translation templates into rosetta
[07:28] <bradb> BjornT: how's the +filebug refactor patch looking?
[07:29] <BjornT> bradb: you'll get a mail soon, there are a few things i want you to do.
[07:29] <bradb> ok, cool
[07:32] <carlos> bayr00t, I'm here
[07:33] <carlos> bayr00t, did you see https://wiki.ubuntu.com/RosettaFAQ ?
[07:35] <bayr00t> carlos: i'll read it now
[07:36] <carlos> bayr00t, thanks
[07:36] <bayr00t> carlos: and then i have to add the sftwr here: https://wiki.ubuntu.com/RosettaPendingImports
[07:37] <carlos> bayr00t, yeah, that way Jordi will handle faster your request
[07:43] <mdz> Kinnison: is apt-ftparchive still running?  there still doesn't seem to be any source published yet
[07:44] <elmo> 1000     30064  2.9 51.6 1677764 1062456 ttyp5 S+   17:46   1:41  |               \_ python scripts/publish-distro.py --careful ubuntu
[08:05] <lucas> hi
[08:06] <lucas> is there a way to send a mail to all members of a team ?
[08:09] <salgado> lucas, currently, no
[08:10] <sabdfl> ok, guys time for an update on the gina situation
[08:10] <lucas> ok
[08:10] <sabdfl> Kinnison: what are you seeing in the archive?
[08:11] <tirian> When can I find a tutorial for moving an exsisting project over to Bazaar/Launchpad?
[08:12] <elmo> apt-ftparchive is still running
[08:14] <Kinnison> aye it is
[08:14] <Kinnison> sorry, had to go shopping
[08:14] <Kinnison> dinner is in the oven so it's fairly hands-off noce
[08:14] <Kinnison> erm s/noce/now/
[08:17] <tirian> Can anyone help me? I'd really like to use Bazaar, but I'm not sure how to begin.
[08:17] <LaserJock> Is it possible to see what bugs I am subscribed to on launchpad? 
[08:17] <mdz> sabdfl: so far I still don't see anything published, though I've just been polling */main/source periodically
[08:18] <mdz> elmo: still, as in from over an hour ago?
[08:18] <elmo> mdz: yes
[08:18] <mdz> my word
[08:18] <elmo> on an unloaded machine, apt-ftparchive from scratch takes an  hour or two
[08:18] <elmo> and that's assuming --no-contents
[08:19] <elmo> (unloaded == this class of HW), (from scratch == without cached package information)
[08:19] <Kinnison> this is no-contents
[08:19] <Kinnison> but gina is running in the background
[08:19] <Kinnison> so it's not unloaded
[08:19] <Kinnison> each universe is taking between 20 and 30 minutes
[08:20] <Kinnison> s'on dists/warty/main/source now
[08:22] <mdz> Kinnison: are we able to estimate gina's progress?
[08:23] <Kinnison> ooh, apt-ftparchive finished
[08:23] <Kinnison> she's somewhere in hoary
[08:24] <mdz> we have something resembling warty
[08:24] <Kinnison> shall I re-run CAP to gather up all she's done so far?
[08:27] <mdz> Kinnison: it looks like the comparison used for the sort isn't quite compatible; it seems to sort foo-bar ahead of foo, while the existing indexes do the opposite.  not a problem for the tools of course, but makes it less convenient to compare them
[08:28] <Kinnison> odd
[08:29] <Kinnison> files.sort(key=os.path.basename)
[08:29] <Kinnison> is what I do
[08:29] <Kinnison> should I instead do something to extract just the package name?
[08:30] <LaserJock> sorry to bother, but can anybody point me to any lauchpad or Malone documentation/instructions?
[08:30] <mdz> Kinnison: dunno; what does katie do? apt-sortpkgs?
[08:30] <mpt> tirian: Try #bzr
[08:31] <mdz> Kinnison: the only delta between staging's warty/main/source/Sources and the production one is that debian-installer has a Priority: header
[08:31] <elmo> katie  sorts by pkg name
[08:31] <Kinnison> jenna seems to sort by full pathname
[08:32] <elmo> hmm, yeah, so she does
[08:32] <elmo> lets pretend I said that instead
[08:32] <Kinnison> so she'll sort blah/libfoo before dooby/dooby
[08:33] <Kinnison> okay so CAP should sort by full pathname instead
[08:33] <Kinnison> that's an easy enough fix
[08:33] <Kinnison> I'll do that once it's finished running
[08:33] <Kinnison> mdz: which is lacking the Priority header?
[08:34] <mdz> Kinnison: yours
[08:34] <Kinnison> mdz: Odd
[08:34] <mdz> Kinnison: but other than that, it looks spot on so far
[08:34] <Kinnison> mdz: phew
[08:35] <mpt> LaserJock: Sorry, there's no way of getting such a list, that's https://launchpad.net/products/malone/+bug/2713
[08:35] <Kinnison> mdz: can you look at some d-i ?
[08:35] <Ubugtu> Error: I cannot access this bug
[08:35] <mpt> kiko, is there a good reason for bug 2713 to be private?
[08:35] <Ubugtu> Error: I cannot access this bug
[08:35] <mdz> Kinnison: the best test would be to do a netboot install from this archive
[08:35] <Kinnison> mdz: Well, if you've got the kit, can you go for it?
[08:35] <Kinnison> mdz: natch I'd wait until this cap run is done
[08:36] <mdz> Kinnison: that won't be possible until it has d-i stuff in it
[08:36] <mdz> (installer-*)
[08:36] <Kinnison> mdz: and so far it doesn't?
[08:36] <Kinnison> oh right
[08:36] <elmo> the best test would surely be that the dists/ on staging and archive are bit for bit, wouldn't it?
[08:36] <Kinnison> the tarballs
[08:36] <Kinnison> elmo: aye, diffing the dists/ on staging and archive is best
[08:36] <Kinnison> give me a sec
[08:36] <mdz> elmo: all the .gzs will differ, as will Release
[08:37] <elmo> mdz: meh, sure - bit  for bit after decompression and excluding checksums of compressed files in Releases
[08:37] <mdz> elmo: that sounds like what I'm doing, then
[08:38] <mdz> can breezy debootstrap still debootstrap warty?
[08:38] <mdz> I guess it ought to
[08:39] <mdz> Kinnison: is that going to use an apt-ftparchive cache from the last run, I hope?
[08:41] <Kinnison> yes
[08:41] <Kinnison> apt-ftparchive caches are kept
[08:41] <Kinnison> otherwise we'd never manage the 30 minute cycle ;-)
[08:41] <Kinnison> Of course, it is adding a sod load more stuff so it might not be instant :-)
[08:42] <Kinnison> well, dinner
[08:55] <mdz> elmo: what would be the most straightforward way for me to get a verbatim copy of the staging dists/ to use for comparisons?
[08:56] <Kinnison> more dinner
[08:57] <elmo> mdz: I've made it available via rsync from the LAN
[08:58] <elmo> is that sufficent?
[08:58] <elmo> or do you need it from the net?
[08:58] <LarstiQ> hello
[08:58] <mdz> elmo: rsync on the LAN is fine, thanks
[09:00] <Kinnison> ProgrammingError: ERROR:  deadlock detected
[09:00] <Kinnison> grah
[09:00] <Kinnison> might have to wait a bit until I can kick off CAP again
[09:00] <Kinnison> gina is getting busy
[09:05] <einheit> hi
[09:06] <SteveA> mdz: hi.  what's new?
[09:10] <mdz> SteveA: getting to the point where we can start to run some meaningful tests on the published archive
[09:21] <fabbione> so what distro is completed in staging?
[09:21] <fabbione> i can run a netinstall using the miniso to boot
[09:21] <fabbione> and fetch the rest from it
[09:21] <fabbione> s/it/staging
[09:23] <mdz> fabbione: warty
[09:23] <mdz> fabbione: but there is no d-i
[09:23] <mdz> does the mini iso have all of d-i?
[09:24] <fabbione> i think so
[09:24] <fabbione> i can still netboot from the local archive and ask d-i to fetch the rest from staging
[09:26] <fabbione> the only thing you can't test without d-i is the stage1 install
[09:26] <fabbione> at the end of that, apt-setup will ask for the mirror again
[09:26] <fabbione> still better than no test at all
[09:32] <mdz> Kinnison: Sources.bz2 are missing
[09:39] <mdz> -Section: multiverse/net
[09:39] <mdz> +Section: multiverse/multiverse/net
[09:40] <mdz> Bugs and Origin seem to be missing
[09:43] <sabdfl> hey all
[09:43] <fabbione> hey sabdfl 
[09:45] <sabdfl> mdz: something resembling warty?
[09:45] <bradb> mpt: around?
[09:46] <mpt> bradb: yo
[09:47] <bradb> mpt: I was hoping to get your opinion on the new navigation portlet, and how we can help the users really kick ass with it, while trying to stay within the limits of what launchpad can currently do (i.e. LP doesn't have a good way of finding a target on which to file a bug yet)
[09:47] <bradb> URL coming up...
[09:48] <bradb> mpt: http://69.70.209.33:8086/products/firefox/+bugs
[09:49] <bradb> disclaimer: the nav portlet *only* works for upstreams right now
[09:49] <mdz> Kinnison: the sorting still seems to be off as well; should I not expect that fix to have propagated yet?
[09:50] <bradb> mpt: so, a couple of things: 1. what do you think of it? 2. how would you expect it to work on distro-side (just jump to packages?) 3. should there maybe be a dropdown to allow you to jump between upstream and distro-side things?
[09:50] <bradb> i guess that's one more than a couple
[09:50] <Kinnison> mdz: haven't managed a complete run since I made that change
[09:51] <Kinnison> mdz: gina keeps deadlocking CAP
[09:51] <mpt> bradb: 1. I don't understand it
[09:51] <mdz> Kinnison: did you see the multiverse stuff I pasted above?
 -Section: multiverse/net
 +Section: multiverse/multiverse/net
[09:51] <Kinnison> the bz2 stuff I have a fix for but it's not on asuka yet
[09:51] <bradb> mpt: the point of it is to help you navigate between contexts.
[09:52] <mdz> multiverse Packages is full of that
[09:52] <Kinnison> that section stuff I'm not sure what happened
[09:52] <bradb> mpt: e.g. right now, if you're looking at launchpad bugs, and decide you want instead to see malone bugs, what do you do?
[09:52] <mpt> bradb: hack the URL :-/
[09:52] <bradb> precisely
[09:52] <bradb> this is the anti URL hacking portlet
[09:52] <mpt> not really
[09:53] <mpt> it doesn't appear in Rosetta, does it
[09:53] <mpt> or in the spec tracker
[09:53] <mdz> Kinnison: Priority seems to be missing for many packages in universe
[09:53] <bradb> mpt: no, right now it's only for bugs
[09:53] <SteveA> so, you're talking about getting to other products from the same project
[09:53] <Kinnison> mdz: that's very odd indeed because priority is in the db for everything
[09:53] <Kinnison> mdz: how does main look?
[09:53] <mdz> Kinnison: I don't see any binaries for main yet
[09:53] <Kinnison> joy
[09:53] <mdz> i386, powerpc and amd64 all empty
[09:54] <mdz> 0-byte Packages, not missing entirely
[09:54] <mpt> bradb: A trivial fix would be to change "Other:" to "Other product:"
[09:54] <Kinnison> Okay, the section stuff appears to be because gina isn't stripping the component off the front of the section
[09:54] <bradb> SteveA: ideally, you could get to any context from anywhere
[09:54] <SteveA> bradb: i don't think so
[09:54] <Kinnison> we can fix that up post-hoc
[09:54] <bradb> mpt: yeah, but that's part of my question to you :)
[09:54] <SteveA> bradb: see, if you offer someone all of that choice, it is too much for them
[09:54] <bradb> mpt: is, *should* the UI perhaps be such than you can jump anywhere, just just within upstreams or within distro-side things?
[09:54] <SteveA> bradb: you need to offer someone a short list of things they're likely to be interested in
[09:54] <mdz> I'll update my mirror
[09:54] <Kinnison> mdz: I think we need for gina to complete so CAP can run unhindered
[09:54] <SteveA> bradb: and then the ability to go farther if needed
[09:55] <bradb> SteveA: yep, that's precisely what that portlet does
[09:55] <sabdfl> Kinnison: we're going to open dapper on katie now
[09:55] <mdz> ah, there are binaries there now
[09:55] <sabdfl> we'll keep working with staging
[09:55] <Kinnison> sabdfl: Oh :-(
[09:55] <bradb> SteveA: when you start using Malone, that portlet grows a bit to present you a list of things you've been working with already
[09:55] <mdz> the diff is very hard to read due to the sorting issue though
[09:55] <sabdfl> though i think drescher is possibly a better bet
[09:55] <Kinnison> sabdfl: right
[09:55] <Kinnison> sabdfl: so what's the game plan?
[09:55] <sabdfl> we will run it in parallel this week, and transition next week if at all possible
[09:55] <Kinnison> Right
[09:55] <Kinnison> when we're all in one place
[09:56] <Kinnison> it'll be good to all be on the same timezone
[09:56] <sabdfl> yes. i'd like to get onto launchpad as soon as we are confident in it with real world data
[09:56] <Kinnison> Right
[09:56] <sabdfl> elmo will save the dapper uploads
[09:56] <Kinnison> So we'll replay them in?
[09:56] <sabdfl> so we will test your "open dapper" script, publish, then push in the dapper uploads, in order
[09:56] <sabdfl> yes
[09:56] <sabdfl> build
[09:56] <mpt> bradb: if this exists at all, it seems like it should belong in the hierarchy at the top
[09:56] <sabdfl> upload
[09:56] <sabdfl> build
[09:56] <sabdfl> upload
[09:56] <sabdfl> etc
[09:56] <Kinnison> sabdfl: coolio
[09:56] <mpt> e.g. as a panel
[09:56] <mpt> hmmmm
[09:57] <mdz> right, if we can get the basics in shape in the next day or two, we can run a full week in parallel and start to catch the more subtle stuff
[09:57] <bradb> mpt: "at the top" of what?
[09:57] <mpt> bradb: the page, where it says "Products"
[09:57] <mpt> perhaps
[09:57] <Kinnison> mdz: aye, that sounds good
[09:57] <bradb> mpt: like the breadcrumbs, you mean?
[09:58] <mpt> bradb: built in to them, perhaps
[09:58] <mpt> but
[09:58] <mpt> one improvement you could make now
[09:58] <mpt> is to put this at the bottom of the bug listing
[09:58] <mpt> instead of in a blue box
[09:59] <bradb> mpt: if i understand correctly, doesn't that mean making it invisible without scrolling?
[09:59] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  Add fixes for three issues: MissingRequiredAttributes was failing a check, coping with absent Format correctly, and dealing with a null ChangeLog in different situations. (patch-2714: christian.reis@canonical.com)
[09:59] <mpt> Show bug reports about product: [                    ] 
[09:59] <mpt> (Recent: _foo_, _bar_, _hum_)
[10:00] <mpt> bradb: It's already invisble without scrolling
[10:00] <bradb> it's perfectly visible in 1024x768 without scrolling, as best i can tell
[10:00] <mpt> bradb: this is bottom-of-the-page material, i.e. where do you want to go *next*
[10:01] <mpt> You use a fullscreen window?
[10:01] <bradb> no, even in 800x600 i see it
[10:01] <bradb> like, 2/3's of it
[10:01] <bradb> and that's considering that we've officially given up on 800x600 too :)
[10:02] <mpt> I'm not talking about moving it to a place so that it's visible
[10:02] <mpt> I'm talking about making it not a portlet so that it's visible.
[10:02] <Kinnison> mdz: CAP is managing to run this time, so we should get some updated dists soon
[10:02] <bradb> mpt: that seems like good reasoning to me. but, really, at the *bottom*?
[10:03] <mpt> bradb: At the moment, *at the moment when you want to use it*, it's probably scrolled off the top of the window.
[10:03] <mdz> Kinnison: are you making notes of the problems I've mentioned here, or should I file bugs?
[10:03] <Kinnison> mdz: file bugs where you can please
[10:03] <mpt> bradb: I.e. when you've gone through the bug list and realized that you're looking at the wrong product.
[10:03] <Kinnison> mdz: against launchpad-publisher
[10:03] <Kinnison> heyhey kiko
[10:04] <kiko> ahoy
[10:04] <kiko> airport wifi rocks
[10:04] <kiko> what's up?
[10:04] <Nafallo> hi kiko :-)
[10:04] <sabdfl> kikoman!
[10:04] <Kinnison> kiko: gina's not stripping component from Section: in non-main packages files
[10:04] <Kinnison> kiko: sux
[10:05] <kiko> Kinnison, that's odd. I /just/ looked at that code -- it checks if there's a "/" in it.
[10:05] <kiko> Kinnison, can you give me an example?
[10:05] <kiko> heya sabdfl 
[10:05] <kiko> I have a testcase for our dsc-missing issue. now to fix it.
[10:05] <Kinnison> 20:39 < mdz> -Section: multiverse/net
[10:05] <Kinnison> 20:39 < mdz> +Section: multiverse/multiverse/net
[10:06] <bradb> mpt: do you think this idea is going to help the user kick ass, or should i just abandon it now?
[10:06] <kiko>                 if "/" in v:
[10:06] <kiko>                     # When a "/" is found in the section, it indicates
[10:06] <kiko>                     # component/section. We don't want to override the
[10:06] <kiko>                     # component, since it is correctly indicated by the
[10:06] <kiko>                     # packages/sources files.
[10:06] <kiko>                     self.section = v.split("/", 1)[1] 
[10:06] <bradb> mpt: (if, say, we tried it at the bottom at first)
[10:06] <kiko> Kinnison, is this for binary or source packages?
[10:06] <Kinnison> kiko: binaries 
[10:06] <kiko> ah!
[10:06] <kiko> sucks.
[10:06] <mdz> Kinnison: incoming
[10:07] <Kinnison> mdz: got it, ta
[10:07] <mpt> bradb: This could be an interesting addition to https://launchpad.net/products/malone/+bug/3152
[10:07] <Ubugtu> Malone bug #3152: Provide prominent links from product bug listing to package bug listings Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3152
[10:07] <kiko> Kinnison, mdz: fixing now.
[10:08] <mdz> Kinnison: installer-* is not expected to work yet, right?
[10:08] <kiko> man there is a queue as long as the chinese wall here at the airport
[10:08] <kiko> they had better not delay my flight
[10:08] <Kinnison> mdz: installer-* is what comes out of the debian-installer.tar.gz files, yes?
[10:09] <bradb> mpt: is it me, or do users have *no* *idea* of the difference between a product and a source package?
[10:09] <mdz> Kinnison: correct
[10:09] <Kinnison> mdz: gina doesn't import thouse
[10:09] <kiko> bradb, that sounds about correct
[10:09] <Kinnison> mdz: instead we'll pre-seed the archive with a copy from katie
[10:09] <bradb> and i'm worried that we've got current UI that relies on thinking that the user actually *does* understand the difference!
[10:09] <mpt> bradb: it's not just you :-)
[10:09] <Kinnison> mdz: the uploader handles them as byhandish things
[10:09] <kiko> Kinnison, that's interesting, because there is code in the packages map that parses the d-i files if they exist.
[10:09] <Kinnison> mdz: Kamion wrote a routine for processing them automatically
[10:09] <kiko> Kinnison, should it be nuked?
[10:09] <mpt> bradb: yup, it's not quite as bad as expecting them to understand a "pocket", but still pretty bad :-)
[10:09] <mdz> Kinnison: worth getting that into Malone as well?
[10:10] <Kinnison> kiko: that's not installer-* that's debian-installer
[10:10] <bradb> mpt: hehe
[10:10] <Kinnison> kiko: and ffs don't nuke it
[10:10] <kiko> oh.
[10:10] <kiko> Kinnison, it's untested.
[10:10] <Kinnison> kiko: untested?!
[10:10] <kiko>             # XXX: untested
[10:10] <kiko>             # Run over the D-I stanzas and store info in tmp_bin_map.
[10:10] <kiko>             dibinaries = apt_pkg.ParseTagFile(info_set.binfile)
[10:10] <kiko> yes :)
[10:10] <Kinnison> urgh
[10:10] <Kinnison> mdz: Nope because gina doesn't do it and shouldn't
[10:11] <Kinnison> mdz: It's part of the byhand acceptance process in katie and it is such in launchpad
[10:11] <Kinnison> mdz: although we actually process it automatically as a raw-installer rather than anything else :-)
[10:12] <bradb> kiko: is gina setting up proper packaging relationships?
[10:13] <bradb> i.e. between sp's/upstream
[10:13] <kiko> nope
[10:13] <kiko> how could she?
[10:14] <bradb> who builds the packaging link between upstream and distro?
[10:14] <kiko> people, aiui
[10:15] <bradb> is there UI somewhere that I can look at to get a sense of whether people are actually doing this or not?
[10:15] <kiko> I believe there's UI in the product pages
[10:16] <Kinnison> bradb: well, there's 233 Packaging records in the stagng DB
[10:16] <bradb> this could make it much less realistic/worthwhile to implement bug #3152's fix
[10:16] <Ubugtu> Malone bug #3152: Provide prominent links from product bug listing to package bug listings Fix req. for: malone (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3152
[10:16] <SteveA> lifeless: ping
[10:17] <kiko> SteveA, isn't he on a plane?
[10:17] <SteveA> maybe
[10:17] <SteveA> don't they have wireless on planes now?
[10:18] <mpt> only on one or two airlines
[10:18] <Kinnison> lufthansa have it
[10:18] <sivang> Kinnison: they do? nice
[10:18] <mpt> bradb: Naturally such links won't be present as long as all these females still haven't finished their work
[10:18] <bradb> Kinnison: thanks for the stats, btw
[10:19] <Kinnison> bradb: np
[10:19] <LarstiQ> SteveA: he was rather tired when packing, so I'm guessing he is sleeping on the plane
[10:19] <mpt> bradb: wrt the context switching, see the "Your Recent History" section that's right at the bottom of amazon.com pages after you've been browsing for a while
[10:19] <SteveA> LarstiQ: thanks
[10:21] <bradb> mpt: 100% invisible to me
[10:21] <lifeless> SteveA: I am waiting to board
[10:22] <lifeless> I have no life, as proven by my logging in here
[10:22] <bradb> along with 98% of the other content they throw on their pages, which i guess is why the Big J notes that Amazon is *not* a good example of an e-commerce site to copy :)
[10:22] <bradb> of course, at the bottom of a Malone page it would be more visible
[10:22] <SteveA> lifeless: hi
[10:24] <SteveA> lifeless: privmsged you
[10:24] <lifeless> k
[10:25] <bradb> mpt: so, would you agree that the following two things are useful to show on every bug page: 1. a list of recent bug "homepages" you've visited and 2. a way of quickly switching to another bug context without hacking a URL?
[10:26] <LarstiQ> is there currently a way to follow all activity in a given product, and not just (individual) bugs?
[10:26] <mpt> bradb: not really
[10:26] <mpt> bradb: At least, I'd regard that as much less important than many other things that currently aren't on the bug page
[10:27] <mpt> sorry
[10:28] <mpt> LarstiQ: No, it's planned but not implemented yet <https://wiki.launchpad.canonical.com/ProductSubscriptions>
[10:28] <bradb> I have a feeling the users will tell a different story at UBZ. I'll predict the URL-hacking-as-navigation is going to lower a user's self-esteem pretty rapidly. :)
[10:29] <LarstiQ> mpt: thanks
[10:30] <mpt> bradb: the non-URL-hacking way of doing it is to click "Products"
[10:30] <mpt> and there really are more grief-reducing things in Malone that could be done right now
[10:31] <mpt> e.g. https://wiki.launchpad.canonical.com/ProductSubscriptions
[10:31] <bradb> How is that going to reduce the grief of the guys at UBZ?
[10:32] <mpt> bradb: It's not about UBZ in particular, it's just the thing that people are asking for a gazillion times more than they're asking for anything else
[10:32] <LarstiQ> I will not be at UBZ, but I'm comfortable with url hacking for the moment, fwiw
[10:32] <mpt> with the possible exception of an easy way to mark bug reports as fixed
[10:32] <bradb> heh
[10:36] <mpt> "The requested page is protected. You will need to login.
[10:36] <mpt> You have been logged in"
[10:36] <bradb> mpt: realistically, we should probably be focussing on the Ubuntu guys the most right now, right? i.e. I'm wondering if PackageSubscriptions is the next major feature I should implement.
[10:38] <mpt> bradb: Well from what I've been seeing and reading, it's the thing that's frustrating people most
[10:38] <mpt> but it's quite possible I'm reading the wrong things
[10:38] <lifeless> ok
[10:38] <mpt> e.g. sabdfl says he's getting comments from people who love Malone
[10:38] <lifeless> I'm about to get cut off
[10:38] <lifeless> buh-ey
[10:38] <mpt> buh-bye
[10:39] <bradb> mpt: wait, I'm confused: the Ubuntu guys are telling you they want ProductSubscriptions more than PackageSubscriptions?
[10:39] <kiko> man
[10:39] <kiko> why is archive-mirror so slow
[10:39] <kiko> ffs
[10:39] <mpt> bradb: How do you think "the Ubuntu guys" are different from anyone else?
[10:39] <bradb> mpt: i.e. the distro use case vs. the upstream one
[10:39] <mpt> bradb: No, ProductSubscriptions and PackageSubscriptions and ProjectSubscriptions should be one and the same thing
[10:40] <SteveA> bug 3538
[10:40] <Ubugtu> Malone bug #3538: paramiko doesn't notice the user in my ssh config Fix req. for: bzr (upstream), Severity: Normal, Assigned to: Nobody, Status: New http://launchpad.net/malone/bugs/3538
[10:41] <mpt> kiko, do you see any reason for bug 2713 to be private?
[10:41] <Ubugtu> Error: I cannot access this bug
[10:42] <SteveA> mpt: i know how to fix the login problem.
[10:42] <SteveA> mpt: and i'll be doing so shortly.
[10:42] <mpt> great, thanks SteveA
[10:42] <SteveA> mpt: it isn't a malone-specific issue
[10:42] <mpt> SteveA: Will you have time to review the design-fascism this week?
[10:42] <bradb> Kinnison: you're the assignee for PackageSubscriptions. do you mind if I assign myself to it (adding it to LP right now)?
[10:43] <Kinnison> Go for it
[10:43] <bradb> ok
[10:44] <ajmitch> bradb: don't worry, I'll make sure the MOTU team chimes in with a few requests as well for you :)
[10:44] <bradb> ajmitch: will you be at UBZ?
[10:44] <ajmitch> yep
[10:44] <bradb> excellent
[10:45] <ajmitch> at last count there were 5 or 6 of the MOTU team that would be there
[10:45] <ajmitch> and we've been using malone a lot by now
[10:46] <bradb> cool
[10:47] <mpt> bradb: Sorry, I guess we were talking at cross-purposes a bit -- I was regarding ProductSubscriptions and PackageSubscriptions and ProjectSubscriptions as being a single thing
[10:47] <gneuman> productrelease to edit it goes to /productname/productreleasename instead of product/productcseriesname/productrelease?
[10:47] <mpt> bradb: They should certainly have an identical design on the page
[10:47] <mpt> bradb: and the data model should be pretty close, too
[10:47] <bradb> mpt: from the user perspective, they probably are. from the imp. perspective, it's useful to think in terms of what's the most important of those to start on right now, IMHO
[10:48] <bradb> so, package sub's it is
[10:48] <mpt> ok
[10:48] <ajmitch> bradb: I'd say our main issues would be navigation & searching, as expected 
[10:48] <bradb> heh
[10:48] <bradb> indeed
[10:50] <sivang> mpt: I think this one bradb mentions should not be overlooked, I myself find it annoying sometime to have to hack-URL my way to switch between filebug on Ubuntu and Launchapd
[10:51] <mpt> sivang: sure, but you can click on the "Products" link, so IMO it's not as important as things that aren't discoverable at all
[10:53] <ajmitch> and yes bug submitters do get confused between products & source packages
[10:53] <mpt> anyway, I'm going home now, tchau
[10:53] <mpt> sorry I was in a bad mood today
[10:53] <ajmitch> I saw someone creating a product just so they could file a bug on it
[10:53] <kiko> time to go too
[10:53] <kiko> see you guys
[10:53] <mpt> I wasn't expecting to still be using baz
[10:53] <ajmitch> so the bug will go nowhere except to them :)
[10:57] <Kinnison> mdz:  dists/warty/main/binary-i386/: New 2811kB 2223 files 1734MB 1m47s
[10:59] <mdz> Kinnison: rsync: send_files failed to open "ubuntu/dists/warty/universe/binary-i386/Packages.bz2.new" (in archive): Permission denied (13)
[10:59] <mdz> (still in progress?)
[11:00] <elmo> yes, .new is an apt-ftparchive-ism
[11:01] <Kinnison> sorry, still in progress yes
[11:01] <Kinnison> I guess it brings them all in in one go
[11:03] <Kinnison> s'off in universe/powerpc right now
[11:07] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: [trivial]  tweaks to meeting spec management and distro package display (patch-2715: mark.shuttleworth@canonical.com)
[11:07] <Kinnison> mdz: finished now
[11:08] <Kinnison> mdz: hoary is still running
[11:23] <mdz> Kinnison: no pockets done yet?
[11:23] <mdz> Kinnison: sorting is still off
[11:24] <mdz> from the look of it
[11:24] <Kinnison> hmm
[11:24] <Kinnison> is it better or worse?
[11:24] <Kinnison> or just differently bad?
[11:25] <mdz> just differently bad
[11:25] <mdz> I'll mail you a diff
[11:25] <Kinnison> thanks
[11:26] <mdz> sent
[11:26] <mdz> somehow liba52-0.7.4-dev is now sorted ahead of aalib1?
[11:27] <mdz> are you by any chance sorting by source package name rather than binary package name?
[11:28] <Kinnison> s'cos a52dec < aalib
[11:29] <Kinnison> I'm sorting by absolute filename
[11:29] <Kinnison> which is what I thought jenna was doing
[11:29] <Kinnison> and I'm fairly sure she does
[11:29] <Kinnison> Do you have a copy of jenna around?
[11:29] <Kinnison> if so, look at line 250
[11:30] <Kinnison> urgh
[11:30] <Kinnison> perhaps she's not
[11:30] <Kinnison> okay, so it's sorting by packagename, not basename, nor filename
[11:32] <Kinnison> Okay I think I've got it now
[11:46] <mdz> apt-ftparchive should just sort the silly thing itself
[11:48] <Kinnison> yes it should
[11:48] <Kinnison> but it doesn't
[11:48] <Kinnison> because it's shit

[11:56] <SteveA> Kinnison: have you seen any oddness with configmanager and getting bzr archives and the '/' character or '%2f' characters in filenames?
[11:57] <Kinnison> yes
[11:57] <Kinnison> you need newer bzr
[11:57] <SteveA> is there a workaround?
[11:57] <SteveA> oh
[11:57] <Kinnison> one sec
[11:57] <SteveA>  *** 0.1.1+20051023-0 0
[11:57] <SteveA> that is what i have
[11:57] <Kinnison> petitemort% bzr --version                                                     ~
[11:57] <Kinnison>   (bzr checkout, revision 1388 {robertc@robertcollins.net-20051024085433-5e48ed93d1546627})
[12:02] <Kinnison> you want I should tar up the bzr I'm using for you?
[12:02] <Kinnison> it's a branch of lifeless' integration branch