[02:38] PR snapd#5222 opened: tests: adding fedora-28 to spread.yaml === chihchun_afk is now known as chihchun === pbek_ is now known as pbek [05:07] morning [05:43] PR snapd#5220 closed: tests: moving test helpers from sh to bash [05:44] PR snapd#5218 closed: many: expose AppStream IDs (AKA common ID) (2.33) [06:14] mwhudson: hey, how does console-conf configures the network? I tried to use it on the WIP core18 images and it seems to be unable to configure the network here [06:15] mwhudson: I will try to get access to the debug logs now [06:15] mvo: morning [06:15] hey mborzecki [06:16] mwhudson: one problem might be that there is (currently) no ifconfig, just the new "ip" on core [06:25] mwhudson: fwiw, netplan itself seems to work (if I add a config manually it generates/applies that) === chihchun is now known as chihchun_afk [06:36] good morning [06:37] diddledan: thank you, I will respond [06:37] :-) [06:39] zyga: hey [06:42] :-) === chihchun_afk is now known as chihchun [06:44] hey zyga [06:45] niemeyer: could you please also add github.com/snapcore/pc-{i386,amd64}-gadget to the repors that mup monitors and announces here in the channel? [06:50] diddledan: replied now [06:56] PR snapd#5223 opened: image: set model.DisplayName() in bootenv as "snap_menuentry" [07:11] hmm [07:12] udisks2 is not implicit on classic [07:12] pstolowski|afk: is this intended? AFAIK it was implicit before [07:12] * zyga checks logs === pstolowski|afk is now known as pstolowski [07:16] morning [07:16] I don't think we changed anything about that directly [07:16] zyga: as pedronis says [07:17] are we missing some call to addImplicitSlots ? [07:17] no, it's just not marked as implicit [07:17] and the code is not ready for it yet [07:18] I assumed it was implicit on classic because it's such an old interface [07:18] but now I recall it came to be for IOT first [07:18] afaict we added it for core [07:18] not classic [07:18] *afaicr [07:19] yes, that's correct [07:23] zyga: that tar exclude pattern is wrong too [07:46] pushed a fix to sergio's PR, we should be able to merge it when the build is green [07:48] need to make a quick run to the tax office, bb in ~1h or so [08:08] * zyga -> coffee [08:08] mvo: can you do one thing for me, open a terminal and run this [08:08] autopkgtest-buildvm-ubuntu-cloud --verbose -r bionic -a amd64 [08:08] and let me know if this ever finishes for you [08:10] zyga: what version of autopkgtest do you have installed? [08:12] 5.0.2 [08:17] zyga: I have 5.3 and the command works for me - but I'm on bionic. at what release are you? [08:37] re === chihchun is now known as chihchun_afk [08:52] mornin' all [08:52] hey Chipaca ! [08:52] pstolowski! [08:52] how's things [08:53] it's too hot [08:53] and it's only May [08:54] pstolowski: "it's only May" seems to be what a lot of people in the UK think [08:54] anyhoo [08:54] haha [08:55] pstolowski: it was really hot yesterday (with almost-proper thunderstorms and everything!) but today there's a nice cool breeze [09:06] Chipaca: so after May comes thunder? [09:06] ;-) [09:06] hey, how are you doing? [09:07] zyga: not bad, you? [09:07] Thunder sounds like a fitting name for someone from EDL [09:08] Chipaca: dizzy a bit [09:08] zyga: you pregnant? [09:08] that'd be new :) [09:17] pedronis: updated #5215 [09:17] PR #5215: ifacestate: improved error handling when creating autoconnect tasks [09:18] pstolowski: I'll look in a bit [09:39] mvo: will core18 ship systemd in the snap too? [09:49] mborzecki: yes [09:49] although … we could ship two core18s [09:49] one for classic, with no systemd nor ssh nor nothing [09:50] one for classicn't [09:50] * Chipaca hides from the wrath of both grammarians and mvoians [09:51] PR snapd#5224 opened: interfaces: remove Plug/Slot types [09:53] Chipaca: fwiw that's ~9-12MB (uncompressed) for just systemd [09:54] it's probably not worth it [09:54] i mean, given it's classic, bandwidth saving is probably the bigger thing, and it doesn't look like much [09:55] it's one photo [09:57] Chipaca: it's interesting given the relative popularity of core18 for booting vs not booting [09:57] PR snapd#5214 closed: cmd/snap: check with snapd for unknown sections [09:57] we should add two new snap types: boot, and jigsaw [09:58] jigsaw [09:59] well, nobody complained so far so maybe it's not worth it indeed [09:59] Chipaca: two cores is interessting, the one for classic would be ~28MB, the one for core18 is ~42mb or so currently [10:00] mvo: why that much smaller? [10:00] mvo: that's the *.snap size or du inside? [10:00] it's very confusing in terms of building, in theory you can build an app for both [10:00] would always build only against the one for classic? [10:00] Chipaca: systemd+ssh+netplan+console-conf [10:01] Chipaca: but mostly netplan/console-conf which pull in most of python3 [10:01] mborzecki: outside [10:01] mvo: no, i mean, current core is 87MB [10:01] mvo: also apparmor userspace [10:01] then you convert one into the other when consider base? [10:01] mvo: that's also python3 [10:01] pedronis: if we want to explore this, having a boot type might make more sense, exactly for those reasons [10:01] Chipaca: aggressive cleanup, not sure if we can keep it this way, no vi, no ifconfig (just ip) no "less" etc [10:02] mvo: there's always classic for that [10:02] we should also think what classic does on 18 [10:02] mvo: also no desktop helper afaics [10:02] Chipaca: yeah, thats a bug we should fix soon, those are small [10:02] :-) [10:02] * mvo thinks [10:03] ironically slim core18 would be a very nice addition to embedded systems running classic distros [10:03] mvo: https://forum.snapcraft.io/t/using-xdg-open-with-core18/5620?u=chipaca fwiw [10:03] as the size increase is really small [10:03] why do you care for uncompressed ? (after all it will never be used uncompressed on any disk) [10:04] ogra_: i don't think we do :-) [10:04] ogra_: but it's worth asking, just to make sure we're talking about the same thing [10:04] Chipaca, mborzecki mentioned uncompressed sizes above ... [10:04] otherwise chinese whispers grows [10:05] ogra_: ah, that's just mborzecki being lazy :-p [10:05] * Chipaca continues hiding [10:05] haha [10:05] Chipaca: my fear it adds complexity and surprises, not sure we are ready to deal with them [10:05] also on the developer/user side [10:05] pedronis: agreed [10:05] pedronis: I agree about that, perhaps it's something to slowly prepare post 18-boot ( [10:05] still, it does seem like nearly double the size [10:06] (if we slowly march towards that for 20 I would be more comfortable) [10:06] so worth considering (as in, writing down the reasons so we can explain to others / our future selves) [10:06] yea, it seems better as a goal for 20 [10:06] than to cram it in now [10:06] so many open questions already, and this double some of them [10:06] if 20 is out embedded systems might not care for an extra 10-20MB on disk anymore :) [10:07] there's one more point of view, it doesn't need to be that more complex, it's just that on 18-boot we keep what we have and rely on it and on 18-non-boot we can start to remove it over time (again, for 20) [10:07] nothing to do, win ;) [10:07] I mean that on more complex boot case we don't change anything at all [10:07] so that's a win indeed :) [10:07] ogra_: that's true [10:07] that case is more complex [10:07] (finding MMCs below 2GB is already hard today ... ad will actually cost you extra) [10:07] the non boot case is really something we could explore without much risk [10:07] *and [10:08] ogra_: (note that this doesn't shrink the MMC embedded case at all) [10:08] this is just for making desktop users happier [10:08] zyga: not quite because it's also a base, if everbody builds against the full one [10:08] you cannot change it [10:08] pedronis: mmmm, indeed [10:08] as in remove stuff [10:08] I take that back then [10:08] because people would have to absolutely build against the stripped down version [10:08] for this to work [10:08] yea, that's the tricky bit [10:08] we might explore a 19 base [10:08] with this property [10:08] that makes it hard to pull off [10:08] to cook it for 20 [10:09] while everything is in flux [10:09] I mean, we could always do magic and replace core18 with core18-classic on classic [10:09] down the road [10:09] a new base, 19, without any boot support [10:09] if we needed to [10:09] Chipaca: yes [10:09] mvo: Ack, will do [10:09] we would have to ensure that the ABI of core18 is also provided by core18-boot but I agree it should not be a 18 goal, its already quite some work ahead as it is [10:11] * zyga likes the core19 as an experiment [10:11] niemeyer: good morning! [10:11] but needs to be supported as short as 19.x ubuntu [10:11] call it core20 from the start and just iterate ;) [10:11] niemeyer: i could use a bit of bikeshed paint on 'refresh.keep-inactive' [10:11] ogra_: I don't think that's good, it may not be compatible with 20 [10:12] ten call it core-experimental ;) [10:12] +then [10:12] so, even cores stable, odd cores devel [10:12] * Chipaca should stop putting crazy ideas out lest they continue to be taken seriously [10:13] Chipaca: Hey, good morning [10:13] * ogra_ quickly writes a softpedia article about Chipaca's masterplan of odd/even cores [10:13] Chipaca: Sure, happy to bring my paint :) [10:13] Chipaca: Is there a PR up already? [10:13] niemeyer: https://github.com/snapcore/snapd/pull/5207 [10:13] PR #5207: overlord/{config,snap}state: the number of inactive revisions is config [10:14] niemeyer: i have it deconflicted and with tests locally, hoping to have a definitive name to rename things and do a single push [10:14] actually still missing some tests though [10:14] * Chipaca gets back to work [10:14] mvo, is there a chance that with core18 the pi config options can be moved out of core ? its so displaced there :/ [10:15] mvo: btw I plan to do a proper review of #5217 today [10:15] PR #5217: asserts,image: add support for models with bases [10:15] Chipaca: Thanks, looking [10:15] pedronis: \o/ [10:16] ogra_: well we support calling those config "system" as well now [10:16] ogra_: we have an alias for those now: system [10:16] heh :) snap [10:16] because of the bases stuff, but still no final plan [10:16] about the internals [10:17] ogra_: whats your concern? where the code lifes? or the config schema (core.pi2-foo)? [10:21] mvo, that you have them on *every* UbuntuCore ... they should live in the gadget... it just makes me itch inside every time i think about it [10:24] core should be generic IMHO ... i always thought of the "pi config options in core" as an interim solution [10:24] and the swith to 18 seems like a natural moment to move that around to the correct place [10:29] * zyga needs to, perhaps, redesign a small fragment of snap-update-ns path handling [10:29] pen & paper time [10:30] Chipaca: Reviewed [10:30] 'ppreciated [11:05] ogra_: the issue at the time was that we would have needed some mechanism for snapd to filter what can be set or not, just letting the gadget write the file was deemed too unsafe [11:06] pedronis, yeah, i reemember why we are where we are, it would just be nice to move out of that situation eventually and moving to a new core fells like the natural time to do so [11:07] *feels [11:08] (and i'm aware that it moved out of core into snapd at some point ... which i find even worse) [11:09] niemeyer: do you have any opinions on the the interface naming in this PR? https://github.com/snapcore/snapd/pull/5184#discussion_r190942503 [11:09] PR #5184: interfaces: add desktop-{contacts,calendar}-service interfaces [11:10] jamesh: hey! [11:10] hi zyga [11:10] jamesh: there was a user a while ago asking about how to use the snap with common themes [11:10] is there anything I could relay him to? [11:12] zyga: there's a published gtk-common-themes snap now (hopefully with the store allowing autoconnect soon), but at the moment it relies on adding a bunch of boilerplate to application snaps in order to use it [11:13] right, is there anything that explains that and how to use it [11:13] I don't think we've got any docs on what that boilerplate should look like yet [11:14] jamesh: Looking [11:15] zyga: gtk3-demo-snapcraft.yaml in https://gist.github.com/jhenstridge/7c1518dfb264014e28558fd03a1ed68a is close to what's needed (it doesn't have the default-provider listed though) [11:15] niemeyer: thanks! [11:15] jamesh: excellent, thank you! [11:17] where are we documenting config options? [11:17] things like refresh.hold etc [11:17] Chipaca: https://forum.snapcraft.io/t/system-options/87 [11:18] mvo, hey [11:20] jamesh: np, and thanks for the PR.. commented there [11:21] PR snapd#5207 closed: overlord/{config,snap}state: the number of inactive revisions is config [11:21] * Chipaca -> lunch [11:21] mvo, about the test snap-core-symlinks, it just works on google, but on the boards or ubuntu-core the core snaps in /var/lib/snapd/snaps are not linked to seeds [11:22] niemeyer: thank you [11:23] niemeyer: the main issue here is that these interfaces might be what we'd consider "legacy" interfaces, and it isn't obvious that we'd want to extend them to cover more than just EDS [11:24] jamesh: In which sense is it legacy? [11:24] niemeyer: that's why jdstrand was gave eds-contacts as a possibility [11:24] jamesh: I mean, other than it being for old services === pstolowski is now known as pstolowski|lunch [11:24] niemeyer: that EDS hasn't been designed for confinement, so these are basically "all or nothing" interfaces [11:25] we can't give an app access to one address book or one calendar [11:25] (or one contact within an address book) [11:25] Hmm [11:26] niemeyer: so if we ever get such an API, it would have quite different semantics to these snapd interfaces [11:26] (e.g. it might be quite safe to auto-connect an interface giving an app access to an app specific calendar) [11:26] jamesh: Would we have an interface at all if that takes place? [11:26] mvo, https://paste.ubuntu.com/p/MbHN3jTfS6/ [11:26] jamesh: I mean, how would we allow access to _one_ contact [11:27] mvo, this is starting the image, no spread tests involved [11:27] jamesh: Other than having an interface that would prevent general access in either case [11:28] jamesh: In other words, would we have a "contacts-service" interface at all when that happens? [11:28] niemeyer: it would have to rely on the service mediating access similar to portals. I think we had something like that as a trusted helper on Ubuntu Phone? [11:28] jamesh: Right, exactly [11:29] jamesh: So I see two possibilities once that takes place: [11:30] 1) We have no interface at all, and grant the access in the base profile [11:30] niemeyer: the other naming issue brought up was KDE: it has its own backend with its own IPC (Akonadi). It isn't clear whether that could be added to these interfaces or not: IIRC it isn't D-Bus based, so it might be giving access to a lot more than "only contacts" or "only calendars" [11:30] 2) We have an interface, and require that to be connected to ask for a contact even then [11:31] jamesh: In (1), we might just obsolete "contacts-service" (or any other name we pick) [11:31] jamesh: In (2), I see no harm in providing access to both services in the same interface.. [11:31] jamesh: We're still confining the best we can for the available means [11:32] niemeyer: right. So I think the suggestion to use "eds-contacts" would be to avoid squatting on a name we might want to use for the possible non-legacy interface [11:32] jamesh: That KDE case needs to be understood indeed.. [11:33] jamesh: I get it.. the rationale above provide some feedback on why I suspect that might not be an issue [11:33] jamesh: That said, the KDE case needs to be better understood [11:33] jamesh: To make sure it's not evidence of a larger problem [11:34] jamesh: We might try to use similar logic there, though.. what are the potential choices we have? [11:34] jamesh: If KDE cannot be split, no possible interface name will suit it [11:35] jamesh: If it can, the actual interface names do not matter [11:35] niemeyer: https://techbase.kde.org/KDE_PIM/Akonadi/Architecture says it is an IMAP-like protocol over a unix domain socket, with the store covering contacts, calendars, email, and other types [11:35] jamesh: That makes it sound like it'd need a custom interface name for it [11:35] "akonadi" being the obvious candidate [11:36] so it doesn't sound like we could restrict based on data type [11:37] I'm kind of leaning towards eds-contacts and eds-calendar, but don't feel too strongly about it (I'm basically just waiting for a decision so I can update the PR) [11:37] jamesh: I'm not strongly in favor of something either, but let's please not go with "eds" [11:38] That makes no sense to pretty much anyone that is not a frequent user of the software [11:39] niemeyer: I'd agree that "eds" on its own doesn't mean much. But combined with "contacts" or "calendar" it has meaning [11:39] "akonadi" as an interface name would be equally impenetrable [11:40] jamesh: Sort of.. google for both [11:40] we also have the interface names [11:40] but how about gnome-contacts, gnome-calendar [11:40] s/names/summaries/ [11:40] and kde-{contacts,calendar} [11:40] better than both eds and akowhatever [11:41] (is akonadi a word or an acronym or just random letters?) [11:41] jamesh: Another perspective: are there any other calendar services? [11:41] zyga: Doesn't matter much [11:42] jamesh: .. and even if there aren't, what if a new one is created.. would we want individual interfaces for all of them? [11:42] jamesh: If so, why did we choose to bundle "password-manager-service"? [11:44] niemeyer: well, ideally everyone would move towards a common confinement friendly API that satisfies your scenario (1). So apps don't necessarily program to a single one [11:45] jamesh: The ideal scenario doesn't help us right now [11:45] akonadi> "named after the oracle goddess of justice in Ghana" says wikipedia [11:45] jamesh: Per early points, in the ideal scenario we can just obsolete everything else and have a base profile [11:45] niemeyer: right, but it is relevant to "what if someone invents yet another data store?" question [11:46] jamesh: Right.. the question was supposing that this is not an ideal scenario [11:48] jamesh: Another piece in the puzzle: we have unity8-contacts and unity8-calendar, and unity8-pim-common already [11:48] So the scenario of having multiple "legacy" calendars is not theory [11:49] Do we have any snaps using these interfaces today? [11:50] I'm tempted to obsolete these interfaces, or potentially remove them if we have a trivial number of snaps published that leverage them and we can communicate with publishers [11:50] niemeyer: I think the unity8-* ones are from the unsuccessful attempt to port Ubuntu Phone to snappy [11:50] and then not do the same mistake again [11:52] I know there's other phone interfaces we wrote that my team wrote that are effectively unused (e.g. thumbnailer-service + storage-framework-service) [11:55] Besides having an "akonadi" interface, we might also have a "pim-service" interface that aggregates both calendar-service and contacts-service [11:56] Or, alternatively, we might go the opposite way and enable akonadi only if both interfaces are connected [11:56] That's all somewhat magical, though [11:57] Having it explicit still feels saner [11:57] niemeyer: at the moment, the primary use case for these interfaces was to be able to snap the gnome-contacts and gnome-calendar applications, and probably have the store allow these apps to autoconnect [11:58] niemeyer: I'm not sure how many other apps would actually use them, since we're talking about highly sensitive personal data [11:58] jamesh: Given all the conversation so far, gut feeling is still that "calendar-service" and "contacts-service" gets us to a reasonable place [11:58] Very clear what data is at stake.. reusable if we find more use cases [11:59] Doesn't prevent other alternatives [11:59] okay [11:59] Follows existing conventions that are in use [12:00] I'll update to use that then. [12:00] Thanks for the discussion [12:04] pstolowski|lunch: reviewed #5215 [12:04] PR #5215: ifacestate: improved error handling when creating autoconnect tasks [12:04] jamesh (cc niemeyer): for some historical context-- Ubuntu Touch had the same problem and used the same technology (eds). there was no application isolation with eds. also, unity8-contacts and unit8-calendar happen to also use eds; the difference with those interfaces is that they are designed with a slot implementation in mind,not as an implicit calssic interface [12:05] on touch there was an addressbook service and iirc something for calendar, but they didn't provide any isolation. it was always planned they would at some point [12:06] cachio_: thanks, thats interessting. I hvae a look in a little bit [12:07] jamesh: re akonadi and imap over unix> yuck :) [12:09] jdstrand: Wouldn't the interface be the same, whether it's designed with a slot upfront or not? [12:09] jdstrand: Over time we had multiple cases that migrated towards offering a slot [12:11] popey: 'snap set system refresh.retain=N' now on master [12:12] niemeyer: it is essentially the same, yes (in fact, I compared them as part of my review for these new ones). the only difference is that jamesh' new ones we slightly more specific in some cases (which was understandable since we had a specific snap's label on the slot side) [12:13] I figured we would probably deprecate the unity8 ones too [12:14] (since these new ones were targetting real world use cases) [12:16] niemeyer: the way that things are going with portals and classic desktop, I'm not sure we'll every have a slot side implementation for these new services, but I wouldn't rule it out [12:17] I should have said 'new services' :) [12:18] mvo: what's #5213 waiting for? [12:18] PR #5213: snapcraft: run with DEB_BUILD_OPTIONS=nocheck [12:19] oh maybe the last +1 is really recent :-) [12:20] * zyga -> walk [12:23] jdstrand: the unity8-* interfaces seem to be missing some rules to talk to the source registry. I wonder if they were relying on the com.canonical.pim.* interfaces for discovery instead? [12:25] Chipaca: yes [12:26] pedronis: thank you! [12:28] PR snapd#5213 closed: snapcraft: run with DEB_BUILD_OPTIONS=nocheck [12:32] PR snapd#5225 opened: selftest: add new selftest package that tests squashfs mounting [12:34] jamesh: I wondered that myself. iirc the unity8 ones didn't use path= everywhere so perhaps it was covered by them be less specific. alternatively, those are buggy and we never saw the bugs cause no one used them [12:34] cachio_: what ubuntu-image do you use to create the image that then does not have the symlinks? the ubuntu-image deb or the ubuntu-image snap? I wonder if the "wrong" snap prepare-image is used here (the snap embedds that) [12:35] jamesh: (I'm recollecting from the other day's review since I'm pulled aside atm) [12:35] mvo, the deb === pstolowski|lunch is now known as pstolowski [12:38] cachio_: and the machine that build the image had snapd 2.33~rc1 installed? [12:39] mvo, 16-2.33~rc1+git758.0a96f21 (4764) [12:39] it is edge [12:42] cachio_: ok, I will try to reproduce [13:14] jdstrand: could the review tools be updated for the new snapd snap? its a bit unusal, but not that much [13:14] jdstrand: it will be uploaded nightly as a snap now [13:16] mvo: it is a normal app snap? what do you want updated in the tools. I see snap-confine (fine). is that external symlink valid? [13:16] package contains external symlinks: lib/udev/snappy-app-dev [13:18] jdstrand: its a normal app snap. the symlink should be fine, I can make it relative though if that helps [13:19] jdstrand: maybe I can even remove it entirely, its just for backward compatiblity. I need to look carefully [13:20] mvo: well, the idea behind the test is that a symlink to outside the snap isn't guaranteed to have the target present and so may be broken. in this case, it's unclear, I mean, the snap is providing the target... [13:24] mvo: I've fixed the snap-confine issue in trunk. I need to add some code for the symlink. let me know if it is needed [13:25] jdstrand: ping me for the review, I'm always curious about that [13:38] PR snapd#5208 closed: interface hooks: update old AutoConnect methods [13:40] niemeyer: my understanding of the problem of parallel installs and classic confinement https://forum.snapcraft.io/t/special-bind-mount-for-snap-instances-including-classic-confinement/5666 === pbek_ is now known as pbek [13:48] mvo: is current master 2.35? [13:48] Chipaca: 2.34 [13:48] mvo: ah! i thought we'd split that already [13:48] ok [13:48] mvo: (asking for the "available since" thing in the docs) [13:49] Chipaca: we split 2.33 [13:49] and now that is in beta [13:52] 2.36 [13:52] because we could to show we, on average, increment once a month ;D [14:01] zyga: quick quiz for you: how many months are there in a year [14:03] Chipaca: how many do you need? [14:03] zyga: no that's the _russian's_ line [14:03] you're getting your jokes mixed up [14:11] Chipaca: about 5225> you asked about squashfs without xz compression - I assume you ask for this to present a better error message? [14:12] mvo: yes [14:13] PR snapd#5216 closed: many: holding refresh on metered connections (2.33) [14:14] mvo: ie do the check for the xz one, if that fails do the same check with the non-xz one [14:14] mvo: OTOH i'm not too happy about having a 4k var, having two would be right out :-) [14:16] Chipaca: I think I can compress it, let me see [14:16] mvo: dude, it's a squashfs :-) [14:17] mvo: but, depending on how smart you want to be, you could drop the trailing zeroes and pad it when testing [14:17] mvo: I can show you what I mean if you want [14:17] Chipaca: yeah, this is what I had in mind, the zeros [14:18] mvo: also perhaps encoding/ascii85 instead of encoding/base64 [14:18] Chipaca: is there a good cmdline tool? [14:18] $ ascii85 [14:18] The program 'ascii85' is currently not installed. You can install it by typing: [14:18] sudo apt install ruby-ascii85 [14:18] Chipaca: http://paste.ubuntu.com/p/xXxNzZZ5Xr/ [14:19] Chipaca: hrm, I pass, I don't want to install ruby just for that :) [14:19] mvo: me neither :-) [14:21]