[12:52] <lamont> (trusting archives should be a property of the chroot, not the real-root)
[12:52] <lamont> I guess that should properly be a bug against launchpad with diff in it, yes?
[12:54] <cprov-out> lamont: indeed, file a bug on launchpad-buildd product, please.
[12:54] <lamont> will do
[01:33] <kiko> lamont, you got mail
[01:36] <lamont> kiko: thanks
[01:37] <lamont> although we exposed the bug by adding a brand spanking new architecture...  which kinda fits your model
[01:37] <lamont> and the mail lets me understand why the lucky packages were, um, lucky
[02:24] <kiko> ScottK, do I need to add any special tags to https://bugs.edge.launchpad.net/ubuntu/+bug/148792 ?
[02:24] <ubotu> Launchpad bug 148792 in ubuntu "Package OGMRip" [Undecided,New]  
[02:26] <ajmitch> needs-packaging
[02:28] <kiko> thanks ajmitch 
[02:31] <Fujitsu> Ew, getdeb.
[02:33] <kiko> heh
[02:40] <ubotu> New bug: #148796 in malone ""Page not found error", when someone updated the bug, while you were editing" [Undecided,New]  https://launchpad.net/bugs/148796
[05:01] <mpt> "You have been subscribed to a public bug by a mysterious stranger"
[05:01] <mpt> "You have been subscribed to a public bug by sunspot activity"
[06:02] <mayeco> heyyy
[06:02] <mayeco> you are changing things in launchpad right?
[07:11] <lifeless> uh yes
[07:11] <lifeless> yes we are
[07:46] <StevenK> Am I able to put multiple affects lines into a signed mail I send into Malone? If so, will it do the right thing.
[07:47] <spiv> StevenK: yes
[07:48] <spiv> StevenK: https://help.launchpad.net/UsingMaloneEmail#head-5ea87d70dba160e5903ca01b9eedd8d8476aa2a1 gives an example of doing that.
[07:49] <StevenK> Excellent, thanks
[08:43] <carlos> morning
[08:43] <Fujitsu> Hi carlos.
[10:39] <carlos> Hobbsee: hi, you didn't ping me again yesterday. Do you still need to talk with me?
[10:44] <Hobbsee> mornign mrevell 
[10:44] <mrevell> hi Hobbsee
[11:14] <yeager> time to leave.. flight to london in 2 hours
[11:46] <thisfred> hi guys: minor gripe about the launchpad translation exports: the structure of and filenames in the exported tarballs seem to be in flux, which makes automating translation synchronization with my applications sort of a pain. Is it documented somewhere how exactly those files are packed, and more importantly, is there a point at which the stucture will remain stable? ;) 
[11:49] <jtv> thisfred: can you show me where (url) you request these tarballs?
[11:50] <jtv> thisfred (so I can figure out what exactly goes into them)
[11:50] <thisfred> jtv, for instance: https://translations.launchpad.net/silva-find/trunk/+pots/silva-find/+export
[11:50] <jtv> thanks, I'm taking a look
[11:50] <thisfred> thanks very much!
[11:53] <jtv> thisfred: is there any chance that these are after-effects of files being renamed or moved around in the past?
[11:54] <thisfred> jtv, possibly, but I don't think so, I mean, I always took care to upload the same thing I got from launchpad in terms of structure and filenames.
[11:55] <thisfred> I'm sure I always uploaded a single tarred flat directory with .pot and .po's
[11:55] <thisfred> now I'm getting files directly in the zip and the .pot in a directory, that has a different name than before
[11:56] <thisfred> also it used to be nl.po, en.po etc. now it's name-of-project-en.po
[11:56] <jtv> hmmm
[11:56] <thisfred> that's all easily changed in my scripts of course
[11:56] <thisfred> I just wanna make sure it won't be changing very soon again ;)
[11:57] <jtv> We're also doing lots of imports for Gutsy at the moment of course, so if those contain changes...
[11:57] <thisfred> I don't think any of my projects are in gutsy
[11:58] <jtv> And Launchpad-native translations, right?
[12:00] <jtv> thisfred: I don't know too much about the naming logic for these files, but I'm asking around.
[12:00] <thisfred> jtv, thanks
[12:00] <thisfred> I'm not 100% sure what you mean by launchpad native
[12:01] <jtv> Nor I, never mind that :)
[12:04] <jtv> thisfred: do you remember when you uploaded these PO and POT files?
[12:04] <jtv> (btw, "breadcrumbs" -> "broodkruimels"?)
[12:05] <carlos> thisfred: we got already bug reports about it and plan to fix it, don't worry
[12:05] <carlos> jtv: is what we talked this morning
[12:05] <thisfred> jtv, I'll have a look
[12:06] <thisfred> carlos, oh, ok, I'll wait for the dust to settle then :)
[12:06] <jtv> thisfred: carlos just mentioned that this sounds like a known problem.  I'mg digging up the bug URL.
[12:06] <carlos> thisfred: https://bugs.edge.launchpad.net/rosetta/+bug/148286 and https://bugs.edge.launchpad.net/rosetta/+bug/148276
[12:06] <ubotu> Launchpad bug 148286 in rosetta "multiple template export has wrong directory names" [High,Confirmed]  
[12:06] <jtv> ah, that's it.
[12:07] <thisfred> many thanks!
[12:07] <jtv> carlos: thanks from me too!
[12:07] <thisfred> I'll subscribe to those 
[12:09] <thisfred> and jvt: I didn't actually do *all* of the dutch translations, but I'll follow the breadcrumbs ;)
[12:09] <jtv> :)
[12:15] <ubotu> New bug: #148901 in malone "less bugs listed when sorting" [Undecided,New]  https://launchpad.net/bugs/148901
[12:35] <jtv> thisfred: you may want to follow bug 148276 as well.
[12:35] <ubotu> Launchpad bug 148276 in rosetta "po files should have the same name as when they were uploaded" [Medium,Confirmed]  https://launchpad.net/bugs/148276
[12:36] <jtv> thisfred: note there's only one digit of difference between those two bug numbers, a bit confusing.
[12:38] <thisfred> jtv, thanks, but I just clicked them, so I don't run the risk of mistyping ;)
[12:42] <jtv> thisfred: for me just _noticing_ the difference is sometimes difficult.
[12:45] <ubotu> New bug: #148905 in malone "unexpectedformdata on clicking "1  bug fixed elsewhere" on gcc" [Undecided,New]  https://launchpad.net/bugs/148905
[02:47] <mantiena-baltix> hi all
[02:49] <mantiena-baltix> who is reponsible for PPA in launchpad ? It seems there are big problems with PPA - it doesn't install python :(
[02:51] <Hobbsee> mantiena-baltix: cprov 
[02:52] <cprov> mantiena-baltix: well, PPA chroot is the same used in ubuntu primary archive, can I see the failed build log ?
[02:55] <ubotu> New bug: #148939 in launchpad "OOPS validating a sign only gpg key" [Medium,Confirmed]  https://launchpad.net/bugs/148939
[02:59] <mantiena-baltix> cprov, yes, of course: http://launchpadlibrarian.net/9721899/buildlog_ubuntu-feisty-i386.pingus_0.7.1-1%7Efeisty1_FAILEDTOBUILD.txt.gz
[03:06] <cprov> mantiena-baltix: I think you should depend on python, but I'm not the best person to ask. Can you request help on #motu ?
[03:08] <kiko> build-depend maybe?
[03:09] <Fujitsu> cprov: #ubuntu-motu, you mean?
[03:10] <cprov> Fujitsu: yes, off course, thanks.
[03:10] <Hobbsee> cprov: that looks like a good question for a buildd admin - to try to install tha tmanually
[03:11] <Hobbsee> or throw the source at a normal feisty pbuilder.
[03:11] <Fujitsu> You'd need to try to install them manually in that chroot to work out what was wrong, yes.
[03:12] <mantiena-baltix> cprov, problem isn't in build-deps (pingus package is taken from ubuntu gutsy), problem is in PPA, other packages, which have build without problems now fails because PPA doesn't install python
[03:13] <mantiena-baltix> look for example at 2 kde-guildance build logs:
[03:13] <mantiena-baltix> http://launchpadlibrarian.net/9721881/buildlog_ubuntu-feisty-i386.kde-guidance_0.8.0svn20070928-0feisty2_FAILEDTOBUILD.txt.gz
[03:14] <cprov> mantiena-baltix: you are building gutsy on feisty, are you considering that, right ?
[03:14] <mantiena-baltix> http://launchpadlibrarian.net/9249766/buildlog_ubuntu-feisty-i386.kde-guidance_0.8.0svn20070727-0feisty6_FULLYBUILT.txt.gz
[03:14] <mantiena-baltix> cprov, I'm backporting from gutsy to feisty
[03:15] <Fujitsu> It's hard to tell exactly what has gone wrong without access to the chroots.
[03:17] <mantiena-baltix> look at the build log of pingus or kde-guidance - there is the same problem:
[03:17] <mantiena-baltix> scons: Depends: python but it is not going to be installed
[03:17] <mantiena-baltix>          Depends: python-central (>= 0.5.8) but it is not going to be installed
[03:17] <Hobbsee> as a check, you include py-central in the build-deps, and see why it bails
[03:17] <Hobbsee> but that's probably not the source of the problem.
[03:18] <Hobbsee> but to say that the python on the buildds is botched is kinda useless - particularly with no buildd access.
[03:18] <cprov> mantiena-baltix: it might be related with the the recent changes we made in chroots for Partner archive, let me try something, one sec and you can retry the failure builds
[03:19] <mantiena-baltix> cprov, thanks
[03:22] <cprov> mantiena-baltix: i386 PPA should be sane now, retry one of the builds, please.
[03:23] <mantiena-baltix> ok
[03:24] <mantiena-baltix> btw, why there are no way to remove package from PPA archive ?
[03:26] <cprov> mantiena-baltix: because it's not yet implemented <wink>, "version bump (tm)"
[03:29] <mantiena-baltix> :)
[03:35] <mantiena-baltix> cprov, hehe, it seems your fix helps - kde-guidance is in build process for about 4 minutes (previously it fails after 2 minutes) :)
[03:38] <cprov> mantiena-baltix: great ! thanks for the feedback, I wasn't aware of this issue 
[03:39] <Fujitsu> cprov: How did partner manage to break it?
[03:39] <Hobbsee> Fujitsu: when there's enough crack in soyuz, just *looking* at it the wrong way can break it.
[03:39] <Hobbsee> s/can/will/
[03:40] <cprov> Fujitsu: partner requires us to use -updates chroots for the supported 'release' pocket (dapper, edgy, feisty)
[03:40] <ubotu> New bug: #148960 in launchpad-bazaar "Same user subscribed twice to a branch" [Undecided,New]  https://launchpad.net/bugs/148960
[03:41] <cprov> Hobbsee: from the soyuz PoV, the crack is on your packages ;)
[03:41] <Hobbsee> cprov: no, no, we dont upload crack.  people can actually audit our packages and see that
[03:41] <Hobbsee> cprov: soyuz is just deluded.
[03:41] <mantiena-baltix> cprov, thanks for the fix - I alredy have successful guidance backport, it's time for pingus :)
[03:42] <mantiena-baltix> btw, amd64 is fixed too ?
[03:42] <cprov> mantiena-baltix: yes, amd64 is ready to go too
[03:55] <Kopfgeldjaeger> hi
[03:56] <kiko> ho
[03:58] <ddaa> hi
[03:59] <mwhudson> m
[04:00] <ddaa> Hobbsee: I did not realize one could read "White Snow" in this way...
[04:00] <mwhudson> e
[04:00] <bigjools> me
[04:01] <Hobbsee> ddaa: dunno which way you're thinking about.  my statement was mostly unrelated.
[04:01] <ddaa> it's probably better
[04:01] <SteveA> Welcome to this week's Launchpad development meeting.  For the next 45 minutes or so, we'll be coordinating about Launchpad development!
[04:01] <SteveA> who is here today?
[04:01] <gmb> me
[04:01] <carlos> me
[04:01] <jsk> me
[04:01] <mthaddon> me
[04:01] <ddaa> me
[04:01] <bac> me
[04:01] <EdwinGrubbs> me
[04:01] <jtv> me
[04:01] <intellectronica> me
[04:01] <adeuring> me
[04:01] <flacoste> me
[04:01] <mwhudson> me
[04:01] <matsubara> me
[04:01] <schwuk> me
[04:01] <jamesh> me
[04:01] <sinzui> me
[04:01] <BjornT> me
[04:01] <barry> me
[04:01] <cprov> me
[04:01] <mrevell> me
[04:01] <salgado> me
[04:02] <bigjools> me
[04:02] <SteveA> stub sends apologies
[04:02] <danilos> me
[04:02] <statik> me
[04:02] <allenap> me
[04:02] <Rinchen> me
[04:03] <kiko> me!
[04:03] <SteveA> == Agenda ==
[04:03] <SteveA>  * Roll call
[04:03] <SteveA>  * Agenda
[04:03] <SteveA>  * Next meeting
[04:03] <SteveA>  * Actions from last meeting
[04:03] <SteveA>  * Oops report (Matsubara)
[04:03] <SteveA>  * Critical Bugs (Rinchen)
[04:03] <SteveA>  * Bug tags
[04:03] <SteveA>  * Operations report (mthaddon)
[04:03] <SteveA>  * DBA report (stub)
[04:03] <SteveA>  * Sysadmin requests (Rinchen)
[04:03] <SteveA>  * A top user-affecting issue (mrevell)
[04:04] <SteveA> ----
[04:04] <SteveA>  (other items)
[04:04] <SteveA> ----
[04:04] <SteveA>  * Blockers
[04:04] <SteveA> 
[04:05] <SteveA> Next meeting: same time next week
[04:05] <SteveA> does anyone know they won't be able to attend?
[04:05] <kiko> I won't
[04:05] <kiko> I'm on vacation.
[04:05] <jamesh> I probably won't
[04:06] <SteveA> thanks
[04:06] <adeuring> I neither -- more complex appointment at a dentist
[04:06] <SteveA> adeuring: good luck
[04:06] <bac> i won't
[04:06] <adeuring> SteveA: thanks :)
[04:07] <SteveA>  * Actions from the last meeting
[04:07] <SteveA> there are none
[04:07] <SteveA>  * Oops report (Matsubara)
[04:07] <matsubara> Thanks jamesh for fixing #132270
[04:07] <matsubara> Today's oops report is about bugs 148939, 44871, OOPS-641E1615
[04:07] <ubotu> Launchpad bug 148939 in launchpad "OOPS validating a sign only gpg key" [Medium,Confirmed]  https://launchpad.net/bugs/148939
[04:07] <ubotu> Launchpad bug 44871 in launchpad "xmlrpc should return appropriate response for a GET" [Medium,Confirmed]  https://launchpad.net/bugs/44871
[04:07] <ubotu> https://devpad.canonical.com/~jamesh/oops.cgi/641E1615
[04:07] <matsubara> Someone from the foundations team want to take #148939?
[04:07] <matsubara> mwh, can you take #44871?
[04:08] <flacoste> salgado: do you think you have time for #148939?
[04:08] <matsubara> I already privmsg'd jtv about the OOPS and jtv will file a bug and follow up on it.
[04:09] <matsubara> mwhudson: can you take #44871?
[04:09] <kiko> flacoste, can you maybe give it to ddaa?
[04:09] <mwhudson> matsubara: i can look at it, at least, i have no intuition as to how hard it will be
[04:09] <matsubara> mwhudson: btw, why do you have 2 nicknames?
[04:09] <mwhudson> matsubara: two machines
[04:09] <Spads> One for casual, one for formal.
[04:09] <salgado> flacoste, I was actually hoping to bribe matsubara on doing that, but I can give it a try today to see if it's easy. if it is then it's fine
[04:09] <SteveA> why mwhudson for xmlrpc?
[04:09] <flacoste> salgado: you might want to try bribing ddaa instead :-)
[04:09] <Hobbsee> matsubara: why have 2 names, when you can have 3?
[04:10] <SteveA> that should be a foundations team issue
[04:10] <flacoste> otherwise, i can probably take both
[04:10] <flacoste> matsubara: assign both to me
[04:10] <ddaa> I'm happy with the foundation bugs I already have.
[04:10] <flacoste> i'll delegate if necessary
[04:10] <matsubara> thanks flacoste 
[04:10] <ddaa> But I can look into this if needed.
[04:10] <kiko> ddaa, this bug will make you even happier :)
[04:10] <SteveA> also, it's likely to be reasonably tricky zope internals
[04:10] <flacoste> matsubara: and put it on the 1.1.10 milestone
[04:10] <matsubara> flacoste: sure thing
[04:11] <matsubara> so, I think I'm done here. thanks all
[04:11] <matsubara> SteveA: back to you
[04:12] <SteveA> thanks matsubara 
[04:12] <mantiena-baltix> sorry for disturbing, but I wanna ask important question - when there will be an ability to register new milestone or new release for other distros in launchpad ? It's too hard to track bugs when there are no ability to set the target milestone :(
[04:12] <SteveA>  * Critical Bugs (Rinchen)
[04:12] <Rinchen> Hi, one for this week, a PPA item:  Bug #144392
[04:12] <ubotu> Launchpad bug 144392 in soyuz "cron.daily dies after poppy restart because of permission problems with queue dot-lock file" [Critical,In progress]  https://launchpad.net/bugs/144392 - Assigned to Celso Providelo (cprov)
[04:12] <SteveA> mantiena-baltix: Il'l add that to the agenda for later.
[04:12] <kiko> I think that bug was actually fixed
[04:13] <Rinchen> cprov, this appears to be assigned to you 
[04:13] <cprov> Rinchen: very trivial 50 lines
[04:13] <Rinchen> Great! Do you have a target?
[04:13] <cprov> kiko: can you check those ? 
[04:13] <mantiena-baltix> SteveA: thanks, I'm waiting :)
[04:14] <Rinchen> cprov, or to reword, will it be by tomorrow?  I suspect we'll want to cherry this?
[04:14] <kiko> Rinchen, I don't think it's affecting us right now
[04:14] <kiko> it can be manually fixed
[04:14] <kiko> the bug is only to avoid it happening again
[04:14] <Rinchen> that's even better. Can you (kiko) or cprov please comment in the bug report to that effect.
[04:14] <cprov> Rinchen: yes, it'd be good, otherwise we will cry again when elmo need to reboot production machines
[04:14] <Rinchen> moving on.. back to you Steve.  Thanks cprov.
[04:15] <SteveA> so... should that bug be critical or just high?
[04:15] <kiko> elmo never reboots machines!
[04:15] <Rinchen> btw, matsubara pointed out that the IE7 bug has been fixed earlier this week. I don't have the bug number handy though
[04:15] <elmo> kiko: yes, http://www.ubuntu.com/usn/usn-518-1, I do
[04:16] <kiko> elmo, shhh :)
[04:16] <SteveA> Rinchen: should that bug be critical or just high?
[04:16] <kiko> high.
[04:16] <kiko> it has a workaround.
[04:16] <Rinchen> based on the above, I agree with high
[04:16] <SteveA> ok, please change its importance
[04:17] <SteveA>  * Bug tags
[04:17] <SteveA> we have a number of proposals for new bug tags today
[04:17] <Rinchen> done
[04:17] <SteveA> oops-tools: Bugs related to the scripts used to generate oops reports, oops.cgi and the processes related to oops in general
[04:17] <SteveA> from matsubara
[04:17] <SteveA> looks good to me
[04:17] <SteveA> any objections?
[04:18] <SteveA> great
[04:18] <SteveA> accepted, thanks matsubara 
[04:18] <matsubara> thanks SteveA 
[04:18] <SteveA> three proposals from francis:
[04:18] <SteveA> librarian: Bugs related to the Librarian component
[04:18] <SteveA> +1 from me.  other comments?
[04:18] <Rinchen> +1
[04:18] <mwhudson> i thought that existed already!
[04:19] <SteveA> openid: Bugs related to the OpenID implementation
[04:19] <SteveA> mwhudson: existing is different from being officially used and having a standard definition
[04:19] <mwhudson> SteveA: ah
[04:19] <SteveA> no objections to 'librarian', so approved.
[04:19] <SteveA> +1 on openid, particularly as we'll be expanding our openid service in the future.
[04:20] <Rinchen> I'm happy with OpenID if it will help Foundations. 
[04:20] <kiko> yes
[04:20] <SteveA> no objections to openid, so approved.
[04:20] <kiko> I think that's a good idea.
[04:20] <kiko> I have a request
[04:20] <kiko> can we merge xmlrpc and api tags?
[04:20] <flacoste> i think that's a good idea
[04:20] <SteveA> kiko: +1
[04:20] <barry> kiko: +1
[04:20] <statik> +1
[04:20] <kiko> thanks.
[04:20] <jamesh> kiko: they'll potentially be using separate infrastructure though ...
[04:20] <Rinchen> +1 here
[04:21] <kiko> jamesh, but does it matter so much?
[04:21] <SteveA> I'd like to keep separate tags for external public APIS
[04:21] <SteveA> and internal APIs we use within the DC
[04:21] <barry> xmlrpc will likely become a private internal thing (only? mostly?) but i'm still fine with merging them
[04:21] <SteveA> well
[04:21] <SteveA> hang on
[04:21] <SteveA> we're confusing the name of a protocol "XMLRPC" with the kind of service
[04:21] <SteveA> we will continue using xmlrpc for internal apis
[04:22] <flacoste> then we should change the definitions and keep the two tags
[04:22] <SteveA> we'll need to maintain some xmlrpc apis externally, for compatibility with older ubuntu releases
[04:22] <SteveA> I think apis should include legacy public xmlrpc
[04:22] <SteveA> the key word here is 'public'
[04:22] <SteveA> we may need a new tag for 'internal-only apis'
[04:22] <flacoste> public-api private-api?
[04:23] <SteveA> I think 'apis' does well for 'public api'
[04:23] <flacoste> and it's shorter
[04:23] <barry> SteveA: that's fine too
[04:23] <SteveA> so 'api' and 'private-api'
[04:23] <barry> SteveA: +1
[04:23] <flacoste> fine
[04:23] <carlos> +1
[04:23] <SteveA> although, again, it's not so much private as 'internal'
[04:23] <flacoste> kiko?
[04:23] <SteveA> so, I'd prefer internal-api tbh
[04:23] <SteveA> and still get rid of 'xmlrpc' as a tag
[04:23] <barry> works for me
[04:23] <Rinchen> I'm happy with that.
[04:24] <SteveA> people: Bugs related to the management of Persons and Teams. This would include registration bugs, but exclude bugs related to login and password recovery.
[04:24] <SteveA> the third proposal from flacoste 
[04:24] <flacoste> i'm not too sure about that one
[04:24] <SteveA> I think the scope needs some work
[04:24] <flacoste> i think it could be well merged with my other proposal
[04:24] <Rinchen> flacoste, to include FOAF?
[04:24] <SteveA> perhaps with more examples
[04:24] <SteveA> Rinchen: be careful of the term FOAF
[04:25] <flacoste> Rinchen: i proposed originally foaf as tag name
[04:25] <SteveA> it has a specific usage in the internet community
[04:25] <SteveA> which is not the same as what we casually refer to as foaf
[04:25] <SteveA> although we do have a FOAF export somewhere I think
[04:25] <SteveA> I'm fine with the tag name 'people', but I want the scope to be clearer
[04:25] <SteveA> flacoste: can we leave this until next week?
[04:26] <flacoste> SteveA: we can
[04:26] <Rinchen> matsubara, your comments as well to flacoste post meeting on this tag would be interesting to have.
[04:26] <kiko> flacoste, I just work here!
[04:26] <SteveA> ok, so that stays there until next week, and get more examples
[04:26] <SteveA> any remaining questions on new bug tags?
[04:26] <SteveA> thanks for your proposals, kiko, flacoste, matsubara 
[04:27] <Hobbsee> ahem.
[04:27] <matsubara> roger, Rinchen 
[04:27] <flacoste> matsubara: remind me: should I update the tags page?
[04:27] <matsubara> flacoste: yes please
[04:27] <SteveA> ok, thanks
[04:28] <SteveA>  * Operations report (mthaddon)
[04:28] <mthaddon> New deployment scripts testing well so far (used in the 1.1.9 release)
[04:28] <mthaddon> New PQM box finally working (still need to plan with IS for ramdisk testing)  and showing improved timing
[04:28] <mthaddon> Also need to coordinate with IS on DB upgrade
[04:28] <mthaddon> I think that's it from me unless there are any questions
[04:28] <salgado> mthaddon, how much did it improve?
[04:29] <mthaddon> https://devpad.canonical.com/~mthaddon/pqm_durations.html
[04:29] <kiko> around 40 minutes I think
[04:29] <SteveA> mthaddon: I'd like to know the results of the ramdisk work so that we can deploy it for week 3 if it is a successful experiment
[04:29] <Rinchen> 110 down to 66 roughly
[04:29] <Rinchen> minutes
[04:29] <SteveA> score
[04:29] <SteveA> thanks admins, for the new box!
[04:29] <mthaddon> SteveA, understood - got bogged down with the PQM bug yesterday... will hope to find time today
[04:30] <SteveA>  * DBA report (stub)
[04:30] <SteveA> hmm, I was expecting to see that on the launchpad list
[04:30] <SteveA>  * Sysadmin requests (Rinchen)
[04:30] <Rinchen> Hi! Is anyone blocked on an RT or have any that are becoming urgent? 
[04:30] <mthaddon> one very nice side effect (PQM for LP is now on it's own box) is that the timing seems to be a lot less variable as well - very consistent timing for a run
[04:30] <Rinchen> As usual we've had several complete this week.
[04:30] <kiko> Rinchen, just the ramdisk testing for PQM that has alredy been managed.
[04:31] <kiko> mthaddon, yes, I had noticed that.
[04:31] <Rinchen> kiko, ok thanks.
[04:31] <carlos> Rinchen: jtv is blocked on one RT ticket
[04:31] <kiko> Rinchen, thanks for handling bdmurray's request
[04:31] <carlos> jtv: ?
[04:31] <Rinchen> The RT blocking mpt was resolved earlier this week as well as one for bdmurray 
[04:31] <jtv> carlos: not actually blocked, it's just a damn nuisance
[04:31] <Rinchen> ah right, you're welcome
[04:31] <Rinchen> carlos, topic? I didn't see it in the weekly
[04:32] <carlos> jtv: well... it's blocking us to relay on you being able to act if there are requests that need you attention...
[04:32] <Rinchen> or jtv...topic and/or number
[04:32] <SteveA>  * A top user-affecting issue (mrevell)
[04:32] <carlos> Rinchen: having jtv member of rosetta@launchpad.net alias
[04:32] <jtv> Rinchen: don't have number handy
[04:32] <SteveA> jtv: please tell Rinchen after the meeting
[04:32] <mwhudson> mthaddon: would be fun to include stddev alongside average in https://devpad.canonical.com/~mthaddon/pqm_durations.html :-)
[04:32] <jtv> ok
[04:32] <mrevell> This week's issue concerns how we announce changes that will affect the way people use Launchpad.
[04:32] <mrevell> I asked the launchpad-users list for input on how to improve these announcements.
[04:32] <mrevell> Some people supported announcing changes in Launchpad's UI, perhaps as a message above the green breadcrumb bar.
[04:32] <mrevell> I'd like to know what people think of this idea. In particular, how do we decide how which changes warrant a UI message.
[04:33] <mrevell> If we don't have time in this meeting, please see the launchpad-users thread "Announcing Coming Changes in Launchpad".
[04:33] <kiko> mrevell, I think it's really the best idea
[04:33] <mrevell> Thanks, back to you SteveA.
[04:33] <kiko> I'm not sure the message above the bar is the best way to do it
[04:33] <Hobbsee> mrevell: ones that actually influence people's workflow
[04:33] <SteveA> we have a spec for such announcements somewhere
[04:33] <SteveA> so that people can confirm an announcement
[04:33] <kiko> but I think we need to find a way of informing people, yes
[04:33] <SteveA> and won't be shown it again
[04:33] <Hobbsee> SteveA: any chance we can mirror that to lp-users or something?
[04:33] <kiko> I think a bubble announcement that shows until you dismiss it is the best idea
[04:33] <Hobbsee> SteveA: (the full spec)
[04:33] <SteveA> but we don't show an announcement that has already happened
[04:33] <SteveA> it was ages ago
[04:33] <mthaddon> mwhudson, I think if we see more variance in the timings on the new box that might be useful 
[04:33] <SteveA> so might need rejiggering or something
[04:34] <SteveA> Hobbsee: we'll make it public if/when we find it
[04:34] <SteveA> moving on...
[04:34] <SteveA> thanks mrevell 
[04:34] <mrevell> I can take a look for the spec
[04:34] <Hobbsee> SteveA: cool, OK
[04:34] <SteveA> mantiena-baltix: proposed an item.
[04:34] <SteveA> he said:
[04:34] <SteveA>  when there will be an ability to register new milestone or new release for other distros in launchpad ? It's too hard to track bugs when there are no ability to set the target milestone.
[04:35] <SteveA> I don't know of a timescale for this
[04:36] <Rinchen> I'll need to do some investigation. I seem to have run across this request previously in my travels. It's not currently targeted though.
[04:36] <kiko> okay
[04:36] <kiko> so I will explain what's going on with that
[04:36] <kiko> back in the day, milestones used to be standalone things
[04:36] <kiko> you created some for your project and distro and lived with them happily
[04:37] <kiko> now at one point that was changed and milestones ended up being subsidiary to project and distro series 
[04:37] <kiko> which means you create a milestone for a particular series
[04:37] <kiko> so far so good
[04:37] <kiko> the problem that mantiena-baltix is running into
[04:37] <kiko> is that we don't allow distro owners to add their own releases
[04:38] <kiko> this is noted in the code as being restricted, btw, because it could cause "problems in soyuz"
[04:38] <kiko> I think this is not accurate or true any longer
[04:38] <kiko> but I am unable to establish the extent of the inaccuracy or untruthfulness without some investigation by others
[04:38] <SteveA> so, it needs some investigation
[04:38] <cprov> kiko: yes, I think so, we have very distribution-oriented scripts/infrastructure atm
[04:39] <kiko> I bet cprov is actually right
[04:39] <kiko> I'd like statik to confirm this
[04:39] <kiko> given I've already loaded him with all distro and distrorelease related questions in the past
[04:39] <cprov> kiko: which means that 'baltix' won't be ever considered.
[04:39] <kiko> the question is: can we change permissions to allow distro owners to add their own distroseries?
[04:40] <lamont> cprov/kiko: would it be terribly difficult SQL foo, or could I get one of you to dump me a list of what source packages in gutsy/main lack hppa build records?
[04:40] <SteveA> lamont: meeting ends in 5 mins.  hang on a sec?
[04:40] <kiko> statik, if you can investigate and answer with a simple yes/no, I'll make the rest happen.
[04:40] <lamont> oops
[04:40] <statik> kiko: I can take this as a meeting action, and work on it (with advice from cprov)
[04:40] <SteveA> ok.
[04:41] <kiko> statik, mantiena-baltix, cprov: I will not move one millimeter on this subject until I have this answer, so please don't ask me about it again!
[04:41] <SteveA> time to move on.  last item on the agenda:
[04:41] <SteveA>  * Blockers
[04:41] <SteveA> SC: not blocked
[04:42] <flacoste> Foundations Team: not blocked
[04:42] <jtv> Translations: not blocked
[04:42] <bigjools> Soyuz: not blocked
[04:42] <BjornT> Bugs Team: not blocked
[04:42] <ddaa> Code: not blocked
[04:42] <Rinchen> Releases Team: Not Blocked
[04:43] <cprov> Rinchen: bug 141062 is not a blocker but it's be nice if we can reach an agreement soon. Unfortunately, mpt is not here.
[04:43] <ubotu> Launchpad bug 141062 in soyuz "Please relocate /faq, /feedback, and PPA TOS to the wiki" [Medium,In progress]  https://launchpad.net/bugs/141062 - Assigned to Celso Providelo (cprov)
[04:43] <statik> collaborative commerce: not blocked
[04:43] <cprov> Rinchen: code is already r=kiko
[04:43] <Rinchen> cprov, sure I'll work on that later today
[04:44] <SteveA> ok, we're done.  Thanks for being here and keeping things moving forwards!
[04:44] <SteveA> MEETING ENDS
[04:44] <SteveA> lamont: please, go for it
[04:44] <cprov> Rinchen: thanks.
[04:44] <lamont> SteveA: thanks.
[04:44] <lamont> cprov/kiko??
[04:45] <cprov> lamont: isn't the build counter for hppa enough ?
[04:45] <flacoste> mrevell: where should we report bug about help.launchpad.net?
[04:45] <lamont> ??
[04:45] <kiko> lamont, first send me some LSD. then we can talk.
[04:45] <mrevell> flacoste: Against Launchpad Documentation Project - I'll get the link
[04:45] <lamont> kiko: that's so 1960s though... you should upgrade
[04:45] <cprov> lamont: https://edge.launchpad.net/ubuntu/gutsy/hppa/+builds?build_text=&build_state=built
[04:45] <sinzui> Robotusin?
[04:45] <kiko> lamont, so, two answers to your question
[04:45] <mrevell> flacoste: https://edge.launchpad.net/launchpad-documentation/+filebug
[04:45] <lamont> cprov: what I want is a list of all the packages that LP won't be building...
[04:46] <kiko> lamont, first, yeah, we could do some investigation
[04:46] <lamont> not the ones it already built.
[04:46] <kiko> but what I asked cprov to do
[04:46] <kiko> is to test the proposed change on mawson
[04:46] <kiko> and see what builds it will attempt to queue 
[04:46] <kiko> I think that will be enough to answer your question and also establish whether this patch is sane or not
[04:46] <lamont> yes
[04:47] <kiko> so let's wait for cprov to do that right after he's tested his crazy archive removal redesign work
[04:47] <cprov> mthaddon: do you have access to launchpad_production snapshots ? I'd like to have a recent one to restore in dogfood. Can you help me with that ?
[04:48] <mthaddon> cprov, sure
[04:51] <mantiena-baltix> SteveA, meeting ends, but I still don't understand why noone wants to fix milestone/release registration problems ;(
[04:52] <jtv> Balaams_Miracle, you still here by any chance?
[04:52] <SteveA> mantiena-baltix: kiko said he wants to fix it, but needs to find out what the issues are.
[04:53] <SteveA> mantiena-baltix: we have a big scary notice in the code about this, and we need to understand what that means before we change anything.
[04:53] <SteveA> mantiena-baltix: so kiko has asked cprov and statik to look into it.
[04:53] <SteveA> mantiena-baltix: although launchpad appears to support many distributions, right now, there are a lot of assumptions that it's just for use with ubuntu, and we need to be careful how we change things.
[04:54] <mantiena-baltix> SteveA, ok, but maybe you can register at least few Baltix releases for me ?
[04:54] <SteveA> mantiena-baltix: kiko said no, until we have looked into this technical issue.
[05:01] <lamont> cprov: on the bootstrapping thing...
[05:01] <cprov> lamont: yes
[05:01] <lamont> please use your do-guest-maintenance script to add my gpg key (0a0ac927) to promethium and samarium
[05:02] <lamont> and then I'll have an i386 chroot for you within the next bit, and we can push amd64 and i386 chroots 
[05:02] <cprov> lamont: uhm, no. why do you want that in ppa builders ?
[05:02] <lamont> icedtea-java7 needs i386 love
[05:02] <lamont> cprov: because I am all-powerful. :-)
[05:02] <lamont> it's a work around for chapt-get being b0rked
[05:03] <lamont> once we fix chapt-get, and LP releases those bits, then I don't need to be god anymore.
[05:03] <cprov> lamont:  can't you sort it with IS/elmo ? I'm not sure if I'm allowed apply such hacks.
[05:03] <lamont> 03-10-2007 17:36:59 < elmo!n=james@83-216-156-21.jamest747.adsl.metronet.co.uk (lamont): +he has a do-guest-maintenance script, he can just add your key to trusted.gpg
[05:04] <lamont> (I already added the key on the non-virtual buildds...)
[05:04] <cprov> lamont: okay, give some minutes then
[05:04] <lamont> cprov: no hurry at all
[05:05] <jtv> thunder rolls
[05:07] <lamont> cprov: if/when something is urgent, believe me, I'll let you know...
[05:07] <cprov> lamont: I know ;)
[05:07] <lamont> (and this isn't one of those times...)
[05:07] <lamont> hrm... /me notes that he owes cprov $BEVERAGE again
[05:08] <cprov> ehe
[05:10] <yeager> mdke: you there?
[05:10] <mdke> yeager: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[05:45] <lamont> given a bug number, what's the simplest url for getting to it?   https://launchpad.net/$PROJECT/+bug/$BUGNUM works, is there a way to skip guessing what $PROJECT is?
[05:46] <Balaams_Miracle> jtv-afk: I'm here now, but you are afk... (*cries softly*)
[05:46] <kiko> lamont, launchpad.net/bugs/$bugnum
[05:46] <lamont> rock
[05:46] <Balaams_Miracle> paper
[05:47] <Balaams_Miracle> ;-)
[05:47] <Balaams_Miracle> Paper covers rock, i win
[05:48] <lamont> my rock is hot lava.  paper burns.  I win
[05:48] <Balaams_Miracle> LOL
[06:01] <kalikiana> Hey there, How do I remove a project from launchpad?
[06:02] <kiko> kalikiana, you request using the URL in the topic
[06:06] <jtv> Balaams_Miracle: not completely gone though :)
[06:06] <jtv> Balaams_Miracle: I have a bit more information now on those oopses you ran into.
[06:07] <jtv> Balaams_Miracle: they do look different from what we've seen before, and I'm not even quite sure what to make of them.
[06:09] <kiko> welcome to software engineering
[06:10] <jtv> kiko: thanks, I've been sitting here waiting for someone to say that for a few years.  :)
[06:10] <kalikiana> kiko, Hm... thanks.
[06:15] <jordi> kiko: I'm sure you'll be interested to know (re one joke/conversation in Montral) that I just created my first ever MSN account. :)
[06:15] <kiko> jordi, I have one too! you can be in my buddy list!
[06:17] <Balaams_Miracle> jtv: Any idea what caused/causes those oopsies?
[06:17] <kiko> jordi, kiko_async@hotmail.com :)
[06:17] <jtv> Balaams_Miracle: not yet, so I wanted to ask you: did they happen more when you were posting, for example?
[06:17] <jtv> Ahem.  I mean, submitting changes.
[06:18] <Balaams_Miracle> jtv: There does seem to be some kind of relation between submitting changes and the timeouts. However, they also occur when i'm just browsing a package
[06:19] <jtv> Balaams_Miracle: right now I'm speculating that maybe those were the normal timeouts, and the ones after submitting changes may (sometimes) be different.
[06:21] <jtv> Balaams_Miracle: in fact, when you submit I'd expect a slightly lower chance of the original problem, so if you saw _more_ oopses after submitting, that suggests this may be what's happening.
[06:22] <Balaams_Miracle> Hmmm... How can i help? Should i report every oops or would that be too silly?
[06:22] <jtv> Balaams_Miracle: probably, though I appreciate the thought.
[06:23] <jtv> Balaams_Miracle: Here's something though...
[06:23] <jtv> Balaams_Miracle: when you submit, you move straight on to the next page, right?
[06:24] <Balaams_Miracle> Yes, and it's often the next page that times out
[06:24] <jtv> Balaams_Miracle: what if, before you submitted, you'd made sure that you'd recently visited that next page?
[06:24] <Balaams_Miracle> Oh wait, you knew that
[06:24] <jtv> No problem with saying things I already know.  :)
[06:25] <Balaams_Miracle> It's worth a try. I'll go and see if it does make a difference tonight (almost dinner time overhere)
[06:25] <jtv> But maybe you could, for example, open the next page in a separate browser tab before you submit your changes.
[06:25] <ffm> How are projects deleted?
[06:25] <jtv> Balaams_Miracle: eet smakelijk!
[06:26] <jtv> ffm: I believe you need an admin for that...
[06:26] <Balaams_Miracle> jtv: Dank je :-) (PS je bleek toch gelijk gehad te hebben over de blauwe tekst)
[06:26] <jtv> Balaams_Miracle: :-)
[06:27] <jtv> Balaams_Miracle: anyway, once you've visited a +translate page successfully, it shouldn't time out again directly after that.  So this way, we can eliminate the timeouts as a suspect.
[06:27] <jtv> Balaams_Miracle: if you still get oopses after submitting, then we'll have a clean, timeout-free reproduction and hopefully that will give us a more useful log.
[06:28] <jtv> Balaams_Miracle: or if it makes the problem disappear, naturally I'm also very interest to hear that!
[06:28] <jtv> *interested
[06:29] <Balaams_Miracle> jtv: I will tell you either way. After all, it's great to help improve something already impressive as LP
[06:29] <jtv> Balaams_Miracle: it's lots of fun, though the kitchen never looks quite as peaceful as the rest of the restaurant.  :)
[06:29] <jtv> Balaams_Miracle: enthusiastic users make it a lot more fun...
[06:30] <Balaams_Miracle> jtv: and if preloading the next page does not help, then that will narrow down the causes of the timeouts. :-)
[06:30] <kalikiana> ffm, Ask a question like "Remove project".
[06:30] <kalikiana> ffm, ie. under launchpad questions
[06:31] <jtv> Balaams_Miracle: it seems to be a mix of timeouts and other errors, so this way we'll get a chance to separate those two.  "Lakmoesproef."
[06:31] <ffm> kalikiana: thx
[06:34] <Balaams_Miracle> jtv: I'm sorry if i seem distracted, but my wife's PC reports error 17 on boot and i'm also trying to fix that
[06:34] <jtv> Balaams_Miracle: no prob, I think we've covered the important stuff.  Good luck!
[06:34] <Balaams_Miracle> Thanks!
[06:53] <jordi> kiko-fud: you must have a jabber account though
[06:56] <carlos> jordi: what for? he gave me one some time ago, but I never saw him connected (I even doubt he accepted/saw my request to see his status)
[06:56] <carlos> ;-)
[07:04] <jordi> heh
[07:06] <jordi> kiko-fud: let's see how that works
[07:11] <ubotu> New bug: #149031 in launchpad "Better visibility for common actions on user profile page" [Undecided,New]  https://launchpad.net/bugs/149031
[07:50] <Kmos> kiko: bug 132221 - comment on it
[07:50] <ubotu> Launchpad bug 132221 in devscripts "requestsync: Add latest debian version to the title of the bug" [Wishlist,In progress]  https://launchpad.net/bugs/132221 - Assigned to Marco Rodrigues (gothicx)
[07:51] <Kmos> it will be nice for LP to have bugs with different subject :-)
[07:51] <ScottK> Kmos: requestsync isn't in devscripts anymore.
[07:51] <Kmos> ScottK: where is it ?
[07:53] <kiko> heh
[07:53] <kiko> Kmos, I think that'd be a fine improvement to requestsync
[07:54] <Kmos> scottk set my bug to invalid
[07:54] <Kmos> wtf
[07:54] <Kmos> what's the package of requestsync now ?
[07:55] <Kmos> ubuntu-dev-tools
[07:55] <Kmos> :)
[08:33] <ScottK> kiko: In one of your mails to ubuntu-devel you asked to let you know if there was an upstream project missing, you'd create it.  Please have a look at Bug 141563
[08:33] <ubotu> Launchpad bug 141563 in malone "CPAN not available as upstream bug tracker" [Undecided,Confirmed]  https://launchpad.net/bugs/141563
[08:33] <kiko> ScottK, yep.
[08:34] <ScottK> I was pretty suprised that one didn't exist as it's the ultimate source for most Perl modules.
[08:35] <kiko> ScottK, but.. CPAN isn't a bug tracker. is it?
[08:36] <LaserJock> see, this is what's confusing me
[08:37] <LaserJock> it seems like we have to be registering projects for everything
[08:37] <kiko> okay so far.
[08:37] <LaserJock> but then if the project doesn't use LP or something LP recognizes then I see some major issues
[08:37] <kiko> well hang on there.
[08:37] <kiko> what does "something LP recognizes" mean? :)
[08:38] <LaserJock> like bug trackers that LP doesn't "get" or no bug tracker at all
[08:38] <ScottK> kiko: CPAN has a bug tracker.
[08:38] <kiko> ScottK, they do?
[08:38] <ScottK> Yes.
[08:38] <LaserJock> for instance, the project I'm work upstream on uses Savannah
[08:38] <kiko> an RT
[08:38] <LaserJock> which LP doesn't know yet
[08:38] <LaserJock> so if people file upstream tasks where does it go?
[08:38] <kiko> LaserJock, you are slightly SOL with savannah right now but it's being fixed.
[08:39] <kiko> right now the tasks aren't linked to upstream bugs -- i.e. you need to maintain the status out of band
[08:39] <LaserJock> right, but the even more common case is no bug tracker at all
[08:39] <kiko> but we are fixing that
[08:39] <LaserJock> I don't even care about status!
[08:39] <ScottK> kiko: Doesn't an RT count as a bug tracker?
[08:39] <kiko> ScottK, indeed it does! I didn't know CPAN had one. 
[08:39] <LaserJock> I'm saying that bugs pile up in LP on a project that the authors may not know about
[08:40] <kiko> LaserJock, yes. though that happens in other distribution bug trackers as well -- Launchpad can't do much better than them in those cases yet.
[08:40] <kiko> LaserJock, for the projects which /do/ have a supported bugtracker we can do much better though.
[08:40] <LaserJock> so Ubuntu users are like "cool, it's got an upstream task so they must be working on it" when in fact the authors have *no* idea that the bugs exist
[08:41] <pwnguin> launchpad can't fix upstream in software
[08:42] <pwnguin> you could invite them to start a launchpad tracking project though ;)
[08:42] <ScottK> LaserJock: I have heard (but am not certain) that Savannah has declined to get data from LP because it's non-free.
[08:42] <kiko> LaserJock, there's a proposal to have bridges to upstream for these projects which we currently have no link to.
[08:42] <kiko> LaserJock, i.e. volunteers that worked as upstream ambassadors
[08:42] <pwnguin> is savannah APL?
[08:42] <LaserJock> kiko: right, but what do we do with the bugs?
[08:43] <LaserJock> I'm very hesitant to register a project
[08:44] <pwnguin> ScottK: savanna is gplv2. non-free is a silly complaint in that case
[08:44] <kiko> LaserJock, for now, we record that they are upstream, and email upstream maintainers if we have the time.
[08:44] <LaserJock> kiko: who does that?
[08:44] <ScottK> pwnguin: I'm not judging, just passing on what I heard.
[08:45] <kiko> LaserJock, the bug triager, or anybody who cares
[08:45] <pwnguin> ScottK: gplv2 "or later", excuse me. but the point is, it doesnt require disclosure of changes on deployed sites. If you ever do hear first hand about that, ask em when savanna will be using Affero ;)
[08:45] <kiko> LaserJock, I used "we" in that sense
[08:45] <LaserJock> well, if there's nobody to triage the bug ...
[08:46] <kiko> LaserJock, in Ubuntu? I think we're talking past each other.
[08:46] <pwnguin> this sounds like a zen koan
[08:46] <pwnguin> "if a user reports a bug and there's no upstream developer to hear it, does it make a sound?"
[08:46] <LaserJock> kiko: well, let me think about
[08:48] <LaserJock> kiko: I can file some test bugs on demo.lp.net right?
[08:52] <yml> hello launchpaders
[08:52] <kiko> LaserJock, on staging, please, yes.
[08:54] <Kmos> kiko: patch for requestsync done.. bug 132221
[08:54] <ubotu> Launchpad bug 132221 in ubuntu-dev-tools "requestsync: Add latest debian version to the title of the bug" [Wishlist,Fix committed]  https://launchpad.net/bugs/132221 - Assigned to Marco Rodrigues (gothicx)
[08:54] <Kmos> :)
[08:54] <yml> I am slowly get familar wit all the capability of launchpad as platform and I would like to know if someone could help me to understand how to work with the translation?
[08:55] <kiko> yml, danilos and carlos and jtv are your best bets, but what would you like to know?
[08:55] <yml> I have uploaded a ".po" file on https://translations.launchpad.net/django-survey/trunk/+imports
[08:56] <yml> hello kiko happy to read from you again
[08:56] <yml> :-)
[08:56] <kiko> yml, you're welcome -- I'm as busy as usual :)
[08:56] <yml> the good sign is that I was able to use launchpad alone during a couple of weeks without your support
[08:56] <kiko> yml, very good. and it's still stuck in needs-review?
[08:57] <yml> review from whom?
[08:57] <yml> I am the developper translator
[08:57] <kiko> yml, from carlos or danilo
[08:57] <kiko> it's the first time it's imported, and that's why
[08:57] <yml> all in one for that project
[08:58] <kiko> yep
[08:58] <kiko> but a launchpad translations admin needs to look at this upload once
[08:58] <kiko> jordi?
[08:58] <yml> What are they reviewing?
[08:59] <kiko> the structure of the pofile, the pathnames, language and variant.
[08:59] <yml> Once this is done what are the next step in the process?
[08:59] <kiko> yml, once that's done you can translate away using the web UI.
[08:59] <LaserJock> kiko: ok, so LP tries to dissuade me from opening an upstream task on gchemutils but I can certainly do it
[08:59] <LaserJock> https://bugs.staging.launchpad.net/gchemutils
[09:00] <yml> How can I update this file with its latest version?
[09:00] <LaserJock> so the problem that I have is what happens when those bugs pile up and there's nobody around to send the bugs upstream
[09:00] <LaserJock> you can create a task without having upstream actually know about it at all
[09:01] <kiko> LaserJock, right. but let's say you convinced somebody upstream to sit in the slot of gchemutils' bug contact.
[09:01] <kiko> LaserJock, then they would get notified of any bugs that were reported upstream
[09:01] <kiko> by Ubuntu triagers, or triagers of any other project that happens to use gchemutils
[09:01] <kiko> LaserJock, does that make sense?
[09:02] <yml> Also I have the feeling that I missed something because this file is also part of a branch: https://code.launchpad.net/~yml-nospam/django-survey/main-yui
[09:03] <yml> I was expecting that I could directly point the translation to this file in the branch instead of duplicating it.
[09:03] <kiko> yml, right now there is no bzr-to-translations integration, unfortunately. when we do, your project will be one of the first to benefit!
[09:03] <kiko> yml, I wish that was possible -- but it will be in the future.
[09:03] <LaserJock> kiko: yeah, I just don't think it's gonna happen
[09:03] <kiko> LaserJock, which part?
[09:03] <LaserJock> projects that don't use LP aren't going to want to track *another* way of getting bug reports
[09:03] <LaserJock> and users don't know all this
[09:03] <LaserJock> all they see is that there is an upstream task
[09:04] <LaserJock> so they assume upstream knows about it
[09:04] <yml> kiko: I tought it was a standart pattern to manage the translation in the branch
[09:04] <LaserJock> upstream tasks shouldn't be just placeholders, they should mean something to people, right?
[09:04] <kiko> yml, it is a standard pattern; it's just that launchpad isn't smart enough there yet.
[09:05] <yml> ;-)
[09:05] <kiko> LaserJock, well, right, they should mean something to people. but let me ask you this.
[09:05] <kiko> LaserJock, let's say you talk to upstream, and ask them for an email address to submit bugs to. that's not ridiculous, right?
[09:06] <LaserJock> it often doesn't happen, but that's what we're hoping for, yes
[09:06] <LaserJock> I very rarely talk to upstreams
[09:06] <yml> kiko: thank you very much I am looking forward getting my .po file reviewed by : carlos or danilo
[09:06] <LaserJock> we touch to many packages to know much of anything about upstreams
[09:06] <kiko> yml, I'm hoping they look at it by tomorrow morning. if not, please talk to me!
[09:07] <kiko> LaserJock, I know. but one step at a time -- first 5 then 50 then 500.
[09:07] <kiko> LaserJock, but if you did convince an important upstream, which is the recipient of many bugs, to add a team with a contact address in LP (or you did it on their behalf) then you'd be half set.
[09:07] <kiko> LaserJock, that's the essence of getting upstream to listen to launchpad bugs.
[09:07] <yml> thank you kiko for your great support 
[09:07] <kiko> LaserJock, they don't even need to use the web UI
[09:08] <LaserJock> well, I think often times it doesn't exactly work that way
[09:08] <LaserJock> we just keep the bugs in Ubuntu
[09:08] <LaserJock> because we don't want to be bothered with upstreams
[09:09] <LaserJock> and I'm afraid of upstreams getting upset users asking "why didn't you fix my bug?" then they learn that there's a pile of bugs they didn't know about in LP
[09:09] <LaserJock> I've experienced this personally
[09:09] <LaserJock> upstreams tracking me down, asking what the heck we're doing
[09:10] <LaserJock> because there's 15 bugs sitting in LP that they didn't know about
[09:10] <LaserJock> and people are blaming them
[09:11] <LaserJock> that is the kind of thing I'm trying to avoid
[09:11] <LaserJock> and merely moving the bugs to a project rather than ubuntu doesn't help at all
[09:12] <LaserJock> unless the upstream gets the info
[09:12] <kiko> LaserJock, but it sounds like you and are are agreeing, then -- because I'm saying that we need to get people to listen as bugcontacts for upstream.
[09:13] <LaserJock> well, kinda
[09:13] <LaserJock> I'm afraid that in an effort to make things better you end up making it worse
[09:13] <LaserJock> that's my concern
[09:13] <LaserJock> in an ideal world, yes, we'd have contacts for every project
[09:14] <kiko> and we need to move in that direction, bit by bit.
[09:14] <LaserJock> but you seem to be pushing that we need more projects registered
[09:14] <LaserJock> when we don't even have contacts for many of the projects we already have
[09:14] <kiko> LaserJock, well... 
[09:14] <kiko> I think we need to move forward and not get stuck waiting for chickens to come from eggs.
[09:15] <kiko> otherwise nothing happens -- it's always a bit of pain to get something rolling
[09:15] <kiko> now, if there's something we can do to mitigate the principal of the concern you're raising, let's do it
[09:15] <kiko> any ideas?
[09:15] <ScottK> kiko: I think many upstreams take rather the opposite view.  It's up to distros to push bugs to them.
[09:16] <kiko> ScottK, you seem to be agreeing with me too, though :) isn't that what I'm proposing?
[09:16] <kiko> a distro triager opening an upstream task, IOW?
[09:16] <ScottK> There are X bazillion Linux distros and projects can't listen to them all.
[09:16] <ScottK> I thought you were trying to get upstreams to look at LP?
[09:17] <kiko> ScottK, no. I just want upstreams to provide us with a contact email address so we can send them upstream bug reports when Ubuntu triagers find them.
[09:17] <kiko> we'll do the rest.
[09:17] <kiko> they can reply via email to the reports, for instance
[09:18] <LaserJock> kiko: is there a way to see *all* "needs forwarding" bugs?
[09:18] <kiko> LaserJock, there is such a report in the advanced bugs page.
[09:19] <LaserJock> that would give a list for all projects?
[09:19] <kiko> LaserJock, for all ubuntu tasks, in the ubuntu context
[09:21] <LaserJock> ok, so I came up with 324 bugs
[09:23] <LaserJock> so now if we had an upstream contact address we could put those in as the bug contact and then they'd automatically be forwarded?
[09:28] <LaserJock> kiko: argg, what's a series? is that a release version?
[09:28] <kiko> LaserJock, well, they wouldn't be automatically forwarded /now/, because they have already been filed
[09:29] <kiko> a series? why are you asking that? :)
[09:30] <LaserJock> well
[09:30] <LaserJock> I'm trying to link a project to a package
[09:30] <LaserJock> and it says that I must first register a series
[09:30] <kiko> just use trunk, LaserJock 
[09:30] <LaserJock> hmm, but a series looks more interesting
[09:31] <LaserJock> ;-)
[09:31] <LaserJock> is there a reason to use trunk over a series?
[09:31] <LaserJock> in this case Ubuntu's packages are really old
[09:31] <LaserJock> and the code is waaay different than what is in trunk
[09:34] <kiko> trunk is just a series
[09:34] <kiko> explaining by example
[09:35] <kiko> linux had a 2.2 and 2.4 series
[09:35] <kiko> apache had a 1.2 and 1.3 series
[09:35] <LaserJock> right
[09:35] <kiko> trunk is a virtual series
[09:35] <LaserJock> ok, so my project has a 0.6 and 0.8 series right now
[09:35] <LaserJock> our packages are currently from 0.6
[09:36] <LaserJock> so would it make sense to create a 0.6 series and link to the packages from there
[09:36] <LaserJock> and if I did that what happens when we switch to 0.8
[09:37] <kiko> you update the link if you switched to 0.8 in a certain distrorelease
[09:37] <kiko> or, if gutsy uses 0.6 and hardy will use 0.8, then you just add a new link.
[09:37] <LaserJock> is there any distinct advantage to using series?
[09:38] <LaserJock> I like the idea of LP automatically importing the tarballs
[09:39] <kiko> we're going to do that
[09:39] <kiko> too.
[09:44] <LaserJock> ok, snazzy
[09:44] <LaserJock> I've got lp.net/gchemutils/ all rigged out
[09:45] <LaserJock> set myself as bug contact, registered the 0.6 and 0.8 branches, got CVS imported, and linked the Ubuntu package
[09:45] <LaserJock> but we've got now bugs, I'll have to get some people to file some ;-)
[09:45] <LaserJock> s/now/no/
[09:50] <LaserJock> kiko: I gotta run and get some real work done. Thanks for the tour/enlightenment
[09:51] <kiko> thanks so much LaserJock!
[10:12] <mdke> iwj: that's what i figured, thanks
[10:58] <nicolai__> gn8
[11:16] <lamont> is there a way for me to mark a package as "failed/don't-even-try-again" or some such?
[11:16] <ScottK> lamont: File a bug?
[11:16] <lamont> enigmail 2:0.94-0ubuntu4.4  in dapper-proposed-updates is going through the infinite loop of build -> autodepwait -> cleardepwait -> build
[11:17] <ScottK> Ah.  Nevermind.
[11:17] <lamont> ScottK: against launchpad-buildd requesting such a button?  it may come to that
[11:17] <ScottK> I thought you were talking about something else.
[11:17] <ScottK> There's always upload a new revision that wants something not in the archive.   That would do it.
[11:18] <lamont> since dapper builds ahead of gutsy in the queue, it slows the buildd farm down by several minutes each queuebuilder run (amd64 takes over 20 minutes before it fails))
[11:20] <lamont> different question for cprov or whoever... if I rescore a build to -1, will it ever build?
[11:20] <lamont> I figure it's either "after all the positive scores", or "never"
[11:21] <cprov> lamont: yes, it will build when the queue is empty.
[11:21] <lamont> well, I suppose that's better than nothing
[11:22] <lamont> of course, since it auto-retries, you don't get to actually see the build log (purged), unless you're patient and have good timing...
[11:22] <cprov> lamont: I meant, yes, the former ...
[11:22] <lamont> not sure what the breakage is that's got it forever looping
[11:23] <lamont> cprov: fwiw, it would appear that LP thinks it should be buildable, and sbuild begs to differ.
[11:23] <cprov> lamont: is it a failure or a given-back (as in 'it continues in needs_build state')
[11:23] <lamont> so there's a logic disconnect there.  just so you know...
[11:23] <lamont> currently-building -> dep-wait -> needs-build -> repeat
[11:25] <lamont> http://launchpadlibrarian.net/9758857/buildlog_ubuntu-dapper-i386.enigmail_2%3A0.94-0ubuntu4.4_MANUALDEPWAIT.txt.gz
[11:25] <cprov> lamont: the build log remains in librarian for a while and you have the direct link in the build-failure-notification email.
[11:25] <cprov> lamont: ah, you have it
[11:25] <lamont> fter installing, the following source dependencies are still unsatisfied:
[11:25] <lamont> mozilla-thunderbird-dev(inst 1.5.0.2-0ubuntu2 ! >= wanted 1.5.0.4)
[11:26] <lamont> Build-Depends: debhelper (>> 4.0.0), coreutils, libidl-dev (>= 0.8.0 ), zlib1g-dev, docbook-to-man, zip, dpatch, m4, mozilla-thunderbird-dev (>= 1.5.0.4), mozilla-thunderbird-dev (<< 1.5.0.99), autoconf2.13, sed
[11:26] <lamont> leads to grabbing 1.5.0.2-0ubuntu2 to satisfy the build-dep.
[11:26] <lamont> bad bob
[11:27] <lamont> Build-Depends: ... mozilla-thunderbird-dev (>= 1.5.0.4), mozilla-thunderbird-dev (<< 1.5.0.99),  ...
[11:27] <lamont> is maybe launchpad overwritting the first with the second?
[11:27] <cprov> lamont: does the builder return the complete missing-dep sentence to LP ?
[11:28] <cprov> lamont: is it in dep-wait now ?  point me to the build page
[11:28] <lamont> Status:  	 Dependency wait
[11:28] <lamont> Missing Dependencies: 	mozilla-thunderbird-dev (>= 1.5.0.4)
[11:28] <lamont> https://edge.launchpad.net/ubuntu/+source/enigmail/2:0.94-0ubuntu4.4/+build/371785
[11:46] <cprov> lamont: well, the dependency lookup method considers all pockets, and apparently you are not using dapper-security in your chroot.
[11:46] <lamont> it's dapper-proposed...
[11:47] <lamont> one could argue that once dapper releases, dapper-* should be looking at dapper-proposed
[11:47] <lamont> obviously, dapper-security should only be looking at dapper and dapper-security to resolve depends....
[11:47] <lamont> do the different pockets have different chroot-ubuntu-dapper-$arch.tar.bz2 tarballs?
[11:48] <lamont> if not, that's yet another enhancement request for LP... :-(
[11:48] <lamont> because -updates should look at -updates for build-deps, and -security should not.