[06:09] morning [06:21] Bug #1749374 opened: The /bin/sync command is not allowed by default [06:33] hey [06:33] mborzecki linode was broken last night [06:33] zyga: did we break it? [06:33] I suppose so [06:34] it stopped responding to API requests [06:34] haha omg [06:34] let's hope it's not that bad today [06:35] zyga: any idea how advanced is the move to GCE or DO? [07:22] mborzecki no, I hope it's under way though [07:26] mborzecki are any of your branches working/ [07:27] zyga: don't have any new PRs open atm [07:33] I'm running tests in linode and locally to compare [07:48] mborzecki can you please have a look at 4664 [07:48] it is designed to unbreak master [07:48] it came out of 4658 [07:48] I also pushed it there to show that it fixes things [07:48] (except where linode doesn't work) [07:49] looking [07:50] I could move some of the patches out to an even smaller prerequisite branch if that helps [07:52] o/ [07:53] hey kalikiana [08:04] hmm. is snap designed to be a fully secured container? [08:04] it depends on what you mean by a container [08:04] cos i've somehow just escaped the snap and managed to create files outside of the container...i think [08:04] snap apps are not typical containers [08:04] are they meant to protect the rest of the environment? [08:04] it depends [08:05] 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] please tell me more and I will try to help you [08:05] if you think this is a security issue you can contact me in private [08:05] or send me an encrypted mail [08:08] telboon- let me know if you need more information [08:09] zyga: let me try to reproduce it in a few scenarios [09:15] + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz [09:15]

