| mup | PR snapd#5222 opened: tests: adding fedora-28 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5222> | 02:38 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === pbek_ is now known as pbek | ||
| mborzecki | morning | 05:07 |
| mup | PR snapd#5220 closed: tests: moving test helpers from sh to bash <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5220> | 05:43 |
| mup | PR snapd#5218 closed: many: expose AppStream IDs (AKA common ID) (2.33) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5218> | 05:44 |
| mvo | 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:14 |
| mvo | mwhudson: I will try to get access to the debug logs now | 06:15 |
| mborzecki | mvo: morning | 06:15 |
| mvo | hey mborzecki | 06:15 |
| mvo | mwhudson: one problem might be that there is (currently) no ifconfig, just the new "ip" on core | 06:16 |
| mvo | mwhudson: fwiw, netplan itself seems to work (if I add a config manually it generates/applies that) | 06:25 |
| === chihchun is now known as chihchun_afk | ||
| zyga | good morning | 06:36 |
| zyga | diddledan: thank you, I will respond | 06:37 |
| diddledan | :-) | 06:37 |
| mborzecki | zyga: hey | 06:39 |
| zyga | :-) | 06:42 |
| === chihchun_afk is now known as chihchun | ||
| mvo | hey zyga | 06:44 |
| mvo | 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:45 |
| zyga | diddledan: replied now | 06:50 |
| mup | PR snapd#5223 opened: image: set model.DisplayName() in bootenv as "snap_menuentry" <Created by mvo5> <https://github.com/snapcore/snapd/pull/5223> | 06:56 |
| zyga | hmm | 07:11 |
| zyga | udisks2 is not implicit on classic | 07:12 |
| zyga | pstolowski|afk: is this intended? AFAIK it was implicit before | 07:12 |
| * zyga checks logs | 07:12 | |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:16 |
| pedronis | I don't think we changed anything about that directly | 07:16 |
| pstolowski | zyga: as pedronis says | 07:16 |
| pedronis | are we missing some call to addImplicitSlots ? | 07:17 |
| zyga | no, it's just not marked as implicit | 07:17 |
| zyga | and the code is not ready for it yet | 07:17 |
| zyga | I assumed it was implicit on classic because it's such an old interface | 07:18 |
| zyga | but now I recall it came to be for IOT first | 07:18 |
| pedronis | afaict we added it for core | 07:18 |
| pedronis | not classic | 07:18 |
| pedronis | *afaicr | 07:18 |
| zyga | yes, that's correct | 07:19 |
| mborzecki | zyga: that tar exclude pattern is wrong too | 07:23 |
| mborzecki | pushed a fix to sergio's PR, we should be able to merge it when the build is green | 07:46 |
| mborzecki | need to make a quick run to the tax office, bb in ~1h or so | 07:48 |
| * zyga -> coffee | 08:08 | |
| zyga | mvo: can you do one thing for me, open a terminal and run this | 08:08 |
| zyga | autopkgtest-buildvm-ubuntu-cloud --verbose -r bionic -a amd64 | 08:08 |
| zyga | and let me know if this ever finishes for you | 08:08 |
| mvo | zyga: what version of autopkgtest do you have installed? | 08:10 |
| zyga | 5.0.2 | 08:12 |
| mvo | zyga: I have 5.3 and the command works for me - but I'm on bionic. at what release are you? | 08:17 |
| mborzecki | re | 08:37 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | mornin' all | 08:52 |
| pstolowski | hey Chipaca ! | 08:52 |
| Chipaca | pstolowski! | 08:52 |
| Chipaca | how's things | 08:52 |
| pstolowski | it's too hot | 08:53 |
| pstolowski | and it's only May | 08:53 |
| Chipaca | pstolowski: "it's only May" seems to be what a lot of people in the UK think | 08:54 |
| Chipaca | anyhoo | 08:54 |
| pstolowski | haha | 08:54 |
| Chipaca | pstolowski: it was really hot yesterday (with almost-proper thunderstorms and everything!) but today there's a nice cool breeze | 08:55 |
| zyga | Chipaca: so after May comes thunder? | 09:06 |
| zyga | ;-) | 09:06 |
| zyga | hey, how are you doing? | 09:06 |
| Chipaca | zyga: not bad, you? | 09:07 |
| mborzecki | Thunder sounds like a fitting name for someone from EDL | 09:07 |
| zyga | Chipaca: dizzy a bit | 09:08 |
| Chipaca | zyga: you pregnant? | 09:08 |
| zyga | that'd be new :) | 09:08 |
| pstolowski | pedronis: updated #5215 | 09:17 |
| mup | PR #5215: ifacestate: improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215> | 09:17 |
| pedronis | pstolowski: I'll look in a bit | 09:18 |
| mborzecki | mvo: will core18 ship systemd in the snap too? | 09:39 |
| Chipaca | mborzecki: yes | 09:49 |
| Chipaca | although … we could ship two core18s | 09:49 |
| Chipaca | one for classic, with no systemd nor ssh nor nothing | 09:49 |
| Chipaca | one for classicn't | 09:50 |
| * Chipaca hides from the wrath of both grammarians and mvoians | 09:50 | |
| mup | PR snapd#5224 opened: interfaces: remove Plug/Slot types <Created by stolowski> <https://github.com/snapcore/snapd/pull/5224> | 09:51 |
| mborzecki | Chipaca: fwiw that's ~9-12MB (uncompressed) for just systemd | 09:53 |
| Chipaca | it's probably not worth it | 09:54 |
| Chipaca | i mean, given it's classic, bandwidth saving is probably the bigger thing, and it doesn't look like much | 09:54 |
| Chipaca | it's one photo | 09:55 |
| zyga | Chipaca: it's interesting given the relative popularity of core18 for booting vs not booting | 09:57 |
| mup | PR snapd#5214 closed: cmd/snap: check with snapd for unknown sections <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5214> | 09:57 |
| Chipaca | we should add two new snap types: boot, and jigsaw | 09:57 |
| mborzecki | jigsaw | 09:58 |
| mborzecki | well, nobody complained so far so maybe it's not worth it indeed | 09:59 |
| mvo | Chipaca: two cores is interessting, the one for classic would be ~28MB, the one for core18 is ~42mb or so currently | 09:59 |
| Chipaca | mvo: why that much smaller? | 10:00 |
| mborzecki | mvo: that's the *.snap size or du inside? | 10:00 |
| pedronis | it's very confusing in terms of building, in theory you can build an app for both | 10:00 |
| pedronis | would always build only against the one for classic? | 10:00 |
| mvo | Chipaca: systemd+ssh+netplan+console-conf | 10:00 |
| mvo | Chipaca: but mostly netplan/console-conf which pull in most of python3 | 10:01 |
| mvo | mborzecki: outside | 10:01 |
| Chipaca | mvo: no, i mean, current core is 87MB | 10:01 |
| zyga | mvo: also apparmor userspace | 10:01 |
| pedronis | then you convert one into the other when consider base? | 10:01 |
| zyga | mvo: that's also python3 | 10:01 |
| Chipaca | pedronis: if we want to explore this, having a boot type might make more sense, exactly for those reasons | 10:01 |
| mvo | Chipaca: aggressive cleanup, not sure if we can keep it this way, no vi, no ifconfig (just ip) no "less" etc | 10:01 |
| zyga | mvo: there's always classic for that | 10:02 |
| zyga | we should also think what classic does on 18 | 10:02 |
| Chipaca | mvo: also no desktop helper afaics | 10:02 |
| mvo | Chipaca: yeah, thats a bug we should fix soon, those are small | 10:02 |
| Chipaca | :-) | 10:02 |
| * mvo thinks | 10:02 | |
| zyga | ironically slim core18 would be a very nice addition to embedded systems running classic distros | 10:03 |
| Chipaca | mvo: https://forum.snapcraft.io/t/using-xdg-open-with-core18/5620?u=chipaca fwiw | 10:03 |
| zyga | as the size increase is really small | 10:03 |
| ogra_ | why do you care for uncompressed ? (after all it will never be used uncompressed on any disk) | 10:03 |
| Chipaca | ogra_: i don't think we do :-) | 10:04 |
| Chipaca | ogra_: but it's worth asking, just to make sure we're talking about the same thing | 10:04 |
| ogra_ | Chipaca, mborzecki mentioned uncompressed sizes above ... | 10:04 |
| Chipaca | otherwise chinese whispers grows | 10:04 |
| Chipaca | ogra_: ah, that's just mborzecki being lazy :-p | 10:05 |
| * Chipaca continues hiding | 10:05 | |
| ogra_ | haha | 10:05 |
| pedronis | Chipaca: my fear it adds complexity and surprises, not sure we are ready to deal with them | 10:05 |
| ogra_ | also on the developer/user side | 10:05 |
| Chipaca | pedronis: agreed | 10:05 |
| zyga | pedronis: I agree about that, perhaps it's something to slowly prepare post 18-boot ( | 10:05 |
| Chipaca | still, it does seem like nearly double the size | 10:05 |
| zyga | (if we slowly march towards that for 20 I would be more comfortable) | 10:06 |
| Chipaca | so worth considering (as in, writing down the reasons so we can explain to others / our future selves) | 10:06 |
| pedronis | yea, it seems better as a goal for 20 | 10:06 |
| pedronis | than to cram it in now | 10:06 |
| pedronis | so many open questions already, and this double some of them | 10:06 |
| ogra_ | if 20 is out embedded systems might not care for an extra 10-20MB on disk anymore :) | 10:06 |
| zyga | 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 |
| pedronis | nothing to do, win ;) | 10:07 |
| zyga | I mean that on more complex boot case we don't change anything at all | 10:07 |
| zyga | so that's a win indeed :) | 10:07 |
| mborzecki | ogra_: that's true | 10:07 |
| zyga | that case is more complex | 10:07 |
| ogra_ | (finding MMCs below 2GB is already hard today ... ad will actually cost you extra) | 10:07 |
| zyga | the non boot case is really something we could explore without much risk | 10:07 |
| ogra_ | *and | 10:07 |
| zyga | ogra_: (note that this doesn't shrink the MMC embedded case at all) | 10:08 |
| zyga | this is just for making desktop users happier | 10:08 |
| pedronis | zyga: not quite because it's also a base, if everbody builds against the full one | 10:08 |
| pedronis | you cannot change it | 10:08 |
| zyga | pedronis: mmmm, indeed | 10:08 |
| pedronis | as in remove stuff | 10:08 |
| zyga | I take that back then | 10:08 |
| zyga | because people would have to absolutely build against the stripped down version | 10:08 |
| zyga | for this to work | 10:08 |
| pedronis | yea, that's the tricky bit | 10:08 |
| zyga | we might explore a 19 base | 10:08 |
| zyga | with this property | 10:08 |
| pedronis | that makes it hard to pull off | 10:08 |
| zyga | to cook it for 20 | 10:08 |
| pedronis | while everything is in flux | 10:09 |
| Chipaca | I mean, we could always do magic and replace core18 with core18-classic on classic | 10:09 |
| Chipaca | down the road | 10:09 |
| zyga | a new base, 19, without any boot support | 10:09 |
| Chipaca | if we needed to | 10:09 |
| zyga | Chipaca: yes | 10:09 |
| niemeyer | mvo: Ack, will do | 10:09 |
| mvo | 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:09 |
| * zyga likes the core19 as an experiment | 10:11 | |
| Chipaca | niemeyer: good morning! | 10:11 |
| zyga | but needs to be supported as short as 19.x ubuntu | 10:11 |
| ogra_ | call it core20 from the start and just iterate ;) | 10:11 |
| Chipaca | niemeyer: i could use a bit of bikeshed paint on 'refresh.keep-inactive' | 10:11 |
| zyga | ogra_: I don't think that's good, it may not be compatible with 20 | 10:11 |
| ogra_ | ten call it core-experimental ;) | 10:12 |
| ogra_ | +then | 10:12 |
| Chipaca | so, even cores stable, odd cores devel | 10:12 |
| * Chipaca should stop putting crazy ideas out lest they continue to be taken seriously | 10:12 | |
| niemeyer | Chipaca: Hey, good morning | 10:13 |
| * ogra_ quickly writes a softpedia article about Chipaca's masterplan of odd/even cores | 10:13 | |
| niemeyer | Chipaca: Sure, happy to bring my paint :) | 10:13 |
| niemeyer | Chipaca: Is there a PR up already? | 10:13 |
| Chipaca | niemeyer: https://github.com/snapcore/snapd/pull/5207 | 10:13 |
| mup | PR #5207: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <https://github.com/snapcore/snapd/pull/5207> | 10:13 |
| Chipaca | 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 |
| Chipaca | actually still missing some tests though | 10:14 |
| * Chipaca gets back to work | 10:14 | |
| ogra_ | mvo, is there a chance that with core18 the pi config options can be moved out of core ? its so displaced there :/ | 10:14 |
| pedronis | mvo: btw I plan to do a proper review of #5217 today | 10:15 |
| mup | PR #5217: asserts,image: add support for models with bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/5217> | 10:15 |
| niemeyer | Chipaca: Thanks, looking | 10:15 |
| mvo | pedronis: \o/ | 10:15 |
| pedronis | ogra_: well we support calling those config "system" as well now | 10:16 |
| mvo | ogra_: we have an alias for those now: system | 10:16 |
| mvo | heh :) snap | 10:16 |
| pedronis | because of the bases stuff, but still no final plan | 10:16 |
| pedronis | about the internals | 10:16 |
| mvo | ogra_: whats your concern? where the code lifes? or the config schema (core.pi2-foo)? | 10:17 |
| ogra_ | 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:21 |
| ogra_ | core should be generic IMHO ... i always thought of the "pi config options in core" as an interim solution | 10:24 |
| ogra_ | and the swith to 18 seems like a natural moment to move that around to the correct place | 10:24 |
| * zyga needs to, perhaps, redesign a small fragment of snap-update-ns path handling | 10:29 | |
| zyga | pen & paper time | 10:29 |
| niemeyer | Chipaca: Reviewed | 10:30 |
| Chipaca | 'ppreciated | 10:30 |
| pedronis | 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:05 |
| ogra_ | 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:06 |
| ogra_ | *feels | 11:07 |
| ogra_ | (and i'm aware that it moved out of core into snapd at some point ... which i find even worse) | 11:08 |
| jamesh | 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 |
| mup | PR #5184: interfaces: add desktop-{contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184> | 11:09 |
| zyga | jamesh: hey! | 11:10 |
| jamesh | hi zyga | 11:10 |
| zyga | jamesh: there was a user a while ago asking about how to use the snap with common themes | 11:10 |
| zyga | is there anything I could relay him to? | 11:10 |
| jamesh | 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:12 |
| zyga | right, is there anything that explains that and how to use it | 11:13 |
| jamesh | I don't think we've got any docs on what that boilerplate should look like yet | 11:13 |
| niemeyer | jamesh: Looking | 11:14 |
| jamesh | 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 |
| jamesh | niemeyer: thanks! | 11:15 |
| zyga | jamesh: excellent, thank you! | 11:15 |
| Chipaca | where are we documenting config options? | 11:17 |
| Chipaca | things like refresh.hold etc | 11:17 |
| mborzecki | Chipaca: https://forum.snapcraft.io/t/system-options/87 | 11:17 |
| cachio_ | mvo, hey | 11:18 |
| niemeyer | jamesh: np, and thanks for the PR.. commented there | 11:20 |
| mup | PR snapd#5207 closed: overlord/{config,snap}state: the number of inactive revisions is config <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5207> | 11:21 |
| * Chipaca -> lunch | 11:21 | |
| cachio_ | 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:21 |
| jamesh | niemeyer: thank you | 11:22 |
| jamesh | 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:23 |
| niemeyer | jamesh: In which sense is it legacy? | 11:24 |
| jamesh | niemeyer: that's why jdstrand was gave eds-contacts as a possibility | 11:24 |
| niemeyer | jamesh: I mean, other than it being for old services | 11:24 |
| === pstolowski is now known as pstolowski|lunch | ||
| jamesh | niemeyer: that EDS hasn't been designed for confinement, so these are basically "all or nothing" interfaces | 11:24 |
| jamesh | we can't give an app access to one address book or one calendar | 11:25 |
| jamesh | (or one contact within an address book) | 11:25 |
| niemeyer | Hmm | 11:25 |
| jamesh | niemeyer: so if we ever get such an API, it would have quite different semantics to these snapd interfaces | 11:26 |
| jamesh | (e.g. it might be quite safe to auto-connect an interface giving an app access to an app specific calendar) | 11:26 |
| niemeyer | jamesh: Would we have an interface at all if that takes place? | 11:26 |
| cachio_ | mvo, https://paste.ubuntu.com/p/MbHN3jTfS6/ | 11:26 |
| niemeyer | jamesh: I mean, how would we allow access to _one_ contact | 11:26 |
| cachio_ | mvo, this is starting the image, no spread tests involved | 11:27 |
| niemeyer | jamesh: Other than having an interface that would prevent general access in either case | 11:27 |
| niemeyer | jamesh: In other words, would we have a "contacts-service" interface at all when that happens? | 11:28 |
| jamesh | 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 |
| niemeyer | jamesh: Right, exactly | 11:28 |
| niemeyer | jamesh: So I see two possibilities once that takes place: | 11:29 |
| niemeyer | 1) We have no interface at all, and grant the access in the base profile | 11:30 |
| jamesh | 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 |
| niemeyer | 2) We have an interface, and require that to be connected to ask for a contact even then | 11:30 |
| niemeyer | jamesh: In (1), we might just obsolete "contacts-service" (or any other name we pick) | 11:31 |
| niemeyer | jamesh: In (2), I see no harm in providing access to both services in the same interface.. | 11:31 |
| niemeyer | jamesh: We're still confining the best we can for the available means | 11:31 |
| jamesh | 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 |
| niemeyer | jamesh: That KDE case needs to be understood indeed.. | 11:32 |
| niemeyer | jamesh: I get it.. the rationale above provide some feedback on why I suspect that might not be an issue | 11:33 |
| niemeyer | jamesh: That said, the KDE case needs to be better understood | 11:33 |
| niemeyer | jamesh: To make sure it's not evidence of a larger problem | 11:33 |
| niemeyer | jamesh: We might try to use similar logic there, though.. what are the potential choices we have? | 11:34 |
| niemeyer | jamesh: If KDE cannot be split, no possible interface name will suit it | 11:34 |
| niemeyer | jamesh: If it can, the actual interface names do not matter | 11:35 |
| jamesh | 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 |
| niemeyer | jamesh: That makes it sound like it'd need a custom interface name for it | 11:35 |
| niemeyer | "akonadi" being the obvious candidate | 11:35 |
| jamesh | so it doesn't sound like we could restrict based on data type | 11:36 |
| jamesh | 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 |
| niemeyer | jamesh: I'm not strongly in favor of something either, but let's please not go with "eds" | 11:37 |
| niemeyer | That makes no sense to pretty much anyone that is not a frequent user of the software | 11:38 |
| jamesh | niemeyer: I'd agree that "eds" on its own doesn't mean much. But combined with "contacts" or "calendar" it has meaning | 11:39 |
| jamesh | "akonadi" as an interface name would be equally impenetrable | 11:39 |
| niemeyer | jamesh: Sort of.. google for both | 11:40 |
| zyga | we also have the interface names | 11:40 |
| zyga | but how about gnome-contacts, gnome-calendar | 11:40 |
| zyga | s/names/summaries/ | 11:40 |
| zyga | and kde-{contacts,calendar} | 11:40 |
| zyga | better than both eds and akowhatever | 11:40 |
| zyga | (is akonadi a word or an acronym or just random letters?) | 11:41 |
| niemeyer | jamesh: Another perspective: are there any other calendar services? | 11:41 |
| niemeyer | zyga: Doesn't matter much | 11:41 |
| niemeyer | 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 |
| niemeyer | jamesh: If so, why did we choose to bundle "password-manager-service"? | 11:42 |
| jamesh | 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:44 |
| niemeyer | jamesh: The ideal scenario doesn't help us right now | 11:45 |
| cjwatson | akonadi> "named after the oracle goddess of justice in Ghana" says wikipedia | 11:45 |
| niemeyer | jamesh: Per early points, in the ideal scenario we can just obsolete everything else and have a base profile | 11:45 |
| jamesh | niemeyer: right, but it is relevant to "what if someone invents yet another data store?" question | 11:45 |
| niemeyer | jamesh: Right.. the question was supposing that this is not an ideal scenario | 11:46 |
| niemeyer | jamesh: Another piece in the puzzle: we have unity8-contacts and unity8-calendar, and unity8-pim-common already | 11:48 |
| niemeyer | So the scenario of having multiple "legacy" calendars is not theory | 11:48 |
| niemeyer | Do we have any snaps using these interfaces today? | 11:49 |
| niemeyer | 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 |
| jamesh | niemeyer: I think the unity8-* ones are from the unsuccessful attempt to port Ubuntu Phone to snappy | 11:50 |
| niemeyer | and then not do the same mistake again | 11:50 |
| jamesh | 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:52 |
| niemeyer | Besides having an "akonadi" interface, we might also have a "pim-service" interface that aggregates both calendar-service and contacts-service | 11:55 |
| niemeyer | Or, alternatively, we might go the opposite way and enable akonadi only if both interfaces are connected | 11:56 |
| niemeyer | That's all somewhat magical, though | 11:56 |
| niemeyer | Having it explicit still feels saner | 11:57 |
| jamesh | 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:57 |
| jamesh | niemeyer: I'm not sure how many other apps would actually use them, since we're talking about highly sensitive personal data | 11:58 |
| niemeyer | 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 |
| niemeyer | Very clear what data is at stake.. reusable if we find more use cases | 11:58 |
| niemeyer | Doesn't prevent other alternatives | 11:59 |
| jamesh | okay | 11:59 |
| niemeyer | Follows existing conventions that are in use | 11:59 |
| jamesh | I'll update to use that then. | 12:00 |
| niemeyer | Thanks for the discussion | 12:00 |
| pedronis | pstolowski|lunch: reviewed #5215 | 12:04 |
| mup | PR #5215: ifacestate: improved error handling when creating autoconnect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5215> | 12:04 |
| jdstrand | 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:04 |
| jdstrand | 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:05 |
| mvo | cachio_: thanks, thats interessting. I hvae a look in a little bit | 12:06 |
| jdstrand | jamesh: re akonadi and imap over unix> yuck :) | 12:07 |
| niemeyer | jdstrand: Wouldn't the interface be the same, whether it's designed with a slot upfront or not? | 12:09 |
| niemeyer | jdstrand: Over time we had multiple cases that migrated towards offering a slot | 12:09 |
| Chipaca | popey: 'snap set system refresh.retain=N' now on master | 12:11 |
| jdstrand | 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:12 |
| jdstrand | I figured we would probably deprecate the unity8 ones too | 12:13 |
| jdstrand | (since these new ones were targetting real world use cases) | 12:14 |
| jdstrand | 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:16 |
| jdstrand | I should have said 'new services' :) | 12:17 |
| Chipaca | mvo: what's #5213 waiting for? | 12:18 |
| mup | PR #5213: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/5213> | 12:18 |
| Chipaca | oh maybe the last +1 is really recent :-) | 12:19 |
| * zyga -> walk | 12:20 | |
| jamesh | 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:23 |
| pedronis | Chipaca: yes | 12:25 |
| pstolowski|lunch | pedronis: thank you! | 12:26 |
| mup | PR snapd#5213 closed: snapcraft: run with DEB_BUILD_OPTIONS=nocheck <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5213> | 12:28 |
| mup | PR snapd#5225 opened: selftest: add new selftest package that tests squashfs mounting <Created by mvo5> <https://github.com/snapcore/snapd/pull/5225> | 12:32 |
| jdstrand | 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 |
| mvo | 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:34 |
| jdstrand | jamesh: (I'm recollecting from the other day's review since I'm pulled aside atm) | 12:35 |
| cachio_ | mvo, the deb | 12:35 |
| === pstolowski|lunch is now known as pstolowski | ||
| mvo | cachio_: and the machine that build the image had snapd 2.33~rc1 installed? | 12:38 |
| cachio_ | mvo, 16-2.33~rc1+git758.0a96f21 (4764) | 12:39 |
| cachio_ | it is edge | 12:39 |
| mvo | cachio_: ok, I will try to reproduce | 12:42 |
| mvo | jdstrand: could the review tools be updated for the new snapd snap? its a bit unusal, but not that much | 13:14 |
| mvo | jdstrand: it will be uploaded nightly as a snap now | 13:14 |
| jdstrand | 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 |
| jdstrand | package contains external symlinks: lib/udev/snappy-app-dev | 13:16 |
| mvo | jdstrand: its a normal app snap. the symlink should be fine, I can make it relative though if that helps | 13:18 |
| mvo | jdstrand: maybe I can even remove it entirely, its just for backward compatiblity. I need to look carefully | 13:19 |
| jdstrand | 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:20 |
| jdstrand | 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:24 |
| zyga | jdstrand: ping me for the review, I'm always curious about that | 13:25 |
| mup | PR snapd#5208 closed: interface hooks: update old AutoConnect methods <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5208> | 13:38 |
| zyga | 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 | 13:40 |
| === pbek_ is now known as pbek | ||
| Chipaca | mvo: is current master 2.35? | 13:48 |
| mvo | Chipaca: 2.34 | 13:48 |
| Chipaca | mvo: ah! i thought we'd split that already | 13:48 |
| Chipaca | ok | 13:48 |
| Chipaca | mvo: (asking for the "available since" thing in the docs) | 13:48 |
| pedronis | Chipaca: we split 2.33 | 13:49 |
| pedronis | and now that is in beta | 13:49 |
| zyga | 2.36 | 13:52 |
| zyga | because we could to show we, on average, increment once a month ;D | 13:52 |
| Chipaca | zyga: quick quiz for you: how many months are there in a year | 14:01 |
| zyga | Chipaca: how many do you need? | 14:03 |
| Chipaca | zyga: no that's the _russian's_ line | 14:03 |
| Chipaca | you're getting your jokes mixed up | 14:03 |
| mvo | Chipaca: about 5225> you asked about squashfs without xz compression - I assume you ask for this to present a better error message? | 14:11 |
| Chipaca | mvo: yes | 14:12 |
| mup | PR snapd#5216 closed: many: holding refresh on metered connections (2.33) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5216> | 14:13 |
| Chipaca | mvo: ie do the check for the xz one, if that fails do the same check with the non-xz one | 14:14 |
| Chipaca | mvo: OTOH i'm not too happy about having a 4k var, having two would be right out :-) | 14:14 |
| mvo | Chipaca: I think I can compress it, let me see | 14:16 |
| Chipaca | mvo: dude, it's a squashfs :-) | 14:16 |
| Chipaca | mvo: but, depending on how smart you want to be, you could drop the trailing zeroes and pad it when testing | 14:17 |
| Chipaca | mvo: I can show you what I mean if you want | 14:17 |
| mvo | Chipaca: yeah, this is what I had in mind, the zeros | 14:17 |
| Chipaca | mvo: also perhaps encoding/ascii85 instead of encoding/base64 | 14:18 |
| mvo | Chipaca: is there a good cmdline tool? | 14:18 |
| Chipaca | $ ascii85 | 14:18 |
| Chipaca | The program 'ascii85' is currently not installed. You can install it by typing: | 14:18 |
| Chipaca | sudo apt install ruby-ascii85 | 14:18 |
| mvo | Chipaca: http://paste.ubuntu.com/p/xXxNzZZ5Xr/ | 14:18 |
| mvo | Chipaca: hrm, I pass, I don't want to install ruby just for that :) | 14:19 |
| Chipaca | mvo: me neither :-) | 14:19 |
| Chipaca | mvo: https://pastebin.ubuntu.com/p/pmv3FYP5HB/ | 14:21 |
| Chipaca | mvo: but that's probably cheating | 14:22 |
| Chipaca | (also not exactly the same file because i was lazy in creating the canary.txt so don't use it as is) | 14:22 |
| mvo | Chipaca: with gzip its 309 byte | 14:22 |
| mvo | Chipaca: hm, 237 | 14:22 |
| Chipaca | mvo: and without gzip, but instead dropping trailing \0's? | 14:22 |
| mvo | Chipaca: no idea, I was too lazy to write code for this | 14:23 |
| Chipaca | :-) | 14:23 |
| mvo | Chipaca: thanks a lot for your suggestion(s) - much nicer (and smaller) now | 14:24 |
| Chipaca | mvo: https://pastebin.ubuntu.com/p/xNTmd4vYbb/ | 14:24 |
| Chipaca | mvo: the first one is base64, the second ascii85, both trimming trailing \0's, no gzip | 14:25 |
| mvo | Chipaca: 296 - nice | 14:26 |
| Chipaca | mvo: code for it if needed: https://pastebin.ubuntu.com/p/sY67dKbb6J/ | 14:36 |
| mvo | Chipaca: thank you, I will ponder about it. my gut feeling is that I want to be able to construct the "squashfs.image" string using std unix tools, hence gzip. but maybe I'm overly lazy here. going from 309byte to 200ish is a nice feature | 14:37 |
| Chipaca | mvo: either is fine tbh | 14:37 |
| Chipaca | mvo: make it a const instead of a var and you're home | 14:38 |
| Chipaca | (or make the var inside the function) | 14:38 |
| mvo | Chipaca: *cough* good point, thanks again | 14:38 |
| Chipaca | (same thing, as the const will still be there, unnamed) | 14:38 |
| mup | PR snapd#5224 closed: interfaces: remove Plug/Slot types <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5224> | 14:46 |
| mvo | cachio_: I tried to reproduce the issue with ubunut-image and the symlinks. I installed ubuntu-image from the deb and refreshed my core to beta. snap version shows 2.33~rc1 for the snap. when I build an image with that combination I get the symlinks. | 15:04 |
| mvo | cachio_: I'm trying the reboot problem now | 15:05 |
| cachio_ | mvo, seemlink issue is happening with the regular beta image | 15:08 |
| cachio_ | if you install the beta image created with ubuntu image you get the symlinks issue | 15:08 |
| cachio_ | then when you reboot from stable to beta and run the auto-refresh test you get the reboot issue | 15:09 |
| cachio_ | you can reproduce both with pc-amd64 or pc-i386 | 15:09 |
| mvo | cachio_: ok, so symlink issue: I did "ubuntu-image --channel=beta pc-amd64.model" and booted the resulted image (with systemd.debug-shell=1) and in there I can see the symlinks. what steps do I need to do to trigger the issue? | 15:11 |
| mvo | cachio_: for the unexpected reboot> what do I need to do here? "ubuntu-image --channel=stable pc-amd64.model" and then "snap refresh --beta core" and then run the autorefresh tests? | 15:12 |
| cachio_ | mvo, well start the vm | 15:14 |
| cachio_ | I do | 15:14 |
| cachio_ | kvm -snapshot -smp 2 -m 2000 -redir tcp:8022::22 -nographic -serial mon:stdio <PATH_TO_IMAGE> | 15:15 |
| cachio_ | mvo, to create the image | 15:16 |
| cachio_ | https://github.com/sergiocazzolato/validator/blob/master/create.sh | 15:16 |
| cachio_ | I use that script | 15:16 |
| cachio_ | with params: beta pc-amd64 | 15:16 |
| cachio_ | mvo, for unexpecte reboot | 15:18 |
| cachio_ | http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-amd64.img.xz | 15:20 |
| cachio_ | then reboot to beta | 15:20 |
| cachio_ | refresh | 15:20 |
| cachio_ | and after the reboot, you run auto-refresh test | 15:20 |
| cachio_ | mvo, I see there are new stable images | 15:20 |
| cachio_ | I was using the factory ones which are older | 15:21 |
| cachio_ | I am using | 15:21 |
| cachio_ | zyga, on fedora 28 the owner for /home/test/.snap is root instead of test | 15:24 |
| cachio_ | zyga, do you know if is it ok? | 15:25 |
| jdstrand | niemeyer: hey, I noticed in https://forum.snapcraft.io/t/classic-confinement-for-postman/5625/6 I no longer have a way to mark something as 'done' (ie, the little checkbox item I use from time to time). is the removal of this ability intentional? | 15:29 |
| noise][1 | i seem to have lost that ability as well | 15:34 |
| Chipaca | jdstrand: noise][1: we bumped versions friday, maybe it's a regression? | 15:34 |
| jdstrand | that's what I was wondering | 15:34 |
| jdstrand | I wonder if we need to have an additional acl or something | 15:35 |
| jdstrand | I vaguely recall that was needed before... by only vaguely | 15:35 |
| jdstrand | but* | 15:35 |
| Chipaca | jdstrand: I can't find it on topics I've created myself either | 15:35 |
| mup | PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170, | 15:36 |
| mup | snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225 | 15:36 |
| Chipaca | jdstrand: noise][1: it's a plugin, maybe the plugin needs updating? | 15:37 |
| mup | PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170, | 15:37 |
| mup | snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225 | 15:37 |
| Chipaca | we used to have a _lot_ of plugins, now there's just one | 15:37 |
| Chipaca | niemeyer: ^? | 15:37 |
| mup | PR # closed: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170, | 15:38 |
| mup | snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225 | 15:38 |
| mup | PR # opened: snapd#4416, snapd#4700, snapd#4767, snapd#4889, snapd#4917, snapd#4940, snapd#4951, snapd#4996, snapd#5030, snapd#5081, snapd#5122, snapd#5162, snapd#5170, | 15:39 |
| mup | snapd#5176, snapd#5178, snapd#5184, snapd#5187, snapd#5197, snapd#5204, snapd#5215, snapd#5217, snapd#5219, snapd#5221, snapd#5222, snapd#5223, snapd#5225 | 15:39 |
| zyga | cachio_: hmm, /.snap is used for store auth typically, I think that's not okay but I don't know the reason | 15:44 |
| mup | PR snapd#5226 opened: data: add systemd user environment generator <Created by mvo5> <https://github.com/snapcore/snapd/pull/5226> | 16:07 |
| cachio_ | zyga, this is fedora 28, -rw-------. 1 root root 44 May 29 14:48 auth.json | 16:12 |
| cachio_ | and this 27, -rw-r--r--. 1 root root 44 May 29 15:04 auth.json | 16:12 |
| cachio_ | this is making fail some tests | 16:12 |
| cachio_ | same for .snap dir | 16:13 |
| zyga | does it fail if you run just one test? I mean if you add restore-each and just check the ownership and mode, will this show the difference | 16:13 |
| zyga | also before you said it's owned by test user not by root, so which one is it? | 16:13 |
| cachio_ | zyga, I just ran 1 test | 16:14 |
| cachio_ | and it failed | 16:14 |
| cachio_ | so it is ok if it is owned by root | 16:14 |
| zyga | is umask different? | 16:14 |
| cachio_ | but test user should be able to read | 16:14 |
| cachio_ | zyga, yes | 16:15 |
| cachio_ | 0022 and 0077 | 16:15 |
| zyga | well that looks like it | 16:16 |
| * zyga boots f27 | 16:18 | |
| zyga | I need to install f28 now | 16:18 |
| zyga | why does everything hurt today, ouch | 16:18 |
| cachio_ | hehee | 16:19 |
| cachio_ | it it the weather | 16:19 |
| zyga | it feels like a flu | 16:19 |
| pstolowski | pedronis: ugh, that auto connect conflict logic needs to be even more complex than what you suggested in the comment to the PR (i think). i think we need that FindSnapsWaitingFor helper i had before | 16:19 |
| zyga | the weather is perfect, it's close to 30C and very sunny all day (weeks) long | 16:19 |
| cachio_ | nice, 26C here | 16:21 |
| cachio_ | but winter is comming | 16:21 |
| zyga | here's still spring, I wonder how summer will look like | 16:21 |
| zyga | 30C during daytime, 17 at night | 16:21 |
| cachio_ | it will be hot | 16:22 |
| zyga | I hope summer time will be more wet | 16:24 |
| zyga | there are a lot of forest fires otherwise | 16:24 |
| zyga | and when it is wet and hot there's an explosion of mushroom to pick | 16:24 |
| cachio_ | hehehe | 16:24 |
| cachio_ | be careful | 16:24 |
| zyga | I will spend most of school holidays with my parents a bit north of here, with the kids | 16:25 |
| cachio_ | there are poisoned ones | 16:25 |
| zyga | nowadays with LTE anywhere it's really not a problem | 16:25 |
| zyga | and with the upgraded data cap (1TB) I won't have to think twice about data | 16:25 |
| zyga | yes, you have to be careful | 16:25 |
| zyga | I only pick those that I always picked as a child | 16:25 |
| cachio_ | well, here if you leave the city the LTE connection is pretty bad | 16:26 |
| zyga | there are several very safe species | 16:26 |
| zyga | outside of cities you usually get 3/4G | 16:26 |
| sil2100 | mvo: heh... it looks like the VM is not the problem - seems like by default is doesn't seem to be able to build the snap correctly on anything below bionic | 16:26 |
| zyga | I've been to the same place in 2016 (when I still had a MacBook for work) | 16:27 |
| sil2100 | mvo: mismatch between libc in the part itself and the one on the system | 16:27 |
| zyga | but this time I have a better modem so I think it will be ok | 16:27 |
| sil2100 | (or something similar) | 16:27 |
| zyga | and they keep expanding the network to cover more roads connecting bigger cities so I may even get LTE now | 16:27 |
| cachio_ | you have a 1TB plan ? | 16:27 |
| zyga | cachio_: yes | 16:27 |
| cachio_ | that's pretty good | 16:28 |
| zyga | cachio_: it's a data plan, it costs about 20 euro a month | 16:28 |
| zyga | no phone calls included | 16:28 |
| sil2100 | mvo: I was just able to snap core18 correctly on a bionic VM - too bad travis doesn't seem to support bionic, it tries to pull things from precise in that case | 16:28 |
| zyga | cachio_: my phone plan is different but I don't know what it is really, it came with a free sim for a laptop that gives me extra 100GB | 16:28 |
| cachio_ | zyga, zyga, it is pretty chip | 16:29 |
| zyga | cachio_: and I still use my Spanish SIM which has 12GB of roaming everywhere so I stick to it instead of switching | 16:29 |
| cachio_ | hehee | 16:29 |
| cachio_ | zyga, conectivity here is expensive and not good | 16:29 |
| cachio_ | 10GB is about 40 euroos | 16:30 |
| zyga | ouch! | 16:30 |
| zyga | I wonder if my roaming would work there | 16:30 |
| zyga | (the one from Vodafone.es) | 16:30 |
| mvo | sil2100: hm, hm, ok. thats really unfortunate. but also slightly strange because I can "snapcraft cleanbuild" core18 and that will use a xenial lxd container unless I'm confusing things | 16:35 |
| zyga | Chipaca: lol, https://www.bleepingcomputer.com/news/technology/npm-fails-worldwide-with-err-418-im-a-teapot-error/ | 16:37 |
| Chipaca | zyga: ¯\_(ツ)_/¯ | 16:37 |
| cachio_ | mvo, could you reproduce any of those errors? | 16:38 |
| sil2100 | mvo: I didn't know about cleanbuild! | 16:38 |
| sil2100 | Let me experiment with that one | 16:38 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | cachio_: fedora 28 installing now | 16:42 |
| cachio_ | zyga, great | 16:43 |
| niemeyer | jdstrand: Not intentional, looking into it | 16:44 |
| sil2100 | mvo: how do you run snapcraft cleanbuild so that the snapcraft inside the container is run with root? Since I seem to be getting errors when it's attempting to mknod | 16:45 |
| zyga | cachio_: booting now | 16:46 |
| zyga | cachio_: f28 umask is 0002 | 16:47 |
| cachio_ | mmm | 16:48 |
| cachio_ | zyga, you mean in desktop? | 16:48 |
| zyga | yes | 16:49 |
| cachio_ | in my desktop too | 16:50 |
| cachio_ | but in the cloud image is different | 16:50 |
| cachio_ | and the umask for root? | 16:51 |
| cachio_ | 0022? | 16:52 |
| zyga | ah, root is 0022 | 16:52 |
| niemeyer | jdstrand: We lost the plugin on the upgrade | 16:52 |
| cachio_ | so I should chnage deafult nmask in the google image and that's it? | 16:53 |
| cachio_ | umask | 16:53 |
| zyga | cachio_: I think we should handle this in spread.yaml | 16:54 |
| zyga | as otherwise we will get a "magic" image that is not representative of fedora | 16:54 |
| cachio_ | zyga, ok, I'll add that to the PR in that case | 16:54 |
| zyga | cachio_: note that on f27 the same umask is used | 16:55 |
| zyga | 0022 for root, 0002 for user | 16:55 |
| niemeyer | jdstrand: deej will bring it back this afternoon | 16:57 |
| jdstrand | niemeyer: cool, thanks! :) | 16:57 |
| kyrofa | Hey Chipaca, give me some love: https://forum.snapcraft.io/t/snapd-rest-api-expose-bind-mount-root-in-tried-snaps/5608 | 17:07 |
| Chipaca | kyrofa: just looking into that | 17:07 |
| kyrofa | Chipaca, ha! | 17:07 |
| kyrofa | Hey niemeyer, mind if I schedule a quick chat about https://forum.snapcraft.io/t/fixing-the-snapcraft-cache-lp-1582469/4127 ? | 17:07 |
| sil2100 | mvo: btw. I'm constantly wondering, is the part name 'boostrap' a typo or is it intentional? ;) | 17:08 |
| cachio_ | zyga, so, in fedora 28 image the umask is ok | 17:13 |
| cachio_ | 0022 | 17:13 |
| zyga | cachio_: hold on, as root or as user? | 17:13 |
| cachio_ | but then I updated it to make the selimux permissive and the umask went to 0077 | 17:14 |
| cachio_ | as root | 17:14 |
| cachio_ | I did dnf makecache and dnf upgrade -y | 17:14 |
| zyga | that's ... weird | 17:15 |
| zyga | what did you do to make selinux permissive? | 17:15 |
| cachio_ | and reboot | 17:15 |
| cachio_ | sed -i 's/SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config | 17:15 |
| * zyga tries | 17:16 | |
| niemeyer | kyrofa: Not at all, thanks for that | 17:20 |
| zyga | cachio_: rebooting | 17:22 |
| * niemeyer => break | 17:22 | |
| zyga | cachio_: I changed SELINUX to permissive and rebooted, umask wasn't affected | 17:23 |
| zyga | cachio_: there must be another modification at play | 17:23 |
| cachio_ | zyga, I'll regenerated the fedora image | 17:25 |
| cachio_ | same than yesterday but without reboot | 17:26 |
| cachio_ | checking how it was generated | 17:26 |
| cachio_ | zyga, it is the same | 17:27 |
| zyga | meaning? it's the same as mine or the same as yours before the regexen? | 17:27 |
| zyga | regeneration | 17:27 |
| cachio_ | 0077 after the regeneration | 17:28 |
| zyga | hmm | 17:29 |
| zyga | this was based on the cloud image? | 17:29 |
| zyga | I will try that | 17:29 |
| zyga | how do you make the image? | 17:29 |
| cachio_ | now I am running a regeneration which just changes the selinux config bht it is not updating | 17:29 |
| cachio_ | the base fedora 28 image it is already created | 17:29 |
| zyga | how was it created? | 17:30 |
| cachio_ | with this script | 17:30 |
| cachio_ | https://github.com/snapcore/spread-images/blob/master/tasks/google/add-fedora-28-64/task.yaml | 17:30 |
| zyga | thanks | 17:31 |
| zyga | I'm pulling the same disk now | 17:32 |
| cachio_ | zyga, so, using the fedora 28 image | 17:36 |
| cachio_ | which has umask 0022 for root | 17:36 |
| mvo | sil2100: *cough* typo but funny | 17:37 |
| cachio_ | zyga, wait | 17:37 |
| cachio_ | I think I know which is hte issue | 17:37 |
| zyga | :-) | 17:38 |
| zyga | I just booted the image | 17:38 |
| mvo | cachio_: I had no luck with the missing symlinks, but I ran manually not from your script. I didn't manage to try the second one unfortunately | 17:38 |
| cachio_ | on the cleanup we are deleting /root/.bashrc | 17:38 |
| mvo | sil2100: iirc it is run as root | 17:38 |
| zyga | oh | 17:38 |
| cachio_ | mvo, ok, I'll try again with the latest changes | 17:39 |
| cachio_ | mvo, it is weird beause it failed in all the runs the symlink test | 17:40 |
| mvo | cachio_: yeah, I can try from the script in the morning | 17:40 |
| cachio_ | zyga, I am regenerating the image without deleting the .bashrc | 17:40 |
| pedronis | pstolowski|afk: mmh, we are probably talking past each other if there's a relevant link-snap there is probably also an auto-connect task | 17:45 |
| pedronis | which would make us ignore the former | 17:45 |
| pedronis | pstolowski|afk: we can talk again tomorrow morning, I might be missing something | 17:47 |
| jdstrand | roadmr: hi! would you mind pulling r1081 or the review tools? it isn't terribly urgent, but sooner is better than later (it isn't an emergency though) | 17:50 |
| jdstrand | ogra_: fyi, you probably got these, but I saw that 'Store authorization failed for linux-generic-bbb' | 17:51 |
| cachio_ | zyga, that was the problem | 17:52 |
| cachio_ | zyga, I regenerated the image and umask is 0022 | 17:52 |
| cachio_ | the issue was that it was cleaning the /root/.bashrc | 17:53 |
| cachio_ | this cleanup is pretty old | 17:53 |
| cachio_ | it comes from linode | 17:53 |
| cachio_ | zyga, something changed on that file on fedora 28 | 17:54 |
| zyga | cachio_: yes, that file just sources /etc/bashrc which sets umask | 18:11 |
| om26er | Chipaca: Hi! got a minute ? | 18:12 |
| om26er | its about `http` snap, a feature request :) | 18:12 |
| mup | PR snapd#5227 opened: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5227> | 18:22 |
| mup | PR snapd#5228 opened: interfaces/hardware-observe: allow access to /etc/sensors* for libsensors (2.33) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5228> | 18:24 |
| jdstrand | niemeyer: hey, if you have a moment to look at https://github.com/snapcore/snapd/pull/4951, I implemented your changes last week | 18:40 |
| jdstrand | your requested* | 18:40 |
| mup | PR #4951: interfaces/screenshot: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951> | 18:40 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| cachio_ | zyga, this change fixed all the failing tests on fedora 28 :) | 18:48 |
| cachio_ | zyga, thanks for the support | 18:48 |
| zyga | Woot, Thank you :-) | 18:48 |
| Pharaoh_Atem | wut? | 18:49 |
| Pharaoh_Atem | wut the wut? | 18:49 |
| Pharaoh_Atem | what happened? | 18:49 |
| === Beret- is now known as Beret | ||
| === grumblr is now known as grumble | ||
| zyga | Bad rm nuked bashes | 18:54 |
| zyga | Bashrc | 18:54 |
| === Kamilion|ZNC is now known as Kamilion | ||
| mup | PR snapd#5229 opened: interfaces: add juju-client-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5229> | 18:55 |
| Pharaoh_Atem | zyga: ah | 18:58 |
| Pharaoh_Atem | zyga: what's going on here? https://github.com/snapcore/snapd/pull/5219#issuecomment-392899258 | 18:58 |
| mup | PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219> | 18:58 |
| mup | PR snapcraft#2144 closed: lifecycle: automatically stage dependencies <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2144> | 19:08 |
| niemeyer | jdstrand: ouch.. I didn't realize the details of the interface | 19:10 |
| Pharaoh_Atem | zyga: Flock 2018 has been announced | 19:13 |
| Pharaoh_Atem | Dresden, Germany this time: https://flocktofedora.org/ | 19:13 |
| zyga | Oooh | 19:13 |
| zyga | Count me in then | 19:14 |
| zyga | I will plan the trip and come | 19:14 |
| zyga | We need to present bases :-) | 19:14 |
| niemeyer | jdstrand: This is such a bad API | 19:15 |
| niemeyer | :( | 19:15 |
| sergiusens | kyrofa: commented on https://github.com/snapcore/snapcraft/pull/2145/files | 19:17 |
| mup | PR snapcraft#2145: lifecycle: automatically clean dirty steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2145> | 19:17 |
| zyga | Pharaoh_Atem: https://github.com/snapcore/snapd/pull/5219/files#r191545658 | 19:30 |
| mup | PR #5219: packaging/opensuse: Refactor packaging to support all openSUSE targets <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5219> | 19:30 |
| sergiusens | kyrofa: I have a minor request and a non mandatory counter-proposal that brings an implicit behavior most people seem to expect (ordered yaml) | 19:38 |
| sergiusens | that's for snapcraft#2146 | 19:39 |
| mup | PR snapcraft#2146: project_loader: process parts in consistent order <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2146> | 19:39 |
| jdstrand | niemeyer: yeah. at least it is manually connected... :\ | 19:44 |
| Pharaoh_Atem | zyga: but openSUSE uses /run/media | 19:44 |
| zyga | let's not change that now, we can tweak it (perhaps set it conditionally) and fix the test | 19:45 |
| niemeyer | jdstrand: Yeah, but it feels too misleading | 19:46 |
| niemeyer | jdstrand: It's an awkward precedent | 19:46 |
| Pharaoh_Atem | zyga: so the test has always been wrong then? | 19:46 |
| niemeyer | jdstrand: So the interface allows saving files *anywhere*? | 19:46 |
| jdstrand | niemeyer: we can say "no, we won't support this. wait for portals" | 19:46 |
| niemeyer | I mean, anywhere the uid calling the API has access to, I suppose | 19:46 |
| zyga | Pharaoh_Atem: perhaps it was right before, are you sure opensuse used /run/media? | 19:47 |
| Pharaoh_Atem | Yep | 19:47 |
| Pharaoh_Atem | openSUSE Leap 42.x, 15.0, and Tumbleweed use /run/media | 19:47 |
| jdstrand | niemeyer: yes. there is some default actions but the dbus api allows specifying the outpath. we can't mediate that in apparmor because it is member data. gnome-shell would have to mediate it with the libapparmor query api to mediate it properly | 19:47 |
| zyga | in that case the test will need tweaking | 19:48 |
| jdstrand | niemeyer: and yes, anywhere the unconfined gnome-shell is allowed to write to | 19:48 |
| Pharaoh_Atem | the switch that changes this for debian (https://salsa.debian.org/utopia-team/udisks2/blob/master/debian/rules#L13), is not set in openSUSE: https://build.opensuse.org/package/view_file/Base:System/udisks2/udisks2.spec?expand=1 | 19:48 |
| Pharaoh_Atem | they switched to /run/media in 2012 | 19:52 |
| jdstrand | niemeyer: it is probably worth reiterating (this was mentioned in the forum) that this gnome-shell api is intended to be a temporary api unitl the pipewire (screencast) and a proper portals screenshot api was in place | 19:54 |
| niemeyer | jdstrand: I feel pretty bad for saying this now, but I think you had it right the first time around, and I didn't realize because I missed those details | 19:56 |
| jdstrand | niemeyer: that said, it has been a long time and screencasting doesn't work yet with pipewire | 19:56 |
| niemeyer | jdstrand: To be clear, I feel bad not because I was wrong, but because you spent time on it | 19:56 |
| jdstrand | niemeyer: well, the it's a weird access. I mean, desktop-legacy already has some terrible stuff, but desktop-legacy is auto-connected. I think the question is do we want this to be autoconnected or not | 19:57 |
| niemeyer | jdstrand: Still, the open path writing is still something that raises eyebrows even in legacy desktop | 19:57 |
| niemeyer | jdstrand: Do we have an equivalent access there? | 19:57 |
| jdstrand | niemeyer: no. just full keyboard sniffing and injection. you know, nothing that bad :P | 19:57 |
| jdstrand | (accessibility) | 19:58 |
| niemeyer | Well, it's just about expectations.. X11 is what it is | 19:58 |
| jdstrand | niemeyer: and don't feel bad. it doesn't take long to shuffle stuff around | 19:58 |
| jdstrand | well yes | 19:58 |
| jdstrand | x11 is one thing, but desktop-legacy doesn't have x11 | 19:59 |
| jdstrand | it is theoreticlly possible to plugs: [ desktop, desktop-legacy, wayland ] | 19:59 |
| niemeyer | jdstrand: Are both APIs exposed in the same term (screencast and screenshot)? | 19:59 |
| niemeyer | same terms | 19:59 |
| jdstrand | niemeyer: we can differentiate between screenshot and screencast. both have the same issue with outpath | 19:59 |
| niemeyer | Hmmm | 20:01 |
| jdstrand | perhaps to confuse things further, X allows screen grabs (screenshot) via the X protocol. gnome-shell is exposing these mostly for the benefit of wayland, but you can use this dbus api under X if you want | 20:02 |
| mup | PR snapcraft#2145 closed: lifecycle: automatically clean dirty steps <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2145> | 20:02 |
| jdstrand | but you had it right the first time. it is a terrible api. I think the idea is that they added it to gnome-shell since it is no worse than X. since mutter isn't a complete X replacement yet, they probably figured they'd fix this in the fullness of time with portals | 20:04 |
| jdstrand | I'm guessing, but I can easily imagine that is how the conversation went | 20:04 |
| niemeyer | jdstrand: Indeed | 20:05 |
| niemeyer | jdstrand: Okay, let's sleep on that one.. the brain isn't yielding any great ideas right now | 20:06 |
| jdstrand | niemeyer: sure, np. I'm kinda leaning towards the manually connected separate interface atm, but we can continue thinking about it | 20:06 |
| niemeyer | In fact, I'll probably do that literally.. woke up somewhat early and I need a nap to refresh a bit | 20:07 |
| jdstrand | hehe | 20:07 |
| jdstrand | have a nice rest :) | 20:07 |
| niemeyer | Thanks :) | 20:07 |
| jdstrand | it's super-annoying to wake up early and not be able to get back to sleep | 20:07 |
| mup | Issue # closed: snapcraft#100, snapcraft#1438, snapcraft#1440, snapcraft#1441, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1455, snapcraft#1456, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1463, snapcraft#1465, snapcraft#1467, snapcraft#1468, | 20:08 |
| mup | snapcraft#1469, snapcraft#1476, snapcraft#1477, snapcraft#1502, snapcraft#1658, snapcraft#1660, snapcraft#1665, snapcraft#1677, snapcraft#1678, snapcraft#1679, snapcraft#1696, snapcraft#1701, snapcraft#1705, snapcraft#1706, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794, | 20:08 |
| mup | snapcraft#1882, snapcraft#1887, snapcraft#1921, snapcraft#1932, snapcraft#2001, snapcraft#2027, snapcraft#2032, snapcraft#2048, snapcraft#2118, snapcraft#2133, snapcraft#2134, snapcraft#2136, snapcraft#2137 | 20:08 |
| Chipaca | om26er: here now | 20:52 |
| sergiusens | kyrofa et.al catch you later in the night | 20:57 |
| * sergiusens is off to aikido practise | 20:57 | |
| mup | PR snapd#5230 opened: interfaces/udisks2: also implement implicit classic slot <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5230> | 20:58 |
| om26er | Chipaca: I am making a form-data post request that uploads a file and it gives permission denied. So maybe if the http snap added `home` interface, things will get more usable. | 21:49 |
| mup | PR snapd#5231 opened: interfaces/joystick: force use of the device cgroup with joystick interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5231> | 22:01 |
| Chipaca | om26er: noted. Meanwhile you can use bash's process substitution | 22:50 |
| Chipaca | om26er: e.g. foo=@<( cat the-file.json ) | 22:51 |
| om26er | Chipaca: Thanks, in this case its a png file, will see how that goes. | 22:51 |
| === erio is now known as erio|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!