[01:58] cachio_afk: Yeah, definitely.. if it's properly designed I'd be happy to include it [03:11] niemeyer, ok, I'll push it on friday, tomorrow is national holidays in argentina === cachio_afk is now known as cachio [05:35] PR snapcraft#1334 opened: tests: use the fake apt cache in deb unit tests [06:01] Bug #1693423 opened: initramfs error while loading Custom ubuntu core Image on X86 but it works fine in KVM [07:11] good morning! [07:53] hello :) [07:53] * zyga is on his way to the airport [07:59] morning peeps [08:00] PR core-build#13 opened: Androidboot support [08:12] Chipaca: hey, good morning [08:12] I was wondering if anyone is working today, lots of folks have a day off [08:23] * zyga goes offline to conserve battery, ttyl [08:29] zyga: hi, I woild be off, but I'm swapping with Monday [08:30] instead, so I'm working today [08:52] Chipaca: hi, I re-nitpicked a tiny bit, otoh I maybe confused [08:54] pedronis: nicht genitpicken! [09:01] pedronis: better now? [09:02] PR snapd#3401 opened: tests: move static and unit tests to spread task [09:04] is there any way to list all available architectures & versions from the CLI? https://forum.snapcraft.io/t/list-available-architectures-versions-through-the-cli/782 [09:07] nottrobin: from snapcraft? [09:07] ah, forum post [09:07] answering there [09:10] Chipaca: thank you, +1ed [09:13] nottrobin: there you go [09:21] so sometimes some prepare project takes 300+ s , sometimes it timeouts taking 20mins [09:26] yeap [09:27] I'd say we bump that timeout, but given that travis itself times out at ~50, it'd be making things worse [09:27] do we know which bit goes into taking 20+ minutes ? [09:27] it seems we don't have inner timestamps [09:27] so hard to tell [09:27] I myself do not [09:27] I wish spread split the project prepare out [09:27] somehow (*handwaves*) [09:27] so it can be done async ahead of time [09:28] like, have a pool of these things pre-prepared [09:28] but that's probably very hard :-) [09:38] Hello! [09:39] Just spent the last 1.5h reviewing the general snapctl PR.. but will try to get some more sleep while I can! :) [09:39] See you soon. [09:43] ouch [09:46] pedronis, hey, mind removing the "Blocked" label from https://github.com/snapcore/snapd/pull/3353 ? [09:46] PR snapd#3353: Add support for reboot parameter [09:47] abeato: done [09:48] pedronis, thanks [09:49] it looks like CI is failing btw, it gives me those ssh timeouts error all the time [09:51] ogra_: i think you're off cavorting today, but if you happen to not be, https://askubuntu.com/questions/867121/snappy-ubuntu-core-64-bit could use a more authoritative answer i think [09:51] heh, should've linked https://askubuntu.com/q/867121/711 to get brownie points [09:51] ¯\_(ツ)_/¯ [09:55] PR snapd#3363 closed: cmd: test everything (100% coverage \o/) [10:01] cool [10:04] Chipaca: have you seen an error about linode:debian-unstable-64:tests/main/snapd-reexec ? [10:04] I don't think I have [10:05] ah [10:05] it seems you changed in your branch [10:08] let's see if merging master helps [10:23] PR snapd#3400 opened: many: stop "snap refresh $x --channel invalid" from working [10:47] ogra_ ping [10:55] ondra: holiday in the germanies [10:56] Chipaca aha, ,makes sense as I can't see any of them online :) [10:56] slowly we might be learning to take time off, at least in small chunks [11:07] * Chipaca curses at spread tests in the abstract [11:08] PR snapd#3374 closed: partition: add directory sync to the save uboot.env file code [11:26] Chipaca: because they fail with abandon? or something else [11:26] pedronis: because I can't just write a handwavy thing and have them dtrt :-) [11:26] ah [11:50] o/ [11:51] Chipaca: how's the day? [11:51] zyga: not bad! how's yours? [11:52] Chipaca: the joys of travel from A to B [11:52] Chipaca: I have an hour till boarding, time to do some work for a change [11:53] speaking of work [11:53] i'm going to go make myself some lunch [11:54] enjoy :) === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:22] * zyga boards the plane [13:27] fgimenez: if you look at https://codecov.io/bash [13:28] niemeyer: snapd#3385 [13:28] PR snapd#3385: cmd: add stub new snap-repair command and add timer [13:28] fgimenez: there's a check that looks like if [ "$CI" = "true" ] && [ "$TRAVIS" = "true" ] && [ "$SHIPPABLE" != "true" ] [13:28] Chipaca: yeap and on it right now, searching for "TRAVIS_" :) [13:28] pedronis: Cheers [13:28] fgimenez: and inside that it uses a bunch of TRAVIS_ vars [13:28] yeah [13:28] Chipaca: yep, thx [13:32] pstolowski: btw we can already see the problem we mentioned: func (iface *serialPortInterface) AppArmorConnectedPlug, it gets a slotAttrs but inside is using slot.Attrs [13:32] for example [13:33] pedronis, every interface has this problem right now, because we only added placeholders in the API [13:33] :( [13:34] that's a bit of a bad idea [13:34] when do we plan to fix these ? [13:34] pedronis, these plug/slotAttrs are not even filled in right now [13:34] yea, anyway we really to rethink when we pass Plug/Slot to interfaces [13:35] or maybe rename Plug/Slot.Attrs to StaticAttrs and go from there or something === chihchun is now known as chihchun_afk [13:39] pedronis, I intended to re-factor all interfaces to use plugAttrs and slotAttrs after the current branch lands, but if we agree on changing all these methods to drop plug and slot, then I will do it first as a prerequisite for current PR [13:40] well before dropping we need to understand how they use those, best would be to drop them and pass something else, second best is to at least rename Attrs on Plug and Slot [13:43] pstolowski: I'm also not sure how we use the *Permant* variants, are those called once? [13:43] pedronis: Reviewed [13:44] pedronis: spread tests passed on snapd#3400 fwiw [13:44] PR snapd#3400: many: stop "snap refresh $x --channel invalid" from working [13:44] pedronis, what do you mean with 'are those called once' ? [13:47] pstolowski: I mean they can also use the static attributes it seems [13:47] given they take only Plug and Slot [13:48] or maybe they should use no attributes at all? [13:53] pedronis, I think it's ok for them to use static attributes from the yaml [13:53] but now we say that we can overwrite them [13:53] what does that even mean then [13:54] the pieces still don't feel like they are clicking together right [13:59] pstolowski: anyway some permanent stuff is indeed using attrs, so I wonder what that means to the idea that hooks can override everything [14:00] pedronis, the Permanent* methods see whatever Sanitize* set. but on Connect hooks will be free to overwrite attributes and this will be visible to "connected" snippets. [14:00] pstolowski: yes, but that doesn't make a lot of sense for stuff that the Permanent* bits used/assumed [14:01] pedronis, indeed, i hear you [14:01] unless we use validate somehow to check per interfaces that stuff that was used by permanent is overriden [14:01] s/is/is not/ [14:02] sounds complex [14:02] well something is off here [14:03] jdstrand, i'd appreciate a manual approval of https://dashboard.snapcraft.io/dev/snaps/7691/rev/2/ [14:03] pstolowski: maybe getting back to no overriding but solving the defaults problem differently might be better [14:03] heh, I was just going through store reviews now :) [14:03] pedronis, i was going to say that.. perhaps the idea of protecting attributes coming from yaml made sense [14:03] hah, snap* :) [14:05] pstolowski: at least for a first iteration, we can relax later, but right now it feels a bit like boiling too much ocean in one go [14:05] otherwise [14:06] pedronis, why don't we leave the problem of defaults to interfaces code? I mean, what's stopping interface code from having a "default-foo" attribute, and then using it as 'foo' if foo wasn't set at runtime? [14:06] ogra_: done [14:06] * ogra_ hugs jdstrand [14:06] * ogra_ goes back on vacation :) [14:06] * jdstrand hugs ogra_ back [14:06] ogra_: enjoy your holiday :) [14:07] pstolowski: we need the defaults in the attributes before we run the policy checks [14:07] that's what's about mainly [14:08] i see [14:18] pstolowski: the simplest thing I could think of, is we don't let override in general, but the interface can have an optional method to return a list of attrs that can be overridden (usually they will be ones with defaults that is ok to change later) [14:18] as far as I know right now we have one interface with this need [14:18] content [14:21] * pedronis break [14:27] If I install a snap from a file, do they ever subsequently get updated from the store? [14:27] or are they stuck at what I installed with? [14:31] ryebot: just the .snap without accompanying assertions (as one can get with snap download) will be stuck [14:31] pedronis: that's perfect [14:32] ryebot: I fear that sort of reaction, it also completely unchecked [14:32] haha ;) [14:35] ryebot: it's also how you build next year's botnet [14:35] * ryebot learns how to mine btc [15:01] niemeyer, +1 for SNAP_COOKIE and cookie; [15:02] niemeyer, then /var/lib/snapd/cookie/ in the fs? (singular 'cookie', not plural) [15:02] pstolowski: Yeah, that sounds good I think [15:04] niemeyer, ok, will change, thanks! === chihchun_afk is now known as chihchun [15:51] Chipaca: is it possible that I have a version too old of shellcheck? [15:51] pedronis: maybe? why? [15:51] I'm getting [15:51] # shellcheck source=tests/lib/dirs.sh [15:51] ^-- SC1073: Couldn't parse this shellcheck annotation. [15:51] pedronis: it's also possible it's too new :-) [15:51] hrmm [15:51] hadn't seen that one [15:52] pedronis: in travis, or locally? [15:52] locally [15:52] and if you're getting this, does this mean travis doesn't actually _have_ shellcheck :-) [15:52] possibly [15:52] pedronis: what version of shellcheck do you have? [15:52] 0.3.7 [15:54] ah, i bumped mine to 0.4.4-2 to check some things mvo spotted [15:54] pedronis: http://mirrors.kernel.org/ubuntu/pool/universe/s/shellcheck/shellcheck_0.4.4-2_amd64.deb [15:54] pedronis: that one should work just fine [15:55] I suppoe travis / spread is not running it at all [15:55] 0.4.4-4 uses a newer ghc and needs a rebuild to work properly though, so avoid it (or rebuild it … but that needs a newer ghc … fun all around [15:55] spread almost certainly not, given this [15:55] sadface [15:55] well, it's optional, not sure why you though it should be there ? [15:56] pedronis: you assume i thought [15:57] PR snapd#3402 opened: many: error types should be called FooError, not ErrFoo [16:02] Chipaca: yes, that one from kernel.org works [16:02] pedronis: it's from yakkety [16:02] https://packages.ubuntu.com/yakkety/amd64/shellcheck/download [16:02] just thought i'd save you a click [16:10] Chipaca: I'll look at your refresh branch tomorrow at this point [16:10] pedronis: fair enough [16:23] Chipaca: hey [16:23] Chipaca: do you have a moment? [16:24] Chipaca: can you please refresh my memory on channels and tracks, [16:24] Chipaca: is it a tuple like (2.x/stable) or am I missing something? [16:25] Chipaca: and what are the precise terms (stability levels, risk levels, etc) [16:25] zyga: every channel has four risk levels [16:25] zyga: the default channel is called latest [16:26] wait [16:26] no, tracks [16:26] gah [16:26] man it's a bad day for this [16:26] haha [16:26] zyga: s/channel/track/ in the above :-) [16:26] should I use the word channel or track to describe the concept? [16:26] zyga: channels come in four risk levels [16:27] ah, you mean in an intro to somebody who's never seen it before sense? [16:27] yes [16:27] start with channels as risk levels [16:27] * zyga makes some slides [16:27] Chipaca: are those tuples? [16:27] Chipaca: can I say (risk-level, channel) ? [16:27] no, just stable/candidate/potato/edge [16:28] I mean, growing the concept didactically in the same way it grew historically works [16:28] talk about channel and risk, and then take a step back and introduce tracks [16:28] ok, can you give me four examples in growing measure of complexity? [16:29] zyga: hypothetical, or actual? [16:29] Chipaca: educational :) [16:30] I bet I will learn as much as my audience now [16:31] zyga: as a first step, you could have a snap that is very low maintenance, that's not seeing active development [16:31] zyga: so all you have is the snap in stable; everybody gets that [16:32] zyga: a good example might be "hello-world", if we can convince mvo to close the spurious channels [16:32] (we've got the same revno in everything) [16:32] haha :) [16:33] zyga: as a next step, you have something in active development, where there is a snap pushed into 'edge' for testing, and it moves through the channels [16:33] fgimenez: are you a collaborator in hello-world? [16:34] zyga: an example of this would be the core snap, for example [16:34] zyga: 'snap info' shows you the progression nicely (when we haven't messed up) [16:35] Chipaca: nope sorry [16:35] zyga: there you can stop and wave your hands and introduce the idea of people doing this kind of qa for stable at the same time as working on the upcoming release [16:35] zyga: or people having LTS as well as current releases [16:36] zyga: and ask how they'd address this [16:37] * zyga hears everyone chanting "PPAs" [16:39] zyga: so you then show them the mysql snap [16:39] (snap info mysql) [16:39] ooooh [16:39] * zyga loves that [16:40] including the funky unicode arrow :) [16:40] thanks! [16:40] zyga: and then you talk about doing CI/CD [16:40] zyga: and show them snap info etcd [16:40] zyga: (note the 'ingest' track) [16:41] what is ingest? [16:41] the burningest of burning edges [16:41] * zyga is so glad he asked [16:41] sounds like a title of a garbage album :) [16:41] "the burinest of the burn, the edgiest of the edge" (to queer music theme) === chihchun is now known as chihchun_afk [16:41] thanks [16:42] zyga: actually i think the ingest track there is old (note the revno) [16:42] * zyga wonders why in 2017 dragging a slide to another position freezes the office suite for 30 seconds [16:43] Chipaca: yes, looks like "gimme tasty but as safe as it gets" [16:43] anyway, I get the concept [16:43] it's whatever people want [16:43] every project gets to define what they mean, yes [16:44] although, AIUI, tracks are manual, and I think we ask for semantic versioning or sth like that? noise][ might know more [16:44] aha [16:44] noise][: ^^ do we have semantic versioning in track names? [16:45] zyga: https://forum.snapcraft.io/t/channel-terminology-and-policy/551 [16:45] oh, great [16:45] you have some leeway, but that's the general guidance on policy [16:46] libreoffice, why is it hard to remove a slide... why do you suck watts doing so... [16:47] Chipaca: suggestion, snap known should complete on assertion types [16:47] would help in discoverability [16:49] we don't have a forum topic that discusses assertion types (an overview of each) do we? [16:52] zyga: ooh, look at that, nicely documented instead of asking me :-) [16:55] zyga: I do plan to move over and improve the assertion bits from the wiki to the forum in the next weeks [16:57] pedronis: he's dead jim [16:58] ah [16:58] reached out on telegram but he might not be there either :-) === genii is now known as JuanValdez === JuanValdez is now known as genii [17:01] anyway. EOD for me. [19:27] roadmr: hey, at your convenience can you pull r881 of the review tools? [19:27] jdstrand: sure! as it happens it's super convenient right now, should have that rolled out early next week [19:28] roadmr: awesome, thanks! [19:29] roadmr: actually, gimme a sec. since we're doing this, let me update for the new interfaces [19:30] jdstrand: hehe I have a script now which prepares the merge request for me and pushes the changes ready to merge-request. It even runs the tools against a small snap to ensure they are sane [19:30] jdstrand: (remember that time a file was missing and they didn't even run?) [19:30] jdstrand: and oh sure, let me know and I'll send another merge [19:31] roadmr: I do remember that time, and I have my own battery of test snaps [19:31] roadmr: nice! [19:32] jdstrand: heh :) yes, mine is just a thin layer of protection. e.g. you could make the tools just return PASS all the time and I'd never notice ;) [19:51] jdstrand: 882 or should I wait for more? [19:56] roadmr: that is the one, but I wanted to check the review-tools snap with that. just waiting for it to publish [19:57] jdstrand: oh ok no rush :) [19:57] * jdstrand kicks off the test [19:57] zyhey, fyi, https://forum.snapcraft.io/t/test-failures-with-cannot-create-lock-directory-run-snapd-lock/390/3 [19:58] meh [19:58] roadmr: ok, yes, r882 [19:59] jdstrand: here I go === JanC_ is now known as JanC [22:54] PR snapcraft#1335 opened: errors: Descriptive error message for bad parts named with uppercase …