[00:07] <poolie> Noldorin: no it doesn't
[00:07] <poolie> there is a bug for this
[00:07] <Noldorin> poolie, ah right. link at hand?
[00:08] <micahg> no, it just links it to the bug, fixed in bzr isn't fixed for most projects
[00:08] <poolie> https://bugs.launchpad.net/launchpad/+bug/318439
[00:09] <poolie> click 'affects' if you like
[00:09] <Noldorin> poolie, thanks. i'll follow that
[00:09] <Noldorin> no big deal for now
[00:09] <Noldorin> as long as i know
[00:10] <micahg> ah, that bug makes sense :)
[00:10] <Noldorin> sounds like a feature
[00:10] <Noldorin> not a fan of the solution either
[00:10] <Noldorin> (proposeD)
[00:10] <Noldorin> but oh well
[00:21] <poolie> which solution?
[00:46] <poolie> lifeless: does this actually mean O(one minute) downtimes?
[00:54] <lifeless> poolie: 300s is the initial window I have gotten an ack for
[00:54] <lifeless> poolie: thats the satisfying criteria
[00:55] <poolie> in the sense of our stakeholders could tolerate more frequent bumps if they're no more than 5m?
[00:56] <lifeless> yes
[00:57] <lifeless> we all want as low as possible
[09:22] <pfarrell> how is the code update going? :-)
[09:23] <dupondje> seems done :)
[09:23] <wgrant> Not quite.
[09:23] <wgrant> Half-way back up.
[09:25] <pfarrell> cool, good luck with it :-)
[09:25] <dupondje> what happens with emails sent to launchpad? they get queued ?
[09:26] <wgrant> dupondje: Right.
[09:29] <wgrant> dupondje, pfarrell: Everything should be back now.
[09:29] <pfarrell> sweet, thanks
[09:30] <dupondje> wgrant: getting timeout error when trying to add patch in a bug
[09:30] <wgrant> dupondje: Do you have an OOPS ID?
[09:31] <dupondje> (Error ID: OOPS-2020CO69)
[09:31] <wgrant> Thanks.
[09:51] <dupondje> something broken ? ;)
[09:56] <dupondje> wgrant: its broken ? :)
[09:56] <lifeless> yes, should be fixed in a minute
[09:57] <wgrant> dupondje: Sorry, yes, in the middle of the fix.
[10:00] <dupondje> aight :D
[10:00] <dupondje> great service
[10:00] <dupondje> :)
[10:26] <apw> any known issues with the launchpad API since the upgrade?  getting "HTTP Error 503: Service Unavailable" from scripts that worked yesterday
[10:27] <wgrant> apw: We have some DB load issues at the moment. Not quite sure if they'll settle down on their own.
[10:27] <apw> wgrant, so keep hammering it until they work :)
[10:27] <wgrant> Something like that...
[10:28] <lifeless> apw: 16 core machines w/128GB of RAM are a little hard to come by on short notice
[10:28] <apw> lifeless, i am sure they are, though i am also sure you didn't release code which you expected to need another one either
[10:29] <wgrant> apw: Well, the normal master DB is getting a disk upgrade.
[10:29] <lifeless> no; so this isn't bad code - we're upgrading the disks on the master machine, so we're running degraded on the replicas
[10:29] <wgrant> apw: So one of the slaves has been promoted.
[10:29] <apw> wgrant, ok so assuming that the issue is just the slave is 'crap', how long is the outage going to be
[10:30] <lifeless> apw: we did anticipate some load (but as the replicas service many requests anyway, no degradation)
[10:30] <lifeless> apw: grab one of the oops ids and get wgrant to look at it; you may be suffering unrelated to load.
[10:31] <apw> lifeless, i am not getting an oops, just a 503 service unavailable responses via the zope api
[10:31] <wgrant> apw: That will have an OOPS ID.
[10:31] <wgrant> apw: Probably in the X-Lazr-OopsID header and the body.
[10:31] <apw> wgrant, ok will try and find it in the 2.5k of html thats its dumping on me :/
[10:32] <wgrant> Yay!
[10:32] <apw>         <code class="oopsid">OOPS-2020CF91</code>)
[10:32] <wgrant> Thanks.
[10:33] <wgrant> Ah, Ubuntu tag searches FTL :(
[10:34] <apw> wgrant, yep one of those painful scripts one has to run because searching in the interface can't find anything
[10:35] <wgrant> Can't find anything?
[10:35] <wgrant> Oh, the CVE FTI thing?
[10:35] <apw> wgrant, yep, the CVE titles don't match, closed development tasks, search issues
[10:38]  * apw notes that nominations have gotten worse, you used to be able to nominate up to two series, now even 1 is too many :/
[10:40] <apw> (Error ID: OOPS-2020DR100)
[10:41] <apw> any idea how long we are going to be degraded, so i know how long to schedule for lunch
[10:43] <wgrant> apw: Potentially up to a day, but we are trying to sort it out.
[10:43] <geser> apw: that will be a long lunch break :)
[10:44] <apw> well as i can't do anything anymore, i guess i have no choice
[11:12] <soren> Argh.. I get a timeout trying to see our PPA page: https://launchpad.net/~nova-core/+archive/trunk  (Error ID: OOPS-2020AS123)
[11:14] <soren> I appreciate you want to track it when things are slow, but I really do wish there was a way I could specify that what I'm trying to do is important to me, and that I'm ok waiting an extra couple of seconds for it.
[11:16] <soren> What I'm trying to say is that I'd rather have a slow Launchpad than no Launchpad at all.
[11:16] <chrisccoulson> hmmm, i'm getting a timeout consistently when trying to access https://code.edge.launchpad.net/~mozillateam
[11:16] <chrisccoulson> OOPS-2020EDGEA42 for example
[11:17] <soren> chrisccoulson: Works for me. (on non-edge)
[11:17] <chrisccoulson> soren, yeah, me too
[11:26] <spiv> soren: it's not just about tracking (we have soft timeouts that are also reported without aborting the page like hard timeouts), it's also about freeing up resources so that other requests aren't overly impacted by the slow parts.
[11:27] <cjwatson> Does anyone know why https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152 might be stuck in "Updating branch..."?  I pushed changes to it yesterday
[11:27] <spiv> (Part of the problem is that if something is slow, it's often *really* slow, more than just "an extra couple of seconds")
[11:37] <soren> spiv: For this particular case, the alternative was to retry 4 extra times before it finally worked. I can't imagine doing the first 9 seconds of each request 4 times is less costly and takes less resources from others than just letting the request run for 12 seconds or however much it would have been the first time around.
[11:38] <soren> ...and I doubt I'm the only one who routinely retries when I'm met by a timeout oops.
[11:39] <wgrant> soren: But then you get a really bad request which goes on for 5 minutes.
[11:40] <soren> wgrant: Maybe the 9 seconds (isn't that what the limit is?) are just a tad optimistic?
[11:40] <wgrant> soren: Around 0.01% of requests time out.
[11:41] <wgrant> soren: Today is special.
[11:41] <soren> wgrant: How so? caches not warmed up yet?
[11:41] <wgrant> (most of that 0.01% is ubuntu tag searches)
[11:41] <wgrant> soren: Our DB master is currently undergoing hardware upgrades, so we're running on inferior slave hardware.
[11:41] <wgrant> 8 cores rather than 16.
[11:42] <soren> wgrant: Oh.
[11:42] <wgrant> Didn't expect it to be quite this bad, though.
[11:42] <SteveExodus> i would like my money back ...
[11:45] <soren> wgrant: Perhaps put that in the /TOPIC or something? Just to help manage expectations.
[11:45] <soren> wgrant: I for one expected it was the code update that caused it and it would be this bad until the next major code update... Which would really suck.
[11:55] <tsarev> Hi there
[11:55] <tsarev> Guys, I have two troubles with launchpad
[11:55] <tsarev> http://img560.imageshack.us/img560/4340/screenshot1t.png - first
[11:55] <tsarev> http://jenkins.percona.com/view/Percona%20Server%205.1/job/percona-server-5.1-param/57/console - second
[11:55] <tsarev> Anybody able to help me?
[11:57] <bigjools> tsarev: yes I can help
[11:57] <tsarev> bigjools: great :)
[11:57] <bigjools> 1. the site is slow today as we are running on degraded hardware
[11:58] <bigjools> keep retrying
[11:58] <bigjools> 2. the output tells you what the problem is
[11:58] <bigjools> "bzr: ERROR: Not a branch: "/var/lib/jenkins/workspace/percona-server-5.1-param/".
[11:58] <tsarev> bigjools: about first - thank you
[11:58] <tsarev> bigjools: No-no, trouble ois before
[11:58] <tsarev> bigjools: bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~percona-dev/percona-server/5.1_slow_extended_tests_fixes/".
[11:58] <tsarev> bigjools: branch is available
[11:59] <tsarev> bigjools: http://jenkins.percona.com/view/Percona%20Server%205.1/job/percona-server-5.1-param/54/console
[11:59] <tsarev> bigjools: ^ here all ok with dir, but bzr branch not available
[11:59] <apw> wgrant, it occurs to me if the machine is half as fast would we not expect to have to proportionatly increase the timeout to match ?
[11:59] <bigjools> tsarev: use lp:~percona-dev/percona-server/5.1_slow_extended_tests_fixes
[12:00] <tsarev> bigjools: https://code.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes
[12:00] <tsarev> bigjools: I trying to build this branch
[12:00] <tsarev> bigjools: All other branch - clones, just for doublecheck what trouble not solved
[12:01] <tsarev> apw: http://bazaar.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes is permanently redirected to http://bazaar.launchpad.net/~tsarev/percona-server/5.1_slow_extended_tests_fixes/changes
[12:01] <tsarev> apw: Lines from log. Trouble on the launchpad side
[12:01] <bigjools> tsarev: use bzr+ssh:// or lp:
[12:02] <tsarev> bigjools: I used lp:~tsarev/percona-server/5.1_slow_extended_tests_fixes
[12:02] <tsarev> bigjools: in the log this is BZR_BRANCH enviroment variable
[12:02] <wgrant> apw: Not quite.
[12:02] <tsarev> bigjools: Before today all works fine.
[12:02] <bigjools> ok
[12:02] <tsarev> bigjools: We change nothing in our Jenkins
[12:03] <bigjools> the lp: url works fine for me
[12:03] <wgrant> apw: We are already fully utilising all CPU cores, so extending the timeout will just let even fewer requests work.
[12:03] <wgrant> It's not that it's slow.
[12:03] <wgrant> It's that we are over capacity.
[12:04] <wgrant> (so timeouts are fulfilling their goal here, but not quite enough)
[12:04] <apw> wgrant, and we are going to be in this state for 24 hours ?
[12:05] <bigjools> tsarev: ah you're using anonymous access
[12:05] <apw> i think that should definatly be in the topic
[12:05] <tsarev> bigjools: Yes. We allow anynimous access to our repos
[12:05] <bigjools> well I mean to LP's branch
[12:06] <bigjools> wgrant: could that be broken with this rollout?
[12:06] <wgrant> bigjools: Possibly. Just checking branch-rewrite now.
[12:06] <bigjools> I have to run out for a bit
[12:06] <wgrant> There should be maintenance people around :(
[12:06] <wgrant> I would like to leave at some point too.
[12:07] <bigjools> yes, who is on maint?
[12:07] <wgrant> Apparently nobody.
[12:17] <tim> hi, i am trying to backport gcc from oneiric to natty (mainly because of the c++0x support of gcc-4.6). it requires backporting of gcc-4.5 as well, because of a libgcc1 conflict. i got as far as uploading the package to launchpad, but launchpad doesn't start the build because of a g++ dependency conflict: http://pastie.org/2206841 ... any idea, what is going wrong? can i fix it myself, or is it simply not possible to build natty-
[12:17] <tim> provided gcc versions on launchpad?
[12:21] <wgrant> tim: You should try building it in a natty chroot/pbuilder/sbuild locally.
[12:21] <wgrant> tim: You can then diagnose the dependency issues.
[12:21] <wgrant> It's not Launchpad-specific.
[12:28] <tim> wgrant: ok will try to set up such an environment ...
[12:31] <tim> wgrant: however i wonder, why it complains about installing g++ >= 4:4.5.2-1ubuntu3 ... because natty seems to provide 4.5.2-1ubuntu4
[12:32] <wgrant> tim: It's saying that it can't install that combination of three packages.
[12:34] <wgrant> tim: It's likely that your gcc-4.6 backport has clobbered something to make gcc uninstallable in your PPA.
[12:36] <tim> wgrant: i see ... will try to find the reason ... otherwise i'll simply build gcc-4.6 from sources without creating a debian package
[13:05] <geser> tim: IIRC gcc-4.6 in oneiric has a breaks on gcc-4.5 which is newer than the version in oneiric which breakes the installation of gcc-4.5; this is known and hopefully fixed soon
[13:05] <wgrant> tsarev: That branch should be working again now.
[13:06] <tsarev> wgrant: Yes, I see already
[13:06] <tsarev> wgrant: THis was launchpad trouble?
[13:06] <wgrant> tsarev: Yeah, fallout from the rollout earlier.
[13:09] <wgrant> tsarev: Most stuff was still cached, but some new lookups weren't working.
[13:09] <wgrant> Like your branch.
[13:09] <tsarev> wgrant: Cool. I'm happy what you solve
[13:10] <tim> geser: i see ... will keep my eye on the gcc versions of oneiric
[13:33] <dpm> hi deryck, are you around and have got a minute for a translations sharing question?
[13:33] <deryck> dpm, on call, available shortly.
[13:34] <dpm> deryck, no worries, I can also ask henninge now that he's around
[13:34] <dpm> henninge, have you got a minute for a translations sharing question?
[13:34] <henninge> dpm: yes but I might get called in to the doctor's any time.
[13:34] <henninge> ;)
[13:35] <dpm> henninge, ok, we'll try to make it quick and painless then :)
[13:35] <dpm> so here it is:
[13:35] <dpm> I've created a table with the intltool-based source packages that will support upstream sharing, with the intention to give an overview and let the community help in enabling sharing:
[13:35] <dpm> https://wiki.ubuntu.com/Translations/Projects/LaunchpadUpstreamImports
[13:36] <dpm> (I need to remove some redundant fields to make it more readable, though)
[13:36] <dpm> As all of the projects are already linked to a source package, I understand that the next step is to enable translations in the upstream projects, and here is my question:
[13:36] <dpm> Given the following translation_usage in the upstream project, do these settings make sense as the ones to recommend?:
[13:36] <dpm> Projects with external translations:
[13:36] <dpm> • Permissions: Closed
[13:36] <dpm> • Translations group: does not matter
[13:36] <dpm> • Translation Import mode: templates + translations
[13:37] <dpm> Projects with translations in Launchpad:
[13:37] <dpm> • Permissions: Structured
[13:37] <dpm> • Translations group: Launchpad Translators/Ubuntu Translators
[13:37] <dpm> • Translation Import mode: templates only
[13:37] <dpm> henninge, so, does that make sense? ^^
[13:37] <henninge> dpm: those look good
[13:38] <henninge> dpm: maybe even suggest "Restricted" permissions?
[13:38] <henninge> dpm: AFAIK Ubuntu uses that setting nowadays
[13:38] <dpm> henninge, ah yeah, good point, my mistake, I wanted to actually suggest "Restricted", yes
[13:39] <dpm> regarding "Closed" permissions, can one still see the statistics?
[13:39] <henninge> dpm: other than that this looks sane
[13:39] <henninge> dpm: not sure.
[13:39] <henninge> If not, that'd be a bug I think.
[13:39] <dpm> henninge, ok, I guess we'll soon find out. Thanks!
[13:40] <henninge> dpm: pleasure
[14:20] <jam> is the branch scanner stopped, or did I just break it?
[14:20] <jam> I submitted this about an hour ago: https://code.launchpad.net/~jameinel/bzr/2.2-is-up-to-date/+merge/67836
[14:20] <jam> It is based on a fairly old version, but the actual changes are pretty small.
[14:23] <jam> I did do a "commit --unchanged" as the last commit, but I don't see why that would break anything
[14:25] <commandoline> hello, my translations aren't imported from the trunk branch. Does anyone know what the problem can be? https://translations.launchpad.net/openteacher/trunk/+imports
[14:29] <jam> danilos: ^^ any chance you can figure out why the diff is still "pending" after 45 minutes?
[14:41] <rye> hi all, is merge proposal diff generator working or there is a huge backlog of tasks? it's been 3 hours since mp submit :(
[15:04] <soren> Are new uploads not being accepted?
[15:05] <soren> I uploaded a package at 13:24 UTC which made it through just fine.
[15:06] <soren> Then I uploaded another one at 14:31 which, at 14:49 still hadn't shown up so I reuploaded it. Still no trace of it.
[15:06] <bigjools> danilos: ^
[15:07] <soren> The package is called "keystone", uploaded to ppa:soren/keystone
[15:10] <cyberdeck> hi, how long does it usually take until you get an accept/reject mail after uploading some source.dsc to your own launchpad ppa?
[15:10] <cyberdeck> *uploaded with dput
[15:10] <bigjools> there's a problem at the moment it seems
[15:10] <bigjools> looking into it
[15:10] <Logan_> I can't get a public key. :|
[15:11] <cyberdeck> is there any kind of upload/incoming queue where one can take a look at? (sry for the newbie question)
[15:12] <Logan_> nvm
[15:13] <bigjools> cyberdeck: there isn't
[15:13] <cyberdeck> oh, ok. thank you!
[15:13] <bigjools> I think there's just a massive backlog at the moment
[15:13] <soren> cyberdeck: Under normal operations, things don't sit there for more than at the most 5 minutes.
[15:14] <bigjools> there were performance problems earlier and it slowed the upload processor down
[15:14] <cyberdeck> well, i got a reject mail after my first upload pretty soon. then i corrected the error and uploaded again. now, after my fourth coffee i started to wonder if it got lost.
[15:14] <bigjools> ah no it looks like someone uploaded a load of language packs
[15:15]  * soren shakes his fist at language packs
[15:15] <bigjools> be patient, it'll get there
[15:15] <cyberdeck> i'll try. even if its my first ppa upload. ^^
[15:16] <bigjools> I think it'll be about 20-30 minutes before the langpacks are done with
[15:17] <bigjools> (my finger in the air guesstimate)
[15:26] <danilos> jam: there were a few issues with some of the branch scripts, hopefully will get resolved soon
[15:32] <bigon> hi, an idea why I get a timeout? OOPS-2020D184
[15:34] <soren> bigjools: Yup, here they come.
[15:34] <soren> \o/
[15:34] <bigjools> hurray
[15:37] <cyberdeck> yay, in 52 min. my first ppa upload ever will be build. \o/
[15:37] <bigjools> congrats
[15:42] <timrc> Hello, is there a way I can get details on who copied a package into a PPA from the UI (I'm looking for a culprit, not the original uploader)?
[15:43] <bigjools> timrc: no, that's not recorded unfortunately
[15:43] <timrc> bigjools, bummer
[15:44] <timrc> bigjools, that's a particularly useful bit of information if the ppa sits upstream of another archive
[15:44] <bigjools> timrc: file a bug!
[15:49] <timrc> bigjools, oh I will
[15:49] <timrc> :)
[15:49] <candrea> Hello! Could somebody please help me with https://answers.launchpad.net/launchpad/+question/164646 ? It's not very urgent, but the sooner it is solved, the better
[15:49] <timrc> Maybe another opportunity for me to chip-in as well
[15:51] <timrc> bigjools, out of curiosity, can you find the info via the api? (e.g. is this just a case of not be supporting in the UI?)
[15:51] <bigjools> timrc: no, it's not recorded anywhere
[15:52] <bigjools> although some changes I am doing right now to make copying asynchronous could help
[15:53] <timrc> bigjools, okay I'll file the bug and assess if finding a solution is within my capability-bounds :)
[15:54] <bigjools> timrc: well, there's an easy way and a better way
[15:58] <timrc> Really, what I'm trying to solve are collisions that occur in a downstream archive as a result of people submitting packages with the same name / version but different hashsums from more than one location
[15:58] <timrc> If we could provide the URL to the immediate downstream archive, we could do this detection early... but it sounds like opening a can of worms :)

