[01:32] in my snapcraft project folder, I have a src dir. After I run snapcraft, the contents of this folder gets copied to the src dir of every single part. Is there a way to control this behavior? Organize or something? [01:40] actually, for every single part in project/parts its in the build, src, and install dir [01:43] scratch that, it happens for parts that use my custom plugin as well as the dump plugin === Sir_Gallantmon is now known as Son_Goku === markusfluer1 is now known as markusfluer [02:31] yeah i need to figure that out too [02:35] knight__: are you referring to the question I asked? [02:40] olympionex, yep [02:40] this channel is pretty sleepy... been asking questions the last 3 days with basically no answers :) [02:41] knight__: I believe I made some progress just now. When you create a custom plugin it inherits from snapcraft.BasePlugin which has a member called 'source' [02:41] by default, it seems to copy whatever is in source to the project/parts/src dir [02:41] and by default that source parameter is the project directory itself [02:41] Oh I see, that's for custom plugin. [02:41] I have a src dir in my snapcraft project folder [02:42] well it works the same with dump I believe, testing it out [02:42] Then a subdir, and a script, that i'm trying to use dump to move into destination app command [02:42] if you don't specify the source option for the plugin, it appears to copy the entire project directory to that part's source dir [02:42] my source is defined as "src/" [02:42] i'm still verifying. I suspect what you want to do is create a project/src/script_dir [02:43] and set the source for the dump plugin to src/script_dir [02:43] then use organize to decide exactly where to copy it [02:43] yeah [02:43] i did source: src/ and then organize with item: item_dir/item [02:43] but maybe that's wrong? [02:45] well previously I was using this: [02:45] http://pastebin.com/LxRDzRUz [02:45] i'm currently working on modifying / testing to make a specific directory project/src/netconf that only has the file netconf.py [02:46] so that it doesn't copy everything in the whole project/src directory to src of that part [02:46] yeah that's similar to what i want [02:47] yeah, that appears to work for me [02:47] you just need to create subdirs for each part under src [02:48] and be careful that for any part which you don't specify source, it will probably copy the whole project dir in [02:48] maybe we need to do: [02:48] organize: item_dir: item [02:50] thats not what I'm doing [02:50] the key should be the filename relative to the source dir [02:50] and the value should be the full path where it will end up in a fileset [02:51] Yes, that's what I'm saying [02:51] whether that is stage or prime [02:51] We can add another level to represent the subdir [02:51] i.e. source + subdir + item [02:51] organize: item_dir: item: item.py [02:52] ah, you mean a suggestion to modify the snapcraft source itself? [02:56] the yaml [02:56] organize statement [02:57] all I had to do to fix it was this: [02:57] http://pastebin.com/F2ar752n [02:57] basically just change src to src/netconf [02:57] and move netconf.py from src to src/netconf [02:57] yep [02:58] my suggestion is if you have other files in src/ with other subdirs and don't want to isolate the source to that [02:59] ah, we were just talking past each other. Thats what I meant by modifying the snapcraft source -- would require changing the operation of snapcraft [03:00] ? [03:00] i guess dump copies all [03:01] you can't cherrypick [03:01] yeah, as far as I can tell, the default behavior of possibly all plugins is to copy everything from source [03:01] I haven't looked yet, but it must be in BasePlugin [03:02] there's got to be a way to be able to pull something down from a dir or remote, and cherrypick [03:03] I think it would require something like having filesets for the pull operation === chihchun_afk is now known as chihchun [04:05] need to figure out how to cross-build armhf support [04:21] is there any way to force snapd to skip a task in a changeset? [04:22] I'm trying to bring up a board and it keeps hanging on "Run configure hook of "core" snap if present" [06:24] knight__: I just noticed that you have to do the same for the nil plugin, which is kind of annoying -- otherwise it will copy the whole project directory to the part source [07:54] PR snapd#2834 opened: release: add galliumos support [09:02] good morning [09:06] PR snapd#2835 opened: strutil: support version compare with empty strings [09:14] PR snapd#2836 opened: release: assume higher version of supported distros will still work [09:22] popey: thank you for the bug reports on distro support sir! === rvr_ is now known as rvr [10:11] jdstrand: Hi! So I tried to declare plugs and slots as you described. Ended up with this. https://hastebin.com/rijasoyoxo.pl But when uploading to the store automatic review fails with this now human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration [10:11] jdstrand: did I do something wrong? [10:26] zyga: no worries, thanks for fixing them :) [10:27] popey: mvo did all the work with a fantastic future-proof branch [10:27] \o/ [10:43] zyga: pfff /me sets up linux from scratch to test the wild claims I'll be back in two whole years with reports ;) === chihchun is now known as chihchun_afk [10:46] davmor2: I expect nothing less than utter success :) [10:54] jibel: quick question about #1663666 - do you run zesty as well? the bugreport is originally on a zesty system, I tried various things to reproduce but no luck so far [10:54] Bug #1663666: max-format is not a positive integer assertion installing unity8-session snap [10:57] mvo, yes on zesty too [10:57] jibel: excellent, let me test it there [10:58] mvo, I wondering if it happens after a package or snap upgrade. After a reboot the problem was gone [10:59] jibel: ohhh, that is super useful information [10:59] jibel: let me try with that [11:23] PR snapcraft#1138 closed: python plugin: exclude the RECORD files [11:42] hello all! quick question; is it possible to change the user running the app inside the snap? [11:42] PR snapd#2837 opened: interfaces/apparmor: allow reading from ecryptfs [11:43] joedborg: not at this time [11:43] zyga: thanks, do you know what user the application inside sees? [11:44] i assumed it was the user who initiated it, but doesn't seem to be the case [11:45] even though if i run with --shell and do a `whoami` it does say the same [11:46] joedborg: yes, when it is a normal command it runs as the user who started it [11:46] joedborg: when it is a service/daemon it runs as root [11:46] zyga: aaaah, thanks, that makes sense (i'm running a daemon) [11:48] I just noticed hexchat uses ~/snap/hexchat/17/.config instead of ~/.config [11:48] brunch875: that's correct [11:48] brunch875: for snaps that are not using confinement:classic the HOME environment variable is changed [11:48] brunch875: since most apps correctly derive $XDG_CONFIG_DIR from $HOME you end up with what you said [11:48] aaah, so I shouldn't worry about the application defaults [11:49] brunch875: note that snaps don't normally have access to your home directory [11:49] brunch875: no, that's fine [11:49] ah thank you, didn't really know how to ask the question but you read my mind :) [11:49] I know ;) === jkridner|pd is now known as jkridner [11:59] ogra_, thanks for the answer to my question the other day. In fact, it was mentioned in a different document on developer.ubuntu.com that the first install should take place with a wired connection. [12:00] yeah, i hope we nail that bug some day [12:01] ogra_, some day? It can't be that huge, can it ? By the way, is it worth filing a change request on "https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3"? [12:01] does that point to wlan stuff ? [12:01] It can be frustrating for first time users when they are following that guide and somehow stumble on that configuration step. [12:02] It's step #3, i guess we could add a note saying that first setup should be wired ? [12:04] I found a similar note on this https://developer.ubuntu.com/en/snappy/start/installation-tips/ but no reference to the first user-guide [12:04] PR snapd#2838 opened: allow core_support interface to modify /etc/hostname using hostnamectl [12:05] davidcalle, ^^^ should we have a known issues castegory on these pages ? [12:11] hi all [12:11] ogra_, is there a dedicated launchpad group that is working to polish things out with snappy ? [12:11] I've been comparing performance of commands provided as snaps vs debs [12:12] deanman, depends ... there is a github team for the snapd related bits and there is snappy-dev on launchpad for the image builds [12:12] even a classic confinement snap appears to have some overhead that I don't see with a deb - would the use of squashfs have some impact here or am i looking at something else? [12:12] 1.6 s vs 0.5 seconds for example - thats just to run neutron --version [12:12] so no network ops in the way [12:13] joedborg: can you say what you are measuring exactly? [12:13] er [12:13] jamespage: ^^ [12:13] zyga, my tests are [12:13] joedborg: I'm sorry, irssi confusion [12:13] time /snap/bin/neutron --version [12:13] zyga: no worries :) [12:13] vs [12:13] jamespage, i doubt it is the filesystems fault but rather the way of executing [12:13] time /usr/bin/neutron --version [12:14] there is surely some extra overhead in that bit [12:14] jamespage: snap adds three execs along the way: snap-run -> snap-confine -> snap-exec [12:14] jamespage: two go and one C executables [12:14] jamespage: there's bound to be some overhead but typically it is hard to even measure [12:14] jamespage: I'd be interested to know more [12:15] zyga, me to [12:15] jamespage: can you run a /bin/true test? [12:15] install a snap that just runs /bin/true) [12:15] jamespage: e.g. snapd-hacker-toolbelt [12:15] jamespage: it ships snapd-hacker-toolbelt.busybox [12:15] jamespage: then you can just say snapd-hacker-toolbelt.busybox true [12:15] jamespage: and see how "fast" that is [12:16] and have a local busybox to compare ? [12:16] jamespage: that should be a good ballkpart number for the overhead itself [12:16] ogra_: well, true just takes 0.00 seconds I bet :) [12:16] dont we have a bash in the hacker toolbelt for direct comparison ? [12:16] jamespage: do a 100 runs and see what you get [12:16] ogra_: I think there's bash as well [12:17] ogra_: because snapcraft :/ [12:17] * ogra_ wouldnt trust busyboax and bash "true" to be the same [12:17] ogra_, is this for the image builds ? https://launchpad.net/~snappy-dev [12:17] ogra_: but that does run busybox "true" applet [12:17] deanman, thats the team managing the builds ... [12:17] ogra_: it's the busybox true [12:17] zyga, looks like about 0.033s vs 0.001s (snap vs /bin/true) [12:17] zyga, right, and to compare with a std true you would have to have the busybox classic deb installed [12:17] jamespage: how many runs did you measure? [12:18] zyga, ~20 on each [12:18] zyga, first hit on snap was a bit more expensive [12:18] ogra_: I'd say that std true is "0.00" in this case [12:18] 0.485s [12:18] jamespage: yes, the first run of snap-confine does way more [12:18] jamespage: can you stick this in a repository [12:18] jamespage: we could benchmark this periodically [12:18] jamespage: and try to come up with a way to lower those numbers [12:19] zyga, I'm pondering whether the fact its python is making a diff there [12:19] jamespage: is the app shipping .pyc files? [12:19] jamespage: maybe that is a factor? [12:20] zyga, that was my thinking [12:20] there are no pyc's in the snap itself [12:20] jamespage: or the pyc files it ships are for different interpreter and python recompiles everything anyway [12:20] jamespage: there you go [12:20] jamespage: my idea: ship python _and_ just pyc files, skip .py [12:20] jamespage: small and faster [12:21] zyga, well we should make that the default for the snapcraft python plugin then [12:21] ogra_, on that team's page there are no bugs for the wlan. Are they reporting them elsewhere? github ? [12:21] deanman, in launchpad, but it is a kernel bug ... [12:21] jamespage: would be nice to have this as an option [12:21] jamespage: anyway, just an idea [12:22] deanman, https://bugs.launchpad.net/ubuntu/+source/linux-raspi2 [12:24] ogra_, thanks [12:25] sergiusens, ^^ any thoughts on the conversation above re perf of python apps in snaps? [12:25] deanman: indeed, for the record, the source of the raspi setup page is here https://github.com/ubuntudesign/developer.ubuntu.com/blob/master/templates/pages/core/get-started/raspberry-pi-2-3.md, if you want to file a bug/make a PR [12:27] davidcalle, got it, thanks! [12:38] davidcalle, PR filled, added small description with that as well. Feel free to rephrase as English is not my native tongue. [12:39] deanman: thanks a lot, I'll have a look! [12:39] jamespage: .pyc? You should be able to force add them through filesets. We don't by default because many people complained about conflicts when using N python parts as all the pyc files (coming from the same py) would be different [12:44] sergiusens, what happens if they are not shipped? does the python in the snap compile them with every invocation? [12:46] jamespage: yes [12:46] jamespage: and discards them [12:47] sergiusens: you could set a variable for python to store .pyc files in $SNAP_DATA/$SNAP_USER_DATA [12:47] (or just .cache) [12:47] sergiusens: could be a nice compromise [12:48] zyga, sergiusens: I wsa digging to see if that was possible [12:51] jamespage: I bet it is [12:51] it's just software :) === plars-away is now known as plars === perrito667 is now known as perrito666 [14:45] zyga: given classic we are removing env vars as a default in our plugins, but people are welcome to do so if they want === JanC_ is now known as JanC [15:21] PR snapd#2828 closed: tests: increase service retries === Mirv_ is now known as Mirv [15:32] PR snapd#2831 closed: interfaces: add missing recvfrom syscall to dbus interface === balloons26 is now known as balloons [16:07] sergiusens: hey! do you know if the parts importer will check as well for snap/snapcraft.yaml? [16:08] * didrocks creates a new parts and would like to know [16:08] (for cloud parts) [16:10] PR snapd#2839 opened: debian/tests: map snapd deb pockets to core snap channels for autopkgtest [16:13] jdstrand: there was a bug to let me write in /dev/shm/envoy_shared_memory_0, right? I find similar things, but I'm not sure which one that was. [16:14] elopio: I'm strugging to parse that question, but you can write to: [16:15] /{dev,run}/shm/snap.@{SNAP_NAME}.** [16:15] /{dev,run}/shm/sem.snap.@{SNAP_NAME}.* [16:15] /{dev,run}/user/[0-9]*/snap.@{SNAP_NAME}/** [16:15] elopio: so if you follow any of those naming schemes, it is allowed [16:15] /dev/user ?? [16:16] ogra_: yeah, that is wrong [16:16] * jdstrand will fix [16:16] :) [16:16] jdstrand: so, I need to patch upstream? We are never going to let a snap write to /dev/shm/envoy_shared_memory_0 ? [16:16] I shouldn't have pasted that anyway cause it wasn't in shm, but glad I did :) [16:16] on linux everything is a file ... even the user ;) [16:18] didrocks: about that, josepht would know for sure [16:18] but iirc, it uses the general mechanics we have for part loading [16:18] elopio: I don't know what /dev/shm/envoy_shared_memory_0 is, but it is not snap-specific so we won't add a rule to the default template or a plugs side interface for that. if this is for a particular slot implementation, we could. you probably want to look at https://github.com/sergiusens/snapcraft-preload if you want to avoid patching [16:20] jdstrand: I thought I read a discussion about this, but it's all too fuzzy. I think we can suggest them to patch their shm path when in a snap, doesn't sound too bad. [16:21] I'll play with preload too. Thanks for the pointer. [16:21] elopio: if you are looking for the bug, it is: https://bugs.launchpad.net/snapcraft/+bug/1577514 [16:21] Bug #1577514: Support preloading to make snaps feel at home [16:21] elopio: sergiusens wrote https://github.com/sergiusens/snapcraft-preload to help with that [16:22] well, I ripped off from deb2snap as suggested by mterry and not quite finished [16:23] josepht: do you know if the part importer handles the snap/ subdirectory? [16:23] thanks. I think this is enough info to restart the conversation with them. This is a project from lyft :) [16:24] didrocks: I don't think so. Let me check to be certain though. [16:25] didrocks: no, it does not yet support snap/snapcraft.yaml. Do you mind filing a bug and I'll get that added. [16:25] josepht: is there any way to workaround, like pointing to a subdir? [16:25] (meanwhile?) [16:28] didrocks: sorry not that I know of. can you add a symlink to snap/snapcraft.yaml? [16:28] Bug #1663175 opened: chroot not allowed in strict [16:35] josepht: yeah, good idea [16:39] is it fine to install something with apt-get when there's already its snap installed? [16:39] I have some strange freeze with hexchat and I want to see if it also occurs out of confinement [16:40] regarding the binray thats totally fine ... note that /snap/bin is last in your PATH though ... the deb version will be prefererred [16:41] regarding the app configuration it totally depends on the snap though [16:41] (and cache... data etc) [16:41] joc, jdstrand: Provided a comment on snapd#2626.. can we please try to review/finalize it so we get this one through? [16:41] PR snapd#2626: interfaces: relax path requirements for serial [16:42] * brunch875_ is back from crashing [16:50] niemeyer: ack (responded) [16:57] PR snapd#2840 opened: unity7: support missing signals and methods for status icons [16:58] Bug #1664297 opened: Snapped indicators using custom themes or actions doesn't properly work [16:59] jdstrand: ^ about that.... I was also wondering that maybe we should instead move all the xdg-desktops related features to a different policy, and inheriting that in unity7, isn't it? [17:00] jdstrand: I see some kde apps only depending on that while it wouldn't be needed, as they only care about indicators, appmenu and few others [17:00] notifications, of course... [17:01] Trevinho: well, unity7 is meant to be a transitional interface and I think it is ok for it to have things that kde apps won't use. there are quite a few things in there that are expected to work in a unity7 environment but that an application may choose to not use [17:03] Trevinho: interfaces also don't imply other interfaces, so if it was split out, everyone would have to use 'plugs: [unity7, xdg-desktops]' instead of just 'plugs: [unity7]', which could be fine, but we can't break people now by moving stuff out [17:03] perhaps for series 18 we could do that, but my first point still stands [17:04] Trevinho: you have that bug marked in progress. does that mean you are preparing a PR? [17:04] jdstrand: I mean at code level.... So that unity7 definition reusess xdg-desktop, then if you mention just one it will work. While mentioning both is pointless [17:04] jdstrand: it's linked [17:04] errr... or maybe not yet :-D [17:05] jdstrand: https://github.com/snapcore/snapd/pull/2840 [17:05] PR snapd#2840: unity7: support missing signals and methods for status icons [17:16] jdstrand: Thanks [17:16] jdstrand: Seems okay that AA is stating something else [17:17] jdstrand: We'll never even ask AA to mediate if we don't get a proper path that passes the Go one [17:18] jdstrand: fixed [17:18] joc: Can we please get back to having more controlled paths there, as suggested in the PR? [17:19] zyga: ping [17:20] niemeyer: we can do. ogra's argument about the maintenance burden not strong enough for you? [17:21] joc: Thanks [17:21] niemeyer: that's correct. the aa rule is only there as an additional protection for the cgroup anyway. both need to agree of course, but the go one is the really important one for udev tagging and the cgroup [17:22] joc: I've just spent the past 6 hours reviewing snapd PRs.. I'm all for avoiding the burden of maintenance :) [17:22] hehe [17:23] joc: But giving away unknown devices with names we didn't bother to consider sounds like a poor plan [17:23] joc: *tty* happens to match things such as PEOPLES CONSOLES [17:27] Pharaoh_Atem: hi [17:28] zyga: did you see the bug filed about the lack of snapd builds in Fedora? [17:28] Pharaoh_Atem: I replied to it [17:28] PR snapd#2838 closed: allow core_support interface to modify /etc/hostname using hostnamectl [17:29] zyga: so have you made any progress on rebasing snapd and snap-confine patches? [17:29] Pharaoh_Atem: no, I'm still stick and I was really not doing much this weekend :/ [17:29] Pharaoh_Atem: (or weekdays for that matter) [17:29] okay [17:39] PR snapcraft#1139 opened: plainbox-provider plugin: filter out sitecustomize [18:01] PR snapd#2737 closed: tests: add more debug if ubuntu-core-upgrade fails [18:05] elopio: have you seen any collisions between file etc/python3.5/sitecustomize.py in python parts? [18:15] elopio: it seems these changes to support classic are breaking things for parts that pull in python but don't use the python plugin [18:58] jdstrand: ping re snapd#2714 [18:58] PR snapd#2714: interfaces: interface to allow autopilot introspection [19:15] jdstrand: Sent some comments there [19:22] anyone available to help us figure out permission errors on the kubelet snap? zyga? [19:28] niemeyer: re autopilot> ack [19:49] snap install ohmygiraffe # finally a game i master .. oh wait, those lions === testing is now known as Guest95827 [19:55] anyone have documentation on how to cross-build to armhf in snapcraft? [19:57] knight___, snapcraft doesn't really support cross-building [19:58] knight___, your best bet is probably to either build on-device or use the Launchpad snap builders [19:58] well how are people building snaps for other platforms then? [19:58] ha build on-device? yikes. [19:58] knight___, personally, the LP snap builders [19:58] knight___: you can actyually using docker and qemu [19:58] sborovkov, that's what i heard. any docs on that? [19:58] Yeah, qemu is an option as well, but it's brutally slow [19:58] Can't be any slower than building on device. [19:59] Fair enough [19:59] knight___, I can't recommend the LP builders enough. They can even auto-upload to the store when the build has completed [19:59] knight___: let me search. I am sure it was in mailing list [19:59] Ok, open to using launchpad snap builders. Docs on that too? [20:00] knight___, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way [20:00] knight___: https://github.com/chihchun/snapcraft-docker [20:00] knight___, note that since that article was written LP added support for auto-syncing git repos from elsewhere [20:01] Would be really cool if we had a snapcraft flag to kick off a cross-build ... like snapcraft cleanbuild --platform armhf and then it kicks it off, either on launchpad or in the snapcraft backend or in a qemu locally. [20:01] knight___, so you can set things up such that new snaps are built when you push to X branch on github, for example (what I do personally) [20:01] ahh yeah that's a good idea [20:01] thanks @sborovkov [20:04] Are there any snapd bindings for other languages? (for instance if I wanted to run "snap download" "snap find" programatically, or do I have to wrap the cli manually?)? [20:04] lutostag: yes [20:04] lutostag: we have gio/glib bindings so you should be able to use this from any language that supports this [20:05] lutostag: the package is (I believe) snapd-glib or something like it [20:05] lutostag: let me know if you need something [20:05] zyga: neato, couldnt find them on https://github.com/snapcore, any link to to a sweet blog-post? [20:05] lutostag: ah, I should make one :) [20:05] lutostag: and we should move the project, it is on https://code.launchpad.net/snapd-glib [20:07] I wonder where the qt/c++ bindings are? [20:07] thanks kyrofa, i'm reading up and registering on Launchpad now [20:07] those and the snapd-glib project need to move out of LP [20:07] zyga: much thanks! [20:08] Pharaoh_Atem: not sure, I wonder if the KDE folks wrote some for the app store [20:08] they didn't [20:08] Pharaoh_Atem: btw; I'm still sick so instead of coding I write text instead [20:08] Pharaoh_Atem: have a look at new.zygoon.pl [20:08] supposedly the guy who wrote snapd-glib also wrote qt/c++ bindings too [20:08] Pharaoh_Atem: I'll add comments over time [20:08] Pharaoh_Atem: ah, I don't know anything about that [20:13] zyga: afaik, my understanding about debian and file caps is that there's no way to express them in dsc packaging [20:13] dpkg-deb just winds up stripping them :/ [20:13] Pharaoh_Atem: does .dsc care? I though that this is a tarball / weird FS someone may want to use issue [20:14] Pharaoh_Atem: in any case, whatever it is.... [20:14] just annoying [20:14] I use "dsc packaging" as shorthand for debian source control [20:14] divergence [20:14] ahh [20:14] hey kyrofa, that's pretty slick. i'm all set up and building through it now ! [20:14] right [20:14] aka, the way debian packages are made officially [20:29] zyga: nice post :) [20:32] In snapd's help for snap install (for the revision arg) it states: "to which you must have developer access", what precisely does that mean? [20:33] lutostag: it must be run as root [20:33] lutostag: I believe that as a developer of a snap you can install any revision from the store [20:33] Pharaoh_Atem: no, not that :) [20:33] no? [20:33] I thought it was referring to superuser access, since nothing in snapd works without it [20:33] lutostag: but as a consumer you can just install the revision that is published in a channel [20:33] lutostag: the exception is that if you have it installed already you can switch between revisions with refresh [20:33] zyga: and this will disable auto-updating with the regular 4x a day refreshes? [20:34] lutostag: but just among the set you already have on your disk [20:34] lutostag: honestly, I don't know :) [20:34] ehhe [20:34] lutostag: chipaca is the person to ask [20:34] lutostag: I work on other areas and this particular detail is a bit obscure [20:34] motivation... juju snap testing and switching between lots of versions when we want [20:34] lutostag: but the general idea is that as a devleoper you see all the revisions but users just see what you publish [20:35] sigh, where can i download ubuntu core images again? [20:35] mwhudson: snap download [20:35] zyga: that downloads a snap surely [20:36] i want something to give to kvm [20:36]