[01:16] <Jasper> Are the builders for Launchpad stuck? We have a build that's been in the queue for 3 hours now.
[01:17] <Jasper> It's said "Estimated time: an hour" for the last three, as well.
[01:23] <wgrant> Jasper: Which build is that?
[01:24] <wgrant> We are having issues with one of our build clouds (we're a pretty good stress test for OpenStack, unfortunately), so there's a queue for the first time in a while.
[01:24] <wgrant> Let me see what I can fix.
[01:35] <Jasper> wgrant, https://code.launchpad.net/~wgreenberg/+recipe/eos-shard-daily
[01:36] <wgrant> Hmm, why are those so far behind.
[01:36] <Jasper> wgrant, thank you for taking a look
[01:37] <wgrant> Ah, urgency=low.
[01:37] <wgrant> dch recently changed to default to urgency=medium, which gives things a slight score bump. When the queue is getting backlogged, packages with the old default of urgency=low will end up slightly behind some others, so it's not so FIFO.
[01:37] <wgrant> cjwatson: I wonder if we should equate low and medium in scoring nowadays.
[01:38] <Jasper> ugh, why was it urgency=low?
[01:38] <Jasper> we're just building from git
[01:38] <Jasper> How does the git reimport work?
[01:38] <wgrant> urgency=low was the default until Debian changed it around xenial.
[01:38] <wgrant> Which is fine except when the queue is backlogged, which is very rare nowadays.
[01:38] <Jasper> It seems bizarre to me that I can bump other people's packages around by specifying a different urgency.
[01:39] <Jasper> Shouldn't urgency be used only for inner-PPA / inner-project ordering?
[01:39] <wgrant> Potentially.
[01:39] <wgrant> But we've preferred to just chastise people for abusing it, in the one or two cases that it's ever been abused.
[01:39] <Jasper> OK.
[01:39] <Jasper> wgrant, https://github.com/endlessm/eos-shard/blob/master/debian/changelog -- the changelog has urgency=medium at the top
[01:40] <wgrant> It is useful in backlogs for getting eg. important security fixes through.
[01:40] <Jasper> Which implies to me that your git reimport script sets urgency=low
[01:40] <wgrant> Jasper: Perhaps recipes hardcode urgency=low.
[01:40] <wgrant> Since that was the default in dch for about 20 years :)
[01:40] <Jasper> How could I find out?
[01:40] <wgrant> wgrant@lamuella:~/src/canonical/bzr-builder/trunk$ bzr grep urgency
[01:40] <wgrant> deb_util.py:            distributions=distribution, urgency="low",
[01:41] <wgrant> indeed
[01:41] <Jasper> ok
[01:41] <Jasper> can you bump it up?
[01:41] <Jasper> after the fact?
[01:41] <wgrant> Oh, the builds are already all running.
[01:41] <wgrant> I rescored them a couple of minutes ago.
[01:41] <Jasper> Thank you.
[01:41] <wgrant> And I'll fix the scoring algorithm to cope with medium being the new normal.
[01:41] <wgrant> But we also shouldn't have a backlog. Trying to fix that.
[01:42] <Jasper> Would be nice to either change bzr-builder to medium or score medium / low the same.
[01:42] <wgrant> Right, I'm going to set medium=low in the scoring algorithm.
[01:42] <Jasper> Cool.
[01:42] <wgrant> Well, low=medium
[01:42] <Jasper> wgrant, also, can you check our recipe configuration? My colleague, Will, who set up the recipe, says that imports happen automatically, but builds don't.
[01:42] <Jasper> Is that normal? Is it possible to set up auto builds?
[01:43] <wgrant> Hm, it is set to build automatically, at most once a day when the source branch changes.
[01:44] <Jasper> hm
[01:44] <Jasper> So maybe we didn't wait long enough
[01:44] <wgrant> It won't trigger immediately, though.
[01:45] <wgrant> You need to wait for the import and then the recipe scheduler cronjob. The former is visible on the branch page, the latter is a cronjob at I think */20.
[01:45] <wgrant> */15, even.
[01:46] <Jasper> OK
[01:46] <Jasper> wgrant, thank you so much!
[01:46] <wgrant> It triggers any recipes that are set to build automatically, that haven't automatically built in the last 24 hours, and where any of the branches have changed since the last automatic build.
[01:47] <wgrant> np
[08:34] <cjwatson> wgrant: Makes sense as long as you're careful with all the hardcoded precomputed values lying around (I adjusted several recently)
[09:09] <wgrant> cjwatson: Right, I'm adjusting urgency=low up to match the new norm.
[09:09] <wgrant> Since you standardised around medium last week.
[14:04] <smoser> asking here since no one paying attention in snappy.
[14:04] <smoser> so these failures here: https://code.launchpad.net/~smoser/+snap/azure-cli thats simply "builders do not have internet access" right ?  am i missing somethign? or does that kind of mean that some large percent of the snapcraft.yaml that people would create will not work there.
[14:16] <cjwatson> Builders have internet access but only during the pull phase.
[14:17] <cjwatson> ... which is the case here.
[14:17] <cjwatson> There's a known but undiagnosed problem with npm.
[14:17] <cjwatson> https://bugs.launchpad.net/launchpad-buildd/+bug/1588870
[14:17] <smoser> ah. nice.
[14:17] <smoser> thank you.
[14:18] <smoser> i've seen this before , but npm definitely *does* use proxy
[14:18] <smoser> as i've used it on serverstack which only has proxied internet acesss
[14:18] <smoser> hm..
[14:24] <cjwatson> Yeah, the docs say it should work.  I don't know exactly what the problem is there.
[14:49] <tgm4883> Not sure the order that happened here, but I've got a building PPA that filled up and I can't delete anything from it (getting Error ID: OOPS-76f614f6c4f29a7c7b3e96162c8764a1 )
[15:21] <cjwatson> tgm4883: that's just a timeout, try again
[15:21] <cjwatson> (possibly a few times)
[15:22] <cjwatson> tgm4883: possibly also try deleting sources one at a time rather than five at once
[15:22] <tgm4883> cjwatson: heh, apparently LP is now in the middle of an update :)
[15:23] <tgm4883> or wait, might be
[15:23] <tgm4883> I just got the uh oh screen :/
[15:24] <cjwatson> tgm4883: No, we have no deployments in progress.
[15:24] <cjwatson> Oh, not a deployment
[15:24] <cjwatson> Database slave server reboot
[15:25] <tgm4883> momentary blip. Ok, all marked deleted. I guess there is a cron job that actually deletes them and frees space?
[15:25] <cjwatson> Yes
[15:26] <tgm4883> ok cool. So my builds then should fix themselves at this point. Thanks cjwatson
[20:44] <clivejo> is there any way to get a list of email addresses for people in the kubuntu members team?
[21:46] <cjwatson> clivejo: you can iterate over the members using the facilities in https://launchpad.net/+apidoc/devel.html#person
[21:48] <cjwatson> lp.people['kubuntu-members'].members is an iterable of all the members; for each one, person.preferred_email_address.email is their address, though you'll likely have to cope with getting ValueError for some of those for people who've marked their email address as hidden from other Launchpad users