[15:59] <dpm> deryck, henninge, I'm doing a presentation on upstream sharing in a few minutes on #ubuntu-classroom, as part of Ubuntu Developer Week. (just a heads up if you're interested, no need to be there)
[16:00] <deryck> dpm, great.  Thanks for the heads up!
[16:09] <danilos> candrea, hi, I am not sure what is going on there, I'm looking around
[16:10] <candrea> thank you danilo
[16:15] <Ampelbein> hi there, I just got OOPS-2020DW183 while filing a bug via the api.
[16:38] <zyga> HI
[16:39] <zyga> is there a way to extend the dreaded launchpad timeout?
[16:39] <zyga> I keep getting a problem when trying to copy _ONE_ package from a ppa
[16:39] <zyga> (Error ID: OOPS-2020B220)
[16:42] <danilos> candrea, I can confirm the problem happens with "bzr branch" with "bzr-hg" plugin installed as well, so I suspect that's where the bug is
[16:42] <sladen> could somebody check the LP database.  Have a user ('mellgoth29@gmail.com') trying to reset their password
[16:43] <sladen> but when I try subscribing them to a bug report using that email address it is also not found, so it might not be the right one
[16:43] <danilos> zyga, if it is stopping people from doing work, we can certainly do that
[16:43] <candrea> danilos, thanks, I'm opening a new bzr-hg bug right now
[16:43] <zyga> danilos, well it is stopping me now
[16:43] <danilos> candrea, I've already did that based on the question
[16:44] <candrea> danilos, ah, great thanks!
[16:44] <zyga> plars, attempts to copy any packages at https://launchpad.net/~linaro-validation/+archive/ppa/+copy-packages fail with a timeout
[16:45] <zyga> danilos, how can I request a timeout "extension"
[16:47] <danilos> zyga, I am not sure, we'd have to talk to the powers that be and investigate how frequently does the OOPS hit our users like you
[16:47] <danilos> zyga, (and figure out the right override or fix the problem)
[16:48] <plars> danilos: zyga's trying to get through this right now and it's blocking him, is there someone in particular we should talk to
[16:48] <zyga> danilos, well right not it hits me each time I try to copy one package to the same ppa (just different series) and this seriously affects my work, is there a chance to get this resolved quickly?
[16:48] <danilos> zyga, I am also waiting for an OOPS to sync to compare with bug 575450
[16:49] <zyga> danilos, the bug description sounds about right, I think it is the same issue
[16:51] <plars> zyga, danilos: last comment on that bug seems to indicate it is believed to be fixed
[16:51] <danilos> zyga, plars: right, which is why I need to wait for OOPS to sync before I can comment further; zyga, for urgent work-arounds, you can talk to lifeless or flacoste perhaps
[16:52] <zyga> danilos, how soon will we know that the OOPS is indeed bug 575450, what's the next step if that is the case?
[16:53] <danilos> zyga, hopefully in less than 30 mins
[16:53] <zyga> danilos, I'd like to have those packages for my ubuntu-developer-week session at 19:00 UTC
[16:53] <danilos> zyga, also, it's possible that upping the timeout won't help since the query might be taking minutes!
[16:54] <zyga> danilos, minutes!
[16:54] <flacoste> zyga: we are experiencing degraded performance currently because of a DB reconfiguration issue
[16:54] <zyga> oh
[16:54] <flacoste> so that doesn't help that particular issue
[16:54] <danilos> zyga, I am just saying that when something is bad, it can be very bad, but without seeing the OOPS report, we don't know if it's fixable
[16:54] <zyga> ok
[16:54] <danilos> flacoste, oh, I thought that was reported fixed (at least it was on identi.ca/launchpadstatus)
[17:45] <bryceh> When I try to land https://code.launchpad.net/~bryce/launchpad/cronjob-component-deletion/+merge/67782 I get this error:
[17:45] <bryceh> ec2: ERROR: Merge proposal is not approved. Get it approved, or use --force to land it without approval.
[17:46] <bryceh> however the review status is approved, so I'm confused.
[17:56] <bac> bryceh: each reviewer has a review status but then the MP as a whole has a status
[17:56] <bac> yours is still in 'needs review'
[17:56] <bac> it doesn't transition automatically b/c different projects have different requirements as to how many individual approves are required
[17:56] <bryceh> bac, ok, how does that get changed?
[17:56] <bac> bryceh: for LP it is just one and you are free to change the status yourself
[17:57] <bryceh> bac, no that option doesn't appear in the status dropdown for me
[17:57] <bac> bryceh: ok, i'll do it for you
[17:58] <bac> bryceh: done.  if you remember, ask your reviewer to be sure to do it next time
[17:58] <bryceh> I see just 'Work in Progress'/'Needs review'/'Merged'
[17:59] <bryceh> bac, I seem to recall I used to be able to set branches to approved when I was on the bugs team; what has changed that I can no longer do so?
[18:01] <bac> bryceh: you have to be a member of ~launchpad-reviewers.
[18:02] <bryceh> bac, ah ok thanks
[18:06] <bryceh> bac, guess that team is closed to community contributors
[18:07] <bac> bryceh: no, we decided to allow community contributors to become launchpad reviewers.  but then we hired the only person who had expressed interest.
[22:35] <pkern> The latest apt update links to LP: #784473.  Does LP claim that a page doesn't exist when privileges are missing nowadays?  I get OOPS-2020CI278 when I try to access it.
[22:38] <lifeless> pkern: yes
[22:39] <pkern> lifeless: Interesting that MOTU isn't enough.  But ok, thanks.
[22:39] <lifeless> pkern: partial disclosure is very hard to do reliably - we found some paths to inappropriate disclosure due to the older behaviour
[22:39] <lifeless> pkern: and we closed it the most expedient way; we -may- revisit it later
[22:40] <lifeless> pkern: its probably a security bug, which ~ubuntu-security is needed for
[22:40] <lifeless> pkern: I imagine it will be unembargoed once all the series are updated
[22:40] <lifeless> pkern: (I also cannot see it)
[22:41] <wgrant> pkern: It's a security bug, yeah.
[22:41] <pkern> Ah, if it's unembargoed afterwards, that's ok.  I guess the Debian security team is already aware of it, I was just checking the issue.  I also searched for the CVE and there was no bug reference, so I wondered quite a bit. ;)
[22:41] <wgrant> Debian is aware, yes.