[02:53] <slangasek> hi, I'm suddenly getting timeout errors trying to load https://bugs.launchpad.net/ubuntu/+source/update-notifier
[02:54] <slangasek> those sorts of URLs have never had problems before - has something gone wrong?
[02:54] <slangasek> (Error ID: OOPS-590b715f28bec743ec26102fd7332d21)
[02:59] <EvilResistance> confirmed on my end, (Error ID: OOPS-8fe1144b294f966bdd75b4401dcdf6b5)
[03:21] <slangasek> escalated internally with the Canonical LP team
[03:21] <EvilResistance> the timeouts seem to be global on bugs for packages, and for package pages
[03:22] <slangasek> the source of the problem has been identified; not sure how long it'll take to roll out the fix but it's being worked on
[03:22] <EvilResistance> for example, https://launchpad.net/ubuntu/+source/znc/
[03:22] <EvilResistance> slangasek:  good, i hope they realize its not isolated to just bugs.launchpad
[03:23] <StevenK> Yes, thank you.
[03:49] <slangasek> EvilResistance: the fix has been deployed
[03:49] <EvilResistance> slangasek:  that was fast :)
[03:49] <slangasek> it was a rather critical problem
[03:49] <slangasek> (and the ops were generally unhappy that it took as long as it did ;)
[03:50] <wgrant> Sufficiently unhappy that I might accidentally rewrite the deployment tool tomorrow :)
[04:19] <thumper> wgrant: juju deploy launchpad
[04:24] <nigelb> haha
[12:31] <mdeslaur> Dear launchpad: Please give me a date instead of writing "27 weeks ago". I've never had a kid, I don't know how to calculate time by counting weeks. kthx
[12:31] <wgrant> mdeslaur: You can get a date by hovering over it, FWIW.
[12:31] <mdeslaur> oh geez, /me goes to try
[12:32] <mdeslaur> hrm, not where I'm looking I can't
[12:32] <wgrant> Although that sounds like it might not be using our usual datetime formatter.
[12:32] <wgrant> Where is hits?
[12:32] <wgrant> this
[12:32] <mdeslaur> package pages: https://launchpad.net/ubuntu/+source/quagga
[12:33] <mdeslaur> "132 weeks ago" makes my head explode :)
[12:33] <wgrant>             <span tal:replace="row/published_since/fmt:approximateduration"/>
[12:33] <wgrant> It should be fmt:datetime instead
[12:33] <wgrant> fmt:approximateduration is for build times and similar short durations :/
[12:33] <wgrant> Could you file a bug?
[12:34] <mdeslaur> wgrant: sure, one sec
[12:34] <geser> mdeslaur: would you prefer "3 releases ago" instead? :)
[12:34] <mdeslaur> geser: hehe, not really :)
[12:37] <mdeslaur> wgrant: LP: #999662
[12:37]  * mdeslaur pokes bugbot
[12:37] <mdeslaur> bug 999662
[12:38] <wgrant> mdeslaur: Thanks.
[12:38] <mdeslaur> wgrant: thanks!
[12:38] <wgrant> Might fix that tomorrow.
[12:38] <wgrant> Given it's so trivial.
[12:38]  * mdeslaur hugs wgrant
[12:43] <nigelb> 9/ws 34
[12:43] <nigelb> grr
[13:03] <cjohnston> wgrant: bug #881019  -  is there a better solution than what Ricardo suggested?
[13:10] <wgrant> cjohnston: Well, the ideal solution is that people would stop creating several accounts each :/
[13:11] <cjohnston> I'm not sure how to fix that social problem ;-)
[13:11] <wgrant> cjohnston: The next best thing is to do what I said in comment #15.
[13:11] <wgrant> Ricardo's suggestion is not practical nor safe.
[13:12] <wgrant> Merging SSO accounts is a lossy operation that may lock the user out of some of their accounts -- it's not something that can be done implicitly.
[13:13] <cjohnston> ic
[16:43] <tgm4883> Is there somewhere we can see the load on the build servers? (eg. how many things are waiting to be built?)
[16:43] <tgm4883> We had to turn off our daily builds last week due to the load, just wondering if it's back to normal so we can turn it back on
[16:45] <knome> anybody familiar with the team membership moderation stuff in launchpad? i'm wondering if i can set a message for those who are trying to join a team - before they click "join" - or if one could set some period after which users would be automatically rejected if not accepted before or so
[16:46] <knome> if not, are things like that under planning?
[17:03] <dobey> tgm4883: "our daily builds" == what exactly?
[17:04] <tgm4883> dobey, Mythbuntu daily builds of MythTV
[17:04] <tgm4883> packages
[17:04] <dobey> oh. do those take exceptionally long to build or something?
[17:05] <dobey> there was another project which had daily builds running, which would often take over a day to build, and that would have disturbed the buildds, for sure
[17:05] <tgm4883> dobey, not really, the issue is when the build servers are overloaded, i386 wasn't starting until about 9 hours after amd64 had finished
[17:06] <tgm4883> that's an issue for us, as there is a single arch independent package that the amd64 installs depends on
[17:06] <tgm4883> technically it's not a large issue, but users get confused when things get "held back"
[17:07] <tgm4883> since it's a daily build, we've also noticed in the past that occasionally it would be > 24 to start the build from upload, and we'd have a new upload before the old build even started
[17:08] <dobey> right
[17:17] <geser> tgm4883: you can see the build status (and queue length) on https://launchpad.net/builders
[17:19] <tgm4883> geser, thanks, good to know.  Does 159 jobs (57 minutes) mean the time before a new upload starts building is 57 minutes?
[17:20] <tgm4883> I'm assuming yes
[17:21] <geser> tgm4883: no, it's around 57 min (depends on how good the guess it) till all packages got build
[17:21] <tgm4883> ah
[17:22] <tgm4883> still, thats a good enough estimate for us to start building again
[17:22] <tgm4883> thanks geser
[18:36] <psusi> lp emailed me about a new bug #999790, but it appears not to exist, what gives?
[18:38] <highvoltage> might be marked as private?
[18:40] <psusi> I can see private bugs and it didn't indicate that in the email... looks like the same user filed several bugs about failed upgrades due to dependency problems today and most of them seem to have been deleted, which I didn't think was possible
[18:40] <maxb> I don't believe they can be, but perhaps someone made them private outside the scope of your permissions?
[18:41] <psusi> is there such a thing?  could an lp admin check?
[18:41] <dobey> if a bug was filed, and you can't see it, then it is private and you don't yet have permissions to see it. crash reports are a common thing which fits into this scenario, as they are private to only apport until it retraces them
[18:42] <psusi> I can see those
[18:42] <maxb> IIUC, private bugs are visible only to subscribers. So yes, it's quite easy for a bug to be private but not visible even if you have a role in the project
[18:42] <psusi> I often see the pending retrace bugs with the private flag
[18:43] <psusi> unless there are two different versions of private?
[18:43] <maxb> Yes, but that's only one possible kind of private bug. I believe there's a dedicated team subscribed to private crash bugs
[18:44] <maxb> https://launchpad.net/~ubuntu-crashes-universe
[18:45] <psusi> I'm an indirect member
[18:45] <TrollinPenguin> AHAHHAHA maxb
[18:45] <maxb> That was quite random
[18:46] <psusi> looks like that group is a member of bugcountrol which I'm a member of... which I guess explains why I can normally see the private reports
[18:46] <psusi> so unless there's some super dooper double secret, I think something's gone wrong with lp
[18:47] <dobey> i don't think anything has gone wrong with lp
[18:48] <maxb> Well it's possible, of course, but seems much more likely the bug has just been made private
[18:48] <psusi> then why does it say these bugs don't exist?
[18:48] <dobey> well, abnormally wrong, anyway :)
[18:48] <dobey> because they are private
[18:48] <maxb> It doesn't say they don't exist
[18:48] <psusi> being marked private doesn't explain that since I have access to see the private bugs...
[18:48] <maxb> It says they don't exist or are private
[18:48] <maxb> psusi: You do not have access to see private bugs
[18:49] <dobey> psusi: you do not have access to see all private bugs
[18:49] <dobey> psusi: you have permissions to see private bugs which you have permissions to see. nothing more.
[18:49] <maxb> psusi: You have access to see private bugs to which you are directly or indirectly subscribed (just as everyone does)
[18:49] <psusi> yes... well, I'm subscribed, why do you think I got the email?
[18:49] <maxb> You happen to be a member of a team which lets you see one particular common kind of private bug
[18:49] <maxb> I'd guess someone unsubscribed the team
[18:50] <psusi> wouldn't I get an email saying they unsubscribed/reassigned/flagged private?
[18:50] <maxb> I'm unsure of that detail
[18:50] <psusi> I normally do...
[18:51] <maxb> In the specific case of bugs, it would be better if LP wasn't quite so cagey about revealing the existence of private identifiers - since the identifiers are a trivial sequence
[18:55] <psusi> the only way I can see for me to have lost access to it is for someone to have flagged it private, and also changed the package it was assigned to... neither of which would make sense since there isn't anything sensetive about the bug, and I should have gotten an email about the change.  rather than engage in conjecture, it would be helpful if an admin could actually take a look.
[19:37] <mounirb> I have a project that I have subscribed a group to see the bugs. The bugs are private. Do we have to subscribe the group to each bug we open? We need the bugs to remain private, the subscription to the bugs at the project level is not working, is this correct for private bugs?
[19:40] <maxb> I don't think project/package level bug subscriptions have any influence on private bug access
[19:42] <mounirb> maxb: you probably right. This is what I see. I wanted to make sure this is the case.  If that is true, then for each private bug, we have to subscribe the group specificaly.
[19:44] <maxb> Each project can have a team in the "bug supervisor" role. I *think* the bug supervisor probably gets automatically subscribed to a project's private bugs
[19:45] <maxb> Though I'm not 100% sure of that
[20:02] <mounirb> maxb: are you suggesting to subscribe the team as the supervisor?
[20:02] <mounirb> maxb; I mean subscribe the group to be the supervisor?
[20:03] <maxb> I'm suggesting it might work
[20:03] <maxb> But you probably want to test or seek more knowledgeable advice
[20:30] <mounirb> maxb: ok will try it - thank you
[20:45] <wgrant> psusi: You won't generally get an email when you lose access, because you no longer have access.
[20:45] <wgrant> mounirb: Is this a proprietary project with a commercial subscription?
[20:46] <mounirb> wgrant no
[20:47] <mounirb> wgrant: it is a project that we want to keep the development closed for a while with access to specific people
[20:47] <jkyle> afternoon
[20:47] <wgrant> mounirb: That requires a commercial subscription.
[20:48] <wgrant> mounirb: Only public open source projects can use Launchpad without a commercial subscription.
[20:50] <wgrant> Projects with commercial subscriptions can be configured to automatically make all their bugs private, and subscribe the bug supervisor team so they can see them.
[20:50] <jkyle> I need ti import a openpgp key into launchpad to sign code of conduct agreement. The instructions describe how to do so using an ubuntu gui. I'm OSX or have access to some virtual machines with unbuntu, no gui. anyone have a less ubuntu+gui centric reference for this process? Also, it's unclear if this is only intended for ubuntu os?
[20:50] <mounirb> wgrant - it is open source project, we want the development to mature a little before we open it
[20:51] <wgrant> That doesn't sound too open source right now.
[20:52]  * jkyle thinks he found a cli tut
[20:52] <wgrant> jkyle: https://help.launchpad.net/YourAccount/ImportingYourPGPKey#Using_GPG_to_manage_OpenPGP_keys
[20:54] <jkyle> wgrant: yep, that's the one I found :)
[21:08] <thopiekar> hi :) I found spam in this bug report: https://bugs.launchpad.net/ubuntu/+source/compiz-fusion-plugins-main/+bug/183685
[21:08] <thopiekar> see the last comments
[21:12] <jkyle> woot, encrypted mail. couldn't figure out how to do it in outlook, got it goign on mail.app pretty easily