[02:16] PR snapd#3403 opened: Sync packaging from Fedora Dist-Git [02:38] Bug #1693664 opened: Snapd won't install anbox, Character error === chihchun_afk is now known as chihchun [08:17] mo'in peeps [08:18] I've got a meeting at the boys' school today so I'll be gone for a chunk of the morning, starting in about 15 minutes [08:18] shout if you need me for something before i'm gone [08:22] Chipaca: hi, I'll look at your branches [08:22] pedronis: appreciated as always [08:23] pedronis: one of them went up in the middle of a store outage yesterday, so everything was red. I redid travis, but the others i'd have to repush if needed [08:40] ok, i'm off, will bbl (nominally in 2h) [09:04] hi pedronis, we are still getting crete-key timeouts on ubuntu-16.04-32 (haven't seen it failing on other systems) https://travis-ci.org/snapcore/spread-cron/builds/236217996#L1960 [09:04] in the same run https://travis-ci.org/snapcore/spread-cron/builds/236217996#L1960, also -32 [09:13] fgimenez: not sure why, otoh it would be ok to run those test only on classic amd64 [09:16] pedronis: ok, should we wait for more errors to make sure it only timeouts on i386? if not i can propose a PR for disabling them now [09:17] fgimenez: let's wait a bit more [09:17] pedronis: ok thx [09:55] hmm i'm getting '- Run configure hook of "core" snap (run hook "configure": 2017/05/26 11:13:09.680326 cmd.go:93: DEBUG: core snap (at "/snap/core/current") is older ("2.26.3+git212.34125a5~ubuntu16.04.1") than distribution package ("1337.2.26.3"))' locally with one of the spread tests; is this something to be worried about or a problem with my local env? [09:58] pstolowski: it means what you have outside is older than what you have inside, but I cannot read that message, is it failing or just a debug message [09:59] pedronis, failing [09:59] pstolowski: anyway it's failign for other reasons that you don't see [09:59] that bit is just debugging [10:00] afaict [10:01] something weird with versions - i think this starts failing at: [10:01] Setting up snapd (1337.2.26.3) ... [10:01] + MATCH unknown [10:01] + snap --version [10:01] error: pattern not found, got: [10:01] snap 1337.2.26.3 [10:01] snapd 1337.2.26.3 [10:01] series 16 [10:01] ubuntu 16.04 [10:01] kernel 4.4.0-78-generic [10:01] + MATCH unknown [10:01] + /usr/lib/snapd/snap-confine --version [10:01] error: pattern not found, got: [10:01] snap-confine 1337.2.26.3 [10:03] pstolowski: were is match unknown coming from [10:04] I see only one very early in prepare.sh [10:04] that should kill the whole run [10:11] pedronis, the spread test i'm running is not doing that explicitely, so must be part of some general preparations [10:11] maybe building is failing [10:13] pstolowski: pedronis i've seen that "MATCH unknown -> pattern not found" previously, it is expected to fail if i read correctly https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L96, probably the error is somewhere else [10:13] yes, it should day saying that something is weird [10:13] with the built snapd [10:15] s/day/die/ [10:15] * pedronis lunch [10:17] i'm trying on linode now [10:17] but not sure if that's relevant at all [10:39] hmm same error on linode [10:41] pstolowski: do you have a complete error log? [10:43] fgimenez, http://pastebin.ubuntu.com/24665653/ [10:46] pstolowski: if the problem is not related to yur branch it should be easy to reproduce, trying that now [11:17] fgimenez, this is failing on a new spread test I added in my branch. but I see no direct relation to my test yet, it's just installing a test snap as any other test, and modifies its config [11:24] pstolowski: something seems to be making the prepare step to fail, i can't reproduce locally, also fwiw the automated execution after the new core was published to edge this morning was good, i've retriggered it and has already passed successfully the prepare stage https://travis-ci.org/snapcore/spread-cron/builds/236247437 (this executes from master) [11:34] * Chipaca returns from the dead [11:34] see, even when i pad these things out i fail to account for the time it takes :-( [11:34] pedronis: thank you for the reviews! I'll get on them in a bit [11:35] abeato, oh ... one other thing about the androidboot support, why /writable/androidboot ... i thought we agreed to have an actual /boot/androidboot/ partition available ? [11:36] abeato, you could use that directgly [11:37] pstolowski: mmm i'm getting a different error locally from master http://paste.ubuntu.com/24665927/ === chihchun is now known as chihchun_afk [12:10] ogra_, using the current userdata partition makes our life easier, and I do not see any advantage in using a separate partition that might not be always available [12:11] ogra_, we can be flexible though and contemplate both cases [12:11] abeato, well, it will require changes to snapd i guess ... since it looks at /boot/ (i think ... perhaps i'm wrong though) [12:12] to decide what way of mangling it needs to use for the cdmline on updates [12:12] ogra_, no, no need for changes to snapd, it is transparent for it, so in fact the decision depends on system specific parts [12:12] i'm really not sure this is still the case ... but in the past it looked for the mounted /boot partition to detect the right bootloader path [12:13] ok, then we're fine i guess [12:13] ogra_, it just searches for files in /boot/xxx [12:13] ok [12:21] pstolowski: looks like i had some leftover files that were making the build to fail, this is from a clean master http://paste.ubuntu.com/24666236/ all seems to be fine [12:50] fgimenez, thanks for checking [12:58] Hellos [13:01] Chipaca, fgimenez, pstolowski: Stand up? [13:01] niemeyer: omw [13:02] niemeyer: omw indeed [13:14] PR snapd#3402 closed: many: error types should be called FooError, not ErrFoo [13:22] ogra_, something else that I'd like to do is to add a modified klicb package in snappy PPA with https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+attachment/4881283/+files/add-reboot-argument-support.patch [13:22] Bug #1692494: klibc does not support reboot arguments [13:22] ogra_, even if we land in arty we still need that [13:22] abeato, did you talk to upstream yet [13:23] (infinity ... ) [13:23] ogra_, nope, where does he hang around? [13:24] * abeato tries ubuntu-desktop [13:24] abeato, #ubunru-devel [13:24] *ubuntu [13:25] ok [13:25] (he's foundations ... really not a desktop guy :) ) [13:26] if we could SRU it right away we'd not need the PPA ... i woudl prefer that [13:35] niemeyer: snapd#3350 , not blocking my current work but would be good to have some feedback, it was planned for the next release [13:35] PR snapd#3350: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots [13:35] pedronis: +1 [13:42] anyone able to merge snapd#3403? [13:42] PR snapd#3403: packaging/fedora: sync packaging from Fedora Dist-Git [13:42] the stupid failure is just Linode being awful [13:47] Son_Goku: I've restarted the integration tests [13:48] niemeyer: I'd hope they pass, since it's all dead code to Travis [13:48] we don't have any Fedora CI yet [13:48] Son_Goku: I always hope they pass as well [13:53] fgimenez: Small comment in #3401 [13:53] snapd#3401 [13:53] PR snapd#3401: tests: move static and unit tests to spread task [13:54] niemeyer: thx on it [13:54] fgimenez: Let's please fix on a follow up.. this is taking 6 minutes out of everything else [13:54] PR snapd#3401 closed: tests: move static and unit tests to spread task [13:55] niemeyer: sure, i'll prepare it [13:57] kalikiana, you are currently working on the cross stuff iirc ... do you know if there is already a way to use arch specific tags in "build-packages:" in snapcraft.yaml ? (i.e. i want to make gadgets build uboot from source, if i build it on an amd64 system i need gcc-arm-linux-gnueabi installed, on native builds i dont) [13:58] (i cant find anything in the docs about that) [14:00] fgimenez: Thank you! [14:04] ogra_: that should iirc work, but for it to work automatically in launchpad there's this https://github.com/snapcore/snapcraft/pull/1253 [14:04] PR snapcraft#1253: go plugin: cross-compilation support [14:04] specifically https://github.com/snapcore/snapcraft/pull/1253/files#diff-e405f18ae8c707ccb3d5ea4e828718c9R202 [14:06] * ogra_ checks (we can move to rocket, i just asked there btw) [14:07] ogra_: don't multi post :-P [14:07] :P [14:07] niemeyer: can I have uour thoughts on https://forum.snapcraft.io/t/version-script-helpers/648?u=sergiusens ? [14:08] sergiusens, hmm, not really what i want ... that only reacts to --target-arch [14:09] sergiusens: Sure, just let me finish a review and will be there [14:13] thanks, shouldn't take much of your time, but mostly to make sure I captured your suggestion correctly [14:34] PR snapd#3403 closed: packaging/fedora: sync packaging from Fedora Dist-Git [14:43] cachio_: Reviewed the spread PR.. it's looking pretty good, thanks. Just a few details and should be mergeable. [14:44] niemeyer, sure [14:49] sergiusens: Replied, thanks for poking [14:50] pedronis: is there any case where a snap can have a local revision but also a snapid? [14:51] snap download ... then you sideload ? [14:51] ogra_: you get the revision from the assert [14:51] ah [14:52] Chipaca: well, a snap can have a revision (as in SideInfo) with a snap id and some without, a revision with both would be an incosistent state though [14:52] Chipaca, well, do i get the assert if i sideload (and dont snap ack it) [14:53] ogra_: if you don't have the assert, you don't get the snap id [14:53] ok [14:53] Chipaca: just pointing out it's a per revision/SideInfo property, is not global [14:53] but i don't know what happens if you mix n match; going to try that now [14:53] pedronis: right, but they're at the same level [14:54] they're both in the sequence, not in the snap [14:54] yes [14:54] each one should be consistent, if you manage to have both it's a bug [14:54] pedronis: basically i'm wondering about this bit of code that sets revision to 0 before checking snapid [14:54] Chipaca: where? [14:55] pedronis: in master i think this is store.ListRefresh [14:55] store? [14:56] or snapstate? [14:56] pedronis: store/store.go [14:56] that's where ListRefresh lives [14:56] well, the we check SnapID a line below [14:57] I think that code is a bit non-sense [14:57] it's not there like that to deal with a real case [14:57] pedronis: maybe i should change it to do the same thing in both cases [14:57] while i'm here [14:58] just continue [14:58] works for me [14:58] that is, if !revision.Store() || snapID == "" [14:58] you could log in one [14:58] of the two [14:58] anyway [14:58] “found a snap with rev<0 and snapID != ""! get out the champagne!” [14:58] :-p [14:59] pedronis: thank you [14:59] Chipaca: fwiw I think it's from before we fully understood things [14:59] yeah... before... [14:59] because now we totally understand things, yes? [15:00] Chipaca: we have a way to install a local unasserted revison on top of a store one, I don't think we have a way to do the reverse though [15:00] snap refresh foo will hit that code [15:01] Chipaca: I didn't tell you what "things" are [15:01] :) [15:01] pedronis: right, but it doesn't matter if a previous revision had a revision and a snapid; it's only current that matters [15:01] exactly [15:02] that's why we don't have a way to do that [15:02] you need to snap remove --revision yourself out of that corner [15:02] I think right now [15:02] assuming revision there works with local ones [15:02] (I don't know if we test for that) [15:08] pedronis: would panicing be appropriate in those cases? [15:08] no [15:08] panicing is if the non-sense is so big that we cannot really go forward [15:08] here we can ignore it [15:08] not great [15:09] but also no dead snapd trying to refresh either [15:12] Chipaca: there's no panic in store atm, except in init() [15:14] Chipaca: I think most our panics are either lock related, some early initialisation or early order of ops, or related to marshaling/unmarshaling from state [15:16] or wrong types being passed around [15:16] (the latter is something our tests should catch) [15:30] hah! just realised [15:31] this test class is still called "UbuntuStoreRepository" :-D [15:33] Chipaca: yes, the tests are still using old names sometimes, I would do a separate PR to fix that though [15:34] aww [15:34] alright [15:34] Chipaca: search and replace together with real change don't mix well [15:35] pedronis: you are absolutely correct === chihchun_afk is now known as chihchun [16:19] reworking the retry code I noticed that indeed we don't retry DNS errors === chihchun is now known as chihchun_afk [16:55] cachio_: Another pass on the spread PR, and then it GLTM [16:55] LGTM even [16:55] pedronis: Nice, glad that one is simple to fix.. I was afraid it might be something more involved [16:55] Good-lookin? [16:58] kyrofa: GLTM! ;) [17:49] niemeyer: well, it might be complicated, for now I find the point where to log them, we might need to look at some examples from spread test run to decide what to do [17:49] s/I find/I found/ [17:50] Anyone here know anything about squashfuse? [17:50] pedronis: That sounds very close to what cachio_ is working on already.. one of the errors there was precisely a DNS error [17:51] Maybe I should go to the lxc channel [17:53] niemeyer: I mean examples once we have the log with the exact internal error [17:53] niemeyer: there's a bit of a russian dolls of errors going on (like for connreset) [17:54] pedronis: Yeah, DNS should be easy to reproduce locally [17:54] cachio_: ^ [17:54] cachio_: Spread PR is in [17:55] (second point unrelated to first point, sorry for confusing points :)) [18:26] I'm taking a break [18:29] i'm taking a beer [18:29] ¯\_(ツ)_/¯🍺 [18:30] Chipaca: Sounds like a much better idea [18:30] niemeyer: it's 1930 here so it's allowed [18:32] Chipaca: I should try.. the reviews might become much more colorful [18:33] Anyway, biab [18:33] niemeyer: no reviews after beer [18:33] or during, for that matter === Sir_Gallantmon is now known as Son_Goku [19:57] niemeyer, how do you usually connect to linode to see tho nodes that are running and their info? [19:57] niemeyer, do you use user/pass in the web page? [19:58] cachio_: Yes, to maintain the provide maintenance when necessary I use the administration panel.. when using spread, I don't do that though [19:58] niemeyer, because I need a way to monitor nodes, I am trying to reproduce the reboot timeout issue [19:59] niemeyer, do you have credentials to share with me? [19:59] cachio_: You can just try to connect to them/ping as usual.. is this not working? [19:59] cachio_: I don't at this time [20:00] cachio_: What happens when you connect to the machine? [20:00] niemeyer, I couldn't repproduce the issue yet [20:00] niemeyer, I created a specific test for that and I am gonna run it now [20:01] cachio_: Okay, so to get started I suggest opening a terminal to the machine [20:01] cachio_: The web interface won't be doing much better than that [20:01] niemeyer, [20:01] ok [20:01] cachio_: Then monitor if the machine is rebooting at all, or if it's stuck [20:02] cachio_: If it gets stuck at a point where there's no network, then please ping me and I'll try to see via the console [20:02] ok [20:03] niemeyer, apart of this one, I want to raise an issue for the econnreset test [20:03] niemeyer, should I create a forum topic? or go to launchpad? [20:06] cachio_: Depends a bit on the content/context.. you already have two topics on the forum for "chasing unreliable tests" and "dealing with flaky tests".. perhaps one of these is a good starting point? [20:07] niemeyer, ok [20:59] niemeyer: is there a way I can bring up a bug (fixed by SRU in ubuntu classic) to attention for ubuntu-core? it would require an update of the core snap [20:59] https://bugs.launchpad.net/netplan/+bug/1672740 [20:59] Bug #1672740: Netplan replug function is incompatible with ath9k_htc module [21:04] cyphermox: Device category in the forum might be a good place [21:04] there's already a bug in launchpad, isn't there a real bug tracker? [21:15] cyphermox: Sorry, I'm not sure of what you're actually looking for.. Launchpad is a real bug tracker.. the forum is a good place to talk. What are you looking for? [21:15] reporting the bug to you. [21:15] there is a bug in launchpad already, that affects ubuntu classic; it also needs an update of the core snap [21:16] also-effects snappy? [21:18] it's the snappy project? I wasn't sure as there's also "ubuntu-core". [21:20] cyphermox, haha, I'm not familiar with that one. I typically use snapd for snapd-specific things (interfaces, etc.), and snappy for larger system things (e.g. core snap, image issues) [21:20] (but just because that's what I do doesn't mean it's the right thing, either) [21:21] cyphermox, note that the core snap is also used on classic, so another vote for snappy over ubuntu-core [21:27] hello, does anyone know if there is an nginx snap available ? [21:28] daker, not standalone that I know of, no. Typically it's bundled [21:28] kyrofa: do you have a .snapcraft of it ? [21:28] daker, all I've got myself is apache [21:29] kyrofa: hmm, ok thanks [21:57] o/ [21:57] any news on the error spike?