[12:04] <lifeless> which is where its at now
[12:04] <lifeless> they take several hours
[12:14] <kiko> lifeless, /why/ is this happenning today?
[12:14] <kiko> or could it be that the bw to chinstrap is strangled? Znarl was talking about this..
[01:17] <dilys> Merge to devel/launchpad/: Fix https://launchpad.net/products/launchpad/+bug/3566 (Oops from registering a specification with an existing URL) r=kiko (r3228: Diogo Matsubara)
[01:22] <lifeless> kiko-zzz: because of the upgrade I did
[01:22] <kiko-zzz> lifeless, oh. that makes sense. will it be super-fast now?
[01:23] <lifeless> kiko-zzz: once it stabilises it will be no faster than it was, but it will be ready for knit upgrading
[01:23] <kiko-zzz> anyway, I need to have dinner. email me if you have more updates, and thanks -- I appreciate it.
[01:23] <kiko-zzz> cool
[01:23] <kiko-zzz> knit upgrading sounds good
[03:03] <mpt> Gooooooooooooood afternoon Launchpadders!
[03:14] <Mez> mpt - morning
[04:51] <dilys> Merge to devel/launchpad/: [trivial]  add test for what happens if checkwatches encounter invalid xml, make it log an error instead of breaking. (r3229: Bjorn Tillenius)
[11:52] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug 33554 (Wrong "Forbidden" exception when viewing bug page) (r3230: Brad Bollenbach)
[12:15] <Kamion> kiko-zzz: distribution owners would be very restrictive for milestone setting - I think far too restrictive
[12:15] <Kamion> kiko-zzz: ubuntu-core-dev or maybe even ubuntu-dev would be fine, and wouldn't impede things as much
[12:15] <Kamion> the publisher is crashing again; can anyone help, please?
[12:15] <Kamion> http://librarian.launchpad.net/1636915/s9V6qvoA40VfduvxtMi4L36cSGG.txt
[12:17] <Kamion> it's crashing on kdelibs_4:3.5.1-0ubuntu7_sparc.changes; no idea why that should be special
[12:26] <SteveA> Kamion: so, it is crashing when the buildd passes stuff off to some rosetta code
[12:26] <SteveA> presumably for extracting translations
[12:27] <Kamion> yeah, Kinnison said that if he couldn't figure it out he'd unlink the translation upload from that .changes in order to get things going again
[12:27] <SteveA> does kdrlibs_whatever have pot or po files in it?
[12:27] <Kamion> yes
[12:27] <Kamion> at this point we don't know whether it's a soyuz bug, a rosetta bug, or a buildd bug
[12:28] <Kamion> -rw-r--r-- root/root     20003 2005-09-10 09:27:50 kdelibs-3.5.1/qt-messages.pot
[12:28] <Kamion> -rw-r--r-- root/root     13730 2005-09-10 09:27:50 kdelibs-3.5.1/kde.pot
[12:31] <SteveA> Kamion: i'm reading the code...
[12:34] <Kinnison> kdelibs must have produced an empty po/pot file
[12:35] <Kamion> it occurs to me that it might be useful if the publisher could continue despite an error on processing a single accepted upload
[12:35] <Kinnison> I was pondering that too
[12:35] <Kamion> that way, problems like this could be demoted from "could you please deal with this even though it's the weekend?" to "have a look on Monday"
[12:36] <Kinnison> heh
[12:36] <Kinnison> Okay, it definitely looks like kdelibs on sparc managed to create some zero length files
[12:37] <Kinnison> https://chinstrap.ubuntu.com/~dsilvers/paste/fileQKDFwj.html
[12:37] <SteveA> Kinnison: maybe the rosetta integration code should give a warning, rather than failing?
[12:38] <Kinnison> perhaps. We'd need carlos to know if that's reasonable
[12:38] <SteveA> not really
[12:38] <SteveA> i mean, not changing any rosetta code
[12:39] <SteveA> but at the point where the buildd stuff calls out to rosetta, catch various rosetta exceptions
[12:39] <SteveA> and make them into warnings.
[12:39] <Kamion> Kinnison: whoa, empty kde.pot?
[12:39] <Kinnison> this is an assertionerror
[12:39] <Kinnison> Kamion: exactly
[12:39] <SteveA> in this case, we'd need to change the AssertionError to a ZeroLengthPot error
[12:39] <Kamion> SteveA: there are other reasons why processing single accepted uploads can fail, and I don't think any of them should stop the entire publisher from running
[12:39] <SteveA> i agree with that
[12:40] <Kamion> SteveA: the one yesterday was breakage with an upload that contained two custom elements (raw-translations and raw-installer), which hadn't happened before
[12:40] <SteveA> on a finer level of granularity, should failure to extract a translation cause that particular upload to fail? 
[12:40] <Kamion> hmm, we probably wouldn't have noticed it otherwise ...
[12:40] <Kinnison> now *that* is a question for carlos
[12:40] <Kamion> so it depends whether we need to notice it
[12:40] <SteveA> if we got a warning, then we should notice the warning
[12:41] <Kinnison> where would the warning go?
[12:41] <Kamion> i.e. does it cause KDE language packs on sparc to be broken?
[12:41] <SteveA> but, if it is a critical part of the workflow, then maybe a failure is better than a warning
[12:41] <SteveA> the warning should end up either on the launchpad error reports mailing list, or as an OOPS report
[12:42] <Kamion> Kinnison: looks like a package bug to me
[12:42] <Kinnison> Kamion: Hmm
[12:42] <Kamion> oh, hmm, I suppose pkgstriptranslations has run by that point ...
[12:42] <Kamion> but it seems like a pretty implausible pkgstriptranslations bug
[12:43] <Kinnison> I'd rather see pkgstriptranslations report a failed build if there are zero length po/pot files in the tarball it creates
[12:43] <Kamion> Kinnison: good idea, I'll report that
[12:43] <Kamion> if my browser ever comes back from trying to render the kdelibs/sparc build log
[12:43] <Kinnison> carlos: What should rosetta do when handed a pkgstripstranslations generated tarball which looks like this: https://chinstrap.ubuntu.com/~dsilvers/paste/fileQKDFwj.html
[12:43] <Kinnison> carlos: note the zero length po/pot files
[12:44] <carlos> Kinnison: they should be ignored
[12:44] <carlos> Kinnison: but I'm not sure if that's the case with the ubuntu uploads
[12:44] <carlos> the files uploaded from hte website are rejected...
[12:45] <carlos> Kinnison: I think that we are not checking that case with the soyuz upload and I suppose it would break the upload as librarian will reject them
[12:45] <carlos> Kinnison: is that being a problem now?
[12:46] <carlos> If I'm right, it's a bug on our code
[12:46] <Kinnison> carlos: currently it's causing assertion errors during accept
[12:46] <carlos> yeah, what I thought
[12:46] <Kinnison> http://librarian.launchpad.net/1636915/s9V6qvoA40VfduvxtMi4L36cSGG.txt
[12:46] <Kinnison> which causes the entire publisher to fail
[12:46] <Kamion> hey, the same is true of kdelibs/i386
[12:46] <Kamion> http://librarian.launchpad.net/1574997/buildlog_ubuntu-dapper-i386.kdelibs_4%3A3.5.1-0ubuntu7_FULLYBUILT.txt.gz
[12:47] <carlos> that has an easy fix
[12:47] <carlos> Kinnison: is soyuz production still using celso's branch?
[12:47] <Kamion> but that was built before we rolled out the new pkgstriptranslations
[12:47] <Kamion> https://launchpad.net/distros/ubuntu/+source/pkgstriptranslations/+bug/33674
[12:47] <Ubugtu> malone bug 33674 in pkgstriptranslations "error on zero-length po/pot files?" [Normal,Unconfirmed]  
[12:47] <carlos> I can add there the needed code to prevent those assertion errors
[12:48] <carlos> anyway, those sourcepackages should be fixed to stop adding empty .pot/.po files
[12:48] <Kamion> yes, just filing a kdelibs bug now
[12:48] <carlos> so I think we should fix Rosetta so it doesn't break with that input and also the packages to stop producing them
[12:50] <Kamion> https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/33676
[12:50] <Ubugtu> malone bug 33676 in kdelibs "produces zero-length kde.pot" [Normal,Unconfirmed]  
[12:50] <Kamion> carlos: agreed
[12:50] <carlos> Kamion: thanks
[12:51] <Kamion> if we make the pkgstriptranslations change suggested above, any packages with this problem will just fail to build, and we'll fix them
[12:51] <carlos> Kinnison: I will log the issue so the logs notes the broken files anyway
[12:51] <Kinnison> carlos: do you want the librarian url to the broken tarfile?
[12:51] <carlos> Kamion: oh, you want that pkgstriptranslations stop building those packages?
[12:51] <carlos> that's also a good way to do that
[12:51] <carlos> Kinnison: no, don't worry
[12:51] <Kinnison> okay
[12:51] <Kamion> carlos: yeah, bug 33674
[12:51] <Ubugtu> malone bug 33674 in pkgstriptranslations "error on zero-length po/pot files?" [Normal,Unconfirmed]  http://launchpad.net/bugs/33674
[12:52] <carlos> Kinnison: I don't have time to look into the source package to fix it
[12:52] <Kinnison> carlos: right
[12:52] <carlos> Kinnison: I'm fixing hte translation import queue right now
[12:52] <Kinnison> carlos: so for now I'll remove the translation tarball from that upload, okay?
[12:52] <carlos> Kinnison: could you confirm if celso's queue is the soyuz version on production?
[12:53] <Kinnison> pardon?
[12:53] <carlos> that way I will do the fix, push it and request celso to merge it to continue building those packages
[12:54] <carlos> Kinnison: is soyuz using same codebase that production is using or are we still using celso's uploader-tests branch?
[12:54] <Kinnison> Not a clue. I'd imagine it'll be celso's branch because we've not yet finished merging it into RF
[12:54] <carlos> to know where should I fix Rosetta to stop breaking with empty files
[12:54] <carlos> ok
[12:55] <carlos> I will implement the fix this weekend and request celso a merge to get those packages built
[12:55] <Kamion> I suspect it'd just get cowboyed on drescher anyway :)
[12:57] <Kamion> carlos: yes, celso's uploader-tests branch according to bzr log
[12:57] <carlos> Kamion: ok, thanks
[12:57] <Kinnison> unfortunately I don't have write access to the branch
[12:57] <Kinnison> if I update it, I'll have to copy it first
[12:57] <Kinnison> I can do it, it'll take some time
[12:58] <carlos> Kinnison: so the buildds are broken until my patch is done?
[12:58] <Kinnison> carlos: no, the entire archive is stalled until it no longer asserts
[12:58] <carlos> in that case I will implement the fix now. I thought it was only a problem with the "broken" packages.
[12:58] <carlos> ok
[12:58] <carlos> working on it now.
[12:58] <Kamion> Kinnison: which does indirectly break the buildds eventually :-)
[12:58] <Kinnison> Kamion: :-)
[12:59] <Kinnison> I'm preparing a copy
[12:59] <Kamion> but only as a side-effect of breaking the rest of the distro world
[01:00] <carlos> it will take a while as my network connection atm is using my mobile phone but I hope it will not be more than a couple of hours
[01:00] <carlos> Kamion: I can call Celso to ask him to do the merge
[01:03] <Kamion> it's 6am for him, if it's easy for Kinnison to do it ...
[01:03] <Kamion> or something-painful-am
[01:03] <Kinnison> carlos: give me a diff and I'll monkey it into place
[01:03] <Kinnison> Kamion: it's 8am for him, but it's saturday
[01:04] <carlos> Kinnison: I'm still getting an updated version of the branch. Will send you the diff as soon as I get the updated branch and I have it
[01:04] <Kamion> oh, reversed DST, always forget about that
[01:04] <Kamion> damn those hemispheres anyway
[01:12] <Kinnison> carlos: If you can tell me what you intend to do, I can make the comensurate change so that the archive can get on with things
[01:16] <carlos> phone...
[01:17] <carlos> ready.
[01:18] <carlos> as I don't need to log anyting, the change is trivial...
[01:19] <carlos> Kinnison: https://chinstrap.ubuntu.com/~dsilvers/paste/fileuefhds.html
[01:19] <carlos> that should fix the problem
[01:20] <carlos> Kinnison: I did it with my old branch, I'm merging all changes now, just in case that file changes a lot and you cannot apply it, anyway, you can add it manually
[01:23] <Kinnison> carlos: right, I can add that into drescher's codeline
[01:23] <Kinnison> one sec
[01:23] <kiko-zzz> hello hackers
[01:24] <Kinnison> okay, I'll now update the symlink to make that codeline current
[01:24] <carlos> kiko: morning
[01:24] <Kinnison> one sec
[01:25] <Kinnison> Right, done
[01:25] <carlos> cprov: morning :-D
[01:25] <cprov> morning dudes
[01:25] <Kinnison> cprov: We added the patch in https://chinstrap.ubuntu.com/~dsilvers/paste/fileuefhds.html to the codeline on drescher, by copying the current codeline and updating the symlink after applying the patch
[01:25] <Kinnison> cprov: This patch fixes a bug in processing a broken translations tarball
[01:25] <carlos> cprov: Rosetta broke your beloved soyuz :-P
[01:26] <Kinnison> cprov: carlos intends to fix this in a branch for you to merge more formally
[01:26] <Kinnison> cprov: hopefully in the meantime the archive can cycle
[01:26] <cprov> Kinnison: I see, what was broken precisely ?
[01:26] <carlos> cprov: empty .pot files
[01:26] <Kinnison> cprov: rosetta would assert on empty pot files
[01:27] <carlos> Kinnison: was it Rosetta or librarian?
[01:27] <Kinnison> carlos: rosetta
[01:27] <cprov> carlos: uhm ...
[01:27] <Kinnison> http://librarian.launchpad.net/1636915/s9V6qvoA40VfduvxtMi4L36cSGG.txt
[01:27] <carlos> ok
[01:27] <carlos> right
[01:28] <cprov> carlos: okay, not a big issue, send me a branch url til monday, I can manage to roll it out 
[01:28] <carlos> cprov: I'm going to use my uploader-tests branch for that
[01:28] <carlos> cprov: I'm merging all changes on your branch since last time I used it
[01:29] <cprov> carlos: right, mail me when you have it done
[01:29] <carlos> s/on/from/
[01:29] <carlos> cprov: sure
[01:29] <cprov> good
[01:31] <Kinnison> Kamion: fyi, a dry-run of process-accepted suggests it'll be fine
[01:35] <Kamion> great, thanks
[01:37] <Kamion> cprov: we suggested that it would be helpful if the publisher could continue despite errors processing single uploads, so that issues like this don't require pulling several people away from what they would otherwise have been doing on a Saturday
[01:37] <Kinnison> This would require process-accepted to be able to commit each accept individually
[01:37] <Kinnison> a touch slower, but not death on a stick
[01:38] <Kinnison> essentially gather a list of ids for queue items to process
[01:38] <Kinnison> then for each in that list, start a txn, try and process, commit/rollback as needed
[01:38] <cprov> Kamion: file a bug, I can do it before the next rollout
[01:41] <kiko> Kamion, okay, I'll consider that.
[01:43] <kiko> Kamion, note that the current owner is Ubuntu Drivers
[01:43] <kiko> which includes the TB and some other people
[01:43] <kiko> including.. me? jimmac? 
[01:43] <kiko> this is probably fallout from the spec permission stuff
[01:44] <Kamion> kiko: sure, but I think "owner" is too strict for milestones
[01:44] <Kamion> at least not distro owner
[01:44] <Kamion> bearing in mind that "owners" of *specific packages* should be able to set milestones
[01:44] <kiko> Kamion, fair enough. but I don't think we have another privilege level to use
[01:44] <kiko> packages don't have owners, AFAIK
[01:45] <kiko> so here's my strawman:
[01:45] <Kamion> aren't ubuntu-core-dev and ubuntu-dev privilege levels associated with the ubuntu distro?
[01:45] <kiko> I mainly want Matt to be able to try milestones out right now
[01:45] <kiko> nope
[01:45] <kiko> not at all
[01:45] <Kamion> for example they are associated with it for the purpose of uploads
[01:45] <kiko> well -- not "for example"
[01:45] <kiko> they are explicitly associated with it for the purpose of uploads
[01:45] <Kamion> doing the same for bugs wouldn't be so bad, then?
[01:46] <kiko> are you suggesting overloading upload privileges with being allowed to set bug milestones?
[01:46] <Kamion> I understand the need to be generic, but I also understand the need for Ubuntu package maintainers to be able to set milestones for the purpose of prioritising their work
[01:46] <kiko> Kamion, I think prioritization is separate from milestones.
[01:46] <kiko> milestones are really a project management thing
[01:47] <Kamion> I need to be able to make a note to fix a bug for dapper
[01:47] <Kamion> particularly when my manager asks me to
[01:47] <kiko> shouldn't your manager go and update the milestone for that bug?
[01:47] <Kamion> sure, but he's a busy man
[01:47] <kiko> but anyway, here's my strawman
[01:47] <kiko> adding a permission slot for this is something that can't be done in a hurry
[01:47] <Kamion> and there are things I personally think are important to fix for dapper that haven't been explicitly requested by my manager, anyway
[01:47] <kiko> but restricting setting of milestones to the owner can
[01:48] <kiko> given that matt currently finds milestones utterly useless to him without some restriction
[01:48] <kiko> I'm suggesting adding a restriction to owner, allowing matt to try the feature out, and discussing and adding a permissions peg to the distribution (or overloading an existing one) next week
[01:48] <kiko> do you think that's a reasonable proposal?
[01:49] <Kamion> OK, as long as the latter is on the plan and not forgotten, it seems a reasonable proposal, yes
[01:49] <Kamion> I agree that restricted-too-much is better than the current totally-unrestricted state
[01:49] <kiko> it's part of the plan -- nag mdz if he doesn't say it's a priority, but otherwise we'll get it done
[01:49] <Kamion> I just don't want restricted-too-much to be permanent. :-)
[01:50] <kiko> okay.
[01:50] <Kamion> thanks
[01:52] <Kamion> cprov: https://launchpad.net/products/launchpad-upload-and-queue/+bug/33688
[01:52] <Ubugtu> malone bug 33688 in launchpad-upload-and-queue "exceptions processing single uploads shouldn't crash the whole publisher" [Normal,Unconfirmed]  
[01:54] <cprov> Kamion: perfect, I need to leave now, but feel free to call me **anytime** +55 16 92067237
[01:54] <Kamion> ok
[01:57] <Kinnison> Right, I have to go now
[01:57] <Kinnison> ciau
[02:21] <lifeless> night all
[02:25] <kiko> is anyone around for a drive-by?
[02:26] <kiko> lifeless?
[02:26] <kiko> BjornT?
[02:26] <kiko> jamesh?
[02:26] <kiko> spiv?
[02:26] <kiko> SteveA?
[02:46] <fabbione> kiko: pick me? pick me!
[02:46] <fabbione> :)
[02:46] <fabbione> kiko: i lost track before.. is the publisher running again?
[02:47] <carlos> fabbione: yes, it should
[02:47] <fabbione> carlos: ok, when is scheduled the next run?
[02:47] <kiko> fabbione, it should be running, and if it isn't, it's a bug
[02:47] <fabbione> never mind
[02:47] <fabbione> it did already
[02:48] <carlos> fabbione: ;-)
[02:48] <fabbione> guys thanks a lot for fixing it so quickly
[02:48] <kiko> sorry about the downtime, the plan is for the publisher to become more robust
[02:51] <fabbione> kiko: it's alright.. better to find problems now than at release time
[02:51] <fabbione> kiko: the only reason why i noticed is that i am waiting the sparc buildds to catch up so i can remove about 60GB of local cache for the buildd :)
[02:51] <fabbione> and be able to reuse my buildd for playing.. but that's a different story ;)
[02:52] <kiko> fabbione, is this your new buildd?
[02:52] <fabbione> kiko: the old buildd that i have at home
[02:52] <kiko> ah. and what of the new ones?
[02:52] <fabbione> i won't touch the new ones
[02:53] <fabbione> they are for the DC :)
[02:53] <kiko> are they there yet?
[02:53] <fabbione> sparc has been built in my house till a few days back when DC got buildd :)
[02:53] <fabbione> kiko: almost
[02:53] <kiko> what's missing?
[02:53] <fabbione> i will have to check in a couple of hours to see how much are they using out of my cache
[02:54] <fabbione> kiko: dunno.. i am not a buildd admin and i can't check queue/status on the overall arch.. can I?
[02:54] <fabbione> in the LP world i am almost a nobody ;)
[02:54] <kiko> you can look at +builds
[02:54] <kiko> and at distros/ubuntu/+builds
[02:54] <fabbione> yes i did..
[02:54] <fabbione> +builds
[02:54] <fabbione> to see what they are processing
[02:55] <kiko> they seem to be working already
[02:55] <fabbione> yes they are
[02:55] <fabbione> that's not the problem
[02:55] <fabbione> old world with katie
[02:55] <fabbione> my sparcbuildd at home was uploading to jackass
[02:55] <fabbione> and that was working fine
[02:55] <kiko> oh I see
[02:55] <fabbione> new world
[02:56] <fabbione> my sparcbuildd at home can't upload but it was still building creating a local cache of pkgs
[02:56] <fabbione> now calculate the delta between new world and yesterday
[02:56] <fabbione> all these pkgs need to be rebuilded from DC buildd
[02:56] <fabbione> but
[02:56] <fabbione> to make things much simpler
[02:56] <fabbione> i opened up my local cache
[02:57] <fabbione> so basically when the buildd will catch up with the backlog, i will be able to kill the local cache
[02:57] <fabbione> make sense?
[02:57] <fabbione> otherwise infinity should have worked N times as much to bootstrap some pkgs..
[02:57] <fabbione> that it is really an annoying process
[02:57] <kiko> yeah, sounds reasonable
[02:57] <kiko> I need to go afk for a sec
[02:58] <fabbione> sure
[02:58] <fabbione> i am going to take a nap soon
[03:00] <carlos> see you later
[03:51] <G0SUB> anyone here?
[03:52] <Keybuk> nope
[03:52] <G0SUB> Keybuk :)
[03:52] <G0SUB> what's the procedure to request a UVF Exception?
[03:52] <Keybuk> ask
[03:53] <G0SUB> just did
[03:54] <Keybuk> I'm not the person to ask
[03:55] <Keybuk> (as in, the procedure is to ask for a UVF exception)
[03:55] <G0SUB> hmm
[03:58] <Kamion> if it's in main or restricted, mail mdz@ubuntu.com and cjwatson@ubuntu.com with a description of what you want to change and the section of the upstream changelog that describes those changes
[03:59] <Kamion> if it's in universe or multiverse, see https://lists.ubuntu.com/archives/ubuntu-motu/2006-February/000545.html
[04:01] <Kamion> I've documented this on https://wiki.ubuntu.com/DeveloperResources
[04:02] <G0SUB> Kamion thanks a lot
[04:02] <G0SUB> Kamion we needed you in ubuntu-motu atm
[04:03] <G0SUB> Kamion there is a critical bug in m17n-db which has been fixed in debian ... but ubuntu is stuck with a older version
[04:05] <Kamion> you don't need me for that; m17n-db is in universe
[04:06] <G0SUB> oh, so who can do it?
[04:06] <G0SUB> i mean we don't need TB people for that ... can MOTUs do that?
[04:06] <Kamion> (why is this in #launchpad anyway?)
[04:07] <Kamion> did you read what I said above? I gave you a link to the procedure for universe
[04:07] <G0SUB> I am sorry
[04:10] <Keybuk> TB don't do exceptions anyway
[04:10] <Keybuk> oh, he RETURN'd
[04:11] <Kamion> R3TURN
[04:14] <Keybuk> it's Saturday, what are you doing online? :)  go be with family and wifey
[05:32] <G0SUB> in my launchpad calendar, when I set the time as 15:00:00, it becomes 14:37:00 after saving
[05:32] <G0SUB> why?
[05:32] <carlos> G0SUB: it looks like a bug...
[05:32] <carlos> G0SUB: please, file a bug
[05:32] <G0SUB> hmm
[05:32] <G0SUB> okay
[05:34] <G0SUB> carlos which product/package?
[05:35] <carlos> G0SUB: https://launchpad.net/products/launchpad
[05:38] <kiko> it is a dupe
[06:19] <dilys> Merge to devel/launchpad/: [trivial]  Improve the person's +packages page by including the upload date and build status feedback. Also link to the relevant source package release page. Also do some minor cleaning up in the method that queries for bugtasks associated to that package (r3231: kiko)
[06:21] <kiko> yes!
[06:23] <carlos> kiko: dude... and all that is trivial?
[06:23] <kiko> I asked if anybody wanted to review it
[06:24] <kiko> it's not really very complicated, though
[06:24] <carlos> lots of trivial changes
[06:24] <kiko> if you want to take a look at the landing and criticize it I'd be happy to address any concerns
[06:24] <kiko> but it mainly adds some fields to a template and uses SourcePackageRelease methods
[06:24] <kiko> not a very big deal
[06:24] <carlos> kiko: I don't have time and I trust you on that... but perhaps r=kiko... :-P
[06:24] <kiko> I could have done it as 3 separate commits...
[06:25] <kiko> yeah, well, it's saturday :)
[06:25] <carlos> :-P
[06:28] <carlos>         return self.__dict__['real_cursor'] .execute(*args, **kwargs)
[06:28] <carlos>     ProgrammingError: ERROR:  could not load library "/usr/lib/postgresql/8.0/lib/plpython.so": /lib/libpthread.so.0: symbol _h_errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
[06:28] <carlos>     INSERT INTO POTemplateName (id, title, translationdomain, description, name) VALUES (6, 'Whatever', 'firefox', NULL, 'firefox')
[06:28] <carlos> ----------------------------------------------------
[06:29] <carlos> note to self... don't run tests while a dist-upgrade ....
[06:29] <kiko> heh
[08:08] <G0SUB> I did a PO file export 15 minutes back, but I haven't received the PO file it ...
[08:08] <G0SUB> does it take that long?
[08:14] <carlos> G0SUB: could be, but not much more
[08:15] <G0SUB> ok
[08:15] <carlos> see you later
[08:20] <G0SUB> carlos not recieved yet
[08:46] <carlos> G0SUB: I don't see anything in our logs. That would be:
[08:46] <carlos> 1.- The cron job is disabled. I cannot check it now, I need stub to check it for me
[08:47] <carlos> 2.- You have a problem with your email account or we have a problem sending you the email
[08:47] <carlos> G0SUB: gie me the URL and I will request the same download to check if it works for me
[08:48] <carlos> Hmm I need to leave... please, send me the URL by email and I will try to handle it tomorrow morning...
[08:48] <carlos> see you
[08:48] <G0SUB> whoops!
[08:48] <G0SUB> what's carlos' email ID ?
[09:08] <nekohayo> hello, that may sound like a silly question, but I have been unable to figure out how I can "add people" to my product in launchpad... do I need to?
[10:10] <gusaweb> hello
[10:11] <nekohayo> hi
[10:13] <gusaweb> do you intend to make the translation of launchpad possible in the near future ?
[10:18] <gusaweb> nekohayo ?
[10:19] <nekohayo> I don't know, I'm not a developer :P
[10:19] <nekohayo> I came here to ask about "project members"
[10:20] <gusaweb> ok :)
[10:22] <Seveas> gusaweb, see launchpad.net/faq
[10:22] <gusaweb> Seveas thanks
[10:28] <nekohayo> Seveas: is there any documentation on my "add people to a project" issue?
[10:29] <Seveas> nekohayo, people will need to join themselves iirc (note: I am not an LP developer)
[10:36] <nekohayo> well, I have not been able to find out a way to "subscribe to a project" yet..
[10:42] <mdke> nekohayo, projects have "admins". if the admin is a team, you can apply to join that team.
[10:42] <nekohayo> mdke: ok, and is there a privilege system for moderating what team members can do on a project?
[10:43] <mdke> nekohayo, not that I know of. What do you have in mind?
[10:44] <mdke> oh actually, you can define translators on a project i think
[10:44] <nekohayo> well that basically means anyone in the team can change the project details, releases, bugs, everything? that's a bit dangerous
[10:44] <nekohayo> for example, if I had packagers I would not give them access to moderating bugs no?
[10:44] <mdke> projects don't have bugs, or releases, I think.
[10:45] <mdke> but yeah, best to keep the team that is admin of a project quite small, I suppose
[10:46] <nekohayo> mdke: yes, there are bugs and everything afaik http://nanokron.info:8000/Screenshot.png
[10:46] <mdke> ah right, that is a product
[10:46] <mdke> launchpad distinguishes between projects and products
[10:47] <nekohayo> is there a documentation page explaining the difference?
[10:47] <mdke> nekohayo, you can try searching on https://wiki.launchpad.canonical.com/
[10:47] <mdke> i'm not sure
[10:47] <nekohayo> also I noticed something strange about launchpad: even when you clearly do not have the permissions to do something, you have the link to do so... someone viewing my profile has links to edit it o_o
[10:48] <mdke> I don't see that
[10:53] <nekohayo> hmmm.. example: https://launchpad.net/people/majikstreet look on the left, you have a "manage" link for the email addresses
[10:55] <mdke> yeah, I'd say that's a bug. Best to check if it's reported already before filing it though
[11:43] <robertj> has there been any OpenID via launchpad discussion recently?