[00:09] <Fujitsu> cprov: May I ask why bug #196782 is deemed to be of such low priority that it has been untargetted? It gives a pretty bad first impression of PPA.
[00:09] <ubotu> Launchpad bug 196782 in soyuz "First build in a new PPA fails" [Low,Triaged] https://launchpad.net/bugs/196782
[00:11] <cprov> Fujitsu: only in the very first job. We can't fight this race-condition effectively.
[00:11] <Hobbsee> so you do nothing, even though it's generating multiple questions in here each week
[00:12] <Fujitsu> Can't you just not let the build be handed out to a builder unless the archive is published?
[00:14] <elmo> Hobbsee: easy - setting it to low priority != 'doing nothing'
[00:15] <Fujitsu> elmo: Untargetting == 'doing nothing for the foreseeable future'
[00:15] <cprov> Hobbsee: exactly what I was saying, it was decided that we have other more important things to be done before this one.
[00:16] <Fujitsu> Speaking of more important things... how's security-in-soyuz doing?
[00:16] <elmo> Fujitsu: well, a) I'd argue, if you can't see past the current LP release schedule, you can't see far ;-), but b) in any event, I think there's more constructive ways to argue for priortization of features
[00:17] <Hobbsee> elmo: what Fujitsu said.
[00:17] <cprov> Fujitsu: very well, soon we will have it running.
[00:20] <Fujitsu> cprov: Is there any public document describing how it will actually be used/
[00:20] <cprov> Fujitsu: one idea is to not dispatch pending jobs for archives (PPAs) younger than 20 minutes (current publishing interval), but that's so naive that doesn't worth the code, if you know what I mean.
[00:21] <cprov> Fujitsu: no, not a public one. I image we will be writing one before switching.
[00:21] <Fujitsu> cprov: Is there not a timestamp of last publishing that you can check for nullness? I imagine that'd be fairly easy and less than hackish that checking the age of the PPA...
[00:21] <cprov> Fujitsu: btw, do you know exactly how dak works nowadays ?
[00:22] <Fujitsu> cprov: I know fairly well how dak works, but not a whole lot about the dak-LP interactions.
[00:23] <cprov> Fujitsu: checking the source publishing date doesn't really help since we very often build unpublished-sources (build-from-accepted feature).
[00:23] <Fujitsu> cprov: I meant archive publishing date.
[00:24] <kiko-afk> Fujitsu, we don't actually store that.
[00:24] <Fujitsu> Ah.
[00:24] <kiko-afk> cprov, it's ironic that this bug actually happens because of build-from-accepted :)
[00:25] <cprov> kiko-afk: yes, kind of short-blanket problem.
[00:26] <kiko-afk> cprov, random idea: could we not put an empty Packages.gz on-disk when activating the PPA? is that crazy?
[00:27] <Fujitsu> I discounted suggesting that as being too much of a hack.
[00:28] <kiko-afk> Fujitsu, well, maybe it is -- just wondering, you know. 
[00:28] <cprov> kiko-afk: i don't see how we can tweak the archive disk from the activating-PPA UI
[00:28] <kiko-afk> cprov, of course, separate boxes.
[00:29] <kiko-afk> cprov, how about not depending on the PPA itself unless at least once source has been published in it?
[00:29] <kiko-afk> cprov, or even one binary
[00:29] <kiko-afk> might one binary work?
[00:29] <cprov> kiko-afk: more often publishing cycle would mitigate this problem and uncover other (archive being changed while being read)
[00:30] <kiko-afk> right
[00:30] <kiko-afk> cprov, I'm thinking don't send the apt sources line for the PPA until we know it's safe to send it.
[00:30] <kiko-afk> what do you think?
[00:30] <cprov> kiko-afk: "blinks" .. that's an good idea 
[00:30] <kiko-afk> that might not be too hard to do
[00:31] <kiko-afk> MIGHT
[00:31] <compbrain> If I am pulling the launchpad all packages build status index for my ppa, im not setting off any bells, yes?
[00:31] <compbrain> (periodically?)
[00:31] <Fujitsu> compbrain: I got a couple of IPs blocked once for pulling a page once an hour.
[00:31] <Fujitsu> That was a while ago, mind you.
[00:32] <compbrain> feh.
[00:32] <kiko-afk> compbrain, what are you pulling?
[00:32] <compbrain> the all-package status page for our ppa, then pulling package build information for non-complete builds
[00:33] <kiko-afk> compbrain, maybe it's easier if you tell me URLs?
[00:33] <compbrain> +archive/+builds
[00:33] <compbrain> and +archive/+build/(\d+)/
[00:33] <emgent> hello
[00:34] <compbrain> hi.
[00:34] <kiko-afk> compbrain, that shouldn't be too big a problem -- what's the period?
[00:34] <Hobbsee> hi emgent 
[00:34] <compbrain> Main page every 15-30, package builds only if their not done about the same, not more than 5 in a given pull
[00:35] <compbrain> kiko-afk: This was the reason for the RSS request bug. we've got a svn->source builder->launchpad->test cluster->release procedure going
[00:49] <spiv> The "Timeline" part of a project page is a bit weird, because it doesn't actually involve any times or dates (just milestones, which don't give much of a sense of time...).
[00:50] <kiko-zzz> spiv, it's actually more like "Series and releases"
[00:50] <spiv> kiko-zzz: Yeah.  Rather than like "line of time" ;)
[00:52] <cprov> Fujitsu: just because we are buddies, bug 207486
[00:52] <ubotu> Launchpad bug 207486 in soyuz "The dependency-lookup method is not restricted to the context PPA" [High,Confirmed] https://launchpad.net/bugs/207486 - Assigned to Celso Providelo (cprov)
[00:53] <kiko-zzz> cprov, ah, neat bug, and probably easy to fix. 
[00:54] <cprov> kiko-zzz: yes, it won't be hard.
[00:54] <kiko-zzz> cprov, it's funny how the PPA stuff really shakes out our multi-archive code
[00:55] <cprov> kiko-zzz: indeed, we keep discovering uncovered callsites 
[01:00] <ubotu> New bug: #207486 in soyuz "The dependency-lookup method is not restricted to the context PPA" [High,Confirmed] https://launchpad.net/bugs/207486
[01:05] <ubotu> New bug: #207488 in launchpad "should pick up .asc files automatically" [Undecided,New] https://launchpad.net/bugs/207488
[01:10] <ubotu> New bug: #207491 in launchpad "ability to register multiple release url patterns" [Undecided,New] https://launchpad.net/bugs/207491
[01:11] <emgent> cprov: ping
[01:12] <cprov> emgent: pong
[01:12] <emgent> cprov: please see bug #207490 and bug #207494
[01:12] <ubotu> Bug 207490 on http://launchpad.net/bugs/207490 is private
[01:12] <ubotu> Bug 207494 on http://launchpad.net/bugs/207494 is private
[01:12] <emgent> notified keescook too.
[01:12] <emgent> another security issue
[01:12] <Fujitsu> cprov: That's what I thought it would be.
[01:12] <emgent> O_o
[01:13] <emgent> :
[01:14] <cprov> emgent: sorry, pidgin doesn't like me
[01:14] <cprov> emgent: uhm, I see 
[01:14] <emgent> cprov: use irssi :)
[01:14] <cprov> emgent: I've fixed other similar bug in the past, but it was in soyuz area.
[01:14] <mpt> spiv, could you report a bug on renaming Timeline?
[01:15] <emgent> yes i know
[01:15] <cprov> emgent: of irssi it's the other way around ;)
[01:15] <emgent> hahah ok :P
[01:15] <spiv> mpt: sure
[01:15] <MacTaylor> how do i remove my email address from a bug update list?
[01:15] <Fujitsu> MacTaylor: Go to the bug, and click `Subscribe/Unsubscribe' in the actions menu on the left.
[01:16] <Fujitsu> Or it might just be Unsubscribe in your case.
[01:18] <cprov> emgent: thanks for filling those bugs, they will be triaged tomorrow morning, I guess (EU & US time)
[01:18] <emgent> np :)
[01:31] <ubotu> New bug: #207499 in launchpad ""Timeline" on a project page is misnamed" [Undecided,New] https://launchpad.net/bugs/207499
[03:22] <frenchy> Hi All!
[03:26] <frenchy> I'd like to raise a blueprint but I'd like to check that no one has addressed this already because it seems like an obviously feature.  The ability to send someone to send another launchpad user an email message through launchpad.
[03:30] <frenchy> Many LP new users don't make their email addresses public when they add translations (for example).  It would be nice to get in contact with them.
[03:33] <mpt> frenchy, that's reported as a bug
[03:33] <mpt> one moment, I'll find it
[03:35] <mpt> There's bug 66105, which is about prospective team members in particular
[03:35] <ubotu> Launchpad bug 66105 in launchpad "Team admin can't contact prospective member who hides e-mail addresses" [Medium,Confirmed] https://launchpad.net/bugs/66105
[03:35] <mpt> For translators in particular, there's bug 8
[03:35] <ubotu> Launchpad bug 8 in rosetta "Translator forums/means of communication" [Wishlist,Confirmed] https://launchpad.net/bugs/8
[03:40] <frenchy> mpt: Thanks.
[03:41] <frenchy> Huh, 8, I knew that it must have one of the first things that people complained about.
[03:54] <mpt> Well, that was long before we hid e-mail addresses
[03:54] <mpt> but it would have been useful regardless
[04:36] <ubotu> New bug: #207532 in launchpad "Product and Project don't have read-only registrant" [Undecided,New] https://launchpad.net/bugs/207532
[04:37] <Fujitsu> mpt: So I can create lots of bogus projects, throw them to various groups and people, and there's really no record? Very nice.
[04:44] <poolie> mpt, http://www.design-police.org/ :)
[04:45] <Fujitsu> Comic Sans is illegal. That's what I want to hear.
[05:01] <mpt> http://bancomicsans.com/
[05:03] <Fujitsu> Hahahah. I like the motto.
[06:09] <cody-somerville> Could a launchpad admin please change the owner of the xubuntu-doc team from ~registry to ~xubuntu-team? Thanks.
[06:37] <spiv> Heh.
[06:37] <spiv> "Successfully registered branch smart-http-fix for this bug." ... "Timeout error" -- on the same page!
[06:38] <Hobbsee> spiv: launchpad is undecisive.
[07:05] <jamesh> spiv: just use bzr to associate the branch
[07:07] <jamesh> "bzr commit --fixes lp:NNNN"
[07:46] <carlos> morning
[08:17] <mdke> hi carlos 
[08:17] <carlos> hi
[08:18] <mdke> carlos: would it be possible yet to give me permissions to upload po files to ubuntu/gutsy/+source/ubuntu-docs for all languages, so that I can upload po files with my fixes?
[08:18] <mdke> (would Launchpad then merge the relevant changes and ignore untranslated strings that have been translated since those po files are created?)
[08:19] <carlos> mdke: the only way to do that is being a rosetta-admins member, so unfortunately, no, I cannot do that without doing code changes (this is something we could do, let's say it's a missing feature)
[08:20] <mdke> right ok
[08:20] <mdke> well, I don't know what the answer is, it seems I'm going to have to fix the same mistakes each time I download po files
[08:20] <carlos> mdke: Launchpad will not ignore untranslated strings, but unset them. You would need to remove those strings from the uploaded file so that reversion is not done
[08:20] <mdke> ouch
[08:21] <carlos> mdke: Anyway, we had a bug in Launchpad that was making impossible to do what you want to do if you already uploaded such fixes as 'published'
[08:22] <carlos> that bug is fixed and the fix will be rolledout today
[08:22] <mdke> carlos: it seems that it's impossible anyway :)
[08:22] <carlos> mdke: I suggest you to file a bug to get such permissions as the owner of the source package
[08:23] <mdke> carlos: sure, I can do that... but then I'd have the problem of having to remove all strings from each po file except the one I fixed...
[08:23] <carlos> mdke: there is a command that would do it for you
[08:23] <mdke> really?
[08:24] <carlos> yeah, I think msgfilter is the command you want
[08:24] <mdke> ok, I'll look into that. How will it know which string is the one I want?
[08:25] <carlos> mdke: or maybe msggrep... Danilo should be more helpful with that
[08:26] <carlos> mdke: you need to look for messages without translations
[08:26] <mdke> I suppose I should really filter out all messages except the ones I have touched
[08:27] <mdke> that way if someone has changed a string since I download the po file, that change will be preserved
[08:28] <carlos> mdke: just to be completely sure... could you confirm that you don't have access rights to https://translations.launchpad.net/ubuntu/hardy/+source/ubuntu-docs/+pots/about-ubuntu/ace/+upload ?
[08:28] <danilos> mdke: that would be your best bet, but if you've got all three PO files (i.e. original translation before you fixed it, your fixed translation, and new translation) you can do it mostly automatically with msg* tools
[08:28] <mdke> carlos: I can see that page
[08:29] <carlos> mdke: ok, then you have enough rights and the problem is the bug I told you about
[08:29] <mdke> oh wow
[08:29] <carlos> mdke: hmm, you don't need to worry about it, Launchpad is smart enough to handle those cases
[08:29] <danilos> mdke: if you need help in getting a script to do this kind of merge, I can help you out :)
[08:29] <mdke> when the fix is rolled out, if I want to upload a file, which of the options should I choose?
[08:29] <carlos> mdke: if someone changed a translation after you got the export from Launchpad, those changed messages will be ignored from your upload
[08:30] <mdke> danilos: seems I just need to remove untranslated strings
[08:30] <carlos> mdke: User upload
[08:30] <mdke> carlos: rock
[08:30] <carlos> mdke: I thought you were not going to merge with what we have in Launchpad
[08:30] <carlos> if you get latest version in Launchpad, you don't even need to remove untranslated strings
[08:30] <carlos> mdke: as long as you don't touch the X-Launchpad-Exported header
[08:31] <mdke> I'd prefer not to have to get the latest version, if there is an easier way (like removing untranslated strings)
[08:31] <carlos> mdke: I mean X-Launchpad-Export-Date
[08:32] <danilos> mdke: yeah, but if you want to give priority to some translations from your update (i.e. fixed XML) and other translations from user changes (i.e. their own spelling fixes or whatever), it gets complicated
[08:32] <carlos> mdke: if you do that, you will need to update X-Launchpad-Export-Date so the upload is not rejected/ignored
[08:32] <mdke> ok, you've lost me now :)
[08:33] <carlos> mdke: you should look at it like a kind of wiki lock that will prevent you to overwrite other people's work
[08:33] <mdke> ok
[08:33] <carlos> if you get latest version in Launchpad and apply all your fixes, everything will work
[08:33] <danilos> mdke: well, we have a PO header 'x-launchpad-export-date' which checks exactly this case: if you keep the export date as it is, you'll basically be fixing everything you want _except_ cases where translators have changed the same messages like you have
[08:33] <carlos> if someone changes a string after your download and before your upload
[08:34] <carlos> those changes will produce that your changes in your upload is stored (only for those messages that were changed)
[08:34] <carlos> and you will be notified by email about those messages
[08:34] <danilos> carlos: but that will overwrite other updates from translators as well
[08:34] <carlos> danilos: if he gets latest version from Launchpad, that shouldn't happen
[08:34] <carlos> except for the ones that he wants to fix
[08:35] <danilos> carlos: right, but I believe it's better not to get the latest version from LP, just upload what he already has
[08:35] <mdke> the problem is that if I have 20 po files I want to fix, getting the latest version from Launchpad each time is a PITA
[08:35] <carlos> mdke: if you don't get latest version, you must do what danilo said before, filter out all messages that are not fixes
[08:35] <danilos> carlos: that should not be the case
[08:36] <mdke> bbiab
[08:36] <carlos> danilos: ?
[08:36] <danilos> carlos: actually, the date from lp-export-date would be older than new fixes in LP
[08:37] <danilos> carlos: so it should work exactly as desired
[08:37] <carlos> danilos: that's assuming the header is not removed in ubuntu-docs SVN
[08:37] <danilos> carlos: well, right, that's what I am assuming
[08:37] <carlos> and that the broken messages were not changed since last sync he got for the fixes
[08:37] <carlos> not changed in Launchpad
[08:38] <danilos> carlos: right, but I assume the chances there are small, and he'll still get an email about them and they'll be easy to spot (i.e. look for some XML :))
[08:40] <ubotu> New bug: #207581 in rosetta "Import queue UI: hard to find products that need review" [Undecided,New] https://launchpad.net/bugs/207581
[08:44] <mdke> carlos, danilos - ok so in summary:
[08:45] <danilos> mdke: yes :)
[08:45] <mdke> provided I keep the lp-export-date the same as it was when i downloaded the po files, LP is clever enough to see which strings I have changed, and ignore any other ones (except in the case where a translator has changed a broken string at a later date, in which case I'll be emailed)
[08:45] <mdke> (as long as I make the upload after the fix is rolled out today)
[08:47] <mdke> correct?
[08:47] <carlos> mdke: right
[08:47] <mdke> brilliant, that's exactly what I want
[08:47] <mdke> so the e-lp-export-date string seems intact in our bzr branch - "X-Launchpad-Export-Date: 2008-02-24 12:17+0000\n"
[08:47] <mdke> since I only edit the files with gedit, I'd expect that these won't change
[08:48] <mdke> thanks guys
[08:48] <carlos> mdke: also, please, remember to update 'PO-Revision-Date'
[08:49] <carlos> if a translator uploaded a new version with a newer date there, your upload will be rejected completely
[08:50] <carlos> danilos: btw, with superfast imports and X-Launchpad-Export-Date feature, I wonder whether this check would be removed... we added it as an optimisation long time ago... Maybe keep it only for syncs with upstream/package imports...
[08:51] <danilos> carlos: what do you mean? what if two translators work on the same file at the same time, one downloads/uploads, another works in LP?
[08:51] <carlos> danilos: X-Launchpad-Export-Date will handle that case correctly
[08:52] <danilos> carlos: right, so I misunderstood you: what check do you want removed then? :)
[08:52] <carlos> danilos: We reject any uploaded file with a PO-Revision-Date older than the one from the latest uploaded file
[08:52] <danilos> carlos: PO-revision-date?
[08:52] <carlos> danilos: yeah
[08:52] <carlos> for user uploads
[08:52] <danilos> carlos: ah, sure, that makes sense
[08:52] <carlos> and keep it for published/imported ones, given that X-Launchpad-Export-Date doesn't applies in that case
[08:53] <mdke> carlos: ok, so if I update that field, it will be ok?
[08:53] <mdke> I won't be overwriting anyone's translations?
[08:53] <carlos> mdke: yeah
[08:53] <carlos> mdke: no
[08:53] <carlos> yeah for the first, no for the second ;-)
[08:53] <mdke> good :)
[08:53] <jtv> carlos: isn't the po-revision-date also useful in cases where newer uploads bypass older ones because the old ones don't get auto-approved?
[08:54] <mdke> ok, late for work - thanks again for your help
[08:54] <carlos> jtv: which usually happens only for imported/published uploads and why I suggest to keep it for those imports
[08:54] <carlos> mdke: you are welcome
[08:55] <carlos> jtv: for user uploads, X-Launchpad-Export-Date field will handle those conflicts
[08:55] <jtv> carlos: in that case, perfect.
[08:55] <carlos> only for the messages with conflicts, instead of reject the whole file like we do with PO-Revision-Date
[08:55] <jtv> carlos: conflict exception?
[08:56] <carlos> jtv: we accept all changes except for the messages with conflicts and notify the user by email
[08:58] <jtv> carlos: it'd definitely remove a nuisance.  I have this vague suspicion that some users may not update that field at all.
[10:01] <ubotu> New bug: #207625 in soyuz "Unicode characters improperly displayed in PPA changelog" [Undecided,New] https://launchpad.net/bugs/207625
[11:32] <emgent> heya people 
[11:55] <tseliot> hi all, could anyone approve my new translation template (for Envy), please?
[11:56] <ubotu> New bug: #207680 in soyuz "Community Admin: Require MOTU archive admin celeb & queue access for universe/multiverse" [High,Triaged] https://launchpad.net/bugs/207680
[11:57] <Hobbsee> Fujitsu: ^ will be interesting
[11:57] <Fujitsu> Indeed.
[11:57] <Hobbsee> bigjools: is someone supposed to go and create that, or?
[11:57] <Fujitsu> I heard something like that was meant to be happening for s-i-s.
[11:58] <bigjools> no, it's internal code
[11:58] <Fujitsu> Seems strange for it to be a celebrity.
[11:58] <bigjools> 1.2.4 is going to see a lot of UI changes for admin!
[11:58] <Hobbsee> woot!
[11:58] <Hobbsee> will i see some of my UI bugs about the admin stuff fixed?
[11:58] <bigjools> yes
[11:58] <bigjools> actually - do you have the numbers handy?
[11:59] <Hobbsee> * No select all checkbox at the top of the queue (https://launchpad.net/ubuntu/gutsy/+queue) https://bugs.edge.launchpad.net/soyuz/+bug/152880
[11:59] <Hobbsee> * If you accept packages from the UNAPPROVED queue, it says they're accepted, and takes you back to the NEW queue.  This should take you back to the UNAPPROVED queue (but the message is good!) https://bugs.edge.launchpad.net/soyuz/+bug/152884
[11:59] <Hobbsee> * The queue page does not show you what the current override for each package is - ie, if it's main/restricted/universe/multiverse https://bugs.edge.launchpad.net/soyuz/+bug/152886
[11:59] <ubotu> Launchpad bug 152880 in soyuz "no select all packages checkbox at the top of https://edge.launchpad.net/ubuntu/gutsy/+queue" [Medium,Confirmed] 
[11:59] <Hobbsee> * No accept/decline button at the top of the queue too - only at the bottom - https://bugs.edge.launchpad.net/soyuz/+bug/152890
[11:59] <ubotu> Launchpad bug 152884 in soyuz "If you accept packages from the UNAPPROVED queue, it says they're accepted, and takes you back to the NEW queue." [Undecided,New] 
[11:59] <ubotu> Launchpad bug 152886 in soyuz "The queue page does not show you what the current override for each package is" [Undecided,New] 
[11:59] <Hobbsee> * Queue should default to 75 items, not 20.  https://bugs.launchpad.net/soyuz/+bug/54297
[11:59] <bigjools> Fujitsu: it's a celeb team because it can't be the same as the currently permission uploaders (or you can just approve your own upload)
[11:59] <ubotu> Launchpad bug 152890 in soyuz "No accept/decline button at the top of the queue" [Undecided,New] 
[11:59] <ubotu> Launchpad bug 54297 in soyuz "Increase the default minimum batch size for +queue page" [Wishlist,Confirmed] 
[12:00] <ubotu> New bug: #207682 in soyuz "Community Admin: Require MOTU buildd admin celeb & access to retry universe/multiverse builds" [High,Triaged] https://launchpad.net/bugs/207682
[12:01] <Hobbsee> bigjools: any chance on the community admin spec being made public?  i'd be interested in reading it.
[12:01] <Fujitsu> bigjools: I would have thought it would make more sense to add per-component/pocket archive admin fields, but I guess a celebrity is just as good as long as only one distro is around.
[12:02] <bigjools> Hobbsee: it's not really written yet, I need to work on it, but sure I'll let you have a look when it's done
[12:02] <Hobbsee> bigjools: cool, OK
[12:02] <Fujitsu> Having specs like that somewhat public is surely very important, as people actually have to use them...
[12:03] <Hobbsee> Fujitsu: they won't attempt to use it until it's actually pronounced to work.
[12:03] <bigjools> Fujitsu: we didn't see the need to add that level of granularity for archive admin work
[12:03] <Hobbsee> Fujitsu: and actualy, for that sort of stuff, you probably *want* them to be private, as there's bound to be at least one OMGTSIF critical bug, which needs to wait for the next rollout, so the less people who use it, the better.
[12:03] <bigjools> in 1.2.5 we'll have extra permissioning for package-specific uploaders though
[12:04] <Fujitsu> bigjools: -security will need completely different teams, won't it?
[12:04] <bigjools> security is being done in a private PPA
[12:04] <Fujitsu> As will universe, so that's already fairly granular.
[12:04] <Hobbsee> Fujitsu: YMMV, but that's what we found last time.
[12:05] <bigjools> does universe need a different set of archive admin permissions to multiverse>?
[12:05] <Fujitsu> bigjools: That'd be another spec that'd be nice to have a public version of.
[12:05] <Fujitsu> bigjools: Very unlikely.
[12:05] <Hobbsee> no
[12:05] <Fujitsu> (s-i-s, that is)
[12:05] <bigjools> ok, good :)
[12:06] <bigjools> I'll quickly summarise the plan for you, it will be good to get early feedback
[12:06] <bigjools> we have 4 main tasks
[12:06] <bigjools> 1. archive admin for MOTU, done via a new celeb that can access universe/multiverse uploads
[12:07] <bigjools> 2. MOTU Buildd admin, to retry builds for universe/multiverse
[12:07] <bigjools> 3. package-driven permissioning
[12:07] <bigjools> 4. queue override in the UI pages
[12:07] <bigjools> mmm I missed one, there's 5. post-publication override too
[12:08] <Hobbsee> bigjools: why a separate buildd admin there?  
[12:09] <Fujitsu> WRT #2... why not just let component uploaders retry, like in PPA?
[12:09] <Hobbsee> aren't there so few anyway, that it makes sense to let everyone access everything?
[12:09] <Fujitsu> Yep.
[12:09] <Hobbsee> Fujitsu: because it's not quite like the ppa stuff.
[12:09] <Hobbsee> Fujitsu: and do you really trust all the MOTU's to do reprio'ing in a good way?
[12:10] <bigjools> a separate team allows for more flexibility
[12:10] <Fujitsu> Hobbsee: hence my `retry' bit.
[12:10] <Hobbsee> bigjools: true
[12:10] <Hobbsee> Fujitsu: oh, just retry.  i missed that bit.
[12:10] <bigjools> and I know how demanding our users are ;)
[12:10] <Fujitsu> Hobbsee: Rescoring and buildd adminning should still be done build a separate team.
[12:10] <Hobbsee> right, yeah.  i misread it then, sorry.
[12:10] <Hobbsee> bigjools: ...cancel builds?  pretty please??  :D
[12:10] <Fujitsu> Er, I can't speak English, apparently.
[12:11] <bigjools> hehe - it's not in the agenda :(
[12:11] <Hobbsee> bigjools: why?
[12:11] <Hobbsee> bigjools: why is all this new stuff on the agenda with buildd admins, yet something as simple and important as cancelling builds not be there?
[12:12] <Fujitsu> Poking sysadmins to fix buildds isn't really ideal.
[12:12] <Hobbsee> Fujitsu: you haven't done it, i suspect.
[12:12] <bigjools> Hobbsee: what you perceive as simple isn't necessarily so
[12:12] <Hobbsee> bigjools: well, relatively speaking.  i know nothing in soyuz is simple.
[12:12] <bigjools> but I will raise it and see what we can do
[12:12] <Hobbsee> thanks.  it would be really good to have.
[12:13] <bigjools> I know... it would make our life easier too to be fair
[12:13] <bigjools> are you guys going to UDS?
[12:14] <Hobbsee> bigjools: you can't seriously think i got an invite.
[12:14] <Hobbsee> bigjools: i think i whinged far too much for that.
[12:15] <bigjools> heh
[12:15] <bigjools> there's a fine line between whinging and constructive feedback :)
[12:15] <Hobbsee> bigjools: if i'm actually active, maybe i'll get to prague+1.  If not...
[12:15] <Hobbsee> yeah well.  apparently i never give constructive feedback, so...
[12:16] <bigjools> and I thought it was supposed to be Brits who whinged :)
[12:16] <Hobbsee> maybe the brits learned to shut up and take it like it was, rather than attempting to change it.  apparently the aussies haven't learnt that lesson yet
[12:17] <Hobbsee> er, s/was/is/
[12:17]  * bigjools ducks out of the conversation at this point!
[12:17] <Hobbsee> heh
[12:18] <bigjools> look out for more bugs file for admin - I'm beavering away on them right now
[12:18] <bigjools> 1.2.4 is going to get a lot targeted to it
[12:18] <Hobbsee> bigjools: was my list helpful?
[12:18] <Fujitsu> bigjools: Realistically targetted?
[12:18] <bigjools> Hobbsee: yes thank you.  We won't get around to all of that, but I think at least 2 of them can be done
[12:19] <Hobbsee> Fujitsu: better not to ask that.
[12:19]  * bigjools has cracked the whip of realism on the Soyuz team
[12:19] <Hobbsee> bigjools: the checkbox, the queue default length, and the wrong url redirect?
[12:19] <bigjools> I'm finally convincing cprov not to target 50 bugs to each milestone!
[12:19] <Hobbsee> woot!
[12:19] <Fujitsu> bigjools: Yay!
[12:20] <bigjools> our current priority is the LP 2.0 goals, plus any critical bugs
[12:20] <bigjools> Hobbsee: the batch size and the override info
[12:21] <bigjools> should be easy to do those - I'll also see if we can do a "un/check all"
[12:21] <Hobbsee> bigjools: right.
[12:21]  * Hobbsee would have classed the wrong url redirect as the most annoying of them, but OK
[12:21] <Hobbsee> guess it depends if you're doing the default queue or not
[12:22] <bigjools> yeah it sounds irritating
[12:22] <Fujitsu> Is s-i-s realistically targetted to 1.2.4?
[12:22] <bigjools> yup
[12:23] <bigjools> it's mostly done already
[12:23] <Fujitsu> ie. very near Hardy release?
[12:23] <Fujitsu> Very nice.
[12:23] <bigjools> it won't be done in time for Hardy
[12:23] <Fujitsu> As long as it doesn't explode.
[12:23] <bigjools> but soon after
[12:23] <Fujitsu> Right.
[12:23] <bigjools> we have a couple of infrastructure privacy issues to fix and then it's going live
[12:24] <Fujitsu> (I mostly do security stuff these days, hence the interest)
[12:24] <bigjools> actually, I hope to get it tested before 1.2.4 with security builds that are not embargoed
[12:24] <bigjools> Fujitsu: we have the capability to have a separate PPA for MOTU security
[12:25] <Fujitsu> bigjools: How does copying from security PPAs to primary occur?
[12:26] <bigjools> right now it's a command line utility, but in this cycle we're adding UI support for it
[12:26] <Fujitsu> So it's the same process as any other PPA?
[12:26] <bigjools> pretty much
[12:26] <Fujitsu> But executable by -security rather than -archive, I hope...
[12:27] <bigjools> it will use the same permissioning as the private PPA does
[12:27] <bigjools> btw if you see P3A anywhere, that's a private PPA :)
[12:27] <bigjools> PPPA....
[12:27] <Fujitsu> Aha.
[12:41] <ubotu> New bug: #207701 in soyuz "Community Admin: The queue UI should allow overriding" [High,Triaged] https://launchpad.net/bugs/207701
[12:58] <emgent> hi barry :)
[13:01] <barry> emgent: hi!
[13:02] <barry> emgent: do you have details on how the rename broke your list?
[13:08] <emgent> yep
[13:09] <emgent> 550 5.0.0 ----->>> User mailbox is Full. Quota limit excedeed <<<-----
[13:09] <emgent>    ----- The following addresses had permanent fatal errors -----

