[00:03] <tedg> sergiusens: So feeling a bit weird, I have to put the getting source options in setup_stage_packages() now
[00:03] <tedg> sergiusens: Because I need the source to know which packages we need.
[00:03] <tedg> sergiusens: It seems to be working, but seems kinda broken.
[00:06] <sergiusens> tedg, ok, but what are you talking about, I am missing some context
[00:07] <tedg> sergiusens: Porting catkin to snapcraft 0.3
[00:07] <tedg> sergiusens: So I need to get the source if it's on git or something to get the packages.xml
[00:10] <sergiusens> tedg, right, but this problem was alway there, right?
[00:10] <sergiusens> too many right don't make a wrong ?
[00:10] <sergiusens> rights
[00:10] <sergiusens> tedg, http://bazaar.launchpad.net/~ted/snapcraft/ros-catkin-plugin/view/head:/snapcraft/plugins/catkin.py#L121
[00:10] <tedg> sergiusens: Hmm, it worked before....
[00:11] <tedg> sergiusens: And I just changed my pull to override setup_stage_packages()
[00:11] <sergiusens> tedg, in your MP you inverted the setup_stage_packages and pull calls
[00:11] <sergiusens> tedg, I think that's why
[00:11] <tedg> sergiusens: What changed is the ordering in pull()
[00:11] <tedg> Oh, I must have unmerged that change.
[00:12] <tedg> So do you like reordering that or overrideing setup_stage_packages() better?
[00:12] <sergiusens> tedg, I'll answer with another question; are we ever going to need something from stage pacckage to satisfy a pull
[00:14] <sergiusens> tedg, ftr https://code.launchpad.net/~ted/snapcraft/ros-catkin-plugin/+merge/273048#diff-line-508
[00:14] <sergiusens> that's the inversion
[00:15] <sergiusens> tedg, I haven't checked if this change would break pip and friends
[00:15] <tedg> I'm curious if we just have bad naming.
[00:15] <tedg> If we shouldn't just call it "pre-stage-packages" and "post-stage-packages"
[00:16] <tedg> It's not that we don't need both, but we need to be clear about how they go.
[00:16] <tedg> Or, perhaps, put setup_stage_packages in the pull() for the super class.
[00:16] <tedg> Then the subclass could move it where it needs it.
[00:19] <sergiusens> tedg, I was wanting to implement pull in the base class today but I am waiting for your plugins to not cause one more update you need to do ;-)
[00:21] <tedg> Ha
[00:21] <tedg> This has touched more files than I expected
[00:22] <tedg> Everything is at least building now.
[08:15] <JamesTait> Good morning all; happy Thursday, and happy Conflict Resolution Day! 😃
[09:13] <biezpal> Hi all! We have a problem with random string in package version and apparmor profiles
[09:13] <biezpal> Apparmor profile:
[09:13] <biezpal> profile "ovs_init-db_0.0.1" {
[09:13] <biezpal> But system is waiting for:
[09:13] <biezpal> ovs_init-db_IDKQMVPQVIGN
[09:13] <biezpal> We cannot specify random version while preparing snap package. How should we handle it?
[09:13] <jjohansen> biezpal: did you have a chance to talk to jdstrand
[09:14] <biezpal> jjohansen, nope :(
[09:14] <biezpal> seems like we have a 12-hours difference in time :)
[09:14] <jjohansen> sadly I am going to give the same recommendation, he is the guy you should talk to
[09:15] <jjohansen> biezpal: yeah, that is a problem, I can ping him about it tomorrow for you but I don't know how much time he will have, so he may not get back right away
[09:16] <biezpal> jjohansen, thanks
[11:45] <Chipaca> Ooops, I did it again.
[11:45] <Chipaca> https://code.launchpad.net/~chipaca/snappy/lock-ness/+merge/274547
[11:45] <Chipaca> 1k lines
[11:45] <Chipaca> how did that happen
[11:47] <davmor2> Chipaca: they let you write the code, that's normally how it happens
[11:48] <Chipaca> and i'm lovin' it
[12:14] <Chipaca> mvo_: ogra2: fwiw, the lock adds 5ms, or 10%, to the quickest rest query on bbb
[12:19] <ogra_> Chipaca, stop taling to that test guy :P
[12:19] <ogra_> *talking
[12:20] <Chipaca> ogra_: why? beuno hardly ever has time for epic dissing contests these days, so i'll take it piecemeal from davmor2
[12:20] <ogra_> haha
[12:24] <davmor2> ogra_: someone has to deflate his head otherwise he can't get through doorways and it's expensive to get building modifications done in the UK
[12:24] <ogra_> oh, and i always thought that was a beard !
[12:28] <jdstrand> biezpal: fyi, your profile name is due to the fact that you are sideloading. there was a change in snappy not too long ago that does that. it changes not only the profile name but install dir, etc, etc
[12:28] <jdstrand> jjohansen: (fyi ^)
[12:29] <Chipaca> oh, missed that
[12:29] <Chipaca> biezpal: jjohansen: holler if you need more help with that
[12:29] <Chipaca> jdstrand: good catch :)
[12:29] <jdstrand> biezpal: if this isn't working right for you, I suggest talking to Chipaca or someone else here
[12:30]  * Chipaca wonders what the problem is
[12:36] <biezpal> jdstrand, we know about random string version for sideloaded apps. The problem is that we cannot specify apparmor profile because of random string version
[12:37] <biezpal> before, we could specify number version in apparmor profile, but now it doesn't work
[12:37] <Chipaca> where/why do you have to specify the version?
[12:37] <biezpal> profile name contain version which is now random
[12:38] <biezpal> apparmor profile config, first line
[12:38] <biezpal> profile "ovs_init-db_0.0.1" {
[12:38] <jdstrand> biezpal: are you using 'security-policy' in your yaml?
[12:39] <biezpal> jdstrand, yes
[12:39] <jdstrand> biezpal: see this: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/framework-template/meta/svc.apparmor.boilerplate
[12:40] <jdstrand> biezpal: basically, have ###VAR### in there, and use ###PROFILEATTACH###, then it all gets filled in for you
[12:41] <biezpal> jdstrand, so, we can use {APP_VERSION} in our profiles, right?
[12:41] <jdstrand> yes
[12:41] <jdstrand> ###VAR### gets expanded to all those vars
[12:42] <mvo_> Chipaca: nice
[12:45] <biezpal> jdstrand, ok, thanks, we'll try it now
[12:57] <biezpal> jdstrand,  seems like I didn't get you right.. How should we define @{APP_VERSION} for our app before installation?
[13:03] <Chipaca> biezpal: so
[13:03] <biezpal> ah, I see now..
[13:03] <jdstrand> biezpal: you don't have to. it gets filled in for you on install
[13:03] <Chipaca> biezpal: do you have click-review?
[13:03] <Chipaca> biezpal: click-review would've told you about ###vars### and ###profileattach###
[13:04] <biezpal> jdstrand, Chipaca yes, I see how it works now, thanks
[13:06] <Chipaca> biezpal: holler if you get stuck again please
[13:07] <biezpal> Chipaca, sure, I will :)
[13:07] <biezpal> thanks
[13:29] <tbr> aj
[13:29] <tbr> EWINDOW
[13:35] <Chipaca> tbr: ENOCOOKIE
[13:36]  * davmor2 gives Chipaca a Cookie now will you stop complaining?
[13:38] <Chipaca> davmor2: http://i.imgur.com/05bXjHW.jpg
[13:39] <davmor2> Chipaca: say Cookie one more time......I dare you!
[13:39] <kenvandine> Cookie
[13:41]  * Chipaca gets behind the bulletproof glass
[13:42] <kenvandine> :)
[13:59] <longsleep> Hey folks, what does "support for secure boot" mean with the latest stable release mean?
[14:00] <longsleep> -mean
[14:04] <mvo_> longsleep: that you can enable uefi and secure boot and the system will boot signed kernels
[14:04] <mvo_> longsleep: useful for systems who need a higher level of trust etc
[14:05] <ogra_> longsleep, after you switched yu rodroid to UEFI you can use signed kernels ;)
[14:05] <ogra_> *your
[14:10] <longsleep> mvo_: signed kernel wit UEFI and microsoft keys you mean?
[14:10] <mvo_> longsleep: yes
[14:10] <longsleep> mvo_: ah ok - thanks - so not relevant for arm
[14:11] <mvo_> well, the shim is signed with the microsoft key and that uses our key for the subsequent steps
[14:11] <mvo_> longsleep: yeah
[14:11] <longsleep> yes true, is it the same shim as with normal ubuntu?
[14:11] <mvo_> yes
[14:11] <tbr> well AArgh64 servers with UEFI...
[14:11] <tbr> if they ever ship
[14:11] <ogra_> longsleep, the last two releases were rather irrelevant to arm overall
[14:11] <mvo_> I guess the mail should have clarified that its about uefi secure boot
[14:12] <longsleep> ogra_: yeah i figured that, my odroids updated flawlessly from 5 to 6 and 7 though
[14:12] <ogra_> and the next one likely as well
[14:12] <longsleep> ogra_: did you look into possibilies for secure boot on armhf?
[14:13] <ogra_> not really ... would that be possible with uboot at all ?
[14:13] <longsleep> tbr: somewhere i read that 2016 will be the year of arm64 servers
[14:13] <ogra_> wasnt that arm64 laptops ?
[14:14] <longsleep> ogra_: mhm could have been laptos - i remember it not very good
[14:14] <longsleep> ogra_: i saw some code in u-boot with which was labled secure boot using some keys fused into the soc
[14:15] <longsleep> ogra_: did not look closes yet though
[14:16] <ogra_> "fused into the soc" heh
[14:16] <ogra_> might be hard to do if you are not a manufacturer
[14:16] <longsleep> true, but getting the uboot signed might be possible somehow
[14:17] <tbr> HS silicon often uses keys from a PROM inside the soc
[14:18] <longsleep> yeah - without knowing anything .. how are the phones which use u-boot protect their bootloader?
[14:19] <ogra_> usualyl from the preloader as i understand
[14:20] <longsleep> right, and how is the preloader protected from beeing overwritten with a preloader which does not validate anything?
[14:22] <tbr> longsleep: e.g. QC usually only loads a signed loader and will not boot if it's not signed
[14:22] <ogra_> yeah
[14:22] <tbr> and most phones don't use u-boot but a-boot or that other thing
[14:22] <ogra_> and you cant easily overwrite it either
[14:22] <longsleep> right
[14:23] <ogra_> some use uboot, but only chainloaded
[14:23] <longsleep> tbr: so i asume it is pretty hard to get secure boot on arm when the soc would boot any loader
[14:24] <tbr> longsleep: just as on x86, it's not an arch dependent problem
[14:24] <longsleep> tbr: right, i see - thanks!
[14:24] <longsleep> ogra_: are there any device which do not chain load uboot with some binary boot loader blob?
[14:24] <tbr> intel will also want your firstborn if you want the secure version of their CPUs
[14:24] <longsleep> hehe
[14:25] <ogra_> longsleep, yeah, most of them ...
[14:25] <ogra_> uboot on phones is rather a rare case ... it exists though
[14:25] <tbr> TI SoCs can usually be booted with u-boot directly
[14:25] <tbr> e.g. the BB with its AM335x
[14:25] <tbr> MLO is just a minimal u-boot
[14:25] <longsleep> oh, thats cool, so no proprietary part required to boot them up?
[14:25] <tbr> correct
[14:26] <tbr> not like RPi that requires that ginormous blob to boot the GPU before it even thinks about ARM cores
[14:26] <tbr> also u-boot on x86 works well
[14:26] <tbr> and I don't mean chain loaded
[14:27] <longsleep> is that in use on x86 in some machines one can buy?
[14:27] <tbr> yes, the minnowboard max for example
[14:28] <tbr> I'm not sure if it still requires the FSP blob or if someone figured that out yet
[14:29] <ogra_> i think you can re-flash the bnootloader on ALIX boards easily
[14:29] <ogra_> they come with coreboot preinstalled though
[14:30] <longsleep> coreboot is nice, though i read that most coreboot devices still load some blob to make hardware components work
[14:30] <ogra_> might be, i have two alix boards but never examined that level
[14:30] <tbr> that's the FSP and SM
[14:31] <tbr> you can get around those in some cases
[14:31] <tbr> you will still very much need the microcode updates though
[14:32] <longsleep> yeah - i would like to know what this stuff is doing though
[14:32] <tbr> the microcode in the soc is most often barely functional
[14:32] <tbr> fsp mostly sets up RAM timings and such IIRC
[14:32] <tbr> I've heard of a coreboot fork called libreboot (how inventive!) that manages on a few devices without those
[14:33] <longsleep> oh let me google that
[14:33] <longsleep> Ministry of Freedom (UK) lol
[14:34] <longsleep> they support the t400 - not so bad
[14:36] <ogra_> t400 ... pfft ...
[14:37]  * ogra_ wants a t1000 to mow his lawn
[14:37] <longsleep> eheh
[14:37] <ogra_> but thats still 600 revisions away
[14:38] <longsleep> the t400 is a little old
[14:39] <longsleep> libreboot can be flashed on the bbb
[14:39] <longsleep> that would be awesome if it then could boot snappy
[14:39]  * tbr fails to see the appeal on BBB, it already has a fully open source boot process
[14:40] <longsleep> oh it has? sorry then i was just ignorant
[14:40] <tbr> 14:25:22< tbr> TI SoCs can usually be booted with u-boot directly
[14:40] <tbr> 14:25:42< tbr> e.g. the BB with its AM335x
[14:40] <tbr> 14:25:50< tbr> MLO is just a minimal u-boot
[14:41] <longsleep> so the sources for MLO are public - i did not know that
[14:41] <longsleep> i do not have a BBB either though
[14:58] <ogra_> longsleep, MLO is uboot on a diet :)
[15:40] <tbr> which is necessary due to the internal SoC ram being only 32k or such. so all it does is try to set up the RAM and find the proper U-Boot binary
[15:59] <elopio> sergiusens: I'll review your code iff you upload the licensed snap.
[15:59] <elopio> that's my price :)
[16:02] <sergiusens> elopio, deal
[16:03] <Chipaca> elopio: "licensed snap"?
[16:03] <elopio> sergiusens: do you like or dislike docstrings?
[16:03] <sergiusens> elopio, wait, can we upload now?
[16:04] <sergiusens> elopio, I like!
[16:04]  * ogra_ buys a license from elopio 
[16:04] <elopio> Chipaca: yes, the one that has a funny paragraph that you have to agree with.
[16:04] <Chipaca> elopio: dude
[16:04] <sergiusens> elopio, I've just never done them properly, but I want to document the base plugin with docstrings
[16:04] <Chipaca> elopio: snappy-examples/licensed
[16:04] <elopio> I suspect you wrote that one.
[16:04] <sergiusens> Chipaca, he wants me to upload that ;-)
[16:04] <sergiusens> Chipaca, to the store
[16:04] <Chipaca> to the stoar
[16:05] <Chipaca> ok :)
[16:05]  * Chipaca gets it now
[16:05] <sergiusens> elopio, I'll check on the 'all reviews must be manual' thing first
[16:05] <elopio> ogra_: the first one is free.
[16:05] <ogra_> yay
[16:05]  * ogra_ feels the greed for more coming up 
[16:06] <elopio> sergiusens: I was just thinking that it's so hard for me to understand the snapcraft code because it doesn't have comments. Like this compose method.
[16:06] <elopio> I think I'd even like an example in the docstring.
[16:06] <sergiusens> elopio, ah, give me an example on how to write a 'proper' docstring and I'll do it :-)
[16:06] <sergiusens> elopio, it is not as easy as it was to do in go ;-)
[16:07] <elopio> sergiusens: https://www.python.org/dev/peps/pep-0257/
[16:07] <sergiusens> elopio, in go I jst started writing them and all was fine, the world was happy; in python there are many iplicit semantic rules :-P
[16:08] <elopio> sergiusens: I'll start documenting some things I understand.
[16:08] <elopio> then you can copy the format.
[16:18] <sergiusens> elopio, does that work for you http://paste.ubuntu.com/12791820/
[16:18] <sergiusens> elopio, ignore the runtests.sh part (that will be a separate MP)
[16:19] <sergiusens> elopio, wht is the correct way to add an example?
[16:32] <elopio> sergiusens: looks good, but not perfect.
[16:33] <elopio> sergiusens: instead of Returns, it should be Return.
[16:33] <elopio> and the first sentence should be a single line.
[16:33] <elopio> there are some tools that take the first line of the docstring as a summary.
[16:33] <sergiusens> elopio, so I have around 50 chars to express it?
[16:34] <elopio> sergiusens: yes, the short summary. Then you write as many lines you want in the following paragraphs.
[16:35] <sergiusens> elopio, it seems there are many ways to write docscrings
[16:35] <sergiusens> which I dislike
[16:35] <sergiusens> elopio, http://paste.ubuntu.com/12791994/
[16:36] <elopio> sergiusens: yes. The form we tried to follow in the tests was to stick to pep 257 as much as possible, using the sphinx tags.
[16:36] <sergiusens> elopio, I found that and then a ::param ...:: format
[16:36] <sergiusens> elopio, I saw ``keyword`` as well
[16:37] <sergiusens> elopio, just show me one docsrting from a test I can follow and I will write awesome docstrings
[16:37] <sergiusens> I dislike the fact that there is choice on how to do this ;-)
[16:38] <ogra_> but linux ius abouot choice !
[16:38] <elopio> sergiusens: https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_common.py#L121
[16:39] <elopio> sergiusens: there's free will, but we crush it on code reviews.
[16:39] <sergiusens> elopio, does help(something) pretty format all those ::param:: declaratons btw?
[16:39] <sergiusens> elopio, should I use ''' or """ ?
[16:39] <elopio> sergiusens: I don't know about help. But the idea is to generate an sphinx html out of this.
[16:39] <elopio> sergiusens: """
[16:41] <sergiusens> elopio, is multiline allowed after ::param keyword:: ?
[16:41] <elopio> sergiusens: yes.
[16:41] <sergiusens> elopio, ah, I see it now
[16:42] <sergiusens> elopio, how do I ref a :param keyword: in return?
[16:42] <sergiusens> elopio, see, this is why I did not start doing this :-)
[16:43] <sergiusens> vmayoral, hey, since you joined, I'm interested in knowing if you have tried experimenting with faster sdcards
[16:44] <vmayoral> hey @sergiusens,
[16:44] <sergiusens> vmayoral, I talked about some of the i/o slowness with ogra_ and mvo_ and there are some ideas floating around aside from just slow sdcard that might affect you; primarily the shared usb bus
[16:44] <elopio> sergiusens: uhm, I don't know. Just name it.
[16:44] <vmayoral> sergiusens: we've ordered them, should be able to test it soon
[16:45] <elopio> http://sphinx-doc.org/domains.html#cross-referencing-python-objects
[16:45] <elopio> sergiusens: it seems you can reference attr, but not parameters.
[16:46] <elopio> sergiusens: this is the examples I mostly follow: http://sphinx-doc.org/domains.html#info-field-lists
[16:52] <sergiusens> elopio, how about this http://paste.ubuntu.com/12792139/?
[16:53] <elopio> sergiusens: perfect.
[16:53] <elopio> I tend to be more verbose on the second paragraph instead of the return keyword.
[16:53] <elopio> but as you prefer.
[16:54] <sergiusens> elopio, I wasn't sure, I just saw duplication and then saw the doc you sent me and the example from ui-toolkit :-P
[16:55] <elopio> sergiusens: just choose whatever makes you happy, and we'll copy that style. The things that are important for me are the param and return tags, and the one line summary.
[16:56] <sergiusens> elopio, great, I'll stick to this, I don't like free form :-)
[16:56] <sergiusens> elopio, the paragraph could be used to go into detail with examples
[16:56] <sergiusens> elopio, which I haven't seen how to do yet
[16:57] <elopio> sergiusens: ah, right.
[16:57] <elopio> there are two options for the examples. You can write doctest  https://docs.python.org/3/library/doctest.html
[16:58] <elopio> or you can make it free form with the sphinx syntax. Let me see if I can find a nice one.
[16:58] <sergiusens> elopio, I don't mind doctest as long as they can access the network or if that won't be a problem we will be facing on and on in the future
[16:59] <elopio> sergiusens: we don't necessarily run the doctests. We need to add a command that runs them, and we can choose not to run them while the package is being build, for example.
[17:00] <sergiusens> elopio, I'll table the doctest/examples with sphinx for now then and think about it
[17:00] <sergiusens> elopio, I've already pushed the docstring while you weren't looking
[17:01] <sergiusens> :-)
[17:01] <elopio> sergiusens: https://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/matchers/__init__.py#L49
[17:01] <sergiusens> vmayoral, great, we are looking forward to isolating the issue
[17:06]  * sergiusens will brb
[18:02] <sergiusens> elopio, I uploaded licensed.canonical
[18:03] <sergiusens> tedg, is the catkin plugin ready for review? I saw some code changes but not sure if I should start code review yet
[18:03] <zyga> sergiusens: hey!
[18:03] <zyga> sergiusens: how are you
[18:03] <sergiusens> zyga, doing good, what's up?
[18:04] <zyga> sergiusens: holidays, a bit ill, enjoying rain and wind in Poland :)
[18:05] <elopio> sergiusens: thanks. I'm still confused by your branch.
[18:06] <elopio> I'm slow today.
[18:06] <sergiusens> elopio, the tests don't make it clear either?
[18:07] <elopio> sergiusens: it's like you are filling the missing properties with the values from the wiki, right?
[18:07] <sergiusens> elopio, exactly; and you might ask why I don't use .update() I guess
[18:08] <sergiusens> elopio, 1 I've had issues with it, 2 there is more to come (properties from the wiki will also do var expansion for the values)
[18:08] <elopio> sergiusens: no, I would just phrase the comments differently.
[18:10] <sergiusens> elopio, this is why we have reviews :-)
[18:10] <sergiusens> zyga, well go and relax if you are on holidays AND ill ;-)
[18:11] <elopio> sergiusens: yeah, but I don't know how to make it better. I'm trying...
[18:12] <sergiusens> elopio, exactly, I tried to explain using only a few words, maybe compose is what causes confusion and that word needs to be changed
[18:12] <elopio> sergiusens: :return: a dictionary that fills the missing values from the properties passed as an argument with values from the part in the wiki.
[18:13] <elopio> sergiusens: just a suggestion. Not sure if yours is better.
[18:13] <elopio> sergiusens: also I don't understand why would you return something if there is no wiki part. Shouldn't it raise an exception?
[18:13] <sergiusens> elopio, ah, I was trying to not use the word dictionary as that was implied in the type, but if that is fine, I don't mind using that
[18:13] <sergiusens> elopio, I can raise an exception too, that is debatable; I don't mind
[18:14] <elopio> sergiusens: I think it's clearer to raise an exception than to return a null value that later has to be interpreted.
[18:14] <sergiusens> elopio, I will raise an exception
[18:14] <sergiusens> elopio, right, as it is now, it is not a nul value, it is a nop
[18:14] <elopio> sergiusens: also, the docs are to be read by people, so make them as readable as possible. Don't worry that much about the metadata or duplication.
[18:15] <elopio> sergiusens: ah, I see. You return the same thing you get.
[18:17] <elopio> I'm inclined for the exception. The caller can take care of catching it to make it no-op.
[18:18] <sergiusens> elopio, ok, let me change that
[18:20] <elopio> sergiusens: and about the tests, I think that the name is the most important thing to make them readable.
[18:20] <elopio> instead of test_compose, I see three tests. something like
[18:20] <elopio> test_compose_must_update_missing_value_from_wiki -> you pass no source as argument
[18:20] <elopio> test_compose_must_keep_value_from_properties -> you pass source as an argument
[18:20] <elopio> test_compose_unexisting_wiki_part_must_raise_exception
[18:20] <elopio> sergiusens: and starting to nitpick, s/part1/part-from-wiki.
[18:20] <sergiusens> elopio, the nitpick I refuse as the part lives in both places :-)
[18:21] <sergiusens> elopio, but if it makes it clearer, then yeah, for the test it is fine
[18:22] <elopio> sergiusens: well, it wouln't hurt to make it more verbose like: part-that-exists-in-wiki
[18:22] <elopio> not a big deal if the name of the test is clear. And you can always throw comments instead.
[18:22] <elopio> sergiusens: anyway, now that I get what your branch does, +1. It looks correct to me.
[18:23] <elopio> I'll top approve after lunch.
[18:23] <sergiusens> elopio, I'll be fixing in the meantime :-)
[18:23] <elopio> sergiusens: and I would throw in an integration or example test.
[18:26] <elopio> but maybe not yet. We only have the curl part in the wiki, and there's no much sense in overwriting its properties. Maybe an example when we have more parts that make sense to extend
[18:52] <mvo_> Chipaca: *if* you are still around, I followed up on the snappy-snapfs-mount MP would love to hear your thoughts, but no rush, I call it a day now
[19:54] <sergiusens> tedg, maybe envvars can all be driven by the plugin and no need to have it in the parts?
[19:57] <tedg> sergiusens: Eh, I'm not sure that many people will use plugins though. I'd like to have less of them.
[19:57] <tedg> sergiusens: For instance if ROS didn't have so many relocation issues, it'd be nice if that didn't have to be a plugin. Just a repo and some stage-packages in the wiki.
[19:58] <tedg> I'm just not sure we're ever gonna live in a world where the libraries end up where we want.
[19:58] <tedg> And I hate pushing people to write shell scripts all the time.
[20:06] <sergiusens> tedg, well the thing is, for a part, we can't
[20:06] <sergiusens> tedg, as in, hey look for stuff here too
[20:10] <tedg> sergiusens: I guess I was thinking that the part would provide environment variables for things it builds. For instance "I put my data here"
[20:12] <sergiusens> tedg, right, I have that email in draft :-)
[20:12] <sergiusens> tedg, The wrapper thing is all fine and dandy to some extent for running, but building is so disparate
[20:14] <tedg> I feel like we're walking a dangerous path with encouraging so many wrappers.
[20:34] <sergiusens> tedg, so I replied and not sure if it will be for the worse :-)
[20:34] <sergiusens> tedg, wrt actual things in the pipeline, just leave a coment in the catkin branch when it is ready for another look
[20:44] <tedg> sergiusens: I think that it is, I'm building a test snap to see if it still all works.