[01:43] Hm, would it be an abuse of snap to try to package up libvirtd + qemu + virt-manager with snappy? It can register services with systemctl and run as root, right? [05:34] morning [05:44] morning [06:01] Good morning [06:01] I will be around in a hour, need to get breakfast and take the dog out [06:13] zyga: so the dog is travelling with you too? :) [06:19] zyga, mborzecki: do you guys know if `snap save` is intended to show me all snapshots? I can see way more in /var/lib/snapd/snapshots than in `snap save` [06:19] morphis93417: snap saved? [06:20] ah [06:20] the output looks quite similar === morphis93417 is now known as morphis [06:21] just run into the issue that our CI system ran out of space because of the automatic snapshot creation on remove [06:21] 100GB of snapshots ... [06:21] morphis: i think you want snap remove --purge [06:21] morphis: though it's probably for 2.40 [06:22] is there another way to purge or avoid the automatic snapshot? [06:22] morphis: i don't think so, but pstolowski|afk or Chipaca will know more [06:24] hm, that is unfortunate [06:25] morphis: looked throught the forum, you can set `snap set system snapshots.automatic.retention=no` that should stop snapshots from being created [06:25] mborzecki: looks like it doesn't for the creation on snap removal [06:26] morphis: https://forum.snapcraft.io/t/snapshots/9468 states 'Disabling automatic snapshots will not affect pre-existing automatically generated snapshots, only those generated by the removal of subsequent snaps.' [06:27] yeah read that [06:27] morphis: looks like you need to drop the old ones manually, but new ones should not be created [06:29] mborzecki: yeah, looks like that's it [06:29] Oh jeeze. I get to the end of my package compile and it says linker version 2.3.3 isn't compatible with files in this app. [06:29] I dont want to\cant build this in an ubuntu 16.04 env [06:30] Not possible to move past that, right? [06:30] df00z: can you use a core18 base instead? that should be like 18.04 env [06:31] Ugh maybe but probably not. Building something that needs up to date libs(qemu, libvirt) [06:32] The whole point of me trying to use this was to avoid managing /usr/local or something awful for a custom build [06:32] df00z: it sounds like you've got snapcraft running in legacy mode. Make sure you've got a "base:" key at the top level, set to "core" or "core18" [06:32] let me try it [06:33] that will switch snapcraft over to building in a VM (for which you'll need to install Multipass) with appropriate libraries to match the base [06:34] weird I put base: core18, it worked, didnt try to start any kind of VM that I can see [06:34] I'm on 19.04 [06:35] Unless it only does that with cleanbuild [06:37] Breakfast time [06:37] I will be back around 9-10. Once we pack and hit the road again [06:37] i gotta head to sleep. i think it worked? maybe coincidentally because 19.04 isn't using an incompatible linker? [06:38] df00z: afaik it's built in a clean environment, so perhaps you already have multipass, or it just spun up a lxd container [06:39] long term im probably going to have to build parts for the entire dependency chain...theres gotta be like 50 libs though [06:40] for now i only built gnutls as a part which ubuntu doesnt have an up to date release that is compatible in it's repo [07:08] I will be around shortly === pstolowski|afk is now known as pstolowski [07:20] morning [07:22] pstolowski: hey [07:22] morphis: hi, all clarified re automatic snapshots afaict? old ones need to be removed manually with snap forget [08:24] hi, anyone familiar with non-root users in snap? [08:26] ackk: non root users in snaps with services? [08:27] mborzecki, I mean the work for being able to use system users in the snap [08:28] ackk: there was a PR from jdstrand but I don't know where it stands at this point [08:28] mborzecki, right, I'm testing with a snapd built from there [08:28] re [08:29] finally all packed and on the road [08:29] mborzecki, I'm having a weird issue. I pass in the "daemon" user and I have a dir under $SNAP_COMMON that's owned by it (daemon:daemon). If I try to delete it from the app, it gets permission denied. that's understandable if I run it as root, but it happens also if I drop privileges to daemon:daemon [08:29] mborzecki, so I'm not sure how to handle that [08:29] it's hard to pack three kids and a dog [08:29] mborzecki: yeah, so there was a selinux denial [08:30] mborzecki: question: should a program that is selinux aware actively set the context of a file it creates? [08:30] zyga, is that like the wolf sheep cabbage problem? :) [08:30] ackk: maybe soemthing inside is now owned by daemon? [08:30] mborzecki: or should this be done from the policy side? [08:30] ackk: it's a OMG why did we agree to do this problem :) [08:30] ackk: driving across europe with our family, including a small baby [08:30] zyga: labels are inherited from parent, unless there's an automatic transition defined [08:30] mhm [08:31] mborzecki, not that I can see it, it's all daemon:daemon [08:31] mborzecki: I didn't look yet but I don't quite get it why the new .info file is any different from the exisiting .fstab or .mnt files [08:31] mborzecki: so I'll get to selinux shortly, I'll read your review first [08:37] zyga: also to spain? [08:37] Chipaca: yeah, we are approaching the coast now, south of france [08:37] from there just a short ride to Palamsos [08:37] Palamos [08:38] zyga: Palimpsest [08:39] Chipaca: looking at the car nav, seeing the destination being 4 hours away is surreal [08:39] Chipaca: normally I would say that is far away [08:40] Chipaca: but after the last few days that's nearly nothing and 4 hour trip is short and easy in comparison [08:41] zyga: I know that feeling [08:41] I remember getting up one morning, thinking "yeah, this morning we'll go get fuel, that's just … 3 hours south of here, we should make it back in time for tea, easy [08:41] " [08:42] *fuel*? [08:42] as in gasoline? [08:43] zyga: yes [08:44] zyga: we were in San Antonio Oeste, and the fuel on the other side of parallel 42 was 50% cheaper [08:44] or maybe more? don't remember exactly. Cheap enough to make it a no-brainer. [08:44] then the next day we did the trip again, this time to see seals and penguins and whales and stuff [08:44] wow, that's quite the story [08:45] zyga: patagonia resets your near/far scale in less than 24 hours :) [08:45] it's humbling and fantastic and awesome and stuff [08:46] (to be clear: argentine patagonia, which is mostly an arid peneplain of nothing but stout shrubs [08:46] ) [08:46] passing some nuclear plant in france now [08:46] kids watched chernobyl a little [08:47] at first they way "is it real" [08:47] but now they just watch [08:47] zyga: is that the one where radiation sickness is contagious? [08:48] a-choo [08:49] lavender fields [08:50] #7028 and #7027 are simple enough and need a second review [08:50] (and if you've looked at the user agent pr you've already looked at these) [08:51] I'll look [08:51] ah great [08:51] that split out is nice and simple [08:52] yeah [08:52] kudos to james [09:03] pstolowski: one for you: https://forum.snapcraft.io/t/does-snap-refresh-trigger-the-disconnect-connect-hooks/11997?u=chipaca [09:04] Chipaca: ok [09:05] mborzecki, I have a minimal python script+snap which reproduces the issue. it seems it happens if I have subdirs of that dir, also owned by daemon:daemon [09:06] mborzecki, https://paste.ubuntu.com/p/kw8swvZS2m/ [09:06] mborzecki, both that and with the last commented line in place of the plain os.rmtree fail [09:07] Chipaca: I left a review on the systemd PR that is more complex than my initial reaction [09:07] https://github.com/snapcore/snapd/pull/7028#pullrequestreview-253865824 [09:07] IMO it is okay to merge but perhaps it'd be worth to look [09:07] ok, next one [09:09] Chipaca: do you know why we do this: https://github.com/snapcore/snapd/pull/7027/files#diff-98811fc63f73eed00da99c36c7326aabR72 ? [09:10] zyga: why would we pass true? [09:11] I don't understand why we'd pass either [09:11] do we need those after? [09:11] why is it relevant to not unset those variables? [09:11] zyga: the API call needs one or the other [09:11] I mean, it takes a boolean [09:11] choose one [09:12] it's a silly thing, just calls Unsetenv on the appropriate environment variables if it's true [09:12] which means you can't grab the sockets again [09:12] aha [09:12] and we want to have them again? [09:12] in tests, sure [09:13] outside of tests, no -- but we don't [09:13] ok [09:15] zyga: otoh if the environ leaks to anything we exec we might want to clear it [09:15] zyga: nothing is breaking today :-) [09:16] Chipaca: how about this? https://github.com/snapcore/snapd/pull/7027/files#diff-98811fc63f73eed00da99c36c7326aabR56 [09:16] why 111? [09:17] zyga: given that 7028 is green, can we land it without the --no-block in the panic? [09:17] yep [09:17] https://github.com/snapcore/snapd/pull/7027#pullrequestreview-253874672 is +1 [09:18] so both can land [09:19] ackk: maybe apparmor blocking this? nothing apparmor related in dmesg? [09:19] zyga: because we want the socket to be 0666 [09:20] zyga: without having to chmod it after the fact [09:23] at some point we're going to have to use dynamic loading or something, to keep the snap command in check :-) [09:23] a bit like git foo → git-foo [09:23] especially for the long-running versions of things [09:23] why? [09:24] to keep them small? [09:25] zyga: yeah [09:26] zyga: having along-running snap command that has all the libs the snap command itself has seems strange [09:26] I wish go had a dynamlically linked "libc-of-go" [09:26] so that hello world was small [09:26] eh [09:27] mborzecki, I only get this error: https://paste.ubuntu.com/p/yX5N6xxRrj/ [09:27] zyga: that should be doable, but i doubt it'd gain traction with the devs [09:27] ackk: looks like regular permissions are the problem [09:27] even simple dynamic loading is under-supported [09:28] zyga, wdym? [09:28] ackk: you get a denial for cap override [09:28] er [09:28] dac override [09:28] zyga, should I add that plug? [09:29] seems weird [09:29] ackk: that happens when acting as root on stuff that you wouldn't have access to given its permission bits & owner [09:30] ackk: I doubt so [09:30] (I would not add that plug) [09:30] ackk: what mborzecki said [09:30] one sec, trying now to remove as daemon user [09:30] the only reason root can access stuff it normally cannot access is because it has DAC override capability [09:30] but the profiles take that away [09:31] zyga, mborzecki I get the same error if I try to remove as daemon user [09:31] (iow after dropping privileges) [09:34] feeling a bit sick from looking at the screen [09:34] mborzecki: you were right [09:34] buth, only three hours left [09:35] so close now [09:35] zyga: hm? [09:35] mborzecki: looking down while moving [09:35] zyga: ah yeah ;) [09:37] so the image tool is using sfdisk now, though the script syntax is kind of ugly [09:41] ackk: apparmor denial this time too? [09:41] mborzecki, same [09:47] zyga: if it makes you sick, then STOP DOING IT [09:47] * Chipaca whacks zyga over the head with some large mythological fish [09:48] Chipaca: yeah, I try to look outside the window as much as I can [09:49] Chipaca: 3 hours 14 minutes left [09:49] popey: you around? [09:49] we'll break after passing montpellier but now lucy is sleeping so as much as we can push it [09:49] mborzecki, ah, it only works if the directory containing the one to delete is 0777 [09:49] Chipaca: for you, always [09:49] mborzecki, which poses a problem because I can't really change $SNAP_COMMON to be 777 [09:49] popey: Wimpress: any way i should tag https://forum.snapcraft.io/t/getting-taskade-linux-app-featured/12005?u=chipaca so you guys are sure to notice it? [09:49] popey: <3 [09:50] i have seen it :) [09:50] popey: right, but if you hadn't? [09:50] (thanks for confirming) [09:51] we don't have an advocacy-requests category :-) [09:53] ackk: it shouldn't happen for test-dir/sub though [09:53] mborzecki, wdym? [09:53] mborzecki, if I os.chmod('test-dir', 0o777), then test-dir/sub can be removed, but to remove test-dir I'd need to chmod $SNAP_COMMON [09:53] ackk: i see you're using shutil.rmtree(test_dir), if you do shutil.rmtree(sub_dir) it should work [09:53] i thought we had a snap-advocacy group [09:54] mborzecki, well, yes and no. in the real case that's a large tree of files/dir, I'd have to recursively chmod everything [09:54] ackk: ah, ok [09:54] oh, we do @advocacy is us [09:54] mborzecki, also I'd have to remove everything inside the dir manually if I can't remove the whole dir [09:54] popey: so i should just say "yo @advocacy"? [09:55] mborzecki, in general, that's a problem, if you can create dirs and you can't remove them :) [10:04] Chipaca: ya, i think that would work [10:04] popey: k [10:11] less than 3 hours left [10:28] Break time [10:28] zyga: https://www.youtube.com/watch?v=otCpCn0l4Wo [10:29] and it's ubuntu one all over again [10:29] * Chipaca takes a break also [10:31] * Chipaca lied [11:02] now yes, i'm off for a bit [11:17] hello I would like to create a script that will release all stable versions of my software for all platforms (eg. set them to current head / latest build) [11:17] how would I do that? [11:17] if I know specific number I can do something like snapcraft release huggle 2146 stable [11:18] but can I substitute the number 2146 with "whatever is latest"? [11:18] petan: i have a vague recollection of version script that can do that [11:19] petan: this is how snapd does that https://github.com/snapcore/snapd/blob/master/snapcraft.yaml#L11-L12 [11:26] fun review if anyone's interested: https://github.com/snapcore/snapd/pull/7030 [11:27] zyga: do you want me to look into the selinux denials you got? [11:28] mborzecki: if you know how to fix that quickly, sure, it will help a lot [11:28] Break is over, back to work [11:36] * zyga melts in the sun [11:43] pstolowski: what was the problem that triggered https://github.com/snapcore/snapd/pull/7029 ? [11:45] How come this exists: https://snapcraft.io/sublime-text-bartixxx ? It makes the store confusing. [11:53] Gargoyle: indeed, I think it should be removed, perhaps popey has an opinion? [11:54] mborzecki: some kind of udev event is too big, i haven't seen this myself, i asked abeato for udevadm monitor output when this happens [11:54] pstolowski: was there a forum topic perhaps? [11:56] mborzecki: no, it was all discussed here and the bug report is the record of it [11:57] mborzecki: fwtw, $ getconf PAGE_SIZE [11:57] 4096 [11:57] that's the value we effectively used [11:58] pstolowski: right, but it was increased in the loop with MSG_PEEK until the messag would fit [11:58] mborzecki: but the logic was bogus imho [11:59] mborzecki: mborzecki MSG_PEEK - This flag causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data. [11:59] pstolowski, mborzecki I've seen this happening on boot, when a lot of udev events accumulate [11:59] mborzecki: question [11:59] mborzecki: should I switch to error handler (as opposed to die) [12:00] mborzecki: so that I can write tests that don't have to fork to work? [12:00] mborzecki: gtest is pretty frustrating when you have to test code that die's at all errors [12:00] mborzecki: there is no mention for using it to probe buffer size; to my understanding it simply leaves the data in the queue but still errors out if buffer is too small, no? [12:00] pstolowski: yes, that's the point of MSG_PEEK :) [12:00] pstolowski, one interesting thing to note is that what systemd does is increasing the socket RECV size to 128MB - in general that is fine as you are only reseving a range virtual addresses in the end. Usually you do not use all [12:03] pstolowski: abeato: fwiw their actual buffer to which they receive stuff is 8k only [12:04] mborzecki, right, as long as they have buffer space in the kernel side, that's fine - probably there is not a single event thas is 8K [12:05] abeato: yup, so they use super careful 128MB on the kernel side, where events get buffered (althouhg never reach this size), while the usespace reads 8k at a time [12:06] mborzecki, that seems to be the case, yes [12:06] zyga: sounds like a store question === ricab is now known as ricab|lunch [12:17] ackk: I'm here if you want to talk about the daemon user. note there are a bunch of things at play here for file access: apparmor, seccomp, capabilities, traditional permissions [12:17] jdstrand, hi, so did you see the discussion from this morning? [12:18] jdstrand, basically for now I've worked it around by removing everything in the dir manually [12:18] ackk: so, if you create a directory, and chown it to daemon:daemon then the daemon user can use it, etc. *but* it can't delete the directory if the parent dir is say, 755 root:root and root can't delete the dir because it lacks dac_override [12:19] ackk: I intentionally left out dac_override since it grants way too much and the snap can be written to not need it [12:20] jdstrand, mhm so is there a way to go around it without having to manually clean dirs? [12:20] ackk: you probably want to create the directory 775 root:daemon [12:20] jdstrand, ah, interesting [12:20] jdstrand, we have some dirs that are the other way, daemon:root 775 [12:21] ackk: that may work too. the files should be 664 as well if you want root to be able to clean them out [12:22] jdstrand, mhm, the problem is that we're talking about the postgres DATA_DIR, so I only create the root, then postgres (which runs as daemon.daemon) does the rest [12:22] mborzecki: did you see my question earlier [12:22] mborzecki: I'm unsure how to test this, I'm eager to proceed with error return and easy tests [12:22] mborzecki: and die in the caller [12:23] zyga: sounds ok to me [12:23] k [12:27] ackk: well, set it up however. I'm just saying you'll have the same issues with files if they are daemon:daemon and root tries to delete them because of how apparmor works [12:27] jdstrand, sigh also even if I set the dir to 775 postgres changes it back to 700 :( [12:37] ackk: ok, you should be able to work through the without patching anything [12:38] ackk: you create $SNAP_DATA/stuff root:daemon 770. then you create $SNAP_DATA/stuff/postgresdb 700 daemon:daemon [12:39] ackk: then postgres, running as 'daemon' can do whatever it wants in $SNAP_DATA/stuff/postgresdb [12:39] ackk: if for some reason you want to clean things out, daemon is able to delete $SNAP_DATA/stuff/postgresdb and below, and root can delete $SNAP_DATA/stuff [12:44] jdstrand, ah I see [12:49] ackk: with a bit of care, dac_override can pretty much always be avoided and when it is avoided, you know that the code got its priv separation right. in your case, postgres is doing fine and you're just wrapping it so it works, but I recall dhcpd having trouble getting this right in their code [12:50] ackk: where we have a profile for it. the deb packaging set up the dirs wrong assuming dhcpd would just clean things up when it started as root before it dropped [12:51] ackk: but then it didn't do that correctly for several releases (and it was funny cause you could see them trying because the behavior changed with each release), until finally they did [12:52] everything aligned and dac_override wasn't needed any more [12:54] (the same generally goes for dac_read_search) [12:56] ackk: thanks for bringing this up btw. I've added a todo to document this when documenting the feature (it is in the policy, but who reads that? ;) [12:56] jdstrand, thank you for the help [12:59] ackk: np [13:01] cachio: standup? [13:11] jdstrand, so it seems the only caveat is that if you create directories that are owned by a non root user directly under SNAP_DATA/SNAP_COMMON/etc you can't ever remove them anymore [13:12] ackk: that is possible, yes, but snap remove always can [13:13] which is why I want to document it [13:14] one could also plugs log-observe, but when people ask for auto-connection, it'll come up and we can direct them ("why does postgres need access to the system logs?") [13:14] jdstrand, yeah I meant from the point of view of a snap [13:15] jdstrand, log-observe doesn't make it work though [13:15] at least, in my test this morning [13:15] or, uhm [13:15] maybe I didn't test it right [13:16] jdstrand, btw, I filed a few bugs related to the confined snap work, any chance they could get fixed soon: https://bugs.launchpad.net/snapd/+bugs?field.tag=maas ? [13:17] the first two are known. I can look at the last two. I have a PR up that I can fold those into [13:19] jdstrand, awesome, thanks! [13:21] zyga: when you arrive somewhere stable, there are weird things in the forum i'd like you to look at [13:22] Ok [13:22] zyga: i've flagged you in them so i/you/we don't forget :-) [13:23] Perfect, thank you [13:26] * pstolowski lunch === ricab|lunch is now known as ricab [13:29] zyga: ok, so figured out some of the tmpfs stuff, i don't think we can plug it nicely now, but otoh it's probably ok to allow s-c readlink there [13:30] zyga: still don't see how the changes trigger this behavior [13:39] cachio: how's validation of 2.39.3 going? [13:39] mborzecki: right? [13:39] mborzecki: it's another file [13:39] mborzecki: we have a few of those already [13:40] mborzecki: maybe it is because when snap-confine calls snap-update-ns some things magically change? [13:40] mborzecki: snap-confine no longer writes to that tmpfs, apart from making an empty file [13:40] mborzecki: once we have snap-bootstrap-ns this can move there (to go) [13:40] zyga: something funny is going on behind the scenes, tmpfs gets a tmpfs_t label, unless there's some transition, what happens is that a bunch of directories is labeled as tmpfs_t and maybe that's a problem [13:42] zyga: take a look at this: https://paste.ubuntu.com/p/Hmkrs3Yhxp/ [13:42] zyga: see how /etc and /run are tmpfs_t in mount ns of the snap? [13:42] mborzecki: what should that directory type be? [13:42] mborzecki: the hierarchy in /run/snapd/ns is managed by snap-confine [13:43] Chipaca, I am reviewing the last log for i386 [13:43] cachio: cool cool [13:43] and it should go to candidate [13:43] zyga: etc_t or var_run_t for /run [13:43] etc_t for /etc ofc [13:43] cachio: let me know when/if it's done so I can poke people about it please [13:43] Chipaca, sure [13:43] I am trying to reproduce an issue [13:44] zyga: i think it's an artifact of us setting up the mount ns, perhaps we should restore the labels (?) the auto transition doesn't work bc it's named or otherwise [13:44] mborzecki: so we don't mount a tmpfs ourselves there [13:44] mborzecki: but we do make a bind mount in /run/snapd/ns [13:45] mborzecki: and change the propagation mode of that mount [13:45] mborzecki: once I'm at home I will boot fedora and explore [13:45] mborzecki: I only have ubuntu on the go [13:46] zyga: we already allow s-u-n to poke tmpfs_t, so I'll push a patch that allows s-c to your branch [13:46] thanks! [13:46] I'm adding tests now [13:46] zyga: and we can investigate later, as i suspect it'll take more work [13:47] yeah, I think so [13:53] popey: do we know any kde devs that hang around the forum? https://forum.snapcraft.io/t/bug-on-web-page-https-forum-snapcraft-io/12013?u=chipaca [13:55] Chipaca: sitter is on the forum. [13:56] popey: ta [13:57] * Chipaca tagged them in the post [13:57] * Chipaca goes to get a cuppa tea, and maybe some cake [13:58] zyga: this is what ends up with tmpfs_t label https://paste.ubuntu.com/p/fvnh98t27k/ [13:59] zyga: oh and pushed a patch to your branch, please fetch before pushing [13:59] mborzecki: looking [13:59] mborzecki: sure, no force push! [13:59] hey folks, I'm trying to seed a classic image with a gadget snap and not use a brand store, but on boot/seeding snapd seems to think it needs to get a serial from the public store: https://pastebin.canonical.com/p/fCpRXvDcbV/ [14:00] snapd seems to work fine otherwise, I can install snaps and such and even login with `snap login`, but I'm just wondering if there's a way to turn off this behavior where it tries to get a serial [14:01] ijohnson: I think that is unsupported [14:01] you must use a vault to use a custom gadget [14:02] ijohnson: it will go to the store to get a serial [14:02] zyga: hmm that's not great [14:02] ijohnson: but the public store only gives serials to canonical models [14:03] ijohnson: it is part of the design, it is unreasonable for one brand to sign serials of another [14:03] zyga: the use case here is building a local gadget snap that exposes slots so that we can use a strictly defined snap with gpio pins and such [14:03] right that's fine I don't want it to get a serial [14:03] ijohnson: everybody gets a serial tho [14:03] ijohnson: that's a separate concern [14:03] ijohnson: serial assertion is a part of the flow [14:03] you will hit other issues this way [14:04] hmm so what would your recommendation be for getting slots and auto-connection rules via a gadget on a classic image that is not connected to a brand store? [14:04] how necessary is it that everyone gets a serial? [14:04] ijohnson: don't do that? [14:04] ijohnson: very [14:04] :-( [14:04] ijohnson: what is the motivation for slots and gadgets on classic? [14:04] ijohnson: can you tell us more about that [14:05] i must admit that i have never seen any issues caused by missing serials on my dev images [14:05] * cachio afk [14:05] to use a strictly confined snap that needs to use gpio ports [14:05] ijohnson: can we make gpio hot-pluggable [14:05] so that you don't need classic gadgets at all [14:05] zyga, gpio, i2c, spi all come from the gadget, not core [14:05] ogra: I know, but now we have a better method for at least some of those [14:05] we convince folks to make their device snaps strict, then we don't provide a way to use those snaps on classic without a gadget [14:06] if hotplug works for that that would indeed be awesome [14:06] ogra: the basics work, it is now per-interface to expand them [14:06] mborzecki: 'basename', one word, is already a unix command [14:06] mborzecki: we have things that are bases [14:06] mborzecki: 'base name', therefore, would be the name of the base [14:06] --base-name=core18 [14:06] mborzecki: probably not what we want [14:07] zyga: I think hotplug gpio is orthogonal to this [14:07] zyga: my larger concern is about how we can get folks to use these strict device specific snaps without telling they always need to be on core or have a brand store [14:07] ijohnson: I disagree, [14:07] ijohnson: classic gadgets are well defined [14:07] Chipaca: right, sounds fishy when you put it like this, Basename like you had it is probably ok then [14:07] ijohnson: use of gadgets for slots is a special case [14:07] because we lacked hotplug support [14:08] but gpio ports aren't fundamentally "hotpluggable" so it seems confusing to me [14:08] mborzecki: to be fair I'd already written a comment agreeing with you when it struck me :-) [14:08] Chipaca: hahah ;) [14:09] * zyga just crossed the border [14:09] finally not roaming anymore :) [14:09] wooot [14:09] ijohnson: sorry, lost some messages [14:09] ijohnson: hotplug is the confusing word [14:09] ijohnson: the real meaning is dynamically discovered vs statically declared [14:10] ijohnson: we got away with many slots being statically declared because they were not representing specific hardware but certain concepts [14:10] roadmr: hi! can you pull 20190625-1410UTC ? [14:10] jdstrand: hello :) sure [14:10] ijohnson: GPIO pins are not like that, they are hardware and you can actually discover them (even by reading dbts) [14:11] ijohnson: so now that snapd has a method of dynamically adding and removing slots that represent hardware [14:11] ijohnson: we should strive to make more hardware compatible with that system [14:11] zyga: hmm so that all makes sense is the plan to make all device interfaces (i2c, gpio, etc.) dynamically discoverable then? [14:11] ijohnson: I think so [14:11] ijohnson: to the extent that is feasable [14:12] ijohnson: primarily because linux already handles that [14:12] ijohnson: it handles the custom ways to convey what the hardware is [14:12] ijohnson: so that userspace doesn't have to worry and do it again [14:13] right that's great but what to do in the meantime until that's done? [14:13] ijohnson: fix it, walk towards the solution [14:13] whistle and pretend it is already there ? [14:13] ijohnson: would be worth checking how hard it is to handle gpio's this way [14:14] ... so on a sacle from my device will start on fire to some failed changes in `snap changes` for the first 2 weeks that a device is running, just how bad of an idea is it to not have a serial [14:14] ijohnson: pstolowski can offer suggestions I'm sure [14:15]