[04:59] <elopio> snappy-m-o autopkgtest 1647 xenial:armhf xenial:arm64
[04:59] <snappy-m-o> elopio: I've just triggered your test.
[08:04] <mup> PR snapcraft#1648 opened: sources: get svn revision with --show-item flag <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/1648>
[09:55] <mup> PR snapd#4110 opened: many:  have a timestamp on store assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/4110>
[10:10] <mup> PR snapd#4111 opened: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[10:10]  * ogra_ really likes the new animations for download and install 
[10:19]  * Chipaca is happy that ogra_ likes it
[10:29] <pedronis> Chipaca: hi
[10:30] <pedronis> Chipaca: #4111 might be something you could review when you have time
[10:30] <mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[10:35] <Chipaca> pedronis: already looking at it yes
[10:36] <Chipaca> pedronis: we still have no answer for how to turn off these flags :-(
[10:36] <Chipaca> beyond reinstalling
[10:36] <pedronis> Chipaca: snap refresh foo
[10:36] <pedronis> that's the answer Gustavo gave
[10:37] <pedronis> Chipaca: : https://forum.snapcraft.io/t/make-ignore-validation-sticky-and-send-the-flag-over/2139/2
[10:37] <Chipaca> hmmm
[10:38] <Chipaca> we're probably not doing the right thing today in a couple of places then
[10:38] <pedronis> that's also the behavior implemented by the branch
[10:38] <pedronis> and tested
[10:38] <pedronis> at least for this flag
[10:38] <pedronis> Chipaca: notice that at least for channel there's special code to do something even if there's no refresh (though for channel we also have switch)
[10:39] <pedronis> adding similar code for this is one of the TODOs
[10:40] <pedronis> Chipaca: I'm talking about this:  https://github.com/snapcore/snapd/pull/4111/files#diff-4f584006240926759b614bfd921c5fc0R938
[10:40] <mup> PR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>
[10:41] <pedronis> Chipaca: so I think I'm following the spec afaiu
[10:44] <Chipaca> pedronis: yeah, that 'do something in refresh when no update' is the missing bit i guess?
[10:45] <pedronis> yes
[10:45] <pedronis> but it's annoying enough that I prefer to do it in a separate PR
[10:45] <pedronis> (also we leaved without it for channels for a long while)
[10:45] <pedronis> s/leaved/lived/
[10:45] <Chipaca> pedronis: OTOH maybe it's an argument to make switch do this instead of refresh, when no update
[10:46] <pedronis> for channels we do both
[10:46] <pedronis> also I fear switch as designed is too channel specific
[10:46] <pedronis> to involve it in this
[10:47] <pedronis> anyway I personally don't see any of that as blocker to the main change
[10:47] <Chipaca> pedronis: why is switch too channel-specific?
[10:47] <pedronis> snap switch -h
[10:48] <pedronis> switch switches channel
[10:49] <pedronis> if we want it to do other flag toggling I'm not sure the name is great or it is easy to explain
[10:49] <Chipaca> pedronis: i thought you meant it would feel unnatural to use it for this, not that we'd have to change the documentation
[10:49] <Chipaca> OTOH it's true that the "strip devmode" thing doesn't work in switch
[10:49] <Chipaca> i.e. it'd have to be 'snap switch --disable-devmode thesnap'
[10:49] <Chipaca> or somesuch
[10:49] <pedronis> yea, it's not an nice UX afaict
[10:50] <pedronis> well, mostly is not a discoverable UX
[10:51] <pedronis> anyway I didn't do any of this in this PR because it has huge bikeshedding potential as you see
[10:57] <pedronis> Chipaca: I'm getting this from prepare in a test run (on 14.04):  + chattr -i /var/cache/snapd/names
[10:57] <pedronis> chattr: No such file or directory while trying to stat /var/cache/snapd/names
[11:09] <mlw> Has anyone here had an issue with cmake "finding" libGLEW.so in the wrong place. Having an issue with snapcraft unable to find it after building. Cmake config says it finds GLEW in /usr/include
[11:09] <mlw> Could anyone point me in the right direction?
[11:10] <mlw> I have the libglew-dev in my build-packages.
[11:48] <diddledan> the cmake snapcraft plugin currently doesn't add <stage>/usr/local/lib{,/x86_64-linux-gnu} to the CMAKE_LIBRARY_PATH variable, and because the var is set in the environment it isn't possible to override using -DCMAKE_LIBRARY_PATH in configflags:
[11:51] <diddledan> same for CMAKE_INCLUDE_PATH and <stage>/usr/local/include
[11:52] <sergiusens> davidcalle hey, not sure how this happened, but the oldest doc in the world was revived here https://docs.snapcraft.io/build-snaps/plugins
[11:53] <diddledan> why does that page have a blurb at the bottom about yocto being owned by linux foundation? I mean what relevance is there?
[11:54] <diddledan> sergiusens: ^^^
[11:55] <diddledan> looks like it's on all the snapcraft.io pages
[11:55] <sergiusens> diddledan I don't know, I feel like I woke up in the twilight zone
[12:31] <mlw> diddledan: so I'm stuck?
[12:32] <mlw> the error I get reads
[12:32] <mlw> CMake Error at cmake_install.cmake:36 (file):
[12:32] <mlw>    file INSTALL cannot find
[12:32] <mlw>    "/home/mattias/djv/parts/cmake-build/src/$CMAKE_PREFIX_PATH:/home/mattias/stage/lib/libGLEW.so".
[12:33] <diddledan> mlw: my comment was unrelated
[12:33] <diddledan> mlw: I was mentioning my own problem
[12:34] <mlw> diddledan: ah, ignore me :)
[12:35] <diddledan> mlw: although it does look like your problem might be similar
[12:35] <mup> PR snapcraft#1649 opened: add stage/usr/local/lib to cmake library path <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/1649>
[12:39] <sergiusens> stgraber jdstrand any ideas about this? "Setup snap "lxd" (4778) security profiles (cannot setup seccomp for snap "lxd": " on a travis run today -> https://pastebin.ubuntu.com/25864977/
[12:43]  * sergiusens goes for a walk
[13:14] <jdstrand> fatal error: runtime: address space conflict'
[13:14] <jdstrand> err
[13:14] <jdstrand> sergiusens: I don't know. I just tried on xenial with edge core and edge lxd and it worked fine. this seems to go a golang thing due to 'runtime: address space conflict: map(0xc820000000) = 0x7fc72ab24000
[13:14] <jdstrand> fatal error: runtime: address space conflict'
[13:15] <jdstrand> sergiusens: I googled that and it said something about garbage collection and heap memory. did the system oom?
[13:16] <jdstrand> sergiusens: looking at the trace, it looks like a heap allocation that failed
[13:25] <pedronis> Chipaca: I pushed my changes to #4076, it could use  a review
[13:25] <mup> PR #4076: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076>
[13:30] <cachio> jdstrand, hey, I am creating a test for desktop interface and I can access the /etc/xdg/user-dirs.conf and .defaults
[13:30] <cachio> jdstrand, I see this https://paste.ubuntu.com/25865263/
[13:31] <cachio> jdstrand, I can access to the rest of the files
[13:31] <cachio> jdstrand, not sure if I need to do something else
[13:34] <jdstrand> cachio: I'm confused. you can access the files but you have denials?
[13:34] <jdstrand> cachio: I can say that we started to allow those files with a recent 2.29 and master PR
[13:34] <cachio> jdstrand, no, I getr permission denied
[13:35] <cachio> jdstrand, I am able to access to the rest of the files and dirs allowed by the interface
[13:35] <jdstrand> cachio: are you on 2.28?
[13:35] <cachio> in master
[13:36] <cachio> jdstrand, I am creating a new test to validate the desktop interface on master
[13:36] <jdstrand> that doesn't make sense. I'm looking at master now and the files are in there
[13:36] <cachio> jdstrand, yes, I did the same
[13:36] <jdstrand> cachio: can you paste /var/lib/snapd/apparmor/profiles/snap.test-snapd-desktop.testdesktop?
[13:37] <cachio> jdstrand, https://paste.ubuntu.com/25865301/
[13:38] <cachio> jdstrand, I have installed 2.28.5
[13:38] <cachio> is it included on this one?
[13:39] <jdstrand> cachio: that file doesn't have the rules
[13:39] <jdstrand> cachio: no. it is in 2.29 and higher
[13:39] <cachio>  jdstrand, well, that's the reason :)
[13:39] <jdstrand> indeed :)
[13:39] <cachio> I'll update
[13:40] <cachio> jdstrand, hanks and sorry
[13:40] <cachio> thanks
[13:40] <jdstrand> np
[13:53] <stgraber> sergiusens: ouch, never seen that before, that's one very unhappy snapd
[14:10] <sergiusens> jdstrand the log is all the info I have, this is travis on trusty
[14:10] <hurricanehrndz> How do you run a search against all the channels?
[14:10] <sergiusens> seems to have been a one time thing, luckily
[14:10] <Chipaca> hurricanehrndz: you can't
[14:11] <Chipaca> hurricanehrndz: why do you want to do that?
[14:13] <hurricanehrndz> Chipaca: Why wouldn't I, There is no snapcraft on openSUSE and I would like to use it. I know it is in the candiate channel, but I know that because I ran a search on reddit, I find it very unproductive to have to go to browser in order to find snaps
[14:14] <hurricanehrndz> Chipaca: so now I'm wondering what other snaps are available on the other channels that I could make use of, but have no way to index
[14:15] <pedronis> hurricanehrndz:  but snap info snapcraft   tells that
[14:15] <hurricanehrndz> Oh, didn't know
[14:16] <hurricanehrndz> That's what I was looking for, I think. Let me try
[14:17] <hurricanehrndz> pedronis: Info only helps, if I know the snap exists
[14:17] <pedronis> this works if you know the name of the snap,  but in general is not a good idea to use not stable snaps you don't know about
[14:18] <pedronis> hurricanehrndz: that's a bit by design currently, if a snap is not stable, is not advertized, but can be used  (install, info etc) if one knows about it
[14:18] <hurricanehrndz> pedronis: I'm a dev, so I'm okay with being on cutting edge. It just seems that find should have an option to search across all channels
[14:19] <hurricanehrndz> pedronis: is there any plans to bring snapcraft to other platforms?
[14:20] <hurricanehrndz> Or is a snap of snapcraft the plan?
[14:20] <Chipaca> hurricanehrndz: that's a question for sergiusens i think
[14:21] <hurricanehrndz> sergiusens: Do you know if there are plans to bring snapcraft to other distros
[14:23] <hurricanehrndz> Thanks for all the guidance guys! :)
[14:24] <sergiusens> hurricanehrndz it is a snap, so if snaps work their, it could potentially work, like all debian based distros should be ok; snapcraft with cleanbuild or persistent containers if not
[14:24] <sergiusens> that said, if you want something like Fedora, we are waiting on Son_Goku ;-)
[14:24] <Son_Goku> wait what?
[14:24] <Son_Goku> sergiusens: what am I being dragged into now?
[14:24] <sergiusens> btw, 2.35 is going to be the one that makes it to stable
[14:25] <sergiusens> Son_Goku dnf?
[14:25] <sergiusens> dnf in snapcraft that is
[14:25] <Son_Goku> oh, you mean RPM support for snapcraft
[14:25] <Son_Goku> yeah, I need to make time to hack on it again
[14:25] <Son_Goku> I've been bombarded with all kinds of stuff lately
[14:28] <sergiusens> Son_Goku yeah, exactly that, and no worries
[14:28] <Son_Goku> hurricanehrndz: I'm working on Fedora/openSUSE support for snapcraft, it's just taking some time
[14:28] <Son_Goku> unlike most folks here, I'm doing this in my free time, so it's not moving as fast as I'd like it to
[14:28] <sergiusens> elopio and kyrofa are you around for a quick hangout?
[14:28] <Son_Goku> I took a break last weekend to just play video games and do nothing else
[14:28] <Son_Goku> Super Mario Odyssey was awesome
[14:29] <sergiusens> Son_Goku heh, some of the things that get done are done in my free time as well but I totally get you as I am not context switching ;-)
[14:29] <sergiusens> Son_Goku I noticed that SMO took some priority over what is considered free time
[14:30] <Son_Goku> the last four weekends were spent working
[14:30] <Son_Goku> I was exhausted
[14:30] <Son_Goku> like, for $DAYJOB
[14:31] <Son_Goku> sergiusens: as for snapcraft cleanbuild, kyrofa has to start packaging lxd for Fedora now ;)
[14:31] <Son_Goku> I fulfilled my end of the bargain and made the selinux policy work with lxd, now we just need lxd in Fedora itself
[14:32] <sergiusens> Son_Goku just snap install lxd on fedora!
[14:32] <Son_Goku> the snap doesn't integrate with our selinux policy
[14:32] <Son_Goku> so things break
[14:32] <Son_Goku> I don't recall if stgraber fixed it, but it was still broken last I checked
[14:33] <Son_Goku> which admittedly, was a few weeks ago
[14:36] <hurricanehrndz> sergiusens: Nope not fedora, openSUSE
[14:36] <hurricanehrndz> sergiusens: Thank you though
[14:36] <hurricanehrndz> Son_Goku: If you need help let me know
[14:37] <hurricanehrndz> Son_Goku: Thanks for all your hard work, it means a lot to all of use that are on RPM based distros
[14:38] <hurricanehrndz> Son_Goku: Good for you taking a break, I know the feeling of needing a breather. It has been awhile for me, he he. I want to get back into playing games again soon.
[14:38] <hurricanehrndz> Ps selinux is a pain in the ass
[14:43] <Son_Goku> hurricanehrndz, SELinux isn't bad or difficult, but it's hard to get Ubuntu people to think about the other side so much ;)
[14:43] <Son_Goku> their only SELinux guy left a long time ago for Google
[14:44] <ogra_> if you talk about kees, he didnt leave ubuntu ... only canonical ;)
[14:45] <ogra_> (he is actually a member of the ubuntu technical board )
[14:45] <elopio> sergiusens finishing my workout. Will be ready in 15.
[14:53] <kyrofa> sergiusens, elopio sorry, late start today, I'm around now
[14:57] <kyrofa> I have coffee roasting though
[15:01] <sergiusens> kyrofa elopio ok, let's join when the clock hits 10, on the weekly one
[15:01] <elopio> I'm ready
[15:04] <elopio> Ack
[15:05] <jdstrand> sergiusens: it seems something unrelated to snappy. my guess is memory pressure
[15:11] <kyrofa> Sorry guys, just finished up the coffee, joining now
[15:12] <kyrofa> elopio, sergiusens darn, was it that quick? :P
[15:15] <elopio> kyrofa: where are you?
[15:15] <sergiusens> kyrofa we are talking still
[15:15] <elopio> wrong hangout?
[15:16] <kyrofa> What the heck... weekly right? I was the only one there
[15:16] <kyrofa> Trying again
[15:36] <om26er> Hi! re: docker snap, seems when I delete my containers and images the disk space is never freed.
[16:03] <cory_fu> Are the build.snapcraft.io builders backed up or something?  I've been waiting all morning for a build of charm-tools so that I can do a release.
[16:03] <om26er> cory_fu: I learned yesterday that builders are busy when gates for new Ubuntu release open.
[16:04] <om26er> my build started at like 12AM last night.
[16:04] <cory_fu> Ah, I see.  That makes sense
[16:08] <mup> PR snapcraft#1647 closed: lxd: better surfacing of errors <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1647>
[16:25] <kyrofa> Haha, oh darn, I was testing that PR. Apparently I can only approve OPEN ones
[16:26] <kyrofa> +1 anyway
[16:27] <diddledan> has snapd lost it's newly inbuilt xdg-open support again?
[16:27] <diddledan> snapd   2.28.5+17.10
[16:27] <mup> PR snapd#4112 opened: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>
[16:27] <diddledan> Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
[16:28] <diddledan> from dpkg -l : ii  snapd-xdg-open                                                   2.28.5+17.10                                amd64        Transitional package for snapd-xdg-open
[16:30] <diddledan> weird. some apps can launch urls fine but one specific one (djv_view that I've been working with mlw to snap) can't
[16:31] <diddledan> oh wait. it's a file:// url
[16:31] <diddledan> bah
[16:32] <diddledan> not supporting mailto: and file: urls is painful
[16:43] <Chipaca> diddledan: raise it in the forum?
[16:45] <diddledan> I thought I had. search isn't showing me the thread tho
[16:49] <kyrofa> The forum search does that
[16:49] <diddledan> why?! seems a bit backwards for a "find the thing you're after" to not show the thing you're after
[16:50] <kyrofa> diddledan, haha, I'm just being mean. I just mean to say it doesn't cooperate with me either
[16:50] <diddledan> aye, I've noticed it on several different times I've tried finding my previous posts
[16:51] <Chipaca> diddledan: i didn't understand it until i tried to read one of the longer topics
[16:51] <Chipaca> there, it's exactly what i wanted
[16:51] <Chipaca> so ¯\_(ツ)_/¯
[18:22] <sergiusens> I need to relocate, internet is down
[19:11] <gsilvapt> hello all
[19:11] <gsilvapt> elopio, you around?
[19:45] <mup> PR snapcraft#1650 opened: Release changelog for 2.35 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1650>
[19:48] <sergiusens> elopio kyrofa ^
[20:32] <kyrofa> sergiusens, elopio, ament is finally all green! Means autopkgtest is promising
[20:33] <kyrofa> sergiusens, once we get this release out the door, would you mind giving snapcraft#1636 a priority? I'm seeing more people wanting to run on trusty
[20:33] <mup> PR snapcraft#1636: internal: more gracefully determine host OS <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
[20:39] <sergiusens> kyrofa hmm, maybe we should get that one in now if it allows trusty, that is a big win. Is it green green?
[20:39] <kyrofa> sergiusens, no autopkgtests have run there, but I can run them if we can spare the resources
[20:40] <sergiusens> kyrofa we will only do trusty as a snap though
[20:40] <kyrofa> sergiusens, of course
[20:40] <elopio> gsilvapt: hello
[20:40] <kyrofa> sergiusens, I'd also like to write some spread tests for it
[20:40] <kyrofa> sergiusens, but I was able to build a ROS snap with it
[20:40] <sergiusens> kyrofa for which we can just enable a new runner on our travis matrix to run the same suite without lxd
[20:41] <kyrofa> Oh that's a good idea, assuming you're talking about the integration suite
[20:41] <kyrofa> Although that will roughly double our PR test time...
[20:41] <kyrofa> Nightly?
[20:42] <kyrofa> It also assumes the testing deps we have work on trusty
[20:42] <kyrofa> I can test that out
[20:43] <kyrofa> Eh... no that won't work. That will pull all deps from trusty, which I bet won't work for some of our tests
[20:45] <sergiusens> kyrofa don't do it now ;-)
[20:45] <sergiusens> for later
[20:46] <kyrofa> Sounds good
[20:46] <sergiusens> kyrofa ugh, you updated the branch, I was about to merge
[20:46] <sergiusens> oh well... this gives some time for elopio to review
[20:46] <kyrofa> sergiusens, you still can if you're comfortable with it, results in the same thing, but yeah that's fine too
[20:47] <kyrofa> I'm retesting it here anyway, a few different things have landed that should make this the last one for trusty, just verifying now
[20:51] <sergiusens> kyrofa ok
[20:54] <kyrofa> sergiusens, in the release notes, let's make sure we call it "initial/experimental support" :P
[20:54] <kyrofa> Then we can build up our suite of tests to gain confidence
[20:54] <sergiusens> kyrofa oh, a first release of anything is that, right?
[20:54] <kyrofa> Haha, totally
[21:11] <kyrofa> sergiusens, built the snap, works great for both the opencv demo as well as the ros-talker-listener integration test (indigo, which is one of the main use-cases for this). Green light on that front
[21:11] <kyrofa> i.e. this is indeed the final PR for trusty support
[21:15] <sergiusens> kyrofa great
[21:40] <kyrofa> sergiusens, it doesn't look like the nodejs plugin ever runs `yarn install` if the package manager is yarn, right?
[21:41] <sergiusens> kyrofa why do you ask?
[21:41] <sergiusens> it is very different in the refactor
[21:42] <sergiusens> but yarn install doesn't do the same as npm install
[21:42] <kyrofa> sergiusens, while I'm waiting for tests to run I'm trying my first nodejs snap, who's build directions are given as yarn install && yarn run start
[21:43] <kyrofa> It's not building without any options, so I've been taking a closer look at the plugin
[21:43] <sergiusens> kyrofa oh, maybe let m give you the refactor
[21:44] <sergiusens> kyrofa look at my nodejs-refactor branch
[21:44] <kyrofa> sergiusens, trying it out now, thanks!
[21:44] <sergiusens> kyrofa this reminds me about `source: .` ... that needs to leave the world as the default
[21:56] <kyrofa> sergiusens, that works way better, although trying to use the tarball created by npm pack isn't working, I'll poke at that
[21:56] <kyrofa> (it doesn't seem to exist, although pack seemed to succeed)
[21:56] <mwhudson> so uh why do we not have snapd for trusty/{arm64,ppc64el}? is this something you should be talked to your local golang maintainer about?
[22:01] <kyrofa> mwhudson, probably worth a forum post, I suspect all the snapd folks are long gone for the day
[22:04] <kyrofa> sergiusens, the tarball doesn't include a 'v' in the version
[22:04] <kyrofa> At least, not this one
[22:05] <kyrofa> sergiusens, the package.json includes a v, but the tarball doesn't
[22:05] <mwhudson> kyrofa: yeah i guess although i've rolled back my concern another level :)
[22:27] <mup> PR snapcraft#1636 closed: internal: more gracefully determine host OS <bug> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1636>
[22:35] <mup> PR snapd#4113 opened: tests: test for desktop interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4113>
[22:51] <kyrofa> elopio, ping on bug #1693058
[22:51] <mup> Bug #1693058: can't install a snap with ca-certificates-java as a build-package <recording> <regression> <Snapcraft:Triaged by elopio> <https://launchpad.net/bugs/1693058>
[23:00] <kyrofa> sergiusens, when you're able, could you take a look at bug #1724972 ? I swear I remember running into that before, but my memory is so hazy. Any chance you remember?
[23:00] <mup> Bug #1724972: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <iot> <snap> <Snapcraft:New> <https://launchpad.net/bugs/1724972>
[23:01] <kyrofa> I thought we fixed stuff like that in the repo
[23:02] <kyrofa> Oh interesting-- that file should be filtered out completey
[23:03] <kyrofa> Oh nevermind. That's just crawling
[23:07] <elopio> kyrofa: pong, closed
[23:07] <kyrofa> elopio, yay \o/
[23:33] <kyrofa> sergiusens, elopio you'll never believe it, but snapcraft#1607 is green
[23:33] <mup> PR snapcraft#1607: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607>
[23:33] <elopio> ^_^
[23:33] <kyrofa> Note that I've not completely solved the problem, and while it is still a problem, it was a red herring that wasted a ton of time
[23:34] <kyrofa> During review, I made a change that happened to cause an integration test to fail. However, instead of showing us that failure, unittest barfed with the exception we all know and love
[23:35] <kyrofa> Now that the tests no longer actually fail, unittest isn't dying
[23:35] <kyrofa> I'm still investigating why unittest is breaking this way on Travis, but it's no longer blocking this branch
[23:36] <kyrofa> Until I figure out what's happening, if you see this exception, it means the tests are failing and need to be run locally