[13:09] <emgent>     (reason: 550 unknown user)
[13:09] <emgent> (sorry for little flood)
[13:09] <emgent> ops sorry. I'm dude. correct email is ubuntu-whitehat@lists.launchpad.net.
[13:09] <emgent> just a moment.
[13:11] <emgent> barry: all ok, sorry.. working fine
[13:11] <emgent> :)
[13:11] <barry> emgent: phew! that's great to know.  i think we'll be able to automate such renames in the future
[13:11] <barry> thanks for letting us experiment on you :)
[13:11] <emgent> heheh thanks to you :)
[13:13]  * emgent go to fix horde3
[13:14] <soren> Are uploads to -proposed announced anywhere?
[13:41] <BUGabundo> hi there
[13:41] <BUGabundo> I keep having trouble opening new bug via email/malone
[13:41] <BUGabundo> is any dev able to look at the error emails and tell me what is wrong?
[13:42] <Hobbsee> BUGabundo: are you signing them?
[13:42] <BUGabundo> ye
[13:42] <BUGabundo> *yep
[13:42] <BUGabundo> I sign all my emails
[13:43] <BUGabundo> ill email back the bounce to LP ML
[13:43] <BUGabundo> so you can have a look
[13:44]  * Hobbsee is no LP dev.
[13:45] <BUGabundo> I know hob
[13:45] <BUGabundo> sent
[13:46] <BUGabundo> did you get it?
[13:46] <intellectronica> BUGabundo: can i have a look?
[13:47] <BUGabundo> sure
[13:47] <BUGabundo> all help is good
[13:47] <BUGabundo> please reply here
[13:47] <BUGabundo> I won't be seeing email until tonight
[13:47] <BUGabundo> bug 207733 is cracking me open...
[13:47] <ubotu> Launchpad bug 207733 in openoffice.org "[hardy] openoffice about says v2.3 and v2.4" [Undecided,New] https://launchpad.net/bugs/207733
[13:47] <intellectronica> email is so old fashion anyway :)
[13:48] <BUGabundo> buuuu
[13:48] <BUGabundo> how do you want poor me to register and reply to LP while offline?
[13:49] <intellectronica> i'm just joking. this is an internet meme that has been making rounds for a few years now and i never quite get
[13:50] <BUGabundo> but I do agree with you
[13:50] <BUGabundo> social networks
[13:50] <BUGabundo> and IM
[13:50] <BUGabundo> will rule soon
[13:51] <BUGabundo> we had that discussions so many timesssss on jaiku
[13:52] <intellectronica> BUGabundo: did you send your bounced email? i can't see it yet
[13:52] <BUGabundo> I did
[13:52] <BUGabundo> let me see if I got the ack
[13:53] <BUGabundo> no ack
[13:53] <BUGabundo> looks like the ML is slow
[13:57] <BUGabundo> where is the LP list archive?
[13:57] <BUGabundo> lists.canonical
[13:57] <Hobbsee> it's shown off lists.ubuntu.com
[13:58] <BUGabundo> found it on the archibe
[13:58] <intellectronica> really?
[13:58] <BUGabundo> naaaaa
[13:58] <BUGabundo> just the old one
[13:59] <BUGabundo> with the same subject
[13:59] <BUGabundo> humm
[13:59] <BUGabundo> didn't kiko set moderation?
[13:59] <BUGabundo> might it have been caught?
[13:59] <BUGabundo> resending...
[13:59] <BUGabundo> sorry if it gets DUPPED
[14:04] <BUGabundo> ahhhh
[14:04] <BUGabundo> I know what prevent it
[14:04] <BUGabundo> I think it got to big
[14:04] <BUGabundo> 70KiBs
[14:05] <intellectronica> BUGabundo: what's too big, an attachment to the email you sent to LP?
[14:05] <BUGabundo> because of the attached image
[14:05] <BUGabundo> nooo
[14:05] <BUGabundo> the fw to LP list
[14:05] <intellectronica> oh
[14:06] <BUGabundo> but didn't get any bounce either
[14:06] <intellectronica> i doubt that 70k is beyond the limit
[14:06] <BUGabundo> its no on the archives
[14:06] <BUGabundo> so users will get it soon
[14:07] <BUGabundo> then how do you explain that the 1st didn't make it, and the 2nd did?
[14:07] <BUGabundo> it was the only change I did
[14:08] <BUGabundo> Hobbsee: have a look at it, now if you please
[14:08] <BUGabundo> kiko is also here now. he replied to my old email
[14:09]  * Hobbsee sees one there
[14:09] <BUGabundo> maybe he can shed light on this
[14:09] <intellectronica> BUGabundo: well, the error message you received is correct, isn't it? you didn't specify a target for the bug
[14:09] <intellectronica> or am i missing something?
[14:10] <BUGabundo> I did use openoffice-base
[14:10] <BUGabundo> isn't that correct?
[14:11] <Hobbsee> openoffice-base is not a source package.
[14:11] <BUGabundo> I reported against it on LP, a few minutes ago
[14:11] <BUGabundo> and it worked
[14:12] <BUGabundo> brb
[14:12]  * BUGabundo goes change copier tonner
[14:28]  * BUGabundo is back
[14:29] <BUGabundo> so any tips to prevent me from failing to post to LP malone via email?
[14:38] <intellectronica> BUGabundo: specify the project or distribution you want to file the bug on?
[14:41] <intellectronica> BUGabundo: you wrote 'affects openoffice.org-base-core', but openoffice.org-base-core is a package, LP wouldn't know where to find it, since a package is part of a distribution. the instructions in the error email are actually pretty clear (but if they're not then we should try to improve them)
[14:41] <intellectronica> BUGabundo: also see https://help.launchpad.net/BugTrackerEmailInterface for more detailed instructions
[14:47] <BUGabundo> already open and re-reading
[14:47] <BUGabundo> so it should have been ubuntu/oo-base?
[14:47] <intellectronica> BUGabundo: cool. feel free to ask for clarification if anything is unclear
[14:47] <intellectronica> BUGabundo: yes
[15:37] <BUGabundo> kiko: are you here?
[15:37] <kiko> I was born here and will die here
[15:38] <BUGabundo> heheeh
[15:38] <BUGabundo> don't say that
[15:38] <BUGabundo> lolol
[15:38] <BUGabundo> surf will miss you
[15:38] <BUGabundo> about my question
[15:38] <BUGabundo> I had " affects openoffice.org-base-core" there
[15:39] <BUGabundo> and before that " affects openoffice.org" 
[15:39] <BUGabundo> sure, I add no distribution
[15:39] <BUGabundo> but the examples uses FF with out any distribuition
[15:39] <BUGabundo> doesn't it?
[15:41] <kiko> BUGabundo, that would be upstream FF, not ubuntu FF. what URL is that, btw?
[15:41] <BUGabundo> on the email it self
[15:42] <BUGabundo> To do this, include a line that starts with a blank space, then the word \n 'affects', then the Launchpad ID of the project or distribution, then \n (if it's a package) a slash and the name of the package. \n For example, reporting a bug on a project: \n affects firefox \n Reporting a bug on a distribution: \n affects ubuntu
[15:42] <kiko> okay
[15:42] <kiko> so we're missing an example for reporting a bug on a distribution package. can you file a bug?
[15:43] <BUGabundo> its there
[15:43] <kiko> meanwhile, file your bug by doing affects ubuntu/openoffice.org
[15:43] <BUGabundo> the line after this
[15:43] <kiko> it's not there
[15:43] <kiko> oh, really?
[15:43] <kiko> then you just didn't understand it? :)
[15:43] <BUGabundo> Reporting a bug on a distribution package: \n affects ubuntu/firefox
[15:43] <BUGabundo> well since the 1st is just a simple example
[15:43] <BUGabundo> I followedd it
[15:43] <kiko> it's for an upstream product
[15:43] <BUGabundo> the example used FF
[15:43] <kiko> not for a package
[15:44] <BUGabundo> so I entered OpenOffice
[15:44] <kiko> we should have used bzr
[15:44] <BUGabundo> didn't work, so I changed to 
[15:44] <BUGabundo>  OpenOffice-base-core
[15:44] <BUGabundo> no luck either...
[15:44] <BUGabundo> now I know
[15:44] <BUGabundo> that I should have used 
[15:44] <kiko> I'll ask intellectronica to swap ff for bzr
[15:44] <BUGabundo> " ubuntu/openoffice-base"
[15:44] <kiko> I hope that cleans things up
[15:45] <BUGabundo> and " ubuntu/openoffice" won't work because it aint uploaded to LP
[15:45] <kiko> aint uploaded?
[15:46] <BUGabundo> at least is what it says
[15:46] <BUGabundo> when you search for the packaged
[15:46] <BUGabundo> while reporting a bug
[15:46] <kiko> it's a source package name
[15:46] <BUGabundo> you lost me
[15:47] <BUGabundo> any user, like me, trying to report against OO
[15:47] <kiko> so openoffice.org
[15:47] <BUGabundo> will first try OpenOffice, but it aint there
[15:47] <BUGabundo> ahhh
[15:47] <BUGabundo> .org
[15:47] <BUGabundo> I miss that
[15:47] <kiko> BUGabundo, you can use openoffice in the web UI
[15:47] <kiko> and, if you are really a true end-user, you use the web UI, not a crazy email interface :)
[15:47] <BUGabundo> doesn't look like it
[15:47] <BUGabundo> I'm talking about WEB now
[15:48] <BUGabundo> sorry for not making it clear
[15:48] <kiko> indeed
[15:48] <kiko> there is no package called openoffice
[15:48] <BUGabundo> suere
[15:48] <BUGabundo> *sure
[15:48] <kiko> if you searched
[15:48] <kiko> you could have found it, though
[15:48] <BUGabundo> its what I did
[15:48] <BUGabundo> then I did
[15:48] <BUGabundo> found oo-base
[15:48] <BUGabundo> didn't even looked for oo.org
[15:49] <BUGabundo> is it possible to change the order that packages appear on the search list
[15:49] <kiko> not easily
[15:49] <BUGabundo> so that known packages appear first?
[15:49] <BUGabundo> like in this case with OO
[15:50] <kiko> we don't know what a "known package" is right now
[15:50] <BUGabundo> if searching for openoffice, openoffice.org should come first
[15:50] <BUGabundo> I see
[15:50] <BUGabundo> there would be the need to have some extra info
[15:50] <BUGabundo> stored some where...
[15:50] <kiko> like a download counter or something
[15:50] <kiko> yeah
[15:51] <BUGabundo> I'll open a wish bug
[15:51] <BUGabundo> not sure how many other packages would suffer from this
[15:51] <BUGabundo> but still even if a few dozens it would make sense
[15:51] <BUGabundo> or users will keep adding bugs to wrong packages
[15:52] <kiko> BUGabundo, the main problem today is people adding bugs with no package :-(
[15:52] <BUGabundo> heehe
[15:52] <BUGabundo> dificulting triage
[15:52] <BUGabundo> I'M SURE that it has to do
[15:52] <BUGabundo> with an OLD BUG that I OPENED
[15:53] <BUGabundo> where I said that the package search box was to high off screen
[15:53] <BUGabundo> and users won't see it until they have reported the bug
[15:53] <BUGabundo> so its quite easy to forget it
[15:53] <BUGabundo> its just your fault on this
[15:53] <BUGabundo> the text box should always show, EVEN on small resolution screens
[15:54] <BUGabundo> I have a 1440x900 and just see the description and subject field
[15:54] <BUGabundo> if I don't scroll UP, I won't place the package
[15:55] <BUGabundo> bug #172816
[15:55] <ubotu> Launchpad bug 172816 in launchpad "launchpad focus browser on summary and "hides" package" [Undecided,New] https://launchpad.net/bugs/172816
[15:55] <BUGabundo> its just sitting there
[15:55] <BUGabundo> undecided
[15:57] <kiko> yeah, it's a good point.
[15:57] <BUGabundo> yeah?
[15:57] <BUGabundo> so is it there, without any attention?
[15:57] <BUGabundo> since November
[16:00] <kiko> BUGabundo, that's the way with bugs when you have that many bugs filed -- either you bring it to somebody's attention, or you have patience
[16:00] <BUGabundo> eheh
[16:00] <BUGabundo> that's what Im doing now
[16:00] <BUGabundo> stupid question:
[16:01] <BUGabundo> if I search form why REPORTED BUGS it won't show me the ones that are marked as dups?
[16:01] <BUGabundo> that's crazy
[16:01] <BUGabundo> I want to see ALL my bugs by default
[16:01] <BUGabundo> took me 3 min to find that OO.O, because it is now marked as dup
[16:02] <BUGabundo> and search won't even find stuff with openoffice in the subject
[16:08] <BUGabundo> kiko and other lp devs: bug 207808
[16:08] <ubotu> Launchpad bug 207808 in launchpad "launchpad should show all bugs even dups when clicking on reportedbugs" [Undecided,New] https://launchpad.net/bugs/207808
[16:11] <kiko> yeah.. BUGabundo, I think the first step there is making the default options clear
[16:13] <BUGabundo> kiko please give bug #172816 some love....
[16:13] <ubotu> Launchpad bug 172816 in malone "launchpad focus browser on summary and "hides" package" [Undecided,New] https://launchpad.net/bugs/172816
[16:14] <BUGabundo> I'm sure it would decrease the number of bugs without a package quite a bit
[16:14] <kiko> agreed
[16:15] <BUGabundo> just added a new comment
[16:15] <BUGabundo> it is a better idea
[16:16] <BUGabundo> Dont select by default any of the check boxs, and make it required.
[16:16] <kiko> that's a separate bug
[16:16] <BUGabundo> of course having them on the bottom could help
[16:16] <kiko> and I'm not sure
[16:16] <BUGabundo> humm what diferent bug?
[16:16] <BUGabundo> I'm talking about the search box bug
[16:17] <kiko> it's a separate bug disallowing "I don't know"
[16:18] <BUGabundo> I don't want that
[16:18] <BUGabundo> please leave it there....
[16:19] <BUGabundo> many times I'm not sure what's the package
[16:19] <BUGabundo> I just want for it to not be selected
[16:19] <BUGabundo> and so the user should be hinted to choose between "I don't know" and searching for a package
[16:19] <BUGabundo> EVEN if the searchbox is too high for the user to see it
[16:20] <keescook> hi! I noticed the mirror prober is only checking for Hardy.  Is that intentional?
[16:21] <ubotu> New bug: #207808 in launchpad "launchpad should show all bugs even dups when clicking on reportedbugs" [Undecided,New] https://launchpad.net/bugs/207808
[16:21] <emgent> keescook: hi! :)
[16:21] <kiko> keescook, not that I am aware of
[16:22] <keescook> kiko: compare, these:
[16:22] <keescook> http://launchpadlibrarian.net/11772344/mirrors.kernel.org-release-probe-logfile.txt
[16:22] <keescook> http://launchpadlibrarian.net/12912376/mirrors.kernel.org-release-probe-logfile.txt
[16:22] <kiko> BUGabundo, if it's a radiobutton, it needs a default option.
[16:22] <keescook> heya emgent :)
[16:23] <kiko> hmmm
[16:23] <kiko> keescook, need to ask salgado-lunch -- that's weird.
[16:24] <keescook> kiko: okay, thanks.  (btw, this is from https://edge.launchpad.net/ubuntu/+mirror/mirrors.kernel.org-release/+prober-logs )
[16:25] <kiko> yep
[16:41] <BUGabundo> sorry kiko
[16:41] <ubotu> New bug: #207818 in malone "Change bug watch form needs better validation when a non-URL is entered" [Undecided,New] https://launchpad.net/bugs/207818
[16:41] <salgado-lunch> kiko, http://releases.ubuntu.com/.manifest
[16:41] <BUGabundo> I accydently clicked on that bug HUGE button
[16:41] <salgado> keescook, ^
[16:42] <BUGabundo> that said "afects LP too"
[16:42] <BUGabundo> grrr
[16:42] <BUGabundo> me and my big curiosity!
[16:42] <BUGabundo> that should have a confirmation dialog
[16:42] <kiko> salgado, how could we make that more obvious to the user?
[16:42] <BUGabundo> please remove LP from #172816
[16:42] <BUGabundo> and just leave malone
[16:43] <kiko> BUGabundo, mark it invalid.
[16:43] <BUGabundo> done
[16:43] <BUGabundo> thanks
[16:44] <keescook> salgado: er, so this is intended behavior?
[16:44] <BUGabundo> kiko, I filed that wish bug, as 207827
[16:45] <keescook> salgado: also, I just registered kernel.org's NL and SE servers each for both archive and CD.
[16:46] <salgado> kiko, good question
[16:46] <keescook> is there some bit to flip for them to start getting verified?
[16:46] <salgado> keescook, I guess it was changed because we were probing mirrors every hour after the beta. elmo would be able to confirm
[16:46] <BUGabundo> bug #207827
[16:46] <ubotu> Launchpad bug 207827 in launchpad "[wish bug] LP should hint users whats the better package when searching for a package to report a bug" [Undecided,New] https://launchpad.net/bugs/207827
[16:46] <salgado> keescook, yes, but someone from IS has to do that
[16:46] <keescook> salgado: okay, thanks.
[16:50] <ubotu> New bug: #207827 in launchpad "[wish bug] LP should hint users whats the better package when searching for a package to report a bug" [Undecided,New] https://launchpad.net/bugs/207827
[17:58] <Rinchen> Meeting in 3 mins over at #launchpad-meeting
[17:58] <Rinchen> maybe 2 :-)
[19:14] <Rinchen> updated new meeting date
[19:28] <LaserJock> kiko: ping?
[19:30] <kiko> LaserJock?
[21:00] <ubotu> New bug: #207955 in launchpad "Drop ShockAndAwe tables" [Undecided,Triaged] https://launchpad.net/bugs/207955
[21:16] <AlinuxOS> danilos, ;) 10 000 kisses ;)
[21:24] <Rinchen> heh, kiko, I was looking at them yesterday thinking the same thing.
[21:31] <ubotu> New bug: #207969 in soyuz "ppa search fail to return expected results on some cases" [Undecided,New] https://launchpad.net/bugs/207969
[22:23] <afflux> If a project uses questions but no answer contact is specified, does that mean that nobody will receive notifications?
[22:23] <afflux> If so, is it possible to subscribe people to questions? I can't find the button :(
[22:24] <kiko> afflux, hmm
[22:24] <kiko> you can't subscribe someone else
[22:24] <kiko> so you should add an answer contact
[22:24] <kiko> what's your specific situation?
[22:25] <afflux> I'd like to have dholbach looking at: https://answers.edge.launchpad.net/5-a-day-data/+question/28167
[22:25] <kiko> afflux, let's add dholbach as answer contact!
[22:25] <afflux> kiko, as long as he doesn't hit me... :)
[22:25] <kiko> hmmm I can't add him
[22:25] <afflux> huh
[22:25] <kiko> how annoying
[22:26] <kiko> afflux, when is he back from vac?
[22:26] <afflux> kiko: no idea
[22:26] <mdke> he's back already
[22:26] <mdke> saw im today
[22:26] <kiko> mdke, good news
[22:26] <kiko> afflux, can you email him for now? there's no easy solution to this right now, and I don't have anyone who could fix that bug in the next month
[22:26] <afflux> yes, of course
[22:27] <afflux> Didn't know he's back ;)
[22:27] <kiko> I'll ping him tomorrow btw
[22:27] <kiko> I need to ask him something for Seveas too
[22:29] <afflux> okay, thanks for your help
[23:20] <muffinresearch> Anyone know if there's a way to make a project private?
[23:22] <muffinresearch> I guess it's something that might go a little against the grain but can be useful in certain circumstances
[23:27] <kiko> muffinresearch, well, not exactly. it depends on what you want to do.
[23:29] <muffinresearch> @kiko So for example you have set up a new project but want it to not to be public until some point in the future. AFAIK there's no way to do that is there?
[23:34] <Rinchen> muffinresearch, that's currently correct.
[23:35] <Rinchen> muffinresearch, open source is, well, open :-)
[23:37] <muffinresearch> @Rinchen that's what I meant by going against the grain, however initially making a project private doesn't mean it will remain private.
[23:37] <Rinchen> muffinresearch, much could be said about a closed source project too :-)
[23:39] <muffinresearch> Hmm for me personally I'm not even looking at this from a point of view of using LP to host a closed-source project but I can see why a privacy feature will be highly unlikely to be added as it might be abused in that way.
[23:39] <mpt> Could be said about Launchpad, even ;-)
[23:40] <Rinchen> to quote mpt, "whew"
[23:41] <Rinchen> muffinresearch, really it comes down to what Launchpad's core is... Launchpad is an open source collaboration service.  You can't collaborate across the open source universe with a private project.
[23:42] <Rinchen> muffinresearch, so while the concept is simple, for open source projects it doesn't really make much sense because you want to engage everyone (cathedral vs bazaar)
[23:42] <mpt> muffinresearch, if it's going to be private, why not just keep everything (Bazaar branches, lists of bugs etc) on your own machine?
[23:42] <muffinresearch> Yeah makes total sense
[23:55] <Odd_Bloke> The downtime banner at the top of the page is helpful, thanks! :)
[23:56] <Rinchen> heh
[23:56] <Rinchen> Odd_Bloke, how are the pqm enhancements coming? ;-)
[23:57] <Odd_Bloke> In my head, it's fantastically easy to use and does everything you could ever want.
[23:57] <Odd_Bloke> On my laptop, it has yet to be setup correctly in the first place. :p
[23:58] <Odd_Bloke> I'm away for a week on a remote island in Scotland, so I may spend some time with it then.
[23:59] <Rinchen> lol
[23:59] <Rinchen> my my, look at the time