| Pharaoh_Atem | zyga: https://youtu.be/UOZXERFHsW4?t=58m26s | 00:16 |
|---|---|---|
| Pharaoh_Atem | https://youtu.be/UOZXERFHsW4?t=1h1m32s | 00:18 |
| Pharaoh_Atem | niemeyer: nice mention by mattdm about our snap work in an interview about fedora ^ | 00:19 |
| sergiusens | Doctor_Nick: at the very end of it, you can opt-in to have that in the snap | 00:48 |
| Doctor_Nick | sergiusens: ah hah | 00:49 |
| sergiusens | there's an env var to allow it all the way through | 00:49 |
| Doctor_Nick | so it's not really required for the build? | 00:49 |
| Doctor_Nick | it's not used in staging, priming, etc.? | 00:50 |
| sergiusens | 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 |
| sergiusens | Doctor_Nick: also https://snapcraft.io/blog/introducing-developer-notifications-for-snap-security-updates | 00:51 |
| Doctor_Nick | ok | 00:52 |
| Doctor_Nick | 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:22 |
| Doctor_Nick | also, why do snap daemons run as root? | 01:48 |
| Son_Goku | zyga, snapd 2.35 has been pushed for f27 too | 03:37 |
| zyga | Good morning | 04:21 |
| zyga | Thank you Neal | 04:21 |
| Son_Goku | zyga, we got some nice mentions in mattdm's recent interview on Destination Linux | 04:31 |
| Son_Goku | you should watch it ;) | 04:31 |
| zyga | I will, thank you for the tip :-) | 04:49 |
| mup | PR snapd#5774 closed: tests: introduce a helper for installing local snaps with --name <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5774> | 04:59 |
| mborzecki | morning | 05:06 |
| zyga | good morning (again) | 05:46 |
| zyga | both kids in school | 05:46 |
| zyga | time to work :) | 05:46 |
| zyga | good morning mvo :) | 05:47 |
| mvo | hey zyga | 05:50 |
| mborzecki | zyga: mvo: hey | 05:50 |
| mvo | mborzecki: good morning | 05:50 |
| mup | PR snapd#5775 closed: tests: also run unit/gccgo in 18.04 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5775> | 06:00 |
| mvo | hm,hm, on arch the interfaces-timerserver-control test is failing for me:https://api.travis-ci.org/v3/job/425119844/log.txt | 06:38 |
| mborzecki | looking | 06:42 |
| mborzecki | mvo: does it reproduce always? maybe it's some temporary hiccup with ntp? | 06:44 |
| mvo | mborzecki: I saw it two times lets see if it happens again | 06:45 |
| s10gopal | can i install ubuntu core on esp8266 | 06:47 |
| s10gopal | ? | 06:47 |
| zyga | hey s10gopal, we haven't heard about anyone attempting that yet | 06:48 |
| zyga | s10gopal: you'd have to have a relatively modern linux kernel and supported boot loader | 06:49 |
| zyga | 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:49 |
| zyga | let us know what you learn | 06:50 |
| s10gopal | zyga, thanks | 06:52 |
| mborzecki | 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:01 |
| mborzecki | 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:02 |
| mvo | pi zero not yet :/ | 07:05 |
| zyga | mvo: indeed | 07:05 |
| mvo | 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 |
| mup | PR #5767: many: remove deadcode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5767> | 07:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:09 |
| pstolowski | mvo: looking | 07:09 |
| mvo | pstolowski: thanks and good morning | 07:10 |
| pedronis | 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:11 |
| mvo | pedronis: aha, no worries | 07:13 |
| mvo | pedronis: just wanted to double check because of the things in flight. thanks for confirming | 07:13 |
| pstolowski | mvo: +1, it's fine to remove it | 07:14 |
| mvo | ta | 07:14 |
| pstolowski | and both pedronis and me claim forgetting to remove it ;) | 07:15 |
| mvo | heh | 07:15 |
| mup | PR snapd#5767 closed: many: remove deadcode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5767> | 07:15 |
| pedronis | :) | 07:16 |
| * pedronis is going to do reviewing this morning | 07:25 | |
| zyga | brb | 07:30 |
| zyga | more coffee | 07:30 |
| mborzecki | coffee, brilliant idea | 07:34 |
| mup | PR snapd#5778 opened: snap-update-ns: remove deadcode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5778> | 07:41 |
| mvo | 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:42 |
| zyga | looking, thank you! | 07:48 |
| zyga | mvo: we need all of those | 07:48 |
| zyga | they are used in the trespassing fix PR already | 07:48 |
| zyga | (they were added as a part of -v1 review | 07:48 |
| zyga | the comments are +1 but the removals are not needed | 07:49 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/5760 | 07:49 |
| mup | PR #5760: cmd/snap-update-ns: don't trespass on host filesystem in /etc and other places <Created by zyga> <https://github.com/snapcore/snapd/pull/5760> | 07:49 |
| mvo | zyga: aha, cool. I close it then | 07:49 |
| zyga | thanks, I'll steal the comments though :) | 07:49 |
| mvo | zyga: yeah, iirc they are a commit that can even be cherry picked | 07:50 |
| zyga | yeah | 07:50 |
| zyga | 91e746fc0d61c8e89b9c4931f3eee39bef6e9ef3 | 07:50 |
| zyga | doing that now :) | 07:50 |
| mvo | zyga: thank you | 07:50 |
| zyga | thank You :) | 07:50 |
| mup | PR snapd#5778 closed: snap-update-ns: remove deadcode <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5778> | 07:50 |
| zyga | mvo: is there any dead code in interfaces? | 07:51 |
| mvo | zyga: chopTree | 07:51 |
| zyga | aha | 07:51 |
| mvo | zyga: thats the only bit | 07:51 |
| zyga | that _may_ become unused | 07:51 |
| zyga | it's part of another fix | 07:51 |
| zyga | but I may end up not needing it | 07:51 |
| zyga | thanks! | 07:51 |
| mvo | zyga: ok, I will leave it alone | 07:52 |
| zyga | I'll remove it if that is the case | 07:52 |
| mvo | 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 |
| mvo | zyga: sounds good, thank you | 07:52 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/5779 | 07:54 |
| mup | PR #5779: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5779> | 07:54 |
| mup | PR snapd#5779 opened: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5779> | 07:54 |
| zyga | oh, mup is back :) | 07:55 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5780 | 07:58 |
| mup | PR #5780: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780> | 07:58 |
| pedronis | 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 |
| mup | PR snapd#5780 opened: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780> | 07:58 |
| mup | PR #5758: overlord/snapstate, snap: handle shared snap directories when installing/remove snaps with instance key <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5758> | 07:58 |
| pedronis | mborzecki: might also show we miss a test | 07:59 |
| mborzecki | pedronis: ack, will do, thanks for the review | 07:59 |
| mup | PR snapd#5781 opened: overlord: add chg.Err() in testUpdateWithAutoconnectRetry <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5781> | 08:01 |
| mvo | ^- 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 |
| zyga | sure | 08:02 |
| mvo | ta | 08:02 |
| zyga | mvo: just merge it | 08:02 |
| mvo | yeah, I think I will | 08:03 |
| mborzecki | pedronis: yeah, that lock, damn, don't know how i missed that :/ | 08:03 |
| pedronis | 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:04 |
| pedronis | mborzecki: I also suspect that error path is not tested | 08:05 |
| pedronis | I mean even before | 08:05 |
| mborzecki | pedronis: right, it should panic there now that the lock is missing | 08:06 |
| popey | Well that's odd. popeycore is a suspended laptop. Wonder how he got here. | 08:09 |
| popey | huh, looks like my core laptop woke up when the battery was 0%, I guess to do the hybrid suspend, but that failed | 08:12 |
| Chipaca | popey: hybrid suspend shouldn't do that | 08:19 |
| ogra | well, its core | 08:20 |
| ogra | we dont really have much experience with suspending on that setup | 08:20 |
| Chipaca | popey: hybrid suspend is: prepare for hibernation, and just before power off, instead of power off, suspend | 08:20 |
| popey | i thought hybrid suspend did exactly that. woke from suspend to go to hibernate? | 08:20 |
| popey | huh | 08:20 |
| popey | ah okay | 08:20 |
| zyga | Chipaca: that's not accurate | 08:20 |
| Chipaca | i know | 08:20 |
| zyga | Chipaca: nowadays firmware assists | 08:20 |
| Chipaca | handwavy a bit | 08:20 |
| zyga | Chipaca: firmware does the suspend to ssd by itself | 08:20 |
| popey | this is not a new laptop | 08:20 |
| zyga | if it's correctly configured (right partitions etc | 08:20 |
| Chipaca | zyga: do we support that already? i thought that was ms-only magic | 08:21 |
| zyga | yes | 08:21 |
| zyga | for many many years now | 08:21 |
| Chipaca | ah ok | 08:21 |
| Chipaca | zyga: i'll have to look this up :-) | 08:21 |
| zyga | Chipaca: it just requires sandy bridge+ (ish, I forgot which exactly) | 08:21 |
| Chipaca | not today though | 08:21 |
| zyga | Chipaca: bios has to support this and it has to be enabled | 08:21 |
| Chipaca | why would you have a sandy bridge | 08:21 |
| zyga | Chipaca: you need to have an ssd and a correct partition layout | 08:21 |
| Chipaca | it's a safety hazard | 08:21 |
| Chipaca | sand makes things slippy | 08:22 |
| zyga | Chipaca: then after configured time the firmware wakes suspend-to-ram machine and suspends ram to ssd | 08:22 |
| zyga | and shuts off | 08:22 |
| zyga | it's _not_ booting the os | 08:22 |
| zyga | it's documented ... | 08:22 |
| zyga | but I cannot find the doc now :) | 08:23 |
| zyga | anyway | 08:23 |
| zyga | just wanted to say there are more parts that move now | 08:23 |
| popey | indeed, anyway, it's not doing that :) | 08:23 |
| Chipaca | 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 |
| zyga | popey: boot windows and update bios | 08:23 |
| zyga | popey: or use fwupd | 08:23 |
| popey | hahahah | 08:23 |
| popey | it's an x61s | 08:23 |
| popey | from the past | 08:23 |
| zyga | x61s, well | 08:23 |
| zyga | then it's not that :D | 08:23 |
| zyga | Chipaca: I have a desktop that supports that at home, it's pretty neat | 08:24 |
| zyga | Chipaca: essentially cuts the power drain while suspended | 08:24 |
| Chipaca | zyga: the power drain while suspended is already pretty low | 08:24 |
| zyga | Chipaca: well, it's zero then :) | 08:25 |
| zyga | and it fixes any magic hardware that doesn't really suspend correctly | 08:25 |
| popey | well mine drained to 0 in a few days | 08:25 |
| zyga | see :) | 08:25 |
| Chipaca | right | 08:25 |
| zyga | this is how modern laptops get month+ on suspend | 08:25 |
| zyga | embedded IC probably still operates / LEDs blink | 08:26 |
| zyga | but not sure really | 08:26 |
| pedronis | Chipaca: hi, thanks for the extra tests, some Qs in #5187 | 08:26 |
| mup | PR #5187: overlord: introduce snapshotstate <Created by chipaca> <https://github.com/snapcore/snapd/pull/5187> | 08:26 |
| Chipaca | pedronis: the var is leftover debug :-( as is the status in the notice :-(( | 08:27 |
| Chipaca | pedronis: I'll answer over there | 08:27 |
| Chipaca | mvo: did I accidentally trick you into supporting TinyHTTPProxy | 08:29 |
| mvo | Chipaca: *cough* the code felt very crufty so I modernized it a wee bit | 08:30 |
| mvo | maybe not crufty but just a bit old iirc, this is from 2006 originally or something | 08:30 |
| Chipaca | mvo: :-) that code has heritage :-D | 08:30 |
| Chipaca | yeah | 08:30 |
| mvo | Chipaca: so yeah, if you see further low hanging fruits, just shout | 08:31 |
| Chipaca | mvo: https://github.com/tkmunzwa/Tiny-HTTP-Proxy/blob/master/TinyHTTPProxy.py fwiw | 08:32 |
| Chipaca | mvo: that seems to be the most modern direct-line evolution of the one I had lying around | 08:32 |
| Chipaca | mvo: the other way this has evolved involves 'pip install', which loses its magic | 08:33 |
| mvo | Chipaca: thanks, I will see if there are useful bits | 08:33 |
| Chipaca | 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 |
| mvo | Chipaca: heh | 08:33 |
| Chipaca | TinyHTTPProxy + ssh port redirection == magic | 08:33 |
| mvo | Chipaca: that should still be possible with the version in the tree | 08:34 |
| mvo | 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:34 |
| mvo | the irony - my latest PR fails in the proxy test which screams - merge the proxy fix :) | 08:35 |
| mup | PR snapd#5781 closed: overlord: add chg.Err() in testUpdateWithAutoconnectRetry <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5781> | 08:36 |
| cjwatson | Saviq,ogra: fix for the npm proxy thing is awaiting deployment (#8 in the IS queue) | 08:37 |
| mup | PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy <Created by chipaca> <Merged by elopio> <https://github.com/snapcore/snapd/pull/8> | 08:37 |
| cjwatson | weird how suddenly a bunch of different people asked me about that on the same day :) | 08:37 |
| zyga | 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 |
| mup | PR #5780: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5780> | 08:38 |
| mup | PR snapd#5779 closed: snap-update-ns: add comments about the "deadcode" in bootstrap.go <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5779> | 08:39 |
| mup | PR snapd#5780 closed: testutil: allow Fstatfs results to vary over time <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5780> | 08:43 |
| mup | PR snapd#5782 opened: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782> | 08:43 |
| Son_Goku | wtf | 08:43 |
| Son_Goku | why did PR8 trigger a notification? | 08:43 |
| ogra | cjwatson, heh ... i blame Saviq though :) | 08:45 |
| pedronis | 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:45 |
| Chipaca | pedronis: I've added the check, and was about to reply "yes", but I think something is missing | 08:46 |
| Saviq | cjwatson: ack, thanks! | 08:46 |
| Chipaca | pedronis: I might need to add a save cleanup | 08:47 |
| Chipaca | pedronis: to catch it | 08:47 |
| pedronis | Chipaca: possibly yes, and remove stuff if Error | 08:48 |
| Chipaca | pedronis: wondering how to set things up so that one tar fails long after the other tars succeeded | 08:48 |
| Chipaca | for the test of that | 08:48 |
| pedronis | Chipaca: remember we have mock command ? | 08:48 |
| Chipaca | i might do it with a shallower test, ie one that mocks backend | 08:49 |
| Chipaca | pedronis: yeah, that'd be the other approach, integration-y | 08:49 |
| pedronis | anyway as you prefer | 08:49 |
| zyga | Chipaca: is there something like filepath.Ext but for the non-extension part? | 09:01 |
| Chipaca | zyga: no; if ext := filepath.Ext(path); ext != path { path = strings.TrimSuffix(path, ext) } | 09:03 |
| Chipaca | zyga: or, grab filepath.Ext and reverse what it returns | 09:03 |
| Chipaca | or dont | 09:04 |
| Chipaca | ¯\_(ツ)_/¯ | 09:04 |
| Chipaca | zyga: (ext'll always be != path unless path is "" fwiw) | 09:04 |
| zyga | thanks, I was hoping there's something baked | 09:06 |
| zyga | I like the TrimSuffix idea | 09:06 |
| mvo | 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:07 |
| mborzecki | mvo: afaict it's for metrics only | 09:09 |
| mvo | mborzecki: we probably also want to hash if we generate error reports thinking about it | 09:09 |
| mvo | mborzecki: ok | 09:09 |
| Chipaca | pedronis: I was wrong :-) we don't need a cleanup; undo does everything we need already | 09:09 |
| Chipaca | pedronis: it's as if i'd thought of this at some point, even :-) just not tested it | 09:09 |
| Chipaca | having to relearn my own code here | 09:09 |
| Chipaca | that's how long it's been | 09:10 |
| mborzecki | mvo: erorr reports contain a lsit of installed snaps? | 09:10 |
| Chipaca | pedronis: anyway now we'll have a test for it | 09:10 |
| mwhudson | zyga: random thought, maybe we should grab an hour one evening in brussels or something and work on snapd in debian | 09:10 |
| zyga | mwhudson: very much so | 09:10 |
| mwhudson | i just can't seem to work up the motivation to do it on my own | 09:10 |
| mvo | 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 |
| mborzecki | mvo: ok, will take a look, addign to my todo list | 09:11 |
| mvo | ta | 09:12 |
| pedronis | Chipaca: :) thanks | 09:16 |
| mvo | 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:22 |
| mvo | pstolowski: e.g. https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+sourcepub/9385143/+listing-archive-extra | 09:23 |
| pstolowski | mvo: looking | 09:23 |
| mvo | thanks | 09:23 |
| pstolowski | mvo: no, i haven't seen it before; looks like a race indeed, investigating | 09:25 |
| seb128 | hey there | 09:42 |
| seb128 | how do I tell snapd to not do any auto refrsh today? | 09:42 |
| seb128 | $ snap refresh --time | 09:43 |
| mvo | seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z" | 09:46 |
| mvo | seb128: then snap refresh --time should tell you that the refresh is on hold | 09:47 |
| mborzecki | 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:48 |
| pedronis | mborzecki: I added some comments to the other ones | 09:52 |
| pedronis | mvo: do you have anything in your pile that needs my review ? | 09:53 |
| seb128 | bah, mobile connection timeouted | 09:53 |
| seb128 | unsure if my question when through before | 09:53 |
| pedronis | seb128: yes | 09:53 |
| seb128 | how can I disable autorefresh for the day? | 09:53 |
| mborzecki | pedronis: thanks, | 09:53 |
| pedronis | <mvo> seb128: you can use "sudo snap set core refresh.hold=2018-09-07T17:00:00Z" | 09:54 |
| pedronis | seb128: then snap refresh --time should tell you that the refresh is on hold | 09:54 |
| mup | PR snapd#5783 opened: tests: add new core16-base test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5783> | 09:54 |
| seb128 | mvo, pedronis, thanks! | 09:54 |
| pedronis | we should grow a command but we have to discuss how to add it (we have too many commands already) | 09:54 |
| seb128 | (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 |
| pedronis | mvo: ^ something to (re)discuss in brussel (how to tame our commands zoo to be able to add some more) ? | 09:55 |
| mvo | 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 |
| seb128 | that would be great | 09:55 |
| mvo | pedronis: yeah, that sounds like a good discussion | 09:55 |
| seb128 | also n-m integration to respect the limited-bandwith flag and not refresh then would be nice | 09:56 |
| seb128 | (gnome-software/flatpak do that) | 09:56 |
| seb128 | mvo, your command confuses me, now | 09:57 |
| seb128 | $ snap refresh --time | 09:57 |
| seb128 | hold: tomorrow at 19:00 CEST | 09:57 |
| seb128 | next: today at 15:23 CEST | 09:57 |
| seb128 | it still says next is today at 15:23? | 09:57 |
| pedronis | yes | 09:57 |
| * seb128 is scared about his data | 09:57 | |
| mvo | seb128: limit or metered? I mean does it not do any refreshes ? | 09:57 |
| mvo | seb128: or slows them down? | 09:57 |
| pedronis | seb128: there is still a next but hold overrides | 09:57 |
| seb128 | metered | 09:57 |
| seb128 | it just doesn't download updates | 09:57 |
| seb128 | since you don't want to risk eating the user data plan in his back | 09:58 |
| seb128 | (well they have a switch to enable auto download in that case, but it's off by default) | 09:58 |
| mvo | seb128: fwiw, we have a option to respect metered, "sudo snap set core refresh.metered=true" | 09:58 |
| seb128 | that integrates to n-m? | 09:58 |
| mvo | mborzecki: maybe we should enabled metered by default? (cc seb128 ) | 09:58 |
| seb128 | that sounds like a reasonable default to me | 09:58 |
| mvo | seb128: +1 | 09:58 |
| seb128 | should I open a forum post about that maybe? | 09:59 |
| mborzecki | mvo: probably needs a +1 from niemeyer too | 09:59 |
| dot-tobias | 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 |
| pedronis | yes, we had a long back and forth when we added it | 09:59 |
| popey | +1 to simplifying that. The syntax is arcane and user hostile | 09:59 |
| seb128 | 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 |
| mvo | seb128, pedronis hm, hm, it sounds like we should we smarter about "next: " when we also have "hold:" to not confuse users | 09:59 |
| mvo | seb128: could you write a forum topic? I prepare a pr then | 10:00 |
| pedronis | mvo: I don't know | 10:00 |
| pedronis | probably superficially somewhere | 10:00 |
| seb128 | mvo, is the forum or github the right place for such reports? | 10:00 |
| pedronis | not deeply | 10:00 |
| pedronis | code is complicated enough as it is | 10:00 |
| mvo | pedronis: :/ ok | 10:00 |
| mvo | seb128: forum works best, otherwise LP | 10:00 |
| seb128 | mvo, k, good | 10:00 |
| niemeyer | What's the use case? | 10:01 |
| niemeyer | Do we have someone that reported issues while using metered connections? | 10:01 |
| niemeyer | (hello, btw :) | 10:01 |
| pedronis | mvo: also remember is partly by design, if you snap set refresh.hold= before that next you would still get the refresh | 10:01 |
| mvo | niemeyer: yes | 10:01 |
| pedronis | mvo: if you change your mind | 10:01 |
| pedronis | is really not meant to move next | 10:01 |
| mvo | niemeyer: seb128 was surprised that the default for honoring metered connections is "off" | 10:01 |
| pedronis | mvo: maybe is just a better of outputting something clearer in snap refresh --time | 10:02 |
| mvo | 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 |
| seb128 | 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 |
| niemeyer | mvo: Sure, but do we have someone with actual issues reporting? | 10:02 |
| mvo | pedronis: heh, sounds like we have the same idea | 10:02 |
| mvo | seb128: please paste me the link to your bug about next/hold and I will have a look | 10:03 |
| seb128 | 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:03 |
| niemeyer | seb128: That's reasonable of course.. how well is the automatic detection of that scenario working nowadays? | 10:04 |
| Son_Goku | niemeyer, we don't have any yet, iirc? | 10:04 |
| seb128 | 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 |
| Son_Goku | or did that stuff get merged? | 10:04 |
| Son_Goku | (I forgot, it's hard to keep track of all the stuff!) | 10:04 |
| niemeyer | Son_Goku: Heya | 10:04 |
| Son_Goku | yo | 10:04 |
| niemeyer | Son_Goku: Not on our end.. we just honor the network manager setting | 10:05 |
| Son_Goku | so then at least from our side, we should be fine | 10:05 |
| niemeyer | The question is how well is the automatic detection of the scenario seb128 described | 10:05 |
| seb128 | 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 |
| Son_Goku | I suppose that depends on whether NM can figure it out, then | 10:05 |
| Son_Goku | if it can't, then *shrug* | 10:05 |
| Son_Goku | in my case, it usually does | 10:05 |
| niemeyer | seb128: The question is about network-manager itself.. we just honor it.. we don't have a setting by ourselves | 10:05 |
| niemeyer | 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:06 |
| ogra | 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 |
| seb128 | 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 |
| niemeyer | seb128: Thanks! | 10:07 |
| seb128 | yw, thanks for being interested in the topic :) | 10:07 |
| ogra | wll, does NM know you are tethering if you do it via wlan ? (assuming you just connect to a phone hostpot (at least thats how i do train rides)) | 10:09 |
| ogra | *well | 10:09 |
| ogra | having some manual knob might make sense in that case | 10:10 |
| popey | nm has a switch to flip to say that | 10:14 |
| Son_Goku | NM has a lot of switches, knobs, and probes for determining whether it should say it's on a metered connection | 10:14 |
| Son_Goku | but last resort, you can *tell* NM it's a metered connection | 10:14 |
| popey | right, i meant in the case of a non-automagically determined connection, the user can override by flipping a switch | 10:15 |
| ogra | ah, i didnt know that (havent seen that in 16.04) | 10:15 |
| Son_Goku | it doesn't exist in 16.04, iirc | 10:15 |
| Son_Goku | most of the functionality was introduced in NM 1.4, I think? | 10:15 |
| ogra | thats like why then :) | 10:15 |
| Son_Goku | iirc, NM 1.0 is in 16.04 | 10:15 |
| mborzecki | ogra: there's DHCP option that convey that you're on phone hotspot, afaik only android phones set it | 10:16 |
| ogra | ah, cool, i didnt know that ! | 10:17 |
| Son_Goku | yeah | 10:17 |
| Son_Goku | I think iOS sends a thing too, because Macs know when its connected to hotspots | 10:17 |
| Son_Goku | but it's not "normal" like Android's | 10:18 |
| mborzecki | any chance we could have snapd gnome-software integration flip the switch appropriately? | 10:18 |
| Son_Goku | mborzecki: the integration is above g-s | 10:18 |
| Son_Goku | it's in gnome itself | 10:18 |
| Son_Goku | specifically, NM tells GNOME that it's metered, and everything responds to that | 10:19 |
| Son_Goku | the g-s snap probably can't access the gnome information index like g-s normally can | 10:19 |
| ogra | but it can use the NM interface to ask NM | 10:20 |
| Son_Goku | yes | 10:20 |
| ogra | (at least it should be able to) | 10:20 |
| seb128 | well g-s already uses that flag in their flatpak plugin | 10:20 |
| mborzecki | snapd asks NM if current coonnection is metered | 10:21 |
| seb128 | but it wouldn't make sense to do something for snaps there since it's not gnome-software who download/refresh snaps | 10:21 |
| seb128 | (as it does for flatpaks) | 10:21 |
| pedronis | Chipaca: I have a question for you, do you remember why we didn't add call to validateInfoAndFlags in snapstate.InstallPath ? | 10:21 |
| pedronis | *a call | 10:21 |
| ogra | right, and if snapd actually DTRT here (talking directly to NM) it should theoretically just work the right way | 10:21 |
| mborzecki | what we need is to tell snapd that it should hold refreshes if on metered, everything else is already there | 10:22 |
| Son_Goku | mborzecki, I thought we already do? | 10:22 |
| Son_Goku | at least, that's what niemeyer said | 10:22 |
| mborzecki | Son_Goku: integration with NM and holding refreshes is there but it's off by default | 10:23 |
| Son_Goku | ah, well that helps nobody | 10:23 |
| niemeyer | Again, the reason why the default is off is because we need to have some idea of whether it will actually fix the problem reported, and whether it might create problems for others | 10:23 |
| mborzecki | as pedronis wrote there was some back and forth about having it on by default | 10:23 |
| niemeyer | And we're having it again just onw.. | 10:24 |
| niemeyer | now | 10:24 |
| niemeyer | The reason we didn't enable is because nobody knew for sure when that flag was enabled or not | 10:24 |
| Son_Goku | how do we turn it on to find out? | 10:24 |
| Chipaca | everybody i've talked to that was complaining about, i asked them to confirm back whether it worked or not | 10:24 |
| Chipaca | and, nobody has so far | 10:25 |
| mborzecki | so we're just missing a piece that talks to gnome and knows whether the user wanted to hold updates (be it system, flatpak or other) while on metered | 10:25 |
| Chipaca | so i've brought you 0 data points | 10:25 |
| niemeyer | mborzecki: The only piece missing is feedback, and proper information | 10:25 |
| niemeyer | mborzecki: It's not about whether the user wants to hold or not, but about when that flag actually goes on or not | 10:26 |
| niemeyer | IIRC, the feature was developed to fix a need for a manufacturer that had specific hardware, and knew what was going on.. they enabled it for their device, which they had strict control over | 10:27 |
| mborzecki | niemeyer: what i meant is that if a gnome user flips it on in gnome settings (or wherever else the setting is), we can only react if there's that integration piece that conveys their choice | 10:27 |
| niemeyer | So the feature worked well there.. but to change that to always enabled, we need a much better idea of when connections will be marked as metered | 10:27 |
| popey | FWIW I set the free train wifi to be metered because it's slow and I need the bandwidth for other stuff. | 10:32 |
| popey | I also defer all updates to 4am because I am often doing podcasts in the evening, and I don't want my laptop to start chugging away updating snaps unexpectedly | 10:33 |
| ogra | but that indeed expects that your laptop is on at that time | 10:33 |
| popey | which it often isnt | 10:33 |
| popey | so I have to manually snap refresh | 10:33 |
| popey | (also, it frustrates me that snapd starts doing updates immediately on wake from suspend which makes the laptop unusable for minutes) | 10:34 |
| ogra | it doesnt kick in after you booted it again ? | 10:34 |
| popey | no | 10:34 |
| ogra | all my VM core images definitely do that ... i have to plan an extra 10-15min when i plan to work with one that i havet booted in a while | 10:34 |
| popey | hm, maybe it does and I didnt notice | 10:35 |
| popey | today I pressed the wake button and walked away to get coffee | 10:35 |
| ogra | ecause the VM typically kicks off a core update right after boot and then reboots | 10:35 |
| pstolowski | mborzecki, zyga hey, since you commented some time ago on https://github.com/snapcore/snapd/pull/5632 - can you re-review? | 10:40 |
| mup | PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632> | 10:40 |
| zyga | sure | 10:40 |
| mborzecki | ok | 10:41 |
| pstolowski | ty! | 10:41 |
| zyga | pstolowski: done | 10:50 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/5632#discussion_r215580734 is the most important issue I think | 10:51 |
| mup | PR #5632: overlord: integrate device enumeration with udev monitor <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5632> | 10:51 |
| seb128 | mvo, https://forum.snapcraft.io/t/next-refresh-info-confusing-when-on-hold/7230 | 10:55 |
| seb128 | sorry, internet was flaky arriving to the station | 10:55 |
| pstolowski | zyga: hmm the err is returned in the next line? | 10:55 |
| zyga | DOH :) | 10:55 |
| zyga | thanks, I missed that :) | 10:55 |
| zyga | I removed it from the review now | 10:55 |
| seb128 | and now going for my next train ;) | 10:56 |
| pstolowski | zyga: thanks for the other suggestions1 | 10:56 |
| mborzecki | pedronis: i'm thinking about that base64, it's possible that there will be - in the encoded data, so simple '-'.split(..) might get a little confusing | 11:00 |
| mborzecki | pstolowski: 'foo'.split('-') ofc | 11:00 |
| mup | PR core18#69 opened: hooks: add libpam-modules <Created by mvo5> <https://github.com/snapcore/core18/pull/69> | 11:01 |
| mup | PR core18#69 closed: hooks: add libpam-modules <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/69> | 11:07 |
| mup | PR snapd#5784 opened: tests: run account-control test on uc16,uc18 and with different bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5784> | 11:08 |
| pedronis | mborzecki: I really hope we don't split those keys anywhere | 11:19 |
| pedronis | mborzecki: why the 39 -> 15 change ? | 11:29 |
| pedronis | Chipaca: did you see my question? | 11:30 |
| Chipaca | pedronis: no | 11:30 |
| Chipaca | pedronis: oh | 11:30 |
| mborzecki | pedronis: should be enough bytes, i can pass the whole lot | 11:30 |
| Chipaca | pedronis: maybe because 'try' would fail validation in that case? | 11:30 |
| pedronis | Chipaca: what's special about try? | 11:31 |
| Chipaca | pedronis: used during dev when things are more likely to be broken | 11:31 |
| Chipaca | pedronis: otoh, seems like the best time to error :-) | 11:32 |
| pedronis | Chipaca: ? | 11:32 |
| pedronis | Chipaca: this is about checks for --classic and --devmode , or am I confused ? | 11:32 |
| Chipaca | pedronis: ah sorry i got confused with the static path checker thing | 11:32 |
| Chipaca | pedronis: let me look | 11:32 |
| pedronis | mborzecki: I would keep all the bits | 11:33 |
| mborzecki | pedronis: ack | 11:33 |
| pedronis | for 512 it was indeed a bit overkill | 11:33 |
| seb128 | niemeyer, mvo, mborzecki, in fact https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 already has lengthy details about what n-m is doing (also the review pointed in the recent comment picks on snapd compared to gnome-software/flatpak due to that :/) | 11:33 |
| pedronis | but this already half of that | 11:33 |
| Chipaca | seb128: but our problem isn't afaik what n-m is doing, but that we can't enable it by default until sufficient people have confirmed it does the right thing | 11:34 |
| pedronis | Chipaca: to be clear we are talking validateInfoAndFlags that you introduced a long while ago | 11:34 |
| popey | Chipaca: do we have a test case documented and call for testing? | 11:35 |
| Chipaca | pedronis: I'm going to chalk it down to oversight | 11:36 |
| Chipaca | popey: I don't think we do (I'd like confirmation that this is indeed what's stopping us from making it a default though) | 11:36 |
| pedronis | Chipaca: there are 3 places that could share a helper if InstallPath was also using it | 11:36 |
| === pstolowski is now known as pstolowski|lunch | ||
| pedronis | but maybe something breaks | 11:37 |
| Chipaca | pedronis: which are those? | 11:37 |
| popey | Chipaca: if we had test case and docs I'd be happy to test it | 11:37 |
| pedronis | Chipaca: doUpdate Install and InstallPath itself | 11:37 |
| pedronis | they all do a couple of validate, construct (a now complicated) SnapSetup | 11:37 |
| pedronis | and call doInstall | 11:37 |
| Chipaca | pedronis: is there anything else calling doInstall? | 11:37 |
| pedronis | yes | 11:37 |
| pedronis | Revert I think | 11:38 |
| Chipaca | eh, ok | 11:38 |
| Chipaca | mborzecki: niemeyer: mvo: am I right in thinking we're just waiting for sufficient confirmation that the n-m metered integration work does the right thing in the field, in order to enable it by default? | 11:39 |
| pedronis | Chipaca: maybe I should just try to add it and run push the PR and see what the test says and go from there | 11:40 |
| pedronis | if you don't recall a strong reason why is not there | 11:40 |
| Chipaca | pedronis: +1 | 11:42 |
| Saviq | sergiusens: hey, have you seen snapcraft getting ENOPERM on host's snapcraft .snap before? https://travis-ci.org/CanonicalLtd/multipass/jobs/425154797 | 11:48 |
| Saviq | when building in a build env, that is | 11:48 |
| sergiusens | Saviq: cleanbuild? | 11:48 |
| Saviq | sergiusens: travis, so yeah | 11:49 |
| Saviq | oh I mean, no, not cleanbuild | 11:49 |
| Saviq | =lxd | 11:49 |
| sergiusens | Saviq: yes, same, snapd changed perms on all snaps, you can use beta where we moved to a different model | 11:49 |
| Saviq | ack | 11:49 |
| sergiusens | Saviq: why lxd and not cleanbuild? | 11:49 |
| ogra | does cleanbuuild work in travis ? | 11:50 |
| sergiusens | ogra: of course it does | 11:50 |
| ogra | (i never tried :) ) | 11:50 |
| sergiusens | ogra: https://github.com/snapcore/snapcraft/blob/master/.travis.yml#L70 | 11:51 |
| Saviq | sergiusens: I don't go through the whole build necessarily, depends on the job https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml | 11:51 |
| ogra | oh, wow, travis even supports snaps ? | 11:51 |
| sergiusens | ogra: yeah, we did a PR for their docs ages ago | 11:51 |
| ogra | it definitely didnt when used it last and still had to manually create xenial chroots | 11:51 |
| ogra | (my experience is from a tme where they only offered precise) | 11:52 |
| sergiusens | ogra: https://docs.travis-ci.com/user/installing-dependencies/#installing-snap-packages | 11:52 |
| ogra | extremely cool ! | 11:52 |
| sergiusens | yeah, and they only offer xenial to enterprise users :-) | 11:52 |
| Saviq | but with lxd, who cares! ;P | 11:53 |
| ogra | ah, i thought they switched the default nowadays | 11:53 |
| sergiusens | so the fact that it is slow to get to the masses might be a commercial thing more than a technical one :-) | 11:53 |
| ogra | yeah | 11:53 |
| === pstolowski|lunch is now known as pstolowski | ||
| Saviq | sergiusens: oh and btw, I'm abusing the fact that the build artifacts (stage, basically) ends up in $PWD and that the container is still around after it completes | 13:00 |
| Saviq | I suppose I won't be able to rely on it soon ;P | 13:00 |
| Saviq | sergiusens: if you have a look through our .travis.yml and suggest changes / highlight issues, that'd be great :) | 13:00 |
| sergiusens | Saviq: abuse all you want, but you will have to make up for your crimes :-) | 13:00 |
| ogra | why stage though ? prime feels a bit more natural | 13:01 |
| sergiusens | Saviq: we can certainly do that, btw | 13:01 |
| seb128 | Chipaca, sorry, on a flaky internet in a train ... what info do you need to figure out if the current code "does the right thing"? the post explains the heuristics used by n-m in details which is a good base I would think? | 13:01 |
| ogra | seb128, you need to stay on the train for the next 48h to see if some auto-update kicks in i guess *g* | 13:02 |
| Chipaca | seb128: well, in theory it works; in practice, we don't know | 13:02 |
| ogra | (geez, is it friday soon ?) | 13:02 |
| Saviq | ogra: I think prime is stripped of some test-related things that we need, but we may reevaluate for sure - and maybe amend what we prime for different build types | 13:02 |
| Chipaca | seb128: no amount of reading about what n-m claims to do will tell us whether it breaks in some weird real-world corner case | 13:02 |
| ogra | Saviq, yeah, prime is closest to the actual endresult though ... makes any tests more realistic i suppose (but yeah, stripped for sure) | 13:03 |
| seb128 | Chipaca, it's being used by others (GNOME, flatpak), could that help us to get some confidence? | 13:03 |
| seb128 | Chipaca, and if not what would? | 13:03 |
| seb128 | trying to understand how we can unblock the situation | 13:03 |
| mup | PR snapcraft#2244 opened: snap: add the https transport <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2244> | 13:20 |
| seb128 | Chipaca, sorry, try is making that difficult, I was saying | 13:25 |
| seb128 | Chipaca, well "break" would mean no autorefresh on some connections, if we are afraid that buggy info could lead to system never updating we could force a refresh anyway after $peiod | 13:25 |
| seb128 | Chipaca, users are typically on a metered connection for a limited time, being on the safe side by default and forcing after a longer period would probably save most users to hist a problem | 13:25 |
| seb128 | Chipaca, anyway let me know if we could help giving confidence in that feature by any mean | 13:25 |
| Chipaca | mvo: so do we need to do anything beyond tweaking the config? Is there a public test phase needed still? | 13:58 |
| mvo | Chipaca: a good question | 13:59 |
| pstolowski | mvo: shall i push to a new github branch and we can set up a ppa from that? | 14:04 |
| mvo | pstolowski: yeah, that sounds reasonable | 14:14 |
| mvo | pstolowski: (in a meeting right now (and after this one too) so may be a bit slow replying but you can just use a personal PPA probably) | 14:14 |
| Chipaca | pedronis: snapshotstate is green again if you want to take a last look | 14:15 |
| pstolowski | mvo: right, will try that (haven't touched ppas for >2 years, let's see how it goes ;)) | 14:15 |
| mvo | pstolowski: good luck | 14:19 |
| pedronis | Chipaca: lgtm | 14:30 |
| Chipaca | whee | 14:30 |
| Chipaca | gasp | 14:31 |
| Chipaca | now what | 14:31 |
| mup | PR snapd#5187 closed: overlord: introduce snapshotstate <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5187> | 14:31 |
| pedronis | Chipaca: celebration time :) | 14:32 |
| Chipaca | pedronis: :-) | 14:33 |
| mvo | Chipaca: \o/ | 14:38 |
| mup | PR snapd#5785 opened: tests,interfaces: run interfaces-account-control on UC18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5785> | 14:38 |
| pedronis | mvo: core16 is a base right ? | 15:04 |
| pedronis | like core18 | 15:04 |
| pedronis | nvm checked myself | 15:08 |
| mvo | pedronis: correct | 15:09 |
| mvo | pedronis: (sorry in a meeting so a bit slow) | 15:09 |
| Chipaca | pedronis: snap info tells you :-) | 15:12 |
| pedronis | Chipaca: that's what I did indeed | 15:13 |
| Chipaca | pedronis: :-) | 15:13 |
| Chipaca | pedronis: in state.State's Prune(), writing() is called only if needed. deleteExpiredWarnings was calling writing() unconditionally, when it was a public method. Should I make it smarter? | 15:23 |
| Chipaca | pedronis: should I drop it and move that logic into Prune directly? | 15:23 |
| Chipaca | the latter would be consistent with what's there already | 15:23 |
| pedronis | Chipaca: I'm kind of eoding, yea, all the pruning is in Prune, | 15:24 |
| Chipaca | pedronis: ok | 15:24 |
| Chipaca | pedronis: have a good'un | 15:24 |
| * cachio lunch | 15:28 | |
| Saviq | sergiusens: so here's a new issue with beta... https://travis-ci.org/CanonicalLtd/multipass/jobs/425225732 snapcraft can't find a package... https://launchpad.net/ubuntu/+source/cmake-extras is it looking at the host package list? | 15:32 |
| sergiusens | Saviq: sent a log privately, I have a workaround for that though | 15:36 |
| mup | PR snapcraft#2245 opened: docker: support for testing snapcraft in proposed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2245> | 15:44 |
| Chipaca | niemeyer: #5514 is ready for another look if you're idle (har har har) | 15:56 |
| mup | PR #5514: daemon, overlord/state: warnings pipeline <Created by chipaca> <https://github.com/snapcore/snapd/pull/5514> | 15:56 |
| mvo | zyga: quick brainstorm - I'm renaming idleManager to ecoManager - or do you have a better name. I think it captures the idea behind it better than idle manager as its not about idle but more about nothing to manage | 16:05 |
| zyga | mmm | 16:05 |
| zyga | do you think that ecoManager could do more things (eventually) that fit into resource preservation concept? | 16:06 |
| zyga | like unmounting unused things | 16:06 |
| mvo | or cleaning unused bases | 16:06 |
| zyga | or running aggressive gc once in a while | 16:06 |
| zyga | or something like | 16:06 |
| zyga | janitorManager | 16:06 |
| zyga | (though I think ecoManager is better) | 16:06 |
| zyga | or we could call it "mother" | 16:07 |
| niemeyer | Chipaca: Thanks! | 16:07 |
| niemeyer | mvo: Do we need a manager for that? | 16:07 |
| mvo | sleeper | 16:07 |
| mvo | niemeyer: not strictly but it has some nice properties | 16:07 |
| niemeyer | mvo: It sounds like this is a cross-concern issue | 16:07 |
| mvo | niemeyer: like that it ties use into the ensure loop | 16:07 |
| niemeyer | mvo: Where every manager would have something to say about it | 16:07 |
| mvo | niemeyer: we want the check to run after the ensure loop of the other managers | 16:08 |
| mvo | niemeyer: but I'm open for ideas of course | 16:08 |
| zyga | niemeyer: ohhh | 16:08 |
| zyga | nice idea | 16:08 |
| niemeyer | mvo: It just feels like this is something managers will need a chance to do something about, otherwise we'll have a manager that will be fiddling with resources of other managers | 16:09 |
| zyga | manager.SaveThePlanet | 16:09 |
| zyga | and then a manager could do something in response to that | 16:09 |
| Chipaca | return false | 16:09 |
| mvo | niemeyer: so far the bits we check are: a) number of snaps (snapstate should provide this) b) is it seeded (devicestate) c) minimal amount of time passed d) pending changes e) active daemon connections. plus it should be run after ensure ideally | 16:10 |
| mup | PR snapcraft#2245 closed: docker: support for testing snapcraft in proposed <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2245> | 16:11 |
| niemeyer | mvo: Sounds like something we should run less often than ensure itself | 16:12 |
| mvo | niemeyer: I can sketch out a design that adds something like "CanGoSocketActivated" to the managers (the name sucks, just here as a stawman) and then do the other checks in its own package and/or daemon or overlord. syncing with the ensure loop is the open question in this design. should I create a hook in the overlord for this? where callbacks can be added | 16:12 |
| niemeyer | Hmmm | 16:13 |
| mvo | niemeyer: right, we can run it less often its just a nice property if its in sync with ensure in some way (so maybe not every ensure ) | 16:13 |
| mvo | (but of course it does not have to be in sync if that makes the other design nicer) | 16:14 |
| Chipaca | I wonder if we can do it by niling out managers when they have nothing to do | 16:14 |
| Chipaca | and then if every manager has gone, we go away entirely | 16:14 |
| niemeyer | mvo: The earlier a-d list sounds a bit uneven | 16:15 |
| Chipaca | anyway. I'm going afk for a while, will bbl (going for a run before it rains) | 16:15 |
| niemeyer | mvo: Some of those aren't something that can be in a manager | 16:15 |
| niemeyer | Chipaca: Enjoy! | 16:16 |
| mvo | niemeyer: the active connections is a problem, the other bits fit ok. but again, happy to do it differently | 16:16 |
| niemeyer | mvo: The time passed also feels misplaced | 16:17 |
| mvo | niemeyer: I need to have dinner now but will read scrollback and also ponder about how to do it without a manager | 16:17 |
| niemeyer | mvo: Time passed since what? Feels like this should be in the routine that would attempt to go socket activated | 16:17 |
| niemeyer | mvo: SOunds good.. we can catch up tomorrow morning as well | 16:17 |
| niemeyer | mvo: Have a good one | 16:17 |
| mvo | niemeyer: the time since startup is what is used right now | 16:17 |
| mvo | niemeyer: yeah, tomorrow is also fine, lets see if we can find some nice pattern :) | 16:18 |
| mvo | s/pattern/place/ | 16:18 |
| mvo | niemeyer: thank you! | 16:18 |
| seb128 | back on stable internet! | 16:48 |
| seb128 | Chipaca, sorry for trying to start a conversation on a bumpy internet, that was not a good idea | 16:48 |
| seb128 | Chipaca, anyway might be a good topic for Brussel, if we can help building trust on that feature/stack in some way that would be nice | 16:48 |
| seb128 | users tend to hate bugs that lead to costs (understandably) | 16:49 |
| ackk | hi, is there a way to unset a snap config option (as opposed to set it to "")? | 17:01 |
| zyga | set it to null | 17:01 |
| ackk | zyga, how do you do that? | 17:02 |
| ackk | zyga, you mean set foo=null ? | 17:03 |
| zyga | snap set foo value=null | 17:03 |
| zyga | I think | 17:03 |
| zyga | yes | 17:03 |
| ackk | oh, so that's a special value | 17:03 |
| ackk | I mean, it's not treated as string | 17:03 |
| zyga | no, that's literally null :) | 17:03 |
| zyga | yeah, all input is yaml | 17:03 |
| zyga | I heard | 17:03 |
| zyga | or json | 17:03 |
| zyga | or ... | 17:03 |
| zyga | now I'm confused | 17:03 |
| ackk | zyga, although it will still show in get -d, it won't be "unset" | 17:03 |
| ackk | (that's fine, just wondering if there was a way to actually unset | 17:03 |
| zyga | ah | 17:04 |
| zyga | mmm | 17:04 |
| zyga | maybe there is | 17:04 |
| zyga | hold on | 17:04 |
| zyga | I don't see any | 17:07 |
| zyga | pstolowski: ^ maybe you can clarify | 17:07 |
| cachio | pedronis, hey, I am trying to push a snap to the staging store and I see this error | 17:08 |
| cachio | https://paste.ubuntu.com/p/9dyxZZgkvY/ | 17:08 |
| cachio | do I need to make any change in the test account? | 17:09 |
| pedronis | cachio: are you logged in ? what does snapcraft list-registered says ? | 17:14 |
| cachio | pedronis, it gives the list of snaps for the user | 17:15 |
| pedronis | then not sure | 17:15 |
| pedronis | it's a strange error | 17:15 |
| cachio | pedronis, who could help with that error? | 17:16 |
| cachio | on the store side | 17:16 |
| pedronis | cachio: I would try to login again, is that snap in the list of list-registered you get? | 17:16 |
| cachio | pedronis, ok | 17:16 |
| cachio | pedronis, yes it is | 17:17 |
| pedronis | it's definitely strange, if relogin doesn't help, ping celso maybe | 17:17 |
| cachio | same errror after relogin | 17:19 |
| cachio | I'll ping him | 17:19 |
| pedronis | snapcraft --debug output might help in case | 17:19 |
| pstolowski | zyga: there's no way to unset | 17:20 |
| pstolowski | ackk ^ | 17:21 |
| pstolowski | that's a known issue/limitation | 17:21 |
| cachio | pedronis, is it using the staging store? https://paste.ubuntu.com/p/rFyBk3NTG5/ | 17:27 |
| pedronis | cachio: no | 17:28 |
| pedronis | something is off with your env | 17:28 |
| pedronis | 'url': 'https://dashboard.snapcraft.io/dev/api/snap-push/ | 17:28 |
| pedronis | or there's a bug in snapcraft, not respecting something for different ops | 17:29 |
| pedronis | a *new* bug | 17:29 |
| cachio | pedronis, that could be | 17:30 |
| cachio | thanks for the support | 17:30 |
| pedronis | as I said list-registered showing the snap but push failing is a bit strange | 17:31 |
| cachio | pedronis, I'll check with snapcraft guys | 17:31 |
| pedronis | (though the permission are different for the two ops) | 17:31 |
| cachio | kyrofa, hey | 17:31 |
| cachio | kyrofa, any idea why it could be not poiting to the staging store? | 17:31 |
| cachio | https://paste.ubuntu.com/p/rFyBk3NTG5/ | 17:31 |
| kyrofa | cachio, sudo might have something to do with it-- have you tried without? | 17:39 |
| niemeyer | Chipaca: LGTM! | 17:40 |
| cachio | kyrofa, that was the problem | 17:41 |
| cachio | kyrofa, tx | 17:42 |
| === pstolowski is now known as pstolowski|afk | ||
| pedronis | cachio: ah, sorry I didn't notice that | 18:15 |
| cachio | pedronis, yes, me neither :( | 18:15 |
| ackk | pstolowski|afk, I see, thanks | 18:17 |
| Chipaca | niemeyer: excellent, thank you | 18:44 |
| TorbenLeif | Hello, I am trying to figure out how to make snappy stop updating my VLC installation to any other versions. | 19:33 |
| TorbenLeif | I've read the man file but I don't see a way to stop snap from refreshing a certain app :/ | 19:38 |
| === pbek_ is now known as pbek | ||
| Chipaca | TorbenLeif: you can't, basically | 20:06 |
| Chipaca | TorbenLeif: and you probably shouldn't :-) why are you wanting to not update vlc? | 20:06 |
| TorbenLeif | @Chipaca VLC Media Player, versions past 3.0.1 broke a certain feature I use regularly and so I keep having to force snappy to reinstall vlc_195.snap. | 20:48 |
| TorbenLeif | Unfortunately VLC doesn't release any other packages so I can avoid using Snappy with it, so it sounds like I'm stuck having to do this every day :/ | 20:49 |
| mup | PR snapcraft#2246 opened: packaging: cleanup extension usage in setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2246> | 20:54 |
| Chipaca | TorbenLeif: have you spoken to the devs? they're usually very receptive of that sort of feedback | 21:08 |
| Chipaca | my memory is terrible but I think thresh was working on that at some point? | 21:10 |
| ogra | yep, he is the vlc snap maintainer | 21:10 |
| ogra | Chipaca, i thought if you use snap revert you will not get auto-upgraded til the next release shows up in the store ? | 21:11 |
| ogra | i onder why TorbenLeif has to do that "every day" ... given that feature | 21:12 |
| ogra | *wonder even | 21:13 |
| mup | PR snapcraft#2244 closed: snap: add the https transport <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2244> | 21:27 |
| Chipaca | ogra: I suspect the have the .snap, and install it every day | 21:27 |
| Chipaca | TorbenLeif: what does "snap list --all vlc" print? | 21:27 |
| ogra | yeah ... revert would be a lot better than sideloading the snap file | 21:28 |
| Chipaca | TorbenLeif: as ogra says, if you "snap revert", snapd will not auto-upgrade you to the same revision -- a new revision would get auto-installed, but not the same one every time | 21:28 |
| Chipaca | ogra: revert is probably the least known of what we think of as the main features | 21:28 |
| Chipaca | ogra: it's not really sideloading as they have the assertion :-) | 21:29 |
| ogra | yeah ... but given its beauty it should really get more promotion ;) | 21:29 |
| ogra | ah | 21:29 |
| Chipaca | ogra: ironically if they didn't have the assertion it'd be actual sideloading (i.e. --dangerous) and it wouldn't update | 21:29 |
| ogra | oh, indeed ! | 21:29 |
| mup | PR snapd#5786 opened: tests: update prepare/restore for nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5786> | 21:37 |
| TorbenLeif | @Chipaca vlc 3.0.3-1-3-gf09fd0d 365 stable videolan✓ disabled | 21:42 |
| TorbenLeif | vlc 3.0.4 555 stable videolan✓ disabled | 21:42 |
| TorbenLeif | vlc 3.0.1-4-g14a4897 190 stable videolan✓ - | 21:42 |
| Chipaca | TorbenLeif: and which is the one you want to use? | 21:42 |
| TorbenLeif | 190 is the one I want to use permanently. | 21:42 |
| TorbenLeif | I have it installed now, but tomorrow it'll update again. | 21:42 |
| Chipaca | TorbenLeif: ok, so try this | 21:43 |
| Chipaca | TorbenLeif: first: snap refresh vlc | 21:43 |
| Chipaca | TorbenLeif: that'll leave you with the one you don't want | 21:43 |
| Chipaca | TorbenLeif: next: snap revert vlc --revision=190 | 21:43 |
| Chipaca | TorbenLeif: that'll leave you with the one you do want, and _blacklist the newer one_ | 21:43 |
| Chipaca | TorbenLeif: you can confirm this by doing 'snap refresh' (without explicitly asking for vlc) | 21:44 |
| Chipaca | if you 'snap refresh vlc' you un-blacklist, if I remember correctly (but i could be wrong! and i'm too tired to go look right now) | 21:44 |
| TorbenLeif | This works, but once VLC releases a new version I just have to do this? | 21:45 |
| TorbenLeif | Or is it a perma solution? | 21:45 |
| Chipaca | TorbenLeif: the next different revision that gets pushed to tip of stable will replace the one you want, yes | 21:45 |
| Chipaca | TorbenLeif: in the meantime, _talk to the vlc maintainers_ | 21:45 |
| TorbenLeif | Okay, that is great. Thank you so much for the help Chipaca! | 21:46 |
| Chipaca | TorbenLeif: what is the feature that breaks, by the way? | 21:46 |
| TorbenLeif | Chipaca The capture card displays a weird zoomed in disorted image post 3.0.1 | 21:47 |
| Chipaca | TorbenLeif: that seriously sounds like something they'd want to fix if they knew it was happening | 21:48 |
| TorbenLeif | I am using an AV2USB adapter that works fine on any program as a regular video0 input except VLC post 3.0.1 | 21:48 |
| TorbenLeif | I talked to them but they have a pushy bug reporting process that I don't want to do (it involves signing up on a bug tracker and such). | 21:48 |
| Chipaca | sounds terrible | 21:49 |
| Chipaca | much easier to refresh the snap every day … (?!?) | 21:49 |
| TorbenLeif | It's not bad if you're really into the community, but just as a guy wanting to inform them of a problem they might be interested in knowing about, it's too much work. | 21:49 |
| TorbenLeif | Writing a script to schedule the necessary commands to revert isn't hard now that I know the commands ^^ | 21:50 |
| Chipaca | I now regret having helped | 21:50 |
| TorbenLeif | Because I don't want to take pictures, learn the necessary debugging commands to create the bug report and sign up for a service to do it? | 21:51 |
| TorbenLeif | I gave them the logs they wanted in irc. | 21:52 |
| TorbenLeif | Bah, idc. Thank you for the help anyway. | 21:52 |
| Chipaca | TorbenLeif: because you'd rather spend my time than yours | 21:52 |
| TorbenLeif | Not necessarily true. | 21:53 |
| TorbenLeif | If I made the bug report it isn't fixed, it is reported. | 21:53 |
| mup | PR snapd#5787 opened: tests: update the listing expression to support core from other channels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5787> | 21:53 |
| TorbenLeif | Seeings as I am not a programmer for the project, either way I still need a temporary fix. | 21:53 |
| TorbenLeif | The VLC channel didn't have a solution to temporarily fix the problem, so after a couple hours I decided reverting constantly is the best solution for me. | 21:54 |
| TorbenLeif | I was unsure on how to do that, so I needed help with reverting snap packages. You helped teach me that. | 21:54 |
| TorbenLeif | Even to that effect, I googled for a solution well prior to coming here and read the man page. Unfortunately documentation on snappy is lacking in this regard, and the feature I wanted didn't even exist. So no, I would have much rather found the solution during the time I spent than take up yours. | 21:59 |
| Chipaca | TorbenLeif: I'm sorry the manpage didn't help. Reading the documentation for revert I see it's missing a mention of the blacklisting, indeed | 22:07 |
| Chipaca | sorry for that; i'll address it tomorrow | 22:07 |
| TorbenLeif | No need to apologize for documentation, it's a community project, not a business. Anywho, thanks again and have a good day. | 22:12 |
| mup | PR snapcraft#2247 opened: yaml loading: properly handle unhashable types <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2247> | 22:48 |
| mup | PR snapd#5788 opened: tests: add publisher regex to fix the snap-info test pass on sru <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5788> | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!