[06:09] <mborzecki> morning
[06:21] <mup> Bug #1749374 opened: The /bin/sync command is not allowed by default <Snappy:New> <https://launchpad.net/bugs/1749374>
[06:33] <zyga> hey
[06:33] <zyga> mborzecki linode was broken last night
[06:33] <mborzecki> zyga: did we break it?
[06:33] <zyga> I suppose so
[06:34] <zyga> it stopped responding to API requests
[06:34] <mborzecki> haha omg
[06:34] <zyga> let's hope it's not that bad today
[06:35] <mborzecki> zyga: any idea how advanced is the move to GCE or DO?
[07:22] <zyga> mborzecki no, I hope it's under way though
[07:26] <zyga> mborzecki are any of your branches working/
[07:27] <mborzecki> zyga: don't have any new PRs open atm
[07:33] <zyga> I'm running tests in linode and locally to compare
[07:48] <zyga> mborzecki can you please have a look at 4664
[07:48] <zyga> it is designed to unbreak master
[07:48] <zyga> it came out of 4658
[07:48] <zyga> I also pushed it there to show that it fixes things
[07:48] <zyga> (except where linode doesn't work)
[07:49] <mborzecki> looking
[07:50] <zyga> I could move some of the patches out to an even smaller prerequisite branch if that helps
[07:52] <kalikiana> o/
[07:53] <zyga> hey kalikiana
[08:04] <telboon-> hmm. is snap designed to be a fully secured container?
[08:04] <zyga> it depends on what you mean by a container
[08:04] <telboon-> cos i've somehow just escaped the snap and managed to create files outside of the container...i think
[08:04] <zyga> snap apps are not typical containers
[08:04] <telboon-> are they meant to protect the rest of the environment?
[08:04] <zyga> it depends
[08:05] <zyga> it all depends on how you installed the snap, which interfaces you connected to it and what the "outside of the container" really is
[08:05] <zyga> please tell me more and I will try to help you
[08:05] <zyga> if you think this is a security issue you can contact me in private
[08:05] <zyga> or send me an encrypted mail
[08:08] <zyga> telboon- let me know if you need more information
[08:09] <telboon-> zyga: let me try to reproduce it in a few scenarios
[09:15] <zyga> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
[09:15] <zyga> <kill-timeout reached>
[09:15] <zyga> hmm :/
[09:17] <zyga> I see this often but on random tests
[09:20] <Chipaca> with all the verbosity in tests, maybe we should add a -v to that tar :-)
[09:23] <zyga> -vv
[09:23] <zyga> --poem
[09:23] <mvo> zyga: quick question, how far are user mounts away (roughly)? days? weeks?
[09:23] <zyga> mvo days
[09:23] <zyga> mvo but unhappy master is making stuff sad
[09:23] <zyga> or is it just my branch?
[09:23] <zyga> hey mvo, how are you doing?
[09:24] <mvo> zyga: I'm fine thank you
[09:24] <mvo> zyga: yeah, unhappy master makes me unhappy too
[09:25] <mvo> zyga: what error do you see? I also see some strange errors
[09:25] <zyga> timeouts
[09:25] <zyga> but not the ones we saw before
[09:25] <zyga> I see tests reaching 49 minutes
[09:25] <zyga> many linode api errors
[09:25] <zyga> errors on tar (see above) being killed by timeout
[09:25] <zyga> honestly, I don't know what's wrong
[09:26] <zyga> mvo I ran my branch in qemu all the way (though not without hiccups)
[09:26] <mvo> zyga: ok
[09:26] <zyga> but my record on linode is "red since yesterday"
[09:27] <zyga> maybe something is related to nfs, I need to look at that
[09:27] <zyga> + umount /home
[09:27] <zyga> umount.nfs: /home: device is busy
[09:27] <zyga> 2018-02-14 08:26:18 Error restoring linode:ubuntu-16.04-64:tests/main/nfs-support :
[09:27] <zyga> we cannot unmount nfs, then we cannot remove the nfs kernel server package
[09:28] <Chipaca> zyga: and you can't umount home because that's where spread's running
[09:29] <Chipaca> zyga: chroot time?
[09:29] <Chipaca> would that even work
[09:29] <zyga> Chipaca this is not a new test
[09:29] <zyga> look at main/nfs-support
[09:31] <Chipaca> zyga: i see it, but i still wonder it works
[09:31] <Chipaca> zyga: does it hang every time with your changes?
[09:31] <zyga> no
[09:32] <Chipaca> ah drat :-)
[09:32] <zyga> yeah
[09:32] <zyga> so something else depends on ordering
[09:32] <Chipaca> zyga: does it hang every time if you specify the seed of the time it hung?
[09:32] <zyga> maybe my patch is just broken
[09:32] <zyga> I didn't try (~~ hours)
[09:32] <zyga> let's see
[09:32] <Chipaca> zyga: if it's reproducible, you can figure out what's holding it back
[09:33] <Chipaca> zyga: OTOH if it works with any subdir instead of just home, maybe use a subdir in the tests, one that isn't being used by the tests :-)
[09:33] <Chipaca> (but if it works sometimes, maybe figuring out what blocks it when it doesn't is better)
[09:33] <zyga> the unmount earlier should not have failed
[09:33] <zyga> some process is lurking
[09:34] <zyga> but
[09:34] <zyga> this is just one of the failure
[09:34] <zyga> *failures
[09:34] <mwhudson> does anyone here have any Opinions on go 1.9 vs go 1.10 as default in bionic?
[09:34] <zyga> mwhudson I suspect 1.10 is just a bit younger so it will be EOLd later
[09:34] <zyga> mwhudson does go have LTS-like releases?
[09:34] <pedronis> no
[09:34] <mwhudson> right, that's certainly a consideration, and no
[09:35] <pedronis> it's why we should really think how to use newer go
[09:35] <pedronis> for snapd, at some point it will bite us
[09:36] <zyga> using new go is easy, using new go everywhere is hard
[09:36] <zyga> changing base requirement is hard
[09:38] <mborzecki> it will have to happen at some point though
[09:39]  * zyga reproduced nfs error with debug shell
[09:39] <zyga> inspecting
[09:51] <zyga> hmmmmmm
[09:54] <zyga> so, I have a suspicion
[09:57] <zyga> it is actually related to nfs
[09:57] <zyga> my code was too optimistic
[09:57] <zyga> and it's failing
[09:57] <zyga> when the nfs aspect changes the code won't load the profile
[09:57] <zyga> the reexec profile handling code needs to be nfs aware
[09:57] <zyga> hmm hmmm
[09:58] <zyga> (that came out wrong, it's more subtle)
[09:58] <zyga> I'm running another run with extra logging
[09:59] <zyga> mvo can you look at 4664 since you wrote the original code there
[10:02] <mvo> zyga: ok
[10:03] <mvo> zyga: debugging a thorny test fialure right now, will do once that is done
[10:10] <mvo> zyga: silly question, what was broken in the old one?
[10:11] <ikey> zyga, jdstrand https://youtu.be/faqQuJkqCIA?t=584 or "why steam snap is threatened"
[10:13] <zyga> mvo the old one was happy with stale file on disk
[10:13] <zyga> mvo as long as it was present it would say, yeah fine
[10:13] <mvo> zyga: how could the file be stale? it was rewriten on a new core release and once written the core template never changes?
[10:14] <zyga> mvo because our test code tarballed the state
[10:14] <zyga> and it contained the old one after fresh core install
[10:14] <zyga> then we repackage core and things go down from there
[10:14] <mvo> zyga: could we just exclude this file from the saved state in the tests? would that re-generate it ?
[10:15] <zyga> yes
[10:15] <zyga> though I would really prefer a properly working generator
[10:15] <zyga> I *think* I fixed it now, testing locally
[10:15] <zyga> well, I suspect I know what the problem was, now I'm thinking about how to solve it in a non-hackish way
[10:16] <mvo> zyga: sure, was mostly trying to understand it (and also thinking YAGNI a bit). I have a look in a wee bit
[10:17] <zyga> mvo the new code is conceptually easier to grok IMO, just the bugging aspect of apparmor nfs
[10:17] <zyga> thanks!
[10:17] <mvo> heh, ok - if it really is easier I will shut up and hug you
[10:18] <zyga> yes, just now we see why the old code worked in more cases :)
[10:18] <zyga> it always reloaded
[10:18] <zyga> mvo I also found a subtle error escaping due to error mishandling
[10:18] <zyga> but nothing serious
[10:18] <zyga> https://github.com/snapcore/snapd/pull/4664/files#diff-57dc34ab6f4bf9730b356d0439daa0fdL208
[10:18] <mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
[10:19] <zyga> if err is an error (but not ENOENT) it will be ignored
[10:19] <mvo> zyga: nice catch
[10:21] <zyga> whee
[10:21] <zyga> ok works
[10:23] <mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[10:24] <zyga> uh
[10:24] <zyga> I hit wrong key and suspended my VM
[10:24] <Chipaca> ogra_: I blame you ^
[10:24] <Chipaca> making me look at code
[10:25]  * ogra_ makes note to cash in bonus for that 
[10:25] <popey> zyga: what was the outcome yesterday of the opensuse conversation, I may have missed it. Are we likely to get an update over there soon?
[10:27] <zyga> popey not sure, there's a community member that works on packaging snapd for factory
[10:27] <zyga> I reached out to him and invited him to join us here
[10:28] <zyga> mvo: https://github.com/snapcore/snapd/pull/4658/commits/0a0a3faa4e0b7f6ef5fdda907870924668523625
[10:28] <mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
[10:28] <zyga> popey I',m "not sure" because it can also mean that the update will take a while and will hit opensuse properly
[10:28] <zyga> I think someone should still look at the "PPA"
[10:35] <mup> PR snapd#4666 opened: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4666>
[10:39] <mvo> zyga: reviewed and agreed, its conceptually simpler
[10:41] <ikey> OK looking for some details please, because finding out the true roadmap is a somewhat opaque thing..
[10:41] <ikey> 1) How far away is actual complete desktop integration (theming, etc.)
[10:41] <ikey> 2) What is the current holdup with apparmor changes to unblock steam-support?
[10:44] <pedronis> ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
[10:45] <ikey> Ok ty
[10:45] <ikey> In that case I'm removing snapd integration from the roadmap for Solus 4
[10:45] <ikey> We were meant to be releasing in january and this snapd debacle has had me held up for months now
[10:45] <ikey> I've lost too much time on this
[10:46] <ikey> I can't support crippling of our own cadence to match that of Ubuntu
[10:48] <mvo> ikey: theming and all that is pretty close (zyga will know the details but my understanding is that most of things needed to make it work have landed now)
[10:48] <pedronis> ikey: afaiu our deadline its +-  beginning of march
[10:48] <zyga> mvo theming is now open for business but it's just getting started on the actual theme snaps
[10:49] <ikey> Would be nice if that had been communicated ahead of time to others, thats what I mean about opaque
[10:49] <ikey> I'm flying blind on the outsides here
[10:49] <ikey> But I believe it safe to say that snapd isn't completely ready yet for the desktop
[10:49] <zyga> ikey theming will be in 18.04 for sure but it's not here now
[10:49] <ikey> Right, an Ubuntu target
[10:49] <zyga> well, more less a deadline for us to reach, many things are in progress
[10:50] <pedronis> I didn't even know you were waiting on us, so I'm probably the wrong person to chime in either way
[10:50] <ikey> pedronis, several months now
[10:50] <zyga> ikey I agree that themes are a known missing feature
[10:50] <niemeyer> ikey: We are late on it ourselves.. and it's not because we are bound to Ubuntu, but because it takes time to develop.. zyga has been working on mounts since forever
[10:50] <ikey> It's taken so long that the flatpak/collabora camp are now developing their own version of what I've been blocked on
[10:51] <ikey> Which to be blunt is crippling my own value-add
[10:51] <ikey> By putting all my eggs in one basket
[10:51] <ikey> At this point waiting on snapd is affecting business decisions in Solus, and I can't allow that to continue
[10:51] <ikey> (I know, its the word we don't like to use)
[10:51] <ikey> But that is the reality
[10:52] <ikey> So I'll defer snapd integration until such point as its suitable and remove it from the Solus 4 roadmap
[10:52] <ikey> As we're way overdue
[10:52] <ikey> Then we can revisit it around the time of 18.04
[10:53] <niemeyer> ikey: It's okay, by the end of the day you know your own priorities much better than anybody else.. we'll continue to be here pushing things forward if you change your mind
[10:53] <ikey> niemeyer, ? im not sure you get it. ive been contributing and my own work has been repeatedly blocked. its not like my mind needs changing
[10:54] <ikey> the platform isn't ready, im blocked on what i need to do for months, and i cant allow it to continue blocking the release
[10:55] <niemeyer> ikey: I totally get it.. our own work gets blocked all the time too.. the more interesting a project becomes the harder it is to make everybody happy about the pace that things move on..
[10:55] <ikey> niemeyer, thats great - but you know whats going on, us poor mortals on the outside do not
[10:56] <ikey> and snapd's interests are clearly aligned with Ubuntu and hasn't got to compete
[10:56] <zyga> ikey we'll get the desktop bits implemented and will gladly have you use snaps more in solus when you feel they meet your goals
[10:56] <niemeyer> ikey: We've been giving you and Solus a fair share of our attention, and we appreciate having you with us, but apparently we still cannot make things work for you as fast as you need
[10:56] <ikey> niemeyer, again its not about speed, its a failure in communication
[10:56] <ikey> repeatedly stone walled and left in the dark
[10:56] <niemeyer> ikey: That's not what I hear above
[10:56] <ikey> I'd appreciate it if you stopped turning this around to put yourself on the moral highground
[10:56] <niemeyer> 2) What is the current holdup with apparmor changes to unblock steam-support?
[10:56] <niemeyer> 08:44:30
 Samuele Pedroni ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