[09:15] hmm :/ [09:17] I see this often but on random tests [09:20] with all the verbosity in tests, maybe we should add a -v to that tar :-) [09:23] -vv [09:23] --poem [09:23] zyga: quick question, how far are user mounts away (roughly)? days? weeks? [09:23] mvo days [09:23] mvo but unhappy master is making stuff sad [09:23] or is it just my branch? [09:23] hey mvo, how are you doing? [09:24] zyga: I'm fine thank you [09:24] zyga: yeah, unhappy master makes me unhappy too [09:25] zyga: what error do you see? I also see some strange errors [09:25] timeouts [09:25] but not the ones we saw before [09:25] I see tests reaching 49 minutes [09:25] many linode api errors [09:25] errors on tar (see above) being killed by timeout [09:25] honestly, I don't know what's wrong [09:26] mvo I ran my branch in qemu all the way (though not without hiccups) [09:26] zyga: ok [09:26] but my record on linode is "red since yesterday" [09:27] maybe something is related to nfs, I need to look at that [09:27] + umount /home [09:27] umount.nfs: /home: device is busy [09:27] 2018-02-14 08:26:18 Error restoring linode:ubuntu-16.04-64:tests/main/nfs-support : [09:27] we cannot unmount nfs, then we cannot remove the nfs kernel server package [09:28] zyga: and you can't umount home because that's where spread's running [09:29] zyga: chroot time? [09:29] would that even work [09:29] Chipaca this is not a new test [09:29] look at main/nfs-support [09:31] zyga: i see it, but i still wonder it works [09:31] zyga: does it hang every time with your changes? [09:31] no [09:32] ah drat :-) [09:32] yeah [09:32] so something else depends on ordering [09:32] zyga: does it hang every time if you specify the seed of the time it hung? [09:32] maybe my patch is just broken [09:32] I didn't try (~~ hours) [09:32] let's see [09:32] zyga: if it's reproducible, you can figure out what's holding it back [09:33] 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] (but if it works sometimes, maybe figuring out what blocks it when it doesn't is better) [09:33] the unmount earlier should not have failed [09:33] some process is lurking [09:34] but [09:34] this is just one of the failure [09:34] *failures [09:34] does anyone here have any Opinions on go 1.9 vs go 1.10 as default in bionic? [09:34] mwhudson I suspect 1.10 is just a bit younger so it will be EOLd later [09:34] mwhudson does go have LTS-like releases? [09:34] no [09:34] right, that's certainly a consideration, and no [09:35] it's why we should really think how to use newer go [09:35] for snapd, at some point it will bite us [09:36] using new go is easy, using new go everywhere is hard [09:36] changing base requirement is hard [09:38] it will have to happen at some point though [09:39] * zyga reproduced nfs error with debug shell [09:39] inspecting [09:51] hmmmmmm [09:54] so, I have a suspicion [09:57] it is actually related to nfs [09:57] my code was too optimistic [09:57] and it's failing [09:57] when the nfs aspect changes the code won't load the profile [09:57] the reexec profile handling code needs to be nfs aware [09:57] hmm hmmm [09:58] (that came out wrong, it's more subtle) [09:58] I'm running another run with extra logging [09:59] mvo can you look at 4664 since you wrote the original code there === ikey|afk is now known as ikey [10:02] zyga: ok [10:03] zyga: debugging a thorny test fialure right now, will do once that is done [10:10] zyga: silly question, what was broken in the old one? [10:11] zyga, jdstrand https://youtu.be/faqQuJkqCIA?t=584 or "why steam snap is threatened" [10:13] mvo the old one was happy with stale file on disk [10:13] mvo as long as it was present it would say, yeah fine [10:13] 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] mvo because our test code tarballed the state [10:14] and it contained the old one after fresh core install [10:14] then we repackage core and things go down from there [10:14] zyga: could we just exclude this file from the saved state in the tests? would that re-generate it ? [10:15] yes [10:15] though I would really prefer a properly working generator [10:15] I *think* I fixed it now, testing locally [10:15] 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] zyga: sure, was mostly trying to understand it (and also thinking YAGNI a bit). I have a look in a wee bit [10:17] mvo the new code is conceptually easier to grok IMO, just the bugging aspect of apparmor nfs [10:17] thanks! [10:17] heh, ok - if it really is easier I will shut up and hug you [10:18] yes, just now we see why the old code worked in more cases :) [10:18] it always reloaded [10:18] mvo I also found a subtle error escaping due to error mishandling [10:18] but nothing serious [10:18] https://github.com/snapcore/snapd/pull/4664/files#diff-57dc34ab6f4bf9730b356d0439daa0fdL208 [10:18] PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current [10:19] if err is an error (but not ENOENT) it will be ignored [10:19] zyga: nice catch [10:21] whee [10:21] ok works [10:23] PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic [10:24] uh [10:24] I hit wrong key and suspended my VM [10:24] ogra_: I blame you ^ [10:24] making me look at code [10:25] * ogra_ makes note to cash in bonus for that [10:25] 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] popey not sure, there's a community member that works on packaging snapd for factory [10:27] I reached out to him and invited him to join us here [10:28] mvo: https://github.com/snapcore/snapd/pull/4658/commits/0a0a3faa4e0b7f6ef5fdda907870924668523625 [10:28] PR #4658: many: don't allow layout construction to silently fail [10:28] popey I',m "not sure" because it can also mean that the update will take a while and will hit opensuse properly [10:28] I think someone should still look at the "PPA" [10:35] PR snapd#4666 opened: interfaces/apparmor: generalize apparmor load and unload helpers [10:39] zyga: reviewed and agreed, its conceptually simpler [10:41] OK looking for some details please, because finding out the true roadmap is a somewhat opaque thing.. [10:41] 1) How far away is actual complete desktop integration (theming, etc.) [10:41] 2) What is the current holdup with apparmor changes to unblock steam-support? [10:44] ikey: afaiu from the forum jdstrand was waiting on input from Gustavo about 2 [10:45] Ok ty [10:45] In that case I'm removing snapd integration from the roadmap for Solus 4 [10:45] We were meant to be releasing in january and this snapd debacle has had me held up for months now [10:45] I've lost too much time on this [10:46] I can't support crippling of our own cadence to match that of Ubuntu [10:48] 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] ikey: afaiu our deadline its +- beginning of march [10:48] mvo theming is now open for business but it's just getting started on the actual theme snaps [10:49] Would be nice if that had been communicated ahead of time to others, thats what I mean about opaque [10:49] I'm flying blind on the outsides here [10:49] But I believe it safe to say that snapd isn't completely ready yet for the desktop [10:49] ikey theming will be in 18.04 for sure but it's not here now [10:49] Right, an Ubuntu target [10:49] well, more less a deadline for us to reach, many things are in progress [10:50] I didn't even know you were waiting on us, so I'm probably the wrong person to chime in either way [10:50] pedronis, several months now [10:50] ikey I agree that themes are a known missing feature [10:50] 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] 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] Which to be blunt is crippling my own value-add [10:51] By putting all my eggs in one basket [10:51] At this point waiting on snapd is affecting business decisions in Solus, and I can't allow that to continue [10:51] (I know, its the word we don't like to use) [10:51] But that is the reality [10:52] So I'll defer snapd integration until such point as its suitable and remove it from the Solus 4 roadmap [10:52] As we're way overdue [10:52] Then we can revisit it around the time of 18.04 [10:53] 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] 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] 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] 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] niemeyer, thats great - but you know whats going on, us poor mortals on the outside do not [10:56] and snapd's interests are clearly aligned with Ubuntu and hasn't got to compete [10:56] 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] 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] niemeyer, again its not about speed, its a failure in communication [10:56] repeatedly stone walled and left in the dark [10:56] ikey: That's not what I hear above [10:56] I'd appreciate it if you stopped turning this around to put yourself on the moral highground [10:56] 2) What is the current holdup with apparmor changes to unblock steam-support? [10:56] 08:44:30 [10:56] Samuele Pedroni ikey: afaiu from the forum jdstrand was waiting on input from Gustavo about 2 [10:56] 08:45:00 [10:56] ufee1dead Ok ty [10:56] 08:45:08 In that case I'm removing snapd integration from the roadmap for Solus 4 [10:57] niemeyer, because again failure to communicate [10:57] i shouldnt have to be meekly asking every week [10:57] and more often times than not, ignored [10:57] Communication is the core problem [10:57] 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] ikey ok, what would you have us change to make things better on communication? [10:58] niemeyer, dude, jesus christ [10:58] stop with the guilt trips and making it about you [10:58] ikey: Yes, sort of related to jesus christ [10:58] fuckin hell [10:58] ill talk to zyga [10:58] zyga, probably not have niemeyer interjecting with childish remarks would be a good start [10:58] As I said in the past, just being kept in the loop would be enough [10:59] Knowing how things are going and the future goals, how things are progressing, is entirely enough [10:59] Then folks external to Ubuntu know how to plan appropriately [10:59] It really is that simple [10:59] And doesn't require the drama that niemeyer is trying to stir [10:59] 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] Yeah eow update sounds perfect [11:00] 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] 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] i.e. inclusion in the software center, promoting of default snaps [11:01] :) [11:01] Frankly I'm shocked at the immediate hostility [11:01] 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] zyga, i totally get it though, ive been in similar situations, when we had to liase with green-badges at intel [11:01] so its not a blame game [11:02] just saying that those of us outside the core circle aren't always abreast of targets/goals [11:02] Thus in the interest of future work, that would be much appreciated and helpful [11:03] 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] 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] 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] 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] (so for the things you cared about the sense of "where are we" was missing?) [11:05] 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] the other important aspect for that is you provide a point for newcomers to the project who want to onboard and contribute [11:05] they see the blockers and have something to work on [11:07] wait for the cringe: virtuous cycle of growth [11:07] ikey: We did report recently about the desktop progress: https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510 [11:07] 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] 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] 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] once you correct your attitude I'll recommence communications [11:08] zyga: yeah, thats a good point, the front-page scrolls by super fast [11:08] zyga, most topics with tag would last a week in the scroll i think? [11:08] like you might need to click the tag first to filter [11:08] zyga: or maybe more categories, but not sure if that would help and now discoverable this actually is [11:09] I don't know the technical forum answer yet, we need to experiment and see how it looks like [11:09] I understand the forum page is personalised so it might need testing in a private browser session [11:09] oh right [11:09] TIL. :) [11:09] ikey: That will make collaboration a bit harder.. :) [11:10] pot calling the kettle black [11:10] 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] Hope I've provided enough details on the report thing [11:10] Like I said, only removing the target for snapd *integration* [11:10] not snapd itself [11:10] Besides, I made aa-lsm-hook, not removing apparmor now :P [11:16] * Chipaca hugs ikey [11:16] ikey: thank you, and sorry, and … stuff [11:16] Chipaca, pfft dont be. you're awesome [11:17] ikey: "sorry for not being awesomer" sounds like a lame non-apology [11:17] lol [11:18] ikey: to be clear, thank you for speaking up and not just going off in a huff [11:18] that's hard to do and i appreciate it a lot [11:18] 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] bit hard to cross back over the river when the bridge is in flames :) [11:19] * Chipaca brings out the marshmallows [11:19] 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] like, ok now we know such and such doesn't happen now, revisit it then, and correct stuff in the meantime [11:20] too old and hairy now for drama [11:22] mborzecki can you please look at https://travis-ci.org/snapcore/snapd/builds/341366071?utm_source=github_status&utm_medium=notification [11:22] looking [11:22] one test failed there [11:22] doesn't look related to the change [11:25] hmm, w8, how does it pass on master? [11:25] what do you mean? [11:27] zyga: https://github.com/snapcore/snapd/pull/4654 stops the timer in prepare [11:27] PR #4654: tests/lib/prepare: disable snapd.refresh.timer [11:27] maybe we are running tests of the branch, not of the merged result [11:27] (that would be an interesting find) [11:28] iirc that's what travis does by default [11:28] that == merged or just branch? [11:28] branch [11:28] anyways, that test was there before right? [11:29] yes [11:30] 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] yeah, I don't know that [11:30] clearly it will file if the timer is stopped [11:31] so somehow it must be started again :/ [11:38] + test -f /usr/share/dbus-1/services/io.snapcraft.Launcher.service [11:38] + diff -u /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig /usr/share/dbus-1/services/io.snapcraft.Launcher.service [11:38] --- /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig 2017-12-18 14:41:33.000000000 +0000 [11:38] +++ /usr/share/dbus-1/services/io.snapcraft.Launcher.service 2018-02-13 16:57:31.000000000 +0000 [11:38] @@ -1,3 +1,4 @@ [11:38] [D-BUS Service] [11:38] Name=io.snapcraft.Launcher [11:38] Exec=/usr/bin/snap userd [11:38] +AssumedAppArmorLabel=unconfined [11:38] ----- [11:38] I have a feeling that our prepare restore code is buggy [11:39] mvo: tweaked the system-shutdown sync comment, see what you think [11:39] might be getting a little rambly [11:53] + snap install test-snapd-control-consumer [11:53] error: cannot install "test-snapd-control-consumer": cannot get nonce from [11:53] store: store server returned status 418 [11:53] that's the teapot, right Chipaca ? [11:53] yes [11:54] mup, what's http status 418 [11:54] Chipaca: In-com-pre-hen-si-ble-ness. [11:54] zyga: se? [11:54] zyga: see? [11:55] thanks [12:03] Chipaca: thanks, comment looks fine [12:03] PR snapd#4662 closed: tests: removing packages which are not needed anymore to generate random data [12:06] [06:16:41 AM] ikey: thank you, and sorry, and … stuff [12:06] did I miss an emotional moment or something? [12:06] we hugged [12:06] :3 [12:06] Son_Goku: ikey called us out on stuff we thought we were better at than we are [12:07] Chipaca: I just don't bother anymore [12:07] Son_Goku: you're just wanting a hug too [12:07] * Chipaca hugs Son_Goku [12:07] aww [12:07] * Son_Goku hugs Chipaca back [12:07] o wait its valentines day [12:07] not to make the hugs awkward or anything [12:07] Yeerp [12:07] .. :D [12:07] :D [12:07] * zyga would pour some vodka but then again this is IRC [12:07] I stay the _hell_ away from your vodka [12:08] yeah you can only have 512 of the vodka [12:08] haha [12:09] 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] unlike ikey though, I don't have the time to dig into everything all the time [12:09] so I just kinda let it go and hope something comes up to give me a better picture later [12:09] I've barely had _any_ time to work on the RPM backend for snapcraft [12:10] which I already know requires me to implement some functionality in DNF to make things a little less stupid [12:11] Son_Goku btw, offtopic. hurricanehrndz is idle for about a month (on irc), is that the right nickname? [12:11] I think that's the right nick [12:12] worst case, I'll probably do some work myself on the openSUSE packaging [12:12] PR snapd#4664 closed: interfaces/apparmor: ensure snap-confine profile for reexec is current [12:12] PR snapd#4666 closed: interfaces/apparmor: generalize apparmor load and unload helpers [12:13] 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] it doesn't even have to involve code [12:13] just at least discussions with selinux developers to figure out gaps and how to close them, if any [12:14] and of course, a way to swap core snaps for building a modular Fedora system built on snaps [12:14] that 2nd thing may come out of base/core 18 work where things will force us to move snapd out of core [12:14] or out of the "one" nap [12:14] *snap [12:15] naming things aside [12:15] 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] mborzecki: Replied in the timer conversation [12:18] niemeyer: thanks [12:19] * zyga switches focus to user mounts for the rest of the day [12:19] and takes a break to relieve back pain [12:25] * kalikiana going for a brief break [12:28] * Chipaca -> lunch [12:39] PR snapcraft#1925 opened: elf: cache crawled files [12:42] PR snapcraft#1922 closed: elf: fast track when the host used matches the base [12:44] 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] 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] PR snapd#4658 closed: many: don't allow layout construction to silently fail [13:36] * kalikiana lunch [13:58] 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] pedronis: thanks, I will prepare a PR and ask you for a review (with appropriate comments) [14:01] PR snapd#4667 opened: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test [14:05] 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] koza: I don't know in general, prepare-device will be retried though if needed [14:08]