[00:16] zyga: https://youtu.be/UOZXERFHsW4?t=58m26s [00:18] https://youtu.be/UOZXERFHsW4?t=1h1m32s [00:19] niemeyer: nice mention by mattdm about our snap work in an interview about fedora ^ [00:48] Doctor_Nick: at the very end of it, you can opt-in to have that in the snap [00:49] sergiusens: ah hah [00:49] there's an env var to allow it all the way through [00:49] so it's not really required for the build? [00:50] it's not used in staging, priming, etc.? [00:51] Doctor_Nick: no, we annotate it regardless, on the step it is done on, but it should not affect following steps (unless, there is always an unless, changes in the previous step, force a rerun marking the following ones dirty) [00:51] Doctor_Nick: also https://snapcraft.io/blog/introducing-developer-notifications-for-snap-security-updates [00:52] ok [01:22] is there a way to set network restrictions like "only accept connections from localhost" in the snapcraft.yaml or does that have to be done elsewhere? [01:48] also, why do snap daemons run as root? [03:37] zyga, snapd 2.35 has been pushed for f27 too [04:21] Good morning [04:21] Thank you Neal [04:31] zyga, we got some nice mentions in mattdm's recent interview on Destination Linux [04:31] you should watch it ;) [04:49] I will, thank you for the tip :-) [04:59] PR snapd#5774 closed: tests: introduce a helper for installing local snaps with --name [05:06] morning [05:46] good morning (again) [05:46] both kids in school [05:46] time to work :) [05:47] good morning mvo :) [05:50] hey zyga [05:50] zyga: mvo: hey [05:50] mborzecki: good morning [06:00] PR snapd#5775 closed: tests: also run unit/gccgo in 18.04 [06:38] hm,hm, on arch the interfaces-timerserver-control test is failing for me:https://api.travis-ci.org/v3/job/425119844/log.txt [06:42] looking [06:44] mvo: does it reproduce always? maybe it's some temporary hiccup with ntp? [06:45] mborzecki: I saw it two times lets see if it happens again [06:47] can i install ubuntu core on esp8266 [06:47] ? [06:48] hey s10gopal, we haven't heard about anyone attempting that yet [06:49] s10gopal: you'd have to have a relatively modern linux kernel and supported boot loader [06:49] s10gopal: in addition you'd have to have golang support, I don't know if esp8266 has an arm core or if it is a separate architecture [06:50] let us know what you learn [06:52] zyga, thanks [07:01] s10gopal: esp8622 is a microcontroller with wifi, there are smaller OSes you can use there (or just go bare metal) but linux is a no go [07:02] s10gopal: you can try pi zero or CHIP board which are slightly larger form factor, have wifi and bt and run on linux, i don't know about ubuntu core on these though, maybe needs some research [07:05] pi zero not yet :/ [07:05] mvo: indeed [07:07] pstolowski|afk: hey, when you are around, could you quickly check the ifstate part of #5767? it is not used currently but given that there are some PRs in flight maybe it was added to accommodate those? [07:07] PR #5767: many: remove deadcode === pstolowski|afk is now known as pstolowski [07:09] mornings [07:09] mvo: looking [07:10] pstolowski: thanks and good morning [07:11] mvo: hi, I think I removed the need for that funciton when I refactored conflict code and made it more blunt/conservative, but I forgot to remove it [07:13] pedronis: aha, no worries [07:13] pedronis: just wanted to double check because of the things in flight. thanks for confirming [07:14] mvo: +1, it's fine to remove it [07:14] ta [07:15] and both pedronis and me claim forgetting to remove it ;) [07:15] heh [07:15] PR snapd#5767 closed: many: remove deadcode [07:16] :) [07:25] * pedronis is going to do reviewing this morning [07:30] brb [07:30] more coffee [07:34] coffee, brilliant idea [07:41] PR snapd#5778 opened: snap-update-ns: remove deadcode [07:42] zyga: ^- this one is for you, not sure if this is ok or goes to far but tests will tell (or maybe you need it for something else later?) [07:48] looking, thank you! [07:48] mvo: we need all of those [07:48] they are used in the trespassing fix PR already [07:48] (they were added as a part of -v1 review [07:49] the comments are +1 but the removals are not needed [07:49] mvo: https://github.com/snapcore/snapd/pull/5760 [07:49] PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places [07:49] zyga: aha, cool. I close it then [07:49] thanks, I'll steal the comments though :) [07:50] zyga: yeah, iirc they are a commit that can even be cherry picked [07:50] yeah [07:50] 91e746fc0d61c8e89b9c4931f3eee39bef6e9ef3 [07:50] doing that now :) [07:50] zyga: thank you [07:50] thank You :) [07:50] PR snapd#5778 closed: snap-update-ns: remove deadcode [07:51] mvo: is there any dead code in interfaces? [07:51] zyga: chopTree [07:51] aha [07:51] zyga: thats the only bit [07:51] that _may_ become unused [07:51] it's part of another fix [07:51] but I may end up not needing it [07:51] thanks! [07:52] zyga: ok, I will leave it alone [07:52] I'll remove it if that is the case [07:52] zyga: deadcode is not super reliable, it does not deal well with import "C" for example so I don't think we can automate it yet [07:52] zyga: sounds good, thank you [07:54] mvo: https://github.com/snapcore/snapd/pull/5779 [07:54] PR #5779: snap-update-ns: add comments about the "deadcode" in bootstrap.go [07:54] PR snapd#5779 opened: snap-update-ns: add comments about the "deadcode" in bootstrap.go [07:55] oh, mup is back :) [07:58] mborzecki: https://github.com/snapcore/snapd/pull/5780 [07:58] PR #5780: testutil: allow Fstatfs results to vary over time [07:58] mborzecki: I spotted one issue with locks in #5758, I suppose because you went back and forth about where/how much to lock, anyway probably worth going again over the lock changes there [07:58] PR snapd#5780 opened: testutil: allow Fstatfs results to vary over time [07:58] PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key [07:59] mborzecki: might also show we miss a test [07:59] pedronis: ack, will do, thanks for the review [08:01] PR snapd#5781 opened: overlord: add chg.Err() in testUpdateWithAutoconnectRetry [08:02] ^- super trivial but would be great to get in so that I can figure out why the ppa builds are failing right now (3/6 arches failed with this error) :/ [08:02] sure [08:02] ta [08:02] mvo: just merge it [08:03] yeah, I think I will [08:03] pedronis: yeah, that lock, damn, don't know how i missed that :/ [08:04] mborzecki: it's easy to see in the diff, don't think is easy to see if you did changes and then more changes, to be honest when doing lock changes and changing one mind I would sort of recommend to start from a fresh master [08:05] mborzecki: I also suspect that error path is not tested [08:05] I mean even before [08:06] pedronis: right, it should panic there now that the lock is missing [08:09] Well that's odd. popeycore is a suspended laptop. Wonder how he got here. [08:12] huh, looks like my core laptop woke up when the battery was 0%, I guess to do the hybrid suspend, but that failed [08:19] popey: hybrid suspend shouldn't do that [08:20] well, its core [08:20] we dont really have much experience with suspending on that setup [08:20] popey: hybrid suspend is: prepare for hibernation, and just before power off, instead of power off, suspend [08:20] i thought hybrid suspend did exactly that. woke from suspend to go to hibernate? [08:20] huh [08:20] ah okay [08:20] Chipaca: that's not accurate [08:20] i know [08:20] Chipaca: nowadays firmware assists [08:20] handwavy a bit [08:20] Chipaca: firmware does the suspend to ssd by itself [08:20] this is not a new laptop [08:20] if it's correctly configured (right partitions etc [08:21] zyga: do we support that already? i thought that was ms-only magic [08:21] yes [08:21] for many many years now [08:21] ah ok [08:21] zyga: i'll have to look this up :-) [08:21] Chipaca: it just requires sandy bridge+ (ish, I forgot which exactly) [08:21] not today though [08:21] Chipaca: bios has to support this and it has to be enabled [08:21] why would you have a sandy bridge [08:21] Chipaca: you need to have an ssd and a correct partition layout [08:21] it's a safety hazard [08:22] sand makes things slippy [08:22] Chipaca: then after configured time the firmware wakes suspend-to-ram machine and suspends ram to ssd [08:22] and shuts off [08:22] it's _not_ booting the os [08:22] it's documented ... [08:23] but I cannot find the doc now :) [08:23] anyway [08:23] just wanted to say there are more parts that move now [08:23] indeed, anyway, it's not doing that :) [08:23] i'll have to look into it; the process i've seen when i used hybrid was the one i described (a bit more complex) [08:23] popey: boot windows and update bios [08:23] popey: or use fwupd [08:23] hahahah [08:23] it's an x61s [08:23] from the past [08:23] x61s, well [08:23] then it's not that :D [08:24] Chipaca: I have a desktop that supports that at home, it's pretty neat [08:24] Chipaca: essentially cuts the power drain while suspended [08:24] zyga: the power drain while suspended is already pretty low [08:25] Chipaca: well, it's zero then :) [08:25] and it fixes any magic hardware that doesn't really suspend correctly [08:25] well mine drained to 0 in a few days [08:25] see :) [08:25] right [08:25] this is how modern laptops get month+ on suspend [08:26] embedded IC probably still operates / LEDs blink [08:26] but not sure really [08:26] Chipaca: hi, thanks for the extra tests, some Qs in #5187 [08:26] PR #5187: overlord: introduce snapshotstate [08:27] pedronis: the var is leftover debug :-( as is the status in the notice :-(( [08:27] pedronis: I'll answer over there [08:29] mvo: did I accidentally trick you into supporting TinyHTTPProxy [08:30] Chipaca: *cough* the code felt very crufty so I modernized it a wee bit [08:30] maybe not crufty but just a bit old iirc, this is from 2006 originally or something [08:30] mvo: :-) that code has heritage :-D [08:30] yeah [08:31] Chipaca: so yeah, if you see further low hanging fruits, just shout [08:32] mvo: https://github.com/tkmunzwa/Tiny-HTTP-Proxy/blob/master/TinyHTTPProxy.py fwiw [08:32] mvo: that seems to be the most modern direct-line evolution of the one I had lying around [08:33] mvo: the other way this has evolved involves 'pip install', which loses its magic [08:33] Chipaca: thanks, I will see if there are useful bits [08:33] the whole point of it, to me, was that it was a single file i could scp places and work around silly firewall rules :-) [08:33] Chipaca: heh [08:33] TinyHTTPProxy + ssh port redirection == magic [08:34] Chipaca: that should still be possible with the version in the tree [08:34] Chipaca: the last bit I'm considering is the selectors module that zyga mentioned but I will try to control my ocd to cleanup further I think its already overdone. anyway, back to this failing test during package build [08:35] the irony - my latest PR fails in the proxy test which screams - merge the proxy fix :) [08:36] PR snapd#5781 closed: overlord: add chg.Err() in testUpdateWithAutoconnectRetry [08:37] Saviq,ogra: fix for the npm proxy thing is awaiting deployment (#8 in the IS queue) [08:37] PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy [08:37] weird how suddenly a bunch of different people asked me about that on the same day :) [08:38] mborzecki: can you look at https://github.com/snapcore/snapd/pull/5780 - it's a part of the bigger one you read, needs 2nd ack [08:38] PR #5780: testutil: allow Fstatfs results to vary over time [08:39] PR snapd#5779 closed: snap-update-ns: add comments about the "deadcode" in bootstrap.go [08:43] PR snapd#5780 closed: testutil: allow Fstatfs results to vary over time [08:43] PR snapd#5782 opened: ifacestate: helpers for generating slot names for hotplug [08:43] wtf [08:43] why did PR8 trigger a notification? [08:45] cjwatson, heh ... i blame Saviq though :) [08:45] Chipaca: btw, there other question is basically do we leave around tar files etc when we undo? the test doesn't seem to check [08:46] pedronis: I've added the check, and was about to reply "yes", but I think something is missing [08:46] cjwatson: ack, thanks! [08:47] pedronis: I might need to add a save cleanup [08:47] pedronis: to catch it [08:48] Chipaca: possibly yes, and remove stuff if Error [08:48] pedronis: wondering how to set things up so that one tar fails long after the other tars succeeded [08:48] for the test of that [08:48] Chipaca: remember we have mock command ? [08:49] i might do it with a shallower test, ie one that mocks backend [08:49] pedronis: yeah, that'd be the other approach, integration-y [08:49] anyway as you prefer [09:01] Chipaca: is there something like filepath.Ext but for the non-extension part? [09:03] zyga: no; if ext := filepath.Ext(path); ext != path { path = strings.TrimSuffix(path, ext) } [09:03] zyga: or, grab filepath.Ext and reverse what it returns [09:04] or dont [09:04] ¯\_(ツ)_/¯ [09:04] zyga: (ext'll always be != path unless path is "" fwiw) [09:06] thanks, I was hoping there's something baked [09:06] I like the TrimSuffix idea [09:07] mborzecki: I am reading 5770 right now, curious about the attack scenario. will the store do anything with the hashed instance name or is that just stored there? [09:09] mvo: afaict it's for metrics only [09:09] mborzecki: we probably also want to hash if we generate error reports thinking about it [09:09] mborzecki: ok [09:09] pedronis: I was wrong :-) we don't need a cleanup; undo does everything we need already [09:09] pedronis: it's as if i'd thought of this at some point, even :-) just not tested it [09:09] having to relearn my own code here [09:10] that's how long it's been [09:10] mvo: erorr reports contain a lsit of installed snaps? [09:10] pedronis: anyway now we'll have a test for it [09:10] zyga: random thought, maybe we should grab an hour one evening in brussels or something and work on snapd in debian [09:10] mwhudson: very much so [09:10] i just can't seem to work up the motivation to do it on my own [09:11] mborzecki: no but if a specific instance fails to install or refresh we might leak the name I have not checked the code just a idle thought [09:11] mvo: ok, will take a look, addign to my todo list [09:12] ta [09:16] Chipaca: :) thanks [09:22] pstolowski: does https://paste.ubuntu.com/p/Jjc3JFDWnT/ ring any bells? it seems to be a race and we hit it ~50% of the time when bulding the edge snap currently [09:23] pstolowski: e.g. https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+sourcepub/9385143/+listing-archive-extra [09:23] mvo: looking [09:23] thanks [09:25] mvo: no, i haven't seen it before; looks like a race indeed, investigating [09:42] hey there [09:42] how do I tell snapd to not do any auto refrsh today? [09:43] $ snap refresh --time [09:46] seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z" [09:47] seb128: then snap refresh --time should tell you that the refresh is on hold [09:48] pedronis: pushed fixes, added a test where UndoSetupSnap fails, also that All() was indeed useless, the variant with Get("snaps"..) is same line count and lighter :) [09:52] mborzecki: I added some comments to the other ones [09:53] mvo: do you have anything in your pile that needs my review ? [09:53] bah, mobile connection timeouted [09:53] unsure if my question when through before [09:53] seb128: yes [09:53] how can I disable autorefresh for the day? [09:53] pedronis: thanks, [09:54] seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z" [09:54] seb128: then snap refresh --time should tell you that the refresh is on hold [09:54] PR snapd#5783 opened: tests: add new core16-base test [09:54] mvo, pedronis, thanks! [09:54] we should grow a command but we have to discuss how to add it (we have too many commands already) [09:55] (not very user friendly to figure out, "$ snap refresh --help" could at least hint that (or best, include a "--skip-next" or something) [09:55] mvo: ^ something to (re)discuss in brussel (how to tame our commands zoo to be able to add some more) ? [09:55] pedronis: yeah, the parser is also very strict about the time format, having something like "snap refresh --defer 1d" would be much nicer [09:55] that would be great [09:55] pedronis: yeah, that sounds like a good discussion [09:56] also n-m integration to respect the limited-bandwith flag and not refresh then would be nice [09:56] (gnome-software/flatpak do that) [09:57] mvo, your command confuses me, now [09:57] $ snap refresh --time [09:57] hold: tomorrow at 19:00 CEST [09:57] next: today at 15:23 CEST [09:57] it still says next is today at 15:23? [09:57] yes [09:57] * seb128 is scared about his data [09:57] seb128: limit or metered? I mean does it not do any refreshes ? [09:57] seb128: or slows them down? [09:57] seb128: there is still a next but hold overrides [09:57] metered [09:57] it just doesn't download updates [09:58] since you don't want to risk eating the user data plan in his back [09:58] (well they have a switch to enable auto download in that case, but it's off by default) [09:58] seb128: fwiw, we have a option to respect metered, "sudo snap set core refresh.metered=true" [09:58] that integrates to n-m? [09:58] mborzecki: maybe we should enabled metered by default? (cc seb128 ) [09:58] that sounds like a reasonable default to me [09:58] seb128: +1 [09:59] should I open a forum post about that maybe? [09:59] mvo: probably needs a +1 from niemeyer too [09:59] I'm trying to stage the directory my-part/install/include → added it to stage as `include/*` but it does not show up in stage/. other directories from stage keyword do show up. Does someone has a hint what I'm doing wrong? [09:59] yes, we had a long back and forth when we added it [09:59] +1 to simplifying that. The syntax is arcane and user hostile [09:59] I'm also going to open a bug about snap refresh --time telling me that the next refresh is on a time where it's not [09:59] seb128, pedronis hm, hm, it sounds like we should we smarter about "next: " when we also have "hold:" to not confuse users [10:00] seb128: could you write a forum topic? I prepare a pr then [10:00] mvo: I don't know [10:00] probably superficially somewhere [10:00] mvo, is the forum or github the right place for such reports? [10:00] not deeply [10:00] code is complicated enough as it is [10:00] pedronis: :/ ok [10:00] seb128: forum works best, otherwise LP [10:00] mvo, k, good [10:01] What's the use case? [10:01] Do we have someone that reported issues while using metered connections? [10:01] (hello, btw :) [10:01] mvo: also remember is partly by design, if you snap set refresh.hold= before that next you would still get the refresh [10:01] niemeyer: yes [10:01] mvo: if you change your mind [10:01] is really not meant to move next [10:01] niemeyer: seb128 was surprised that the default for honoring metered connections is "off" [10:02] mvo: maybe is just a better of outputting something clearer in snap refresh --time [10:02] pedronis: yeah, maybe its enough to be smart at the presentation layer, i.e. snap refresh --time could look at the values maybe [10:02] niemeyer, I'm just train travelling and on mobile plan/tethering and I don't want snapd to eat my 1G monthly cap [10:02] mvo: Sure, but do we have someone with actual issues reporting? [10:02] pedronis: heh, sounds like we have the same idea [10:03] seb128: please paste me the link to your bug about next/hold and I will have a look [10:03] mvo, niemeyer, I'm going to start a discussion in the forum about that I guess, I think the safe default on metered connection is not eat datas since it's likely that those have a cost or a limit [10:04] seb128: That's reasonable of course.. how well is the automatic detection of that scenario working nowadays? [10:04] niemeyer, we don't have any yet, iirc? [10:04] mvo, will do, I'm going to need to jump off that train and connect to another one in like 3 min but I do once I'm settled down in the next one :) [10:04] or did that stuff get merged? [10:04] (I forgot, it's hard to keep track of all the stuff!) [10:04] Son_Goku: Heya [10:04] yo [10:05] Son_Goku: Not on our end.. we just honor the network manager setting [10:05] so then at least from our side, we should be fine [10:05] The question is how well is the automatic detection of the scenario seb128 described [10:05] niemeyer, I don't know about the snapd side and where it gets its info from, but network-manager has heuristics that seem to make sense to me [10:05] I suppose that depends on whether NM can figure it out, then [10:05] if it can't, then *shrug* [10:05] in my case, it usually does [10:05] seb128: The question is about network-manager itself.. we just honor it.. we don't have a setting by ourselves [10:06] seb128: But to change defaults, we need to have some idea of whether it will actually fix the problem reported, and whether it might create problems for others [10:07] Saviq, btw, it might make sense to have something added to the review-tools so packages using wayland-socket-dir get auto-rejected with a deprecation message on upload ... i wonder how hard that is to add for jdstrand [10:07] niemeyer, ok, I'm going to get the details and write on the forum with what n-m is doing exactly, we can have a discussion there then [10:07] seb128: Thanks! [10:07] yw, thanks for being interested in the topic :) [10:09]