[00:12] hello, build.snapcraft.io question: how can i tell the site to pull submodules too ? [00:14] hey guys [00:14] allah is doing [00:14] sun is not doing allah is doing [00:14] to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [00:17] captine: i guess it's commercial [00:21] is there a browser available in snappy? i am not sure how snappy works with GUIs. will it pull the whole X-server, window manager, etc?? [04:32] daker, thanks.the liune "available as an image so anyone can download" is a little misleading if it is commercial only [06:01] PR snapd#3394 closed: interfaces/seccomp: add bind() syscall for forced-devmode systems [06:49] hi guy, i'm tryng to run the command snapctl set device-service.url="https://device-service" from the login shell but i have the following error: *error running snapctl: cannot set without a context* - where is the problem? [06:57] NicolinoCuralli: you can only run snapctl from within a hook, like the prepare-device hook [06:57] manually invoking snapctl from outside of any context is not possible [06:58] pstolowski: are you still having this autopkgtest problem? [06:58] morphis_: can i run it on configure hook for a snap? [06:58] yes [06:58] NicolinoCuralli: however, "snapctl set device-service.url .." only makes sense as part of the prepare-device hook [07:02] morphis: I undestand it but i can't setup a Serial Vault for problem that I wrote in a post on forum ( no response until now) and i need to go in production in a few week with our brand store [07:05] mvo, hi! no, I followed advice from fgimenez and started from a clean directory, it's actually a problem in my branch [07:07] NicolinoCuralli: you have a link to that thread? [07:07] morphis_: https://forum.snapcraft.io/t/how-configure-serial-vault-for-signing-serial-assertion-with-a-key-registered-to-a-store/731/6 [07:08] hey pstolowski good to know! :) [07:08] NicolinoCuralli: ah I see, so the problem is just with the setup of the serial-vault, that is up to James [07:09] good morning mvo! quick question, we didn't have new edge core snaps this morning, is that expected? [07:09] NicolinoCuralli: but it is essential that snapctl set device-service.url is called from within the prepare-device hook of the gadget snap [07:09] NicolinoCuralli: otherwise your device bootstrap process may be broken [07:09] fgimenez: not expected, let me check [07:09] mvo: ok thanks! [07:10] pstolowski: aha, ok. thank you, still curious what could have caused this. when I have a free minute I will try to dig some more [07:10] fgimenez: ha! "store upload failed: service unavailable" … [07:11] mvo, the root cause i'm chasing is configure hook failure in my branch, and this is related to the renaming of SNAP_CONTEXT variable in my branch (which breaks all hooks in my branch atm) [07:13] hey hey [07:13] morphis_ : then I am blocked until jamej fix the problem :( [07:14] mvo: aha, ok, at least the dashboard seems to be fine now [07:14] NicolinoCuralli: you mean you're blocked because your device gets no serial-assertion? [07:16] morphis_ : i need to use Serial-Vault to block device not mine then i'm blocked [07:17] NicolinoCuralli: you mean you want to block other devices from accessing your branded store? [07:17] morphis_ :yes [07:17] ok [07:18] you could, as a workaround, turn device authentication off in the branded store and keep things in place until James fixes the problem [07:31] mvo: I need some time to get my stuff together and catch up, do I understand that the key issue to fix is still seccomp format? [07:37] morphis: prepare-device is very simple but without test it I am sure taht it works: it is very dangerous [07:37] morphis: prepare-device is very simple but without test it I am not sure that it works: it is very dangerous for us [07:39] zyga: no worries, the seccomp issue has multiple dimensions, the most pressing one is that we need to unblock 2.25, I will catchup with gustavo about this today in a hangout [07:39] mvo: how can I help? [07:40] NicolinoCuralli: sure, but at least you can verify that snapd takes up the right URL but fails to contact it [07:40] NicolinoCuralli: that is visible in the logs [07:41] zyga: then there is the bpf thing which will not help with the immediate issue but will help in the longer term (and is fun :) [07:42] zyga: let me think for a sec, the immediate issue is kind-of-blocked on design, I made various suggestions we now just need to decide which one we use [07:43] mvo: understood [07:43] mvo: I'll try to look at that lock issue [07:43] zyga: what was that again about? [07:45] mvo: the errors that show up on the errtracker [07:45] mvo: about /run/snapd/lock access [07:45] mvo: and one working theory that has a hard time to explain the volume of reports [07:46] zyga: aha, right, thank you [08:02] bah ... all core uploads tonight failed with LP OOPSes [08:06] ogra_: https://forum.snapcraft.io/t/store-upload-issue/819/1, fixed a few hours ago. I think Michael's retrying them. [08:07] mvo, are you ? (else i'll do it now) [08:07] ogra_: I have not yet, so go ahead [08:07] * ogra_ does so :) [08:09] oh, interesting ... at the same time i see that LP auto-retries the failed uploads now ... [08:09] so we'll get two sets :) [08:09] Oh? [08:09] Oh, you requested fresh builds? [08:09] https://launchpad.net/~snappy-dev/+snap/core/+build/41415 [08:10] I retried that one myself a couple of minutes ago [08:10] i requested fresh builds ... right afterwards i got a mail for a successfull upload [08:10] (from the former build obviously) [08:10] If the upload fails, you can just hit the Retry button on the build page. [08:10] ah, then that was you, ok [08:10] It retries just the upload step [08:10] yep, i know [08:11] clicking on 6 buttons on 6 pages is more work than calling a script for a full rebuild though ... i'm lazy ;) [08:13] Heh, fair enough. [08:13] My poor buildds :'( [08:27] wgrant, FYI, all uploads worked fine for this build [08:28] ogra_: Excellent, thanks for confirming. [08:32] pedronis: hey, could you please look at https://forum.snapcraft.io/t/the-gadget-snap/696/4 [09:01] zyga: he may not be around today [09:08] Chipaca: hey [09:08] zyga: hiya! [09:08] How was the weekend zyga? [09:09] i've seen photos of zyga doing stuff on twitter [09:11] JamieBennett: busy :) [09:11] JamieBennett: it was great, just wish I didn't spend nearly two days traveling there [09:11] JamieBennett: I sent you some quick thoughts yesterday [09:11] zyga: ouch, I didn't realise it was so long for you [09:12] zyga: saw the draft feedback, I look forward to the full report [09:12] yes, connections [09:12] zyga, The route is the goal ;) [09:12] I'm getting back to speed, catching up on stuff first (I was home past 23:00) [09:13] zyga: lets catch up in 45 mins :) [09:13] sounds good [09:15] mvo: I commented a little on https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-revert-race-condition/722/13 [09:15] mvo: I think the divest idea is sound, I think it may have to be runtime (at least partially) detected but we can work with that [09:15] mvo: I'm somewhat on edge about the digest itself, it could be nice to just call this a feature string so that we can easily eyeball things and understand what's going on [09:25] zyga: yeah, right now its not much of a digest, I also like the property that it is human readable, lets see what gustavo thinks when we have the catchup. one thing I am slightly worried about is that we need to be careful to make it not too ambitious (at least v1) because we are currently blocking on it [09:36] PR snapd#3350 closed: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots [09:43] pedronis: thank you! [09:43] pedronis: I'm sorry I didn't review that [09:44] mvo: re [09:44] mvo: let's finish here [09:45] mvo: how would you feel about teaching cmd.go to use the current revision rather than "current"? [09:46] Chipaca: hey [09:46] zyga: you mean for InternalToolPath? [09:46] Chipaca: maybe you can have a saner idea [09:46] yes [09:46] Chipaca: we have a problem where we use internal tool path that follows the current symlink [09:46] Chipaca: and in the upgrade path of core itself, we rely on that _before_ we link the now snap [09:46] Chipaca: so new snapd wishing to use its new internal tools uses the old internal tools [09:47] Chipaca: and in this case the old internal tool reports "sorry, I'm not implemented" and fails [09:47] zyga: is this master, or omg-how-on-earth released? [09:47] * Chipaca wants to know whether to have a heart attack or not [09:48] Chipaca: I think this is master and OMG people tracking channels but I think mvo knows better [09:48] Chipaca: but it would explain lots of error reports [09:48] zyga: master breaks ¯\_(ツ)_/¯ it's why it's edge, i'm less worried [09:49] Chipaca: I think its also affecting beta [09:49] Chipaca: right but the point is we cannot release and need to fix this [09:49] mvo: augh [09:49] Chipaca: I'm trying to verify this right now, sorry, we are still in the early stages of investigations [09:49] np! [09:49] zyga: what tools are we calling before we set the symlinks ? [09:49] Chipaca: the symptoms are snap refresh outputs: "setup snap "core" (2053) security profiles (cannot update mount namespace of snap "go-example-webserver": cannot update preserved namespace of snap "go-example-webserver": cannot update snap namespace: not implemented)" and fails [09:50] ah [09:50] pedronis: update-ns [09:50] pedronis: because we follow current symlink [09:50] so there was an assumption that we can call setup-profiles both in the old world and the new world [09:50] a naive approach would be to just follow the revision matching core that is running [09:51] zyga: I'm a bit confused though, if the old core is still running why is it trying to call a new tool? [09:51] zyga: is this actually related to current? [09:51] pedronis: it's the new core already [09:51] how can it be [09:51] runNamespaceTool calls mountNsPath calls mountNsPath which doesn't look at current [09:52] something is not maing sense to me [09:52] I'm looking at [09:52] https://errors.ubuntu.com/oops/ef5ad412-4519-11e7-ac3f-fa163ebeb28a [09:52] look what happens there [09:52] we never ran update-ns before it was implemented [09:52] but here we run update ns on core (so new snapd is doing that) [09:52] and it reaches the never-used, not-implemented version that just says it's not implemented and fails [09:53] ah, current is used by InternalToolPath [09:53] yes [09:53] Chipaca: yes, that's exactly the issue [09:53] zyga: thing is, it isn't current yet [09:53] we run setup-profiles firs time before we run link-snap [09:53] that's by definition the old core [09:53] so setup-profiles neeeds to run in the new core [09:54] pedronis: yes, but pre-restart snapd never touched update-ns [09:54] so it shouldn't be calling InternalToolPath [09:54] zyga: you understand the question is not how to make it work, why at all is the new core involved at that point? [09:54] zyga: question: do you know what core you're running for, from UpdateSnapNamespace? [09:55] pedronis: aha, I see [09:55] pedronis does have a good point there though [09:55] Chipaca: maybe, we could look at argv[0] or /proc/self/exe [09:56] zyga: does that get updated on execve? (i don't remember) [09:56] we split setup-profiles to avoid that sort of problem [09:56] if it's happenign a lot of other assumptions are wrong [09:56] maybe something else is at play [09:57] I have a sync call now but I will look at the revisions used there [09:57] and see if there was something wrong at that stage [10:00] * zyga joins sync call [10:08] Chipaca, zyga: *maybe* it only affects people on 2.26.3+201705171658.git.78e21e6 [10:17] zyga, Chipaca: when going over the error reports from the last two days I found only 2.26.3+201705171658.git.78e21e6, 2.26.3+201705191509.git.f89261c, 2.26.3+git209.2f19233 to be affected, everything before and after appears to be fine [10:18] _and after_? [10:19] Chipaca: well, its a good question, things do not refresh so maybe it is something else and this is just where it started [10:23] mvo: maybe that error is from an undo path? not the forward path [10:23] JamieBennett: is this me or you? [10:27] davidcalle, "download ubuntu core" on https://www.ubuntu.com/core is a 404... [10:28] kyrofa: thanks, the WIP dev.ubuntu.com has been mistakenly deployed when I was off on friday and I'm collecting the pieces... [10:28] davidcalle, ah, okay. Sorry man, that's never fun [10:29] kyrofa: I believe you are in Bluefin today? [10:29] davidcalle, I am! [10:29] davidcalle, why, are you around? [10:30] kyrofa: then hug the webteam for me, I'm sending them a ton of bug reports about it ;-) [10:30] Hahaha [10:30] kyrofa: no, I'll be there next week for a couple days [10:30] davidcalle, dangit, come on man, we need to coordinate. I'll be back end of June, come back then [10:32] kyrofa: well, I could be there, we'll see :) [10:32] ;) [10:32] Chipaca: btw maybe you can do a 2nd review for snapd#3373 [10:32] PR snapd#3373: snapstate: consider connect/disconnect tasks in CheckChangeConflict [10:33] I can [10:33] these tests make my head hurt anyway [10:37] re [11:12] * zyga lunch [11:33] davidcalle, according to a post in https://forum.snapcraft.io/t/startx-as-a-regular-user/460 the mir-kiosk docs are also gone from dev.ubuntu.com ... [11:33] ogra_: I know, see above [11:33] Oh, sorry, missed the "also" [11:34] :) [11:41] Saviq: by any chance, when you worked on it a couple weeks ago, did you kept a backup of the content? I may be able to poke around in #IS and get something (archive.org most recent is april 16th from last year), but if you have it in some form it would be way faster to get it back online [11:54] * Chipaca ~> lunch [12:07] pedronis, hmm ... my snap changes on self-built images is full with re-occuring "Initialize Device" entries ... i cant remember having that before (Initialize Device used to run only once and never again when it failed) ... is there any reason that we run it in a loop even though we alredy know the brand id will not be signable ? [12:08] that makes the snap changes output really noisy and hard to read [12:19] davidcalle: https://webcache.googleusercontent.com/search?q=cache:K946WjTJyyoJ:https://developer.ubuntu.com/en/snappy/guides/mir-snaps/+&cd=1&hl=en&ct=clnk [12:20] (21 May 2017) [12:27] daker: ah! *hug* [12:36] davidcalle: if you need more content, you can just paste the link on google, there is a little arrow to get the cached version https://imgur.com/a/hDK0D [12:40] ogra_: it's a long while it behaves like that, it has a back off though, at it end it tries 1 or 2 times per day [12:41] hmm, then i probably didnt see it because my images were old installs ... [12:41] mvo, any idea what could be affecting that I run the spread tests in linode from my machine and everything works and when I run the tests from travis the snap-confine-from-core which I modified is failing? [12:42] pedronis, but i still think trying more than once (as long as we know we reach the store and all) is a waste ... or is there any expectation that all of a sudden my barnd id can sign it ? [12:42] *brand [12:42] mvo, I mean, is there something different in the runs we do from travis? [12:43] ogra_: we expect all devices ideally to have a serial, we are erring on the side of trying by design, as I said after a while it tries 1 or 2 times per day [12:44] cachio: a good question, do you have a link to the failure? what travis runs is in .travis.yml, its very little, ./run-check.sh --static, --unit, --spread - does it maybe fail in one of the earlier tests? [12:44] pedronis, right, but it is very unlikely that a brand id that can not sign suddenly changes its behaviour [12:44] ogra_: we don't interpret the errors [12:45] so trying it over and over doesnt feel like it makes any sense [12:46] hi pedronis, new create-key timeout on i386 https://travis-ci.org/snapcore/spread-cron/builds/237349446#L1551 [12:47] mvo, this is the link https://travis-ci.org/snapcore/snapd/builds/237376386?utm_source=github_status&utm_medium=notification [12:47] mvo, I have executed those tests in the same way and I don't see any error [12:48] mvo, also I executed the failing tests from my machine using linode repeating 200 times and all tests passed [12:49] mvo, I have modified the test snap-confine-from-core to add a missing check [12:51] mvo: hey, do you have time to talk about the seccomp/snap-confine issue? [12:51] mvo: I feel like people aren't hearing my concerns about determinism [12:52] jdstrand: I have 8min, then meeting, then time again [12:52] cachio: looking, one sec [12:53] cachio: hm, that sounds strange indeed [12:53] jdstrand: am I one of the people who fail to hear your concern bout determinsim? if so, I definitely want to understand them [12:55] mvo: well, I don't know if you are-- I feel that way because I haven't heard anyone acknowledge my point :) [12:56] mvo: my point is-- the actually problem is that the policy on disk is not reflective of the snapd/snap-confine version that is used [12:56] actual* [12:56] jdstrand: not sure how busy you are today, but I would love to talk about it after our standup (so in ~30min or 45min depending how long it runs) [12:56] mvo: please ping me whenever you are free [12:57] mvo: it shouldn't take terribly long, but likely more than 8 minutes [12:57] jdstrand, mvo: I'd like to participate please [12:57] jdstrand: I think I understand your concern [12:57] (and what mvo is trying to do) [12:58] jdstrand: great, I will. however I'm not sure if thats the actual problem, I think we have a various ones (startup race, profiles not forward compatible, not versionized) but I think we will fix them all :) [12:58] zyga: sounds good [12:59] zyga: super keen to hear yours and jdstrand ideas what we can do [12:59] mvo: I don't mind any of the improvements, but my point is that it just pushes the problem around. we need to have policy that is generated by the running snapd/snap-confine version otherwise there will always be other issues. it just so happens, if that is fixed, all the improvements are less important [13:00] mvo: I think your idea is OK but jdstrand wants to ensure snapd still starts before services / commands can run, [13:00] standup! [13:00] yes [13:00] jdstrand, zyga: yes, I think we want the same, its just one of the steps [13:01] but if it is the first step, things are nice :) [13:01] anyway :) [13:45] jdstrand: tools r822 are now in prod \o/ [13:48] roadmr: woohoo! :) [13:48] roadmr: thanks :) [13:48] zyga: I sadly don't have time for that today but it would be great if we could sync up about the suse stuff tomorrow [13:59] * Chipaca kicks off spread tests and goes for a cuppa tea [14:50] sergiusens: hey! small question: is it possible in the dump plugin, or via a scriptlet to differ actions (files to install) through arch? [14:50] I can ofc run "arch" in the scriplets, and depending on the result do some magic… [14:50] was wondering if there was something more "out of the box" [14:51] zyga: ping me once you have build/downloaded a snapd with the right revision to reproduce the refresh hang [14:54] mvo: sure [14:55] didrocks, not right now, but it's on the roadmap [14:59] mvo: I cannot find core at revision 1968, I no longer have access to core [15:00] kyrofa: ok, so you would advise relying on `arch` right now? [15:01] didrocks, if that covers your use-case, go for it. It obviously won't solve everything [15:02] We're trying to make a generic way to specify most things using a grammar similar to the stage-packages [15:02] Lunch! [15:03] zyga: you are still listed as a collaborator [15:03] hmm [15:03] sudo snap refresh --revision=1968 core [15:03] this fails with: error: cannot refresh "core": snap not found [15:03] zyga: oh, that will not work [15:03] zyga: or maybe it should [15:03] zyga: interessting [15:03] I think it should work [15:03] it should [15:03] Chipaca: ^^ [15:03] i use that all the time [15:04] anyway, I need that coffee [15:04] brb [15:04] are you sure 1968 is the one you want ? [15:04] maybe, mvo is that the one you are on? [15:04] (i.e. is it your arch) [15:04] zyga: I'm on 1968 [15:04] zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=snapd&field.status_filter=&field.series_filter= might also be a place to look for the revno [15:04] --revision works only if you can push to the snap [15:04] oh [15:05] indeed ... and i can [15:05] (for core) [15:05] and supposedly so can I [15:05] i dont think so [15:05] * ogra_ checks [15:05] (if the dashboard ever loads ... tap ... tap ... tap) [15:05] zyga: log in [15:06] zyga: assuming you've got dev access to core, you can pull arbitrary revisions with --revision; otherwise no [15:06] ah [15:06] yeah, zyga should be able to ... [15:06] that was it [15:06] sorryt [15:06] I used sudo [15:07] it works [15:07] Hello, I'm traing to build an snap of Konsole. I followed this tutorial https://apachelog.wordpress.com/2016/12/02/snapping-kde-applications/ but I'm getting the following error "" [15:07] You need to connect this snap to the kde-frameworks-5 snap. [15:07] You can do this with those commands: [15:07] snap install kde-frameworks-5 [15:07] snap connect :kde-frameworks-5-plug kde-frameworks-5:kde-frameworks-5-slot [15:08] I already did what the instructions says without success [15:09] * zyga looks at a 48GB 24CPU box [15:10] but first, coffee [15:10] * genii sips [15:18] re [15:18] ok, back with my coffee [15:18] Chipaca, if a channel closes, is snapd not currently falling back today? [15:18] mvo: I'm on the smae revision now [15:18] kyrofa: yes, why? [15:18] kyrofa: I mean yes it is falling back [15:19] Chipaca, in a released version? [15:19] kyrofa: I don't think it's ever not fallen back [15:19] also that behavior is fully on the store side [15:20] kyrofa: you're making me nervous :-) [15:20] Chipaca, sergio is claiming it doesn't.... made ME nervous [15:21] zyga: does snap refresh --edge work for you? [15:21] fgimenez: https://travis-ci.org/snapcore/snapd/builds/237053889 seems to be failing with timeouts in lots of prepares [15:21] kyrofa: psh. What does sergiusens know [15:21] sergiusens: no seriously tell us [15:23] mvo: trying [15:23] pedronis: thx looking [15:23] mvo: yes [15:23] mvo: I'm now on 2053 [15:23] mvo: which version of the package are you on? [15:24] mvo: I suspect it worked for me because I installed locally-built package earlier [15:24] zyga: aha, you were on a non-rexec version? [15:24] mvo: possibly [15:24] zyga: snap version will know [15:24] zyga: but not anymore :) [15:24] mvo: anyway, I should reinstall snapd from the archive [15:25] ok [15:25] I'm on 2.25 [15:25] pedronis: on of the errors is super weird https://travis-ci.org/snapcore/snapd/builds/237053889#L1220 it previously checked for SNAP_REEXEC != 0 here https://travis-ci.org/snapcore/snapd/builds/237053889#L1187 [15:25] one of the errors [15:25] mvo: now to switch back core [15:25] and try [15:26] fgimenez: also one of the restore timed out, I suppose one a restore fails then we can be in really weird stats [15:26] s/one a /once a/ [15:26] mvo: reproduced! [15:26] mvo: thank you [15:27] mvo: so, quick suspicion, there was one day when snapd from core would run snap-update-ns from distro [15:27] pedronis: indeed, if they don't come alone the restore errors might be caused by something that failed before [15:27] mvo: I fixed that on monday after landing update-ns on friday [15:27] zyga: it might be that, yeah. [15:27] mvo: if this is that version then there's no bug to look for (hopefully) [15:27] zyga: this would explain the narrow set of versions we are seeing this [15:27] zyga: plus it never left edge [15:27] mvo: yes [15:28] mvo: so the snap-update-ns in core is correct (does real stuff) [15:28] mvo: but we are running the one I have in /usr/lib/snapd [15:28] from 2.25 [15:28] yes [15:28] essentially [15:28] zyga: now the question is what we do about all N people who are affected. we could simply ignore the problem [15:28] mvo: aha, good question [15:29] mvo: eventual exnial release will fix it [15:29] zyga: good point [15:29] mvo: we could do a point release [15:29] mvo: and SRU it quickly [15:29] mvo: to have update-ns just return 0 [15:29] while saying not implemented [15:30] mvo: I can prepare a debdiff if you think this is worth doing === heber_ is now known as heber [15:30] if it never left edge anyway ... why bother [15:31] zyga: probably fine to ignore for now as long as the number is very small [15:31] mvo: use repair assertion :D [15:31] zyga: soon [15:31] * zyga would love if we could try that :-) [15:31] but still chicken-and-egg [15:31] we should tell the pople with it what to do though on the forum [15:31] *people [15:31] pedronis: good point [15:31] pedronis: I think refreshing to stable [15:32] pedronis: and to edge should fix it [15:32] * zyga tries [15:32] mvo: actually, maybe universal recovery stragegy for broken edge? [15:35] no, because with patches or patch like stuff it might break as well [15:36] pedronis: interfaces-cups-control got stuck too on apt-get install (18mb) https://travis-ci.org/snapcore/snapd/builds/237053889#L6883 [15:36] pedronis: in theory yes but we stopped doing that, right? [15:36] well we stopped using patches [15:36] but we do some stuff like that in ensure [15:36] so not completely broken [15:37] but you can get interesting effects [15:37] pedronis: indeed though those are (for now) still safe [15:37] so really edge to beta or edge to candidate [15:37] might be better [15:37] than jumping all the way to stable [15:37] mvo: anyway, I think for this case refresh to core does not work [15:37] if possible [15:37] mvo: so we need to help people but we need something else [15:37] mvo: I'd suggest replacing update-ns in the package with bin/true [15:37] mvo: from there on it would work, if you want I can write a blog post [15:38] mvo: I can even make a shell script that "recovers" the system [15:45] fgimenez: I wonder, would increasing the timeout help, or do we get into stuck states somehow for which even waiting forever wouldn't help, also wonder whether we should do the reverse, see what are the usual times, and reduce the timeout, so we fail fast [15:48] mvo: let me know if you want me to do that [15:50] pedronis: yes, i don't think increasing the timeout further would help too much [15:53] pedronis: i was wondering if keeping disabled ip6 here would help https://github.com/snapcore/snapd/blob/master/spread.yaml#L258, most of these timeouts happen during downloads for installations [15:55] Chipaca, https://forum.snapcraft.io/t/channel-fallback-doesnt-change-tracked-channel/828 [15:56] kyrofa: but fallback != changing tracked [15:56] It continues tracking the closed channel? [15:56] kyrofa: the channel tracked does not change [15:56] kyrofa: correct [15:57] kyrofa: if you're tracking beta, and beta closes for a bit, you don't want to be dumped onto stable indefinitely [15:57] Chipaca, huh... seems unintuitive for branches though [15:58] Chipaca, I mean, that revision that I just refreshed to did _not_ come from stable/junk. I never released it there [15:59] kyrofa: maybe snap info could say something like "tracking: foo/stable/hotfix (from foo/stable)? Although I don't know how we'd get that info [15:59] s/\)\?/)"?/ [16:00] Yeah... it's just not stating the truth there :P [16:01] kyrofa: it is stating the truth [16:01] kyrofa: you're misunderstanding the truth that it's stating [16:01] alternative facts! [16:01]