[08:15] <LocutusOfBorg> is it normal that *lots* of builds are stopping without even a log?
[08:16] <LocutusOfBorg> I'm trying hard to build haskell stuff on arm* but they constantly fail without logs
[08:16] <LocutusOfBorg> even ghc itself
[08:28] <SpecialK|Canon> LocutusOfBorg: We've had a bit of networking unhappiness in that cluster with unhappy failure modes; we're working on the underlying issues but I'll kick off some restarts in the interim that should help the immediate issues
[08:40] <LocutusOfBorg> thanks!
[09:42] <croraf> Hi, anyone here? I have a bug to report about launchpad platform
[09:42] <croraf> Can you open following link:
[09:42] <croraf> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=microphone&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=&orderby=-
[09:43] <croraf> https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field.searchtext=microphone&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=&orderby=-datecreated&start=0
[09:43] <croraf> the second one
[09:47] <SpecialK|Canon> croraf: Yes
[09:48] <croraf> SpecialK|Canon, do you see the excessive 286 days in the list?
[09:48] <SpecialK|Canon> croraf: No
[09:53] <croraf> https://pasteboard.co/JnPxqXH.png
[09:53] <croraf> SpecialK|Canon, is this what you see?
[09:57] <SpecialK|Canon> croraf: Looks like part of it, yes
[09:58] <croraf> If you observe the Age column, you will see that all are in order except the 286 days one
[09:58] <croraf> SpecialK|Canon,
[09:58] <SpecialK|Canon> croraf: Ah except I don't have the Age column
[09:58] <croraf> Oh. Please add it.
[09:59] <SpecialK|Canon> croraf: Right, that's not the default
[10:00] <SpecialK|Canon> croraf: Am I right in thinking you're talking about the difference between "Age" and sorting by "datecreated"?
[10:01] <croraf> SpecialK|Canon, yes it is not visible by default. I thought if the serach query has it that it would be added :)
[10:02] <croraf> SpecialK|Canon, yes, it is sorted by dateCreated (that is Age). All bugs are sorted correctly except this excessive 286 days
[10:02] <croraf> I noticed this couple of days ago.
[10:04] <cjwatson> The bug was created 286 days ago, but the bug task on /ubuntu/+source/linux (the search context) was created 10 days ago
[10:04] <cjwatson> The Age column uses the former, while the search order uses the latter
[10:04] <croraf> cjwatson, this should be corrected
[10:05] <croraf> cjwatson, this "search contenxt" I dont see anywhere
[10:05] <cjwatson> It's in your URL
[10:05] <cjwatson> I'm not necessarily defending this, but both have their uses (for instance, the search order means you can see which tasks have recently appeared in a package's bug list)
[10:06] <cjwatson> So it's not obvious to me that either one is more correct as such, though I can see that this particular presentation is jarring
[10:06] <cjwatson> Anyway, to report bugs on Launchpad, please use https://bugs.launchpad.net/launchpad/+filebug - we don't generally track bug reports on IRC
[10:07] <croraf> cjwatson, if both dates are relevant then there should be 2 columns for them
[10:07] <cjwatson> That would be one possible resolution for a bug report I suppose
[10:10] <croraf> Would you comment on the bug with your note after I open it?
[10:10] <croraf> cjwatson, or I should mentioned this context.
[10:11] <croraf> this search context
[10:14] <cjwatson> Sure
[10:16] <croraf> https://bugs.launchpad.net/launchpad/+bug/1892697
[10:17] <croraf> I put your comment, cjwatson . If you wish to add something, add
[10:20] <cjwatson> Done
[10:30] <croraf> cjwatson, what is the bug task creation date?
[10:30] <croraf> When is the bug task created if not at the time when the user creates a bug?
[10:41] <cjwatson> croraf: Bugs can have multiple tasks, for example when they affect more than one piece of software.  If you look at the "Affects" table at the top of the bug in question (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1852071) you'll see that it affects both "OEM Priority Project" and "linux (Ubuntu)".  It's possible to mark a bug as affecting an additional target using things like "Also ...
[10:42] <cjwatson> ... affects project" or "Also affects distribution/package".
[10:59] <mdeslaur> hi, could someone please kill this build? https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/19856787
[11:02] <cjwatson> mdeslaur: Do you not have a "Cancel build" link there?
[11:02] <mdeslaur> yeah...I thought you told me not to use that last time I had a hung build?
[11:03] <mdeslaur> did I misunderstand?
[11:03] <cjwatson> mdeslaur: I don't remember what that was nor why I would have said that.  It's the only way I have to kill builds ...
[11:04] <mdeslaur> cjwatson: ok, thanks, sorry about that, I'll go click it
[11:04] <cjwatson> np
[11:08] <croraf> cjwatson, ok, so that the bug affects multiple piece of software and which is something that someone other than reporter sets?
[11:11] <croraf> And this search is per package. So when someone opens a bug at later time someone might set a task on another package regarding this bug.
[11:11] <cjwatson> Basically yes
[11:29] <croraf__> cjwatson, what if you want to search the bugs that dont have any package attached. The age column, as is now, would bug
[11:30] <cjwatson> croraf__: Every bug has at least one task
[11:31] <croraf__> cjwatson, when i want to report a bug i can put "i dont know" as package
[11:31] <cjwatson> Yes.  It still gets a task in that case, which would have the distribution as its target
[11:32] <cjwatson> Rendered as just "Ubuntu" rather than as "linux (Ubuntu)" or whatever
[11:48] <croraf__> cjwatson, Yes i reported a bug right now, and it shows Ubuntu target
[12:17] <croraf__> After i report a bug on linux package after 10 min the message to do the apport-collect showed up. Is this automatical, or someone did the the request to gather specific files manually?
[12:37] <cjwatson> croraf__: It's automatic
[12:37] <cjwatson> croraf__: It says so in the message ...
[12:38] <cjwatson> "This change has been made by an automated script, maintained by the Ubuntu Kernel Team"
[13:00] <croraf__> cjwatson, yes, I thought someone had to trigger this depending on the type of the request
[13:01] <croraf__> what confused me is that the first file reported is the alsa information, which is related to my specific issue
[13:01] <croraf__> but it is alphabetically first
[20:00] <ricotz> SpecialK|Canon, hi :), there are several builders marked "Cleaning" for some hours - https://launchpad.net/builders
[20:00] <gpiccoli> Hi folks, I started to observe a failure in building one package after the upgrade of PPA builders to bionic
[20:01] <gpiccoli> it seems related to the base kernel, worked on 4.4 and it's failing on 4.15
[20:01] <gpiccoli> Is there a way to set a PPA to use Xenial (or even Bionic with 4.4) to confirm that was the issue?
[20:01] <cjwatson> ricotz: Poking
[20:01] <cjwatson> gpiccoli: There is no way
[20:01] <gpiccoli> the package is cryptsetup
[20:02] <cjwatson> gpiccoli: (Should be possible to try it in a VM locally, though?)
[20:02] <gpiccoli> cjwatson, so maybe trying to reproduce locally in a chroot environment is the way to go right?
[20:02] <cjwatson> Well you'd need a pair of VMs with 4.4 and 4.15 but otherwise matching chroots to have an apples-to-apples comparison
[20:02] <cjwatson> But yes
[20:02] <gpiccoli> maybe...I'll try and see what I get. Another idea would be to try powerpc and amd64 ..to see what happens, I expect powerpc to succeed and amd64 to fail hehe
[20:03] <gpiccoli> That'd be an indication
[20:03] <cjwatson> That's a possibility, yes
[20:03] <gpiccoli> cool, let's cjwatson - thanks for confirming =)
[20:04] <cjwatson> gpiccoli: If absolutely necessary I can switch one of our staging builders back to 4.4.  But decentralised investigation is usually better :)
[20:04] <gpiccoli> sure, I agree with you, and thanks a lot for the offer cjwatson =))
[20:05] <ricotz> cjwatson, thank you
[20:05] <cjwatson> (BTW the reason we can't do this sort of per-PPA stuff is that, to minimise latency, the VM is reset before LP knows what build it might want to dispatch to it.)
[20:05] <gpiccoli> oh, cool! makes sense!
[20:06] <cjwatson> In principle it might be possible to maintain multiple pools with different properties, but that would decrease overall throughput so we try to avoid that.
[20:09] <gpiccoli> and increase complexity, something definitely bad too heh
[20:11] <cjwatson> Exactly
[20:12] <cjwatson> buildd-manager is already one of our two or three most complex services
[20:12] <gpiccoli> hehe nice!