=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === iMadper is now known as Madper|SaltedFis === Madper|SaltedFis is now known as SlatedFishMadper [02:56] hmm has anyone talked about making the netplan config part of the core snap's config recently? [02:56] the point of that being that a gadget could then override the default [02:56] wrong time of day for this conversation i guess [04:59] PR snapd#3195 opened: interfaces/builtin: allow full access to properties iface of the udisks service [07:09] morning [07:15] PR snapd#3185 closed: snap: added tasks subcommand [08:04] good morning [08:05] sory for being late [08:05] pstolowski: hey [08:06] hi zyga ! [08:06] * zyga is sleepy a little [08:07] I was sleeping outside in a tent [08:08] mvo: I fixed a bug in running snap-confine from core [08:08] morning all [08:08] mvo: and now https://github.com/snapcore/snapd/pull/3149 is green and can land [08:08] PR snapd#3149: cmd: make locking around namespaces explicit [08:08] Son_Goku: good morning :-0 [08:08] :-) [08:08] I woke up at midnight :/ [08:08] PR snapd#3193 closed: interfaces/mount: parse mount options to map[string]string [08:08] mvo: please review that branch and we can use it as a base for your earlier work on /snap sharing [08:08] zyga: PR 3149 isn't going to cause it to stop using snap-confine from the host distro, is it? [08:09] because that's a problem [08:09] Son_Goku: using snap-confine from host distro is tied to reexec now [08:09] okay, so the answer is no in my case [08:09] PR snapd#3196 opened: tests: ensure we mock force dev mode as well to fix FTBFS in sbuild [08:09] Son_Goku: right [08:10] Son_Goku: it is related to having snapd work in containers and in other places where / is not rshared [08:10] zyga: sure, looking [08:10] Son_Goku: so /snap or /var/lib/snapd/snap is also not rshared [08:10] right [08:10] I'm aware of that little issue [08:10] mvo: it's nothing urgent but I just wanted to let you know the tests are green there and we could progress [08:10] it's what prevents things like snapd from running in docker or flatpak [08:11] Son_Goku: it should be fixed soon :) [08:11] (maybe today) [08:12] Son_Goku: the fix is easy we just needed to do something to make initialization not racy [08:12] Son_Goku: hence locking ;) [08:12] right [08:12] it also is a nice step towards making snapd work in unprivileged contexts [08:13] zyga: what bug did you fix in running snap-confine from core? is that in already? [08:14] mvo: it was a simple one liner, it only affected tests [08:14] mvo: let me find it [08:14] https://github.com/snapcore/snapd/pull/3194 [08:14] PR snapd#3194: tests: copy snap-confine apparmor profile into testbed [08:15] zyga: ta [08:16] offtopic, github added support for project tags [08:17] e.g. we could add "packaging" to snapd [08:18] PR snapd#3186 closed: tests: allow installing snapd from -proposed for SRU validation [08:21] zyga— also "awesomeness" [08:21] good morning [08:21] Chipaca: good morning :) [08:22] Chipaca: what's up? :) [08:22] not me [08:22] * Chipaca 's back is acting up again [08:23] Chipaca: :-( [08:23] I know the pain :( [08:24] uhhh@chipaca [08:24] * mvo hugs Chipaca [08:24] mvo— good morning sah! [08:25] Chipaca: good morning to you as well! [08:29] davidcalle: https://github.com/CanonicalLtd/snappy-docs/pull/69 [08:29] PR CanonicalLtd/snappy-docs#69: Update Arch Linux status [08:32] that's a sad change [08:32] but well [08:33] btw, do we duplicate the wiki and the table there? [08:33] maybe we should just redirect [08:33] the wiki has more details than the website does [08:34] and I fully expect _every_ distribution to enforce this change soon [08:34] I've already spoken to some of my counterparts in other distros about this, which is why I keep telling you it'll happen :P [08:35] i've little emergency here. need to take my daughter to the dentist.. bb in ~1h [08:35] and I've already updated the wiki accordingly: https://github.com/snapcore/snapd/wiki/Distributions [08:37] PR snapd#3197 opened: store: retry on connection reset too [08:37] Son_Goku: I think this is couter-productive [08:37] Son_Goku: I'd only do it after we have better classic confinement [08:38] Son_Goku: the FHS is not some nagic sacred unicorn, it's not worth removing features over [08:38] I just want to avoid the back and forthiness and the complexity of directory migrations [08:38] it's a pain and we're lucky to have avoided it in Fedora [08:38] the poor Arch guys don't have fancy transaction scriptlets like we do, so everything is harder [08:38] Son_Goku: it's not a pain, it's just stubborn people [08:39] Son_Goku: really, nobody normal cares about this, this is just geeks disageeing on niche stuff [08:39] Son_Goku: (but reversing decision has negative consequences) [08:39] nobody normal cares about Linux [08:39] so that's a really bad argument to use with me :) [08:39] nobody uses android right [08:39] Son_Goku: I disagree [08:39] fine, GNU+Linux [08:40] seb128: snapd can't run on Android anyway [08:40] Son_Goku: nobody using android (great point seb128) cares about the FS layout there [08:40] no SELinux support, and alternate filesystem layout isn't supported either [08:40] Son_Goku: and it's not the "blessed" and "only correct" FHS [08:40] I'm not saying it is [08:40] saying "nobody cares about X" to somebody that cares about X is not how you win an argument with them, FWIW [08:40] but breaking people's expectations isn't good either [08:40] Son_Goku: so what you are doing is IMO harmful, why go to this effort if we're not ready to switch? [08:40] I did not change Arch Linux [08:40] Son_Goku: breaking something that worked is also not good :) [08:40] someone else already did [08:41] Son_Goku, it's funny how fedora doesn't care about the FHS when it comes to udisks and mountpoints but now you do when it's snapd... [08:41] seb128: what are you talking about? [08:41] Son_Goku: notre, thank you, should go live today [08:41] noted* [08:41] udisks mountpoints are ephemeral, which is why they're in /run in the first places [08:41] it's weird, yes [08:41] but whatever [08:42] Son_Goku, https://bugs.freedesktop.org/show_bug.cgi?id=51709 [08:42] Son_Goku, it's also not FHS compliant [08:42] seb128: at least you're not breaking people's ability to back up their whole system [08:44] * Son_Goku shrugs [08:44] I love this comment https://bugs.freedesktop.org/show_bug.cgi?id=51709#c7 [08:44] I didn't particularly like this either [08:44] it really does capture the essence of FSH [08:44] it's just old stuff that who that can commit can change at will [08:45] and any that innovate can just ignore as old [08:45] Son_Goku, right, but if it's coming from fedora it's fine but if it's coming from somebody else it's not, great double standards right? [08:45] ENOSACREDCOWINFHS [08:45] seb128: no, it's not fine regardless [08:45] but still fedora did it [08:45] and like then, I can't convince you to change anything [08:45] didn't reverse patch upstream [08:48] well, apparently no one ever complained about it in rhbz [08:48] I guess if someone complained, then something might happen [08:48] when I complained about the ovirt guys doing it, their packages got backed out of the distribution [08:50] k, anyway I was just making a comment about those double standards which are a bit sad, no point going over that for an hour, sorry for the noise === chihchun_afk is now known as chihchun [08:53] seb128: if I really wanted to get into that mess, I would bitch about Debian "multi-arch" [08:53] I've pretty much let it go [08:53] I've had my fair share of complaints about FHS [08:54] them intentionally ignoring /usr/libexec which led to Debian and openSUSE spending literally over a year moving everything into the wrong place [08:54] I think it's time for second breakfast [08:55] and not specifying sysroot style FHS as being a valid mechanism (that is, /usr//{bin,lib})... [09:06] davidcalle: where's the source for the home page: https://snapcraft.io/ [09:07] Son_Goku: https://github.com/canonical-websites/snapcraft.io/blob/master/index.html [09:07] geez [09:07] why can't everything be in one place :( [09:12] Given the amount of teams involved in the snapcraft ecosystem and also involved in many other projects, it's a trade off between having a similar workflow for everything a team is working on and having everything in one place. In this case, Canonical websites follow a specific org structure, because the people building and maintaining them work in a specific [09:12] way. [09:20] zyga: hm, master is unhappy right now, looks like its related to 3194 [09:21] zyga: I'm looking at this now [09:23] mvo: sorry, I'm in a call [09:24] zyga: np [09:27] davidcalle: meh... we need something to know where stuff is [09:27] it's really aggravating because I know they're forkable, I just don't know where they are [09:28] anyway... [09:28] davidcalle: https://github.com/canonical-websites/snapcraft.io/pull/305 [09:48] PR snapd#3190 closed: Change default options for Arch Linux [09:50] do we have a fedora image for spread under qemu? [09:50] Son_Goku— ^ maybe you know? [09:52] re [09:52] Chipaca: no, I don't think we do [09:52] mvo: what's the status of 3194 [09:53] zyga: ignore me for now, maybe I was reading the output wrong, I'm running a local test now [09:54] zyga— isn't that merged? [09:54] aha [09:54] Chipaca: yes, I think mvo found a potential issue with it though [09:54] ah [09:54] zyga: yeah, but maybe I'm wrong and I was just confused by the output. sorry for the noise (maybe) [09:54] fedora's "reboot & install" is weird. Also, takes forever. [09:55] Chipaca: reboot & install? [09:55] rpm used to beat deb-based on speed; what happened? [09:55] zyga— "upgrades are available; reboot & install?" [09:56] Chipaca: aha [09:56] Chipaca: that's the new systemd way of updating [09:56] Chipaca: you reboot, it installs everything in a controlled environment, [09:56] Chipaca: and it reboots back [09:56] in the time since i commented it's gone from 55% to 56% [09:56] Chipaca: I honestly still just "dnf update" [09:57] I am wearing my newbie hat, here [10:09] hmm, getting selinux alerts about snapd trying to access /home [10:10] also about snapd tyring to access ld-linux-x86-64.so.2 [10:19] Chipaca: yes [10:19] Chipaca: those are complain moe [10:19] Chipaca: I started filing bugs about this [10:19] Chipaca: but we really should sit through one session [10:20] Chipaca: and write a meaty patch to the policy [10:20] Chipaca: there are tools that mostly generate the policy for you [10:20] Chipaca: so it shouln't be hard to fix 80% (hand-wavy estimate) of those quickly [10:23] zyga— ok [10:24] zyga— good thing these are complain, otherwise nothing would work [10:24] OTOH i also get the same thing for systemd and systemctl trying to do stuff [10:25] e.g. systemctl creating a .mount [10:26] and systemd reading the current symlink [10:26] mvo, thanks for hacking around retry code! [10:32] pstolowski: my "pleasure" ;) [10:33] pstolowski: this one is hard to test [10:34] mvo, yeah, I agree [10:34] Chipaca: yes, there's plenty of them; I don't know if all the fixes can go into the snapd policy; perhaps some must be made in the upstream policy [10:57] mvo, mind giving a second ack on https://github.com/snapcore/core-build/pull/5 [10:57] PR core-build#5: Update cloud-init configuration [11:05] tvoss: hey, do you know why in my 14.04, every time I reboot the snap `core` and others are marked as broken? [11:05] I need to reinstall int all the time... [11:08] ogra_: sure, I have a look [11:08] zhx [11:11] zyga— is snapd built differently in fedora, or is libexec autodetected? [11:12] if it's the latter, then everything works wrt snapd#3150 [11:12] PR snapd#3150: In-snap bash tab completion [11:14] And now.... error: cannot install "core": snap type unset [11:19] Chipaca, zyga: I already started looking into those denials on fedora but one after another :-) [11:19] PR core#35 opened: move xdg-open to proper paths [11:21] there isn't a way to know libexec from bash, is there? [11:21] PR snapcraft#1257 closed: core: support running from other operating systems [11:22] nm ignore me [11:22] :-) [11:22] * Chipaca looking at too many things, got confused for a mo' === JanC_ is now known as JanC [11:42] zyga, pedronis, you both kinda-half reviewed #3150; could you finish it? [11:49] Chipaca: yes [11:49] Chipaca: I just finished throwing something together [11:49] Chipaca: let me open a few PRs and I'll get to it [11:51] PR snapd#3198 opened: interfaces/mount: pass mount.Profile to mount.NeededChanges [11:54] PR snapd#3199 opened: interfaces/mount: add stub Change.{Needed,Perform} [11:55] PR snapd#3200 opened: interfaces/mount: add Change.String for readable output [11:55] there [11:55] Chipaca, mvo: I'll make a coffee and resume reviewing [11:56] mvo, pstolowski, Chipaca: I would appreciate if you can land the stub PR (3199) as this will allow me to propose the actual algorthim behind update-ns [11:56] Chipaca: have a couple for a review? [11:56] Chipaca: https://github.com/snapcore/snapcraft/pull/1260 [11:56] PR snapcraft#1260: meta: version from git support [11:57] sergiusens— we need to talk about completion from snapcraft [11:57] Chipaca: completion as in being feature complete or something more scoped? [11:57] sergiusens— yes [11:58] sergiusens, you dont forget about my override requirements when doing this, right :) [11:58] ogra_: that comes next, it is rather easy (version-script to run after everything is in stage) [11:58] cool ! [11:58] thanks [11:59] by which I guess we will do it when everything is primed [11:59] to not be all spread out in the lifecycle [12:02] Chipaca: so, when or where do you want to discuss this? [12:02] sergiusens— reviewing this thing first [12:02] ok, thanks! [12:02] sergiusens— but after that? although i should have lunch before the standup which is at 2 [12:04] ok, whenever you want or forum post it :-P [12:25] re [12:49] uh oh CheckChangeConflict in Disconnect() doesn't really do a thing if snap/plug/slot names are omitted [12:54] niemeyer: ping [12:55] PR snapd#3199 closed: interfaces/mount: add stub Change.{Needed,Perform} [13:26] PR snapd#3157 closed: store: add more logs around retry in download [13:36] Chipaca: theresa may seeks "snap election" [13:36] Chipaca: snap find election [13:36] zyga— IKR [13:36] IKR? [13:36] totally [13:38] Chipaca: can you "snap revert brexit"? [13:40] zyga— you're just being mean, now [13:45] Chipaca: snap install humor [13:45] Chipaca: I just saw you laughing in the hangout [13:45] :-) [13:45] niemeyer— given the 2009 date of the bug, "soon" could mean 2021 [13:46] zyga— I always laugh when I confirm that everything is terrible [13:46] it's the only way to do it [13:47] Chipaca: Yes! :) [13:47] renatu: Heya [13:48] niemeyer, hey [13:48] renatu: Missed your topics in the forum.. am I blind or did you manage to get a fix? [13:48] * zyga gets to reviews [13:48] niemeyer, sorry what topic exactly? [13:49] renatu: Related to the conversation we had here yesterday [13:49] niemeyer, I do not remember that, probably you talk with another person :D [13:50] renatu: Most probably! 8) [13:50] renatu: Sorry.. :) [13:50] np [13:50] Yes, "renat" vs. "renatu".. :) [13:55] PR snapd#3196 closed: tests: ensure we mock force dev mode as well to fix FTBFS in sbuild [13:56] sergiusens, anybody, mind to explain me the difference between snapcraft tests: [static|unit|integration|snaps] ? (basically, which should be run in which situations) thanks [13:56] * Facu promises to add this explanation to the HACKING.md doc [14:00] niemeyer: ping [14:00] morphis: Heya [14:01] niemeyer: hey! [14:01] niemeyer: you saw my post in the forum about a linode auth key? [14:02] niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250/3 [14:02] morphis: No, I still need to go through this morning's forum posts [14:03] morphis: Will get you a key for usre [14:03] sure [14:03] niemeyer: thanks, will wait then :-) [14:03] niemeyer: just wasn't sure if you're the right one for this [14:31] Bug #1683823 opened: snapcraft list-revisions showing multiple publications in the same channel [14:34] Facu: you want to talk to elopio; but the gist of of; static->flake8; unit-> no-builds; integration->shells to snapcraft, builds; snaps-> builds snaps, installs and checks how they run === chihchun is now known as chihchun_afk [14:35] sergiusens, thanks [14:36] PR snapd#3200 closed: interfaces/mount: add Change.String for readable output [14:36] PR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) [14:37] Bug #1683827 opened: snapcraft list-revisions strip trailing 0's from versions [14:41] PR snapd#2969 opened: interfaces: mediate netlink sockets via seccomp [14:46] Pharaoh_Atem: did you check those SELinux denials for snapd already? [14:52] Bug #1683827 changed: snapcraft list-revisions strip trailing 0's from versions [15:07] Lunch, biab [15:08] niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250/6 [15:08] niemeyer: not sure for how long the machines stay when I've used -reuse [15:09] mvo: there is something odd in tests [15:10] mvo: I just saw this failure: https://travis-ci.org/snapcore/snapd/builds/223175451#L860 [15:11] + cp -a /etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/usr.lib.snapd.snap-confine.real squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real [15:11] cp: target 'squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real' is not a directory [15:11] first of all, why there are both .real and old files there and why is something a directory?! [15:13] the cp command tries to copy two files ... [15:13] ... so the target path needs to be a dir [15:13] aaaha [15:13] thanks! [15:13] so [15:13] on 14.04 it is the plain file [15:13] on 16.04 it is the .real file [15:13] so I used a * to get both [15:14] ah [15:14] but why do we get both at once now? [15:14] anyway, I think the rule needs tweaking [15:14] s/rule/command/ [15:17] mvo: https://github.com/snapcore/snapd/pull/3202 [15:17] PR snapd#3202: tests: handle case when both .real and plain are present [15:17] ogra_: https://github.com/snapcore/snapd/pull/3202 :-) [15:18] PR snapd#3202 opened: tests: handle case when both .real and plain are present [15:19] zyga, if both files are existing they will both end up in target though ... is that what you want ? [15:19] (great solution beyond that) [15:20] yes, that's fine [15:20] or [15:20] ... [15:20] is it? [15:20] gah, I think we only look at one of them [15:25] morphis: I have not, but I will this evening [15:27] ogra_: updated [15:28] Pharaoh_Atem: great! [15:28] Pharaoh_Atem: was trying to find my way through those but if you will have a look I can ignore this for now [15:28] I've been busy with Mageia stuff [15:28] zyga, approved [15:28] morphis: there are more important issues I need you to address, anyway [15:29] getting upstream snapd to build without patches and working with hughsie on gnome-software are both more critical [15:29] I've been going back and forth on whether I should submit a variant of the spec to be included in the snapd git repo [15:30] but if we get down to zero patches, then I can just slightly tweak the one in dist-git so that it can be pulled during spread [15:30] I want to avoid going back and forth with dist-git<->git [15:31] Pharaoh_Atem: yeah I am on that [15:32] Pharaoh_Atem: g-s is lined up and willcooke asked robert to spend time on this [15:32] ogra_: thanks! [15:33] Pharaoh_Atem: you mean spread doing a comparision alerts when both are out of sync? [15:34] morphis: I mean for Fedora dist CI [15:34] one aspect of that is making sure things don't go out of sync, yes [15:35] but another aspect is to make sure the build doesn't get broken [15:35] ok, so you're going to run spread insight the fedora CI? [15:35] I don't know what I'm going to do [15:35] fgimenez— sunc -> sync (on https://forum.snapcraft.io/t/core-snap-delivery-process/314) [15:35] at this point, I'm sorta thinking aloud ;) [15:36]