[00:55] <kyrofa> elopio, alright thanks :)
[03:46] <liuxg> how is "organize" in snapcraft.yaml is used? thanks
[08:14] <liuxg> dholbach, ping
[08:15] <dholbach> liuxg: pong
[08:16] <liuxg> dholbach, do you know what the following sentence means in the snapcraft.yaml?  http://paste.ubuntu.com/13886619/ the organize part
[08:18] <dholbach> liuxg: no, I'm afraid not - best to ask sergiusens or kyrofa when they are back online
[08:19] <liuxg> dholbach, ok. I will do that. the explanation in the document is very weak. https://docs.google.com/document/d/1Rj9nVBttx62BvGlbnkmKOzAlAIEWuLNr1QaSGe3gQDA/edit#heading=h.bx30erj03sx1
[08:19] <dholbach> ah ok, look at this:
[08:19] <dholbach>    * `organize` (yaml subsection)
[08:19] <dholbach>      A dictionary exposing replacements, the key is the internal name whilst
[08:19] <dholbach>      the value the exposed name, filesets will refer to the exposed named
[08:19] <dholbach>      applied after organization is applied.
[08:19] <dholbach> ah, yes - that's the same
[08:19] <liuxg> dholbach, what does it exactly mean in the context?
[08:19] <dholbach> I don't know - I didn't write it
[08:19] <dholbach> I would need to read the code to understand
[08:20] <dholbach> are files renamed with the patterns mentioned there?
[08:20] <liuxg> dholbach, I am going to have a snapcraft training for some of the people in one week. I am trying to understand more about it.
[08:21] <dholbach> I see
[08:21] <liuxg> dholbach, it sounds like that the files inside opt/bin will be put into the bin directory?
[08:22] <dholbach> I don't know
[08:22] <dholbach> have you tried it?
[08:22] <liuxg> dholbach, I have tried the code snippet there, and it does not work at all. http://paste.ubuntu.com/13886619/, it seems there is some error for it.
[08:23] <dholbach> if it errors out, that's a bug :/
[08:23] <dholbach> or the example needs to be updated
[08:23] <liuxg> dholbach, the line does not work at all    - *.h
[08:24] <dholbach> can you file a bug about it?
[08:24] <liuxg> dholbach, i will, the "type" null means a null plugin, right?
[08:24] <dholbach> yes
[08:24] <liuxg> dholbach, there are a few bugs with the code there.
[08:24] <dholbach> yes, it needs to be updated
[08:25] <liuxg> dholbach, so, it is against snapcraft?
[08:25] <dholbach> maybe the example needs to be updated and then it works?
[08:25] <dholbach> there were some changes in the early versions of snapcraft, like type → plugin
[08:26] <liuxg> dholbach, that seems the only document we can refer to. we need a complete tutorial on snapcraft. will anyone push for that?
[08:26] <dholbach> liuxg: the document needs to be updated if the example doesn't work
[08:27] <dholbach> ricmm: ^
[08:27] <dholbach> in general I think it does a good job though
[08:29] <liuxg> dholbach, this is the project https://github.com/liu-xiao-guo/null
[08:30] <liuxg> dholbach, would you please have a try in your place?
[08:30] <dholbach> I can't
[08:30] <dholbach> I have to go to the dentist now
[08:30] <liuxg> dholbach, ok. if you are free, you can do it at your convenience later on.
[08:30] <dholbach> but there are a lot of other folks in here, maybe somebody else can help
[10:03] <JamesTait> Good morning all; happy Thursday, and happy Nobel Prize Day! 😃
[10:45] <liuxg> zyga, ping
[10:59] <zyga> liuxg: hey
[11:00] <liuxg> zyga, last time, you told me to try the requirements.txt, I have tried it, and there is a problem for it. I have reported a bug for it at https://bugs.launchpad.net/snapcraft/+bug/1523384
[11:01] <zyga> liuxg: thanks for reporting the bug
[11:02] <liuxg> zyga, it is ok. by the way, today, I tried another project at https://github.com/liu-xiao-guo/null, I also failed. I did it according to the document "Snappy Ubuntu Core - Application Developer Manual 15.04". I do not where I was wrong for it.
[11:04] <liuxg> zyga, I also reported a but for it at https://bugs.launchpad.net/snapcraft/+bug/1524663.
[12:48] <dholbach> liuxg: I sent a pull request for your example -it should work now
[12:48] <dholbach> but still I feel it's a valid bug because the error messages of snapcraft didn't actually reveal any of the issues
[12:48] <dholbach> maybe you could change the bug description to that
[12:48] <liuxg> dholbach, do you mean the null example?
[12:48] <dholbach> yes
[12:48] <dholbach> https://github.com/liu-xiao-guo/null/pull/1
[12:49] <liuxg> dholbach,  did you do any change?
[12:49] <dholbach> see the pull request
[12:49] <dholbach> there were a number of issues with the example (I updated the doc already)
[12:50] <liuxg> dholbach, OK. many thanks, I think document should be updated :). yes, we need to make the example working. the document is accessed by many people.
[12:50] <dholbach> liuxg: I already updated the doc
[12:51] <liuxg> dholbach, that is cool! by the way, have you figured out "organize" ?
[12:51] <dholbach> yes, it's basically a rename
[12:52] <dholbach> just check the contents of the snap in your example and the files in the parts/ directories
[12:52] <liuxg> dholbach, do you mean rename the "opt/bin" to "bin"?
[12:52] <dholbach> yep
[12:53] <dholbach> or in the working example   usr/bin  →  bin/
[12:54] <liuxg> dholbach, in my example, it is  opt/bin: bin, so, we change it to "usr/bin to  "bin"?
[12:55] <dholbach> https://github.com/liu-xiao-guo/null/pull/1/files
[12:55] <dholbach> check the diff
[12:55] <dholbach> that's what makes the example actually work
[12:56] <liuxg> dholbach, yes, I see it. thanks a lot.
[12:56] <dholbach> ok, cool :)
[13:00] <liuxg> dholbach, you are marvelous!
[13:00] <dholbach> thanks a lot - this was a useful exercise for me as well :-)
[13:03] <liuxg> dholbach, so all of the files in the /usr/bin are gone. the final snap is like http://paste.ubuntu.com/13893283/. the gnupg files are not there.
[13:03] <dholbach> hum, that's weird - try:   snapcraft all --force
[13:04] <dholbach> for me it looks like this: http://paste.ubuntu.com/13893318/
[13:05] <liuxg> dholbach, I have merged your changes already, now the project is like https://github.com/liu-xiao-guo/null/blob/master/snapcraft.yaml. I pulled everything there
[13:07] <dholbach> I'm using xenial, but I'm not sure if that makes a difference
[13:08] <liuxg> dholbach, I just used your command "  snapcraft all --force", it seems to be right. I am now doing it again with a normal "snapcraft"
[13:09] <dholbach> ok
[13:09] <dholbach> "all --force" will go through all phases of snapcraft again and through away old results
[13:09] <dholbach> that's useful if previous runs downloaded something else or moved files around or whatever
[13:09] <dholbach> Sergio said that in version 2.0 snapcraft is going to be cleverer
[13:10] <dholbach> but until then we will have to bear that trick in mind
[13:12] <kyrofa> dholbach, an even more handy trick is to alter your part's `state` file and set its contents to "pull," then run snapcraft again
[13:12] <kyrofa> That way it will rebuild the part without repulling .debs etc.
[13:13] <kyrofa> I find that to be the longest part, depending on the project of course
[13:15] <liuxg> dholbach, If I simply use "snapcraft", the result is the same as what I showed you. However, if i use "--force" option is the like yours. I am still confused. Do I need to use "--force" option all the time?
[13:16] <dholbach> no
[13:16] <dholbach> you shouldn't have to
[13:16] <dholbach> I need to run again... see you later
[13:17] <liuxg> dholbach, ok. thanks. I will let you know the result. it is a little strange to me anyway
[13:17] <kyrofa> liuxg, the snapcraft behavior is very unintuitive right now regarding how the steps are run after they've already been run once. --force is backwards, and it's all very confusing
[13:17] <dholbach> kyrofa can probably help
[13:18] <kyrofa> liuxg, we're working on changing that right now :)
[13:18] <kyrofa> liuxg, so rest assured, we feel your pain
[13:19] <liuxg> kyrofa, thanks for your explanation. so in the future, we will just use snapcraft, right?
[13:19] <elopio> kyrofa: today I need to take my motorcycle to the mechanic. I might be late for the stand up, because buses are unpredictable.
[13:20] <elopio> I'll ping you when I'm back.
[13:20] <kyrofa> elopio, no problem, thanks for the heads up :)
[13:21] <kyrofa> liuxg, first of all, before I try to explain anything you're gonna have to take what I say with a grain of salt-- I only started on snapcraft recently :)
[13:21] <liuxg> kyrofa, alright, thanks
[13:22] <kyrofa> However, my understanding is that the snapcraft steps (pull, build, stage, snap, assemble) will remain the same
[13:23] <kyrofa> liuxg, I believe running `snapcraft` will continue to run through all steps, but it won't re-run any steps it has already run unless you force it
[13:24] <kyrofa> liuxg, similarly, say I run `snapcraft` once and it makes a .snap. If I run `snapcraft pull` again, it won't re-pull because it knows it's already done that. So I'd have to run `snapcraft pull --force`
[13:24] <kyrofa> sergiusens will know all the details here, so hopefully I'm not leading you astray with where things are going
[13:24] <liuxg> kyrofa, I got you. If I run a "snapcraft clean" first, after that, I run "snapcraft", will it run through all of the steps?
[13:26] <kyrofa> liuxg, that sounds about right
[13:27] <liuxg> kyrofa, in my places, it a little bit not so right. I have my test project at https://github.com/liu-xiao-guo/null. it seems to give me different results when i run it.
[13:29] <kyrofa> liuxg, you mean `snapcraft clean` followed by `snapcraft`?
[13:29] <liuxg> kyrofa, yes, that is what I did here. I did not see all of the directories before I did another "snapcraft"
[13:30] <kyrofa> liuxg, give me a minute, let me pull the project
[13:33] <kyrofa> liuxg, I get this after a `snapcraft` run. Same as you? http://pastebin.ubuntu.com/13894019/
[13:33] <liuxg> kyrofa, what is the content inside the snap?
[13:34] <kyrofa> liuxg, bin/{wget,gpg-zip,gpgsplit,gpg}
[13:35] <liuxg> kyrofa, in my case, http://paste.ubuntu.com/13893962/
[13:36] <kyrofa> liuxg, alright let me try a clean and another snapcraft
[13:36] <liuxg> kyrofa, this is another try with "--force" option http://paste.ubuntu.com/13894098/
[13:37] <kyrofa> liuxg, interesting, you're right-- after I've cleaned and run again, I have the same as you
[13:37] <kyrofa> liuxg, let me look into this
[13:37] <kyrofa> liuxg, hang around, I'll ping you when I learn something
[13:37] <liuxg> kyrofa, it is a very confusing to me. running different command gets different results :)
[13:38] <kyrofa> liuxg, agreed
[13:38] <kyrofa> liuxg, confusing to me too :)
[13:38] <liuxg> kyrofa, sounds like a bug somewhere :) next time, I have to use to methods to try them. Still maybe I do not know which one is right.
[13:43] <liuxg> kyrofa, daniel seems to have a different result than us http://paste.ubuntu.com/13893318/
[13:46] <kyrofa> liuxg, haha, no kidding. I didn't have the lspgpot in there
[13:46] <kyrofa> liuxg, I suspect something is weird in the filtering
[13:47] <liuxg> kyrofa, I do not have it too :)
[13:49] <liuxg> kyrofa, I am using daniel's repository, which is the same as mine. I got different results for the two builds http://paste.ubuntu.com/13894397/
[13:56] <liuxg> kyrofa, I have created a bug report for it at https://bugs.launchpad.net/snapcraft/+bug/1524846. if you have any updates about it, could you please update it there? thanks a lot for your helping!
[13:57] <kyrofa> liuxg, no problem :)
[14:42] <kyrofa> sergiusens, I ran into a terrible problem yesterday
[14:43] <kyrofa> sergiusens, if the `source` option for a plugin is ".", it causes ./parts/foo/src to be symlinked to ., which results in a circular link. Which makes any automatic src parsing useless
[14:46] <kyrofa> elopio, ^^ too
[14:46] <tasdomas> hi
[14:46] <tasdomas> how do I disable the automatic snappy update installation
[15:00] <ogra_> tasdomas, the easiest is probably:
[15:00] <ogra_> snappy config ubuntu-core >core-config.yaml
[15:00] <ogra_> then edit the value of autoupdate from true to false ...
[15:00] <ogra_> and run:
[15:00] <ogra_> sudo snappy config ubuntu-core core-config.yaml
[15:00] <ogra_> that will set the new value
[15:06] <tasdomas> ogra_, thanks
[15:45] <elopio> kyrofa: that happened to me, but when the yaml was not in the root.
[15:45] <elopio> in theory we have a condition check that prevents the parts dir to be copied.
[15:45] <kyrofa> elopio, but it's a symlink, not a copy
[15:46] <kyrofa> elopio, note that I'm talking about the sourcedir, not the builddir
[15:46] <elopio> kyrofa: right, the condition is on build, where we copy.
[15:46] <kyrofa> elopio, and that makes sense
[15:46] <kyrofa> elopio, so perhaps this is only really a problem where we need to interrogate the sourcedir in order to complete the pull()
[15:46] <kyrofa> elopio, e.g. the catkin plugin
[15:47] <kyrofa> elopio, so I'm simply making the source and source-subdir checks a bit stricter for that plugin
[15:47] <kyrofa> elopio, but definitely a dangerous thing to keep in mind, at least
[15:47] <elopio> I couldn't add the condition to pull, because of the symlink. So maybe it would be good to copy in pull too.
[15:47] <kyrofa> elopio, took me forever to figure out why it was taking so darn long to run
[15:47] <rOger___> Hi all
[15:47] <kyrofa> elopio, interesting idea, but a bit heavy depending on the project
[15:47] <elopio> kyrofa: right, same here. Until it failed because it was copying a path too long.
[15:47] <kyrofa> elopio, that may be the best/cleanest solution
[15:47] <elopio> rOger___: Hello!
[15:47] <rOger___> I'm checking ubuntu snappy as a base system for embedded appliances
[15:48] <rOger___> for our requirements we should be able to replace several parts of the boot scripts with a different init "system"
[15:48] <rOger___> is there an official way to accomplish this?
[15:49] <ogra_> why do you need to replace the init system ?
[15:49] <elopio> rOger___: not yet. But the devs are working on splitting the image into snaps. And one of the things they are discussing is where is the bootloader defined, and how to replace it.
[15:50] <rOger___> We want to use our python based init scripts where we have more influence on some parts of the system config (like networking)
[15:50] <ogra_> well, thats not really how snappy works
[15:50] <morphis_> sergiusens, ricmm: does the snappy store group snaps per core image version?
[15:50] <morphis_> or do I publish a snap for everything?
[15:52] <ogra_> you have a very locked down core (readonly etc) ... that does the system boot ... and ten you have snaps ... a snap can ship services and binaries ... so you can have your application in a snap nad have the service started on boot ...
[15:53] <rOger___> @ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
[15:53] <nothal> rOger___: No such command!
[15:54] <rOger___> \ogra_: so if you call a "firewall" an application; It will be called too late in the boot process; the network interfaces will be setup before the application will be started so during a short time I have a router instead of a firewall
[15:55] <ogra_> things like networking are part of the core component though
[15:55] <ogra_> snappy offers an interface to configure it etc but you wouldnt easily be able to replace parts in the core
[15:55] <ogra_> (your snap could also ship its own network handling and tell snappy to turn off its own handling though ... )
[15:58] <ogra_> no, as i said, you can tell snappy to not take over networking
[15:58] <morphis_> ogra_: you know that?
[15:58] <ogra_> morphis_, well, in 16.04 you will be :)
[15:58] <ogra_> not sure Chipaca landed that yet but i know it was discussed :)
[15:59] <ogra_> rOger___, jdstrand recently created a ufw snap ... though that integrates with the existing core
[16:00] <morphis_> ogra_: so what is the current store targetting?
[16:00] <rOger___> ogra_: that sounds interesting; i will check it out
[16:00] <ogra_> morphis_, depends ... you can pick when you upload ... most packages should target stable
[16:01] <ogra_> but you can pick "edge" as well
[16:01] <ogra_> (which would target the rolling release by default)
[16:03] <morphis_> ogra_: ah
[16:03] <morphis_> ogra_: stable is 15.10?
[16:03] <morphis_> ogra_: and that changes with 16.04?
[16:04] <ogra_> not sure how it will chane then .... stable is 15.04
[16:04] <ogra_> *change
[16:04] <morphis_> ok
[16:05] <morphis_> ogra_: so I can publish two versions?
[16:05] <morphis_> on for edge and stable?
[16:05] <ogra_> you should be able to ... havent tried it myself
[16:09] <morphis_> ogra_: thanks!
[16:09] <ogra_> np ... ask beuno for more details :)
[16:25] <kyrofa> elopio, ah! I finally understand this stupid mock library
[16:51] <beuno> mwenning, yes you can
[16:51] <beuno> er
[16:52] <beuno> morphis_, ^
[16:52] <morphis_> beuno: great
[19:45] <sergiusens> tyhicks, is there a security reason for this https://bugs.launchpad.net/snappy/+bug/1523372 ?
[19:50] <sergiusens> kyrofa, hey, do you have a sec?
[19:50] <kyrofa> sergiusens, for you, always
[19:50] <sergiusens> kyrofa, hah, let me give you a hangout link :-)
[19:52] <tyhicks> kyrofa: check the privmsg from me
[23:04] <wililupy> Hello, I'm trying to build a snap of LISPmob, but it requires some system changes to snappy, like a configuration file in /etc and some changes to the /etc/sysctl file. How do I go about this in my snapcraft.yaml file?