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