=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === ePierre_ is now known as ePierre === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [11:13] I'm seeing snap builds on LP fail because apt fails to fetch index files (407 Proxy Authentication Required), is this a known issue? [11:14] e.g. https://launchpadlibrarian.net/347717933/buildlog_snap_ubuntu_xenial_amd64_libreoffice_BUILDING.txt.gz [11:19] oSoMoN: could you provide a link to the build page on launchpad.net, please? [11:19] it's awkward to find from the build log [11:22] cjwatson, https://code.launchpad.net/~libreoffice/+snap/libreoffice [11:22] the last two builds failed in the same way [11:24] oSoMoN: Right, so your problem is that there's a timeout on how long snap builds are allowed to access the internet for, starting from the start of the build. You need to arrange to do all your internet access in the pull phase at the start of the build if possible, rather than after spending 2+ hours building libreoffice [11:26] so I'd need to build the libreoffice part last, to make sure that all the other parts have pulled their stage packages first [11:26] I'll try that [11:27] I'm a bit confused as to what's going on here, since we explicitly run "snapcraft pull" first [11:27] Is there a plugin that's somehow causing that to do some build work as well? [11:28] Oh, "after: [libreoffice]" in your caches part [11:28] I guess [11:29] I wonder if snapcraft causes that to mean that pull:caches can only happen after build:libreoffice [11:29] You might need to rearrange a bit [11:33] but I really need that part to run after the libreoffice one, as it requires stage files from libreoffice [11:33] I introduced that part yesterday, so that explains why the build wasn't failing before [11:33] cjwatson, any chance the timeout can be increased? [11:40] I think a colleague may have had security.ubuntu.com redirected by his ISP, and there's also https://www.reddit.com/r/Ubuntu/comments/7dpnwl/requests_to_archiveubuntucom_being_redirected_on/. Which reminds me of bug 716535. [11:40] bug 716535 in Launchpad itself "Please support Valid-Until in release files for security.ubuntu.com" [Low,Triaged] https://launchpad.net/bugs/716535 [11:41] oSoMoN: Reluctant, as it's a stopgap against malicious builds [11:41] oSoMoN: Is it possible to move {stage,build}-packages to another part? [11:41] Perhaps of increasing importance if it's becoming more common for ISPs to redirect security.ubuntu.com, as they could get end up with a stale cache with no malicious intent. [11:41] cjwatson, I understand, and I suppose it can't be adjusted on a per-buidl basis? [11:42] oSoMoN: No, it's implemented in the central proxy [11:42] ok [11:42] We have increased it in the past, but I'm more easily persuadable about that when there's a problematic build where all the network access is near the start ... [11:43] cjwatson, yes, I can probably move the stage and build packages to another part that does nothing before building libreoffice, and then run the install scriptlet in another part [11:43] rbasak: Acknowledged, but no time at the moment to work out the details of rewriting Release periodically :-( [11:43] I'll give that a try and will nag you again if it doesn't work [11:44] cjwatson: understood. I didn't expect you to have time but I thought I'd at least make you aware :) [11:48] It slightly ties into the work I did a couple of years back on doing *Release*-only republications for hash changes [11:48] Which would definitely make this easier: it's now roughly possible to republish *Release* without having to republish the whole suite === ScriptRipp is now known as ScriptRipper [19:45] wgrant: you about? [19:59] how do I unsub from merge requests? [19:59] there are no headers or footers say how to remove [20:02] ah never mind