[10:56] <niemeyer> 08:45:00
 ufee1dead Ok ty
[10:56] <niemeyer> 08:45:08 In that case I'm removing snapd integration from the roadmap for Solus 4
[10:57] <ikey> niemeyer, because again failure to communicate
[10:57] <ikey> i shouldnt have to be meekly asking every week
[10:57] <ikey> and more often times than not, ignored
[10:57] <ikey> Communication is the core problem
[10:57] <niemeyer> ikey: I've been on holiday because it's been Carnival in Brazil.. I'm not actually sorry for spending some of my time with my family :)
[10:57] <zyga> ikey ok, what would you have us change to make things better on communication?
[10:58] <ikey> niemeyer, dude, jesus christ
[10:58] <ikey> stop with the guilt trips and making it about you
[10:58] <niemeyer> ikey: Yes, sort of related to jesus christ
[10:58] <ikey> fuckin hell
[10:58] <ikey> ill talk to zyga
[10:58] <ikey> zyga, probably not have niemeyer interjecting with childish remarks would be a good start
[10:58] <ikey> As I said in the past, just being kept in the loop would be enough
[10:59] <ikey> Knowing how things are going and the future goals, how things are progressing, is entirely enough
[10:59] <ikey> Then folks external to Ubuntu know how to plan appropriately
[10:59] <ikey> It really is that simple
[10:59] <ikey> And doesn't require the drama that niemeyer is trying to stir
[10:59] <zyga> do you think a periodic (say weekly) update on the roadmap, blockers and similar things, in written form would be sufficient to convey this information
[11:00] <ikey> Yeah eow update sounds perfect
[11:00] <zyga> I think we have a few things going on but they are probably not coordinated with each other (some newsletters, some forum posts, etc)
[11:00] <ikey> Like I wanna be perfectly clear here, I did *not* say I was removing snapd from Solus (so the overreaction was completely unwarranted) - I said i was removing snapd *integration* from the Solus 4 roadmap
[11:00] <ikey> i.e. inclusion in the software center, promoting of default snaps
[11:01] <niemeyer> :)
[11:01] <ikey> Frankly I'm shocked at the immediate hostility
[11:01] <zyga> I agree that communication is hard and it's probably most evident for people that don't participate in daily standups where everyone shares their progress and priorities
[11:01] <ikey> zyga, i totally get it though, ive been in similar situations, when we had to liase with green-badges at intel
[11:01] <ikey> so its not a blame game
[11:02] <ikey> just saying that those of us outside the core circle aren't always abreast of targets/goals
[11:02] <ikey> Thus in the interest of future work, that would be much appreciated and helpful
[11:03] <mvo> ikey: thanks for sharing this with us, I know it sounds cliche but it is important feedback. I personally had the feeling that we get the communication right (now that we have the forum and there is a lot of buzz there). so its good to get corrected on that view
[11:03] <zyga> right, I think we should advertise our roadmap and updates more, maybe we could start a recurring update forum post (written by everyone hacking on snapd) and collectively sent/shared every week
[11:04] <ikey> yeah i mean i dont think it needs to be overly formal, you just need to expose the pulse, if that makes sense
[11:04] <mvo> ikey: just to double check that I get this correctly - the main problem was e.g. that "theme support" was on the roadmap but no clear times/dates attached and not clear if/how much progress was happening(?)
[11:05] <mvo> (so for the things you cared about the sense of "where are we" was missing?)
[11:05] <ikey> mvo, so in a nut shell yeah, aware of items drifting on the horizon for some length of time, but we dont know where they are or when they come or whats stopping them
[11:05]  * mvo nods
[11:05] <ikey> the other important aspect for that is you provide a point for newcomers to the project who want to onboard and contribute
[11:05] <ikey> they see the blockers and have something to work on
[11:07] <ikey> wait for the cringe: virtuous cycle of growth
[11:07] <niemeyer> ikey: We did report recently about the desktop progress: https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510
[11:07] <mvo> ikey: thats a good one too, I wonder if the forum and a pinned topic would help with that. I personally find this apsect (good newcomer tasks one of the hardest)
[11:07]  * mvo messed up the () above, clearly needs to do more lisp
[11:07] <ikey> niemeyer, if you think im going to talk to you now you're very much mistaken, you're one of the core issues with this project
[11:07] <zyga> mvo I think pinning might be the key, we have lots of discussions now (because the forum is quite successful) and it's hard to find the essential news in summarized form
[11:08] <ikey> once you correct your attitude I'll recommence communications
[11:08] <mvo> zyga: yeah, thats a good point, the front-page scrolls by super fast
[11:08] <ikey> zyga, most topics with tag would last a week in the scroll i think?
[11:08] <ikey> like you might need to click the tag first to filter
[11:08] <mvo> zyga: or maybe more categories, but not sure if that would help and now discoverable this actually is
[11:09] <zyga> I don't know the technical forum answer yet, we need to experiment and see how it looks like
[11:09] <zyga> I understand the forum page is personalised so it might need testing in a private browser session
[11:09] <ikey> oh right
[11:09] <ikey> TIL. :)
[11:09] <niemeyer> ikey: That will make collaboration a bit harder.. :)
[11:10] <ikey> pot calling the kettle black
[11:10] <ikey> Anyway, I'm gonna take my leave for now, because I really can't be in the same room as him right now.
[11:10] <ikey> Hope I've provided enough details on the report thing
[11:10] <ikey> Like I said, only removing the target for snapd *integration*
[11:10] <ikey> not snapd itself
[11:10] <ikey> Besides, I made aa-lsm-hook, not removing apparmor now :P
[11:16]  * Chipaca hugs ikey 
[11:16] <Chipaca> ikey: thank you, and sorry, and … stuff
[11:16] <ikey> Chipaca, pfft dont be. you're awesome
[11:17] <Chipaca> ikey: "sorry for not being awesomer" sounds like a lame non-apology
[11:17] <ikey> lol
[11:18] <Chipaca> ikey: to be clear, thank you for speaking up and not just going off in a huff
[11:18] <Chipaca> that's hard to do and i appreciate it a lot
[11:18] <Chipaca> ikey: and sorry that you had to do so, we like to think we're better than this and need reminding every so often
[11:19] <ikey> bit hard to cross back over the river when the bridge is in flames :)
[11:19]  * Chipaca brings out the marshmallows
[11:19] <ikey> Chipaca, well i always look at these things as a way to refresh the path forward tbh
[11:20]  * Chipaca brings out the marshmallow rpg
[11:20] <ikey> like, ok now we know such and such doesn't happen now, revisit it then, and correct stuff in the meantime
[11:20] <ikey> too old and hairy now for drama
[11:22] <zyga> mborzecki can you please look at https://travis-ci.org/snapcore/snapd/builds/341366071?utm_source=github_status&utm_medium=notification
[11:22] <mborzecki> looking
[11:22] <zyga> one test failed there
[11:22] <zyga> doesn't look related to the change
[11:25] <mborzecki> hmm, w8, how does it pass on master?
[11:25] <zyga> what do you mean?
[11:27] <mborzecki> zyga: https://github.com/snapcore/snapd/pull/4654 stops the timer in prepare
[11:27] <mup> PR #4654: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4654>
[11:27] <zyga> maybe we are running tests of the branch, not of the merged result
[11:27] <zyga> (that would be an interesting find)
[11:28] <mborzecki> iirc that's what travis does by default
[11:28] <zyga> that == merged or just branch?
[11:28] <mborzecki> branch
[11:28] <mborzecki> anyways, that test was there before right?
[11:29] <zyga> yes
[11:30] <mborzecki> right, so 4654 travis job was ok, some master jobs after that PR was merged were fine too, so why does it fail now?
[11:30] <zyga> yeah, I don't know that
[11:30] <mborzecki> clearly it will file if the timer is stopped
[11:31] <mborzecki> so somehow it must be started again :/
[11:38] <zyga> + test -f /usr/share/dbus-1/services/io.snapcraft.Launcher.service
[11:38] <zyga> + diff -u /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig /usr/share/dbus-1/services/io.snapcraft.Launcher.service
[11:38] <zyga> --- /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig	2017-12-18 14:41:33.000000000 +0000
[11:38] <zyga> +++ /usr/share/dbus-1/services/io.snapcraft.Launcher.service	2018-02-13 16:57:31.000000000 +0000
[11:38] <zyga> @@ -1,3 +1,4 @@
[11:38] <zyga>  [D-BUS Service]
[11:38] <zyga>  Name=io.snapcraft.Launcher
[11:38] <zyga>  Exec=/usr/bin/snap userd
[11:38] <zyga> +AssumedAppArmorLabel=unconfined
[11:38] <zyga> -----
[11:38] <zyga> I have a feeling that our prepare restore code is buggy
[11:39] <Chipaca> mvo: tweaked the system-shutdown sync comment, see what you think
[11:39] <Chipaca> might be getting a little rambly
[11:53] <zyga> + snap install test-snapd-control-consumer
[11:53] <zyga> error: cannot install "test-snapd-control-consumer": cannot get nonce from
[11:53] <zyga>        store: store server returned status 418
[11:53] <zyga> that's the teapot, right Chipaca ?
[11:53] <Chipaca> yes
[11:54] <Chipaca> mup, what's http status 418
[11:54] <mup> Chipaca: In-com-pre-hen-si-ble-ness.
[11:54] <Chipaca> zyga: se?
[11:54] <Chipaca> zyga: see?
[11:55] <zyga> thanks
[12:03] <mvo> Chipaca: thanks, comment looks fine
[12:03] <mup> PR snapd#4662 closed: tests: removing packages which are not needed anymore to generate random data <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4662>
[12:06] <Son_Goku> [06:16:41 AM]  <Chipaca>	ikey: thank you, and sorry, and … stuff
[12:06] <Son_Goku> did I miss an emotional moment or something?
[12:06] <ikey> we hugged
[12:06] <ikey> :3
[12:06] <Chipaca> Son_Goku: ikey called us out on stuff we thought we were better at than we are
[12:07] <Son_Goku> Chipaca: I just don't bother anymore
[12:07] <Chipaca> Son_Goku: you're just wanting a hug too
[12:07]  * Chipaca hugs Son_Goku 
[12:07] <Son_Goku> aww
[12:07]  * Son_Goku hugs Chipaca back
[12:07] <ikey> o wait its valentines day
[12:07] <ikey> not to make the hugs awkward or anything
[12:07] <Son_Goku> Yeerp
[12:07] <ikey> .. :D
[12:07] <Son_Goku> :D
[12:07]  * zyga would pour some vodka but then again this is IRC
[12:07] <Son_Goku> I stay the _hell_ away from your vodka
[12:08] <ikey> yeah you can only have 512 of the vodka
[12:08] <zyga> haha
[12:09] <Son_Goku> but yeah, these days, I don't really know whats going on with the features for snappy that I need to accomplish my objectives
[12:09] <Son_Goku> unlike ikey though, I don't have the time to dig into everything all the time
[12:09] <Son_Goku> so I just kinda let it go and hope something comes up to give me a better picture later
[12:09] <Son_Goku> I've barely had _any_ time to work on the RPM backend for snapcraft
[12:10] <Son_Goku> which I already know requires me to implement some functionality in DNF to make things a little less stupid
[12:11] <zyga> Son_Goku btw, offtopic. hurricanehrndz is idle for about a month (on irc), is that the right nickname?
[12:11] <Son_Goku> I think that's the right nick
[12:12] <Son_Goku> worst case, I'll probably do some work myself on the openSUSE packaging
[12:12] <mup> PR snapd#4664 closed: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4664>
[12:12] <mup> PR snapd#4666 closed: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4666>
[12:13] <Son_Goku> zyga, but at least from a fedora point of view, the main things I want to see is *some* effort towards a selinux backend for snap-confine
[12:13] <Son_Goku> it doesn't even have to involve code
[12:13] <Son_Goku> just at least discussions with selinux developers to figure out gaps and how to close them, if any
[12:14] <Son_Goku> and of course, a way to swap core snaps for building a modular Fedora system built on snaps
[12:14] <zyga> that 2nd thing may come out of base/core 18 work where things will force us to move snapd out of core
[12:14] <zyga> or out of the "one" nap
[12:14] <zyga> *snap
[12:15] <zyga> naming things aside
[12:15] <zyga> 1st thing is something I just don't have time to work on, I agree it is interesting and would like to see that started eventually
[12:18] <niemeyer> mborzecki: Replied in the timer conversation
[12:18] <mborzecki> niemeyer: thanks
[12:19]  * zyga switches focus to user mounts for the rest of the day
[12:19] <zyga> and takes a break to relieve back pain
[12:25]  * kalikiana going for a brief break
[12:28]  * Chipaca -> lunch
[12:39] <mup> PR snapcraft#1925 opened: elf: cache crawled files <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1925>
[12:42] <mup> PR snapcraft#1922 closed: elf: fast track when the host used matches the base <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1922>
[12:44] <pedronis> I'm getting this:  Cannot allocate linode:ubuntu-16.04-64: cannot boot linode:ubuntu-16.04-64 (Spread-5941868): missing or incomplete Linode startup profile.  Contact Linode support.
[12:53] <jdstrand> ikey: for my part, sorry steam-support dragged a bit. honestly, I didn't know it was a blocker for solus 3, but I'm going to keep working at it. also, fwiw, I thought you were saying you were dropping snapd too so glad to hear you are keeping that and apparmor :)
[13:00] <mup> PR snapd#4658 closed: many: don't allow layout construction to silently fail <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4658>
[13:36]  * kalikiana lunch
[13:58] <pedronis> mvo: let me if I can help with that issue, I also noticed that I replicated the issue in my new branch about the new api
[13:59] <mvo> pedronis: thanks, I will prepare a PR and ask you for a review (with appropriate comments)
[14:01] <mup> PR snapd#4667 opened: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4667>
[14:05] <koza> pedronis, hey, quick question: assuming eth cables are plugged in and internet is available can I be sure that prepare-device hook runs after the networking connection is established or there is a race?
[14:07] <pedronis> koza: I don't know in general, prepare-device will be retried though if needed
[14:08] <koza> pedronis, i know just want to make sure if i can safely assume it runs with networking *if* is available at the time of boot and properly configured
[14:10] <mborzecki> zyga: 4667 should address the failure in tests/main/ubuntu-core-services you were seeeing
[14:15] <pedronis> koza: I don't know, that seems related to the systemd services setup,  mvo might know more about that
[14:17] <koza> pedronis, mvo, ^^ and what has to happen for prepare-device to be retried; do i remember rightly it will happen when the Initialize Device stage is failed?
[14:17] <pedronis> koza: yes,  also if prepare-device itself fails
[14:18] <koza> pedronis, got it, thanks
[14:18] <mvo> koza: we just use "WatnedBy=multi-user.target", so no gurantee other than that
[14:18] <mvo> koza: i.e. we do not have anything like after=network of network-online.target
[14:19] <koza> mvo, right, understood; but one could rely on retry and wait for net to be up in case there is a race between these two
[14:26]  * kalikiana re
[14:33] <mup> PR snapd#4668 opened: store: revert PR#4532 and do not display displayname <Created by mvo5> <https://github.com/snapcore/snapd/pull/4668>
[14:43] <mborzecki> off to pick up the kids
[15:03] <alexlarsson> zyga: when referring to snap in writing, what do i use "snap", "snappy"?
[15:05] <popey> alexlarsson: we tend not to use "snappy"  so much, snap and snapcraft are more widely used
[15:05]  * popey realises he is saying that in #snappy
[15:06] <zyga> alexlarsson hmmm
[15:06] <zyga> I try to say "snapd" because snappy is a compression format and snap typically a file
[15:07] <zyga> alexlarsson it also depends on what you are writing about, snap packages are "snap" but it is "snapd" who manages them
[15:07] <popey> (and snapcraft [generally] that makes them)
[15:07] <alexlarsson> more like refering to the project/organization/people
[15:08] <alexlarsson> "snap wants to use portals"
[15:08] <popey> "the snap developers want to use portals"
[15:08] <zyga> I would say "snapd integrates with portals" and "snap packages can use portals"
[15:08] <alexlarsson> ok, cool
[15:33] <popey> niemeyer: we have a new user on the forum who is going to post a call for testing of their snap. They will get anti-spam blocked linking to their issue tracker. Can you help?
[15:33] <popey> (I am pre-emptively asking because I know this will happen)
[15:34] <zyga> Chipaca 4669 is trivial and I think you wrote the original
[15:34] <zyga> or perhaps mvo
[15:34]  * zyga knows how to gather reviewers ;-)
[15:34] <mup> PR snapd#4669 opened: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <https://github.com/snapcore/snapd/pull/4669>
[15:35] <Chipaca> zyga: mountSuite does the mocking of proc/mounts?
[15:35] <Chipaca> or whatever it was :-)
[15:35] <Chipaca> ah tere it is
[15:40] <zyga> re
[15:41] <zyga> Chipaca, no, there's mocking in each function
[15:42] <niemeyer> popey: Yeah, happy to help
[15:43] <niemeyer> popey: In general I tend to respond to such blocks quickly if it's during my day
[15:43] <niemeyer> popey: But please feel free to ping here or on Telegram when necessary
[15:43] <popey> niemeyer: will do
[15:44] <niemeyer> popey: I just approved a different one moments ago coincidentally, which was responding to a request for version
[15:44] <niemeyer> popey: Not sure why it triggered the anti spam.. too many pre blocks?
[15:44] <popey> Excellent. :)
[15:48] <mvo> zyga: heh
[15:52] <zyga> Chipaca, mvo: another part of the per-user mount split: https://github.com/snapcore/snapd/pull/4670
[15:52] <mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[15:52] <zyga> trivial 34 additions PR
[15:52] <mup> PR snapd#4670 opened: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[15:58] <mvo> zyga: in a meeting right now
[15:58]  * zyga nods
[16:01] <zyga> jdstrand quick ack on https://github.com/snapcore/snapd/pull/4670
[16:01] <mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
[16:01] <zyga> jdstrand I'll reduce the per-user branch to the most essential (hard) changes today
[16:04] <mup> PR snapd#4667 closed: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4667>
[16:05] <zyga> Chipaca can you please merge master into https://github.com/snapcore/snapd/pull/4665
[16:05] <mup> PR #4665: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[16:05] <zyga> (or rebase since it's so tiny)
[16:15] <mup> Bug #1749538 opened: refresh time docs lacks the correct command <docs> <Snappy:New> <https://launchpad.net/bugs/1749538>
[16:25] <jdstrand> zyga: ack
[16:32] <mup> PR snapd#4669 closed: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4669>
[17:05] <zyga> hmmm
[17:05] <zyga> https://travis-ci.org/snapcore/snapd/builds/341459647?utm_source=github_status&utm_medium=notification
[17:06] <zyga> It says "We couldn't find the repository snapcore/snapd"
[17:10] <mborzecki> zyga: restart the job?
[17:10] <zyga> look at that page
[17:10] <zyga> there's no link for that
[17:11] <zyga> in fact
[17:11] <zyga> it looks like all travis jobs are broken
[17:11] <zyga> cachio ^
[17:11] <zyga> man
[17:11] <zyga> this feels like a time to EOD and take a break
[17:12] <cachio> zyga, let me take a lokk
[17:12] <zyga> mvo ^ (in case you were hoping for releases)
[17:14] <kalikiana> bah. what is it with containers and networking that it works perfectly but also doesn't
[17:14] <mborzecki> zyga: refreshed now and the job page is there
[17:14] <zyga> same here
[17:14] <mborzecki> zyga: also restarted the build, seems like github failed this time :/
[17:14] <kalikiana> I guess I'll have something to investigate tomorrow morning
[17:14] <zyga> broken travis?
[17:15] <zyga> mborzecki can you look at 4670
[17:15] <zyga> it's trivial and blocks other bits
[17:20] <cachio> zyga, travis is a caos
[17:20] <zyga> caos?
[17:21] <cachio> chaos
[17:23] <zyga> cacaos :)
[17:23] <cachio> hehehe
[17:23] <cachio> zyga, I still cant run tests on linode
[17:23] <cachio> from localhost
[17:23] <zyga> no? what happens
[17:24] <zyga> I ran some this morning
[17:24] <mborzecki> tried to something here ~3pm, didn't work either
[17:24] <mborzecki> i was getting: '2018-02-14 14:59:29 Cannot allocate linode:ubuntu-core-16-64: cannot decode Linode response (status 200): json: cannot unmarshal string into Go struct field linodeServerData.PLANID of type int', a change in linode's API?
[17:24] <cachio> mborzecki, I see errors from linode
[17:25] <cachio> mborzecki, yes
[17:25] <cachio> that
[17:25] <zyga> eh :/
[17:25] <zyga> thank you for the feedback Chipaca!
[17:27] <mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[17:32] <mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[17:48] <zyga> Chipaca fixed
[17:48]  * zyga heads for some food
[17:48] <zyga> ttyl
[18:56] <mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4665>
[18:58] <mup> PR snapd#4671 opened: tests: adding new test to validate the raw-usb interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4671>
[19:36] <Oooohboy> hello all, I'm getting what looks to be a permissions issue when running snapcraft. "Can't drop privileges for downloading as file"
[19:37] <Oooohboy> anyone have any links or anything to general troubleshooting docs on snapcraft? This is probably user error here, but I've tried sudo and sudo -H
[19:40] <nacc> Oooohboy: you don't generallly want to be root to buildl a snap
[19:40] <nacc> Oooohboy: can you pastebin your exact command and output?
[19:43] <Oooohboy> https://pastebin.com/DnFdGfxt
[19:43] <Oooohboy> should be everything needed there I think
[19:49] <nacc> Oooohboy: do you possibly have a ppa on your system that doensn't work?
[19:49] <nacc> Oooohboy: ppa.launchpad.net_tista_adapta_ubuntu_dists_artful_
[19:51] <Oooohboy> nacc: yes
[19:52] <Oooohboy> nacc: well, I think it works...
[19:55] <nacc> Oooohboy: sorry, i'm not sure then; i'd wait till a snapcraft dev is arounnd
[19:59] <Oooohboy> nacc: thanks for looking. As this is my first snap I was sure it was something I was/am doing wrong
[20:07] <kyrofa> Oooohboy, have you tried without sudo?
[20:14] <Oooohboy> kyrofa: yeah sorry heres that paste https://pastebin.com/YRiWqasy
[20:17] <kyrofa> Oooohboy, I suspect things are owned as root now in that dir. Try blowing away the snapcraft cache in `/home/sbrady/.cache/snapcraft` and trying again (without sudo)
[20:20] <mup> PR snapd#4672 opened: tests: adding test for removable-media interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
[20:20]  * cachio afk
[20:21] <Oooohboy> kyrofa: thanks for looking...did that, same issue...apt-get update and upgrade are working fine https://pastebin.com/4stUYuGR
[20:22] <kyrofa> Oooohboy, note that stage-packages don't use `apt-get` directly
[20:22] <Oooohboy> ok
[20:23] <kyrofa> That's not actually the same error... something is segfaulting
[20:23] <kyrofa> Oooohboy, can I see the output of `snap version` please?
[20:25] <Oooohboy> https://pastebin.com/HkFZRcXR
[20:47] <mup> PR snapcraft#1924 closed: schema: update version regex <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1924>
[20:48] <kyrofa> Hmm, 17.10, I've not tried that recently
[22:07] <mup> PR snapd#4670 closed: interfaces/mount: add support for per-user mount entries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4670>
[22:10] <mup> PR snapd#4673 opened: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
[22:14] <zyga> jamesh, I'm chopping your user-mounts branch into pieces, I will merge master into the main branch until it reduces to an empty diff
[22:14] <zyga> this way it will get in faster as smaller pieces are easier to iterate on
[22:14] <zyga> I'm going to bed, talk you tomorrow!