[00:01] I usually do that latter with sudo ./ubuntu-device-flash core 16 --channel=edge --gadget=canonical-pc --kernel=canonical-pc-linux --os=ubuntu-core -o ubuntu-core-16.img [00:01] wililupy: It sounds like your "su" method to become root is not running as a login shell, and so not reading /etc/profile to set PATH to find snaps. [00:02] wililupy: compare $PATH from two environments. [00:02] Thanks qengho. I started digging into it some more and I have some other issues with the snap as well. Upstart seems to not like it either and it's not loading the services properly. [00:02] It? snapd? [00:03] the snap has a service that runs for console redirection and ASIC driver communication with kernel drivers. [00:05] When I run the console command to get into the ASIC programming console, I get an error Unable to connect to Upstart: Failed to connect to socket com/ubuntu/upstart: Connection Refused [00:06] If I try to run sudo snap.console it says command not found, but if I run it from /snap/bin I get the above error about Upstart and a missing file that I have never heard of. [00:06] ...Gremlins.... [00:10] wililupy: what file? [00:12] My atom-fusion package still doesn't seem to be publicly available for download. I uploaded it to the store 16 hours ago. Anyone have any ideas how I can make it available? I took a screenshot of its publish history if that helps http://i.imgur.com/gYJWbap.png [00:14] fusion809: installing from same machine as where you built it? [00:14] Installing it isn't the problem, it's getting the package available from the official snap repository. [00:15] I am installing it just fine, and I'm working on Arch Linux so that's a feet in itself. [00:15] feat^ [00:16] fusion809: yep. Are you installing on the same machine as where you built? [00:17] I built it in a Docker container (for Ubuntu 16.04) that I'm running on the same machine as where I installed it. [00:17] fusion809: is that the same architecture? Not amd64 vs i486? [00:18] AMD64, I'm pretty sure Docker doesn't even run on 32-bit platforms, nor does it provide containers for 32-bit systems [00:18] fusion809: what's the name? [00:19] "atom-fusion" [00:19] ? [00:19] Exact snap package name is atom-fusion_1.8.0_amd64.snap. So yeah atom-fusion is the package's name [00:24] fusion809: it can take a few minutes to publish, but there could be something wrong. At bottom, file a bug report. [00:24] It's been 16 hours, so yeah probably need a bug report. [00:35] qengho: /usr/sbin/console.fp [00:37] Done reporting the bug https://bugs.launchpad.net/snapcraft/+bug/1594622 [00:37] Launchpad bug 1594622 in Snapcraft "Package Uploaded via web browser not being added to public repository" [Undecided,New] [00:37] qengho: I'm going to try rebuilding my snap with confinement: devmode to see if I can get more logs. [00:38] qengho: Thank you so much! [00:40] wililupy: Are you acessing $SNAP/usr/bin/console.fp? [00:49] wililupy: I think that's your problem. /something instead of $SNAP/something . [01:15] hey [01:15] anyone around? [01:16] o/ [01:16] !help | johnsel [01:16] johnsel: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [01:16] :) [01:16] alright, fair enough [01:17] ./openvpn: error while loading shared libraries: libpkcs11-helper.so.1: cannot open shared object file: No such file or directory, any clues? [01:17] it's in the snap itself [01:17] at ./usr/lib/x86_64-linux-gnu/libpkcs11-helper.so.1 [01:18] hmm weird [01:18] johnsel: stick around, maybe someone else has a better answer :) [01:18] I will, meanwhile I'm going to try and compile it from source [01:18] See if that helps [02:20] elopio hey, what is the easiest way to debug the fake servers? Seeing this https://github.com/ubuntu-core/snapcraft/pull/584 === zeroedout_ is now known as zeroedout [02:31] sergiusens: could you paste the error? [02:38] elopio: could you look at my PR again? [02:54] tsimonq2: I can review it tomorrow. [02:57] elopio: thank you :) [03:47] tsimonq2: are you running the tests locally, for your subversion patch? [03:50] qengho: yeah, but I can't figure it out [03:52] qengho: see anything I'm missing? === cpaelzer_ is now known as cpaelzer === chihchun_afk is now known as chihchun [06:42] hey there [06:43] does anyone know if it's possible to tell snapcraft to stage some packages from a ppa or a local dir? [06:48] seb128: not possible, last time I checked. [06:49] qengho, thanks, I'm going to file a bug against snapcraft I guess [06:54] seb128: while you're at it, please ask for APT-like source semantics. foo=version, foo/release, with whatever you think is best for PPA and whatnot. Maybe "foo@ppadescription" [06:54] hum, if I remember some discussion, snapcraft was supposed to take your source.list [06:54] and so, yours ppa [06:54] instead of rewriting it [06:54] that was in february [06:54] (however, that ofc, won't work in cleanbuild or launchpad, which is an issue) [06:54] It does, didrocks, but that only works for your machine. the yaml isn't very portable. [06:55] right! [06:56] good enough for today, I'm going to play with that, but first coffee [07:12] o/ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:22] hey hey [07:23] hey it's dholbach! o/ [07:23] dholbach: how are you? [07:24] hey hey - doing well - how about you? :-) [07:24] qengho: do we have a Chromium snap? [07:24] dholbach: awesome :) [07:26] tsimonq2: Yes. Its security policies are almost available, and it works pretty well in devmode. [07:28] qengho: do you have code somewhere that I could take a peek at? [07:32] hey dholbach [07:32] salut seb128 [07:36] tsimonq2: Well, the recent parts will be in snapd, but the snapcraft that uses it will be something like https://code.launchpad.net/~chromium-team/chromium-browser/snappy-packaging [07:44] oh cool, thanks qengho :) [09:14] hmm, whern i use the mak plugin, shouldnt snapcfat clean call make clean ? [09:14] *snapcraft [09:15] ogra_: make clean make :) [09:15] my faviourite solution to WTF issues [09:15] zyga, well, i want snapcraft to clean up when i call clean [09:16] yeah === iahmad is now known as iahmad_ === iahmad_ is now known as iahmad [09:24] hmm, is discarding the build dir enough? [09:41] !info python-magic [09:41] python-magic (source: file): File type determination library using "magic" numbers (Python bindings). In component universe, is extra. Version 1:5.25-2ubuntu1 (xenial), package size 5 kB, installed size 53 kB [09:41] \o/ [10:00] hiall [10:01] hello matteo :) [10:10] !info gplugin [10:10] Package gplugin does not exist in xenial [10:11] !info gplugin-dev [10:11] Package gplugin-dev does not exist in xenial [10:11] :( [10:26] !info help2man [10:26] help2man (source: help2man): Automatic manpage generator. In component universe, is optional. Version 1.47.3 (xenial), package size 108 kB, installed size 420 kB [10:26] \o/ [10:32] !info gobject-introspection-1.0 [10:32] Package gobject-introspection-1.0 does not exist in xenial [10:32] !info gobject-introspection' [10:32] gobject-introspection (source: gobject-introspection): Generate interface introspection data for GObject libraries. In component main, is optional. Version 1.46.0-3ubuntu1 (xenial), package size 261 kB, installed size 1412 kB [10:47] !info default-mta [10:47] Package default-mta does not exist in xenial [10:47] !info mail-transport-agent [10:47] Package mail-transport-agent does not exist in xenial [10:47] grr [10:47] !info urlview [10:47] urlview (source: urlview): Extracts URLs from text. In component universe, is optional. Version 0.9-20 (xenial), package size 19 kB, installed size 65 kB [10:47] !info aspell [10:47] aspell (source: aspell): GNU Aspell spell-checker. In component main, is optional. Version 0.60.7~20110707-3build1 (xenial), package size 77 kB, installed size 360 kB === hikiko is now known as hikiko|ln [11:28] mvo: hey, I'm trying to make a mutt snap and I'm getting thrown a build error, would you be able to test if my snap works locally? dholbach says that you use mutt. https://github.com/ubuntu/snappy-playpen/pull/98 === chihchun is now known as chihchun_afk [11:45] tsimonq2: mutt! [11:45] tsimonq2: \o/ [11:46] heh [11:47] mvo: I'm going to bed, weird sleep schedules, so if you have any suggestions, comment on the PR [11:47] but yes, mutt! \o/ [11:47] :P XD [11:47] o/ [11:47] tsimonq2: will do. mutt! I'm excited :) I love my mutt [11:47] is that known that a "cp -a" triggers an invalid syscall under restricted snaps? === hikiko|ln is now known as hikiko [11:54] seb128, yeah, chown I think [11:55] kyrofa, is that a bug or a feature? [11:55] seb128, I assumed a feature, but jdstrand would know more [11:55] k [11:57] kyrofa, thanks for your replies on the channel btw ;-) [11:58] seb128, haha, of course! [11:59] kyrofa, do you have an idea why snapcraft clean doesnt trigger a make clean call when using the make plugin ? [11:59] Who's stealing all the armhf and arm64 launchpad builders!? [11:59] i kind of expected it would [11:59] kyrofa, doko most likely [11:59] ogra_, because it's not the smart :( [11:59] ogra_, remember make isn't the only build system it supports [11:59] ah [12:00] ogra_, its version of cleaning the source is to blow it away [12:00] ogra_, since that was the shortest path to success [12:00] right ... my makefile copies something to ../src [12:00] ogra_, I full intend on making that better [12:00] fully* [12:00] which i would like to clean along [12:00] Agreed. It would also be awesome if it actually noticed changes to the source [12:00] And just ran make again [12:00] yeah [12:01] But I need to come up with a generic way to do that for all build systems [12:01] Something that can be extending via local plugins [12:01] is there a way to do the pull/build again on some parts and not others? [12:01] seb128, yeah, but the inconsistency would be confusing [12:01] like to not redo a full source build everytime just because you changed the wrapper or the stage packages [12:01] anyone here with a 32 bit distro? [12:01] stop building that giant stuff :P [12:02] matteo, _o/ [12:02] seb128: http://pastebin.ubuntu.com/17638846/ [12:02] can you run this? [12:02] seb128, yeah that should be possible. You have to rebuild the part on which you changed the stage packages though... no way around that I don't think [12:03] seb128, if you have stage packages on a part that's building something, and it doesn't actually need or use the stage packages, you might be better off putting those stage packages in their own part, even if using the nil plugin [12:03] kyrofa, right, that's fine, it's "deb" part ... how do I do that? how do I tell it to repull the debs part only? [12:04] seb128, yeah it's not that fine-grained. The stage packages are pulled during the pull step [12:04] Along with the source code [12:04] can I pull only one part? [12:04] seb128, so you might want to have them in separate parts [12:04] seb128, oh certainly! [12:04] seb128, `snapcraft pull ` [12:04] seb128, that applies to all steps: `snapcraft build ` [12:04] seb128, `snapcraft clean --step=build` [12:05] ah [12:05] seb128, note that "snap" is not a valid step though, since it's what creates the image. i.e. `snapcraft snap ` is not a valid command [12:06] kyrofa, thanks, seems obvious now the mention it, I sort of got lost between the steps and parts for some reason [12:07] seb128, heh, no problem. Our `help` could probably use a little love [12:08] matteo, is there anything specific you are looking for/any error you hit? that's just on a normal system or under snappy? xenial? [12:10] seb128: does it download the whole file? [12:10] normal system [12:12] seb128: I get this: http://pastebin.ubuntu.com/17639303/ [12:30] snappy on arc isn't full supported yet, right ? [12:31] killua99, zyga should be able to tell you [12:32] I mean the arc aur package did install. I did just install krita over snap, but I can't find the app :D [12:33] you might need to re-login after installing snapd ... it ships an /etc/profile.d snippet to enhance your PATH [12:33] though krita also has a .desktop file, if you use some desktop with menu, it should show up there too [12:33] killua99, indeed, as ogra mentioned /snap/bin needs to be in your PATH [12:34] ogra@styx:~$ which krita [12:34] /snap/bin/krita [12:34] thats what i get on ubuntu [12:34] i would assume arch does something like that too [12:34] unless zyga didnt finish up that part yet [12:34] aha, re-login might be the missing part. Thanks ogra_ I'll try that later ;D [12:35] ayan (and Chipaca): re seccomp syscall-- yes, in 2.0.9 [12:35] * Chipaca hugs jdstrand [12:35] wb dude [12:37] good morning [12:37] tedg: snap-confine-- that is precisely it. 1.0.30 in yakkety will have all the fixes. xenial will once zyga/mvo transitions to snap-confine. I think that is imminent [12:37] hey sergiusens, 'sup [12:38] matteo, seems to always return 64823296 here compiled or not [12:38] seb128, kyrofa: chown is bug #1581310. will be fixed with seccomp arg filtering [12:38] bug 1581310 in snapd (Ubuntu) "ubuntu-core doesn't allow sed -i (fchown syscall)" [Medium,Triaged] https://launchpad.net/bugs/1581310 [12:39] well, fixed for many apps [12:39] jdstrand, excellent, thank you :) . How far out is argument filtering, by the way? That will solve many issues [12:39] didrocks qengho seb128 launchpad builders allow you to setup PPAs for the build [12:39] jdstrand, ah ok, thanks [12:39] and yes, ppa support for cleanbuild is the only thing really missing === dpm_ is now known as dpm [12:39] Morning sergiusens! [12:40] sergiusens, k, good to know, I didn't even know that snapcraft was using the system config [12:40] sergiusens, is there any way to give it a specific apt config? [12:43] kyrofa: waiting for (hopefully) final review from tyhicks. things got pushed back due to holidays and sprint [12:43] matteo: can you also print err in that program? ie the last line, make it fmt.Printf("%d copied; %v\n", n, err) [12:43] jdstrand, awesome :) [12:43] seb128 not today; I went back and forwars with Colin on this some time ago and we agreed to make it an out of snapcraft thing [12:44] although for cleanbuild it would need to be supported [12:44] seb128: there is a workaround. snappy-debug tells you to do: cp -r --preserve=mode [12:46] * jdstrand hugs Chipaca back :) [12:46] kyrofa how is it going? [12:47] sergiusens, not bad, how was the extended weekend? [12:49] have you been fathering a lot ? [12:49] jdstrand, thanks, I don't know about snappy-debug, I should give it a try :-) [12:49] sudo snap install snappy-debug [12:50] sudo /snap/bin/snappy-debug.security scanlog [12:50] that will tail /var/log/syslog, dereference syscalls and make suggestions [12:50] k [12:50] (and first run will tell you the proper snap connect command to run [12:50] ) === chihchun_afk is now known as chihchun [12:54] kyrofa turns out I had the flu for 2 weeks and did not notice until the weekend when some dry coughing kicked in :-P [12:55] sergiusens, blech, so a lovely extended weekend then [12:55] it was good still ;-) [12:59] jdstrand: sorry -- what do you mean by 'yes'? [13:00] ayan: yesterday someone asked if the seccomp syscall is allowed. the answer is 'yes' in 2.0.9 [13:00] jdstrand: ah, okay. is 2.0.9 available now? [13:01] ayan: it is released, yes. If you are using Ubuntu, it is in xenial-proposed [13:01] https://launchpad.net/ubuntu/+source/snapd/2.0.9 [13:02] Chipaca: it's nil [13:03] Chipaca: sorry [13:03] 34651558 copied, err: unexpected EOF [13:04] matiasb: there you go [13:07] but, why EOF? [13:26] jdstrand, mvo, do you know if anyone gave some consideration on letting snaps claiming mimetypes and how that could work? [13:27] zyga: hi, can you provide any advice for debugging an interface which includes udev snippets? are the snippets stored in a file somewhere when they are registered? [13:28] seb128 (and mvo): I think someone mentioned it at some point as something we'd want to support in the future. I think that needs proper design. I can sort of see it as an extension to interfaces, but we'd likely need to coordinate with tvoss or others from personal since they have something similar in url-dispatcher [13:30] jdstrand, mvo, would you see an objection on running update-desktop-database on /var/lib/snapd/desktop/applications so applications show as handler in e.g nautilus on unity7? maybe as a temporary thing until we figure out something better [13:32] seb128: otoh, I would, yes. that is too automagical since the snaps could take over mime handling and that should be an explicit choice. I suspect I'll be overruled on that [13:32] that gets back to design [13:33] joc_: hi [13:33] the design should involve discussion regarding how to transition to the new system [13:33] joc_: yes, they end up in /etc/udev/rules.d [13:33] jdstrand, the mailing list would be the right place to start that discussion I guess? [13:34] seb128: I'm not sure. I guess. it depends on if people feel it should be an interface. I guess the mailing list and then someone might ask to file a bug [13:34] k, thanks [13:34] seb128: you might want to wait for mvo to respond though [13:35] I'm getting close from a working evince [13:35] I'm not necessarily up on all the latest decisions [13:35] like I've it opening pdf even in restricted mode [13:35] nice [13:35] but it's a bit less useful if you can't double click on documents [13:35] like if you need to start evince from the dash and then browse to the file you want [13:37] seb128: well, there is the xdg-open thing [13:37] seb128: which is a toe in the water [13:38] Chipaca, the xdg-open things is the other way around though, right? [13:38] seb128: ah! [13:38] having code from inside the snap calling e.g your system browser [13:38] seb128: that's what happens when i skim the backlog and try to be helpful :-) [13:38] lol [13:38] thanks for the reply though ;-) [13:39] zyga: the system /etc/udev/rules.d i.e. not just from the confined app's perspective? [13:40] joc_: yep, the real one [13:40] joc_: if we put udev rules in place we reload udev and re-trigger the rules [13:41] joc_: so you should see stuff happening [13:44] hmm, not sure why i'm not seeing anything === chihchun is now known as chihchun_afk [14:05] jdstrand, so mime handling would be nice, but my real blocker is dconf atm I think ... do you still have that one on your todolist? [14:05] seb128: sounds ok [14:07] seb128: I am not actively working on that. there are 3 parts: 1) create a global gsettings interface that allows access to the global db by the sandbox (assigned to me, I did that) 2) gsettings apparmor backend-- multiple teams, in progress, behind a couple other things wrt security team) 3) making a snap find and use gsettings at all (ie, the HOME issue) [14:08] seb128: '3' is what you need. that seems to me to be a snappy team and/or desktop team thing (ie, it has nothing to do with the sandbox and I have no insight as to the proper fix) [14:08] maybe it is a snapcraft thing [14:08] jdstrand, I can figure 3 out but we also need access to the system XDG_RUNTIME_DIR [14:08] * jdstrand isn't sure [14:09] jdstrand, which is where I'm blocking [14:09] I don't even know if it's ok from a security point of view [14:09] are you saying the sandbox is blocking access to the XDG_RUNTIME_DIR? is there a bug for the system XDG_RUNTIME_DIR? [14:09] what is that dir? [14:11] jdstrand, XDG_RUNTIME_DIR=/run/user/1000 [14:11] jdstrand, I get a permission denied when I try to access /run in a confined snap [14:11] seb128: what is the apparmor denial? [14:11] l[30316.913854] audit: type=1400 audit(1466518291.070:296): apparmor="DENIED" operation="open" profile="snap.gnome-logs-udt.gnome-logs-udt" name="/run/user/1000/" pid=9158 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [14:12] well, that is for 'ls' [14:12] but what is the denial when you use gsettings? [14:13] becuase we allow access to /{,var/}run/user/*/dconf/user already in the gsettings plug [14:13] jdstrand: hey! Small question/remark/needs your brain. We are thinking about introducing best practices for shaping snapcraft.yaml for our developers via some rules set (order of stenzas, and so on). This tool would be a linter which may be extended as an helper for IDE for autocomplete as well. [14:14] so it means it needs to be fast to execute (as autocomplete on temporary file in the IDEs) and work on snapcraft.yaml source [14:14] jdstrand, ok, I think I just got confused and assumed that if I couldn't ls to it it was not available, I see no deny [14:14] jdstrand, I'm going to try to figure out 3) then, sorry for the nois [14:14] jdstrand, and thanks for the replies! [14:14] seb128: np [14:14] I was first thinking about about the click-reviewer-tools (that we will integrate on package built from the ide ofc), but I'm a little bit more vary on using/extending it for snapcraft.yaml + introducing our best practice rule then [14:15] having some experience on linter written in python integrated in IDE and their speed… wdyt? [14:16] didrocks: I think the tools could be extended to read a specific snapcraft.yaml on the fs and run fast enough [14:16] jdstrand: so you would probably be in favor of us going that road instead of trying to get something in go? [14:17] didrocks: the thing that can be slow now is unpacking the snap, going through all the files, etc. just parsing snapcraft.yaml would be fast [14:17] didrocks: yes-- otherwise the test will diverge and maintenance would be a problem [14:17] tests* [14:17] jdstrand: yeah, but it means for every character typed in the IDE, the python interpretor would be executed by the IDE plugin [14:17] (for autocomplete for instance) [14:17] it is already hard enough keeping snapcraft and the tools in sync. adding another thing would be hard [14:18] yeah, that's why I prefer talking about it to you beforehand :) [14:18] didrocks: hmmm, for every character? that sounds slow now matter how you do it. I mean, if you could keep the interpreter running, then it would be fast, but invoking the interpreter over and over will likely be too slow [14:19] jdstrand: I'm afraid that out extending most of IDEs are working though [14:19] that's* how [14:19] but in theory, you have nothing against us extending the click-reviewer-tool for those functionality? (parsing snapcraft.yaml + introducing autocomplete) [14:20] functionalities* [14:20] I do not-- it has a ton of lint tests already [14:21] jdstrand: great! the LP project is still the main branch, right ? (nothing on github?) [14:21] how to integrate would be the interesting bit [14:21] all LP [14:22] yeah, I'll have a look on some ides and how this works, but from a quick look, it's similar to what you do with the tool already: returning some json (where you have the line number…) [14:22] you'd need to extend that part. we don't track line number-- we track by key/value [14:23] yeah, but I think it's another binary anyway [14:23] (not that line number would be difficult to add) [14:23] as it's not meta.yaml [14:23] by another file, with other rules (some are commons) [14:23] you might want to create a 4th category-- 'bestproactice' or something. error, warn and info are likely not enough for what you need (something between info and warn) [14:24] indeed [14:24] I'll have a look in the next days and keep you posted! [14:24] thanks for your feedback :) [14:24] np [14:37] zyga: maybe I have found the download issue [14:40] matteo: yes? what is it? [14:41] the connection is resetted when the network is faster than the disk [14:48] I'm trying to run a snappy app as a service account but get the following message: failed to create user data directory. errmsg: Permission denied. Anybody have a workaround? [14:55] re [14:55] swartzr: re [14:56] swartzr: so can you tell me more about your issue [14:57] zyga: installed a snap that I built on one of our servers although the service account that will run it (jenkins) throws that error message when it tries to run it. [14:58] I looked in jenkin's home directory and i see a snap directory so I assume it is created successfully === ratliff_ is now known as ratliff [15:03] abeato: i take it you tested that the udev rules were definitely be created for modem-manager? [15:03] joc_, yep [15:06] swartzr: can you tell me what the error is in more detail [15:06] swartzr: what is the host? (where does snapd run) [15:08] abeato: do you have an amd64 snap i can install? looks like your recent builds failed [15:09] hmm, weird [15:10] zyga: The host is an ubuntu server 16.04 x86_64 when i run the snap via /snap/bin/ftptransfer I get the message: "failed to create user data directory. errmsg: Permission denied" nothing more [15:11] zyga: the snap is also installed in devmode [15:11] joc_, http://people.canonical.com/~abeato/snappy/modem-manager_1.4.0-1_amd64.snap [15:13] swartzr, do you have an encrypted home directory? [15:15] abeato: boo, yours works here too :p [15:15] joc_, lol [15:15] kyrofa: no although it is in a different spot than normal /var/lib/jenkins [15:16] swartzr, interesting. Any chance $HOME/snap is owned by root? [15:16] zyga: Actually I forgot to look at syslog. I have a apparmor deny does this help? http://paste.ubuntu.com/17646112/ [15:17] kyrofa: no it is owned by the user jenkins [15:17] swartzr, yep, that'll do it [15:17] kyrofa should it be owned by root? [15:17] swartzr, it's the denial. The profile under which u-c-l runs won't let it create $HOME/snap if $HOME is in /var [15:17] At least, that's what it looks like [15:18] jdstrand, can you take a look at that? ^^ [15:18] which that? [15:18] the /var/ denial is likely from zyga's recent changes [15:18] and so it would need to be allowed [15:18] jdstrand, $HOME is /var/lib/jenkins, getting http://paste.ubuntu.com/17646112/ and permission denied when creating user data directory [15:18] Ah [15:19] swartzr, ^^ [15:19] hmm [15:19] hmm [15:19] * jdstrand is assuming the flipped mounts work is causing that ^ [15:20] swartzr: home has to be in /home/$foo, or apparmor will have a few issues [15:20] jdstrand: which changes are you referring to? [15:20] zyga: ok I might have to change the way I'm deploying this then [15:20] jdstrand: ubuntu still ships the old ubuntu-core-launcher [15:20] swartzr: quick idea [15:20] swartzr: vm /var/lib/jenkins /home/jenkins [15:21] er [15:21] mv [15:21] then ln -s it back [15:21] and try [15:21] so the real home is /home/jenkins [15:21] and /varlib/jenkins is a symlink to /home/jenkins [15:22] zyga: if this is in the old code, then the profile is lacking the rules to create HOME dir for daemons. That said, I thought something else was creating that directory in /var/lib [15:25] jdstrand: my memory is hazy [15:25] jdstrand: AFAIR the per-user thing is created by the launcher [15:25] jdstrand: and the /var/snap/$SNAP_NAME thing is created on install by snapd [15:27] zyga let me look at that. I have to make sure that it won't mess anything else up first. [15:27] zyga: Thank you [15:30] zyga: if /var/snap/$SNAP_NAME is created on install, then the launcher arguably shouldn't be creating dirs in there even if HOME is set to /var/snap/... [15:32] jdstrand: I think the launcher was doing the $HOME-derived (SNAP_USER_DATA) one [15:33] zyga: but they said that home was /var/lib/jenkins. I think I' confused now [15:33] how was HOME set to /var/lib/jenkins? [15:33] that isn't right in any scheme [15:33] jdstrand: I suspect jenkins package does that [15:33] jdstrand: it's not a snap, jenkins is just a regular package [15:34] I'm really confused now. why is the launcher getting denials for launching something that isn't a snap? [15:34] jdstrand: jenkins runs a snap [15:34] jdstrand: and the snap has a non-default HOME [15:34] jdstrand: and that falls out of the policy [15:34] jdstrand: that's how I understand it [15:34] how does the snap have a non-default HOME? [15:35] * zyga wonders if "falls out of sth" means anything [15:35] how is that even possible? [15:35] jdstrand: I mean the user running the snap doesn't have a normal home [15:35] jdstrand: that particular user happens to be jenkins [15:35] jdstrand: cat /etc/passwd and look for home directories [15:35] I see what you're saying now [15:36] this seems like a failing of the jenkins job that runs the snap [15:36] it should set HOME to something else [15:37] jdstrand: like? [15:39] hmm, how can i tell snap find to show me snaps from beta [15:40] seems it doesnt accept a --channel arch [15:40]