[07:11] <tsimonq2> https://launchpad.net/ubuntu/+source/yara/3.11.0-2/+build/17974429
[07:12] <tsimonq2> What this is implying is that a source carried over from Focal -> Groovy needs an NCR if there are failed builds.
[07:12] <tsimonq2> At least, from my interpretation.
[07:12] <tsimonq2> That seems fairly peculiar.
[07:29] <mvo> hey, the snapd ppa upload fail current (https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/19231876) with "INFO 	Built-Using refers to source package apparmor (= 2.10.95-0ubuntu2.11), which is not known in xenial in ~snappy-dev/ubuntu/image" - any suggestions what I can do to fix this?
[07:35] <tomwardill> mvo: see the chatter in launchpad-ops
[08:05] <mvo> thanks tomwardill
[08:06] <tomwardill> I don't entirely follow it myself, just got back from PTO, but I think it's an unintended consequence of a new feature, cjwatson will know more
[08:14] <mvo> tomwardill: if it's know I will just be patient, thanks for the update
[08:58] <cjwatson> mvo: You can also drop Built-Using for now as a workaround given that this is part of implementing the feature - it didn't do anything before.  But I expect to weaken that constraint shortly until we get more details sorted out
[09:41] <mvo> ok, thank you
[10:26] <mvo> cjwatson: is there a bug I can subscribe to about the built-using issue? I'm preparing the workaround now
[10:31] <cjwatson> mvo: sorry, no, but the temporary workaround at our end is already on master
[10:31] <mvo> cjwatson: cool, I hope it's ok if I create one, then I can reference it in my workaround and once closed I revert the workaround
[10:31] <cjwatson> Sure
[10:32] <mvo> cjwatson: is there a (rough)timeline for deployment ? no rush, just curious
[10:32] <cjwatson> mvo: today
[10:32] <mvo> cjwatson: heh, nevermind then
[10:33] <mvo> cjwatson: I will just wait a bit
[10:33] <cjwatson> I just need to get it past our slightly flaky buildbot
[10:33]  * mvo nods
[13:34] <xalqor> Hi everyone
[13:35] <xalqor> I'm trying to backport postfix 3.5.1 to ubuntu 18.04
[13:35] <xalqor> I followed directions to create the package and upload it to my ppa on launchpad
[13:35] <xalqor> I got an email that the package upload was accepted into my ppa
[13:36] <xalqor> But the package list in my ppa is empty
[13:36] <xalqor> So when I do apt-get update,  even though it lists my ppa in the sources,  it doesn't see any packages there
[13:37] <rbasak> xalqor: check "View package details" on your PPA page. The package might still be building.
[13:38] <xalqor> It says there were build failures on amd64 and i386
[13:38] <xalqor> Hmm... I thought I built that on my machine before uploading?
[13:39] <xalqor> Ok I'm looking at the log, I don't actually see the issue
[13:39] <xalqor> It seems to be complaining about some dummy package "sbuild-build-depends-core-dummy"
[13:40] <xalqor> Here is the build log: https://launchpadlibrarian.net/477446139/buildlog_ubuntu-bionic-amd64.postfix_3.5.1-1~ubuntu18.04.1~ppa1_BUILDING.txt.gz
[13:40] <cjwatson> The actual error is above
[13:40] <cjwatson>  sbuild-build-depends-postfix-dummy : Depends: debhelper-compat (= 12)
[13:40] <cjwatson> That's telling you that bionic doesn't have that version of debhelper
[13:41] <cjwatson> You can reconfigure your PPA ("Edit PPA dependencies") to use the backports pocket in the primary archive, since bionic-backports happens to have debhelper 12.  Or you can backport the package to work with debhelper 11.  Your choice.
[13:42] <cjwatson> Your local test probably wasn't in a clean enough environment
[13:43] <xalqor> Ok -- I'm a total newbie at packages -- I'm setting ubuntu dependencies to backports on my ppa
[13:44] <cjwatson> The "rmadison" tool (the name is a patchwork of multiple layers of historical reasons, don't even try ...) in the devscripts package is handy for getting a quick view of which packages exist where.  "rmadison debhelper" in this case
[13:46] <xalqor> I will check that out.
[13:47] <xalqor> debhelper | 11.1.6ubuntu1               | bionic
[13:48] <xalqor> debhelper | 12ubuntu1                   | disco
[13:48] <xalqor> debhelper | 12.1.1ubuntu1~ubuntu18.04.1 | bionic-backports
[13:49] <cjwatson> The other thing that may not be obvious is that each version of debhelper declares a Provides field expressing the compatibility levels it supports
[13:49] <cjwatson> (among other things)
[13:49] <cjwatson> So for instance in focal:
[13:49] <cjwatson> $ apt-cache show debhelper | grep ^Provides
[13:49] <cjwatson> Provides: debhelper-compat (= 9), debhelper-compat (= 10), debhelper-compat (= 11), debhelper-compat (= 12), dh-sequence-dwz, dh-sequence-elf-tools, dh-sequence-installinitramfs, dh-sequence-systemd
[13:50] <cjwatson> And in the above build log, apt is saying that it couldn't find anything that was actually a package called debhelper-compat with version 12 (which we don't expect anywhere), or a package that has Provides: debhelper-compat (= 12)
[13:52] <cjwatson> In bionic it's just "Provides: debhelper-compat (= 9), debhelper-compat (= 10), debhelper-compat (= 11)"
[13:52] <xalqor> So setting the ppa dependencies to backports means that launchpad can use debhelper 12 in bionic-backports to build it
[13:53] <cjwatson> Right.  Each build gets its own /etc/apt/sources.list dispatched to it on top of a corresponding clean base image, and will only be able to see things that are available starting from that
[13:54] <xalqor> Looks like the build worked this time, but I'm still waiting for it to upload
[13:54] <xalqor> I guess from the launchpad build server to the repository
[13:55] <xalqor> https://launchpadlibrarian.net/477499548/buildlog_ubuntu-bionic-amd64.postfix_3.5.1-1~ubuntu18.04.1~ppa1_BUILDING.txt.gz
[13:55] <cjwatson> My personal preference is normally to backport to the target series' released version of debhelper instead, but that can be a more involved process and does need more experience
[13:56] <cjwatson> The upload in question is from a temporary staging area to Launchpad's database
[13:56] <cjwatson> There's then a separate publication step
[13:56] <cjwatson> But it all looks in progress now, so cup of tea time
[13:58] <xalqor> I always forget the kitchen accessories at home
[13:59] <xalqor> Thanks for the help :)
[14:03] <xalqor> I'm still not seeing it in the package list
[14:05] <xalqor> Not sure what status I should be looking for to know that it should be there
[14:08] <xalqor> Both amd64 and i386 targets are showing up as successful builds now on launchpad
[14:10] <xalqor> Ah it's showing up now
[14:10] <seb128> hey there, question of the day
[14:10] <seb128> is that a bug or am I overlooking something?
[14:11] <seb128> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1802675 has a comment from today but https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1802675/+activity has the most recent even in decembre?
[14:43] <wgrant> seb128: Activity tracks bug metadata changes.
[14:55] <seb128> wgrant, oh, thanks, it's not obvious from the label
[14:56] <seb128> wgrant, do you know if there is a way from the api to query who was the last person to comment on a bug?
[14:56] <wgrant> seb128: Not without iterating through bug.messages, I don't think
[15:02] <seb128> wgrant, thanks
[15:36] <xalqor> @cjwatson thanks for the help. I also had to backport init-system-helpers and now it seems to be working
[15:50] <cjwatson> Good stuff
[16:37] <cjwatson> mvo: You should no longer get that Built-Using error now
[16:40] <mvo> cjwatson: \o/ thank you!
[18:04] <RikMills> someone trip over a lead? LP seems dead
[18:04] <ijohnson> yeah I can't get to LP either :-|
[18:05] <sarnold> ilasc, btw, no notice on https://twitter.com/launchpadstatus yet
[18:06] <sarnold> ah I hadn't noticed the times in the topic..
[18:09] <RikMills> sarnold: they should change that twitter account to say, "if you are checking this account, launchpad is probably broken"
[18:09] <sarnold> lol
[18:10] <basd82> Hello is correct that lauchpad is unreachebol
[18:11] <sarnold> basd82: correct, it's currently offline
[18:11] <basd82> maintenance ? or mallfunction
[18:11] <sarnold> I'm not sure
[18:11] <ijohnson> seems a malfunction with network issues
[18:12] <pappacena> We are checking it, but it's mallfunction.
[18:12] <Eickmeyer> Wiki is down too.
[18:12] <basd82> Oke than it is not at my side , hope it fix soon i am in the middel of deployment
[18:17] <pappacena> Not on your side, basd82. It affects a few other services too (https://status.canonical.com/), and our team is working to put everyting back online.
[18:20] <RikMills> it was debian who had half their infra die yesterday. guess it is our turn ;)
[18:22] <Odd_Bloke> Guess we should have blacklisted "network-outage" so it wouldn't autosync. :p
[18:43] <basd82> where back up
[18:46] <RikMills> looks like build farm is not happy yet, but progress :)
[18:47] <pappacena> git and bzr might not be 100% fixed yet too (although I just did a successful git pull here). But we have people working on it.