=== JoshStrobl is now known as JoshStrobl|AFK [03:54] PR snapcraft#1642 opened: tests: move the plainbox test to the integration suite [03:57] PR snapcraft#1643 opened: [WIP] tests: run daily autopkgtest in travis [05:26] good morning [05:33] zyga-ubuntu: good morning ! [05:33] zyga-ubuntu: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810 - looks like something for pawel [05:43] PR snapcraft#1644 opened: lxd: fix the push in container builds [05:55] PR snapd#4079 closed: daemon: allow Polkit authorization to cancel changes === kira is now known as Guest63697 [06:07] PR snapd#4082 opened: cmd/snap: tell translators about arg names and descs req's (2.29) [06:08] PR snapd#4083 opened: snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) [06:11] PR snapd#4084 opened: interfaces: clean system apparmor cache on core device (2.29) [06:12] Hello currently working on ubuntu core 16 need to build qt application which works on postgres database do [06:12] on need to create a separate snaps for it [06:12] and is any document for qt and postgres [06:15] Guest63697: hello [06:15] Guest63697: I don't know about postgres but there's something for a kiosk qt app [06:15] Guest63697: my suggestion would be to get postgress up and running [06:16] Guest63697: and then move on to qt [06:16] Guest63697: also, not sure why you want separate snaps for that but that's ok, you will just need to use content interface to share data/sockets so that they can talk to each other [06:16] PR snapd#4085 opened: debian: do not build static snap-exec on powerpc (2.29) [06:16] zyga-solus: Hi for more details i am currently working on dell edge gateway 5000 with ubntu core16 installd [06:18] Guest63697: right, you can prototype this on a typical ubuntu system (16.04 is ideal) and then just install the resulting snap on the device [06:18] mvo: o, looking [06:19] zyga-solus: I am new to the core os i just tried running hello world application so needed jus help to move my existing application to core :) [06:19] mvo: aha, I see that service management test failed [06:20] Guest63697: I suggest you start by learning about snapcraft, using snaps on your 16.04 desktop/laptop (classic system) and playing with your core system with a few snaps [06:20] Guest63697: build a hello-world.c from source, see how that looks like [06:20] Guest63697: then look at what it would take to run postgres === JanC is now known as Guest53324 === JanC_ is now known as JanC [06:20] Guest63697: or separately at kiosk-style Qt (this is documented on the forum) [06:21] Guest63697: in the end all the pieces will come together and you should get it to work fine [06:21] Guest63697: stick around, join the forum, experiment. read, and ask :) [06:21] oh, and welcome :-) [06:21] mvo: I'll ignore that master failure for now unless pawel comes around and asks for help [06:21] mvo: I need to finish apparmor changes for overlayfs [06:22] mvo: and expand the spread tests for that [06:22] zyga-solus: I have been searching on the web a multiple links can you please suggest any useful and just for curiosity should i put all the application and its dependecy under one snp [06:22] Guest63697: try forum.snapcraft.io [06:22] Guest63697: we also have a snapcraft tutorial on ... [06:22] https://docs.snapcraft.io/build-snaps/your-first-snap [06:22] zyga-ubuntu: yeah, just a heads up about the failure not a request-for-action :) [06:23] note that you can use a classic "regular" ubuntu system for all of this [06:23] that's the beauty of snaps :) [06:23] zyga-solus: sure thanks [06:23] in the end you just deploy it on core [06:23] mvo: ack, thank you :) [06:23] PR snapd#4081 closed: systemd: run all mount units before snapd.service to avoid race [06:23] mvo: I was asking my son if he would like to wake up at 3AM tomorrow to look at sunirse in the nearby fields, we could take some photos of the birds nesting there [06:23] mvo: I was talking about this the whole week [06:24] mvo: and while earlier he was "yeah dad, that would be fun" [06:24] mvo: today he said "but if we stay at home, can we sleep longer" [06:24] mvo: I think I lost that one :) [06:24] mvo: if you want I can work on mount unit refresh later today [06:25] mvo: I'd like to think how to approach that: as a fixup type thing or as a change in how we maintain them [06:28] PR snapd#4086 opened: snap-confine: increase sanity_timeout to 6s [06:28] zyga-ubuntu: it seems conceptually cleaner to do the later [06:29] mvo: I agree but then my conclusion was, if this is something that will run in ensure (that is, all the time)? [06:30] mvo: and if so, what should we do after we notice that the files were chaned [06:30] mvo: I was thinking that this is where it gets hairy [06:30] mvo: we could log "discrepancy in unit %q" [06:30] mvo: and do nothing at all (for this specific case that's fine) [06:30] mvo: but it feels like a stretch of the concept [06:30] mvo: we also don't have similar ensure for interfaces [06:30] mvo: but [06:31] mvo: if we actually do this then the system is self-healing in a nice way [06:31] zyga-ubuntu: well, if its a one-off thing we should handle it like this and not complicate things, just a "fixupMountUnits()" somewhere [06:31] mvo: ^ commented on the PR, I think you need to change a few tests too [06:31] zyga-ubuntu: 2.29 is super close this healing thing may not even make it [06:32] mvo: yes, I agree we absolutely have to have something for 2.29, so a fixup is good [06:32] zyga-ubuntu: aha, thanks. we have two autopkgtest failures where the alarm goes of [06:32] mvo: maybe 2.31 target for generic healing [06:32] zyga-ubuntu: 2.29 is super close, candiate targeted monday so it may not even make it [06:32] zyga-ubuntu: but if it does even better [06:32] zyga-ubuntu: I plan ~rc2 today [06:32] zyga-ubuntu: and hopefully that is the last one [06:32] mvo: for the tests we need "make check" to pass [06:33] mvo: what about 4008? [06:34] zyga-ubuntu: its still hanging there, I wanted to see where things are at lunchtime, if everything else is in and ready +1 [06:35] zyga-ubuntu: thanks, I adjusted the test now. I did a force push to make it easier to cherry-pick (either way) [06:36] mvo: no worries, I approve of --force ;D [06:47] PR snapd#4087 opened: cmd: downgrade log message in InternalToolPath to Debugf() [07:32] pstolowski: hey, good morning. you have two 2.29 targeted PRs, could you please create a branch based on upstream/release/2.29 and cherry-pick your commits to it so that we merge to 2.29? [07:32] pstolowski: also master is failing right now [07:34] mvo, sure [07:35] mvo, what is failing? [07:43] o/ [07:58] zyga-ubuntu: I am trying run the qt4 text editor example on from snapcraft github it is giveing error as application cannot connect to x server [08:00] Guest63697: on core or on classic? [08:00] zyga-ubuntu: on core [08:01] on core there's no display stack [08:01] you need to look at qt + kiosk mir demos for that [08:15] pstolowski: sorry for the delay, I was distracted: master is broken currently :/ https://travis-ci.org/snapcore/snapd/builds/293175118#L5810 [08:15] pstolowski: maybe racy? [08:15] pstolowski: line 5810 (takes forever to load for me :/ [08:16] pstolowski: maybe https://travis-ci.org/snapcore/snapd/builds/293175118#L5758 works better? [08:17] pstolowski: the gist is http://paste.ubuntu.com/25828740/ [08:17] mvo, thank you [08:17] mvo, oh damn.. this indeed might be racy. i wonder what to do about that test :( [08:18] pstolowski: sleep 10 - what we always do (kidding of course) [08:18] i guess we need a function that tries a couple of times until a timeout passed, then it gives up [08:19] pstolowski: yeah, I think that is sensible [08:20] mvo, ok, i'll work on this, sorry about the problem [08:21] pstolowski: no worries, thank you [08:23] mvo, when cherry-picking for 2.29, is it ok to squash? [08:25] pstolowski: if it is merge in master already then please cherry-pick individually otherwise the merge of 2.29 into master will be infected with conflicts [08:26] pstolowski: if it is not merged yet the easiest is to squash merge when merging into master to get any easy cherry-pick [08:27] mvo, ack [08:40] mvo: hi, I'm trying to finish something not to lose state, let's talk about ignore-validation after lunch [08:42] pedronis: +1 [08:54] PR snapd#4082 closed: cmd/snap: tell translators about arg names and descs req's (2.29) [09:01] is there a way for a snap to know the underlying os version? (not the core snap one) [09:04] ackk: mmm, no I don't think there is === JanC_ is now known as JanC === JoshStrobl|AFK is now known as JoshStrobl [09:17] * zyga-ubuntu -> coffee [09:17] pstolowski: while you fix the test I can help with the 2.29 cherry-picks for 4070 - we need this for 2.29, right? its a bugfix aiui? [09:19] PR snapd#4088 opened: snapctl: cherry pick service commands changes [09:20] mvo, ^ [09:21] mvo, yes, it's kind of a bugfix [09:23] mvo, nb, i think 4080 is not very important for 2.29 [09:27] pstolowski: thank you [09:28] pstolowski: what branches does 4088 cover? i.e. which of the previous PRs that were tagged 2.29? [09:29] mvo, 4070 and 4065 (the latter for prerequisite for the former anyway) [09:31] oooh [09:31] man [09:31] after using vim for what, 20 years [09:31] I learned what "x" is for when in directory listing mode [09:33] pstolowski: do we need to cherry-pick b693557 in 4088 as well? its the last commit in 4070? [09:34] mvo, oh yes, that a test only, but yes. done [09:34] ta [09:35] zyga-solus, do you think that adding an interface for allowing that would be accettable? [09:35] ackk: not sure how such an interface would look like [09:35] ackk: why do you need this information? [09:35] ackk: and how would you expect to read it? [09:36] zyga-solus, for an app to expose the information. perhaps reading /etc/os-release from the host (possibly linked somewhere else) [09:38] ackk: most apps I know of don't read or expose /etc/os-release, I'm sure there must be some special cases though that's why I'd like to understand the need better [09:38] ackk: /etc/os-release says you are on ubuntu core [09:41] yeah [09:52] mvo, ok, i've a tentative fix for test race, let's see how travis likes it, i've never experieced it locally [09:53] pstolowski: great [09:53] and i hope it's a race, nothing else [09:53] pstolowski: looking forward to it, my top priority for today is to get the 2.29 branches in and release 2.29~rc2 to beta so that it can go to candidate monday. having master in good shape is vital .) [09:53] pstolowski: yeah [10:10] man, it's cold today [10:10] PR snapd#4088 closed: snapctl: cherry pick service commands changes [10:11] PR snapd#4089 opened: tests: wait for service status change & file update in the test to avoid races [10:12] mvo, ^ [10:16] pstolowski: thanks a bunch, lets see if travis is happy with this [10:27] ok [10:27] fingers crossed [10:29] mvo: so just to confirm, 4008 should be squash merged today [10:34] zyga-solus: if we want it in, yes [10:37] mvo: ok, please tell me when === JoshStrobl is now known as JoshStrobl|zzz [10:55] zyga-solus: ackk /etc/os-release is already exposed in apparmor afair [10:57] kalikiana: yes but it doesn't show you the real /etc/os-release file [10:57] kalikiana: it shows the one from the core snap [10:59] zyga-solus: Hmm classic snaps can see the real file... but I guess in that case apparmor doesn't apply anyway [11:01] kalikiana: can you show me how you determined that? [11:02] kalikiana: I just saw the file from core snap on a 16.04 test vm [11:03] zyga-solus: snapcraft can read the file. From checking interfaces/apparmor/template.go in snapd sources it's not obvious, though, if that applies or not [11:03] To me at least [11:03] kalikiana: I didn't say that it is not unreadable, it *is* readable [11:04] kalikiana: I said that it should almost always contain the /etc/os-release file from the core snap or other base snap that is used by a given app snap [11:04] kalikiana: thus when read on fedora it will not say "fedora" [11:04] kalikiana: it will consistently say "ubuntu core" or whatever the base snap says [11:05] zyga-solus: Right. I didn't mean to contest that... maybe bad wording on my part [11:05] kalikiana: no worries, I just wanted to explain what I meant earlier :) [11:08] zyga-solus: I think it technically makes sense so long as you have no access to the underlying system. Tho it would make something like a user agent that's used for statistical purposes impossible [11:11] PR snapd#4089 closed: tests: wait for service status change & file update in the test to avoid races [11:11] kalikiana: yes, I agree [11:11] technically we have the real file in /var/lib/snapd/hostfs/{etc,lib}/os-release but it is not readable in strictly confined apps === chihchun_afk is now known as chihchun [11:29] PR snapd#4087 closed: cmd: downgrade log message in InternalToolPath to Debugf() [11:57] hrm [11:57] some good and some bad news [11:57] let's make a PR [12:04] zyga-solus, kalikiana: /var/lib/snapd/hostfs/{etc,lib}/os-release is actually allowed via system-observed [12:04] system-observe* [12:05] PR snapd#4090 opened: interfaces/mount: exspose mount.{Escape,Unescape} [12:07] jdstrand: oh! [12:07] jdstrand: that's neat, I didn't know [12:07] (and didn't check apparently :) [12:08] mvo: I'm merging 4008 (squash) [12:08] mvo: speak now to stop me please [12:09] mvo: 3... [12:10] PR snapd#4086 closed: snap-confine: increase sanity_timeout to 6s [12:10] mvo: 2... [12:11] mvo: 1... [12:12] merging [12:13] PR snapd#4008 closed: cmd/snap-update-ns: create missing mount points automatically [12:16] PR snapd#4060 closed: interfaces: clean system apparmor cache on core device [12:16] PR snapd#4091 opened: cmd/snap-update-ns: allow fault injection to provide dynamic result [12:16] zyga-solus: ok, no worries [12:17] mvo: you can cherry pick for 2.29 [12:22] jdstrand: Does system-observed change which one /etc/os-release points to? Is it still the one from the core snap? [12:23] kalikiana: no, it doesn't [12:23] PR snapd#4069 closed: debian: do not build static snap-exec on powerpc [12:23] PR snapd#4092 opened: cmd/snap-update-ns: allow Change.Perform to return changes [12:24] PR snapd#4080 closed: snapctl: added long help to stop/start/restart command [12:25] PR snapd#4085 closed: debian: do not build static snap-exec on powerpc (2.29) [12:30] PR snapd#4083 closed: snap-{confine,seccomp}: make @unrestricted fully unrestricted (2.29) [12:30] PR snapd#4084 closed: interfaces: clean system apparmor cache on core device (2.29) [12:33] zyga-ubuntu: just to double check - freezeSnapProcess() is now called everytime snap-update-ns is run, right? with 4008? [12:34] yes [12:43] kenvandine, hey [12:49] mvo: I have one more for 2.29.2 [12:51] zyga-solus: which one? [12:51] mvo: https://github.com/snapcore/snapd/pull/4093 [12:51] PR #4093: cmd/snap-update-ns: initialize logger [12:51] just one liner [12:52] but it will help us in case 4008 explodes in the field [12:52] cachio, hey [12:52] zyga-ubuntu: ok [12:52] PR snapd#4093 opened: cmd/snap-update-ns: initialize logger [12:53] kenvandine, I copied the approach you use for the calculator [12:53] kenvandine, but still it can't access to the gsettings schema [12:53] I it copying the schema to the correct place [12:54] cachio, can i get a checkout of your yaml? I'll try it myself [12:54] kenvandine, https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings/tests/lib/snaps/test-snapd-gsettings [12:54] cachio, i have a bunch of snaps all using gsettings [12:54] kenvandine, I know [12:55] kalikiana: system-observe doesn't change the system. you can either look at /etc or /usr/share/... for what the os-release is for the snap's runtime (you have access to this by default), or you can plugs system-observe and look in hostfs to see what the host system is [12:55] zyga-solus: re new> yes, it is a recent update [12:55] cachio, oh... you aren't using the desktop helpers [12:55] i bet that has something to do with it [12:55] kenvandine, how should I add it? [12:56] the desktop helpers probably tweak the schema env [12:56] after: [desktop-gtk3] [12:56] for example [12:56] and command: desktop-launch check-schema [12:56] or you can look at the launcher script and reproduce that in your own script [12:57] kenvandine, ok, I'll try that [12:57] that helpers sets lots of env needed for desktop stuff [12:57] kenvandine, thanks [12:57] np [13:00] jdstrand: Alright, that makes sense, thanks for clarifying! I guess even in that case it's best to have both available and not just change behavior. [13:29] PR snapcraft#1625 closed: tests: use the snapcraft snap for integration tests [13:34] jdstrand: hey [13:35] jdstrand: do you have 15 minutes to consider and answer a question? [13:35] jdstrand: it would require you to have spread (local or remote) and checkout my branch, run it, get a denial and see what you think about it [13:36] jdstrand: I suspect you know the answer without running it [13:36] jdstrand: but I wanted to check [13:39] kenvandine, works with the desktop-lunch [13:39] launch [13:39] popey: hey! was looking at this yaml a few days ago but couldn't find it today. Do you have a copy ? https://github.com/snapcrafters/pycharm-community/blob/master/snap/snapcraft.yaml [13:39] thanks [13:39] (need that yaml file to snap a related project) [13:39] cachio, cool [13:39] hi om26er [13:40] i deleted the repos from snapcrafters because it's owned upstream now. I have a backup though, can pastebin if you need it? [13:40] popey: yes, that would do. [13:41] http://paste.ubuntu.com/25830418/ [13:41] PR snapd#4094 opened: tests: cherry pick the fix for services test into 2.29 [13:43] mvo, ^ [13:44] pstolowski: ta! [13:45] mvo, the changes to help docs seem to already be there in 2.29, guess you merged them [13:45] pstolowski: yeah, I cherry picked [13:45] cool, thanks [13:48] popey: I would need the .desktop file as well :) [13:49] http://paste.ubuntu.com/25830453/ [13:49] sorry [13:57] * zyga-solus lunches [14:02] PR snapd#4093 closed: cmd/snap-update-ns: initialize logger [14:02] thank you :) [14:03] mvo: is Chi-paca supposed to be back Monday? [14:04] pedronis: AFAIK he is [14:04] zyga-solus: thank *you* and cherry-picked into 2.29 [14:07] PR snapd#4095 opened: debian: make packaging/ubuntu-14.04/copyright a real file again [14:11] hey folks, is it possible to have private snaps using the public store? [14:11] when will build.snapcraft respect `architectures` config ? [14:16] kenvandine: hey, fyi I noticed an issue with the gedit snap [14:16] om26er, https://forum.snapcraft.io/t/snapcraft-build-on-hint-for-builders/939 [14:16] jdstrand, oh? [14:16] mattyw: yes, but just keep in mind a private snap is just for the publisher and collaborators, e.g. for QA prior to release. Collaborators have full read-write access to the snap. [14:17] kenvandine: if you go to open a file and get the gtk3 file chooser, in the upper left the 'Documents', etc don't work as expected because they are expecting those folders to be under SNAP_USER_DATA (ie, what HOME is set to) [14:17] noise][, is it possible to define who the collaborators are - like if I have a snap that I just want people in my team to have access to? [14:17] kenvandine: the Documents, etc in the lower left all work fine [14:17] jdstrand, yeah, i haven't figured out what to do with that [14:17] portals will help [14:18] mattyw: yes - on your snap details page on dashboard.snapcraft.io, there's a "Collaboration" link in the side nav [14:18] kenvandine: it should. another idea is to symlink from SNAP_USER_DATA/Documents to /home/user/Documents [14:18] jdstrand, oh... we could do that in the helpers [14:18] kyrofa: when you're up, perhaps we can chat about snapcraft#1641 briefly? [14:18] PR snapcraft#1641: lxd: catch CalledProcessError in _container_run [14:18] right [14:19] zyga-solus: can you just show me the denial, the spread test and the branch of the code? [14:21] kalikiana, let me take a look here... [14:22] jdstrand, i'll take a swing at that [14:22] kalikiana, alright, want to HO real quick? [14:22] jdstrand: ha, no denial, this is overlayfs [14:22] kyrofa: Yeah, gimme 1 minute to fetch my headset [14:22] Sure thing [14:23] jdstrand: I can show you the branch if you want to try [14:23] one sec [14:24] jdstrand, actually the helpers run from within the snap and don't have access to $HOME [14:25] jdstrand: fetch my remote please, go to feature/transparent-overlayfs and pop one patch off, that is go to bc687e812a693afe532f51803645cc41d027de00 - then run SPREAD_DEBUG_EACH=0 spread -debug -v -reuse qemu:ubuntu-16.04-64:tests/main/interfaces-content-mkdir-writable:snap [14:25] kalikiana, haha you're ringing my phone, hold on, I need to learn how to use hangouts [14:25] kyrofa: https://hangouts.google.com/hangouts/_/ygq3wu36wzebfjotr7gdj7ofhye [14:25] we'd have to do some mangling of the paths like in $SNAP_USER_DATA [14:25] kyrofa: Oh, heh. Wasn't my intention. Just created a hangout ( I think...) [14:25] Ah excellent [14:26] jdstrand: I'm running it here [14:27] kenvandine: gedit plugs the home interface [14:28] yes [14:28] but we don't have proper $HOME i meant [14:28] so we would need to strip out part of the path [14:28] doable though [14:28] use getent. there is already stuff in there [14:28] oh cool [14:29] * zyga-ubuntu is a bit preoccupied and worried about Spain vs Catalonia just now; Catalonia has just declared independence [14:29] kenvandine: getent passwd $UID | cut -d ':' -f 6 [14:29] jdstrand, yeah, thanks! [14:29] * kenvandine always forgets about getent :) [14:29] zyga-ubuntu: you asked me to look at something with overlayfs. what is it you want me to look at? [14:29] jdstrand: yes [14:30] jdstrand: that's exactly that branch and that is exactly what I'm running as well [14:30] note, this is not going to take only 15 minutes if you are asking me to verify that it is going to dtrt with apparmor [14:30] jdstrand: to ensure we're seeing the same thing [14:31] 2017/10/27 14:31:17.262504 main.go:154: cannot apply mount change mount (/snap/test-snapd-content-advanced-slot/x1/source /snap/test-snapd-content-advanced-plug/x1/target none bind 0 0): cannot open path segment "x1" (got up to "/snap/test-snapd-content-advanced-plug"): permission denied [14:31]