#snappy 2016-01-04
<dholbach> good morning
<fgimenez> good morning
<anpok> I continued toying around with a nfs server snap... now there is a library opening a config file in /etc/.. libtripc within rpcbind. The path is a compile time literal. Whats the right way to solve that? Is snappy doing something on startup to remap paths for each app? Should I change that to a relative path.. or use an env var?
<asac> happy new year!
<dholbach> asac: and the same to you!
 * asac hugs dholbach 
 * dholbach hugs asac
<JamesTait> Good morning all; happy Monday, happy New Year, and happy World Braille Day! ð
<anpok> snappy new year!
<asac> ubuntu@localhost:~$ snappy enable-classic
<asac> 147.41 KB / 73.75 MB [______________________________________________________________________________] 0.20 % 367.10 KB/s 3m25s
<asac> 73.75 MB / 73.75 MB [====================================================================================] 100.00 % 1.12 MB/s
<asac> failed to create classic mode dir: mkdir /writable/classic: permission denied
<asac> mvo: ?
<asac> $ snappy list
<asac> Name                   Date       Version      Developer
<asac> canonical-linux-raspi2 2015-12-17 4.2.0-1014-3 canonical
<asac> ubuntu-core-armhf      2015-12-21 16.04.0-4    canonical
<asac> canonical-pi2          2015-12-17 2.2          canonical
<asac> dont see an apparmor error for that... so guess just missing directory?
 * asac mkdir /wrtable/classic and then retries
<asac> mvo: oh i think its bnecause i didnt use sudo
 * asac retries another time
<asac> bah lp timeout when filing this as a bug :(\
<mvo> asac: yeah, sudo - but that is a bug in itself that it tries to do that even without uid=0
<asac> mvo: nexty problem ist hat i cant apt-get install in classic\
<asac> tried to snappy classic shell with sudo, but didnt work
<asac> also when running snaoppy shell classic i end up with ubuntu user in the container
<asac> mvo: https://bugs.launchpad.net/snappy/+bug/1530826
<ubottu> Launchpad bug 1530826 in Snappy "enable-classic should fail fast if not run with sudo/as root" [Undecided,New]
<asac> bug one
<asac> mvo: bug two: https://bugs.launchpad.net/snappy/+bug/1530827
<ubottu> Launchpad bug 1530827 in Snappy "cannot apt-get install in snappy shell classic" [Undecided,New]
<mvo> asac: that seems to be something new in xenail I will debug
<mvo> asac: releated to the new apt sandbox stuff
<asac> mvo: what is apt sandbox
<asac> ?
<ogra_> asac, apt has its own user now
<ogra_> (broke the images for a week :P )
<ogra_> so it drops privs (abd does other stuff to operate more securely)
<ogra_> *and
<mvo> asac: yeah, what ogra_ says. the idea is that if e..g there is a buffer overflow in the http downloader then the attacker does not get root right away
<mvo> asac: on fixing the issues now (but may get interrupted by a lunch break soon :)
<ogra_> mvo, are you actually working already again ?
<asac> mvo: so we got debian crack that broke everywhere? nice :P
<ogra_> it only broke snappy and touch due to the added user :)
<mvo> ogra_: I think so, I need to check the calendar but I think I do :)
<anpok> hm i guess there is no policy called network-servr
<anpok> *server
<mvo> ogra_: may take a day off during the week
<mvo> asac: *cough* yeah
<ogra_> mvo, heh ... i'm still off til 16th ... but wanted to poke you with that pending u-d-f merge .... and snappy FTBFS on arm64 in xenial since a few weeks now
<ogra_> would be good if someone could handle that
<mvo> ogra_: 16! woah :)
<ogra_> well, i had to burn vac. days and decided to actually burn some in advance this year :)
<mvo> ogra_: u-d-f> I have a look, I think I need to spend some time on that one :/
<ogra_> oh, why is that ?
<mvo> ogra_: just because noone else is and the all-snap branch needs integration in there too
<ogra_> it applies, builds an runs fine for me
<mvo> ogra_: oh, sorry, not specific to your diff, thats just a tiny part of it :)
<ogra_> i dont think it should be affected by all-snaps ... at least not beyond some preipherial bits
<mvo> ogra_: thats good
<mvo> ogra_: arm64> is it just a test failure? if you don't know from the top of your head don't worry, I check it out
<ogra_> i dont know, i just see the image build failure since a while, i didnt check the snappy build itself
 * ogra_ sighs ...snow ... i thought i'd get away without shoveling this year
<mvo> asac: sorry for the apt trouble, I looked at this and you need to run "sudo apt update",  this is a bug in apt that it does not tell you this. plus you probably can't use sudo in classic right now because the fix https://github.com/ubuntu-core/snappy/pull/266 is not merged yet :/
<pindonga> sergiusens, mvo jdstrand_ hi there... if I need to add a dependency to snapcraft for a feature I'm proposing, I also need to package that dependency as an ubuntu package right?
<pindonga> but that would also mean having to introduce a PPA until the pkg is available in the main repos
<pindonga> maybe there's a better alternative?
<sergiusens> pindonga, you only want to target xenial for snapcraft 2.0 (if the question is about that)
<sergiusens> pindonga, landing in xenial is pretty fast
<pindonga> sergiusens, so the answer would be 1) yes, package deps for ubuntu (xenial), 2) yes, use main repos
<pindonga> right?
<sergiusens> pindonga, yeah, I was also suggesting no need to think about backporting
<pindonga> ack
<asac> mvo: no worries.... thanks! let me try
<asac> so yeah, no sudo in classic (e.g. lack of sudoers)
<ogra_> ppisati, http://paste.ubuntu.com/14399210/ ... worjking dragonboard config with your branch ... it isnt merged with the std ubuntu one yet so a bit messy, but it makes all HW work fine
<ogra_> ppisati, it uses the apq8016-sbc.dtb DT
<mvo> asac: yeah, this is fixed in the branch above, once that branch is merged it will be fine
<asac> cool... waiting then
<kyrofa> Good morning
<kyrofa> Chipaca, so `snappy remove` doesn't remove any of the snap's data?
<ppisati> ogra_: i've seen your email from december
<ppisati> ogra_: the kernel with your config changes is building ATM
<ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+build/8800172
<ogra_> ppisati, yeah, but i re-did a lot of that stuff since
<ogra_> cool !
<ppisati> ogra_: ah
<ppisati> ogra_: did you change anything in the config?
<ogra_> initially i was using the wrong DT ...
<ogra_> a lot, yeah
<ppisati> ogra_: oh ok, then i'll do anothe config diff and repush
<ogra_> effectively i went back to the 96boards one plus systemd and apparmor options
<ppisati> ogra_: anyhow, i couldn't test this kernel
<ogra_> i.e. you will have to go over it and somehow merge it with the normal ubuntu config (not all USB modules, etc etc ... )
<ppisati> ogra_: cause i've a problem with your img
<ogra_> oh ?
<ppisati> ogra_: it's weird, but after the first boot
<ppisati> ogra_: my board refuses to boot subsequently from sd
<ogra_> you made sure it is a 4G card ?
<ppisati> ogra_: 8G
<ogra_> !
<ogra_> there is a reaadme next to the image :P
<ogra_> resizing is still broken, it wipes your GPT
<ppisati> ogra_: fuck
<ogra_> you need a 4G card
<ppisati> i haven't see that
<ppisati> that explain it
<ppisati> ok
<ogra_> yeah
 * ppisati search for a 4G card then
<ogra_> i might fix the resizing during my vacation :)
 * ogra_ is still officially off til 16th
<ppisati> ogra_: no prob, i'll play with your img and my kernel
<ppisati> ogra_: till it works fine
<ogra_> well, the current cnfig should work fine but surely has glitches (iirc it has preempt turned on and stuff)
<ppisati> ogra_: the kernel compiling there, it's the same from december + the config diff you posted back then
<ogra_> i also havrnt looked at the firewall options, i think most are missing as well
<ppisati> ogra_: i'll make sure eveyrhing is fine
<ogra_> yeah, i just used your source package ;)
<ppisati> at least now i know why the img had that weird behaviour
<ogra_> yeah
<ogra_> note that you have to replace the wrongly named DTB when you change the kernel on it
<ogra_> uboot still points to the wrong name
<ogra_> (<ou need to copy apq8016-sbc.dtb over it)
<ppisati> ok
<ogra_> oh, and with that kernel there is a bug with console blanking(havent checked if the 96boards kernel has it too) ... it doesnt wake up on keystroke
<ogra_> in case you plan to use the tty console :)
<ppisati> ogra_: i even tried to install uboot on the boot partion on the internal flash
<ppisati> ogra_: but i couldnt make the board boot in that case
<sergiusens> kyrofa, morning
<ppisati> lets' see if i can figure that out too
<kyrofa> Hey sergiusens!
<kyrofa> Good vacation?
<sergiusens> kyrofa, you can tell from my absence here :-)
<ogra_> ppisati, well, you need to turn it into a boot.img first if you use the internal flash i think
<kyrofa> sergiusens, haha :)
<sergiusens> it was pretty good, really humid and rainy though, flooded cities everywhere
<kyrofa> Ugh
<kyrofa> Everyone save though?
<ppisati> ogra_: i did that, my problem was that i couldn't boot the board
<kyrofa> s/save/safe/
<asac> mvo: can i hack my classic stuff so that ubuntu is in sudoers maybe?
<asac> would really love to unblock what i am really after: "get an armhf build env"
<ppisati> ogra_: it was like, after kernel / dtb load and decompression, the board hung there
<ogra_> ppisati, like ... not at all ? i.e. not even messages from the SPL on the serial console ?
<ppisati> ogra_: zero
<sergiusens> kyrofa, mostly evacuated and the losses are only monetary; but it hasn't been without losses
<ogra_> ppisati, well, you should at least get the SBL messages, else you messed something up ...
<ppisati> ogra_: i was following this, i guess you saw that too
<ppisati> ogra_: http://rglinuxtech.com/?p=1606
<ppisati> ogra_: sorry
<ppisati> ogra_: still sleepy :P
<sergiusens> kyrofa, how was your time off?
<kyrofa> sergiusens, I'm sorry :(
<ppisati> ogra_: yes, i got a "complete boot" up to the point of loading kernel / dtb
<ogra_> ah
<ppisati> ogra_: so uboot was live and 'working'
<ogra_> that was with your kernel back then ?
<ppisati> ogra_: right, but even with the config change you pasted back then
<ogra_> oh
<kyrofa> sergiusens, mine was nice, but a little tough-- my wife has been having some pretty good contractions and we're still over a month out. She's been more or less on bed rest
<ogra_> but you used the right dtb :)
<ppisati> ogra_: right
<ppisati> ogra_: apq-
<ogra_> my first config change only worked withteh wrong one
<ppisati> ogra_: that might explain it
<ogra_> the pasteed config above now works with the right one :)
<sergiusens> kyrofa, yeah, that can be tough
<ppisati> ogra_: cool, i'll do config diff, recompile and reboot tests
<sergiusens> kyrofa, I get you guys are getting pretty anxious due to that
<kyrofa> sergiusens, yeah it's a bit stressful
<ppisati> ogra_: it'll be ready for when you are back
<ogra_> :D
<mvo> asac: yes, just do "sudo vi /writable/classic/etc/group" and add "ubuntu" to the "sudo" group
<mvo> asac: and bribe someone to review my branch that fixes the issue :P
<asac> mvo: i need your branch on top?
<mvo> asac: just that, then you should be fine
<mvo> asac: the branch will do it automatically
<sergiusens> kyrofa, elopio should we do a quick standup?
<elopio> Hello everybody.
<elopio> it's good to be back.
<kyrofa> sergiusens, yeah
<elopio> sergiusens: yes.
<sergiusens> elopio, trading a natural jungle with a software one :-)
<sergiusens> elopio, kyrofa I'm in
<kyrofa> asac, how are those snapcraft PRs coming? I'd be happy to push them the rest of the way if you like
<kyrofa> sergiusens, the ld.so.conf.d idea is really elegant. I'm wondering if we should perhaps do that throughout snapcraft rather than just the catkin plugin. Thoughts?
<kyrofa> sergiusens, might save some pain for devs
<kyrofa> elopio, ^^
<sergiusens> kyrofa, +1 on that
<kyrofa> sergiusens, excellent :)
<asac> kyrofa: could be that we can abandon them... let me try something
<kyrofa> asac, alright let me know
<asac> and hny!
<asac> sergiusens: heya! can we ahve a default target back to be snap?
<asac> on master
<asac> utlemming: do you have xenial snappy all-snaps builds set up for aws, gcloud etc. yet?
<asac> that would make my month :)
<sergiusens> asac, we can, yes; I just need to make it clear in the spec.
<asac> cool
<asac> i think that would feel more natural than bailing out
<asac> kyrofa: https://github.com/asac/etherpad-lite-snap/commit/e68ad2fd5ab2d75034c5fc32466c32eb380a0417
<kyrofa> asac, happy new year to you as well!
<asac> that seems to work; entirely due to my lack of node knowledge
<asac> i have to dobule check but for now assume its an abandon
<kyrofa> asac, ah, interesting. And yeah, I can't help you on the node knowledge-- maybe sergiusens can? I think he made the plugin
<asac> i think its fine as above
<asac> and i wont need a new feature for node plugin this way
<asac> just have to test the runtime package :)
<kyrofa> asac, I'll go ahead and close them, then-- you can always reopen if you still want it :)
<asac> will do thanks!
<asac> if anyone wants to install http://people.canonical.com/~asac/etherpad-lite_master_amd64.snap and see if the pad is working on 9001 port after
<asac> that would be cool
<sergiusens> kyrofa, I am not a node expert, only looked at it for one day and came up with a simple hand written app and an existing popular one :-)
<asac> i only have my new "production" etherpad snappy instance
<sergiusens> asac, if you need node help, beowulf is the guy we want to talk to
<kyrofa> sergiusens, heh
<sergiusens> asac, is that snap built with snapcraft?
<asac> sergiusens: of course
<sergiusens> asac, nice!
<asac> with the branch above
<asac> https://github.com/asac/etherpad-lite-snap/
 * beowulf looks to see what kind of bus sergiusens has thrown him under
<asac> is legacy already though, because the real variant moved it into real tree
<asac> https://github.com/asac/etherpad-lite
<asac> e.g. in tree snapcraft
<asac> vs. out of tree snapcraft which is the -snap repo above
<asac> will hack on awesome config support today
<kyrofa> Haha, hey beowulf
<asac> https://github.com/asac/etherpad-lite/tree/snap-support/bin/snappy
<asac> thats the in-tree snapcraft
<beowulf> o/ kyrofa
<kyrofa> beowulf, it's been a while! What are you working on nowadays?
<asac> would love to consolidate the README to just have "snapcraft" for both 1.x and 2.x
<beowulf> kyrofa: i'd like to say i work on the store, but it's more like the store works on me
<kyrofa> beowulf, :D
<elopio> ping plars. Are you working today?
<plars> elopio: yes, Happy New Year :)
<plars> elopio: what's up?
<elopio> plars: same to you!
<elopio> plars: we are wondering about making an ubuntu-device-flash specific for 16.04. That would mean that you need xenial to build new images, and an older distro to generate 15.04 images.
<elopio> plars: could you get two agents working, one for new and one for old images?
<plars> elopio: no, it's not really possible to have two different agents coordinating the same device
<plars> elopio: it may be possible to somehow give a hint to how it's built, but it couldn't be on two different agents. Wouldn't it be possible to just have two different ubuntu-device-flash binaries? Why does the whole distro it's built on need to be different?
<elopio> plars: well, there are many options, I just thought two builders was the easiest. The u-d-f from xenial will build 16.04, the u-d-f from the other distros will build 15.04. If you can install both on the same agent, and tell me how to choose, I think that works too.
<plars> elopio: so it's just a different binary then, the whole distro you are building the image on does not need to be updated correct?
<plars> a different udf binary that is
<elopio> plars: afaik, yes. sergiusens: right?
<plars> elopio: do you know if there's any plan to add backward compatibility support?
<elopio> plars: that's what we want to avoid.
<plars> elopio: There are a few different approaches we could take, either way you'll definitely want to set up a new "image" in spi (since it is a new image)
<plars> elopio: for that image, you'll need to tell it to use the new udf binary to build the image, not the default one
<elopio> plars: sure. So what remains is to see if we can have both installed in the same machine.
<sergiusens> elopio, I don't know, that is a mvo question, but I am thinking that there is a dependency on using 16.04 for the new stuff
<plars> elopio: this will require some rethinking of how the agents work too I'm afraid... we never anticipated needing multiple versions of UDF, rather it was assumed that we want to carefully control the version of udf installed and make sure it's updated only when needed
<plars> elopio: so as a result, you specify the options to udf, rather than a script to just go get whatever version of udf you want (like you do with the tests) and run it
<plars> sergiusens: dependency on using 16.04? or a dependency on using 16.04 version of udf? And can that version also build 15.04 based images?
<elopio> plars: worst case scenario, we'll want the agents to be xenial. And fgimenez and I can run the 15.04 tests manually on our homemade labs :p
<noise][> elopio: wasn't there some talk about u-d-f becoming ubuntu-image + ubuntu-flash as 2 new separate binaries for 16.04?
<plars> elopio: it may not be so simple... what about others that may want to test 15.04 images?
<elopio> noise][: yup. We are planning the transition for that.
<plars> elopio: hopefully there's some transition path for all of this? Otherwise everything will just be broken for a while
<plars> elopio: of course, for bbb, I think we're still down because of that bug right?
<noise][> if that were the case, couldn't the existing 15.04 compat. u-d-f still be packaged for xenial alongside the 16.04 split ones?
<sergiusens> noise][, u-d-f can still be there in xenial; but the new ubuntu-image will only build with all snaps in mind
<elopio> noise][: maybe. So far I'm just asking the questions to see what are the requirements for the transition.
<elopio> I'm ok with a little downtime, if that speeds up the transition to all-snaps.
<elopio> Also we want to avoid having u-d-f generating 15.04 and 16.04 images.
<anpok> Jan  4 16:33:03 localhost systemd[1]: Cannot add dependency job for unit ubuntu-snappy.snapd.socket, ignoring: Unit ubuntu-snappy.snapd.socket failed to load: No such file or directory.
<anpok> ^ something I should care about?
<plars> elopio: so it's a whole new command - ubuntu-image, that will be used?
<plars> elopio: is there any documentation about this?
<elopio> plars: that's the final solution, yes. While that command is ready, we need to support building new images.
<plars> elopio: it would be a little weird to run these agent hosts on xenial I think, is there no plan to build a trusty version of the new ubuntu-image binary?
<plars> elopio: it's still not clear to me if the build host *must* run xenial, or if it just needs the new binary
<elopio> plars: we want to avoid that. We want to have people writing things for xenial to be using xenial.
<plars> elopio: but we're not developing anything on that system, just building an image
<plars> elopio: In either case, I think we'll need to extend the json you pass for spi to support a new field for using ubuntu-image vs. udf
<elopio> plars: again, right now I'm just asking for requirements. If we can completely ignore trusty, that would be easier for sure.
<plars> elopio: then once all 15.04 images are deprecated, we can just kill the previous stuff
<plars> elopio: I think in the near future though, we have to support both
<kyrofa> Chipaca, ping
<kyrofa> Chipaca, I'm having trouble merging my understanding of snappy with my understanding of this purge code :P
<kyrofa> Chipaca, specifically, if DataDirs returns multiple results, Purge seems to try and deactivate the snap more than once, resulting in an error after the first deactivation since it was already deactivated
<kyrofa> Chipaca, I thought that was a common scenario?
<kyrofa> Chipaca, trying to fix https://github.com/ubuntu-core/snappy/pull/264 by the way
<kyrofa> sergiusens, any chance you know what I'm talking about?
<Chipaca> kyrofa: sorry, hadn't brought irc up yet. am here now.
<Chipaca> reading backlog
<kyrofa> Chipaca, ah, no problem :)
<Chipaca> kyrofa: so, correct, `snappy remove` leaves data in place
<kyrofa> Chipaca, makes sense given how apt-get works
<kyrofa> Chipaca, or dpkg I guess
<Chipaca> kyrofa: yeap, which is why it's this way, but it is surprising if you don't come from apt, so it'll change for 16.04 to be less so
<Chipaca> kyrofa: oh dear, you are correct in that the use of datadirs is buggy :-(
<Chipaca> hmm
<kyrofa> Chipaca, oh *whew* that's better than me being incredibly confused :P
<Chipaca> :-)
<Chipaca> well, users might disagree with you on that =)
<kyrofa> Hahaha
<kyrofa> Chipaca, well I've got fixed (i.e. failing) tests anyway
<Chipaca> hmm
<kyrofa> Chipaca, I can make a PR to fix it before fixing #264
<Chipaca> on the other hand, maybe not
<Chipaca> ah! yes because it'll do deactivate in the second path
<Chipaca> bah humbug :-(
<Chipaca> kyrofa: +1
<Chipaca> kyrofa: things current code doesn't consider is a snap using both data dir and user data dir, and multiple users
<Chipaca> kyrofa: both would fail in similar ways
<kyrofa> Chipaca, ah, indeed
<Chipaca> kyrofa: in both cases moving deactivate to inside the first loop would solve it i think?
<kyrofa> Chipaca, what was the purpose of looping through the data dirs in the first place? Is there a use-case I'm missing?
<Chipaca> kyrofa: as opposed to what?
<kyrofa> Chipaca, ah, it was for multiple VERSIONS
<kyrofa> Chipaca, yes?
<Chipaca> ah, yes
<kyrofa> Chipaca, okay, I'll point you to the PR when I make it, if that's alright
<Chipaca> kyrofa: that would be very alright
<Chipaca> kyrofa: going back on this a bit, depending on the size of the change, maybe moving it to pkg/lightweight is better
<kyrofa> Chipaca, ah, I've never looked at that package
<Chipaca> kyrofa: they're both my fault, but datadirs is rather adhoc for the purge command, whereas lightweights is an iteration of the idea made more generally useful (only i didn't get around to removing datadirs)
<kyrofa> Chipaca, I don't think the change is large, but it sounds like a refactor that should happen at least eventually. Would you like me to do that here?
<Chipaca> kyrofa: as the whole purge command is going away, probably not worth it unless fixing datadirs is big
<kyrofa> Chipaca, I think not. But I'll keep it in mind just in case
 * Chipaca nods
<kyrofa> Chipaca, https://github.com/ubuntu-core/snappy/pull/283
<sergiusens> kyrofa, so should we do a 1.x today?
<kyrofa> sergiusens, we can, but this ld.so.conf.d feature will need to get into 1.x as well. I'm fine with waiting on it or releasing twice-- up to you
<kyrofa> sergiusens, but I know we've been wanting to get that out
<sergiusens> kyrofa, depends on how long it will take, I don't want to delay too much ;-)
<sergiusens> kyrofa, also, do the docs need more work or can they merge?
<kyrofa> sergiusens, agreed. How about we wait until tomorrow. If it's not done and looking good, we'll release
<kyrofa> sergiusens, ah, let me look them over again now
<sergiusens> kyrofa, yeah, releasing on wednesday is fine by me
<sergiusens> kyrofa, it would be nice to get the qml fix backported too
<kyrofa> sergiusens, agreed. I didn't see a response on that, so I can cherry pick
<sergiusens> kyrofa, is it CLA worthy? A single cherry requires squashing though iirc
<kyrofa> sergiusens, the qml fix guy did sign the CLA
<sergiusens> great
<brei> is it possible to define an unpack path for the tar_content.py plugin?
<kyrofa> sergiusens, the ld.so.conf idea may not actually work. At least from what I've seen so far, those files are placed in the .deb postinst, which doesn't seem to have an effect since we're really only unpacking them
<sergiusens> kyrofa, oh bummer
<kyrofa> sergiusens, yeah it's sad... it was such a good idea
<sergiusens> kyrofa, I can't think of another way that can reliably work for all cases
<kyrofa> sergiusens, I want all that stuff to be done in some sort of temporary lxc so the packages can actually be installed or something
<sergiusens> kyrofa, we should only focus on lxc for 2.x
<sergiusens> kyrofa, I'd say, send some sort of proposal to the devel list to see what comes
<kyrofa> sergiusens, alright... I guess I'll scrap this idea for 1.x then, unless you think walking /lib and /usr/lib and adding them all to LD_LIBRARY_PATH is an acceptable backup plan
<sergiusens> kyrofa, what about things in /opt' and such?
<sergiusens> it sort of gets some things working, but not all
<kyrofa> sergiusens, yeah, it doesn't work in all cases, but it works better than what we have now
<kyrofa> Exactly :P
<sergiusens> kyrofa, can we use rpath with relative paths?
<sergiusens> probably not a good solution either
<kyrofa> sergiusens, I think you can with some special keywords, but it's been a long time since I played with that
<kyrofa> sergiusens, yeah... I'm not a huge fan of either. Do we like one better than the other, or stick the .snap author with making wrappers every time they have a lib outside of the standard?
<sergiusens> kyrofa, the general consensus was that most of this is a project specific problem
<kyrofa> sergiusens, which makes a certain amount of sense, but also can mean a nightmare for someone just trying to package something with a lot of .deb dependencies
<sergiusens> kyrofa, personally, snapcraft magic voodoo should only be done when there's something we can hold on to
<kyrofa> sergiusens, yeah, you're right
<sergiusens> kyrofa, there's nothing reliable we can use here
<sergiusens> too bad those ld things are postinst :-(
<sergiusens> I thought they'd be config files at most
<kyrofa> sergiusens, agreed. Let's scrap the idea and revisit if we ever get some sort of contained build
<kyrofa> sergiusens, they are, but they're symlinked in
<sergiusens> kyrofa, is there any specific path that is already blocking something?
<kyrofa> sergiusens, I ran into it making a ROS .snap that uses opencv, which relies on opengl, which is in /usr/lib/arch/mesa
<sergiusens> kyrofa, for the case of mesa/egl/gl, right?
<kyrofa> sergiusens, right
<sergiusens> kyrofa, those are sufficiently common I guess to be able to track and check for
<kyrofa> sergiusens, I can at the very least add it to the catkin env(). Want me to add them to the overall runtime_env()?
<sergiusens> kyrofa, overall is fine
<sergiusens> kyrofa, I wonder if this is a pattern ''/etc/alternatives/.*_conf
<sergiusens> something we can check for
<kyrofa> sergiusens, in the case I'm looking at, the real .conf is distributed within /usr/lib/arch/mesa, and the postinst installs it with update-alternatives
<kyrofa> So yes.... but no
<kyrofa> Because in that case, even the etc/alternatives is a symlink
<sergiusens> kyrofa, ah/usr/lib/x86_64-linux-gnu/mesa-egl/ld.so.conf
<kyrofa> sergiusens, right
<kyrofa> Stupid chicken and egg problems...
<sergiusens> kyrofa, the other option is to search for ld.so.conf files
<sergiusens> but that can be dangerous too
<kyrofa> sergiusens, I assume that name is nonstandard
<sergiusens> kyrofa, exactly
<sergiusens> kyrofa, so maybe search for those specific egl ones and read them through
<sergiusens> kyrofa, we'll need to figure out what nvidia does as well
<sergiusens> gl is sort of an important topic
<sergiusens> ah, nvidia is mostly a runtime thing, disregard me
<kyrofa> sergiusens, alright, I can do that
<sergiusens> kyrofa, elopio is this just me with a new pep? http://paste.ubuntu.com/14404846/
<sergiusens> easy fix, just want to know how it got through :-)
#snappy 2016-01-05
<fgimenez> good morning
<JamesTait> Good morning all; happy Tuesday, and happy Golden Gate Bridge Day! ð
<Chipaca> stevebiscuit: mo'in!
<Chipaca> stevebiscuit: a question that suddenly came to me
<Chipaca> stevebiscuit: why is webdm fetching the icon?
<Chipaca> stevebiscuit: (as opposed to giving the url to the browser and letting it figure it out)
<stevebiscuit> Chipaca: hello!
<LefterisJP> hello
<stevebiscuit> Chipaca: the browser could handle things for uninstalled packages as the icon path would be something on the store
<LefterisJP> When using snappy-remote, to upload a testing snap to a snappy target is it supposed to give some form of progress bar? I would like to determine if my process is stuck or if it's actually doing something
<stevebiscuit> Chipaca: for installed packages, the path would be something like "/1.0/icons/myapp.myorigin/icon" which would be unaccessible
<Chipaca> hurr durr
<Chipaca> stevebiscuit: sorry i even asked :-)
<stevebiscuit> Chipaca: not to worry, I had to double check!
<LefterisJP> Hey all got a question. I am trying to deploy some test snapps from the snapcraft examples. The host is an Ubuntu 14.04 LTS and the snappy target is a Raspberry PI.
<LefterisJP> When I do snapcraft the resulting .snap file has amd64 in its name and when I try to deploy with snap-remote I get this error:
<LefterisJP> /tmp/webcam-webui_1_amd64.snap failed to install: package's supported architectures (amd64) is incompatible with this system (armhf)
<LefterisJP>  
<LefterisJP> How can I generate a .snap file for specific architecture?
<LefterisJP> hmmm is anyone seeing my messages/questions or is there a problem with my IRC client :-) ?
<Chipaca> LefterisJP: wait a bit for sergiusens or kyrofa to be around, i think
<Chipaca> stevebiscuit: how much do we care about somebody calling their icon something utf8-ish?
<kyrofa> Good morning
<stevebiscuit> Chipaca: good question, when a snap is built will it allow a utf8 filename?
<Chipaca> stevebiscuit: let's assume no, at least for now
<kyrofa> LefterisJP, I believe snapcraft needs to be run on the target arch
<stevebiscuit> Chipaca: grand, I'm happy to abdicate the responsibilty :)
<Chipaca> stevebiscuit: especially because what we do know is incorrect for utf8 filenames only on firefox
<Chipaca> which does blow my mind a little bit
<Chipaca> and not in a good way
<Chipaca> although that's 2013 info; might need updating
<LefterisJP> kyrofa: thanks for the reply. So I would have to install snapcraft in a Raspberry PI and then build the package there?
<kyrofa> LefterisJP, I believe so, assuming you're compiling (last I checked snapcraft didn't support cross-compiling)
<kyrofa> LefterisJP, or in an arhm qemu or something
<kyrofa> s/arhm/arm/
<sergiusens> good morning
<kyrofa> Morning sergiusens :)
<kyrofa> sergiusens, to double check: to build an armhf .snap with snapcraft, snapcraft needs to run on an arm, right?
<sergiusens> kyrofa, today, yes
<LefterisJP> or in general what is the recommended way to build for Raspberry PI target from an Ubuntu host.
<sergiusens> kyrofa, you are up early, or maybe I am up late :-P
<kyrofa> sergiusens, yeah a little. This time of year exercising in the morning sucks
<kyrofa> sergiusens, so I'm trying to shift my schedule back a little so I can exercise after work
<LefterisJP> sergiusens: You mentioned today yes. Is there any plans to add support for compiling for RaspPi (armhf) from an Ubuntu host in the future?
<sergiusens> LefterisJP, only ideas; probably mostly for things like go and node. Nothing stops you today from writing a custom plugin basing out of one of the existing ones that does just that for your needs though
<LefterisJP> I am still getting my bearings as to how Snappy Ubuntu works and how I can accomplish my goals.
<LefterisJP> Thanks I understand.
<sergiusens> LefterisJP, what are your goals?
<LefterisJP> I may bother you guys a bit more with extra "newbie" questions.
<kyrofa> LefterisJP, no bother!
<kyrofa> LefterisJP, but yeah, if you can explain what exactly you're looking to accomplish, we can probably point you in the easiest direction
<LefterisJP> I am working for slockit (http://slock.it/) and am trying to evaluate and see if it makes sense to use Snappy Ubuntu for our work. I am trying to gather as much info as possible to creating Snappy Frameworks as my final goal is to create an Ethereum(https://ethereum.org/) Snappy Framework which other Snappy apps can utilize.
<LefterisJP> At least for now for testing purposes I use a Raspberry Pi as my testing target environment
<kyrofa> LefterisJP, for evaluation purposes perhaps it would be easier to use an amd64 virtual machine running snappy?
<kyrofa> LefterisJP, a qemu VM is just going to be slow is all
<sergiusens> kyrofa, btw are you on xenial?
<kyrofa> (an arm one anyway)
<sergiusens> kyrofa, I am seeing this with the tests http://paste.ubuntu.com/14410381/
<sergiusens> but it does not happen on travis
<kyrofa> sergiusens, no I'm on trusty :P
<kyrofa> sergiusens, huh, that doesn't look good
<kyrofa> Looks like the mock lib changed... ?
<sergiusens> kyrofa, indeed
<kyrofa> grr... breaking api...
<kyrofa> sergiusens, I'm not sure how to fix that in a backward-compatible way
<sergiusens> kyrofa, I'll look into it
<kyrofa> sergiusens, alright let me know. I can fire up a xenial lxc in no time
<sergiusens> kyrofa, I can do it with more code
<sergiusens> kyrofa, the problem is the error 'helper' message when the assertion fails
<kyrofa> sergiusens, oh. Did they just remove support for it?
<sergiusens> kyrofa, I don't think it was removed entirely as I use it too and those don't fail (Equal), only in the called one it seems
<kyrofa> sergiusens, worst case we can just remove the helper message and that will work on all versions
 * sergiusens checks the docs
<sergiusens> kyrofa, I;ll leave the message, don't worry ;-)
<sergiusens> easy to fix
<sergiusens> kyrofa, so even worse, nothing changed; assert_not_called only exists in 3.5 and trusty uses 3.4 so you were tricked by the mock's consumtion of anything it was called with :-P
<kyrofa> sergiusens, oh no
<kyrofa> sergiusens, that's _terrible_
<kyrofa> sergiusens, oh, so embarrassing :P
<kyrofa> sergiusens, easy fix though
<sergiusens> kyrofa, yeah, done already; taking more time to think of a commit message than anything else :-
<sergiusens> :-P
<kyrofa> sergiusens, just using .called?
<sergiusens> kyrofa, yeah
<kyrofa> sergiusens, great, thanks for mopping up behind me
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/200
<LefterisJP> So I have a bit more general question. Once you make an app or Framework for Ubuntu core it does not mean that it will run on every device running Ubuntu core, right? It means only for devices having the same architecture? Then to support each device you would have to generate a .snap for that device's architecture separately?
<kyrofa> LefterisJP, you have the right idea, although it's possible to create a .snap for multiple architectures if your project supports such a thing. An example might be a series of shell scripts, or something you've already compiled for other architectures
<kyrofa> LefterisJP, keep in mind that you don't HAVE to have snapcraft build your snap for you. In current releases you can just snappify a directory with snappy build (future releases moves that functionality into snapcraft, but you can still just snappify a directory)
<LefterisJP> interesting, where can I find more information for multiple architectures projects? I mean I saw some projects adding an architectures list in the yaml file, like: `architecture: [amd64, armhf]` but how can you specify the rules as to how to build each architecture.
<kyrofa> LefterisJP, that's what I'm saying-- if you want snapcraft to do the building for you, you're going to be stuck with the host arch
<LefterisJP> hmm okay
<kyrofa> LefterisJP, however, let's pretend your project was written in go, or C++. Let's say you built it yourself for multiple architectures and ended up with a binary for each
<kyrofa> Then you name them according to their arch: project_amd64, project_armhf, etc
<kyrofa> LefterisJP, then you make a shell script that looks at the current arch, and launches the right onw
<kyrofa> one*
<kyrofa> LefterisJP, now that shell script is your snappy binary
<kyrofa> LefterisJP, and voila, you support multiple architectures in the same .snap
<kyrofa> LefterisJP, and you don't need snapcraft to build it-- just setup the meta/package.yaml etc. accordingly and run snappy build
<LefterisJP> kyrofa: Thank you for your help
<LefterisJP> Is there any blog post or tutorial or something I can use for reference for this?
<LefterisJP> I found this to be useful: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/
<kyrofa> LefterisJP, of course, it's why we're here :) . And yeah, that sounds kinda like what I described, nice
<kyrofa> LefterisJP, and we are indeed trying to make that better in snapcraft. But supporting cross-compiling for all the supported possibilities in a general way is a difficult problem to solve
<LefterisJP> yeah I understand. I had seen a presentation by Maarten Ectors in (Ethereum) Devcon1 about Ubuntu Core and I had understood that you had somehow had a magical way to cross-compile for everything already. I know it's a hard problem to solve, but who knows, with enough research and work many architectures may be supported.
<LefterisJP> Are these snapcraft pluging used for cross-compiling? https://github.com/ubuntu-core/snapcraft/tree/master/snapcraft/plugins
<sergiusens> LefterisJP, no, those are just used for building natively
<sergiusens> you can override them and support a specific target if you want
<LefterisJP> I see. Then just out of curiosity in which part of the system would any cross-compiling capability be built (in the future as you said)
<sergiusens> LefterisJP, in the plugin itself
<sergiusens> as each plugin (tech) uses a different mechanism to support this
<kyrofa> LefterisJP, right, cross-compiling C++ is different than cross-compiling Go, for example
<LefterisJP> yeah I know :(
<LefterisJP> 2 clients exist for Ethereum, one in Go and one in C++. I like C++ a lot myself but well ... cross-compiling it for different architectures is painful
<kyrofa> LefterisJP, yeah that's my favorite
<kyrofa> I'm afraid snapcraft isn't going to be the C++ cross compiling silver bullet though, sorry :( . At least... not yet ;)
<kyrofa> LefterisJP, what build system does the C++ client use?
<LefterisJP> cmake
<kyrofa> LefterisJP, well at least you have that-- cross compiling is a little easier with a good build system obviously
 * kyrofa 's day always improves when he thinks he's out of coffee... and then discovers there's actually a little bit left
<kyrofa> sergiusens, standup?
<sergiusens> oops
<LefterisJP> where you guys located at? Europe or US or both?
<enoch85> ping kyrofa
<kyrofa> Hey enoch85 :)
<enoch85> kyrofa, so I installed Ubuntu Snappy once again, and didn't touch anything else. what would be the next step?
<enoch85> kyrofa, do I build the ownCloud.snap seperatly from the system, and can this be done inside a VM?
<enoch85> kyrofa, can I use my scripts in the .snap or do I have to build it from schratch?
<kyrofa> enoch85, in order to develop the .snap, I'd ignore the rpi2 for now and do this on your dev machine
<enoch85> kyrofa, ok, where do I begin?
<kyrofa> enoch85, well, assuming you're running Ubuntu on your dev machine. Are you?
<enoch85> yes
<kyrofa> enoch85, which version?
<enoch85> on my laptop I have Ubuntu Mate 15.10, and when I develop scripts and such I usually do this on a Ubuntu Server VM
<enoch85> kyrofa, sorry forgot to mention you...
<kyrofa> Excellent. First of all, get snapcraft setup (https://developer.ubuntu.com/en/snappy/build-apps/get-started/)
<kyrofa> enoch85, haha, no problem
<kyrofa> enoch85, let me fire up a 15.10 lxc real quick so I can walk through with you
<enoch85> kyrofa, hmm, so I can make a standard VM and use snapcraft to compile it onto snappy? that would be awesome!
<enoch85> kyrofa, ok!
<kyrofa> enoch85, indeed
<enoch85> kyrofa, yeah, and I will create a dev envirroment I think... to keep things seperated.
<enoch85> kyrofa, which one do you recomend?
<enoch85> kyrofa, server or desktop?
<kyrofa> enoch85, what virtualization tech are you using?
<enoch85> kyrofa, VMware Workstation
<kyrofa> enoch85, short answer is server-- you won't need a GUI
<kyrofa> enoch85, but it won't hurt anything to have a gui either
<sergiusens> kyrofa, this was fixed, right? https://bugs.launchpad.net/snapcraft/+bug/1524374
<ubottu> Launchpad bug 1524374 in Snapcraft "Snap fails to build with "Bad Variable Name"" [Undecided,New]
<enoch85> kyrofa, ok, but will it end up in alot of files all over the place, or is it clean in case I want to remove it later, in that case I don't need to create a seperate VM
<enoch85> enoch85, I can just use my laptop as dev machine
<kyrofa> sergiusens, yes I believe so-- let me verify
<kyrofa> enoch85, the files it creates are pretty localized
<kyrofa> sergiusens, yes: https://github.com/ubuntu-core/snapcraft/pull/161
<kyrofa> enoch85, assuming you're talking about the process of building a .snap
<enoch85> kyrofa, so basically purge snappy-tools when I'm done?
<sergiusens> kyrofa, I can't remember when we did the split; I'll mark it fixed commited for trunk but leave it open for 1.x
<enoch85> kyrofa, yes, that as well
<kyrofa> sergiusens, I think it was after, so that sounds good
<kyrofa> enoch85, ah, yeah. And remove the PPA
<kyrofa> enoch85, of course if you're worried, virtualize it (I do)
<enoch85> kyrofa, ok, then let's go
<enoch85> kyrofa, naah, I need to reformat my latop soon anyway, just another reason to do it if I choose not to proceed ;)
<kyrofa> enoch85, hahaha, okay
<kyrofa> enoch85, give me one sec, setting up...
<enoch85> kyrofa, ok cool :)
<enoch85> kyrofa, oh, nice progress bar when installing the tools
<enoch85> kyrofa, can I get that in the server env as well?
<kyrofa> enoch85, heh, I'm not sure what you're referring to
<enoch85> kyrofa, I got a progress bar when I installed the tools, it appeard in the bottom line
<enoch85> kyrofa, just wondering if I can script that in a regular apt-get upgrade command on a server for instance
<kyrofa> enoch85, via apt-get? Yeah I'd assume that would be the same regardless of desktop or server
<enoch85> kyrofa,
<enoch85> cool
<enoch85> kyrofa, anyway, on page 2 now in the guide
<enoch85> kyrofa, snapcraft tutorial
<kyrofa> enoch85, right, so, snapcraft is a tool that will build .snaps for you if you tell it your dependencies, etc.
<enoch85> kyrofa, could I use ondrejs PPA for PHP 7 for instance?
<enoch85> kyrofa, btw a completley doifferent question: will PHP 7 be optional in UBuntu 16.04?
<kyrofa> enoch85, yes, but you'll need to write a custom snapcraft plugin for the nonstandard repo. And honestly I'm not sure regarding 16.04
<kyrofa> enoch85, is PHP7 a requirement for owncloud nowadays?
<enoch85> kyrofa, ok, so what I want is: LAMP with PHP 7 + ownCloud + some scripts that will be included in the snap at boot for the ownCloud. Basically, I want the same as I have today: https://en0ch.se/index.php/s/i3csGfYlpivkFvh
<enoch85> kyrofa, not a requrement, but nice to have. speed things up quite a bit.
<enoch85> kyrofa, please download and try if you have the time
<LefterisJP> I am playing around with deploying a simple "Hello World" shell script snappy in a Pi and after succesfully deploying it with snappy-remote when I try to run it inside the Pi I get: `appname Test-snap-echo.sideload not allowed`
<LefterisJP>  
<LefterisJP> what am I doing wrong?
<kyrofa> enoch85, alright. That sounds doable. I've not put together a php .snap before, so we may want to start with the default repos, just for simplicity for now
<enoch85> kyrofa, yeah ok, and I (we) can develop it further later on
<enoch85> :)
<kyrofa> enoch85, exactly
<kyrofa> sergiusens, hey on wily, snappy-tools doesn't seem to include snapcraft?
<kyrofa> So enoch85 you'll need to `apt-get install snapcraft` as well
<enoch85> kyrofa, on it
<sergiusens> kyrofa, I'll add a note to check
<enoch85> kyrofa, done
<kyrofa> sergiusens, just makes the docs inconsistent is all
<kyrofa> Alright enoch85, let's first try to just make a .snap that has apache running
<enoch85> kyrofa, ok
<enoch85> kyrofa, LAMP**
<enoch85> kyrofa, wouldn't it be possible to make a LAMP snap?
<kyrofa> enoch85, haha, we're getting there
<enoch85> kyrofa, ok
<enoch85> :)
<kyrofa> enoch85, but all the .snaps I've made so far are a little simpler. So we're going to learn together. Sound okay?
<enoch85> kyrofa, very good. win-win
<kyrofa> enoch85, I figure once we get a .snap with apache, we'll add PHP, then mysql, then owncloud
<enoch85> kyrofa, into one snap, or seperate?
<kyrofa> enoch85, into one
<enoch85> kyrofa, ok cool
<kyrofa> enoch85, alright, make sure you're here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<enoch85> kyrofa, yes
<kyrofa> enoch85, scroll down to the "Snapcraft Recipe"
<enoch85> kyrofa, yes
<enoch85> kyrofa, mkdir apache?
<kyrofa> enoch85, so we use a file named `snapcraft.yaml` to instruct snapcraft on how to assemble our .snap
<kyrofa> enoch85, make a folder for the overall snap. I'm making a ~/src/owncloud-snap folder
<enoch85> kyrofa, ok
<kyrofa> enoch85,  In that folder, create a snapcraft.yaml file
<enoch85> kyrofa, touch i suppose?
<enoch85> or just copy the text and add my things instead?
<kyrofa> enoch85, or vi or some other editor, no matter. Right, take the text from the tutorial and alter to fit
<kyrofa> enoch85, just the name through the icon
<kyrofa> enoch85, generic metadata
<kyrofa> enoch85, ooo, actually just run snapcraft init, haha
<kyrofa> Get in that folder and run snapcraft init. Then alter the snapcraft.yaml to fit
<kyrofa> enoch85, if I actually read the tutorial...
<enoch85> kyrofa, haha ok
<enoch85> sec
<enoch85> kyrofa, sorry for noise:
<enoch85> name: owncloud-server
<enoch85> version: 1
<enoch85> vendor: Daniel Hansson <daniel@techandme.se>
<enoch85> summary: ownCloud Server Snap
<enoch85> description: ownCloud server is you self-hosted cloud
<enoch85> icon: icon.png
<enoch85> something like that?
<kyrofa> enoch85, sure, that works fine
<LefterisJP> guys ping: `appname Test-snap-echo.sideload not allowed` when trying to run a binary of an app I installed via snappy-remote. Why would I get this?
<kyrofa> enoch85, make sure you actually have that icon. I use a .svg simply containing `<svg />` or something
<kyrofa> enoch85, eventually we can actually use the owncloud icon
<enoch85> kyrofa, was just about to ask... don't have an icon
<enoch85> can copy one from ownCloud though
<kyrofa> enoch85, that works
<enoch85> kyrofa, yes
<enoch85> sec
<kyrofa> LefterisJP, is the shell script executable?
<enoch85> kyrofa, saved that inside the owncloud-snap folder (my dev folder)
<enoch85> kyrofa, togehter with the icon
<kyrofa> enoch85, owncloud? That's fine, we won't use it just yet but it won't hurt anything. 8.2.2?
<LefterisJP> kyrofa: yes
<enoch85> kyrofa, yes, latest
<kyrofa> LefterisJP, out of curiosity (not sure it will fix anything) try changing the name to something without hyphens and try again
<kyrofa> enoch85, alright, so now let's tell snapcraft that we want apache
<enoch85> kyrofa, exiteing!
<enoch85> kyrofa, exciting!*
<LefterisJP> kyrofa: Will do. Does that mean I need to purge it from the snappy target too? Also, my package.yaml calls the executable like:
<LefterisJP>    exec: ./bin/testecho.sh
<LefterisJP> do I need to put sh in front? The script does have the shebang on the top
<kyrofa> LefterisJP, no as long as the shebang is valid you should be good. And no, when you're sideloading you can load it right over the top
<kyrofa> enoch85, so we're going to specify parts, like further in the tutorial
<enoch85> kyrofa, i'm with you
<enoch85> kyrofa, just a file called parts?
<kyrofa> enoch85, no, no files, this is all in the yaml
<enoch85> kyrofa, sorry, add it to .yaml
<kyrofa> enoch85, right, you got it
<kyrofa> enoch85, so every .snap is made up of (potentially many) parts
<enoch85> kyrofa, cool
<enoch85> kyrofa, what repos can I use here?
<kyrofa> enoch85, in snapcraft, each part is assembled by one of its many plugins. Part of the process we're going through may very well end up making a php plugin
<kyrofa> (since snapcraft doesn't have one)
<enoch85> kyrofa, ok. is it ok to post here or do you want a pastebin instead?
<enoch85> kyrofa, maybe PM?
<kyrofa> enoch85, pastebin is less noisy and easier to read. Perhaps PM would quiet the list down a bit :)
<enoch85> kyrofa, like that?
<enoch85> kyrofa, what should be instead of plugin and source i.e?
<kyrofa> enoch85, let's take this PM
<LefterisJP> I have a question about this blogpost: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/
<LefterisJP> He has a snappy directory with bin/ARCH1 and bin/ARCH2 and has 2 executables under it
<LefterisJP> how does snappy build know which one to put in what architecture? Cause I tried to do something similar and it ended up having bin/ARCH1 and bin/ARCH2 under the Raspberry PI where I only wanted to have the corresponding Architecture subtree there.
<kyrofa> dholbach, https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/ doesn't show sublists
<kyrofa> LefterisJP, that's the thing-- it puts both
<kyrofa> LefterisJP, that's why you need that third item-- the shell script that determines which one to run
<dholbach> kyrofa: ok, looking into it
<LefterisJP> I could do that, but then how does (in the blogpost) the package.yaml point to the same executable?
<kyrofa> LefterisJP, the executable is the shell script
<kyrofa> LefterisJP, which will run on all archs
<kyrofa> LefterisJP, then launch the corresponding binary
<dholbach> kyrofa: I filed https://bugs.launchpad.net/developer-ubuntu-com/+bug/1531200 to track it
<ubottu> Launchpad bug 1531200 in Ubuntu Developer Portal "Snappy/Snapcraft docs don't show sublists" [Undecided,New]
<kyrofa> dholbach, thank you! Yeah, I'm just pointing people to github for now
<dholbach> kyrofa: we're getting closer to finally having the markdown importer working and deployed, from there on it should be a lot less tedious and we started adding tests as well
<kyrofa> dholbach, awesome!
<LefterisJP> kyrofa: I understand what you say, but in the blog post he seems to produce a binary called "port-listener" from go-build and then another one with the same name through go-build cross compiling for ARM. And he only puts them in different bin/ directories under the main snappy/ dir.
<LefterisJP> kyrofa: And his package.yaml does not seem to contain a shell script
<LefterisJP> services:
<LefterisJP>  - name: port-listener
<LefterisJP>    description: "template Go snappy project"
<LefterisJP>    start: ./bin/port-listener
<LefterisJP>    caps:
<LefterisJP>      - networking
<LefterisJP>      - network-service
<LefterisJP> Unless this bin/port-listener is actually a selection shell script
<kyrofa> LefterisJP, exactly!
<kyrofa> LefterisJP, your last point is spot on
<kyrofa> LefterisJP, and it in turn runs the binary that it knows will run on the current arch
<LefterisJP> kyrofa: I see. Quite strange that he does not mention this in the blog post (https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/)
<kyrofa> LefterisJP, "The run file plays a little trick. It invokes the correct binary file depending on the currently running architecture. This allows you to package one snap that works on my architectures. "
<LefterisJP> kyrofa: My bad
<LefterisJP> kyrofa: Missed that line totally
<LefterisJP> kyrofa: Okay now I found it in the bzr repo too. Got the shell file. This will be really helpful. Thanks.
<kyrofa> LefterisJP, no problem!
<renat> Hi! It's Renat from Screenly. I wanted to contact @mectors about creating a custom store for screenly snaps. It is set up by store.id setting in YAML file for the  OEM snap. Is there any information about that? Thanks.
<renat> Hi, kyrofa!
<kyrofa> renat, hey there!
<LefterisJP> kyrofa: But wouldn't it be smarter if the binaries were only uploaded to the device for which they were made, and having package.yaml determine which binary goes to which architecture? And then snappy-remote or snappy-install can simply deny installation for incompatible architectures. Because as it stands right now we will end up having binaries inside the /apps/bin/ of a snappy app that we would never use. I am wondering how come
<LefterisJP> things ended up as they are now
<renat> kyrofa, can you help me please? I want to contact mectors, but cannot see his nick in users list here. Question about custom store for Screenly becoming more urgent, and I want to resolve it until it's too late.
<kyrofa> sergiusens, do you know anything about renat's question?
<kyrofa> renat, I'm afraid I've not dealt with that, but I'd be curious about the answer as well. We'll see if we can find someone else to help you :)
<kyrofa> sergiusens, or know who to talk to about it, anyway. I suspect mectors is not actually the right person
<sergiusens> renat, do you have his email?
<sergiusens> renat, kyrofa I think you want to talk to beuno
<renat> sergiusens, kyrofa, thanks.
<renat> sergiusens, how can I contact beuno?
<kyrofa> sergiusens, yeah I wondered. renat have you tried the snappy mailing list?
<sergiusens> renat, I just pinged beuno to join, not sure why he isn't here
<renat> sergiusens, thanks!
<sergiusens> Chipaca, hey, does license agreement require a license version or vice versa?
<Chipaca> sergiusens: no
<sergiusens> Chipaca, either of those require a license though? And if not, it seems sane if I require those keys to have a license defined, right?
<Chipaca> sergiusens: if package version A has require-license-agreement, and B has require-license-agreement, and A is installed, and A and B both have the same license version, then the user isn't asked again
<Chipaca> on upgrade i mean
<Chipaca> sergiusens: if you require a license agreement, a license file is required and must be nonempty
<Chipaca> sergiusens: i'm not sure i'm answering your question =)
<enoch85> does anyone know the user and pass to the snappy OVA image?
<enoch85> found here: https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/
<ogra_> same as everywhere :)
<ogra_> ubuntu/ubuntu by default
<sergiusens> Chipaca, perfectly; it was obvious, but was making sure :-)
<sergiusens> Chipaca, but you can have a license, require an agreement and not version it, meaning it is a one time thing or until you version it
<enoch85> ogra_, tried ubuntu ubuntu, but no. :/
<Chipaca> sergiusens: yes. And you can have a license and a version and not require an agreement
<ogra_> enoch85, then something must be broken ... the rootfs is the same everywhere for snappy
<Chipaca> sergiusens: and you can have a license version and no license and not require an agreement, and that probably doesn't complain even =)
<enoch85> http://i.imgur.com/UPPwifU.png ogra_
<enoch85> ogra_, and I get: intel_rapl: no valid rapl domains found in package 0
<enoch85> maybe that's the cause?
<ogra_> i doubt that
<sergiusens> Chipaca, that last one seems more like a bug though ;-)
<sergiusens> Chipaca, I'm making it complain in snapcraft fwiw
<enoch85> ogra_, any clue?
<ogra_> enoch85, not from that screenshot ... perhaps cloud-init went south or something ... check your boot loag (i'm officially not here btw :) )
<ogra_> *log
<enoch85> ogra_, ok, thanks :)
<plars> elopio: on x86, I'm seeing a message from udf with rolling/edge: "expected 5 partitons but found 0" but it exits 0. I'm assuming this was a silent failure?
<plars> elopio: and on a different system, I get 'error while executing external command kpartx -ds /tmp/x86.img: device-mapper: remove ioctl on loop1p5 failed: Device or resource busy'
#snappy 2016-01-06
<dholbach> good morning
<stevebiscuit> Chipaca, mvo: if I build the snapd binary, is there an easy way of getting it running on a snappy VM?
<mvo> stevebiscuit: yes, for some definition of "easy". Chipaca has the details, it should be a matter of just building and scp to the snappy system $HOME and starting it here. However I have not done this yet, I can give it a quick try. you could even do the development on snappy itself from the classic environment. let me quickly try if my suggestion actually works
<stevebiscuit> mvo: I've tried killing off the running snapd and then running the scp'd one but it gives me "error: daemon does not handle 0 listeners right now, just one" which is do with systemd from my reading of the code
<mvo> stevebiscuit: ok, this is actually slightly more complicated, I get the same. here is what you need to do:
<mvo> stevebiscuit: sudo systemctl stop ubuntu-snappy.snapd.service ubuntu-snappy.snapd.socket
<mvo> stevebiscuit: sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd
<stevebiscuit> mvo: that works a treat, cheers!
<mvo> stevebiscuit: great! https://github.com/ubuntu-core/snappy/pull/291 so that this is easier to find in the future
<liuxg> Chipaca, ping
<asac> sergiusens: is it right that its odd that if i have a typo in snapcraft python code like referencing an non existing var
<asac> that it just bails with the error but no indication of line number etc.?
<asac> or is that normal for python?
 * asac feels like being in debugging stoneage when hacking on snapcraft etc.
<sergiusens> asac, it is not normal, just user friendly, for devel I recommend you change one thing
<sergiusens> asac, either remove try/except here or change sys.exit to raise e
<sergiusens> asac, I'll add an envvar there so you can devel easier
<sergiusens> Chipaca, hey, mind doing a review?
<Chipaca> sergiusens: REVIEWS FOR THE REVIEW GOD
<Chipaca> sergiusens: but she's busy, so I guess I'll do them instead
<sergiusens> Chipaca, https://github.com/ubuntu-core/snapcraft/pull/201
<sergiusens> Chipaca, just the semantics for license keywords if you don't want to check code
<Chipaca> sergiusens: reviewed
<Chipaca> sergiusens: you dun good
<asac> sergiusens: user friendly?
<sergiusens> asac, end user; someone not introducing new code but using the tool
<sergiusens> Chipaca, thanks
<asac> sergiusens: ok, just couldnt see how not printing line number faults on error could help someone
<asac> i would think best case someone using tool wont see errors
<asac> but if he does he probably would want to have something useful to bug report
<asac> but maybe i am missing some error cases where this would help
<asac> sergiusens: anyway, env paired with entry in hacking.md etc. would be good (not that i read hacking.md, but at least i would have done that next i think)
<asac> sergiusens: thoughts on https://gist.github.com/asac/d66ecdbb286e4a60269e
<asac> thanks
<asac> (note its not complete=
<asac> not sure about run_raw... but i couldnt figure better way
<asac> mvo: are there changes to snappy config protocol coming on master branch or do we stick to current approach for now?
<brei> when I build a snap with snapcraft, not every file from the stage is copied to the snap folder. What are the filter criterias?
<asac> kickinz1: so downloading i386 vs. amd64 docker-latest from https://docs.docker.com/engine/installation/binaries/ ... i see that the i386 is 7.X M and the amd64 is like 30M+ ?
<asac> does that make sense?
<kickinz1> asac: for me seems like i386 is only client side docker.
<asac> kickinz1: like http://paste.ubuntu.com/14419442/
<asac> 1.6 is 15M... latest is 30M
<asac> even for 64
 * asac scratches head
<kickinz1> asac, there has been a lot of changes between 1.6 and 1.8-1.9 series (with arch support breakage).
<asac> kickinz1: how do you check if a docker binary has just client?
<kickinz1> You can try running it as a daemon, 'docker daemon' or 'docker -d' for prev 1.8
<kickinz1> asac ^
<sergiusens> asac, looks good, just not so sure about raw_config
<asac> kickinz1: i moved to a different machien... do you have the link again :)?
<asac> err
<asac> sergiusens: ^
<asac> sorry kickinz1
<asac> thank kickinz1 ... seems that latest is busted i guess upstream
<kickinz1> asac:  https://docs.docker.com/engine/installation/binaries/
<asac> right wrong ping :)
<kickinz1> asac: docker just support amd64 arch, so all other arches are client only iirc
<asac> sergiusens: nevermind... found that github has history for me
<asac> sergiusens: there is no raw_config ... just run_raw
<asac> sergiusens: what i need to run is "yes" "" | make oldconfig
<sergiusens> asac, good, because I have no idea what you were talking about wrt docker
<kickinz1> asac, there are patches and an un-upstream way to build it that allow other arches to work.
<asac> i couldnt figure how to do that with existing run methods
<asac> sergiusens: ignore docker :)
<asac> sergiusens: just the gist
<sergiusens> asac, yeah, run_raw is what I meant, sorry
<asac> sergiusens: yeah. so no ideas how to do it different?  e.g. good?
 * asac finishes the patch and then thinks about tests
<sergiusens> asac, I'm mostly sure you can implement run with what you have in run_raw
<sergiusens> asac, btw https://gist.github.com/asac/d66ecdbb286e4a60269e#file-kbuild-diff-L56 your assert message is wrong here
<sergiusens> asac, but I don't mind either way, this whole run thing is waiting for a refactor since forever
<sergiusens> asac, the only thing missing in your diff are unit tests ;-)
<asac> right. have to add one more featuure to allow starting with the kconfigfile instead of defconfig
<asac> then will think about tests
<asac> but i am very illeterate onthat,, so might need hand holding
<asac> sergiusens: you think using an argument raw=False for run in __init__.py (avoiding a dupe in that file) would be good?
<asac> oir should i rather just leave it to the refactor master?
<kyrofa> Good morning
<asac> hey kyrofa
<kyrofa> Good morning again now that my internet is working
<sergiusens> asac, I mean, the `exec $*` in regular run might as well be what you have in raw
<sergiusens> kyrofa, ah, that explains the absence :-P
<sergiusens> good morning
<kyrofa> sergiusens, hey :P
<kyrofa> Gahhh sergiusens the yaml tests sent me for a loop this morning
<kyrofa> patcher = unittest.mock.patch('os.path.exists')
<kyrofa>         mock_wrap_exe = patcher.start()
<kyrofa>         mock_wrap_exe.return_value = True
<kyrofa> ^^ didn't see that
<kyrofa> sergiusens, I was starting to add debug prints to /usr/lib/python3.4/os.py :P
<sergiusens> kyrofa, yeah, patching can do this sometimes
<asac> sergiusens: right. i kind of sensed there is something in here... guess having exec nicely takes over the process and hides the parent shell hack for env
<asac> sergiusens: on that, do you know why the initial code does not set the env through the python call_
<asac> ?
<asac> not complaining for my case, just wondered if python doesnt have easy way to just pump env to the command it runs
<asac> bah... out of all the skills i have, i seem to be not smart enough to login to my local all snaps kvm using ssh -p XXXX ubuntu@localhost
<sergiusens> asac, I inherited like this; I don't know
<asac> let me reboot to latest .... maybe the dev 17 image is buggy on this, but i thought i managed to log in at some point
<sergiusens> asac, all the env management still needs some work so actually use keys instead of a list
<asac> sergiusens: does ssh to all snap kvm work for you?
<asac> interestingly all host keys are 0 size... guess i know what might have happened ... i killed the first boot when it generated stuff
 * asac redoes image
<asac> do we crewate those keys using cloud-init still?
 * asac wonders where to file bug in case this is the prob
<sergiusens> asac, yes, still with cloud-init
<asac> jdstrand: * adjust program to not use 'setgid' until per-snap user/groups are supported
<asac> jdstrand: could we reference a tracking bug for that feature in the comment (though very nice guidance here)
<asac> thats with snappy-debug.security scanlog
<jdstrand> asac: sure
<sergiusens> elopio, bumper https://github.com/ubuntu-core/snapcraft/pull/201
<asac> jdstrand: do you remember why busybox did use setgid on everything?
<enoch85> kyrofa, hey! shall we continue? :)
<asac> i remember we looked at the code a while back
<asac> for the hello-world.sh thingy
<kyrofa> Hey enoch85 :) . I have a meeting here in a minute, let me ping you
<enoch85> kyrofa, okay! :)
 * asac tries to disable SUID
<kyrofa> sergiusens, elopio sorry guys... internet is flaking
<sergiusens> kyrofa, we can wait
<asac> jdstrand: nevermind... i fixed a config in build system to not support suid of bb and now it works \o/
<jdstrand> asac: I don't, however bash can be used for hello-world.sh these days
<jdstrand> (just fyi)
<asac> yeah
<asac> seems bizbox has a feature called CONFIG_FEATURE_SUID... i disabled it and now its fun
<asac> sergiusens: is stage a no-op these days? seems that stage happens for each part during build?
<asac> sergiusens: is there a wildcard feature for binaries? i would like to add all that is in stage/bin/ as binaries without having to keep them in sync
<sergiusens> asac, you can use directories in your 'snap' directive
<sergiusens> asac, stage is more complex in 2.x; it takes into account the dependencies (1.x is broken in this regard)
<sergiusens> jdstrand, hey; is there a reason why I can't have spaces in my start keyword?
<sergiusens> jdstrand, without allowing that I have to resort to things like this https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/snapcraft.yaml#L9
<sergiusens> jdstrand, with a wrapper script that only does https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/shout.sh
<jdstrand> sergiusens: are you saying you want to put the contents of the shout.sh script in 'start' in the yaml?
<sergiusens> jdstrand, I want to be able to write 'start: shout --home $SNAP_APP_DATA_PATH'
<jdstrand> right
<sergiusens> jdstrand, ah, '$' is also not allowed
<jdstrand> so, 'start' is not used with the APP_ID since in this example the app id is shout_server_0.52.0
<jdstrand> so, I think this is to make sure that the systemd file is sane
<sergiusens> jdstrand, I don't follow
<jdstrand> what is in 'start' ends up in ExecStart in the systemd service
<sergiusens> jdstrand, correct, and I'm using SNAP_APP_DATA_PATH, no APP_ID
<sergiusens> not*
<jdstrand> we need to be careful with ExecStart, since a crafted 'start' could run commands outside of confinement
<sergiusens> jdstrand, so basically if I need switches or envvars I need to resort to wrapper scripts?
<jdstrand> if we make the review tools and snappy not allow ';', perhaps we could allow arguments to start
<jdstrand> I wasn't talking about env vars
<sergiusens> jdstrand, that sounds reasonable
<jdstrand> I would assume that if the unit properly set SNAP_APP_DATA_PATH then whatever was in ExecStart would see it
<sergiusens> jdstrand, just asking since it is not allowed, spaces either iirc
<sergiusens> if it is just because of a ; then I hope we can just block offenders
<sergiusens> jdstrand, no rush though
<jdstrand> if someone were to expand this in the manner you would like, we would have to proceed very carefully, because that would be an avenue of attack for a malicious app developer
<sergiusens> jdstrand, yeah, that's why I say no rush :-)
<jdstrand> historically, I feel like 'start' was used as part of the app id. ie, if 'name' was not specified or something
<jdstrand> if start is not part of the app id ever any more, then allowing arguments would seem to make sense (if done carefully)
<sergiusens> jdstrand, so appids are now uuids, right?
<sergiusens> Chipaca, ? ^
<sergiusens> well """now""" (many air quotes)
<jdstrand> sergiusens: no, not in my current understanding. the app id is today as always. what we are moving to is uuid_appname_revision
<jdstrand> sergiusens: where appname the 'name' in the yaml
<jdstrand> for a service/binary
<jdstrand> so pkgname goes to uuid and version goes to revision
<jdstrand> but appname stays the same
<sergiusens> jdstrand, right, pkgname is snap-id basically which is a uuid
 * jdstrand nods
<sergiusens> jdstrand, another thought is that the only envvars that can be used in a service are those exported in the service itself and we control that (snappy)
<jdstrand> sergiusens: I thought that is more or less what systemd is doing with Environment
<elopio> ping stgraber: I was trying to get a xenial lxc in travis to run the snapcraft tests, but it doesn't have network access:
<elopio> https://travis-ci.org/ubuntu-core/snapcraft/builds/100523000
<elopio> can you help me here?
<kyrofa> enoch85, today may not work very well... I seem to be having some internet connectivity issues
<stgraber> elopio: it may just be a timing thing, that is, your container doesn't have an IP address yet
<elopio> stgraber: mmm, I'll add a sleep to check.
<kyrofa> enoch85, but I do plan on working on that .snap today
<enoch85> kyrofa, ok, feel free to work on the apache snap whenever you want. It's above my skill set anyway, so I feel I can't contribute.
<stgraber> elopio: I'm also very surprised that you're able to install and run lxd in what looks like Travis' docker based environment. I thought they restricted what package and repositories you could install to prevent getting their whole infrastructure to be taken over
<enoch85> kyrofa, I'm available all day. Just ping me. :)
<kyrofa> enoch85, very good. I'll make sure to walk you through wha tI've done :)
<elopio> stgraber: this is not a docker container. This is a trusty machine in google compute.
<stgraber> elopio: oh, interesting, I didn't know they supported that
<elopio> stgraber: it's been working for a couple of months. It's nice, but now we need xenial.
<enoch85> kyrofa, sounds good :)
<kyrofa> enoch85, sorry about that. I just keep dropping today :(
<enoch85> kyrofa, np mate. get a better line :) ;)
<kyrofa> I wish
<enoch85> kyrofa, anyway, no stress.
<enoch85> kyrofa, need to be done by the 20:th, so there is plenty of time
<kyrofa> enoch85, alright sounds good :)
<elopio> stgraber: no luck. After the sleep it still can't ping anything.
<stgraber> elopio: might be worth running ifconfig inside the container and outside of it, just to check if things look sane
<elopio> stgraber: ok, it'll take some minutes. Travis is slow today...
<sergiusens> kyrofa, elopio I'll bbl in case someone pings me
<kyrofa> sergiusens, alrighty
<kyrofa> elopio, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/204 ?
<elopio> stgraber: the host shows lxcbr0. The container shows nothing:
<elopio> http://pastebin.ubuntu.com/14422058/
<elopio> kyrofa: let me see.
<elopio> kyrofa: what about an example test for this change?
<kyrofa> elopio, what does that mean in snapcraft? Something that exercises this in snapcraft/examples?
<stgraber> elopio: what's your travis.yml?
<elopio> kyrofa: yes. Like a real world example that uses the new code.
<stgraber> elopio: the behavior you're getting would be consistent with having an older version of lxc, or lack of lxcfs or systemd being unhappy in the container
<elopio> stgraber: https://github.com/elopio/snapcraft/blob/lxd/.travis.yml
<elopio> stgraber: I'm getting it from the lxd-stable ppa.
<kyrofa> elopio, alright I'll throw something together :)
<elopio> kyrofa: thank you.
<stgraber> elopio: ok, add a "sudo apt-get dist-upgrade -y" after the apt-get update and add "lxcfs" on the apt-get install line, just in case travis runs with recommends disabled by default.
 * elopio tries.
<stgraber> elopio: and add a "lxc exec xenial -- ps faux" too so we can see what's running in the container
<kyrofa> elopio, do I also add the new example to TestSnapcraftExamples ?
<elopio> kyrofa: to build it, yes. I'm guessing that it will require manual inspection to check that it works ok, am I right?
<kyrofa> elopio, ah, yeah this is a runtime fix, not build
<elopio> we might need to add a manual_tests dir, like in snappy.
<kyrofa> elopio, and we're not running runtime tests, right?
<elopio> kyrofa: we can from xenial, so just let me finish this PR and there will be automated runtime tests.
<elopio> kyrofa: but I'm wondering is how to confirm that your example works ok automatically. Well, I better wait to see the example.
<kyrofa> elopio, yeah, basically without this fix it fails to run since it can't link up with libgl. But it builds fine. With the fix it links and runs successfully
<elopio> kyrofa: ok, so we can at least check that it doesn't return an error. For now leave it with the build test, and soon we'll start adding runtime tests for the examples.
<kyrofa> elopio, good deal, adding now
<kyrofa> elopio, alright, take another look at that PR for the example
<elopio> stgraber: it pinged!
<elopio> kyrofa: are you in a hurry, or can I go and get something to eat first?
<stgraber> cool, so it was either an old pre-installed lxc or missing lxcfs
<kyrofa> elopio, I'd like to get this merged today just so I can prepare the release, but my EOD is a few hours away yet
<kyrofa> elopio, I'd never stand between you and food ;)
<elopio> kyrofa: let me better review it first. Otherwise I'll keep thinking of you during lunch :p
<kyrofa> elopio, hahaha
<kyrofa> elopio, fortunately I don't think it could be simpler
<elopio> yes, looks good. I like that we now have an opencv example!
<kyrofa> elopio, awesome!
<elopio> stgraber: is there a fancy way to wait for the ip? The sleep is making my nice script ugly.
<stgraber> elopio: not a very nice one, but there is nicer than just a big sleep, yeah
<stgraber> while ! lxc info tryit | grep -q eth0.*IPV4; do
<stgraber>     sleep 5s
<stgraber> done
<stgraber> replace tryit by your container name
<elopio> thanks!
<elopio> -
<kyrofa> sergiusens, is the fix to bug #1530995 to chmod before running, or run with sh?
<ubottu> bug 1530995 in Snapcraft "Snapcraft requires autogen.sh to be executable" [Medium,Triaged] https://launchpad.net/bugs/1530995
<kyrofa> sergiusens, which is the safer assumption-- we have permission to chmod, or it's actually using sh and not bash or something?
<asac> sergiusens: by default all files from stage/ go to snap/ right?
 * asac about to hit send on answer on ML
<asac> damage done :=
<sergiusens> asac, answer is yes
#snappy 2016-01-07
<fgimenez> good morning
<dholbach> good morning
<LefterisJP> Hey guys good morning. (If you are located in Europe)  :)
<LefterisJP> In an experimental snapp I am playing with I have a binary which tries to access the $SNAP_APP_PATH variable
<LefterisJP> Instead of getting the /apps/NAME/version/ path I get the current directory there.
<LefterisJP> Any idea why and/or how I can get the actual path?
<JamesTait> Good morning all; happy Thursday, and happy Old Rock Day! ð  ð¸
<renat> exit
<femdom> Hi all! I'm trying to make a webcam using program work. But apparmor denies me usage of my webcam (Denies ac
<femdom> Hi all! I'm trying to make a webcam using program work. But apparmor denies me usage of my webcam (Denies access to the /sys/bus)
<renat> I can see that in OEM snap I can unmask webcam device in the "assign" setting. But is it possible to whitelist that webcam in the regular app snap?
<LefterisJP> I will ask my question again since it seems nobody saw it :)
<LefterisJP> In an experimental snapp I am playing with I have a binary which tries to access the $SNAP_APP_PATH variable
<LefterisJP> but it shows to be the current directory instead of what I would expect
<LefterisJP> anyone knows why?
<renat> LefterisJP, how are you trying to access?
<renat> Please see this http://pastebin.com/f0d2NRGZ
<renat> Notice that SNAP_APP_PATH becomes your workdir just before your application is started
<LefterisJP> I am simply trying to run the binary manually since running it from Appname.binary did not work and wanted to see why this happened.
<LefterisJP> The binary is the shell script from the go-template that chooses the "correct architecture" binary
<LefterisJP> from this post: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/
<LefterisJP> This is the shell script in question: https://gist.github.com/LefterisJP/90d7a91933db92011a02
<LefterisJP> for it to work I would expect snapp_dir=$SNAP_APP_PATH when echoed to show the /apps/name/version/ directory
<renat> Doesn't this happend because of line 30?\
<renat> Please, see your wrapper in the /apps/bin/ directory
<renat> You will see a script which sets all SNAP_* variables
<renat> If it's your experimental script - you can just copy - paste all SNAP_* vars there and see if that helps.
<LefterisJP> it's not due to line 30 since I tried to echo the $SNAP_APP_PATH even before those lines, and then it seems to be empty.
<LefterisJP> But indeed you are right, there is a script in /apps/bin which looks like the one you linked. I can of course manually paste them and I expect it to work, but what would that achieve? I would like to be able to access these variables from my binary  (and the shell script I linked assumes this is possible to select the right architecture)
<LefterisJP> hmm I think I understand. When I run the binary, then this wrapper at /apps/bin runs which in turn should call the architecture selection script.
<renat> No
<renat> There should be one more wrapper script
<LefterisJP> I am getting appname Geth.sideload not allowed so this is why I tried to run the binary directory
<LefterisJP>  
<LefterisJP> /s/directory/directly
<renat> apps/bin/wrapper should run /apps/snapname.sideload/current/bin/binary.wrapper which should run /apps/snapname.sideload/current/bin/binary
<LefterisJP> Ok I am trying to see why I am getting sideload not allowed, so I am gonna go through all these
<renat> Maybe I'm wrong.
<renat> But anyhow if you use SNAP_* variables - you need to execute script in /apps/bin/ which sets all appropriate variables
<LefterisJP> Any idea why one would get this "Sideload not allowed" error?
<LefterisJP> This is what I get when I run the /appas/bin/wrapper
<renat> Don't know. Maybe you can find an answer if you run dmesg
<LefterisJP> so basically this part of the /apps/bin/wrapper script (last line) seems to fail
<LefterisJP> ubuntu-core-launcher Geth.sideload Geth.sideload_.-bin-geth_IJXfQHMIaSVL /apps/Geth.sideload/IJXfQHMIaSVL/bin/geth "$@"
<LefterisJP> with appname Geth.sideload not allowed
<LefterisJP> IF I use snappy-remote --url FOO install PACKAGE isn't it enough? Do I need something different to properly allow executing a sideloaded app?
<enoch85> kyrofa, ping
<LefterisJP> so I think I have pinned down the problem a bit more
<LefterisJP> I have installed the hello-world example which calls its binary also via ubuntu-launcher
<LefterisJP> ubuntu-core-launcher hello-world.canonical b c
<LefterisJP> Will give an error about the path
<LefterisJP> which is okay
<LefterisJP> but ubuntu-core-launcher Geth.sideload b c will give an error about the appname not being allowed
<LefterisJP> Why would ubuntu-core launcher not allow me to launch an app with that name when I have already installed it and it appears as sideloaded when I do `snappy list`  ?
<sergiusens> Chipaca, can you help out there
<Chipaca> where?
<sergiusens> LefterisJP, are you on rolling or 15.04?
<sergiusens> Chipaca, ^ sideloading and core launcher failures
<Chipaca> LefterisJP: what are you doing, exactly?
<sergiusens> then again, I haven't grabbed all the details to the problem :-)
<LefterisJP> I am using an ubuntu 15.10 with snappy tools. I snapify a directory with snappy-build and get the package. Then I upload it to my Rpi with snappy-remote.
<LefterisJP> Once there I can confirm it's sideloaded with snappy list
<LefterisJP> But when I try to run the Binary by doing Geth.geth I get the:
<LefterisJP> appname Geth.sideload not allowed
<LefterisJP> error
<Chipaca> LefterisJP: do you have click-reviewers-tools installed?
<Chipaca> LefterisJP: I don't think you can use uppercase there, but i might be wrong
<LefterisJP> So I have been digging to find out why this happens, and it's an error omitted by this ubuntu-core-launcher used in the wrapper script.
<kyrofa> Good morning
<kyrofa> enoch85, pong
<LefterisJP> Chipaca: Good idea. I will try with all lowercase too. What about the click-reviewers-tools? Is it supposed to be in the target or in the host machine?
<Chipaca> LefterisJP: if you have it installed on the host machine, `snap build` will warn you about stuff
<enoch85> kyrofa, hey Kyle! :) How is your schedule today? :?
<Chipaca> LefterisJP: as long as you have a recent-enough one installed, it'll give you the same warnings as the store would
<sergiusens> kyrofa, morning
<LefterisJP> Chipaca: Just checked. I do have it. And snappy build gives no warnings.
<Chipaca> LefterisJP: hmm... i don't believe you =)
<Chipaca> LefterisJP: you should be getting "malformed name" with an uppercase package name
<Chipaca> LefterisJP: i just checked this
<Chipaca> LefterisJP: maybe you have an older snappy that *didn't* run click-review automatically?
<Chipaca> LefterisJP: try running it by hand: click-review <snapname>
<Chipaca> e.g., $ click-review Hello-world_1.0.18_all.snap
<Chipaca> Errors
<Chipaca> ------
<Chipaca>  - lint:snappy_name_valid
<Chipaca> 	malformed 'name': 'Hello-world'
<Chipaca> Hello-world_1.0.18_all.snap: FAIL
<LefterisJP> ahh wait
<LefterisJP> I had already changed the name ....
<Chipaca> LefterisJP: ah :)
<LefterisJP> let me try again
<kyrofa> enoch85, this morning is a little full, but this afternoon is a bit more open
<LefterisJP> nah .. changed it back and snappy build did not complain.
<LefterisJP> http://postimg.org/image/jek4a32o5/
<LefterisJP> Maybe I do have an older version.
<LefterisJP> Let me see if the RPI likes the lowercase name though
<Chipaca> LefterisJP: you can always run click-review by hand, as above
<kyrofa> sergiusens, elopio I need to miss standup today-- I have a doctor's appointment
<sergiusens> kyrofa, no worries
<Chipaca> LefterisJP: i'd suggest you add the ppa to have the most recent stuff if you're going to be building stuff with snappy long-term
<LefterisJP> Chipaca: Will do. Thanks. Good to know this tool exists.
<LefterisJP> Chipaca: Which ppa? I only have the one mentioned in the Get Started guide.
<LefterisJP> ppa:snappy-dev/tools
<Chipaca> LefterisJP: hm, that's probably right. What does `apt-cache policy ubuntu-snappy-cli` say?
<LefterisJP> Installed: 1.5ubuntu1
<LefterisJP>   Candidate: 1.5ubuntu1
<LefterisJP>   Version table:
<LefterisJP>  *** 1.5ubuntu1 0
<LefterisJP>         500 http://gb.archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages
<LefterisJP>         100 /var/lib/dpkg/status
<LefterisJP>  
<Chipaca> huh
<Chipaca> mvo_: ping
<Chipaca> LefterisJP: i guess that is the right version for 15.04 compatibility (which is stable snappy until 16.04)
<Chipaca> but we might want to enable click-review (i thought we had?); hence mvo_ ping
<LefterisJP> Chipaca: understood. Anyway it really helps since I am already getting other errors with my snap thanks to these tools. `Error could not find binary`. Looking into what it is now
<Chipaca> LefterisJP: ð
<renat> Hi guys! It's Renat from Screenly. I have more and more questions=)
<renat> First - how I can enable access to the webcam in the snapcraft.yaml file? I want to use webcam snap (C++ app with OpenCV). And when I try to run it - that app doesn't work. Because of AppArmor. I've used hw-assign to enable /dev/video0 for my snap.
<renat> But it doesn't work anyhow.
<renat> From dmesg I can see
<renat> apparmor="DENIED" operation="open" profile="webstreamer.sideload_camcapture_IJXBNQHfABEX" name="/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1/1-1:1.0/video4linux/video0/dev
<sergiusens> renat, I'll defer that to jdstrand ^
<renat> sergiusens, thanks
<kyrofa> sergiusens, take another look at https://github.com/ubuntu-core/snapcraft/pull/206 when you're able?
<enoch85> kyrofa, cool, I will go to my regular work now, but I'll be back in your afternoon. As I said earlier, feel free to work without me. :) Later!
<kyrofa> enoch85, sounds good!
<LefterisJP> If I am having trouble with an executable inside an Ubuntu core installation on the Raspberry PI is there any way to invoke common Unix tools like strace and ldd to see what could be wrong?
<LefterisJP> (Want to find out why my cross-compiled executable does not run)
<sergiusens> kyrofa, sorry one more comment
<kyrofa> sergiusens, no need to be sorry! Thanks for being thorough :)
<sergiusens> LefterisJP, not exactly strace but `sudo snappy install snappy-debug`
<sergiusens> it will help out with all the security warnings and such
<kyrofa> sergiusens, fixed
<LefterisJP> sergiusens: thanks. Will try it out
<sergiusens> kyrofa, just fwiw, I thought you said we needed the exact format for closing bugs '(Closes LP: #XXXX)' or is 'Fixes ...' also fine?
<sergiusens> kyrofa, or just LP: #XXXX
<sergiusens> you must be gone by now :-P
<kyrofa> sergiusens, right, Closes|LP is the default pattern
<kyrofa> sergiusens, so LP: #XXX
<kyrofa> sergiusens, alright I gotta run
<mvo_> Chipaca: ups, sorry for the delay. yes, I thought we did enbable that, wonder what happend here. did you figure it out already or should I have a look
<Chipaca> mvo_: i haven't looked
<elopio> sergiusens: sorry, I hit the close button but you kept talking :)
<sergiusens> elopio, no, mutual
<sergiusens> I did not notice you hit it
<sergiusens> :-P
<elopio> stgraber: yesterday I almost got all the tests passing in the travis lxc. But then I wanted to run them as the user, not as root, and it fails when the tests try to run sudo, like this: http://pastebin.ubuntu.com/14430440/
<elopio> sudo: no tty present and no askpass program specified
<elopio> Do you know a good way to work that around?
<stgraber> stgraber@castiana:~$ lxc exec blah -- su - ubuntu -c "sudo ls /"
<stgraber> bin   dev  home  lib64	     media  opt   root	sbin  sys  usr
<stgraber> boot  etc  lib	 lost+found  mnt    proc  run	srv   tmp  var
<stgraber> seems to work here, can you give me the url to your travis.yml again?
<elopio> stgraber: I rolled back to root late last night: https://github.com/elopio/snapcraft/blob/lxd/.travis.yml
<stgraber> elopio: ah, the difference is probably that I was tested with the official cloud images rather than the minimal image we have on images.linuxcontainers.org
<elopio> stgraber: should I be using the official cloud image instead?
<stgraber> elopio: instead of "lxc remote add..." do "lxd-images import ubuntu xenial --stream daily --alias ubuntu" and instead of "lxc launch images:..." do "lxc launch ubuntu xenial"
<elopio> I like that :D
<stgraber> elopio: I think so, that'll solve the sudo issue at least and probably save you a few dependencies too. Some folks still prefer the other images due to their size, they are about half the size of the cloud images
<jdstrand> renat: you use hw-assign for things in /sys/devices too. It can be used with globs (one '*' for everything in a directory, '**' for subdirectories too and end with a '/' and it is everything in that directory. eg, 'sudo snappy hw-assign foo.sideload '/sys/devices/**/video4linux/video0/'
<jdstrand> renat: note, this is going to change with the new capabilities work
<jdstrand> zyga: fyi (and I think we are on the same page here) is that when we do a capabilities assignment (eg, assign camera which maps to /dev/video0 underneath (whatever the syntax ends up)) then we get not only the /dev/video0 but also /sys/devices/**/video4linux/video0/ (and related items)
<jdstrand> s/is that//
<jdstrand> renat: hey, did you see my comment to you regarding hw-assign? you dropped off right after I gave it
<jdstrand> renat: in case not: you use hw-assign for things in /sys/devices too. It can be used with globs (one '*' for everything in a directory, '**' for subdirectories too and end with a '/' and it is everything in that directory. eg, 'sudo snappy hw-assign foo.sideload '/sys/devices/**/video4linux/video0/'
<jdstrand> renat: note, this is going to change with the new capabilities work
<renat> jdstrand, thanks. Where I can read about new capabilities? So this mean - it's not possible to enable access to the device until snap is not installed?
<jdstrand> renat: the new capabilities work was announced on snappy-devel@ in Nov/Dec. it is still being defined/implemented and isn't available yet on any images
<jdstrand> well, maybe it is in parts. perhaps zyga can point you at something
<renat> jdstrand, understood. Thanks.
 * sergiusens takes a break from implementing the new format for snap apps
<zyga> jdstrand: hey
<zyga> jdstrand: that's up to the capability to decide, I have some code I want to show you for some review
<zyga> jdstrand: but probably tomorrow, I'm trying to make something that I can propose in parallel to other branches aimed at trunk
<zyga> jdstrand: I'd like to understand how to plan for the major flag day when snappy uses capabilites to boot
<zyga> jdstrand: and to do that I need to get everyone to agree on a few details
<zyga> jdstrand: and to ask you and tyhicks about some details of ubuntu-launcher and apparmor/seccom bits
<zyga> jdstrand: specifically, exactyl which file is read / written by which tool outside of snappy itself
<zyga> jdstrand: *exactly
<zyga> jdstrand: I read most of aa and snappy code related to that but I don't want to bet I'm correct
<zyga> jdstrand: as for the actual security bits, I'll show you a branch/gist in one hour, we can discuss it tomorrow/next week
<asac> sergiusens: hmm.. cant find a python pip example anymore :
<asac> :(
 * asac feels blind
<asac> python3 and py2 seem to not be doing pip stuff anymore
<asac> but rather pull from git a tree
<sergiusens> asac, there are many, te most simple one using whatever is in setup.py https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pypi-config/snapcraft.yaml
<sergiusens> asac, using `python-packages` https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-list/snapcraft.yaml
<sergiusens> asac, and requirements.txt https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-file/snapcraft.yaml
<sergiusens> asac, also `snapcraft help python3`
<sergiusens> or 2
<asac> sergiusens: why no example/ anuymore?
<sergiusens> asac, I don't think there ever was an example
<renat> Guys. It's me again. Sorry=( For the some reason /dev/vchiq device not appearing in snappy. But I can see it in Raspbian.
<renat> Tried to load vchiq by modprobe, with no result. Maybe it's compiled in somehow.
<renat> Maybe it's because udev. Let me investigate.
<asac> sergiusens: really odd ... i see https://aws.amazon.com/de/cli/ that pip install awscli should do the trick
<asac> but if i do this it doesnt yield a bin/aws et.
<asac> etc
<asac> well look at en: https://aws.amazon.com/cli/
<aPragmatist> hello all. I have an armhf c++ project that depends on several 3rd-party libraries (zmq, jsoncpp, eigen, etc) that I've been running on a bunch of beaglebone blacks with debian. I'd like to port this project, and a couple of others, to snappy in order to take advantage of the atomic updating/rollback features. What approach do you all recommend? Should I adapt the project to use snapcraft, or build as I have been with make, and
<aPragmatist>  include all of the libs manually in the snap?
<aPragmatist> Or... do you think I'm better off just implementing the update/rollback features myself and not using snappy?
<aPragmatist> Thanks in advance for your help :)
<jdstrand> zyga: ack
<zyga> jdstrand: thanks!
<sergiusens> asac, strange since we already had aws' cli working with snapcraft
<zyga> jdstrand: I won't have the gist for discussion today, sorry :/
<zyga> jdstrand: I got more food for though with hooks, I'm processing that now
<renat> Nevermind guys. vchiq worked after firmware upgrade using rpi-update.
<jdstrand> zyga: no worries-- I've got plenty to do :) tomorrow or ideally monday would work best for me. enjoy your evening :)
<renat> jdstrand, sorry for disturbing you. Not sure if it's important, but your current Raspberry PI2 firmware with vchiq support broken. I don't know who is responsible for that, but you may want to update your raspberry pi image with newer firmware.
<jdstrand> ogra_: iirc, that is something you'd be interested in ^
<jdstrand> renat: thanks
<ogra_> vchiq ?
 * ogra_ googles 
<ogra_> well, i doubt anything on the RPi is even remotely ready for graphical stuff yet
<ogra_> i was planning to take a look after my vacation though
<ogra_> renat, please file a bug :)
<renat> ogra_, ok.
<kyrofa> Chipaca, are you still around?
<Chipaca> kyrofa: no
<Chipaca> kyrofa: 'sup?
<kyrofa> Chipaca, okay I'll ask tomorrow ;)
<Chipaca> kyrofa: i've got 5 minutes before the risotto needs tending again
 * sergiusens notices that Chipaca is always needs to leave as soon as food is ready implying he might be eating all day
<sergiusens> :-D
 * Chipaca agrees
<kyrofa> Chipaca, okay this should be relatively quick. The discussion here (https://github.com/ubuntu-core/snappy/pull/264) culminating in the ML post just sent... I don't understand what he's saying. We redefine $HOME=$SNAP_APP_USER_DATA_PATH anyway
<Chipaca> kyrofa: ah. i haven't read the email yet.
<sergiusens> kyrofa, he's saying running sudo should make $HOME point to the euid
<sergiusens> today, sudo preserves your env on ubuntu
<kyrofa> sergiusens, but the wrapper effectively does that
<kyrofa> sergiusens, well, along with #264's fix
<sergiusens> kyrofa, you might be completely right here; we have too many wrappers to keep track of ;-)
<kyrofa> sergiusens, yeah there's that problem too :P
<Chipaca> kyrofa: I think #264 is one implementation of this, but
<Chipaca> kyrofa: maybe we should just get euid's home directly and not worry
<kyrofa> Chipaca, so really it's a different implementation altogether. Before the wrapper it touched, $HOME should point elsewhere?
<kyrofa> Chipaca, which is where you were coming from with the libc comment, okay I think I gotcha
<Chipaca> something like that, yes
<kyrofa> Chipaca, okay thank you! I just wanted to understand where he was coming from there
<jerryG> any1 able to answer questions about mir, xmir or shared libs in snappy?
<Chipaca> kyrofa: just read gustavo's email, and i think his proposal is sane and is basically what you're trying to do with 264 but gives us a framework against which to check the other things; i still need to look at what we're doing vs what we want to do
<kyrofa> Chipaca, okay. I'm going to leave #264 alone until I get some better guidance. I can tweak that as needed, close and do something earlier in the process, or just let you deal with it
<jerryG> mterry: are u online?
<Chipaca> kyrofa: +1.33Ì
<niemeyer> kyrofa: My concern, which I'm trying to address in that mail, is that we've been solving that issue in small pieces, and with slightly different semantics each time
<Chipaca> jerryG: what's your question about shared libs in snappy?
<kyrofa> niemeyer, oh I'm sorry-- I would have just asked you but I was trying to put the e before the i and it wasn't tab-completing, so I figured you weren't online :P
<niemeyer> kyrofa: Rather than tweaking where the user data points to, I hope we can make it consistently point to the user's home, so everything falls from that
<niemeyer> kyrofa: No worries
<kyrofa> niemeyer, and yeah, I'm on board with that
<kyrofa> niemeyer, we'll still need to create the directory when it comes to services, though
<Chipaca> this breaks the "sudo vim finds my .vimrc", but i don't see a way around that
<niemeyer> kyrofa: If there's consensus around that approach, it's clear how to fix the problem in every case
<Chipaca> and so many apps get that wrong and write the user's config when uid!=euid, it's not worth it tbh
<niemeyer> kyrofa: Why are services any different?
<jerryG> Chipaca: I have 2 questions: 1. how do I add shared libraries (files) in snapcraft.yaml, 2. how do I include xmir in my app,
<kyrofa> niemeyer, just because the binary wrapper makes sure user data path exists, services do not
<niemeyer> kyrofa: That sounds like a bug on itself
<Chipaca> jerryG: shared libraries should be added automatically aiui
<kyrofa> niemeyer, agreed
<niemeyer> kyrofa: In the sense that services shouldn't have a complete different path for everything
<niemeyer> kyrofa: services are not that special
<Chipaca> jerryG: i know nothing about xmir, but maybe somebody else here does =)
<kyrofa> niemeyer, yeah I think that should be removed from the wrapper and added to ubuntu-core-launcher
<kyrofa> niemeyer, makes them more similar
<Chipaca> the wrapper needs cleaning up a lot
<Chipaca> for 16.04
<Chipaca> including nuking the silly tmpfile thing we did pre-1504
<Chipaca> (i mean silly to still be doing it now we no longer do it)
<niemeyer> kyrofa: I still haven't visited the whole code base, and this is an area I'm specifically less aware about, so I'm afraid of saying yes or no.. perhaps would be my best answer before I know more
<kyrofa> niemeyer, understood! +1 on your proposal though
<kyrofa> niemeyer, I'll respond to the ML though
<niemeyer> Chipaca: pre-1504 makes it sounds *really* old :D
<kyrofa> Hahaha
<niemeyer> kyrofa: Thanks, appreciated
<jerryG> Chipaca: how do I wrap program with LD_PRELOAD? like mterry did?
<mterry> jerryG, am now, back from lunch
<jerryG> mterry: great!..  how does libsnappypreload.so work?  How do I include .so files in my snaps?
<Chipaca> niemeyer: ditto for SNAPP_ variables
<mterry> jerryG, look at how https://github.com/mikix/deb2snap works
<Chipaca> jerryG: libsnappypreload.so is *old*
<Chipaca> jerryG: what are you trying to do?
<mterry> jerryG, it has most of the grossness on display -- src for libsnappypreload
<mterry> jerryG, and wrappers to use it
<mterry> jerryG, but it's a super gross way to do things
<Chipaca> i mean, the old way to do thinigs =)
<mterry> jerryG, Chipaca can explain the new fun way
<Chipaca> no no, i can have dinner
<Chipaca> which is almost the same thing, but different
 * Chipaca afk's
<mterry> heh
<mterry> jerryG, well *someone* can explain the new ways (using snapcraft and such)
<mterry> jerryG, I'm not so involved with that
<Chipaca> sergiusens: ^^
<jerryG> mterry: ok thanks.  Can you answer questions about xmir and mir?  or is that different now too?
<mterry> jerryG, it maybe be different, I'm not sure how snapcraft helps integrate those
<jerryG> mterry:  I read that xmir must be implemented in the snap, and use mir as a framework
<mterry> jerryG, yeah that's still the current plan I think
<jerryG> mterry: how do I implement xmir in the snap?  is that similar to the way you did it? or is that different now with snapcraft?
<kyrofa> sergiusens, alright 1.0 is ready to go. Want to take another look at the changelog?
<jerryG> Chipaca: thanks for the help :}
<kyrofa> sergiusens, any other backports/features need to go into that?
<mterry> jerryG, I don't know how different it is in snapcraft these days
<kyrofa> elopio keeps stealing my travis
<kyrofa> His tests take forever
<jerryG> mterry: is there any docs or any way to check?... I couldn't find much about xmir and mir in snappy other than your git
<mterry> jerryG, I don't know!  The only intel I have is ancient when I made deb2snap
<mterry> :-/
<mterry> jerryG, maybe tedg knows?
<jerryG> mterry: k thx.  what do they have u working on now?
<mterry> jerryG, oh I work on the phone
<mterry> jerryG, which isn't *yet* on snappy  :)
<jerryG> mterry: oic
<sergiusens> kyrofa, let me take a minute or two on that
<kyrofa> sergiusens, take your time. I'm sorry for dragging it out but I'm happy with it now :)
<sergiusens> mterry, jerryG we are getting rid of frameworks for 16.04
<sergiusens> for the new way to setup mir, talk to kgunn, he's working on a wiki part (not done yet I believe)
<sergiusens> tht said, I have no idea how display stuff works, much less xmir
<jerryG> sergiusens: can u help with shared libraries?... can I include them manually instead of using apt-get?
<jerryG> sergiusens: interesting decision to remove frameworks
<sergiusens> jerryG, what do you mean by manually? you have a lib already? use the copy plugin
<jerryG> sergiusens: kk
<enoch85> kyrofa, ok, back from work. are you here?
<kyrofa> enoch85, I am :)
<kgunn> jerryG: as sergiusens, i've just learned myself that things are changing for 16.04 wrt frameworks and security policy...
<kgunn> so even i'm back at the drawing board for mir
<sergiusens> kgunn, oh, I thought frameworks wouldn't affect the 'single snap model'
<kgunn> sergiusens: you're right in that sense, it's only related in that, aiui we can't split out sec caps to different parts within a snap
<kgunn> and sec team doesn't want too much capability in a snap for a client app
<kgunn> so i'm being pushed back to the 2 snap approach
<sergiusens> kgunn, I thought the idea was for each app in a snap to have its own capabilties
<sergiusens> kgunn, oh, yeah, that brings in a lot more work
<kgunn> sergiusens: right, it was a feasible way (the 1 snap) but wouldn't scale....
<kgunn> and doesn't really match the framework going away (as can't set you're own policy)
<jerryG> kgunn: On 15.04 stable, to use xmir, do I need to include it inside snap and utilize mir framework?..  if so... how do I include xmir inside snap?
<jerryG> kgunn: are you going to ubucon?
<Doughy> Hello all, the company I work for is considering Ubuntu Core as the basis for an IoT product that we are building on top of the BeagleBone Black. Is Snappy mature enough for commercial production?
<jerryG> Doughy: no
<jerryG> Doughy: well.. depends on what ur doing
<Doughy> jerryG: We would like to use it as the embedded distribution on the BBB. We are attracted to the update features.
<Doughy> Basically we have a gateway device with the Beaglebone Black, that runs our application and web server. We would like our interface to have an "UPDATE NOW" button that allows us to push both OS and application updates to the device.
<jdstrand> kgunn: you are able to use different 'caps' within a snap now and with the new capabilities work
<jdstrand> kgunn: eg:
<jdstrand> apps:
<jdstrand>   - name: foo
<jdstrand>     caps: ...
<jdstrand>   - name: bar
<jdstrand>     caps: ...
<jdstrand> kgunn: this will look different than 'caps' in 16.04, but this sort of thing will be available. what won't available is defining raw security-policy. people will have to work with Canonical to define the new capabilities (security caps currently)
<jdstrand> but the two snap approach (server/shell and client app) is a cleaner model than everyone forking mir+app
<jdstrand> and it happens to work well with the new capabilities approach
<jdstrand> what also won't be available is shipping framework-policy
<kgunn> got it, so really, reviewing for the store not scaling is the main reason
<kgunn> jerryG: yes, you would need to include xmir in your client snap
<kgunn> xmir is just a client from mir's perspective
<kgunn> not going to ubucon
<kyrofa> sergiusens, why does the autotools plugin run `./configure --prefix=` ? Is that intentional?
<sergiusens> kyrofa, we have that from original code, maybe mvo_ or mterry know
<sergiusens> kyrofa, I always meant to ask
<kyrofa> sergiusens, it breaks my apache build
<kyrofa> mterry, any clues there?
<sergiusens> kyrofa, fix it to anything that makes sense ('/' or '/usr')
<mterry> kyrofa, prefix is commonly /usr or /usr/local
<mterry> kyrofa, I found some packages that broke with prefix=/
<sergiusens> kyrofa, if you do a --prefix in configflags the last one takes precedence I believe
<mterry> kyrofa, but I didn't find one that broke with prefix=
<mterry> kyrofa, (and I wanted one of them purely for cosmetic reasons, so that all files in the snap weren't full of /usr paths
<kyrofa> mterry, that makes sense, thank you for the explanation! It just hanging there looked... bug-like
<kyrofa> sergiusens, good to know, I'll give that a shot :)
<kyrofa> sergiusens, not a bit autotools user here
<kyrofa> s/bit/big/
<Doughy> Anyone know if there is a way I can get someone from Canonical on the phone? I'm willing to pay for it. I need answers around Ubuntu Core and can't seem to get them.
<sergiusens> kyrofa, I am mostly done with the work to support snap.yaml, package.yaml, readme.md and all the hooks (icon, license and config) :-D
<sergiusens> just pending a rewrite of all the unit tests :-P
<kyrofa> Doughy, have you tried the snappy mailing list?
<kyrofa> sergiusens, awesome!
<kyrofa> sergiusens, you work too fast. Makes the rest of us look bad
<kyrofa> Doughy, Ubuntu Core is pretty stable, but it is indeed under heavy development. You would need to be aware of that
<sergiusens> kyrofa, nah; once you see this you will notice it wasn't that complicated
<kyrofa> Doughy, what specific questions do you have?
<Doughy> kyrofa, I have an armhf c++ project that depends on several 3rd-party libraries (zmq, jsoncpp, eigen, etc) that I've been running on a bunch of beaglebone blacks with debian. I'd like to port this project, and a couple of others, to snappy in order to take advantage of the atomic updating/rollback features. What approach do you all recommend? Should I adapt the project to use snapcraft, or build as I have been with make, and include a
<Doughy> ...in the snap.
<kyrofa> Doughy, alright, so a current limitation of snapcraft is an inability to cross-compile, so you would need an arm environment in which to run it (e.g. a qemu vm)
<Doughy> OK, that's not a problem.
<kyrofa> Doughy, and that's only if you choose to do the build with snapcraft. If you keep your current built methodology, you can cross-compile yourself and simply package the result as a .snap
<kyrofa> Doughy, how do you include the 3rd party libs? Do you compile from source? .deb packages?
<Doughy> Compiling from source.
<kyrofa> Doughy, man you're golden if you can live with the cross-compile limitation of snapcraft
<Doughy> Is there a good example of a C++ snap that uses 3rd party libraries that we can go off?
<kyrofa> Doughy, hmm... you know I don't think there is. But I'm currently working on one I'd be happy to share once I make some more progress
<kyrofa> Doughy, there are examples of using libs packaged as .debs, but not source depending on source that I know of
<Doughy> kyrofa, That would be awesome. Really appreciate it. Do you work for Canonical?
<kyrofa> Doughy, I do
<sergiusens> kyrofa, there are simple examples in c, 'downloader_with_wiki_parts' and 'libpipeline'
<kyrofa> Ah, thanks sergiusens. Doughy check out https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/libpipeline
<Doughy> kyrofa, Does Canonical offer any paid support for this kind of stuff? Some way to get direct support as we develop rather than hoping to find you here?
<Doughy> We'd be willing to pay to make sure we can get questions answered quickly.
<Doughy> Thanks for the link. We've seen that link.,
<kyrofa> Doughy, yeah, we just need to put you in touch with the right people. Mind shooting me your email in a PM?
<Doughy> Awesome. Will do now.
<sergiusens> kyrofa, ok, so early morning we can do the release; I'll create a hangout so you can see how boring it is
<sergiusens> elopio, maybe you can check 1.x as it is now and verify nothing broke badly on trusty or vivid?
<kyrofa> sergiusens, sounds good
<sergiusens> kyrofa, ideas RuntimeError: Package "std_msgs" isn't a valid system dependency. Did you forget to add it to catkin-packages? If not, add the Ubuntu package containing it to stage-packages until you can get it into the rosdep database. ?
<sergiusens> kyrofa, that's on xenial
<kyrofa> sergiusens, yeah it may have something to do with the ubuntu version
<kyrofa> sergiusens, let me check something
<sergiusens> kyrofa, sure
<kyrofa> sergiusens, yeah, I don't think the indigo rosdep rules include provisions for xenial (which makes sense)
<kyrofa> sergiusens, hmm... this will require some thinking
<sergiusens> kyrofa, no worries, maybe there's an early thing for xenial going on already, I'll shoot out an email to dirk and cc you
<kyrofa> sergiusens, alright
<sergiusens> kyrofa, in case you are bored and want something to do https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:snap_yaml?expand=1
<sergiusens> an initial diff of everything except units
<enoch85> kyrofa, sorry, got hold up with something else
<enoch85> kyrofa, builing a new VM - totally focused you know... :)
#snappy 2016-01-08
<dholbach> good morning
<om26er> Hi! Where can I download the latest snappy image ?
<JamesTait> Good morning all; happy Friday, and happy English Toffee Day! ð  ð¬
<asac> adduser/useradd does not work on 15.04 latest?
<asac> tells me that it cant lock passwd
<asac> didnt we implement this?
<asac> ogra_: ?
<asac> oh i am not on 15.04 to start with :)
<asac> lol
<asac> mvo: when will my classic fixes land?
<asac> really was hoping that i could demo it next week
<asac> or rather today to prep for that demo
<mvo> asac: it got merged last night. you are running on an all-snap system? what arch? amd64? rpi2?
<asac> mvo: pi2 for now
<asac> otherwise i wouldnt need classic that badly
<ogra_> asac, you need the extrausers option
<asac> and yes i am on all-snap
<ogra_> but even with that there is one bug left
<ogra_> (see --help, i forgot the exact syntax)
<mvo> asac: pi2 and all-snaps?
<asac> ogra_: /usr/bin/chfn: unrecognized option '--extrausers'
<asac> thats the bug left?
<ogra_> yeah
<asac> mvo: ack!!
<ogra_> you can ignore it
<mvo> asac: ok, I will prepare a new image
<ogra_> user addition should still process
<asac> mvo: will i get it thropugh update?
<asac> thanks!!!
<mvo> asac: yes
<asac> i can also reflash for sure
<asac> nice
<mvo> asac: you will need to destroy/create the classic though after you got the new version
<asac> ogra_: so you say it succeeded?
 * asac checks
<asac> ogra_: urright
<asac> works :)
 * asac prefers being asac tghan ubuntu
<asac> mvo: sure... already destroyed it hoping that the fix was there
<ogra_> asac, http://paste.ubuntu.com/14437429/ thats the script i use for setting up machines
<ogra_> (for syntax reference)
<asac> mvo: find it odd that we have enable-classic vs destroy ... rather think create-classic if its destroz, but afaik it all moves to a snap anyway soon?
<mvo> asac: yeah, I need to get the details from guastvo about the exact UI but it will change
<asac> cool
<asac> mvo: how long you think until the new image is up?
<mvo> asac: ~1h
<asac> gogogogo
<mvo> asac: sorry, there is the potential for it to be (much) faster but right now its not because we reuse a lot of the infrastructure
<asac> mvo: 1h is better than what i was scared to hear :)
<asac> so no worries
<asac> mvo: how would it be much faster by not reusing infra?
<asac> oh is that about taking lxc images as starting point and patching up?
<mvo> asac: the process is build snappy git snapshot in the ppa, wait for it to build and publish, trigger image build on cdimage, wait for it to build and get imported, generate OS snap and upload to the store. if there was a way to do the building locally everything would be way quicker
<mvo> asac: anyway, the ppa build is running, once that is in I will trigger the image build etc
<ogra_> mvo, just a reminder poke about the u-d-f merge (it will really not interfere with all-snaps, all code runs after image creation)
<asac> ogra_: so i unpacked our initrd and noticed that all the bbox binaries were copies rather than symlinks to busybox binary
<asac> is that because i used wrong cpio flags? or do we really have them all duplicated?
<asac> mvo: gotcha
<ogra_> asac, are you sure they are bb binaries ? ...
<ogra_> i think the binaries you see are all native versions
<asac> ogra_: sure...  same size
<ogra_> well, then i dont know
<asac> all same size identical with bb?
<ogra_> we only run update-initramfs to create the initrd ... nothing fancy
<asac> ogra_: http://paste.ubuntu.com/14437554/
<ogra_> yeah, i belive you
<ogra_> i'm pretty sure inside the initrd they are links
<ogra_> did you unpack in a vfat ?
<asac> ogra_: no its on my tmpfs on my normal laptop
<ogra_> weird
<asac> ogra_: anyway... dont worry for now... did you ever try to snap up screen?
<asac> ogra_: i used cpio -i to unpack
<asac> if that matters
<ogra_> heh, no, that never struck me
<ogra_> (to snap screen)
<asac> ok let me try what happens then :)
<ogra_> might need some device rules ...
<ogra_> (to access ptys and ttys)
<asac> device rules?
<asac> you mean grant permissions to non dialout group?
<ogra_> well, permissions
<ogra_> it will be confined, most of /dev wont be accessible without extra work ...
<ogra_> (hw-assign, capabilities etc)
<asac> sure
<kyrofa> Good morning
<ogra_> anyway ...
 * ogra_ goes back to do vacation stuff
<asac> oh darn :( ... of course i ahve to wait for classic
 * asac sets countdown and goes for basic food
<ogra_> heh
<kyrofa> sergiusens, good progress on the yaml changes. I do have a few questions though
<sergiusens> kyrofa, we can discuss them in 15 minutes live if you wnt ;-)
<kyrofa> sergiusens, sounds good to me
<kyrofa> sergiusens, worst case, I forgot-- we can actually host our own rosdep yamls in a github fork
<sergiusens> kyrofa, sounds good to
<kyrofa> sergiusens, because it looks like the cache is pickled :(
<sergiusens> kyrofa, better if it is in the plugin itself though
<sergiusens> ah
<sergiusens> darn
<kyrofa> sergiusens, agreed, we'd need to keep it up to date which isn't ideal
<sergiusens> kyrofa, how about patching rosdep itself?
<kyrofa> sergiusens, you mean officially, or in the plugin?
<sergiusens> kyrofa, in the plugin; not sure about officially
<kyrofa> sergiusens, are we fighting this too much? Should the plugin just support different sources for ros releases and compare them against the ubuntu release and error out if it's not supported?
<sergiusens> kyrofa, maybe so
<kyrofa> sergiusens, I mean, it's not ideal, but it's how they've chosen to support ubuntu
<sergiusens> kyrofa, but jade only goes all the way to vivid :-P
<kyrofa> sergiusens, gahh
 * rsalveti kicks asac :P
<asac> rsalveti: what did i do :)
<kyrofa> sergiusens, alright, I figured out a way around this, but there's sort of a greater limitation I'd like to discuss. Right now the catkin plugin has the trusty .deb repos hard-coded, as you know
<rsalveti> asac: are you playing with the db410c board/
<kyrofa> sergiusens, which means any rosdistro not in there will error out
<asac> rsalveti: not personally, but others do :)
<asac> i didnt receive one yet :)
<rsalveti> alright :-)
<asac> ricmm and lool etc.
<asac> ogra as well
<kyrofa> sergiusens, fortunately, rosdep has a command line parameter for what version of ubuntu to use to resolve dependencies
<rsalveti> great, want to make sure you guys are using the stuff we are producing (or getting the patches from it at least)
<kyrofa> sergiusens, so for now I can just say "use trusty" even if they're on vivid or xenial
<rsalveti> asac: how is the kid going? listening metallica already?
<kyrofa> sergiusens, I'll test that out-- perhaps that's enough for 1.0 to be releasable
<kyrofa> We can revisit the repos later
<ogra_> rsalveti, i'm on vacation, i did work out a proper kernel config for our tree before my holidays, ppisati is preparing a package i can use after i return then .. i think we're fine on track
<rsalveti> ogra_: cool, then what are you doing online? :-)
<ogra_> stuff :)
<rsalveti> :P
<asac> rsalveti: no, i moved to mozart instaed :P
<kyrofa> sergiusens, since both jade and indigo are supported in trusty, and pretty much everyone is using one of those
<asac> j.k.
<rsalveti> :P
<sergiusens> kyrofa, that's fine for 1.x, not so for 2.x
<kyrofa> sergiusens, how come?
<kyrofa> sergiusens, just to support newer releases, you mean?
<sergiusens> kyrofa, we said snapcraft 2.x would only work on xenial; or better said, starting this new iteration; build on target is the way to go; we can discuss in a bit if you want; I'm in no call no so now is also good
<kyrofa> sergiusens, I'm not sure this affects that. Yeah, let's discuss (we can wait a bit though if you like)
<elopio> mvo: for some failover tests we need to break the kernel, and for some we need to break the os. Is there a way to query for the name of a type of snap?
<mvo> elopio: from the commandline? I think we don't have this right now, so we need to add it
<elopio> mvo: do you want me to report a bug?
<mvo> elopio: yes please. in the meantime you can find the name via "grub-editenv  list|grep ^snappy_os=" but its not a great workaround
<elopio> okay, I'll make a note of that too.
<elopio> mvo: fgimenez: so the thing here is to have a break in the fake update. Prepare the update, break the app, and then do the update.
<elopio> fgimenez: and we'll have to change all the logic about current and other partition on the failover tests. Basically, rewrite them :) But it seems they will be a lot simpler.
<fgimenez> elopio, that sounds good :)
<mvo> elopio: yeah, with the new "make-fake-update" code we "just" need to inject our breaking in there
<mvo> elopio: if you want I can create a skeleton with what I have in mind (if what I said was unclear or anything)
<elopio> mvo: maybe. I was thinking of just calling the steps of the good fake update one by one, and add a call to the break method in the middle.
<elopio> mvo: it sounds you have something fancier in mind.
<mvo> elopio: just a callback with custom injections when building the new snap, but either way is fine, if you have a plan just go ahead, I'm in the middle of something else right now :/
<elopio> mvo: okay, I was thinking of overwriting methods, like the current tests. But a callback sounds good, I can try. First I'll try something dirty just to see if I can break the reboot.
<mvo> elopio: cool, thanks a lot for working on this, its very exciting!
<mvo> elopio: keep me updated
<elopio> it is indeed. Makes testing a lot easier.
<mvo> its also much cleaner
 * mvo really is excited
<elopio> mvo: https://bugs.launchpad.net/snappy/+bug/1532245 for next week :D
<ubottu> Launchpad bug 1532245 in Snappy "there is no way to tell which snaps are os, kernel and gadget" [Undecided,New]
<sergiusens> kyrofa, lets have a call now?
<kyrofa> sergiusens, alright sounds good
<kyrofa> sergiusens, I'm in the standup url
<sergiusens> kyrofa, joining then
<kyrofa> sergiusens, note that those hard coded sources will only work until the next version of ROS is released. Then we'll have to be a little smarter about it
<kyrofa> sergiusens, but that shouldn't be too bad
<sergiusens> kyrofa, that is fine; when we get close to 16.04 releasing we can start working on a plan to support whatever ros LTS release will come out
<kyrofa> sergiusens, perfect
<sergiusens> kyrofa, in theory there should be a K release, right?
<kyrofa> sergiusens, indeed
<sergiusens> kyrofa, documentation suffers on the ros site as everywhere :-P
<kyrofa> sergiusens, haha, yes it does
<sergiusens> kyrofa, ROS Kinetic Kame
<sergiusens> 	
<sergiusens> May, 2016
<sergiusens> 	
<sergiusens> TDB
<sergiusens> 	
<sergiusens> TDB
<sergiusens> 	
<sergiusens> May, 2021
<sergiusens> oops
<sergiusens> supposed to be a one liner :-)
<sergiusens> http://wiki.ros.org/Distributions
<kyrofa> sergiusens, what on earth is a Kame
<sergiusens> A kame is a geomorphological feature, an irregularly shaped hill or mound composed of sand, gravel and till that accumulates in a depression on a retreating glacier, and is then deposited on the land surface with further melting of the glacier.
<sergiusens> google images shows anything but that
<sergiusens> must be a popular "star" name
<genii> So a pile of detritus
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/212 . Should be a painless review
 * asac wonders if there is a way to convince screen to not write to /var/run/ without patching
<asac> ok SCREENDIR looks like a candidate
<asac> jdstrand: debug.security saying "* add 'mknod' to 'syscalls' in security-override
<asac> "
<asac> is good guidance?
<ogra_> asac, btw, ii thijnk i'll give up on my postfix/dovecot snap ... i really dont want to maintain users in an SQL db or some such and want to be able to use procmail ... getting that to work in a snap will be super tricky
<sergiusens> kyrofa, I need to drop for a bit, baby issues
<kyrofa> sergiusens, hey I have those too, no worries :)
<jdstrand> asac: it may also say to adjust the program to not use mknod
<jdstrand> asac: on a 16.04 system to get the snap running, you can do:
<jdstrand> service:
<jdstrand>   - name: foo
<jdstrand>     caps: network-client
<jdstrand>     security-override:
<jdstrand>       syscalls: [ mknod ]
<jdstrand> lots of caveats: you will likely have other things to add (eg, write-path), this would be blocked by the store, security-override is going away
<jdstrand> (in favor of new capabilities system)
<jdstrand> I advise adjusting the program to not use mknod
<kyrofa> elopio, any chance you have a minute to review https://github.com/ubuntu-core/snapcraft/pull/212?
<asac> jdstrand: ok lety me try that
<sergiusens> kyrofa, I reviewed it, just wanted to test it on xenial :-)
<elopio> kyrofa: oh, even better. I'll merge my xenial branch to confirm it now passes.
<elopio> give me a second...
<kyrofa> sergiusens, oh, okay!
<asac> jdstrand: and click-review tools?
<asac> is that supposed to work with squash?
<sergiusens> elopio, that seems to be the way ;-)
<sergiusens> knowing that it runs though is a big bonus too ;-)
<jdstrand> asac: if you have the latest checkout, yes, it should work
<jdstrand> asac: I don't think that the tools ppa has it though, since all snaps hasn't landed yet
<asac> jdstrand: http://paste.ubuntu.com/14439310/
<jdstrand> asac: snapcraft may not understand the 16.04 security-override. sergiusens, can you comment?
<asac> ok seems not :/
<asac> jdstrand: is apparmor and seccomp still an option or not valid anymore on 16.04?
<kyrofa> jdstrand, anything 16.04 specific hasn't been released yet
<kyrofa> sergiusens, elopio also look over https://github.com/ubuntu-core/snapcraft/pull/211 when you have a chance. We've started getting PRs with no associated bugs
<asac> jdstrand: i am running click-review from lp: trunk
<asac> tells me its not a debian package
<asac> jdstrand: http://paste.ubuntu.com/14439370/
<jdstrand> asac: so, security-override changed in 16.04 to be usable
<jdstrand> this was before Brazil
<jdstrand> on 15.04 you do:
<jdstrand> services:
<jdstrand>   - name: foo
<jdstrand>     security-override:
<jdstrand>       apparmor: path/to/foo.apparmor
<jdstrand>       seccomp: path/to/foo.filter
<jdstrand> and path/to/foo.apparmor was a click security manifest (json) and path/to/foo.filter was a list of syscalls
<jdstrand> it was crap and bad and removed
<jdstrand> so on 16.04 there is:
<jdstrand> services:
<jdstrand>   - name: foo
<jdstrand>     security-override:
<jdstrand>       syscalls: [ a, b ]
<jdstrand>       read-paths: [ /c, /d ]
<jdstrand>       ...
<jdstrand> snapcraft isn't accounting for the yaml change in 16.04
<jdstrand> but, in Brazil, security-override will be removed (probably why snapcraft isn't updated)
<jdstrand> asac: so in light of that, remove security-override from your yaml. if you are just debugging, add mknod to /var/lib/snappy/seccomp/profiles/... for your app
<jdstrand> asac: if this is for the store, do that ^ until you are happy, then use 'security-policy'
<jdstrand> we are at a weird point for developing on snappy-- things are changing a lot and it is a bit bumpy
<sergiusens> jdstrand, asac reason was that snapcraft used work across all versions, now it is bound to release; I haven't made that change yet
<elopio> I'm running more than 10 sets of tests at the same time :D
<elopio> travis, vm, real machine, I'm going to explode.
<kyrofa> elopio, *achievement unlocked*
<kyrofa> I can hear you now "And they're ALL failing! What are the odds?"
<elopio> kyrofa: I can build and install the snap. But when I run the binaries I get python not found, rosrun not found, cat not found.
<elopio> that's like: half of the test passed :)
<kyrofa> elopio, argh. Which version of ubuntu core are you running?
<elopio> kyrofa: rolling edge #310, kvm.
<kyrofa> elopio, investigating now
<elopio> goal for the next week, get the examples install and execution suite automated.
<kyrofa> elopio, yeah something must have changed pretty significantly from vivid (which is what I'm running). I'll get a rolling VM up
<kyrofa> elopio, any chance you know why u-d-f is giving me "generic-amd64 failed to install: snappy package not found" when I try to create a rolling image?
<kyrofa> (on xenial)
<elopio> kyrofa: yes, use --oem generic-amd64/stable
<sergiusens> kyrofa, elopio we really want to make sure 15.04 works for 1.x though
<kyrofa> elopio, hmm... that gives me other errors ("generic-amd64/stable failed to install: exit status 2"). What incantation are you using?
<kyrofa> sergiusens, 15.04 works fine in my tests
<elopio> sergiusens: I'm testing that with my left hand :)
<kyrofa> elopio, hahaha
<elopio> kyrofa: sudo ubuntu-device-flash core rolling --channel edge --oem generic-amd64/stable --developer-mode -o ubuntu-snappy-rolling-edge-amd64-generic.img
<kyrofa> elopio, huh, yeah "exit status 2."
<kyrofa> elopio, maybe I'll try on wily instead
<elopio> kyrofa: I'm with u-d-f 0.33-0ubuntu2
<kyrofa> elopio, same here. What on earth
<kyrofa> u-d-f needs to depend upon ubuntu-snappy
<kyrofa> cli
<kyrofa> elopio, is this really the first snapcraft issue you've hit on rolling?
<elopio> stgraber: hey look, all green \o/ https://travis-ci.org/ubuntu-core/snapcraft/builds/101115699
<elopio> The only thing I didn't like was that I had to chmod 777 the directory I mounted on the container.
<elopio> I tried chown 100100, but it gave errors when the tests created links, and when touching the coverage file in the base directory.
<elopio> kyrofa: it's the first I tested this year.
<kyrofa> elopio, huh, wily gave me the same problems. Wonder if it has something to do with lxc
<kyrofa> elopio, any chance you can share your image? :P
<kyrofa> sergiusens, if it's verified that this works for 15.04, is it good for 1.0?
<stgraber> elopio: to avoid the chmod you can either run a privileged container (pass -c security.privileged=true to launch) or chown or add an acl for uid 101000 (the mapped uid of user ubuntu in the container)
<elopio> kyrofa: hum, no, that would take like the whole day. Remember that I'm bandwidth handicapped. Do you have access to canonistack?
<kyrofa> elopio, oh yeah :P
<kyrofa> elopio, and yes, I do
<elopio> stgraber: I tried chown. Maybe I'll go the privileged container way.
<elopio> kyrofa: there is a rolling image of yesterday in there. Do you know how to start it?
<stgraber> elopio: you could apt-get install acl and do "setfacl -m default:user:101000:rwX -R $(pwd) && setfacl -m user:101000:rwX -R $(pwd)", that should set the posix ACL everywhere where it matters including a default ACL that should automatically be set for any new entry
<kyrofa> elopio, oh brilliant! Yeah, thanks :)
<stgraber> elopio: but otherwise, since it's an ephemeral environment and you don't really care about security, security.privileged=true would certainly be the easiest way out of the problem :)
<elopio> stgraber: okay, so more tries for next week :)
<elopio> stgraber: look at this one: https://travis-ci.org/ubuntu-core/snapcraft/builds/101121816
<elopio> travis is awesome, free machines for everybody. Now we have trusty, vivid and xenial for each suite.
<stgraber> :)
<sergiusens> kyrofa, yeah
<kyrofa> elopio, has your 15.04 test finished?
<elopio> kyrofa: I'm using trusty to build the examples. The two go ones failed, I'm investigating. And I'm starting a 15.04 snappy to run the ros I've built in there.
<kyrofa> elopio, and the ros was built from xenial?
<kyrofa> elopio, or vivid? Something past trusty
<elopio> kyrofa: the ros built from trusty works on 15.04
<elopio> kyrofa: the packages built on xenial can't be installed on 15.04
<kyrofa> elopio, alright. I built the ros package on xenial using the 1.x branch, and it installed and ran fine
<kyrofa> elopio, well, with the bugfix branch actually
<elopio> ah, using the 1.x branach
<kyrofa> elopio, right
<kyrofa> elopio, use my backport branch
<elopio> ok, now let me refocus.
<kyrofa> elopio, but yeah, sounds like 1.x has some issues with later versions of snappy, which isn't entirely surprising
<elopio> I wanted to confirm that 1.x worked on trusty. kyrofa: do you want me to confirm that 1.x ros works on vivid too?
<kyrofa> elopio, it wouldn't hurt, but we've now confirmed that 1.x works on trusty and xenial, so...
<kyrofa> (at least as far as ros goes)
<kyrofa> elopio, so I'm satisfied with that bugfix anyway
<elopio> for 1.x, if you have already built it and run it, I agree.
<kyrofa> elopio, alright. Shall I merge it and update the release PR, then?
<elopio> kyrofa: sure. I'll start firing my vivid vm to see if I find something weird in there.
<elopio> where did sergiusens go?
<kyrofa> elopio, just back to general release testing?
<kyrofa> elopio, not sure. Perhaps more problems with the little one
<elopio> kyrofa: I'm getting errors in the go examples in trusty. Also travis is failing there: https://travis-ci.org/ubuntu-core/snapcraft/jobs/101121821
<elopio> oh wait, wrong link. That's the one your pr fixes.
<elopio> sergiusens: kyrofa: https://travis-ci.org/ubuntu-core/snapcraft/jobs/101121821 go examples failed to build in trusty.
<sergiusens> elopio, archive errors it seems
<sergiusens> elopio, Failed doing pull for godd: W:Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/binary-amd64/Packages  Hash Sum mismatch
<kyrofa> sergiusens, elopio yeah I've noticed those a few times too-- rerun
<elopio> ah, yeah, I'll retry for that one. But also:
<elopio> http://pastebin.ubuntu.com/14440028/
<elopio> this is the one I get with godd on my vm:
<elopio> http://pastebin.ubuntu.com/14440034/
<sergiusens> elopio, oh, right, godd might not be buildable on trusty anymore; or did we not talk about this at some point already? I forget
<elopio> well, it seemed to have been building before. My guess is that something installed in the travis trusty machine made it work.
<elopio> now that we are in a lxc, we need to figure out what that was.
<sergiusens> elopio, no worries, I have my trusty lxc instance and it worked last I checked
<elopio> yes, it passed on kyle's branch for the changelog.
<jerryG> kgunn: are u there?
<kyrofa> sergiusens elopio, alright the release branch has been updated
<elopio> ok, the only problem I can find on trusty is that with the go examples, which if is a bug it's not new.
<elopio> kyrofa: sergiusens: if you want, you can wait for me to do some validation on vivid. Or you can release now.
<jerryG> chipaca: u there?
<elopio> kyrofa was trying stuff in vivid, so I doubt I will find something here.
<kyrofa> jerryG, capital-C: Chipaca
<jerryG> kyrofa: k thx
<jerryG> Chipaca: u there?
<kyrofa> sergiusens, your call
<sergiusens> elopio, kyrofa I have no issues with waiting and not having to look back ;-)
<elopio> sergiusens: ok. Can we release on monday then so I can have a relaxed lunch? or do you want to release today?
<sergiusens> kyrofa, ? are you in a rush?
<kyrofa> sergiusens, elopio fine by me
<elopio> monday it is then :D Actually we should make a rule of never ever releasing on friday.
<sergiusens> elopio, I love releasing on Friday
<sergiusens> check the history ;-)
<kyrofa> Hahaha, elopio you don't want to come back a million bug reports on Monday?
<elopio> I would prefer the million bugs to be on tuesday ;)
<kyrofa> :F
<kyrofa> Err, :D. Wow
<kyrofa> Beaver smiley?
<sergiusens> lol
<Chipaca> kyrofa: jerryG: OHI
<jerryG> Chipaca: hey!
<Chipaca> kyrofa: i'm case-insensitive, fwiw, but you guys always seem to call me post-EOD =)
<elopio> post-EOW :)
<jerryG> Chipaca: im trying to get mir clocks example running on snappy stable.  But I'm getting a "connection to mir failed... check if MIR is running" error
<kyrofa> Chipaca, heh. I'm not calling you though!
<Chipaca> jerryG: is mir running?
<kyrofa> Chipaca, if you're EOD you should ignore us!
<jerryG> Chipaca: yeah.  I'm using mir.mvp-demo though.  But I get the cursor on black background.
<Chipaca> jerryG: and where does that mir have its socket?
<jerryG> Chipaca: how to check? ps-ax?
<Chipaca> jerryG: or find perhaps
<Chipaca> kgunn: wasn't there a newer mir than mir.mvp-demo?
<jerryG> Chipaca: mir_demo_server --window-manager fullscreen --file /run/mir_socket --vt 1
<Chipaca> jerryG: k
<Chipaca> jerryG: and is your client using that same socket, and does it have access to it?
<jerryG> Chipaca:  how to check?... my "clocks" shell script executes /apps/mir/current/bin/mir-run
<jerryG> Chipaca: and I have "framwork" set to mir in the yaml
<Chipaca> jerryG: have you checked syslog for apparmor denials?
<kyrofa> jerryG, or run snappy-debug
<jerryG> Chipaca: snappy service logs?
<jerryG> kyrofa: how do i use snappy-debug?
<kyrofa> jerryG, install it: sudo snappy install snappy-debug, and run it: sudo snappy-debug.security scanlog
<kyrofa> jerryG, it parses syslog for apparmor denials and gives you some helpful advice
<jerryG> kyrofa: kk thx.  i see all the denials
<jerryG> Chipaca: kyrofa: I fixed apparmor denials.  But still getting same "connection to mir failed" output from clocks example.
<Chipaca> jerryG: what socket is it trying to connect to?
<mvo> jdstrand: I have a branch that renames /apps to /snaps - is there apparmor work needed for this? pardon my ignorance on this, I did change some code in security.go for this new location but I'm not sure if there is more to do for that
<sergiusens> Chipaca, just noticed that my PR for licenses was wrong, it was supposed to be meta/license.txt, not meta/hooks/license.txt ;-)
<mvo> jdstrand: https://github.com/ubuntu-core/snappy/pull/308 fyi, but its pretty borning
<sergiusens> jdstrand, I solve the fact that we can't use envvars in command (former start) within snapcraft itself, so if snapcraft is used, it is allowed (given our wrapping) ;-)
<jdstrand> mvo: with click-apparmor gone, the only thing should be your change to security.go. if you can install hello-world.mvo and run hello-world_env, it should be fine
<jdstrand> mvo: (ie, that is why we use apparmor variable for INSTALL_DIR instead of hardcoding it in policy)
<mvo> jdstrand: cool, thanks
<jdstrand> np
<sergiusens> elopio, is there a way to get a better pep8 on trusty?
<sergiusens> elopio, these drive me nuts :P https://travis-ci.org/ubuntu-core/snapcraft/jobs/101158429
<mvo> ogra_: arm64 build works again
<sergiusens> kyrofa, elopio if nothing to do you guys have, maybe check this you might https://github.com/ubuntu-core/snapcraft/pull/215
<sergiusens> Chipaca, zyga mvo as well ^
<sergiusens> that's snap.yaml in full except capabilities with full backwards support for package.yaml and readme.md
<sergiusens> just needs documentation updates
<jerryG> Chipaca: how to check?
#snappy 2016-01-10
<femdom> Hi all! It's me again with my questions.=) I'm trying to make my snap, which uses OpenCV, to work with camera. /dev/video0 dev. Even if I do hw-assign - I can work with camera only from the root user.
<femdom> Seems it's because /dev/video0 has wrong access right.
<femdom> *access settings. Sorry.
<femdom> Oh. Sorry. I'm lying. It's root:video rw-rw----
<femdom> I can't see anything suspicious in the dmesg output.
<femdom> This may mean that I should manually add my user to video group, even if I do hw-assign?
<amriunix> how to install nodejs on snappy (rpi2)
#snappy 2017-01-02
<zyga> good morning
<pwik> Anyone have any experience installing ca-certficiates-mono as a stage-package in a snapcraft package?
<zyga> pwik: not me, sorry
<zyga> pwik: you may also ask in https://rocket.ubuntu.com/channel/snappy
<zyga> it's like IRC but persistent and a bit more modern
<zyga> if you have a launchpad account you can just log in and use it
<pwik> Alright, I'll try that. Basically the problem is that the ca-certificates-mono packages installs certificates and creates symlinks to them when installed in the OS. The symlinks are missing when installed in a snap package.
<pwik> Any ideas?
<zyga> pwik: I have ideas for that
<zyga> pwik: your snap executes in a different environment
<zyga> pwik: you cannot install anything into /usr for example
<zyga> pwik: I blogged about how snap execution work a while ago http://www.zygoon.pl/2016/08/snap-execution-environment.html
<pwik> I'll check it out.
<pwik> Is there any way to enable verbose logging when building snaps?
<zyga> pwik: I don't know that, check with sergiusens perhaps
<mup> PR snapd#2539 closed: spread: improve qemu ubuntu-14.04-{32,64} support <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2539>
<mup> PR snapd#2542 opened: many: use snap-confine to save cost of repackaging core snap for testing <Created by zyga> <https://github.com/snapcore/snapd/pull/2542>
<mup> PR snapd#2543 opened: spread: install build-essentail unconditionally <Created by zyga> <https://github.com/snapcore/snapd/pull/2543>
<mup> Bug #1614587 changed: unable to run snapd on ubuntu 14.04 <Snappy:Invalid> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1614587>
<mup> PR snapd#2544 opened: interfaces: implement login-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/2544>
<mup> PR snapd#2543 closed: spread: install build-essentail unconditionally <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2543>
<mup> PR snapd#2545 opened: overlord: allow max 100 changes in "ready" state to avoid boundless grow <Created by mvo5> <https://github.com/snapcore/snapd/pull/2545>
<Guest1768> hi...just a question..the version for raspberry pi 3, is a 64-bit os?
<snap_user4> Is there an official web service to search for snap packages? I know about uappexplorer.com but it's not official and is only for ubuntu touch apps.
<snap_user4> How can I get information about a snap package? For example with `apt` I would do `apt show <package>`. I don't see any snap command to do that in the help section.
<Elleo> snap_user4: there's the info command: "snap info <snapname>"
<snap_user4> `snap --help | grep info` shows nothing
<snap_user4> `error: unknown command "info", see "snap --help"`. my snap version 2.17.1ubuntu1 do I need to be on bleeding edge or something to get that feature ?
<Elleo> snap_user4: ah, I'm using 2.19, so I guess it was introduced recently
<snap_user4> Elleo: Where did you install your snapd, from source? I tried upgrading my snapd `sudo apt install -y snapd` but I'm already at the latest version
<Elleo> snap_user4: yeah, I've got a git checkout
<snap_user4> Elleo: Alright thanks, I guess I'll wait for a stable package to be released
<popey> snap_user4: uappexplorer does index snaps as well as touch apps
<zyga> snap_user4: snapd 2.20.1 is in -proposed, try that version if you want
<snap_user4> zyga: Thanks, that version seems to be available for ubuntu 16.04 https://launchpad.net/ubuntu/+source/snapd. I tried `apt install snapd=2.20.1` but it seems apt can't find the version. I know this question isn't really related to snaps but do you know how I could install it with apt?
<almightybob> Trying to install snapd in new Fedora 25 install.  Keep getting: 'Failed to synchronize cache for repo 'zyga-snapcore', disabling.'
<almightybob> Anybody else run into this?
<zyga> snap_user4: hey, you need to enable the proposed repository directly, https://wiki.ubuntu.com/Testing/EnableProposed
<zyga> almightybob: hey, the copr repo is abandoned and development has moved to the fedora archive directly
<zyga> almightybob: I'm EOD now so it's not the best time but ping me tomorrow, there are a few outstanding issues that prevent me from releasing snapd into fedora
<zyga> almightybob: and I could use some help
#snappy 2017-01-03
<MarkB2> Could someone refer me to a URL having a guide on installing UBuntu Linux to an external USB-HDD ?
<mup> Bug #1634089 opened: Cannot activate Chinese input method for Qt app <Snappy:New for jdstrand> <https://launchpad.net/bugs/1634089>
<mup> PR snapd#2540 closed: tests: fix mkversions.sh failure on zesty <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2540>
<mup> PR snapd#2545 closed: overlord: allow max 100 changes in "ready" state to avoid growing changes for 24h <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2545>
<mup> PR snapd#2545 opened: overlord: allow max 100 changes in "ready" state to avoid growing changes for 24h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2545>
<mup> PR snapd#2546 opened: overlord: use a ticker for the pruning <Created by mvo5> <https://github.com/snapcore/snapd/pull/2546>
<mup> PR snapd#2512 closed: Release snapd 2.20.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2512>
<mup> PR snapd#2547 opened: To allow access disk partition from efivar library with mmc and other platform specific drivers interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/2547>
<mup> PR snapd#2377 closed: snap: provide friendlier `snap find` message when no snaps are found <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2377>
<mup> PR snapd#2527 closed: tests: fix -reuse and -resend when govendor is missing <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2527>
<cking> any ideas why I'm seeing "binary_filesize: This field is required." when I try and upload the bcc snap?
<cking> looks like it's been reported here: https://bugs.launchpad.net/software-center-agent/+bug/1649946, it is blocking me uploading the bcc snap, so it's a show stopper for me
<mup> Bug #1649946: race condition in uploader widget  <Software Center Agent:New> <https://launchpad.net/bugs/1649946>
<mup> Bug #1653648 opened: classic does not properly unmount /dev/pts on exist <Snappy:New> <https://launchpad.net/bugs/1653648>
<mup> PR snapd#2548 opened: snap: show `snap --help` output when just running `snap` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2548>
<mup> PR snapd#2518 closed: many: put a marker in the User-Agent sent by snapd/snap when under testing <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2518>
<ogra_> xnox, hmm, seeing bug 1651947, do you also plan to backport the transition to the LTSes (xenial mainly so we can have it in the snappy images)
<ogra_> (i assume "transition" just means pointing urandom to the new file)
<mup> Bug #1651947: installer ought to install a proper random-seed <livecd-rootfs (Ubuntu):Confirmed> <ubiquity (Ubuntu):Confirmed for xnox> <https://launchpad.net/bugs/1651947>
<liuxg> sergiusens, is this a problem in the snapcraft tool? I am now still stuck here. https://bugs.launchpad.net/snapcraft/+bug/1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:New> <https://launchpad.net/bugs/1650946>
<xnox> ogra_, i've based my comment on the xenial systems.
<xnox> ogra_, i see that on my xenial desktop systemd-seed-random.service is used and expects /var/lib/systemd/seed-random.
<xnox> ogra_, i expect more of "fix broken stuff" rather than "transition pointlessly from one name to another"
<ogra_> welll, i just noticed that we ship both in snappy ... do you mean /var/lib/systemd/seed-random will be properly seeded regardless ?
<xnox> ogra_, what i mean is that /var/lib/urandom/seed-random is not used at all in xenial by anything (e.g. it is not read, not loaded into random pool on boot)
<xnox> however, let me check initramfs hooks too.
<ogra_> (iirc we use a generator that transitions sysv jobs over to systemd units on first start)
<xnox> ogra_, but urandom.service masks urandom init.d script, and thus only systemd-seed-random.service is in use.
<xnox> e.g. $ systemctl status urandom -> gives the status output for systemd-seed-random.
<ogra_> ah, k
<ogra_> then we're fine
<mup> PR snapcraft#1021 closed: integration tests: add alias integration test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1021>
<mup> PR snapcraft#1012 closed: travis.yaml: use docker exec to split build phases <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1012>
<mup> PR snapd#2370 closed: i18n: use github.com/mvo5/gettext.go (pure go) for i18n to avoid cgo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2370>
<shuduo> sergiusens: hi, according to your blog i tried to reproduce UC16 image for dragonboard. but the booting interrupted. i have reported a bug https://bugs.launchpad.net/snappy/+bug/1652617. Anything wrong i made?
<mup> Bug #1652617: customized dragonboard image cannot complete booting <Snappy:New> <https://launchpad.net/bugs/1652617>
<sergiusens> shuduo that post is rather old, might need some updating to get the right toggles in place
<shuduo> sergiusens: do you mean snapcraft-examples/examples/96boards-kernel need update too?
<sergiusens> shuduo if it does, we welcome a PR
<shuduo> sergiusens: there is a customer working on their community kernel by referring the blog but stuck there now. any quick way to fix or workaround? thanks
<mup> PR snapcraft#941 closed: sources: support symlinks in deb sources <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/941>
<mup> PR snapcraft#727 closed: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/727>
<mup> PR snapcraft#972 closed: ci: add a checklist in the pull request template <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/972>
<sergiusens> shuduo no, not really I haven't touched anything kernel in more than 9 months, maybe ogra_ can help
<ogra_> well, i can obnly point you forward to the kernel team
<ogra_> given how old the blocg post is it is well possible that things changed regarding the default config etc
<shuduo> ogra_: could you let someone of kernel team in #snappy know? :)
<ogra_> well, ppisati seems to still be on vacation
<ogra_> (at least i dont see him here)
<shuduo> ogra_: okay. let me wait ppisati back.
<shuduo> ogra_: maybe EXT4_FS need be builtin to fix. i  will try
<ogra_> shuduo, hmm, looking at the bug ... do you actually have a filesystem labelled "writable" on the SD at all ?
<liuxg> sergiusens, ping
<ogra_> also note that the gadget snaps from github are still untested ... did you try using the gadget from the stable channel instead ?
<ogra_> (you are building with two modified snaps there, i'd try with one only first so you can rule out that something is broken by the combination of them)
<liuxg> sergiusens, when I build my classic snap project, it shows sth like http://imgur.com/a/zJbCk
<mup> PR snapd#2549 opened: cmd/snap-confine: add shutdown helper <Created by chipaca> <https://github.com/snapcore/snapd/pull/2549>
<shuduo> ogra_: http://pastebin.ubuntu.com/23733760/
<ogra_> heh, parted -l .... (-l is a fdisk flag,. parted needs "print", that is why it prints sda too)
<ogra_> well, the Sd looks fine to me
<ogra_> so yeah, try with building in ext4 ...
<shuduo> ogra_: i also tried launchpad's  lp:~snappy-dev/snappy-hub/snappy-systems but no luck. good point to use stable channel's
<ogra_> and really try with the gadget from the store first
<ogra_> i.e. just drop --extra-snaps dragonboard_16.04-0.18_armhf.snap
<ogra_> that will make it pull the one from the store
<ogra_> while you're at it. vfat needs to be builtin too
<alf_> mvo: Hi! I was looking at upower_observe.go interface and noticed that it only supports running upowerd unconfined (i.e. plug rules have label=unconfined). Is this on purpose, or just not updated yet to support non-classic?
<shuduo> ogra_: okay i will try them as your suggest. thanks
<ogra_> good luck
<liuxg> elopio, do you still have the reported problem in your place? https://bugs.launchpad.net/snapcraft/+bug/1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
<alf_> jdstrand: ^^ see question to mvo above
<mvo> alf_: sorry, I defer to jdstrand for this one
<alf_> mvo: sure, thanks
<elopio> liuxg: not sure. I will retry today.
<liuxg> elopio, OK. I am still having the problem. I am not sure whether it is related to any installation.
<elopio> jdstrand: hey, I heard you were having troubles with your rocket account. Did you solve them? I can't log in.
 * ogra_ had that too ... solved it by remembering that i had created the login before SSO was enabled on the rocket server .... normal username/passwd login worked for me 
<ogra_> it is pretty misleading that it always wants to take you to SSO immediately
<elopio> ogra_: username/password doesn't work for me. Neither password recovery.
<ogra_> wow, thats bad
<morphis> jdstrand: ping
<mup> PR snapd#2129 closed: interface hooks: prepare plug slot hooks (step 1) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2129>
<mup> PR snapd#2547 closed: To allow access disk partition from efivar library with mmc and other platform specific drivers interface <Created by timchen119> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2547>
<mup> PR snapd#2209 closed: interface hooks: confirm plug slot hooks (step 2) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2209>
<mup> PR snapcraft#1023 closed: nodejs plugin: fix the pluginâs dependency installation <Created by jonathon-love> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1023>
<mup> PR snapd#2550 opened: interface hooks: connect plug slot hooks (step 2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2550>
<mup> Bug #1634089 changed: Cannot activate Chinese input method for Qt app <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1634089>
<jdstrand> alf_ (cc mvo): regarding upower-observe and unconfined: the interface is currently only designed for classic (and thus, unconfined), which is why it is currently in implicitClassicSlots in snap/implicit.go. upowerd does not exist in the core snap so a slot implementation (and corresponding updates to the interface) would need to be implemented.
<jdstrand> elopio: re rocket> it worked fine once I stopped trying to use sso
<jdstrand> morphis: hey
<alf_> jdstrand: morphis is working on upower-control which contains a slot part. If that lands, is then the next step is to update upower-observer for non-classic? (e.g. ###SLOT...### vars?)
<jdstrand> alf_: yes, though it could be part of the same PR
<mup> Issue snapd#2538 closed: Stop the download of the snap package <Created by sidahmed-malaoui> <Closed by sidahmed-malaoui> <https://github.com/snapcore/snapd/issue/2538>
<morphis> alf_: if I forgot that, let me fix that tomorrow
<morphis> jhodapp: first, happy new year and I hope you had a good time off :-)
<iLembus_> anyone here knows details about Ubuntu Snappy Core?
<iLembus_> I'd like to install it on an Raspberry Pi 3
<iLembus_> but the first boot needs to be guided with a display device
<iLembus_> i dont have such a thing
<iLembus_> any chance i can ssh into it?
<kyrofa> iLembus_, unfortunately SSH is only enabled after the first boot
<iLembus_> kyrofa: isn't there like a special edition i could use which enabled a default-configured ssh?
<iLembus_> kyrofa: any alternative?
<kyrofa> ogra_, is console conf made available over serial?
<iLembus_> kyrofa: i only want a small and stable device to install ownCloud
<kyrofa> iLembus_, yeah fair enough-- the default images have no default passwords, which is why that first boot experience exists. But indeed, if you make your own image you can do whatever you like with it
<Chipaca> iLembus_, not even a serial cable?
<kyrofa> Chipaca, I'm not 100% certain that is available on serial (though it should be)
<kyrofa> I've seen a few people mention it doesn't work
<kyrofa> Have you tried it?
<Chipaca> that was my next question (to ogra_)
<Chipaca> it used to work, i haven't tried it in a while though
<Chipaca> it works in qemu :-D
<kyrofa> iLembus_, have you tried that?
<Chipaca> bah, last time i tried it which was a few weeks ago also :-)
<ogra_> kyrofa, yes, indeed
<ogra_> console-conf is replacing all tty jobs until it was run one
<ogra_> *once
<mup> Issue snapd#2510 closed: spread tests fail when invoked in a sub-directory (generate-packaging-dir) <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2510>
<mup> PR snapd#2511 closed: spread: find top-level directory before running generate-packaging-dir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2511>
<ogra_> so it will be available on all possible consoles, including serial
<kyrofa> ogra_, alright very good, thank you!
<ogra_> (and i know it definitely works on stable images, i tested it there last release)
<kyrofa> iLembus_, that's probably your best bet, then
<ogra_> no idea about edge though ... i havent touched them in a while
<mup> PR snapcraft#986 closed: parser: clean up help <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/986>
<elopio> ogra_: how can I change the /etc/os-release of snappy? Where does it come from?
<ogra_> elopio, from under mvo's desk ;)
<ogra_> elopio, it is set hard-coded in livecd-rootfs during the build of the core snap, i dont think there is a way to change it despite re-squashing
<Cust0sLimen> hi
<ogra_> elopio, http://paste.ubuntu.com/23734598/
<ogra_> elopio, what needs changing ?
<Cust0sLimen> is there some place where I can see available snaps ?
<Cust0sLimen> want to know if there is current vlc snap
<Cust0sLimen> nvm
<Cust0sLimen> https://uappexplorer.com/apps?type=snappy
<Cust0sLimen> hmm
<Cust0sLimen> only see vlc daily
<Cust0sLimen> is there like vlc 2.2.4 ?
<elopio> ogra_: it has an extra "
<elopio> VERSION_ID="16""
<kyrofa> Cust0sLimen, indeed, all I see is daily as well. Note that they are published by videolan, though-- probably a question for the
<kyrofa> m
<ogra_> elopio, yeah, i see it ... fixing (for edge though)
<elopio> ogra_: could you get it from a repository during the build?
<elopio> not a big deal now that you will fix it, but it would be nice to know where it is defined, and be able to propose changes there.
<ogra_> elopio, http://paste.ubuntu.com/23734727/ uploaded ... will be in tomorrows edge core snap
<elopio> ogra_: thank you!
<ogra_> elopio, you can file a snappy bug and open a livecd-rootfs task next time and assign to mvo or me ... we are usually the only ones caring for that package in that context
<ogra_> that package lives fully in the image PPA though ... and it isnt really easy to trace back that the change came from  a script during build ... so IRC ping is probably still the best bet
<elopio> ogra_: I had time to play with my beagle during the holidays :) I have a few questions for you, but I'm first trying to not drown in my inbox. I'll be bothering you later in the week :)
<ogra_> elopio, dont hold back ;)
<mup> Bug #1653769 opened: Missing keyring interface <Snappy:New> <https://launchpad.net/bugs/1653769>
<lololollolololol> yo'
<lololollolololol> l,,,,,,,llllllllllll,
<lololollolololol> l
<lololollolololol> l
<lololollolololol> k
<lololollolololol> k
<lololollolololol> ]j
<lololollolololol> j
<lololollolololol> jk
<lololollolololol> k
<lololollolololol> j
<lololollolololol> j
<lololollolololol> i
<lololollolololol> 0
<lololollolololol> o\o
<lololollolololol> lo
<lololollolololol> lo
<lololollolololol> l
<lololollolololol> l
<lololollolololol> o/o
<lololollolololol> ;
<lololollolololol> ;
<lololollolololol> ;
<lololollolololol> oop
<lololollolololol> ;
<lololollolololol> '
<kyrofa> JamieBennett, ^^
<lololollolololol> op
<mup> PR snapcraft#971 closed: tests: fix integration tests in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/971>
#snappy 2017-01-04
<mup> PR snapcraft#1006 closed: schema: replace `snap` filter with `prime` filter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1006>
<mup> PR snapcraft#1014 closed: tests: reorganize plugin tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1014>
<liuxg> elopio, have you checked the reported "classic confinement requires the core_dynamic_linker to be set"? I just installed a container, and I found the same issue
<mup> Bug #1653851 opened: no way to avoid CDN for assertions.ubuntu.com within launchpad builds <Snappy:New> <https://launchpad.net/bugs/1653851>
<mup> Bug #1653852 opened: Cannot activate Chinese input method for Qt app even in the devmode <Snappy:New> <https://launchpad.net/bugs/1653852>
<liuxg> elopio, I have tried to build it in yaketty container, and I have the same issue. What is your finding? thanks
<mup> PR snapd#2492 closed: cmd/snap: remove currency switch following UX review <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2492>
<mup> PR snapd#2549 closed: cmd/snap-confine: add shutdown helper <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2549>
<davidcalle> Morning and happy new year! Is it expected that on 2.20.1+17.04ubuntu2 , network-bind doesn't auto-connect?
<davidcalle> mvo ^
<davidcalle> (or zyga ? ^)
<liuxg> davidcalle, network-bind needs to have mannual connect? according to the spec, http://snapcraft.io/docs/reference/interfaces, it should be.
<davidcalle> liuxg: I know, that's why I'm asking why it's not auto-connecting anymore
<topi`> I'm trying to build os/kernel/gadget snaps for an unsupported device (Hummingboard), any idea how to "cache" the always-recurring download of ubuntu-core when running "snapcraft"?
<topi`> no matter how little I change, it always re-downloads it
<davidcalle> sergiusens: ^
<jamespage> jdstrand, ok so I've had some good success with the new network-namespace support in network-control with the nova-hypervisor snap
<jamespage> jdstrand, the nova-hypervisor snap almost works in strict mode now
<jamespage> jdstrand, looking at the remaining syslog DENIED messages, the remaining issues look related to processes wanting to drop privs for things like dnsmasq
 * jamespage is frustratingly close to having this working...
<mup> PR snapd#2551 opened: refactore store.Snap to take a spec struct <Created by chipaca> <https://github.com/snapcore/snapd/pull/2551>
<kalikiana_> topi`: Does the core snap show as being installed? Does "snap changes" say anything dubious?
 * kalikiana_ has no idea about that device, but checking those should be a good start
<mup> PR snapcraft#1015 closed: tests: reorganize command tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1015>
<mcphail> kyrofa: are you still maintaining the nextcloud snap? If I install it, in preference to a manual nextcloud install, what restrictions would I be likely to face? Can I, for example, use Let's Encrypt etc?
<mup> Issue snapd#2552 opened: snapd is not tested with against Arch Linux <Created by zyga> <https://github.com/snapcore/snapd/issue/2552>
<kalikiana_> Hrm. Getting "...changes in progress..." error and nothing in 'snap changes'. I hate it when that happens.
<mup> Bug #1653955 opened: Access to /dev/shm/sem.snap.@{SNAP_NAME}.* should be allowed for semaphores to work <Snappy:New> <https://launchpad.net/bugs/1653955>
<mup> Issue snapd#2553 opened: snapd is not tested against Debian <Created by zyga> <https://github.com/snapcore/snapd/issue/2553>
<popey> mcphail: http://flexion.org/posts/2016-12-raspberry-pi-3-powered-nextcloud-box-on-ubuntu-core - i used that guide to add letsencrypt
<mcphail> popey: thanks. That looks clever. Didn't realise there were helper scripts in the snap. Do you know if you can dd extra apps like the calendar app etc? Not sure how the snap would handle that...
<mcphail> *add
<popey> mcphail: i think so, yes. I added an app as part of that guide
<didrocks> pedronis: hey! I was wondering if when providing required-snaps, I could make one installed in devmode?
<pedronis> didrocks: you can say --devmode for everything but it's probably going to change again
<pedronis> didrocks: anyway is something you pass/would pass to ubuntu-image, not something that goes into the model assertion
<pedronis> didrocks: we have a open task about clarifying/fixing this
<pedronis> didrocks: mvo started to look into that
<didrocks> pedronis: hum, so, in the model assertion, I should put the snap name
<didrocks> pedronis: and in ubuntu-image, there is a devmode option?
<pedronis> didrocks: yes, just the snap name
<pedronis> didrocks: there should be but might not work atm
<mcphail> popey: excellent. Ta
<pedronis> as I said bit of wip atm
<didrocks> pedronis: ok, I think this isn't going to work for our workshop deadline thus
<didrocks> pedronis: I'll keep on "this does not work thus"
<didrocks> :)
<mup> PR snapcraft#1019 closed: tests: reorganize state tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1019>
<mup> PR snapcraft#973 closed: ci: check the license agreement on Travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/973>
<mup> PR snapd#2551 closed: refactor store.Snap to take a spec struct <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2551>
<mup> PR snapd#2554 opened: tests: add end-to-end store test for classic confinement <Created by mvo5> <https://github.com/snapcore/snapd/pull/2554>
<liuxg> sergiusens, ping
<sergiusens> liuxg hey
<jacekn> hello. What's the best way to create new directory in my snap package using snapcraft.yaml? I need to ship it with empty directory but can't find a way to do it, thought dump plugin woudl do it but does not look like it
<liuxg> sergiusens, regarding the bug https://bugs.launchpad.net/snapcraft/+bug/1650946, I tried to compile my sample project using LXD, and I had the same issue. What could be reason for it? thanks
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
<liuxg> sergiusens, I checked it with my colleague and it worked under 17.04.
<sergiusens> liuxg oh, does snap list show `core` in there? if not, `snap install core`
<sergiusens> and tell me if that works
<liuxg> sergiusens, http://paste.ubuntu.com/23739129/, this is the list
<liuxg> sergiusens, I think ubuntu-core is there already
<sergiusens> liuxg I didn't need the list ;-) And no it is not, `ubuntu-core` != core
<sergiusens> so `snap install core`
<liuxg> sergiusens, oh, I see your point. However, I got an error http://paste.ubuntu.com/23739153/. Should I remove ubuntu-core first?
<liuxg> sergiusens, I am wondering what is the difference between "core" and "ubuntu-core". Are they the same thing? Sorry, this is the first time I tried to install core.
<sergiusens> liuxg I don't know about that, I have both at the same time. But you need that for classic snaps to be buildable
<sergiusens> core replaces ubuntu-core
<sergiusens> liuxg you will need to ask someone in the snapd (core team) about this
<liuxg> sergiusens, so, I should remove the "ubuntu-core" first in order to install "core".
<liuxg> sergiusens, by the way, who is from the snapd team?
<sergiusens> mvo zyga ^
<sergiusens> liuxg you can get by this by `snap install core` in a clean lxd container and build there
<liuxg> sergiusens, OK. I will try it. thanks
<mvo> liuxg: ubuntu-core and core are currently mostly identical except the name, we will transition ubuntu-core to core at some point but thats not done yet
<sergiusens> mvo right, classic confined snaps require having core installed to build and eventually run
<liuxg> mvo, the thing is that classic needs to have "core" instead of "ubuntu-core", right? I cannot remove the "ubuntu-core" for now in my 16.04 system. Can I get them both co-exist in order to test classic?
<sergiusens> seems an addition to not allowing both installed was added recently
<liuxg> sergiusens, mvo, the problem is that how can I test it on 16.04 OS. By default, "ubuntu-core" is installed on my machine. when i tried to remove "ubuntu-core", it complains "error: cannot remove "ubuntu-core": snap "ubuntu-core" is not removable"
<mvo> liuxg: thats a bug then in classic mode, it should work with either ubuntu-core and core, let me have a look
<mvo> liuxg: plus it should be possible to exachange the two, thats another bug :/
<sergiusens> mvo it actually isn't possible, we designed it that way with zyga
<liuxg> mvo, thanks! I never got it working. could you please see the bug report at https://bugs.launchpad.net/snapcraft/+bug/1650946?
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
<sergiusens> mvo the linker used is hard coded in the elf headers
<mvo> sergiusens: oh, ok. so then we need to make it possible to remove ubuntu-core
<mvo> sergiusens: I have a look
<pedronis> mvo: that is a bit problematic in other ways, IÂ think we wanted to allow that but only if there are no other snaps installed (on classic)
<pedronis> IÂ mean to remove core/ubuntu-core
<mup> Bug #1653988 opened: no soundcore in linux-raspi2  <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1653988>
<mvo> pedronis: aha, I see, to avoid that people break their system? I guess "snap install core and remove ubuntu-core" would be nice :)
<pedronis> mvo: yes, to avoid people breaking stuff without thinking
<pmcgowan> mvo, is there a workaround to the issue discussed above? can I just rm the /snap/ubuntu-core folder?
<mvo> pmcgowan: cleanest workaround is to purge snapd (the deb) and then snap install core as the first operation
<pmcgowan> OK
<popey> mvo: that requires removal of all snaps?
<mvo> popey: unfortunately, we work on something better but its not there yet
<popey> ok
<jdstrand> niemeyer: hi! I'm not up on everything for 'aliases'. I need to add support to the review tools and was wondering if declaring aliases should prompt for manual review. My understading is 'no' since the aliases are applied by the user unless there is an auto-alias in the store
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Happy new year (to all!)
<niemeyer> jdstrand: Yeah, it shouldn't prompt for manual review.. the idea is that people can experiment with aliases without the burden of involving reviews
<niemeyer> jdstrand: We then need a way for people to ask for aliases
<niemeyer> ask for auto-aliases, that is
<niemeyer> Which is just an explicit whitelist of a particular alias that may (and may not!) be in the snap
<jdstrand> niemeyer: ok, thanks. fyi, cprov showed me today that the store already has support to grant auto-aliases. I don't know the status/plans for how to request them
<jdstrand> I mean, putting them in the yaml is a form of request, but I don't think that is what you were talking about
<niemeyer> jdstrand: Yeah, that's no tit
<niemeyer> jdstrand: As long as you can edit them, we can take bugs as requests for the time being
<jdstrand> niemeyer: sounds good
<ogra_> sudo apt install fakeroot
<ogra_> bah !
<longsleep> ogra_: hey any idea how and whom to contact so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1652262 can be resolved rather sooner than later? For me right now its pretty unclear how extra dependencies for stuff added to ubuntu-core are handled. I remember there was some ppa which got pulled in during rootfs build in the past.
<mup> Bug #1652262: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
<ogra_> heh, i just saw someone comment on it
<longsleep> ogra_: yeah me too, thats why i rememberd to ask you :)
<ogra_> longsleep, usually subiquity is mwhudson's baby
<ogra_> might be that he is still on EOY vacation though
<longsleep> ogra_: yes but the fix is in a dependency of subiquity - i wonder how these get pulled in
<ogra_> oh ?
 * ogra_ checks the bug 
<longsleep> ogra_: fix is in https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a
<longsleep> ogra_: so in the probert python module
<ogra_> longsleep, ah, well, that might be a cyphermox package (though mwhudson tends to touch it too)
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> last probert upload for xenial is from nov. 10th though
<longsleep> ogra_: ah yeah that was the repo - good to know that this is still used
<longsleep> ogra_: yeah so what needs to happen to get probert updated eventually is the question
<ogra_> yeah, sadly it is ... i'll work my way throuhg SRUs the next weeks
<ogra_> technically all these packages need SRUing
<ogra_> longsleep, you either catch mwhudson or cyphermox to upload a new version to that PPA
<longsleep> ogra_: ok - great  thanks!
<ogra_> longsleep, if you dont get any answers before EOW, ping me again and we can see what to do (i would just upload a fixed package but i dont want to break any processes the guys have in place)
<longsleep> ogra_: yeah no hurry - i can wait until they have time
<mup> PR snapd#2555 opened: many: implement 'snap aliases' <Created by pedronis> <https://github.com/snapcore/snapd/pull/2555>
<mup> PR snapd#2556 opened: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <https://github.com/snapcore/snapd/pull/2556>
<mup> PR snapcraft#989 closed: pluginhandler: add support for disabling system library migration <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/989>
<elopio> ev_: I heard you can help me with my rocket chat account. I can't log in.
<ev_> elopio: hey! sorry for not getting back to you on Telegram
<ev_> Iâm not actually an admin on RocketChat
<elopio> ev_: Also, I'll have a meeting with shadow tomorrow at 14:30 UTC. What to join us?
<ev_> no idea who keeps pointing people in my direction
<elopio> ev_: ^_^
<ev_> shadow> yes please!
<elopio> sabdfl: do you know who is admin in rocket chat?
 * ogra_ gives up for the day ... this extrausers group stuff makes my brain hurt ... 
<ogra_> (but we'll eventually have lxd working on core images at least ... )
<kyrofa> elopio, in our snaps tests, are we using the ubuntu-core snap or the core snap?
<kyrofa> (i.e. is it a clean install)?
<mup> Issue snapd#2557 opened: Serial Port Plug/Interface issue with Ubuntu-core 16.04 <Created by mrsinghgit> <https://github.com/snapcore/snapd/issue/2557>
<ogra_> hopefully the latter
<elopio> kyrofa: it is a clean install. But sergiusens forced one test to install core if it wasn't installed before.
<kyrofa> elopio, ah! Excellent
<Cust0sLimen> hi
<Cust0sLimen> how poorly will snappy work with firewalld ?
<kyrofa> Cust0sLimen, I expect it just needs to be properly packaged with the right interfaces
<Cust0sLimen> kyrofa, well ... let me put it like this rather ... if I use firewalld on ubuntu ... will snappy stop working ?
<kyrofa> Cust0sLimen, ah, indeed I misunderstood the question
<kyrofa> Cust0sLimen, I don't see why that would interfere with snappy. What makes you suspect that it will?
<Cust0sLimen> so there is this: http://snapcraft.io/docs/reference/interfaces - "firewall-control - Can configure network firewalling giving privileged access to networking."
<kyrofa> Yeah, if you have a snap installed that utilizes that interface you might run into issues
<Cust0sLimen> kyrofa, :/
<kyrofa> Cust0sLimen, run `snap interfaces` to check that
<kyrofa> Cust0sLimen, it would be like having both ufw and firewalld installed
<Cust0sLimen> why could ubuntu not just be fedora without stupid rules that result in not having ffmpeg ;(
<Cust0sLimen> kyrofa, I have no snaps at the moment
<Cust0sLimen> just pessimistic
<kyrofa> Cust0sLimen, then you should have no issues
<Cust0sLimen> kyrofa, I might have some installed later though
<kyrofa> Cust0sLimen, just don't install a firewall snap then, and you should be fine
<jdstrand> Cust0sLimen: the firewall-control interface you referenced in the documentation is something that a snap may request, not what snappy necessarily controls. in other words, if your system uses firewalld, you'll have no problems with snappy. if you install the ufw or some other firewall snap and use it, they might conflict with each
<jdstrand> other
<jdstrand> Cust0sLimen: this is no different than trying to install two different firewall applications via rpm and eb and using them at the same time
<jdstrand> s/and eb/or deb/
<jdstrand> Cust0sLimen: so, basically, what kyrofa said: if you don't install a firewall snap, you should have no issues
<jdstrand> roadmr: hi! can you pull r814? it adds 'aliases' support to the review tools among other things
<roadmr> jdstrand: sure thing
<roadmr> jdstrand: (happy new year :)
<jdstrand> roadmr: thanks! and happy new year to you too :)
<wswartz> Hello.  I was wondering if anyone knew what the various flavors (Gnome, KDE, etc) were planning to also be Snap-based?
<mup> PR snapd#2556 closed: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2556>
<mwhudson> longsleep: hi
<longsleep> mwhudson: hey
<mwhudson> longsleep: you want a probert upload?
<longsleep> mwhudson: yeah would be awesome to have probert with the wifi stuff try/except change in edge asap
<mwhudson> alright
<longsleep> mwhudson: i still do not know why it fails with my kernel though as my test code works just fine in classic ubuntu
<longsleep> mwhudson: but the try/except fix would unblock me to hopefully get a working edge image for further testing
<mwhudson> longsleep: with the same kernel?
<mwhudson> that is pretty odd
<mwhudson> longsleep: does your board actually have wifi?
<longsleep> mwhudson: yes, different builds though
<longsleep> mwhudson: yes board has wifi / iw works just fine as well
<mwhudson> longsleep: how odd
<mwhudson> anyway, i'll get the fix uploaded
<longsleep> mwhudson: did you see my test program - maybe you can spot a difference - or probert runs in some confinment when started on snappy boot
<longsleep> mwhudson: awesome - most appreciated thanks
<longsleep> mwhudson: btw if i might suggest an improvement to https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a#commitcomment-20335990 - it should say that it cannot start the nl80211 listener instead of just the listener imho
<mwhudson> it says wlan_listener?>
<longsleep> ah right, wouldnt be nl80211 wlan_listener better? After all there is also the rtnetlink wlan listener?
<mwhudson> there's nothing wlan about the rt listener
<longsleep> oh
<mwhudson> i agree it's a bit obscure
<longsleep> right - then i guess its just my misunderstanding
<mup> PR snapcraft#1025 opened: project loader: better error message for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
<mwhudson> longsleep: uploaded, should be in the next edge build
<longsleep> mwhudson: very nice thank you!
<longsleep> mwhudson: i just rebuilt probert from source on classic ubuntu on that kernel to see if i can reproduce the original issue there
<mwhudson> longsleep: that would be interesting
<mwhudson> longsleep: you can just run python3 probert/network.py
<mwhudson> (after python3 setup.py build_ext -i)
<longsleep> mwhudson: yeah on it, need some extra python modules installed first
<longsleep> mwhudson: what do you make of this http://paste.ubuntu.com/23741215/ ?
<mwhudson> longsleep: well that's interesting
<longsleep> mwhudson: thats not the same error as when run through subiquity though
<mwhudson> yeah
<mwhudson> pretty odd though, is the device actually up already?
<longsleep> mwhudson: ifconfig shows wlan0 and wlan1 it as up yes
<mwhudson> longsleep: can you hack network.py:435 to print link.flags?
<longsleep> mwhudson: sure hold on
<mwhudson> it shouldn't be trying to up the device if it's already UP
<mwhudson> um i guess printing ifindex would be useful too
<longsleep> mwhudson: mhm magic print makes it work - no error this time
<longsleep> let me down it again
<mwhudson> hah uh maybe some kind of race maybe
<mwhudson> longsleep: wait, you have two wifi devices? i haven't tried it in that situation, maybe there is some confusion
<longsleep> ah yeah if its down before
<mwhudson> shouldn't be but who knows
<longsleep> yeah two
<longsleep> that driver creates two interfaces for a single card
<mwhudson> oh right
<longsleep> mwhudson: xxx (5, 1)
<mwhudson> so i bet when you up one, the other gets implicitly upped too
<longsleep> 5 is the index and 1 is the flags
<longsleep> mwhudson: ah yeah thats true
<longsleep> mwhudson: i usually disable the second device in interfaces
<mwhudson> and probert tries to up both and something complains
 * mwhudson waves hands
<mwhudson> longsleep: wait what, the flags are 1 for the call that crashes?
<longsleep> mwhudson:  yes - full output at http://paste.ubuntu.com/23741260/
<longsleep> mwhudson: if i run it again without downing the interfaces first, no error
 * mwhudson tries to remember how to find out what -16 means
<mwhudson> longsleep: can you pastebin git diff, to be sure?
<mwhudson> oh
<mwhudson> #define NLE_SEQ_MISMATCH	16
<longsleep> +                print("xxx", (ifindex, IFF_UP))
<mwhudson> longsleep: oh
<mwhudson> longsleep: link.flags, not IFF_UP :)
<longsleep> err sorry
<longsleep> mwhudson: link.flags is 4098 for both errors
<mwhudson> longsleep: thanks
<longsleep> mwhudson: http://paste.ubuntu.com/23741285/
<mwhudson> longsleep: but anyway, the wlan_listener is starting ok?
<mwhudson> eh it must be
<longsleep> mwhudson: well no other error and it shows a bunch of networkinfo objects
<mwhudson> longsleep: and the interfaces are up after you run probert?
<longsleep> mwhudson: yes
<mwhudson> then i don't know what is going on but it seems harmless
<longsleep> mwhudson: xxx wlan_listener started (<_nl80211.listener object at 0x7fa91f3b88>,)
<mwhudson> longsleep: cool
<mwhudson> if still mysterious why it doesn't work with snappy
<longsleep> mwhudson: ok, but it confirms that wlan listener starts fine on classic ubuntu, same kernel except that one is manual build and the other is built by snapcraft
<longsleep> mwhudson: fyi - kernel snap is built with this https://github.com/longsleep/build-pine64-image/blob/master/snappy/kernel/snapcraft.yaml
<longsleep> mwhudson: and the classic kernel is also built only with sun50iw1p1smp_linux_defconfig config
<mwhudson> longsleep: can you do this: http://paste.ubuntu.com/23741362/ re-down the interfaces and run network.py again?
<mwhudson> uh after running build_ext -i
<mwhudson> pastebin the output, there will be a lot of it
<longsleep> mwhudson: sure hold on
<longsleep> oh wow thats a lot of output
 * longsleep installs pastebinit
<longsleep> mwhudson: http://paste.ubuntu.com/23741380/
<mup> PR snapcraft#1010 closed: meta: add 'desktop' entry for apps <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1010>
<cliftonts> Evening everybody
<cliftonts> I'm having an issue packaging up a python script, is there anybody here who might be able to point out where I'm going wrong?
<kyrofa> cliftonts, sure! What's up?
<cliftonts> Initially it was building but the installed snap was saying it couldn't find python
<kyrofa> cliftonts, which plugin were you using?
<cliftonts> Mark Shuttleworth suggested I change the python location stated in the script, now it just loads the python interpreter.
<cliftonts> my snapcraft.yaml is here: http://paste.ubuntu.com/23741430/
<kyrofa> cliftonts, the python plugin pulls in python2-- is that the one you want?
<cliftonts> My script will work with either 2 or 3
<kyrofa> cliftonts, ah, but you have no setup.py or anything
<cliftonts> for what purpose?
<kyrofa> cliftonts, to tell snapcraft (or users, for that matter) about your project's dependencies and where it should be installed
<kyrofa> cliftonts, I'm referring to the RokuTerm project itself
<kyrofa> We still might be able to get this to work, hold on a sec
<cliftonts> I am not the most experienced at this. I've never been able to package an app. Tried with deb for 2 years and gave up!
<cliftonts> So please forgive me if I'm doing things in an odd way.
<kyrofa> cliftonts, that's alright, you're just about there :)
<cliftonts> It's one of those things that's impossible until you've done it once I think.
<kyrofa> cliftonts, I'm playing with it for a minute, hold on
<cliftonts> kyrofa - rokuterm is a sort of prototype program, mostly not finished, mostly patched together and just there to iron out some kinks in the design which will be transferred to a new project later. It seemed appropriate to experiment with packaging on an experiment.
<cliftonts> I would be keen to learn how one of these setup.pys would work though.
<kyrofa> cliftonts, it's a python packaging thing. This might prove a good starting point: https://stackoverflow.com/questions/1471994/what-is-setup-py
<cliftonts> Ok, thanks
<kyrofa> cliftonts, but you probably don't need it for this
<cliftonts> I was about to say, the snap handles all of that anyway, right?
<kyrofa> I'll explain in a second
<kyrofa> cliftonts, well, you still have to tell snapcraft what to put in the snap
<kyrofa> cliftonts, the `dump` plugin just puts EVERYTHING in its `source` into the snap (unless files are filtered out)
<cliftonts> Yes, but once I've got it actually loading the script I can then worry about dependancies and permissions.
<kyrofa> cliftonts, the make plugin doesn't-- it runs `make` and `make install`
<kyrofa> cliftonts, i.e. if you didn't have a Makefile, the `make` plugin wouldn't know what to install. Does that make sense?
<kyrofa> The python plugins are the same way
<kyrofa> cliftonts, but we can get around that by telling it exactly what to do
<cliftonts> kyrofa - I see, I have simply been following the demo for the python3 snap, trying to change as little as possible. But to be honest that didn't seem to work for me either.
<kyrofa> cliftonts, the python3 demo pulls in https://github.com/markokr/spongeshaker, which has a setup.py
<cliftonts> kyrofa - I will browse further. The problem with coming in with zero knowledge is you can so easily overlook the obvious.
<kyrofa> cliftonts, alright, quick question:
<kyrofa> cliftonts, rokuterm.py is supplied by two things, it seems: the github project and alongside the snapcraft.yaml
<kyrofa> cliftonts, can you explain that? Do you actually want both of them?
<cliftonts> kyrofa - No, as I previously stated that is pretty much a carbon copy of the spongeshaker yaml. Make it go, then figure out why it goes. I had no idea what was removable, yet.
<kyrofa> cliftonts, ah, I see. So that github project should work standalone?
<cliftonts> Download it to your desktop and run the py, it'll just work.
<kyrofa> No dependencies other than python2 or 3?
<kyrofa> (Note that the py is not executable)
<cliftonts> kyrofa - Only a number of python modules. I debated with myself whether it would be frowned upon to have it set as executable as standard.
<kyrofa> cliftonts, default python modules, or pypi?
<cliftonts> requests, urllib, sys, time, os, urllib2
<kyrofa> Alright, sounds standard. Does this work better? http://pastebin.ubuntu.com/23741636/
<kyrofa> I made a few changes. First of all, got rid of the extra dump usage
<kyrofa> Second, I noticed the script uses `env python` so I used python2 instead of python3
<kyrofa> Third, I had to tell snapcraft how to install the script, due to the lack of a setup.py that tells that to snapcraft for you
<kyrofa> It's just a simple "make a bin folder, copy it into the bin folder, make it executable"
<kyrofa> cliftonts, does that make sense?
<cliftonts> Sounds good
<cliftonts> kyrofa - Trying now
<kyrofa> cliftonts, looks like you use requests
<kyrofa> Oh, you said so. Not standard, missed that
<cliftonts> kyrofa - I will work on creating the setup.py next then. Easier now I have a starting point
<cliftonts> Requests if python 3
<cliftonts> Oh no sorry, I use th requests module yes.
<kyrofa> cliftonts, alright, this works: http://pastebin.ubuntu.com/23741673/
<cliftonts> kyrofa - Excellent! I now get an error stating no module named requests so that's one problem fixed, one created. Progress!!
<kyrofa> cliftonts, it doesn't work though-- it's trying the wrong subnet for me. But that should get you closer :)
<kyrofa> At least it builds correctly now
<cliftonts> kyrofa - As I said it is experimental, one of the next stages is to get network scanning working correctly. But you can specify the IP manually anyway.#
<kyrofa> How? I have a roku
<cliftonts> kyrofa - rokuterm 192.168.blah, blah
<gb__> kyrofa ive been searching for a solution to my snap/nextcloud question.  I have I installed the ownbackup plugin but it doesnt seem to run.  What would you recommend as a backup solution?  I found on reddit that your the goto guy and worked on the snap package.
<cliftonts> kyrofa - Brilliant. It works but of course it is contained so can't access the network. I haven't read up on that yet.
<kyrofa> cliftonts, excellent, a little homework then!
<kyrofa> gb__, we've been talking about that actually
<cliftonts> kyrofa - Feel free to download and play with it. The aim is to re-create it using a graphivcal interface once all the features work.
<kyrofa> gb__, can you explain what you're trying to backup and why?
<kyrofa> cliftonts, already done ;)
<kyrofa> cliftonts, nice job by the way
<kyrofa> cliftonts, it would probably be helpful if you brought your mailing list thread to a close, by the way
<kyrofa> To others, I mean
<cliftonts> kyrofa - It's not that impressive, I've simply reverse engineered the code for uroku for ubuntu touch.
<gb__> kyrofa all i wanted to do was backup the data so if i loose the boot disk on my server i can restore everything
<kyrofa> gb__, so you want _everything_, including the data?
<kyrofa> gb__, how often do you want to capture such a backup?
<gb__> kyrofa thats what i was thinking of yes
<gb__> kyrofa, just once a week its only a home server
<cliftonts> kyrofa - Thanks for your help. More progress in 24 hours than the last 2 years!
<kyrofa> gb__, that's all I have to, but that's still a few hundred GBs per backup if you include the data. Where do you intend on putting them? (not trying to attack by the way, it's just helpful having a use-case to poke at)
<kyrofa> cliftonts, any time!
<mup> PR snapcraft#1025 closed: project loader: better error message for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
<kyrofa> gb__, and how many do you intend on keeping?
<cliftonts> I'm off to try and find something to watch on the bottomless pit that is roku. Night!
<gb__> kyrofa i have a zfs array on the server to backup too
<mup> PR snapcraft#984 closed: parser: improve output <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/984>
<kyrofa> gb__, okay. So currently, you can totally just slurp the entire /var/snap/nextcloud/current directory
<kyrofa> As well as the /var/snap/nextcloud/common directory (which holds the raw data)
<kyrofa> To restore, just install the snap and copy stuff over the top
<kyrofa> gb__, but we're working on making a nicer export/import
<kyrofa> gb__, but unlike just Nextcloud, we have other things to think about. SSL keys, etc
<kyrofa> gb__, so: do you find yourself caring about the raw data, the database, the nextcloud config, the extra stuff like SSL keys, or everything in one big dump?
<kyrofa> gb__, note that the discussion to which I refer is happening here: https://github.com/nextcloud/nextcloud-snap/issues/126
<gb__> kyrofa thinking about it if i backup just the data i could always copy it back
<kyrofa> gb__, yeah just backup /var/snap/nextcloud/common, then. If you need to restore, just put the files back in there and Nextcloud will pick them up
<kyrofa> gb__, but we can make that better
<kyrofa> It's on the list :)
<gb__> kyrofa thanks for your help Ill do that then.  I have a long list of todo's too.  Thanks for your help :)
<kyrofa> gb__, any time!
<kyrofa> gb__, thanks for letting me pick your brain. Feel free to join in that conversation on the bug
<gb__> kyrofa will do!
<mwhudson> longsleep: sorry for the delay, that doesn't really make much sense to me though :(
#snappy 2017-01-05
<mup> PR snapcraft#1026 opened: Add support for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1026>
<mup> Bug #1654130 opened: Adding a tag indicating manual connection is needed when displaying interfaces <Snappy:New> <https://launchpad.net/bugs/1654130>
<Croepha> Whats the name of the network config stuff thats on core? the thing that replaces etc/interfaces ... trying to find documentation on it and its been a while forgot what it was called
<Croepha> netplan
<longsleep> mwhudson: well that particular wifi driver is crap in any case, so i would not bother much as the rest seems to work fine. Will try the new edge build on the weekend and then hopefully can report that everything is working
<liuxg> Croepha, I have a Chinese blog article at http://blog.csdn.net/ubuntutouch/article/details/53500874 you may use google translate to translate it.
<zyga> o/
<davidcalle> kyrofa: sergiusens: when is the next snapcraft release?
<mup> Bug #1637611 opened: snappy images should not ship /etc/profile.d/Z99-cloud-locale-test.sh <Snappy:In Progress by ogra> <livecd-rootfs (Ubuntu):In Progress by ogra> <https://launchpad.net/bugs/1637611>
<mup> PR snapd#2558 opened: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2558>
<ogra_> mvo, /etc/profile.d/snappy-oem-branding.sh still looks in /oem for stuff ... should we update it to look somewhere else or just throw it out ?
<mvo> ogra_: throw it out please, we have no equivalent for this currently
<ogra_> yeah, thought so
<mardy> hi, can anyone help me with this snapcraft error? https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html
<mup> PR snapd#2395 closed: make state and squashes immutable when appropriate <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2395>
<mup> Issue snapd#2559 opened: seccomp tests fail on Ubuntu 16.04 in when running in qemu or linode <Created by zyga> <https://github.com/snapcore/snapd/issue/2559>
<zyga> jdstrand: hey
<zyga> jdstrand: any chance you could have a look at ^^
<zyga> jdstrand: just as a sanity check, to answer one question
<zyga> jdstrand: specifically if this part looks fishy:
<zyga> DEBUG: Input line: mmap2
<zyga> DEBUG: seccomp rule: ALLOW sycall -10029
<zyga> when loading the profile, we seemingly parse "mmap2" to syscall number -10029 (int)
<jdstrand> zyga: https://github.com/snapcore/snapd/issue/2559 gives a 404. based on what you pasted, it is saying that mmap2 is allowed by the snappy policy but is unknown on the system that snapd is running on. based on http://people.canonical.com/~ubuntu-security/syscalls/, mmap2 was introduced in kernel 3.19
<zyga> jdstrand: the mup thing is buggy, use "issues" not "issue" (missing "s")
<zyga> https://github.com/snapcore/snapd/issues/2559
<jdstrand> zyga: perhaps the application is a statically compiled application that uses mmap2? perhaps the application is using a library that uses mmap2?
<zyga> jdstrand: we run /bin/true
<zyga> jdstrand: that's the old test
<jdstrand> zyga: nothing in your paste indicates the profile is malformed
<zyga> jdstrand: right
<zyga> jdstrand: anyway, if you can and are interested in this puzzle, read the bug report
<zyga> jdstrand: it has all the facts
<jdstrand> zyga: does it have the kernel version?
<zyga> jdstrand: kernel is the same as on my machine where the same test works
<zyga> jdstrand: the failure occurs in qemu
<zyga> jdstrand: running xenial adt cloud image
<zyga> jdstrand: for context, I'm trying to re-enable those tests: https://github.com/snapcore/snapd/pull/2433
<mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<jdstrand> zyga: I left some questions but I need to prepare for a meeting and then work on the trusty seccomp issue after. I'll swing back around and check in on this later if I'm able to
<zyga> jdstrand: thank you
<zyga> jdstrand: I added the kernel log snippet, taking a break from this topic now but I suspended a VM that has the environment so I can resume ant any time
<mup> Bug #1645605 changed: No alsa module on ubuntu core image <snapd-interface> <Snappy:New for zyga> <https://launchpad.net/bugs/1645605>
<mardy> sergiusens: hi! I completely morphed bug 1652290, now it's a bit more interesting
<mup> Bug #1652290: Error with remote part depending on another remote part <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1652290>
<mardy> sergiusens: I can work on that, if you like (and maybe have some hint for me)
<mup> PR snapd#2560 opened: snap: fix missing sizes in `snap info <remote-snap>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2560>
<sergiusens> mardy sure, work with josepht who maintains that or Trevinho who started playing with it
<mardy> sergiusens: thanks!
<mardy> josepht, Trevinho: do you have some last words to say, before I start banging my head into that? :-)   (bug 1652290)
<mup> Bug #1652290: Error with remote part depending on another remote part <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1652290>
<sergiusens> popey I CCed you on an email that led me to the anatine yaml
<popey> sergiusens: thanks
<josepht> mardy: Go for it. I'm happy to help.
<mup> PR snapd#2561 opened: many: obtain installed snaps developer/publisher username through assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2561>
<kyrofa> davidcalle, new version should be in proposed this week
<kyrofa> davidcalle, then some testing to do... probably in updates middle of next week
<popey> jdstrand: is there a workaround for this http://paste.ubuntu.com/23746854/ - (apps wanting to mknod in /dev/shm/foo) ?
<ogra_> use /dev/shm/$SNAP/foo ?
<ogra_> (iirc thats what the security check tool tells you)
<popey> I used the word "workaround" to mean, "not have to patch upstream"
<davidcalle> kyrofa: thanks!
<ogra_> :)
 * ogra_ doubts there is one
<popey> It's a python app.
<jdstrand> popey: no workaround. what ogra_ said is the current situation. this is bug #1577514
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<popey> :(
<popey> SamYaple: I note you are/were affected by the above bug. Is that still the case? Did you do anything specific to work around it?
<sergiusens> popey snapcraft update; snapcraft define preload
<sergiusens> jdstrand ^
<popey> ooh
<jdstrand> sergiusens: oh, neat! is that documented somewhere? I don't see a mention of that in the bug
<sergiusens> jdstrand yeah, I removed snapcraft from the problem
<sergiusens> jdstrand popey but it did solve most of someone's problem's on rocket/snapcraft
<popey> sergiusens: so basically after: [preload] and then what? Add a preload or something to the launcher?
<sergiusens> popey yeah `commmand: preload <whatever>`
<popey> winner, thanks. will give that a try
<popey> that could fix a few broken snaps I've had in the past.
<sergiusens> popey yeah `commmand: preload desktop-launch <whatever>`
<popey> I may have to buy you beer
<sergiusens> no need, took me long enough to promote this as much ;-)
<sergiusens> also, no need for the `after` at all, these can be independent
<popey> eh?
<sergiusens> but you might need it now that I think of it as you won't be overriding anything
<popey> how do I tell snapcraft to use it though?
<popey> s/use/include/
<kyrofa> sergiusens, yeah, if you leave the plugin out you need _something_ else
<kyrofa> sergiusens, probably a schema bug
<sergiusens> popey this is the only way by design unless you do the override dance
<sergiusens> popey http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
<mup> PR snapd#2562 opened: cmd/snap-confine: check for rst2man on configure <Created by zyga> <https://github.com/snapcore/snapd/pull/2562>
<mup> PR snapd#2563 opened: cmd/snap-confine: small tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/2563>
<mup> PR snapd#2564 opened: cmd/snap-confine: build non-installed libsnap-confine-private.a <Created by zyga> <https://github.com/snapcore/snapd/pull/2564>
<mup> PR snapd#2565 opened: store: setting of fields for details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/2565>
<mup> PR snapd#2566 opened: tests: disable some ppc64el on yakkety and zesty too <Created by mvo5> <https://github.com/snapcore/snapd/pull/2566>
<zyga> jdstrand: good call!
<zyga> jdstrand: snap-confine itself needs more syscalls to finish working
<zyga> jdstrand: presumably due to debug writes etc
<zyga> jdstrand: I trully wonder why this didn't fail on my box though, I'll keep digging
<popey> sergiusens: :( preload didn't work. still wants to write to /dev/shm/foo
<azubieta> Hello guys! IÂ´m making software center (https://github.com/nomad-shell/nx-software-center) to manage snaps wich uses the snapd REST api in the backend. I was reading the api specifications at the wiki but i found very little about the background process. Is there any place were I can read how to monitor such tasks? Thanks
<kyrofa> azubieta, Chipaca is probably your guy
<kyrofa> azubieta, attente might also be able to help (or point you in the right direction) from our software center point of view
<zyga> azubieta: hey
<azubieta> hello
<zyga> azubieta: we had an event api but it was removed as it was not finished
<zyga> azubieta: what do you need exactly?
<azubieta> zyga: monitor the install, remove, update tasks
<Chipaca> azubieta, I'm your guy, but I'm in a meeting and then I'm out of here
<attente> azubieta: you might also want to look at https://launchpad.net/snapd-glib that robert_ancell maintains
<Chipaca> azubieta, john.lenton@canonical.com (or tomorrow, same place, a little earlier)
<zyga> azubieta: you can do what snap CLI does
<zyga> azubieta: issue the operation
<zyga> azubieta: this gives you change ID
<zyga> azubieta: then query snapd about that change
<azubieta> Chipaca: thanks!
<azubieta> zyga: I saw the change id but I was unable to find the path where should I make the query
<zyga> azubieta: look at snap changes
<Chipaca> azubieta, if you want to "poke" at the api, i'd recommend `snap install http` and then e.g. `http snapd:///v2/changes`
<zyga> azubieta: it's not documented on the wiki
<zyga> azubieta: but look at /v2/changes/{id}
<zyga> azubieta: or at /v2/changes/
<zyga> azubieta: you can control changes as well (abort)
<azubieta> zyga: thanks!
<azubieta> zyga: thatÂ´s what I was loking for
<azubieta> Chipaca: right now iÂ´m making the http requests by hand and sending then throud the /run/snapd.socket
<Chipaca> azubieta, yeah, http is just convenient (it does the same)
<Chipaca> it's httpie + unix socket support + magic for snapd:/// urls
<azubieta> Chipaca: sounds good, does it has a c/c++ api ?
<azubieta> by the way, is there any other software center for snaps ?
<zyga> azubieta: gnome-software
<Chipaca> azubieta, there's glib-snapd i think?
<Chipaca> libsnapd-glib-dev etc
<mup> PR snapd#2567 opened: debian: skip snap-confine unit tests on nocheck <Created by zyga> <https://github.com/snapcore/snapd/pull/2567>
<azubieta> Chipaca: would you recomend using snapd-glib instead talking directly to the REST API ?
<Chipaca> azubieta, I'm probably the wrong person to ask :-) I think if your focus is the software centre, then working with snapd-glib will let you ignore the vagaries of the rest api
<Chipaca> azubieta, me personally i like poking at the rest api directly
<Chipaca> :-D
<azubieta> Chipaca: jeje, iÂ´ll take your advice
<Chipaca> azubieta, either way, do shout if you find things that don't work as you'd expect
<azubieta> Chipaca: iÂ´m reading a post about snapd-glib they say that they will make a qt/qml port so if it is finished it would be mucho more easier for me
<azubieta> Chipaca: i will
<azubieta> Chipaca: thanks again
<Chipaca> azubieta, the snapd-glib author is in NZ timezone afaik
<Chipaca> anyway, i've got to run
<vigo> ogra_, confirmed
<vigo> I just created an image from edge and config.txt is updated
<ogra_> vigo, i would be shocked if it wasnt :)
<sabdfl> elopio, elmo and me
<matteo> http://pastebin.ubuntu.com/23747897/
<matteo> is there something wrong with this control interface?
<mup> Bug #1636931 changed: Configure hook not running <Snappy:Fix Released> <https://launchpad.net/bugs/1636931>
<mup> Bug #1654362 opened: updating pi3 snap does not update config file <Snappy:New> <https://launchpad.net/bugs/1654362>
<lazyPower> elopio  - heyo, looking @ the etcd snap as a possible drop in for the etcd v3 migration. Is what's in the snappy-playpen the latest work on this snap?
<mup> Bug #1587448 changed: Can't reboot device from snap <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1587448>
<mup> Bug #1590679 changed: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1590679>
<mup> Bug #1612871 changed: Permission denied to exec /bin/stty <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1612871>
<mup> Bug # changed: 1613686, 1614269, 1615124, 1615262
<mup> Bug # changed: 1620442, 1624533, 1624675, 1627813, 1639988
<mup> Bug #1644810 changed: snapd system-observe interface is missing rules to allow memory usage analysis <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1644810>
<mup> Bug #1596515 changed: IIO access and configuration from a snap <apparmor> <iio> <snapd> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1596515>
<mup> Bug #1639967 changed: Add support to access to some Avahi methods from org.freedesktop.Avahi <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1639967>
<mup> Bug #1641869 changed: openvswitch-support interface <snapd-interface> <Snappy:Fix Released by james-page> <https://launchpad.net/bugs/1641869>
<Croepha> so, not sure what happened, I have used --try many times before with no trouble, but after a reboot I am getthing this error when trying to use something inside of a --try snap :  cannot snap-exec: cannot read info for "my-snap": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory
<Croepha> that file totally exists
<Croepha> its a simlink to the prime dir
<mup> Bug #1598266 changed: Cannot read/write to usb device [libusb][hidapi] <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1598266>
<mup> Bug #1577897 changed: auto-connection should cover snaps other than OS snap <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1577897>
<mup> Bug #1591839 changed: Can't read/write to USB devices <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1591839>
<mup> Bug #1611819 changed: implement a way for daemons to play audio <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1611819>
<kyrofa> davidcalle, it seems I lied: with the sprint next week, we're delaying release by one week
<davidcalle> kyrofa: ok :)
<kyrofa> davidcalle, were you looking for a specific feature, or just generally curious?
<davidcalle> kyrofa: generally planning, although I could use being walked through scriptlets, I've only seen one example so far
<kyrofa> davidcalle, yeah we could use some real docs for that. Happy to help you there (though note those were released in 2.24)
<mup> Bug #1645410 changed: interface required: openvswitch <snapd-interface> <snap-nova-hypervisor:New> <Snappy:Fix Released> <https://launchpad.net/bugs/1645410>
<davidcalle> kyrofa: thanks
<mup> Bug #1613775 changed: cannot access /mnt/storage even through symlinks from $HOME <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1613775>
<mup> Bug #1618004 changed: Need a classic-bin interface to see classic binaries <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1618004>
<Croepha> any ideas on how to make sense of this: cannot snap-exec: cannot read info for "my-snap": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory ?
<mup> Bug #1617314 changed: Services can only run as root <snapd-interface> <Snapcraft:Invalid> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1617314>
<kyrofa> Croepha, you're `snap try`ing, I assume?
<Croepha> kyrofa: yes, try --devmode
<kyrofa> Croepha, and does /var/lib/snapd/snaps/my-snap_x1.snap exist? It should be a symlink
<Croepha> yes, and it is
<kyrofa> Croepha, pointing to a valid location?
<kyrofa> (a prime directory)
<zyga> jdstrand: quick question about old snap-confine unit tests, do I remember correctly that they were only going to pass on amd64?
<zyga> jdstrand: I'm seeing a list of errors on i386
<zyga> jdstrand: (details are burried under links from https://github.com/snapcore/snapd/pull/2433)
<mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<Croepha> kyrofa: yes: /var/lib/snapd/snaps/my-snap_x1.snap/*.wrapper returns several results
<Croepha> meant to say that I `ls`d that and got several results
<Croepha> my only guess is that snap is running in some other file system context (name space or chroot) where it can't stat that path?
<kyrofa> Croepha, any chance you have an encrypted home?
<Croepha> kyrofa, no, but I am running in Vmware, and use a mapped home directory, but not sure how that would be affected, it lives in /mnt/hgfs/
<jdstrand> zyga: they should work. I just tried them locally with snapd 2.20 on trusty
<kyrofa> Croepha, ah indeed, that's probably the issue. zyga may know more
<zyga> jdstrand: on i386?
<jdstrand> yes
<Croepha> kyrofa my prime doesn't live in my home or in that hgfs
<zyga> Croepha: hey
<zyga> Croepha: try snap run --shell yournsap
<zyga> Croepha: snaps do run in a different context
<jdstrand> zyga: I'm trying to fix the amd64 snapd/snap-confine testsuite failure and ran the tests on i386 to make sure I didn't break anything (I didn't)
<zyga> Croepha: that will give you a (confined) shell in the same context as a given snap/app
<zyga> jdstrand: it seems to work on my real box
<zyga> jdstrand: but never works in spread (neither qemu nor linode)
<zyga> jdstrand: gustavo suggested that it might be caused by those things running as root but I didn't investigate yet
<Croepha> zyga run --shell gives the same error
<zyga> jdstrand: I'd love if you could drop patches to unbreak https://github.com/snapcore/snapd/pull/2433/files (tip: you can git push to my branch directly!)
<mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<zyga> Croepha: can you givem e more context?
<Croepha> zyga: this is the error: cannot snap-exec: cannot read info for "tanager-flock": stat /var/lib/snapd/snaps/my-snap_x1.snap: no such file or directory
<zyga> jdstrand: maybe spread is breaking something, I see 7 failures on i386 and (finally) 0 failures on amd64
<Croepha> zyga: that path does exist and is valid, it is a symlink to a prime dir
<zyga> Croepha: is that file around in "real space"?
<zyga> Croepha: did you create that symlink?
<zyga> jdstrand: can you tell me how are you running tests?
<jdstrand> zyga: I'll talk to ratliff on how to prioritize the i386 test failures in https://github.com/snapcore/snapd/pull/2433
<mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<jdstrand> zyga: I did debian/rules build
<jdstrand> zyga: I would also do: make -C cmd check
<jdstrand> zyga: I can't get to those tests today. still working on trusty/libseccomp
<zyga> jdstrand: did you try spread?
<zyga> jdstrand: that's ok
<zyga> jdstrand: thanks!
<jdstrand> zyga: no. you said unit tests. is it the unit tests or the spread tests?
<zyga> jdstrand: spread runs them
<zyga> jdstrand: we don't run unit tests when building the package in spread
<zyga> jdstrand: so I wanted to run them as a task
<jdstrand> well, I'd have to look at what is happening. I didn't run in spread as I was debugging a testsuite failure from the build
<Croepha> zyga: not sure what is meant by "real space", but  I see that in the context where I login via ssh.... I did not create that symlink, I used  snap try --devmode and it made the symlink
<zyga> jdstrand: all regular unit tests run but the older tests that exercise seccomp don't pass
<zyga> Croepha: I see
 * jdstrand is curious why you don't run the unit tests during the build in spread
<zyga> Croepha: can you tell me where the source directory was located?
<zyga> Croepha: we don't run them at package build time (in spread) because it takes extra time (snapd build) and we run the separately along with other spread tasks
<zyga> er
<zyga> jdstrand: ^ that was for you
<zyga> jdstrand: I fixed a few issues but it's still broken, I need to make the debug output better
<zyga> jdstrand: (that tail of kern log for instance)
<zyga> jdstrand: in any case, you answered my earlier question, thanks
<zyga> jdstrand: I'll keep digging
<jdstrand> zyga: I noticed we have a lot of 'dmesg | tail -1' in the seccomp tests. that should be 'dmesg | grep 'audit=1326' | tail -1'
<zyga> 1326?
<Croepha> zyga: this is the prime dir: /mnt/2/flock21_build/prime  if that is what you are asking  and this is the related findmnt line: ââ/mnt/2                              /dev/sda3                       ext4                rw,relatime,data=ordered
<jdstrand> zyga: ok, I've got the trusty/seccomp thing, then several customer items for snappy then can circle back around to this. it won't be today. it will hopefully be tomorrow, it may be monday
<zyga> Croepha: does it work if you don't snap try but rather build a regular snap?
<zyga> Croepha: that symlink is, I believe, what is causing the problem
<Croepha> zyga: a regular snap install works as expected
<jdstrand> zyga: 1326 is the code for seccomp
<Croepha> zyga: I agree, im just not sure how to remedy it, before kyrofa got back to me, I was thinking of just doing a fresh install of ubuntu and starting over....  it was working fine for a long time, but it just stopped working
<jdstrand> zyga: and I of course meant this: dmesg|grep 'type=1326'|tail -1
<jdstrand> eg:
<jdstrand> $ dmesg|grep 'type=1326'|tail -1
<jdstrand> [ 9653.865938] audit: type=1326 audit(1483637031.980:825): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=24498 comm="snap-confine" exe="/home/ubuntu/sbuild/snapd/trusty/snapd-2.20.1~14.04/cmd/snap-confine/snap-confine" sig=31 arch=40000003 syscall=201 compat=1 ip=0x55609c89 code=0x0
<grapestomper_1> does anyone know how to change the default console output from ttyS0 to ttyUSB0
<grapestomper_1> snappy series 16 (core 16?)
<grapestomper_1> in 15.04 I could change the grub.d file - not an option now
<Croepha> grapestomper_1, do you really need a kernel console or will a login console work fine?
<Croepha> because you can add a tty service to run on that usb device if you want
<grapestomper_1> hmmm dont know - I want to be able to watch the boot process. Is that kernel?
<Croepha> yeah, thats kernel
<grapestomper_1> is kernel tty set at snap cration?
<grapestomper_1> creation
<Croepha> well, i don't know how to do it, but I think you will need to make your own gadget or kernel snap
<Croepha> there might be an easier way, i don't know of it though, sorry
<grapestomper_1> np - thanks
<kgunn> hey is there a clever way a snap can determine if the console config has been run?
<kgunn> working with a mir-kiosk image, but the server is currently launching before i can run through the config to get wifi etc
<kgunn> kyrofa: ^ know of anything?
<kyrofa> kgunn, does it die if it runs before then?
<kgunn> kyrofa: no, mirkiosk happily runs...but takes over the screen
<kyrofa> Ah of course, so console conf can't be run, how fun!
<kgunn> so we're thinking to add some logic in the launcher file to check if console has run or not
<kyrofa> kgunn, hmm, you could do hacky things like see if you have an IP address, but there must be a better way
<kyrofa> mwhudson, do you have any ideas? You're involved with that, no?
<kyrofa> Oh darn, he's gone
<kgunn> yeah, i would think this might be a common theme....people wanting to add snaps to their own image, but wanting console conf to run prior to daemon launching
<kyrofa> Taking a quick peek at the src
<kyrofa> I bet if there is something though, it won't be accessible to snaps
<kyrofa> kgunn, I kinda feel like no services should run until console-conf has run
<kyrofa> kgunn, yeah, /var/lib/console-conf/complete
<kyrofa> kgunn, nothing you can reach from a confined snap
<kyrofa> kgunn, I suggest discussing it with niemeyer and mwhudson
<alvarolb> Hi all!! I am trying to upload a snap package to the ubuntu store, but I always get the error: Unexpected output from click-review. click-review
<alvarolb> If i execute the click-review manually, I get a RUNTIME_ERROR, but no any other hint
<alvarolb> the verbose show some checks that are all passed OK
<alvarolb> anyone with the same issue? I am using snapcraft for building the package for amd64
<kyrofa> cyphermox, are you familiar with console-conf?
<kyrofa> cyphermox, do you know if there's a way to tell if it's been run from within a confined snap?
<kgunn> kyrofa: thanks... yep, can bring up tomorrow
<mup> PR snapcraft#1007 closed: lifecycle: clean without parsing if possible <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1007>
<kyrofa> kgunn, curious to hear the answer myself
<Croepha> zyga: So i got /usr/lib/snapd/snap-confine to run for me, and the symlink is definitely broken in the confined environnment
<Croepha> so /mnt/ is empty in the confined environment
<Croepha> zyga: So bind mounting /mnt/2 under my home directory and running it there fixed my issue
<Croepha> fyi
<Croepha> I still have no clue as to why it worked before but not now
<mup> PR snapcraft#1026 closed: Add support for hooks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1026>
<mwhudson> kyrofa: if kgunn comes back the answer is really $(snap managed)
<kyrofa> mwhudson, ah, good to know. But that can't be run from within a snap-- do you know if that command has been added to snapctl?
<mwhudson> ah good point
<mwhudson> i do not know, and suspect not
<kyrofa> I suspect the same
 * mwhudson points at niemeyer
 * niemeyer listens (and reads)
<niemeyer> No, managed isn't yet available on snapctl, but seems sensible and trivial to add
<kyrofa> niemeyer, though do you think it makes sense to not fire up snap services until console conf has completed?
<niemeyer> @kyrofa: No, that'd render the device broken until managed
<nothal> niemeyer: No such command!
<kyrofa> niemeyer, though it doesn't even have network at that point, does it?
<niemeyer> kyrofa: I don't need network to run my fridge, tv, projector, etc
<kyrofa> Ah fair enough
<mcphail> kyrofa: if the nextcloud snap was to upgrade to version 11, would an already-running server upgrade gracefully? Would it be necessary to stop and restart?
<kyrofa> mcphail, an already running server meaning a current nextcloud snap install?
<mcphail> kyrofa: yes
<kyrofa> mcphail, yeah, when the upgrade it pulled down it'll stop the server momentarily
<kyrofa> mcphail, snapd does it as part of the upgrade process. Stop old services, mount new snap, start new services
<mcphail> kyrofa: very cool. Thanks!
<kyrofa> mcphail, no problem. Since you asked, FYI v11 should be released as soon as I fix this https bug
<mcphail> kyrofa: no rush. Just trying the snap on a vps to see if it is a viable alternative to a manual install. Sounds as if you have cracked it :)
<mcphail> Your hard work is much appreciated
<kyrofa> mcphail, it's not perfect! But we're getting there. And thank you!
<mcphail> Just one more question - does the snap make the Let's Encrypt certs automatically renew?
<kyrofa> mcphail, yes
<mcphail> kyrofa: perfect! Cheers
<kyrofa> davidcalle, are you still around?
<davidcalle> kyrofa: I am
<kyrofa> davidcalle, I had to put out a fire, but if you've got a few minutes I'd love to show you around the scriptlet stuff
#snappy 2017-01-06
<davidcalle> kyrofa: not really, just came back online to finish a snapcraftio deployment. Would you have time tomorrow?
<kyrofa> davidcalle, certainly, I'll ping you when I get in
<davidcalle> kyrofa: sounds good! ty
<mup> PR snapcraft#920 closed: pluginhandler: ensure staged files are included in the prime step <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/920>
<alvarolb> hi! anyone knows why my snap package does not pass the click-review? It reports RUNTIME ERROR, although the package install fine with snap
<kyrofa> alvarolb, you probably want jdstrand
<alvarolb> thanks kyrofa.
<kyrofa> He may be out today, you might try tomorrow
<alvarolb> ok, will try tomorrow :) as I cannot upload my snap package with this error
<cyphermox> kyrofa: I'll be back on Monday
<cyphermox> kyrofa: console-conf AFAIK runs unconfined, as part of the OS snap.
<kyrofa> cyphermox, no worries, we got it sorted, thank you!
<cyphermox> aka. core snap.
<alvarolb> I submitted a bug in the meanwhile: https://bugs.launchpad.net/snappy/+bug/1654451
<mup> Bug #1654451: ubuntu store snap click-review error <Snappy:New> <https://launchpad.net/bugs/1654451>
<mup> Bug #1654451 opened: ubuntu store snap click-review error <Snappy:New> <https://launchpad.net/bugs/1654451>
<mup> PR snapcraft#1027 opened: tests: fix broken unit test in master <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1027>
<mup> PR snapcraft#1027 closed: tests: fix broken unit test in master <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1027>
<mup> PR snapcraft#1004 closed: tests: add aliases integration test <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1004>
<grapestomper> does anyone know how to change the default console output from ttyS0 to ttyUSB0
<grapestomper> snappy series 16 (core 16?)
<grapestomper> kernel console output (I want to see the boot process)
<mup> PR snapcraft#1028 opened: [Highly experimental] Run the integration suite in parallel <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1028>
<mup> PR snapcraft#1029 opened: rust plugin: add conditional compilation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1029>
<mup> PR snapcraft#952 closed: rust plugin: add features for conditional compilation <Created by cholcombe973> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/952>
<liuxg> grapestomper, you may refer to the picture http://img.blog.csdn.net/20160912142114476?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center
<liuxg> grapestomper, open the file and change it there dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
<mup> PR snapd#2566 closed: tests: disable some ppc64el on yakkety and zesty too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2566>
<mup> PR snapd#2128 closed: many: finalize trusty support <Created by vosst> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2128>
<mup> Issue snapd#2568 opened: snapd needs a SELinux profile to run on Fedora <Created by zyga> <https://github.com/snapcore/snapd/issue/2568>
<mup> Issue snapd#2569 opened: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <Created by zyga> <https://github.com/snapcore/snapd/issue/2569>
<mup> PR snapd#2548 closed: snap: show `snap --help` output when just running `snap` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2548>
<mup> Issue # closed: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569
<mup> PR # closed: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2562, snapd#2563, snapd#2564, snapd#2567
<mup> Issue # opened: snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2559, snapd#2568, snapd#2569
<mup> PR # opened: snapd#2416, snapd#2433, snapd#2520, snapd#2528, snapd#2542, snapd#2563, snapd#2564, snapd#2567
<mup> PR snapd#2570 opened: snap: add support: line in `snap info <Created by mvo5> <https://github.com/snapcore/snapd/pull/2570>
<mup> PR snapcraft#1030 opened: tests: fix broken delta upload unit test <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1030>
<mup> PR snapd#2571 opened: tests: generate higher local version than any "ubuntuN" version from the archive <Created by mvo5> <https://github.com/snapcore/snapd/pull/2571>
<ogra_> morphis, yo ... trying your pulse snap on pi3 ...
<ogra_> Jan  6 11:33:42 pi3 kernel: [100001.213596] audit: type=1326 audit(1483702422.800:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3658 comm="pulseaudio" exe="/snap/pulseaudio/12/usr/bin/pulseaudio" sig=31 arch=40000028 syscall=206 compat=0 ip=0x76df5456 code=0x0
<ogra_> Jan  6 11:33:42 pi3 snap[3647]: Bad system call
<ogra_> looks like some seccomp love is needed there
<ogra_> morphis, 206 is setgroups32, that doesnt exist on 64bit arches, that might be the reason why it works on amd64 but not on armhf (and likely also not on i386)
 * ogra_ tries --devmode
<morphis> ogra_: hm, koza told me that it works and this thing is fixed, which core snap revision are you using?
<morphis> not sure if it requires the latest from candidate and already works with the one from stable
<ogra_> ogra@pi3:~$ sudo pulseaudio.parec foo.wav
<ogra_> ^C
<ogra_> ogra@pi3:~$ ls -l foo.wav
<ogra_> -rw-r--r-- 1 root root 520856 Jan  6 11:48 foo.wav
<ogra_> ogra@pi3:~$
<ogra_> works with --devmode
<ogra_> (no idea what it recorded there, i have no mic :P )
<ogra_> my pi doesnt find one in stable btw ...
<ogra_> i'm using edge
 * ogra_ checks --candidate
<ogra_> also needs --devmode to start
<popey> Is there a plan to allow daemons to run as non-root in snaps, or allow snaps to create users?
<ogra_> yes... but i dont know how far out that is
<popey> is there a work item / card / bug?
<ogra_> definitely on the long term, list of the security team
<popey> It's a blocker for an ISV with a postgresql database as a part
<ogra_> you gotta ask jdstrand
<popey> ok
<sergiusens> popey it was recently (these past few days) discussed on the mailing list under "Process privileges and owners in snaps"
<popey> sergiusens: thanks
<Elleo> jdstrand: I'm getting some odd behaviour with anonymous sockets under snappy, I've currently got a simple app armor rule of: unix (bind, send, receive) addr="@/tmp/maliit-server/dbus-*" but when maliit attempts to create a QtDbus server using that socket it gets stuck in a pthread_wait (which doesn't happen if its in devmode); any ideas what my be causing that before I dive into qtdbus's internals to see what's happening?
<mup> Issue snapd#2572 opened: .fstab files generated by snapd for the content interface do not follow the snap.<snap name> scheme <Created by morphis> <https://github.com/snapcore/snapd/issue/2572>
<DanChapman> Hey! I'm having what now seems to be an issue with automatic releasing of my snap on the edge channel. I have an lp builder publishing to the store but i'm having to manually release each revision after the store review using `snapcraft release`.
<DanChapman> Is this a known issue or some setting i might have accidently changed in myapps.d.u.c
<nessita> DanChapman, what's the name of your snap?
<nessita> (hi!)
<DanChapman> nessita, hey! it's dekko
<nessita> DanChapman, let me dig a little
<DanChapman> thanks!
<nessita> cjwatson, hi there, would you help me confirm if the issue Dan explained above is on LP or the store end? will LP builder try to release the revno? if they fail is there a log?
<ogra_> DanChapman, note that there is usually a delay between it passing the tests and the auto-publisher ... like ... 20-30 min
<ogra_> could it be that you just hit that ?
<nessita> ogra_, good point, thanks for pointing that out
<DanChapman> ogra_: oh it could be that! I didn't know there was a delay.
<DanChapman> nessita: i'll test again just to be sure. get back to you shortly :-)
<cjwatson> will check logs after this call
<nessita> DanChapman, thanks!
<cjwatson> nessita,DanChapman: LP is consistently getting a 200 response from /dev/api/snap-release/ according to our logs, so not our problem :-)
<cjwatson> [2017-01-03 12:04:13,678: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None
<cjwatson> e.g.
<nessita> cjwatson, thanks for checking!
<mup> PR snapcraft#990 closed: tests: fix snaps tests in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/990>
<cjwatson> (waiting for it to get round to the most recent build so that I can give you a more recent timestamp to use for SCA log checking)
<cjwatson> [2017-01-06 13:34:15,294: DEBUG/Worker-3] "POST /dev/api/snap-release/ HTTP/1.1" 200 None
<cjwatson> DanChapman: has the most recent ppc64el build in https://launchpad.net/~dpniel/+snap/dekko-edge been released?
<cjwatson> the log entry above is LP asking the store to do so
<DanChapman> cjwatson: yes that has been released fine.
<DanChapman> nessita: seems to be ok. I must not have left it long enough last time.
<DanChapman> nessita: cjwatson: thanks for your help and sorry for the noise :-)
<nessita> DanChapman, thanks for confirmin
<nessita> g
<ogra_> :)
<jdstrand> Elleo: addr="@/tmp/maliit-server/dbus-*" is part of a rule for an abstract socket, but you said you are having trouble with anonymous sockets. can you clarify?
<cjwatson> np
<Elleo> jdstrand: sorry, I meant abstract not anonymous
<jdstrand> popey: there are open bugs for that. also (cc ogra, ratliff and JamieBennett), the security team is currently not tasked with implementing opt-in users though I have ideas on the design that I've discussed with people. what I plan to do very soon (if it doesn't get bumped again, next week) to allow daemons to drop to 'daemon'
<jdstrand> popey (cc ogra, ratliff and JamieBennett): that would allow things like postgresql to drop to a non-root user that already exists (specifically, 'daemon')
<jdstrand> Elleo: can you disable kernel rate limiting with: sudo sysctl -w kernel.printk_ratelimit=0
<JamieBennett> jdstrand, sounds good, a long requested feature so will be nice to see some solution
<jdstrand> Elleo: then do 'tail -f /var/log/syslog|grep DEN' and see if there are any denials when trying to use maliit?
<Elleo> jdstrand: no denials
<Elleo> jdstrand: without that apparmor rule it was previously getting denials when trying to create the socket, so that's obviously having an effect at least
<jdstrand> popey (cc ogra_, ratliff and JamieBennett): see https://lists.ubuntu.com/archives/snapcraft/2017-January/002286.html for my thoughts on how opt-in users could be implemented
<jdstrand> Elleo: if there are no denials it shouldn't be apparmor. what is likely happening is that there are multiple problems. the first was the socket creation, then you allow that and moved to the next problem
<Elleo> jdstrand: it works if the snap is installed with devmode though, so presumably it's something confinement related
<jdstrand> Elleo: sure, but not necessarily apparmor. before diving into qtdbus internals, you might strace it
<mup> PR snapd#2571 closed: tests: generate higher local version than any "ubuntuN" version from the archive <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2571>
<jdstrand> Elleo: and to be super sure-- you are observing /var/log/syslog, not kern.log, not dmesg and not using a tool like snappy-debug and still not seeing denials?
<jdstrand> Elleo: the other parts of confinement are seccomp (do you see any seccomp denials in syslog? look for 'type=1326' or use snappy-debug), device cgroups (not used by most interfaces, but what interfaces are you plugging?) or mount namespace
<Elleo> jdstrand: yep, and if I grep for ALLOWED there's a line for the binding: http://pastebin.ubuntu.com/23752229/
<Elleo> jdstrand: although, what's the "denied_mask" property?
<jdstrand> Elleo: the mount namespace shouldn't affect an abstract socket, but depending on your testing, it could affect something file related if you are trying to access something in the snap from outside the snap and inside the snap gets confused
 * jdstrand doubts that is the case)
<jdstrand> Elleo: denied_mask is the part of requested_mask that got denied
<jdstrand> Elleo: all my questions regarding denials are for when running in strict mode. ALLOWED shows you are in devmode
<ogra_> xnox, yo !
<Elleo> jdstrand: ah right, that'd have been from when I double checked it worked okay in devmode then
<Elleo> jdstrand: aha, there are seccomp entries: http://pastebin.ubuntu.com/23752238/
<jdstrand> $ scmp_sys_resolver 50
<jdstrand> listen
<jdstrand> use 'network-bind'
<jdstrand> if you are writing an interface for maliit, then add 'listen' to you seccomp filter
<Elleo> jdstrand: ah okay, thanks :)
<mup> PR snapcraft#1031 opened: store: fix sso_host for dev sso <Created by shawn111> <https://github.com/snapcore/snapcraft/pull/1031>
<Elleo> jdstrand: that's fixed it, thanks very much!
<jdstrand> Elleo: great! :)
<jdstrand> mvo: hi! if you are going to plan a new upload for trusty snapd, you might adjust the Build-Depends from 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty1)' to 'libseccomp-dev (>= 2.1.1-1ubuntu1~trusty3)'. 'trusty3' is the one that fixed amd64. certainly don't respin just for that though
<ogra_> jdstrand, hmm, looking at /var/lib/snapd/seccomp/profiles/snap.pulseaudio.pulseaudio i see setgroups and setgroups32 commented out at the top but then setgroups at the bottom uncommented ... why the duplication ?
<mvo> jdstrand: thank you
<jdstrand> ogra_: the top comes from the default template. the bottom from a slot snippet
<ogra_> ah, k, thanks
<jdstrand> ogra_: the top is a reminder that we don't (yet) support privilege dropping
<xnox> ogra_, que?
<ogra_> xnox, on your quest to look at swapfiles, did you happen to look at the "swapspace" package ?
<ogra_> (dynamically creates swap files on demand and deletes them afterwards)
<ogra_> jdstrand, heh, so adding setgroups32 just leads me to the next blocker ... "send" (289 on armhf)
<ogra_> hmm, i see pulse connected to the network interface, but not to network-bind
<mvo> jdstrand: updated
<jdstrand> mvo: thanks!
<mup> Bug #1654451 changed: ubuntu store snap click-review error <Canonical Click Reviewers tools:In Progress by jdstrand> <Software Center Agent:Invalid> <https://launchpad.net/bugs/1654451>
<xnox> ogra_, yes and we don't what that.
<xnox> ogra_, yes and we don't want that.
<ogra_> xnox, whats the reason ?
<ogra_> (we're considering such a feature for snappy images, thats why i ask)
<xnox> (when system is under memory preassure you don't want to randomly start eating into disk space, and consuming memory to allocate swap. We only need swap as a contingency and want it allocated up front. Also things like btrfs rebalance east a lot of memory and you can't really create swap whilst that is in progress)
<xnox> using memory to create swap; when swap is actually needed; is the worst time to do it =)
<ogra_> so you will be going with a fixed snap file set up by the installer ?
<xnox> ogra_, please don't do that. Ideally snap gadgets whould e.g. declare none or an appropriate sized swall swapfile /relevant/ for that device workload and that's it.
<xnox> yes.
<ogra_> well ... we'Re often operating on devicers with very low ram but a lot of diskspace
<xnox> on classic one can resize and/or remove it. on all-snaps systems i would not think that it needs to be amendable (outside e.g. gadget snap upgrading and changing the swapfile size)
<xnox> ogra_, if it's flash storage rather than SSD storage you will kill the device with swap =) there is only so many write cycles on flash storage.
<ogra_> but we dont want swap to be used at all if avoidable to avoid any slowness indeed
<ogra_> yes, i know
<ogra_> in that light dynamic swap file creation will help a lot though
<xnox> you have to use less memory - that's the best win, for size, performance, longivity.
<xnox> no, it won't.
<ogra_> you only wear out flash if you write a lot to the same place
<ogra_> due to dynamic creation that cant happen
<xnox> hahahahahahahaha
<ogra_> (compared to a fixed swapfile)
<xnox> hahahahaha
<xnox> it's the same.
<ogra_> or will happen less at least :)
<xnox> because silly micro-controllers abstract filesystem and round-robin the physical locations to what filesystem and kernel sees, on cheap storage.
<ogra_> not the same ... if you need i.e. 1GB swap swapspace will create 100 swap files each 100MB ...
<xnox> therefore with dynamic you get either the same wear as static, or possibly more wear =)
<ogra_> and dynamically delete them again if you dont need the space anymore
<xnox> on average, it's the same wear.
<xnox> it's best not to use swap to avoid pointless wear =)
<ogra_> so the filesystem usage will be different from having a permanent gigantic 1GB file
<xnox> at all.
<ogra_> right, but we have user demand for it
<ogra_> so we need to provide *something*
<ogra_> and dynamic feels safe than permanent
<xnox> how so again? the device blocks you see, are virtual to you, and you never know what physical block they correspond to. because cheap flash microcontrollers....
<ogra_> *safer
<mup> PR snapcraft#1028 closed: [Highly experimental] Run the integration suite in parallel <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1028>
<xnox> it's fragile =)
<ogra_> true indeed ... but if the blocks are in use new blocks will be used
<xnox> which can remap to the old physical block.
<ogra_> which is more likely if you have small fragmented files
<xnox> it's really random walk on most of these controllers.
<xnox> microcontroller has no visilibity to FS files.
<xnox> and does not care about virtual blocks either.
<ogra_> inded
<xnox> it really picks any =)
<ogra_> ok, so much for that theory :P
<ogra_> anyway, it will not permanently eat disk space ... thats still one advantage
<xnox> so on reboot, your static swapfile may write to new physical locations =/ (that is quite scary....)
<xnox> ogra_, does not work on btrfs or zfs.....
<xnox> or lvm.
<ogra_> which we currenmtly dont care for on core images
<ogra_> the OS is currently hardcoded to ext4
<xnox> ...
<ogra_> indeed it will bite once we support other FSes
<xnox> think this trough a little.
<xnox> talk to ubuntu-image developers about this.
<ogra_> (which i'm not sure we'll do anytime soon)
<xnox> we are shipping lvm cloud images soon.
<ogra_> snappy based ?
<ogra_> that will require a ton of changes in the OS
<ogra_> everything everywhere currently expects ext4
<xnox> i thought ext2 was the end-game for filesystems too at one point =)
<xnox> and that armhf will rule them all
<xnox> etc.
<ogra_> well, its a legacy we carry from system-image setups
<xnox> things will change, because things do change =)
<ogra_> it can surely be changed to other filesystems but will need a lot of changes
<ogra_> code changes i mean
<ogra_> so if anyone wants these cloud images any time soon, they should better look at the boot pÃ¼rocess or talk to someone who knows about it :)
<ogra_> jdstrand, so adding send additionally to setgroups32 makes it work ... i'll file a bug for you ... funnily the send syscall is enabled in all the pulse oprofiles, just not for the daemon itself :)
<alvarolb> thanks jdstrand for reviewing the bug in click-reviewer-tools
<grapestomper_1> does anyone know how the change the default kernel output from ttyS0 to tty??? (ex. ttyUSB0)?
<ogra_> grapestomper_1, edit the console= arg of your bootloader
<grapestomper_1> I used to do this in grub.d but that is not there. what file is it now
<ogra_> somewhere in /boot/grub/
<ogra_> iirc
 * ogra_ rarely touches x86 images
<grapestomper_1> I looked at there but all the files are read-only
<ogra_> hmm, i thought the grub.cfg is rw
<grapestomper_1> I see a 50-system-image.cfg that is rw
<grapestomper_1> I take that back
<ogra_> no, there needs to be a grub.cfg
<grapestomper_1> -rw-r--r-- 1 root root
<grapestomper_1> agreed :)  but I dont see one
<ogra_> well, the other option is to roll your own gadget snap with changed cmdline
<ogra_> to do that you clone https://github.com/snapcore/pc-amd64-gadget
<ogra_> and then edit prebuilt/grub.cfg (commandline is at the bottom there) and call snapcraft in the toplevel dir of the branch
<grapestomper_1> ok, thanks - I will look into that
<diddledan> the new dbus slot mechanism in snapd 2.20 works. I've tried uploading corebird-diddledan to the store using the working config but the store has complained that "not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus)"
<mup> Bug #1654585 opened: seccomp profile of pulseaudio snap misses syscalls on armhf <Snappy:New for jdstrand> <https://launchpad.net/bugs/1654585>
<kgunn> niemeyer: hey there, kyrofa thot you might be the right guy to ping
<kgunn> we're creating a mir-kiosk image
<kgunn> but trouble is mir-kiosk launches before i can run console-conf
<kgunn> is there a way i could check in my launcher file to not launch in the case where console-conf hasn't run?
<ogra_> kgunn, console-conf writes /var/lib/console-conf/completed when it was run successfully
<ogra_> but i have no idea how you would be able to see this from a snap
<ogra_> (might need some special interface)
<kgunn> ogra_: it would seem like this might be something that other people would want to know as snap image creation proliferates in the world
<morphis_> ogra_: mvo told me to poke you about https://bugs.launchpad.net/snappy/+bug/1654588
<mup> Bug #1654588: Make /etc/systemd/logind.conf.d writable <Snappy:New> <https://launchpad.net/bugs/1654588>
<mup> Bug #1654588 opened: Make /etc/systemd/logind.conf.d writable <Snappy:New> <https://launchpad.net/bugs/1654588>
<ogra_> claimed :)
<ogra_> morphis_, uploaded to the PPA ... will be in the next core
<mup> Bug #1654590 opened: docker interface should account for /run/shm/ in addition to /dev/shm <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1654590>
<morphis_> ogra_: you're my hero :-)
<mup> PR snapcraft#1032 opened: Use more secure temporary directory for parser runs <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1032>
<mup> PR snapd#2573 opened: snap: add information about tracking channel (not just actual channel) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2573>
<jdstrand> lool: hey, fyi, testing docker on trusty/i386 (note bug 1654590 which I'm going to fix):
<mup> Bug #1654590: docker interface should account for /run/shm/ in addition to /dev/shm <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1654590>
<jdstrand> $ sudo docker run ubuntu:trusty uptime
<jdstrand> docker: Error response from daemon: rpc error: code = 2 desc = "oci runtime error: exec format error".
<jdstrand> lool: oh, nm, I'm dumb
<jdstrand> I think I pulled a 64 bit image
<lool> eh
<jdstrand> lool: do you know how to pull a 32 bit image? sudo docker pull ???
<lool> jdstrand: they only introduced multiarch images recently; the armhf image is named differently: arm/ubuntu instead of ubuntu
<lool> jdstrand: docker run 32bit/ubuntu
<Sweet5hark> can someone advise on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1649620? where to put stuff in "pull()" so that its not deleted and can be used during "build()" -- best without creating extra copies?
<mup> Bug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620>
<lool> jdstrand: TBH 32-bits images might not be maintained anymore
<jdstrand> lool: that is what I tried:
<jdstrand> $ sudo docker pull 32bit/ubuntu
<jdstrand> Using default tag: latest
<jdstrand> Pulling repository docker.io/32bit/ubuntu
<jdstrand> Tag latest not found in repository docker.io/32bit/ubuntu
<jdstrand> I think I'll just focus on amd64 for docker for my testing
<lool> jdstrand: Yes, i386 is not officially supported upstream and they dont really support biarch either
<lool> they need docker support libraries for the 64 bits docker binary inside the 32bits container
<jdstrand> ah
<lool> amd64 is a better base
<lool> or armhf
<lool> or even arm64
<jdstrand> wonder if the i386 snap makes sense then
<seb128> Sweet5hark, what is it that you refer as 'pull()' and 'build()'? snapcraft isn't deleting anything if you don't use 'clean' afaiik
<seb128> Sweet5hark, you said it's only doing that on launchpad and not on local builds?
<seb128> Sweet5hark, oh, I see, you override things with a plugin ... your build() is calling "make clean", you are sure that's not what clean things for you?
<niemeyer> kgunn: Heya
<kgunn> hey o/
<niemeyer> kgunn: What's the actual outcome from console-conf that mir-kiosk depends on?
<kgunn> niemeyer: so from my usage perspective, i dl and flash a mir-kiosk image onto dragonboard....boots, but i can't set  up wifi via console conf b/c mir-kiosk steals the screen
<niemeyer> kgunn: Hmm
<Sweet5hark> seb128: nope. the make clean should never delete the source. FWIW, I put the call to "./autogen.sh" _before_ the make clean just to be sure and it fails to find ./autogen.sh. so between "pull()" and "build()" something clears the parts dir ...
<kgunn> niemeyer: i was thinkin', i could just add access to the /var/lib/console-conf/completed
<kgunn> to the mir interface
<kgunn> to prevent launching in the instance it's not there...
<kgunn> thots?
<seb128> Sweet5hark, but only on launchpad?
<niemeyer> kgunn: The idea of snapctl managed felt nice
<mup> PR snapd#2565 closed: store: setting of fields for details endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2565>
<niemeyer> kgunn: But both of these feel slightly awkward from the perspective that console-conf is going away for good.. it also feels slightly magic
<niemeyer> Finish console-conf and BAM, you're off into something else altogether
<niemeyer> kgunn: If we're exposing console-conf as an actual UI, why isn't the enablement of the kiosk an explicit action?
<niemeyer> mir-kiosk.takeover
<niemeyer> kgunn: That'd feel a lot less like a behind-my-back action, if you see what I mean
<kgunn> niemeyer: yeah, i see what you mean
<Sweet5hark> seb128: nope, locally too.
<seb128> Sweet5hark, sorry, just saw your new comment ... so yeah, snapcraft issue
<seb128> sergiusens or kyrofa might have some clue what could be going on there
<Sweet5hark> seb128: locally, I can work around that by just doing everything in build(). But that doesnt work on lp, as in "build()" you cannot use the network there.
<kgunn> niemeyer: to make sure i understand what you mean tho, are you saying that mir-kiosk.takeover would be somehow built into the tail end of console-conf?
<kgunn> AlbertA: fyi ^
<seb128> Sweet5hark, you can use the network in build now
<niemeyer> kgunn: No.. I mean you'd have an actual command that once called would make the kiosk takeover
<kgunn> niemeyer: k, just thinking it thru....like a real kiosk maker, how they'd install the device..and steps they'd go thru
<seb128> Sweet5hark, see email https://lists.ubuntu.com/archives/snapcraft/2016-December/001978.html
<lazyPower> elopio - (tz differences withstanding) I think i made some progress here - https://gist.github.com/9ce253608b1be84fafd27ed0e63afa32  i've got the bins placed and i'm looking into the plugins/slots i need to enable strict mode.
<niemeyer> kgunn: A polished device experience would hopefully avoid console-conf altogether
<lazyPower> i gave up on trying to fix their symlink issue and went for using their pressed bin delivery for now, so there's no hope of this ever building in launchpad
<niemeyer> kgunn: So it really depends quite a bit on what we want to have
<kgunn> AlbertA: so with this idea ^ we just need to make it not be a daemon
<Sweet5hark> seb128: ah, cool. will give that a try as a workaround.
<AlbertA> niemeyer: kgunn: would "takeover" be similar to calling a config hook?
<AlbertA> or would console-conf just call that command?
<kgunn> AlbertA: iiuc, it would be a separate thing from console-conf
<AlbertA> and what would replace connsole-conf, some sort of provisioning tool on the host computer?
<lazyPower> do we have any info on how to interface with systemd via installed snap? My google-fu is failing me
<mup> PR snapd#2561 closed: many: obtain installed snaps developer/publisher username through assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2561>
<seb128> Sweet5hark, I can confirm your bug btw
<seb128> Sweet5hark, kyrofa, sergiusens, looking like to that the "Preparing to build ..." step is creating the build dir without considering or whether it was already created in the pull
<sergiusens> seb128 why would it be created as part of the pull?
<seb128> Sweet5hark, you should probably pull somewhere else and move it in the build
<seb128> sergiusens, that's what Sweet5hark does in https://git.launchpad.net/~bjoern-michaelsen/df-libreoffice/+git/libreoffice-snap-playground/tree/parts/plugins/x_libreoffice.py?h=xenial#n173
<seb128> sergiusens, that's about https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1649620
<mup> Bug #1649620: stuff downloaded during "pull()" is deleted before "build()" <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1649620>
<mhall119> jdstrand: is granting snap declarations for dbus names going to be something you have to manually do for each app that uses the interface?
<sergiusens> elopio add libreoffice to the candidate testing btw ^
<sergiusens> kyrofa can you help seb128 out? I can do that on and off next week or the week after for sure
<kyrofa> sergiusens, sure, let me take a look
<seb128> sergiusens, kyrofa, Sweet5hark, it's probably for next week now
<Sweet5hark> seb128, sergiusens: yeah, I just just put stuff "somewhere" in pull() and pick it up again in in build(), but there is no way to know if that stays workable.
<sergiusens> Sweet5hark if in pull, put stuff in srcdir or in installdir and it will stick
<Sweet5hark> seb128, sergiusens: e.g. could try to use tmpdir for that, but that might run out of space our stop being accessible on lp etc. -- so some clear advise on how to do that is appreciated.
<jdstrand> mhall119: initial upload, yes. subsequent uploads, no
<Sweet5hark> sergiusens: so downloading stuff to ./libreoffice-build in my case? would work for me, but really, why are we mixing source and work directories left and right btw? (download sources to the rather read-only ./libreoffice-build, having ./parts/plugins in the otherwise transient ./parts)
<kyrofa> Sweet5hark, there are a few somewhat special directories within parts/<part>. src is where stuff is pulled, build is where things are built, and install is where things are installed once the part has completed building
<kyrofa> Sweet5hark, I don't recommend messing with any of those directories. However, other directories within parts/<part> are fair game. For example, I have a PHP plugin that pulls its own extensions to a new directory in there
<mup> PR snapcraft#1033 opened: misc: delete bzr ignore <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1033>
<kyrofa> Sweet5hark, I still don't quite understand why you're wanting to build stuff in the pull step though
<kyrofa> The scrollback was a little spread out so I'm not sure I got everything
<Sweet5hark> kyrofa: I dont want to build during pull
<kyrofa> Ah, you're just cloning and patching, it seems?
<kyrofa> Sweet5hark, you can clone into src if you're not concerned about clobbering your other pulled stuff, or yeah, create your own working area in parts/<part>
<Sweet5hark> kyrofa: all I want from you guys is an explicit statement like: "if you put file during pull() to $FOO dir, you can be sure to still have them there during build()". For LO another possible problem is that if you pull to one dir and then need to copy to a build dir, that might make some builders out of discspace (if you do a full build later)
<Sweet5hark> (aka I want a recommended best practice from you that you promise not to break)
<kyrofa> Sweet5hark, if you create a new directory under parts/<part> that is not part of snapcraft's internal structure, you will have them for all subsequent lifecycle steps. Including clean, actually (which is why plugins have clean_pull, clean_build, etc. functions)
<kyrofa> Sweet5hark, if you're concerned about space, you can use shutil.copytree with file_utils.link_or_copy as its copy_function
<kyrofa> That'll hard link
<Sweet5hark> kyrofa: I mostly concerned about there being no best practice for described by snapcraft and its docs for this. If snap/snapcraft is supposed to be a platform, it needs to keep working with whatever people throw at it. If you dont have a bst practice for this, there will soon be 200 different creative ways to do this in the wild and you will be https://xkcd.com/1172/ 'ed very hard.
<kyrofa> Sweet5hark, the method I described to you is used by numerous plugins within snapcraft itself
<Sweet5hark> kyrofa: that doesnt mean at all that Random J Upstreamcoder will do it that way too.
<kyrofa> Sweet5hark, my point is, if you want a best practice, perhaps that's a good place to look.
<kyrofa> Sweet5hark, I agree that the local plugin stuff needs to be further documented
<mup> Bug #1654629 opened: Async REST API operations don't return 'Location' header <Snappy:New> <https://launchpad.net/bugs/1654629>
<Sweet5hark> kyrofa: Sure, just add it to the docs too, so Random J. (whom we very much want to provide snaps too) has a chance to find it too ;)
<Sweet5hark> right ;)
<jdstrand> roadmr: hi! can you pull r815 of the review tools? this fixes bug #1654451
<mup> Bug #1654451: ubuntu store snap click-review error <Canonical Click Reviewers tools:Fix Committed by jdstrand> <Software Center Agent:Invalid> <https://launchpad.net/bugs/1654451>
<mup> Bug #1654642 opened: classic snap files logs with apparmor ALLOWED messages <Snappy:New> <https://launchpad.net/bugs/1654642>
<diddledan> weird. I've released a corebird snap built by launchpad's autobuilder and it is very broken. Yet the same snapcraft yaml file builds, installs, and runs perfectly fine when I do it manually
<diddledan> building myself I used the command `snapcraft cleanbuild` so I assumed that because that worked then the launchpad autobuilder would produce the same result
<kyrofa> diddledan, happy to take a look at your yaml
<diddledan> kyrofa: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml?id=4fecf0085f66f7024fe7eefafe07ecd540ea318d
<kyrofa> diddledan, can I see the LP log?
<diddledan> do I need to copy that to pastebin or does the direct link work without being me? https://launchpadlibrarian.net/301454571/buildlog_snap_ubuntu_xenial_amd64_corebird-diddledan_BUILDING.txt.gz
<kyrofa> Yeah snap builds are public, link is good
<kyrofa> diddledan, that log seems to end in success... ?
<diddledan> kyrofa: yeah the build is fine. it's the running of the result that fails hard
<kyrofa> Ah
<diddledan> but the same yaml run locally through cleanbuild works fine
<kyrofa> diddledan, the use of architectures in your yaml is a little suspicious. I don't see that often
<diddledan> i.e. the store version is b0rked despite being supposedly identical to what I've built and tested outside of the store
<diddledan> I read somewhere about architectures tag, I can try removing it and letting it rebuild
<kyrofa> diddledan, yeah, remove it and just ask LP to build one snap for each arch
<kyrofa> diddledan, how does the one built by LP break?
<diddledan> the one I've currently got in 'stable' complains that it can't load the en_GB locale because zlib1g shared object isn't present. in response to that I tried adding zlib1g as a stage package and put that in 'candidate' which is where I got the 'omgz0r the world is ending' spew: http://pastebin.ubuntu.com/23753963/
<kyrofa> Hoo, beautiful
<diddledan> :-)
<diddledan> errors are always fun :-p
<kyrofa> diddledan, I think the architectures thing is saying "this snap will run without modification on the archs I specify"
<kyrofa> But then the libs that are being pulled in are probably arch-specific
<kyrofa> So remove that option, and check both i386 and amd64 boxes for which archs to build in LP
<kyrofa> Then it'll build one snap for each arch
<diddledan> so I was basically saying "do a compile, package exactly only the packages I listed in stage-packages, and shut the rest of the world out. hard."?
<kyrofa> The rest of the world meaning the system on which the snap was installed?
<diddledan> meaning that gtk and such are all excluded because I didn't list it directly
<kyrofa> diddledan, no they're included as well as a result of the remote gtk part you're using
<diddledan> hmm
<kyrofa> It's just that which ones are pulled depend on the arch of the builder
<kyrofa> But you're yaml is promising that the resulting snap can run on both amd64 and i386
 * diddledan scrachy head
<diddledan> scratchy*
<diddledan> my Brian hurts :-p
<kyrofa> Heh. Try removing it, and see if that helps. Just make sure you ask LP to build for both archs
<diddledan> yup, I've done so. just waiting on LP now (it hasn't noticed the build needs running yet)
<kyrofa> diddledan, let me know
<diddledan> willdo
<grapestomper_1> looking for help with packaging a deb file - does anyone have a link or two they can refer me to?
<roadmr> jdstrand: sure, r815 coming up
<mup> PR snapd#2574 opened: interfaces/docker-support: allow /run/shm/aufs.xeno for 14.04 (LP: #1654590) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2574>
<jdstrand> roadmr: thanks!
<diddledan> kyrofa: positive result - removing the architectures config fixes it
<kyrofa> diddledan, excellent
<diddledan> now everything is working except loading URLs (I have installed snapd-xdg-open in my host and in devmode that works so maybe there's a problem with strict confinement?) error: http://pastebin.ubuntu.com/23754246/
<diddledan> all http(s) urls are behaving the same way - failing to open with the log message similar to: (corebird:9849): Gtk-WARNING **: Unable to show 'http://gizmodo.com/kodak-swears-its-not-giving-up-on-that-digital-super-8-1790907907?utm_medium=sharefromsite&utm_source=Gizmodo_twitter': Operation not supported
<kyrofa> diddledan, I'm afraid I have zero experience with that. Perhaps jdstrand can help
<kyrofa> diddledan, do you see any denials in syslog or with snappy-debug?
<diddledan> yes, grepping /var/log/syslog reports apparmor="DENIED"
<diddledan> oops
<diddledan> http://paste.ubuntu.com/23754260/
<diddledan> ^ reports that
<diddledan> last 5 lines seem to be the most recent attempt
<diddledan> let me try snappy debug
<jdstrand> I don't have much experience with snapd-xdg-open except to say that it will open things on the applications behalf and wouldn't be affected by the snap's security policy. the denials indicate that your snap *may* not be using snapd-xdg-open (it's possible a library is trying to look in there, in which case those denials would be harmless)
<jdstrand> you can add the following to /var/lib/snapd/apparmor/profiles/snap.corebird-diddledan.corebird:
<jdstrand> /usr/share/applications/{.*} r,
<jdstrand> /var/lib/snapd/desktop/applications/{,.*} r,
<jdstrand> then run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.corebird-diddledan.corebird
<jdstrand> then restart your snap and see if it works or if you get other denials (that may indicate if your app is trying to find a suitable handler or passing to snapd-xdg-open)
<diddledan> should I add those two lines to the bottom or in a specific location of the profile?
<jdstrand> diddledan:: anywhere is fine. just before the trailing '}'
<diddledan> ok, I added those lines (fixing the missing comma in the first one :-p) but still failing. it seems corebird isn't using xdg-open then
<jdstrand> diddledan: whoops, the first has a typo
 * jdstrand nods
<jdstrand> sounds like it, yeah. I think didrocks may know more, but he seems offline
<jdstrand> maybe send a new email to the list?
<diddledan> it's odd because I know that I _have_ had it working with the same version of corebird but in a devmode snap
<jdstrand> hmm
<mup> PR snapcraft#1009 closed: store: implement push pre-check <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1009>
<diddledan> I'm thinking maybe the environment in which LP compiles could be slightly different to a cleanbuild lxd container?
<diddledan> that seems to be the only difference - the snap built by LP rather than locally
<diddledan> other than devmode/strict
<diddledan> ok, it's not a cleanbuild vs LP issue. that leaves the only difference being strict vs devmode - retrying a build using devmode to test the theory
<diddledan> yes. the same package installed using --devmode to snap install allows xdg-open to work correctly
<diddledan> is there a way to change from strict to devmode on an already installed and up-to-date store version without removing and reinstalling?
<diddledan> revert --devmode is possible but that requires a previous version to be available on your system
<diddledan> and refresh --devmode is possible but that requires a later version in the store than you have installed
<jdstrand> diddledan: I'm not sure how to move back and forth. I can try to reproduce here
<kyrofa> jdstrand, how much do you know about gnome-keyring? Would an interface for it be easy, you think?
<jdstrand> kyrofa: I can't think of anything otoh that would be particularly difficult
<kyrofa> jdstrand, is it just dbus?
<jdstrand> afaik
<kyrofa> jdstrand, would you say it would need to be privileged?
<kyrofa> i.e. manual connection required
<jdstrand> kyrofa: for sure
<jdstrand> on Ubuntu, the keyring is unlocked on login and any application in the session get obtain the passwords
<kyrofa> jdstrand, yeah makes sense
<jdstrand> for it to be auto-connectable, gnome-keyring would have to be modified to only allow access to certain keys from certain security labels
<jdstrand> and/or have apparmor integration, then we could think about policy
<kyrofa> Alright
<jdstrand> diddledan: this is needed: /usr/local/share/applications/{,*} r,
<diddledan> jdstrand: yes, confirmed, that line added to the profile fixes it
<jdstrand> diddledan: https://bugs.launchpad.net/snappy/+bug/1654666
<mup> Bug #1654666: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666>
<jdstrand> diddledan: I'll get that fixed hopefully for 2.21
<diddledan> thank you. I've marked as affecting me, and subscribed to notifications :-)
<jdstrand> cool
<mup> Bug #1654666 opened: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1654666>
<jdstrand> I'm heading out now, but feel free to add comments to the bug
<diddledan> ok
<diddledan> thanks again
<jdstrand> np
#snappy 2017-01-07
<mup> PR snapcraft#1029 closed: rust plugin: add conditional compilation <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1029>
<mup> PR snapcraft#1034 opened: rust plugin: respect fetch parameters <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1034>
<mup> PR snapcraft#1035 opened: rust plugin: use the part source path <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1035>
<mup> PR snapcraft#1036 opened: parts: better error message when defining parts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1036>
<mup> PR snapcraft#1037 opened: schema: support the notify daemon type <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1037>
<mup> PR snapcraft#1033 closed: misc: delete bzr ignore <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1033>
<mup> PR snapcraft#1038 opened: misc: delete bzr ignore <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1038>
<thresh> hello
<thresh> I'm packaging a gettextized application.  How do I make sure the user's locale is picked up by the app?
<thresh> do I include locales-all in the stage-packages, and provide a plug: locale-control?  Sounds like a bad idea since there will be a lot of unused data on the filesystem..
<thresh> the .snap size is already quite enormous (~125M)
<ahayzen> thresh, this bug seems related https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282
<thresh> thanks, and it does not work for me, since I don't really want to pass any .so preloaded
#snappy 2017-01-08
<mup> PR snapcraft#1036 closed: parts: better error message when defining parts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1036>
<mup> PR snapcraft#1037 closed: schema: support the notify daemon type <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1037>
<mup> Bug #1653512 opened: Transition away from ubuntu-core-launcher not smooth <Snappy:New> <https://launchpad.net/bugs/1653512>
<mup> Bug #1639948 changed: exec: /usr/bin/ubuntu-core-launcher: not found <Snappy:Expired> <https://launchpad.net/bugs/1639948>
<mup> Bug #1640229 changed: error refreshing snap <Snappy:Expired> <https://launchpad.net/bugs/1640229>
<UniSuperBox> Hello everyone. Is there any way to get snapcraft to perform a source pull every time I run it? I want it to pick up changes that I've made to the source, but not redownload os.snap
<mup> PR snapcraft#1039 opened: Check the older ubuntu-core snap name for core dynamic linker <Created by thomir> <https://github.com/snapcore/snapcraft/pull/1039>
<thresh> so now I have version: daily in snapcraft.yaml for my package
<thresh> I would rather like it to be something along the lines of 3.0.0 (current VLC development version)
<thresh> questions are, would they upgrade nicely from daily to 3.0.0?  how do I do about upgrading 3.0.0 (current) to the 3.0.0 release?
<mup> Bug #1647517 opened: Segmentation fault on core snap refresh from candidate channel <Snappy:New> <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1647517>
#snappy 2018-01-01
<azepic819> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)mrkaz: chihchun_afk sbeattie lamont âââââââââââââââ
<azepic819> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)gpqrzcggyx: Guest87025 palasso flexiondotorg ââââââââââââââ
<azepic819> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)yshieugid: stokachu kristbaum niemeyer ââââââââââââââââââââ
<azepic819> ââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)rwvkcsmve: kristbaum jospoortvliet AmarokNelg âââââââââââââââââ
<azepic819> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dynehh: Kaleo joedborg tianon ââââââââââââââ
<palasso> JamieBennett ogra
<mcphail> flexiondotorg: I saw you post about MATE welcome and boutique as snaps. Are snaps available on the Pi MATE image yet? It'd be a shame to break compatibility
<flexiondotorg> mcphail: Not yet, but something I want to resolve for 18.04.
<mcphail> flexiondotorg: brilliant. I was hoping that would be the answer!
#snappy 2018-01-02
<mborzecki> morning
<zyga> good morning! :)
 * zyga looks at a mountain of email
<mborzecki> zyga: hey
<zyga> hey :)
<zyga> happy new year
<mborzecki> likewise :)
<mborzecki> zyga: did you enjoy your break?
<zyga> mborzecki: yes, it almost feels weird to go back after so long
<mborzecki> i would call it a shock, rather than just being weird :)
<kalikiana> good morning
<kalikiana> happy 2018
<zyga> good morning kalikiana!
<pstolowski> mornings!
<mborzecki> pstolowski: hey
<zyga> good morning koza
 * zyga reboots for some updates
<mborzecki> mvo: hey
<mup> Issue snapcraft#1837 closed: Can't run snapd on Codenvy 5.22.0 <Created by 20avva> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1837>
<mvo> hey mborzecki! how are you?
<mvo> mborzecki: did I miss anything interessting this morning :) ?
<mborzecki> (unsurprisingly) the morning has been rather slow
<mborzecki> i'm poking around yocto support, slow progress however
 * mvo nods
<mvo> mborzecki: yocto> nice to hear
<mborzecki> promised this guy https://forum.snapcraft.io/t/yocto-rocko-core-snap-kernel-panic/3261/11 to look into it once i get back :)
 * mvo nods
<mup> Issue snapcraft#1834 closed: Feature Request: NGINX plugin <Created by jamesbeedy> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1834>
<mup> PR snapd#4427 opened: snap: fix snap find " " output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4427>
<mborzecki> zyga not around?
<mvo> mborzecki: heh
<zyga> hey mvo :) long time no see
<zyga> how are you doing?
<mborzecki> zyga: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L589 afaiu /root is assumed to always exist then?
<zyga> mborzecki: yes, there's a lot of directories we just assume
<zyga> mborzecki: for /root we could skip it if absent
<mborzecki> i'm asking as it's not here in poky (yocto build), at least with rocko brach (the last release)
<mvo> hey zyga ! good to see you, happy new year
<mborzecki> frankly, i don't recall if it used to be there or now, never needed to do/keep anything around in /root
<clienthax__226> ââââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!jmnaxjlu: ubot9 hurricanehrndz verterok âââââââââââââââ
 * kalikiana coffee break
<zyga> hey Chipaca
<Chipaca> zyga!
<Chipaca> how's things?
<zyga> Chipaca: snappy :)
<zyga> Chipaca: still waking up/getting into coding spirit (code reviews now)
<zyga> how are you doing? are you feeling better?
<mvo> hey Chipaca! welcome back, great to "see" you
<Chipaca> mvo: o/
<Chipaca> zyga: i caught a lot of sun, and a little head cold, but overall feeling good. you?
<zyga> Chipaca: I'm doing great, disappointed for not having much snow this xmas
<Chipaca> mvo: likewise, how're you doing?
<mup> PR snapd#4428 opened: daemon: return "bad-query" error kind for store.ErrBadQuery <Created by mvo5> <https://github.com/snapcore/snapd/pull/4428>
<Chipaca> zyga: snow is nice but i'm happy with my choice :-)
<zyga> Chipaca: did you travel somewhere warmer for your holidays/
<mvo> Chipaca: in general great, today in particular not so great, caught a stomach bug yesterday and still feel weak from that. but hacking beats lying in bed and being bored :)
<Chipaca> mvo: i'll preted not to know half of your hacking today is from an unconventional seat
<mvo> lol
<Chipaca> zyga: visiting friends on the costa d'azur
<zyga> Chipaca: stdout flushes manually, stderr flushes on output ;-)
 * zyga stops thinking about IO jokes
<zyga> Chipaca: ah, lovely
<zyga> Chipaca: I've visited some friends from Catalonia but we chose to go to the capital of coal in poland (katowice) instead :)
<Chipaca> oooh
<Chipaca> i've only run trains through the places you visit
<Chipaca> mvo: is the client side of the bad query kind coming, or not needed?
<mvo> Chipaca: I can add it,  I think it makes sense, I was mostly doing it for roberts glib based client implementation
<mvo> (where it is not needed AIUI) - but for symmetry it does make sense
<Chipaca> mvo: if we're not going to use it, it's just bitrot waiting to happen
<Chipaca> mvo: (otoh all the kinds could use a reshuffle to not be defined twice...)
<Chipaca> dunno
 * Chipaca does not bring new wisdom into the new year
<mvo> Chipaca: lol
<mvo> Chipaca: all good, I will push the client side and make a nice(r) error message for `snap find "()!Â§$Â§%Â§%*"`
<mvo> Chipaca: something like "error: cannot list snaps: bad query, please use less special chars"
<zyga> mvo: "please use latin letters or digits" maybe
<Chipaca> oh you just reminded me i probably need to change this error message before submitting it as a PR
<mvo> zyga: yeah, thats better
 * zyga looks at the intense fog outside
<Chipaca> 	ErrAppEscapes   = errors.New("snap is unusable due to fuckery")
<mvo> Chipaca: *cough* this is a family channel!
<zyga> mvo: or arabic digits ;-)
<Chipaca> mvo: /o\ sorry
<mvo> zyga: maybe ascii letters/digests
 * mvo hugs Chipaca 
<zyga> Chipaca: go and stand in the corner now ;;-)
<zyga> mvo: yeah
 * Chipaca hugs mvo from the corner
<zyga> we have a lot of PRs
<mvo> zyga: my fault
<zyga> mvo: how is that a fault? :)
<zyga> mvo: thank you for all the nice fixes
<mvo> zyga: I was doing bug triage and there is soooo many low hanging fruits
<zyga> can I get a review on https://github.com/snapcore/snapd/pull/4315
<mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga> it's from _november_ and has one review
 * zyga boots subsequent VM for the round of updates
<Chipaca> how's travis/linode/spread behaving?
<zyga> I haven't tried anything new yet, I see lots of red PRs though
<zyga> so maybe it's still having a hangover
<Chipaca> zyga: one of the things we realised towards the year end was that the interfaces-many was taking a relatively long time to run
<Chipaca> as in 10 minutes
<zyga> that's pretty slow, is it CPU bound on apparmor compiler?
<Chipaca> zyga: probably not
<Chipaca> zyga: because dropping the unlock/lock around things dropped the time down a lot
<Chipaca> iirc down to 4 minutes? somehting like that
<zyga> Chipaca: oh? that's curiou
<zyga> Chipaca: around what specifically?
<Chipaca> zyga: around â¦ and this is from memory â¦ the security backend setup loop? something like that
<Chipaca> zyga: basically it means moving to an actual database for state should not be postponed much longer
<zyga> Chipaca: and that locking serializes state and this is expensive?
<Chipaca> zyga: yep
<Chipaca> zyga: when done in a loop like in that test, yes
<Chipaca> keep in mind because of what that test does, it's almost a worst case
<Chipaca> lots of changes to serialize
<zyga> Chipaca: lots as in "KBs of text"
<zyga> Chipaca: I think the real DB will take some time to arrive
<mborzecki> Chipaca: 'actual database' do you have anything particular in mind?
<zyga> Chipaca: it's a major change
<Chipaca> zyga: yes i know
<pedronis> I told the same, given everything it's a post 18.04 afai would guess
<Chipaca> mborzecki: gustavo had thoughts on this, there was somehting ike an in-memory all-go db
<zyga> Chipaca: is it possible that the cost is in fsync ops and not in anything else?
<Chipaca> pedronis: hello :-)
<pedronis> BoltDB I think
<Chipaca> pedronis: just trying to make sure this isn't lost
<pedronis> is what Gustavo mentioned
<Chipaca> zyga: go's profiler pointed to json encode
<pedronis> Chipaca: hello,  me is slowly rebooting :)
<mborzecki> mhm, i'm asking cause we moved to lmdb at some point in mender
<Chipaca> zyga: but it _might_ be io disguised as that
<mup> PR snapd#4429 opened: tests: add regression test for LP 1681739 (snap var interpolation) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4429>
<Son_Goku> I still have one more week of vacation :)
<mup> PR snapd#4405 closed: taskrunner/many: KnownTaskKinds helper <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4405>
<mup> PR snapd#4428 closed: daemon: return "bad-query" error kind for store.ErrBadQuery <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4428>
<mup> PR snapd#4420 closed: cmd: clarify "This leaves %s tracking %s." message <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4420>
<mup> PR snapd#4403 closed: asserts/signtool: support for building tools on top that fill-in/compute some headers <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4403>
<mup> PR snapd#4422 closed: packaging/arch: disable services when removing <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4422>
<Chipaca> Son_Goku: showoff
<Son_Goku> eh, I was sick most of my vacation
<Son_Goku> this might be my only "enjoyment" week
<Chipaca> Son_Goku: I think everywhere I've lived, if you're sick during a vacation it counts as sick leave and not vacation
<Son_Goku> I filed it as vacation, then became sick after
<Son_Goku> at that point, it doesn't matter
<Son_Goku> I got sick during my trip to my parents' home
<Chipaca> Son_Goku: i understand you filed it as vacation, but if you get sick during your vacation, you can then claim it back (and take your vacation when you're not sick)
<Chipaca> this is, in argentina and the eu it works
<Chipaca> i've not lived elsewhere
<Son_Goku> it's true here too
<Chipaca> good to know
<Son_Goku> but as I have "unlimited PTO" and only 5 sick days, there's no point
<Chipaca> Son_Goku: i understand if it's academic because of â¦ yeah, those limits
<Chipaca> Son_Goku: especially if sick days are not paid
<Son_Goku> sorry, five paid sick days
<Chipaca> Son_Goku: and is the unlimited PTO also paid?
<Son_Goku> yes
<Son_Goku> if I take more than two weeks of sick leave, I'd probably be fired
<Chipaca> ah fair enough :-)
<Son_Goku> not without some kind of doctor's notice, anyway
<Chipaca> ah yeah the "claim it back" thing involves a doctors scrip
<Chipaca> strip?
<Chipaca> bit of paper
 * Chipaca has no idea where he picked up that word
<mvo> zyga: quick question about lp: 1708703
<kalikiana> Chipaca: strips of paper exist. although you might want to take the whole one with you to show to your employer rather than tearing of part of it ;-)
<Son_Goku> heh
<Chipaca> kalikiana: pretty sure it's 'scrip'
<Chipaca> kalikiana: but as i say, dunno where i picked it up
<Chipaca> my english has [*] reference needed all over the place
<Chipaca> citation*
<Son_Goku> scrip is technically correct
<Son_Goku> though I've not heard that word in common use
<Son_Goku> it's short for prescription
<Chipaca> the sources of my english include, but are not limited to, north scottish fishermen, south american british hospital staff, and welsh [censored]
<Chipaca> Â¯\_(ã)_/Â¯ family
<pedronis> interestingly enough in that use is a contraction of script itself there a contraction of prescription
 * pedronis (is perusing a dictionary)
<zyga> mvo: looking
<mvo> zyga: mostly curious if you know more about it as you assigned it to yourself
<zyga> mvo: yes, I remember now
<mvo> zyga: tell me more please
<zyga> mvo: looking at the code, when we enable / disable we setup security
<zyga> mvo: then we look at snaps that were affected and also setup those
<zyga> mvo: then that can fail "silently" when we cannot get snap state for any of those snaps
<zyga> mvo: now I'm not sure if this is happening here
<zyga> mvo: let me try
<zyga> mvo: it looks ok but ...
<mvo> zyga: I tried it today and can still reproduce it (with the mir snaps)
<zyga> mvo: did you try that in a VM with core snap?
<zyga> mvo: or on classic?
<mvo> classic
<zyga> mvo: aha, let me see master quickly now, just adding some logging
<mvo> ok
<zyga> mvo: logging in tests says it's not broken, may be broken later, trying with real snaps now
<mvo> zyga: ta
<zyga> mvo: hmm, mir-kiosk is not in the store?
<zyga> ah, edge
<mvo> yes
<zyga> ha
<zyga> indeed
<zyga> the reason is simple, autoconnect
<Chipaca> for some reason i thought we were interpolating variables in app commands
<zyga> mvo: when the mir-kiosk-apps is disabled it gets disconnected
<Chipaca> turns out we aren't
<Chipaca> weren't we going to do that?
<zyga> mvo: then when it is enabled it thinks that nothing happened because of autoconnect
 * zyga looks
<mvo> zyga: iirc it was still showing as connected when I tried
<zyga> mvo: yes, there's something buggy going on
<zyga> mvo: it should say it got disconnected but didn't
 * mvo nods
<zyga> mvo: oddly repo.DisconnectSnap returns [] so something is very fishy there
<zyga> mvo: so on enable r.plugs[] and r.slots for that snap is empty
<zyga> mvo: so something is wrong in the repo, digging deeper
<mvo> ok
<mvo> thanks
<zyga> pstolowski: ^ FYI
<pstolowski> zyga, is this re 1708703?
<zyga> yes
<zyga> I see the bug now
<pstolowski> ok, for a moment I thought I broke something in recent refactorings, but I guess that's an older issue
<zyga> yes, it looks like an older issue
<pstolowski> interesting how it survived all the changes :/
<zyga> fixed :)
<zyga> now for some tests
<pstolowski> zyga, thank you
 * pstolowski lunch
<mup> PR snapd#4430 opened: overlord/ifacestate: fix disable/enable cycle to setup security <Created by zyga> <https://github.com/snapcore/snapd/pull/4430>
<zyga> pstolowski, mvo: ^
 * mvo hugs zyga 
<Son_Goku> zyga, when are you going to give me snapd selinux backend? :)
<zyga> Son_Goku: no idea, but if I start now maybe in December?
<Son_Goku> better than never, so worksforme
<zyga> Son_Goku: I haven't discussed what our todo list is yet
<sergiusens> morning
<zyga> hey sergiusens :)
<kalikiana> morning sergiusens
<kalikiana> and happy new year
<mup> PR snapd#4429 closed: tests: add regression test for LP 1681739 (snap var interpolation) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4429>
 * kalikiana going to take a lunch break in ~15
<Chipaca> mborzecki: in https://paste.ubuntu.com/26306252/, what  is the 1st column?
<mborzecki> Chipaca: just an index in the data set
<mup> PR snapcraft#1838 opened: tests: fix broken rust test snap <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1838>
<mborzecki> Chipaca: same dataaset, ubuntu-16.04-64 only this time: https://paste.ubuntu.com/26306338/
<Chipaca> mborzecki: hmmm
<Chipaca> mborzecki: what does the duration of the suite mean?
<Chipaca> mborzecki: because the suite takes 58s and in the suite a bunch of tests take 50s, it sounds like an accouting error
<Chipaca> oh wait
<zyga> Chipaca: is it measuring wall time or accumulated time from each node?
<mborzecki> Chipaca: it's taken from travis folds
<Chipaca> mborzecki: my mistake sorry
<Chipaca> tests/main/completion vs tests/completion :-)
<zyga> meh, it's getting dark already
<zyga> my monitors are too bright
<zyga> and have poor controls for adjusting
<Chipaca> zyga: redshift?
<zyga> Chipaca: i think it's built into gnome now
 * zyga looks for that
<Chipaca> zyga: yes (but don't you need to enable it?)
<zyga> Chipaca: I'm also complaining about short daylight cycle here :( software cannot fix that
<Chipaca> zyga: i'm pretending not to notice
<zyga> enabled :)
<zyga> thank you for reminding me about it
 * kalikiana bbl
<zyga> Chipaca: on the other hand I moved my systems to a darker green tinted wallpapers/color schemes and I like that a lot
<Chipaca> man, apt needs a 'find' alias now :-(
<mborzecki> zyga: about teleconsole on fedora, `snap run --shell teleconsole` should not fail with 'execv failed: No such file or directory', right?
<zyga> mborzecki: right
<zyga> mborzecki: it looks like it's trying to exec /usr/lib/snapd/snap-exec
<zyga> vs libexec
<zyga> (just a guess)
<zyga> I haven't rebooted F27 after updates
<zyga> 47% installing
<mborzecki> but it works for 'hello' snap
<zyga> classic doesn't do redirection
<zyga> I think I know what's going on
<zyga> we disabled classic on fedora
<zyga> so you did the symlink
<zyga> but the code that runs classic stuff had hardcoded assumptions on dir layout
<zyga> if you print execed programs you will see (probably) it running the wrong directory
<pedronis> Chipaca: #4389 and #4392 are probably PRs you could review
<mup> PR #4389: overlord/snapstate: override Snapstate.UserID in refresh if the installing user is gone <Created by pedronis> <https://github.com/snapcore/snapd/pull/4389>
<mup> PR #4392: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392>
<zyga> mborzecki: as a quick test add a symlink /usr/lib/snapd -> /usr/libexec/snapd
<mborzecki> zyga: right, works now
<zyga> mborzecki: cool, that should be as simple fix
<zyga> *a
 * zyga removes 34,028 messages from launchpad from his inbox
<mborzecki> zyga: hm we can't exactly mess with rootfs and fedora guys would probably be unhappy if we symlink, the fix would need to be automatically cleaned up when snap exits
<zyga> no no, the symlink is just a test
<zyga> we don't need it
<zyga> but we now know exactly what is wrong
<zyga> it's a simple bug in cmd.go
<zyga> or cmd_run.go
<mborzecki> zyga: https://paste.ubuntu.com/26306484/ like this? :)
<zyga> yes
<zyga> looks excellent
<zyga> thank you!
<zyga> mborzecki: look at how this behaves when classic + reexec is in use
<zyga> mborzecki: but this looks ok for fedora
<mborzecki> zyga: https://paste.ubuntu.com/26306521/
<mborzecki> and teleconsole works now, yay
<zyga> I think the test is wrong
<zyga> if you are reexeed you want:
<zyga> path to core snap in the distro + core libexec dir
<zyga> e.g. /var/lib/snapd/snap/core/current/usr/lib/snapd/snap-exec
<zyga> which combines a fedora-specific snap mountdir + core layout that contains snap-exec
<zyga> you can perhaps simplify
<mborzecki> hmm right
<zyga> by using the same trick that cmd.go does
<zyga> find your own executable
<zyga> and then run snap-exec as your peer
<zyga> though because snap is not in the same directory as snap-exec or snap-confine, this may be more cloudy
<zyga> I'd vote for a direct test + explicit join
<mborzecki> mhm
<mborzecki> looks like we have a way forward, i'll open a PR later
<zyga> thank you :)
<mborzecki> been fun chasing it
<mborzecki> still now idea why strace hangs occasionally
<mborzecki> anyways, i'm off to pick up the kids
<Chipaca> so, the completion tests do take 50s per
<Chipaca> they can be made significantly faster by dropping a delay and/or by bumping a send rate
<Chipaca> these two things exist because without them the tests were flaky
<Chipaca> should I try dropping them to see if they continue being flaky?
<zyga> Chipaca: worth a try, I wonder if we could do _something_ to become reliable
<kalikiana> re
<mup> PR snapd#4421 closed: daemon: add new polkit action to manage interfaces <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4421>
<mup> PR snapd#4427 closed: snap: fix snap find " " output <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4427>
 * zyga break for small taxes and paperwork
<elopio> good morning team!
<jdstrand> kyrofa: hi! I played with the nextcloud snap a bit over the holiday. I was wondering if you thought about a content interface (readonly?) for it so that snaps on the system could access the files. eg, a minidlna snap could consume nextcloud content for serving movies, pictures and/or videos
<jdstrand> kyrofa: and happy new year :)
<sergiusens> elopio good morning
<kyrofa> Happy New Year everyone!
<kyrofa> Morning jdstrand :)
<sergiusens> kyrofa hey
<kyrofa> jdstrand, I considered it, but it's possible for someone to use the removable-media interface for data, and then the snap isn't sharing anything useful
<kyrofa> Hey there sergiusens, nice break?
<jdstrand> kyrofa: with the nextcloud box, it stores its data not in /media by default since it formats the drive and installs itself on it
<popey> Saviq: is there an easy way to make a multipass disk bigger, 2.1GB seems awfully small for the initial size
<kyrofa> jdstrand, yeah, by default it uses $SNAP_COMMON
<Saviq> popey: on launch, pass `--disk 5G` or so
<jdstrand> kyrofa: I was thinking of creating a systemd unit to bind mount stuff into /media and use removable-media for a minidlna snap, but thought maybe things could be easier for people
<popey> Saviq: but not after I made it?
<Saviq> popey: 2G is what the default size is of the cloud images
<jdstrand> kyrofa: anyway, food for thought
<Saviq> popey: I think someone wrote on the forums how to do it after launch
<Saviq> it's not trivial since you have to resize the FS
<popey> found it, thanks
<Saviq> so I'm not sure we'll ever built that functionality into multipass (but we'll allow you to change the default initial size)
<popey> I'll destroy and start again :(
<jdstrand> kyrofa: also, is the nextcloud-client expected to be fully functional? (excepting auto-start)
<Saviq> popey: we might bump the default anyway, it's qcow so it's not stealing your storage straight away
<kyrofa> jdstrand, indeed, although I'll admit I don't use it due to the autostart thing so I wouldn't be surprised to learn that it has issues. Does it?
<jdstrand> kyrofa: (nextcloud-client snap that is. I kept ending up with defunct processes and things not syncing (not 100% sure things not syncing was the snap's fault and not mine cause it was still early days in my playing)
<jdstrand> )
<kyrofa> Hmm, that sounds odd
<zyga> jdstrand, kyrofa: hey :)
<jdstrand> happy new year zyga :)
<kyrofa> Happy new year, zyga! How was break?
<zyga> kyrofa: exhausting :) too long I would say
<kyrofa> Hahaha
<zyga> kyrofa: I'm happy to be back :)
<zyga> how are you guys doing? I heard US has move to ice age
<zyga> *moved
<sergiusens> kyrofa good, yourself?
<sergiusens> zyga I want to be on a break for longer!
<kyrofa> Yeah me too
<kyrofa> sergiusens, short, but good
<zyga> sergiusens: for how long were you away?
<sergiusens> zyga just the week in between the two big holidays
<ppisati> ogra_: i think some files were moved inside os.snap, without updating the kernel plugin
<ppisati> ogra_: can you give your opinion on this?
<ppisati> ogra_: https://bugs.launchpad.net/snapcraft/+bug/1740882
<mup> Bug #1740882: Missing initrd.img-core in os.snap <Snapcraft:New> <https://launchpad.net/bugs/1740882>
<kalikiana> kyrofa: Happy New Year, Franz ;-)
<kyrofa> Hey there kalikiana! Back at you. How was your break?
<kalikiana> Very necessary, haha
<kyrofa> No kidding
<mup> PR snapd#4430 closed: overlord/ifacestate: fix disable/enable cycle to setup security <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4430>
<Chipaca> mborzecki: mvo: anything further blocking #4394?
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<ogra_> ppisati, i didnt touch anything (still on vacation) ... if anyone moved anything around it would likely be mvo though
<ppisati> mvo: ^
<ppisati> ogra_: ta
<mvo> ppisati: probably https://github.com/snapcore/core/pull/63 but its slightly puzzling, there is a symlink there - is this symlink broken?
<mup> PR core#63: 25-create-generic-initrd.chroot: use symlink instead of copy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/63>
<mvo> ppisati: fwiw, this was requested to be a symlink instead of a copy to help the store with diff generation
<ogra_> yeah, looks more like an issue with the kernel plugin not respecting links
<ppisati> nope, the kernel plugin expected usr/lib/ubuntu-core-generic-initrd/initrd.img-core to be the real file and not a symlink, that's because at the beginning of _unpack_generic_initrd() only a portion of os.snap was unsquashed - so now instead of the file, we have a dangling symlink to something that is not there
<ppisati> anyhow, thnaks for the confirmation, i alread attached a patch to the LP that fixes it
<ogra_> yeah, looks good to me
<mup> PR snapd#4431 opened: snap: make `snap info invalid-snap` output more user friendly <Created by mvo5> <https://github.com/snapcore/snapd/pull/4431>
<mvo> zyga: iirc we discussed lp: #1705549 a while ago, do you remember the details? I would like to update the bugreport
<mup> Bug #1705549: Snaps in lxc can't refresh if old revisions need to be cleaned <snapd:New> <https://launchpad.net/bugs/1705549>
<zyga> mvo: yes
<zyga> mvo: we went through several rounds of attemps to fix this and have a solution that seems oK both technically and from security POV but haven't implemented it
<mup> PR snapcraft#1839 opened: kernel plugin: update initrd.img-core path to boot/initrd.img <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1839>
<mvo> zyga: anything I could point to in the bug?
<zyga> mvo: prior attempts either worked but were too open for security or didn't work
<zyga> mvo: I can look for several PRs but those are all closed now
<zyga> one has some interesting discussion
<zyga> let me find it
<zyga> mvo: this is one https://github.com/snapcore/snapd/pull/4258
<mup> PR #4258: cmd/snap-confine,tests: fix unmounting on systems without rshared / <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4258>
<zyga> (I think the interesting discussion was on IRC acctually :/)
<mvo> zyga: thanks
<mvo> jdstrand: your opinion on lp: 1698412 would be appreciated. the question is if bluetooth-control should be able to read /sys/bus/usb/drivers/btusb/module/
<leftyfb> If I install gnome-3-26-1604 on Ubuntu 16.04, will that just allow other snaps which are connected utilize it or does it install/setup my entire DE to use it?
<kyrofa> leftyfb, it's just a runtime for other snaps
<leftyfb> ok, good to know
<leftyfb> hey kyrofa!
<leftyfb> kyrofa: sorry we haven't got back to you
<mup> PR snapcraft#1838 closed: tests: fix broken rust test snap <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1838>
<leftyfb> kyrofa: things got kinda busy with the holidays/retail
<kyrofa> Haha, same here! No worries
<jdstrand> mvo: I'll take a look and comment
<leftyfb> kyrofa: snappy is something we'll definitely be looking at this year. We first need to get all the customers running Xenial
<kyrofa> leftyfb, understood! You know where to find me, always happy to help :)
<mvo> jdstrand: also lp: #1689577 would be appreciated. hopefully quick and easy (both of them :)
<mup> Bug #1689577: bad system call "shutdown" trying to use systemd-cat from a snap <snapd:Incomplete> <https://launchpad.net/bugs/1689577>
<kyrofa> leftyfb, and I'm glad to see you around!
 * kalikiana going to call it a day - see you guys tomorrow
<mup> PR snapcraft#1840 opened: docker: instructions to build from the snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1840>
<kyrofa> Hey zyga, are you still working on that lxd snaps not updating bug?
<zyga> hey
<zyga> not at present but I will likely come back to it soon
<zyga> (this week)
<zyga> I'll focus on landing https://github.com/snapcore/snapd/pull/4329
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<kyrofa> zyga, okay
<kyrofa> sergiusens, the circle ci tutorial, would you like that to be a snappy-docs document, or a tutorials.ubuntu.com document?
<zyga> HEADS UP EVERYONE: 2.30 is now in stable
<sergiusens> kyrofa tutorials, to match the travis one
<kyrofa> Oh riiight, forgot about the travis one
<zyga> mvo: so, who can we ask from the store?
<kyrofa> sergiusens, 1-1 today? I don't have anything particularly new to share, so we can skip if you like
<kyrofa> I'll assume that's a skip
<sergiusens> kyrofa yeah
<sergiusens> elopio let's skip unless you have something
<elopio> sergiusens: next week I will have something :)
<mup> PR snapcraft#1841 opened: Update test_export_login.py <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1841>
<mup> PR snapcraft#1833 closed: cli: humanize push message <Created by Sheogorath2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1833>
#snappy 2018-01-03
<mborzecki> morning
<zyga> o.
<zyga> o/
<zyga> good morning everyone
<mborzecki> zyga: hey
<kalikiana> o/
<kalikiana> morning, zyga
<zyga> hey pawel
<zyga> sorry for being absent earlier, my son is ill and I'm trying to get him ready for a visit at the doctor's
<zyga> so 2.30 is out, any hiccups on your machines?
<zyga> mborzecki, pstolowski: can you check snap changes for any failures?
<pstolowski> zyga, looks sane here
<mup> PR snapd#4432 opened: cmd/snap,  tests/main/classic-confinement: fix snap-exec path when running under classic confinement <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4432>
<zyga> thank you mborzecki, looking :)
<mborzecki> zyga: also reenabled one of the classic confinements tests on fedora now ;)
<zyga> sweet
<zyga> mborzecki: approved
<mborzecki> great
<zyga> mborzecki: I was thinking about the fedora symlink, perhaps we could enable that in prepare.sh globally
<zyga> not a big deal and perhaps a risk in itsel
<zyga> let's see if more tests start to need that
<mborzecki> hm better talk to Son_Goku first
<mborzecki> uhh, you're talking about tests
<zyga> yes, just tests
<zyga> pstolowski: can you please review https://github.com/snapcore/snapd/pull/4315
<mup> PR #4315:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga> it has one +1 and I want to land it
<zyga> it's from november :'(
<mborzecki> looks like there's just a handfull of 'classic' confiment tests, we could enable fedora in those explicitly
<zyga> mborzecki, pstolowski: in case you need to do it, this is how to release the core snap: https://new.zygoon.pl/post/core-snap-release-mechanics/
<mborzecki> zyga: good i'm not the only one finding arch/revision combination confusing
<mborzecki> anyone wants to take a look at #4313? it's already been approved by niemeyer and needs a second review and perhaps comments on the syntax
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<zyga> mborzecki: I'll do it next, looking at error in 4426
<mborzecki> thanks
<pstolowski> zyga, will review. is mvo off today?
<zyga> pstolowski: I don't think he is but perhaps he feels worse than yesterday and is just not around yet
<zyga> mborzecki: reviewing now
<mborzecki> btw. any ide what's the status of fedora 27 in spread?
<zyga> mborzecki: no, is it broken?
<mborzecki> zyga: see #4336, there's a comment from niemeyer about rawhide, and it has been addressed already
<mup> PR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
<pstolowski> zyga, reviewed 4315, mostly a few questions
<mborzecki> mvo: hey, feeling better today?
<zyga> pstolowski: thanks, I'll check soon
<mvo> mborzecki: hey, good morning! yeah, still a bit weak but better
<mvo> and good morning pstolowski  and zyga !
<pstolowski> hey mvo! how are you feeling today?
<zyga> welcome back mvo!
<kalikiana> mvo: o/
<mvo> hey kalikiana
 * mvo makes a cup of tea and starts looking at open PRs after that
<mup> PR snapd#4432 closed: cmd/snap,  tests/main/classic-confinement: fix snap-exec path when running under classic confinement <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4432>
<zyga> mborzecki: booted my arch system, wish we had the binary package for snapd :/
<mborzecki> zyga: pacaur and makepkg are your friends :)
<mup> PR snapd#4433 opened: interfaces: allow socket "shutdown" syscall in default profile <Created by mvo5> <https://github.com/snapcore/snapd/pull/4433>
<zyga> mborzecki: while that's probably very arch of it it's not very snapd of it :)
<zyga> mborzecki: I wish we could fix the package in the archive
<mborzecki> one more classic confinement tests that can be enabled on fedora now
<mup> PR snapd#4434 opened: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4434>
<zyga> mborzecki: hmm
<zyga> mborzecki: that test is special-ish
<zyga> mborzecki: think about what happens
<zyga> mborzecki: to really properly test that you need to use fedora base snap
<zyga> mborzecki: NAK unless you want to take it to the store and enable a pure binary built test (execution) on fedora
<zyga> mborzecki: sent more feedback in the PR
<mborzecki>  zyga: doesn't that apply to all distros?
<zyga> and small break
<zyga> mborzecki: tests don't build C programs (most of the time)
<zyga> see my feedback and let's talk here
<Chipaca> mvo: mborzecki: dunno if you saw my Q yesterday about #4394
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<mborzecki> zyga: i'm looking at the makefile, looks like it's a least pain path without involving the store
<pedronis> Chipaca: hi, did you see my asking for reviews yesterday? :)
<Chipaca> pedronis: i did not
<Chipaca> pedronis: 'appropriate creds'?
<pedronis> yes
<pedronis> and #4389 (which is small)
<mup> PR #4389: overlord/snapstate: override Snapstate.UserID in refresh if the installing user is gone <Created by pedronis> <https://github.com/snapcore/snapd/pull/4389>
<zyga> oooh
<zyga> shit
<zyga> ^H
<zyga> badbadbad
<pstolowski> zyga, ?
<zyga> one sec
<mvo> Chipaca: oh, yes, I saw and forgot, I open the pR now
<mvo> Chipaca: so that I don't forget again
<zyga> uff
<zyga> the bug is just in my branch
<zyga> fire over
<zyga> and now it should work :)
<mvo> zyga: heh
 * mvo hugs zyga 
<zyga> I fixed the base snap stale thing
<Chipaca> zyga: I love bugs that are only in your branches :-D
<mvo> zyga: neato!
 * kalikiana coffee break
<zyga> mvo: I was checking if I'm on classic on the inside of the mount ns :'-((
<zyga> woooooot
<zyga> pushed, I'll let travis deal with it now
<mborzecki> zyga: about that test, it tries very hard to make sure that the binary works with ld.so and libs from the core snap, not sure why it should not run on non-ubuntu (btw. it's already enabled for suse and debian)
<zyga> mborzecki: it should be only built on ubuntu and should run everywhere
<zyga> mborzecki: suse is a bug here, it's equally meaningless
<zyga> mborzecki: the point is that it must match the core snap, not the distro
<zyga> mborzecki: to illustrate that any distro with the core snap can run correctly built classic snaps
<zyga> pstolowski: updated 4315 and responded to your feedback, thanks
<pstolowski> zyga, thanks, looking
<mborzecki> zyga: ok, i'll try to rework the test to have the snap installed from the store, probably will need some help in the process :)
<zyga> mborzecki: thank you, I'll gladly help
<mup> PR snapd#4431 closed: snap: make `snap info invalid-snap` output more user friendly <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4431>
<mup> PR snapd#4435 opened: snap: do not leak internal network errors to the user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4435>
<zyga> mvo: +1
<mvo> zyga: heh, nice one!
<pedronis> Chipaca: thanks
<Son_Goku> mborzecki: yeah, no symlink is going into the real stuff
<Son_Goku> and the only way I'm accepting classic confinement for real is when you guys finally fix the /snap thing
<Son_Goku> so that /snap isn't the barrier to classic confinement
<zyga> Son_Goku: that's impossible
<Son_Goku> no it isn't
<zyga> Son_Goku: you know it, I know it
<Son_Goku> I've actually talked to niemeyer about it before
<Son_Goku> there is a way... it's just very difficult
<zyga> Son_Goku: such as?
<Son_Goku> I'd have to dig out old chat logs for that
<Son_Goku> which I don't have on hand atm
<zyga> Son_Goku: when you have a moment please share, I'm curiou
<Son_Goku> will do
 * Chipaca -> lunchmaking
<Chipaca> ogra_: ondra: are you both on holidays still?
<mborzecki> Son_Goku: https://github.com/snapcore/snapd/commit/563795fd8d628c64da4019aee3f5c6a845eb0fe7 might be worth cherry picking to Fedora package as it addresses an issue that broke running classic snaps (should the user do a /snap symlink first of course)
<Son_Goku> mborzecki won't work
<Son_Goku> re-exec is disabled in Fedora
<zyga> Son_Goku: that's unrelated
<mborzecki> Son_Goku: it's not related to reexec
<Son_Goku> oh snapexec
<zyga> Son_Goku: it's a correct bugfix
<mborzecki> we were using the icnorrect path to snap-exec
<Son_Goku> yeah, I'll cherry pick it
<ogra_> Chipaca, back tomorrow
<mborzecki> Son_Goku: great, thanks
<mup> PR snapd#4436 opened:  snap: do not leak internal errors on install/refresh etc  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4436>
<zyga> Son_Goku: I updated my f27 yesterday
<Son_Goku> it's not in 2.30 either, so I'll pull it when I rebase to 2.30
<zyga> Son_Goku: oddly it picked the updates in gnome-software but not in dnf? maybe I was still sleepy
<Son_Goku> try "dnf --refresh upgrade"
<zyga> Son_Goku: I'll try next time, it's up-to-date now
<Son_Goku> zyga, kalikiana: I just got DNF into OpenSUSE Leap 15.0
<zyga> Son_Goku: will it replace zypper?
<Son_Goku> no
<zyga> Son_Goku: what's the use case?
<Son_Goku> python3-dnf
<Son_Goku> for snapcraft
<zyga> aah
<Son_Goku> also, kiwi can produce images for Fedora/CentOS with it
<kalikiana> Son_Goku: woot, awesome
<Son_Goku> the goal here is to have a single backend for rpm stuff
<Son_Goku> and pretty much all distributions that aren't SUSE are gradually converging on DNF
<Son_Goku> SUSE has Zypper, which for all practical purposes works identically to DNF
<Son_Goku> since they use the same resolver
<mborzecki> fwiw, even yocto also integrated dnf some time ago
<Son_Goku> yeah
<Son_Goku> I helped out kanavin with that last year
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4337/files
<mup> PR #4337: cmd/snap: use snap-exec from core with a classic snap when reexecing <Created by mwhudson> <https://github.com/snapcore/snapd/pull/4337>
<zyga> mborzecki: ^_^ i forgot about this
<zyga> mborzecki: maybe you want to review it
<mborzecki> i've added a comment there
<zyga> ohh
<zyga> I have green :)
<zyga> everyone: please review this and let's have it in 2.31
<zyga> https://github.com/snapcore/snapd/pull/4329
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<mup> PR snapd#4315 closed:  cmd/snap-update-ns: add execWritableMimic <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4315>
<zyga> mvo: 2.29 and 2.30 milestones on GH have no due date and are open
<zyga> mvo: (thank you for opening 2.31)
<zyga> jdstrand: ^
<pedronis> given that 2.30 is stable now we can close 2.29
<zyga> I agree
<mborzecki> hmm i'm trying `snapcraft cleanbuild` with the test snap, but it fails both on arch (running from snaps) and on xenial (installed from repos)
<mborzecki> on arch it's trying to push an assert file to the container, looks like it's confused about the path where the assert file is, maybe something with snap mount dir being different than /snap
<mup> PR snapd#4437 opened: tests: add test that ensures we never parse versions as numbers <Created by mvo5> <https://github.com/snapcore/snapd/pull/4437>
<zyga> mborzecki: just build it manually
<zyga> mborzecki: upload to the store
<ondra> Chipaca no back working
<zyga> mborzecki: and share it with mvo
<ondra> Chipaca what's up?
<zyga> mborzecki: it's a special test IMO
<mborzecki> on xenial, the container is started, i see it gets updated, but then i get `Temporary failure resolving 'archive.ubuntu.com'` when trying to install gcc as build-package
<zyga> mborzecki: request: please use test-snapd- prefix
<Chipaca> ondra: https://forum.snapcraft.io/t/best-practice-for-reporting-ubuntu-core-system-kernel-issues/3382
<zyga> mborzecki: the dns issue you see is interesting and probably worth looking into, could be lxd specific, could be general /etc mess bug
<Chipaca> ondra: i thought maybe you had input there (otherwise ogra_ will get to it tomorrow i guess :-) )
<mborzecki> zyga: i added --debug to cleanbuld, it dropped me to the shell and i can apt-get install gcc just fine :/
<zyga> aha
<zyga> good then
<zyga> mborzecki: really just build it and push to the store
<ondra> Chipaca let me check
<ogra_> "rainbow" (in the bug) sounds wrong all over ...
<ogra_> would be somethig to verify ...
<ogra_> regarding the bug filing i think using "Snappy" for image issues is fine as a catch all project
<Chipaca> ogra_: agreed. now get out of here.
<ogra_> :)
<Chipaca> :-)
<mup> PR snapcraft#1842 opened: lxd: Change "Terminating" message to debug level <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1842>
<mborzecki> zyga: just to be sure, snapcraft register test-snapd-hello-classic && snapcraft push --release=edge test-snapd-hello-classic_*.snap ?
<zyga> mborzecki: looks right (I think)
<mborzecki> mvo: pushed it to the store, the name is test-snapd-hello-classic
<sergiusens> morning
<kalikiana> sergiusens: good morning!
<sergiusens> kalikiana hey, mind looking at what mborzecki is talking about?
<sergiusens> zyga I m not sure, but it would be nice to have an API to retrieve the snap-declaration/revision assertion from snapd :-)
<kalikiana> mborzecki: can you paste your log somewhere?
<mborzecki> kalikiana: https://paste.ubuntu.com/26312927/ snapcraft from snaps, trying cleanbuild on arch, lxd seems to work just fine
<kalikiana> mborzecki: I notice `error: open /var/lib/snapd/hostfs/` are you using the lxd snap from edge?
<pedronis> mvo: this is the PR IÂ mentioned: #4392
<mup> PR #4392: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392>
<kalikiana> mborzecki: the snap broke just before xmas
<zyga> sergiusens: I think you can already, via the snap known API
<zyga> sergiusens: or are you talking about getting them from the store for snaps snapd doesn't know about?
<mborzecki> kalikiana: https://paste.ubuntu.com/26312943/ and this is snapcraft on xenial, from packages, when i get dropped to debug shell i can successfuly install required packages, not sure why it's hitting a timeout there :/
<mvo> pedronis: thanks
<mborzecki> mvo: the PR with the snap is #4434
<mup> PR #4434: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4434>
<kalikiana> mborzecki: Broken DNS would be my guess. It seems to work and then fails later on. Did you do `lxd init`and go through the terminal UX to set up the network?
<zyga> kalikiana, mborzecki: look at /etc/nsswitch.conf please, see if it's fishy
<zyga> we could use a DNS-test-snap (spread test)
<zyga> that exercises glibc API and maybe systemd-specific new API
<mborzecki> kalikiana: cleanbuild --debug drops me to the shell in the container right?
<kalikiana> mborzecki: Yes
<sergiusens> zyga for snaps installed, kalikiana are you using that?
<mvo> mborzecki: please run "snapcraft release test-snapd-hello-classic 1 edge"
<mvo> mborzecki: and your snap should be availabe, then we need to transfer your snap
<mborzecki> kalikiana: when i'm dropped to the shell, i can install gcc just fine
<mborzecki> mvo: done
<kalikiana> sergiusens: zyga for locally installed snaps, we have code in snapcraft to get assertions via the snaps endpoint (https://github.com/snapcore/snapd/wiki/REST-API#get-v2snapsname) . If that's what you're looking for, checkout this code https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/lxd/_containerbuild.py#L236
<kalikiana> mborzecki: I can believe that. And unfortunately it doesn't contradict what I said
<kalikiana> that's what broken DNS does
<mvo> mborzecki: cool, now fire away, your test hopefully works now
<zyga> my keyboard seems to have issues when I do backups over wifi :/
<zyga> sergiusens: I mean whatever fuels "snap known", not sure what that is
<mborzecki> mvo: thx, started the test just now :)
<mborzecki> zyga: tried switching the wifi to 5ghz band?
<zyga> mborzecki: I am using it
<zyga> mborzecki: (ah, no)
<zyga> perhaps it's not
<kalikiana> mborzecki: You can also check `ifconfig` and `/etc/resolv.conf` if there's a proper IP and ns respectively
<zyga> my backup is to a "home" network that uses a mixture of 2.4 and 5
<mborzecki> kalikiana: fyi, it's also runnign in a vm :), so it's qemu -> xenial -> lxd in this case :)
<kalikiana> mborzecki: that's generally fine. I'd try `sudo dpkg-reconfigure lxd` suspecting you didn't configure it before
<kalikiana> in the xenial running in the vm
<kalikiana> mborzecki: I'm heading out for lunch now. If that doesn't do the trick I'll try to think of what else to debug there
<mborzecki> kalikiana: thanks, i've reconfigured lxd and trying a cleanbuild now
<mborzecki> kalikiana: seems to work now :) thanks again
<kalikiana> mborzecki: Sweet! Glad it worked!
 * kalikiana now trying to leave the house without being blown away by the wind
<mborzecki> still got some spread tests running, but i'm wrapping it up for today
<pedronis> mvo: seems we changed something about test-snapd-toosl release status, and now test snap-info failes
<pedronis> test-snapd-tools.channels.beta expected 'â', got '2.10      (7) 12kB -'
<pedronis> beta was closed and now it has a different release
<mvo> pedronis: uh, I can fix this
<mvo> pedronis: fixed, sorry for the trouble
<pedronis> mvo: is the new version needed for some work in progress?
<mvo> pedronis: yes for my latest PR but I can use a different snap or adjust the tests in my PR, I don't want to break the world with that
<pedronis> ok, thank you
<kalikiana> re
<elopio> good morning! :D
<kalikiana> hey elopio
<kalikiana> elopio: whilst preparing snapcraft#1842 I noticed we seem to have no way to test if log messages use the expected level (debug, info). might be nice to consider what we could do about it in the future
<mup> PR snapcraft#1842: lxd: Change "Terminating" message to debug level <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1842>
<elopio> kalikiana: yeah, we have pending a complete redesign of logs, info messages and errors. Currently we have a mix of prints, logs and exceptions
<kalikiana> elopio: I'm referring to existing uses of `logger`. There's no way to test that they use the correct level
<kyrofa> kalikiana, you can make a fake logger that grabs a specific level
<kalikiana> kyrofa: Hmmm do we have an example of this?
<kyrofa> Yeah let me find one
<kalikiana> Thanks!
<kyrofa> kalikiana, look at test_yaml_missing_confinement_must_log in unit/project_loader/test_config.py
<kyrofa> It's the FakeLogger fixture. It grabs whatever logging level you define as well as more critical levels
<kyrofa> Perhaps that latter point makes it less useful for your case, I'm not sure
<kalikiana> kyrofa: Hm... I think I need sort of the opposite. Assuming info would be 'more critical' I'd get the message, whether it's info or debug
<kyrofa> kalikiana, are you trying to verify a message is debug, or info?
<kalikiana> kyrofa: I'm changing the message from info to debug. I'd like to verify it's debug only.
<kyrofa> kalikiana, you can change the log format in that fixture to include the log level
<kyrofa> Kinda hacky, but then you could match the log level
<kalikiana> Hmmm I'll give that a go. Thanks!
<mup> PR snapcraft#1843 opened: elf: warn if primed files will not work with the base's linker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1843>
<sergiusens> kyrofa elopio ^
 * sergiusens is not a fan of checking for existence or lack of messages logged in tests
<kalikiana> sergiusens: kyrofa: elopio This is what I came up with https://github.com/snapcore/snapcraft/pull/1842/commits/535cefbabbdb69481a4a6cc73ed3998e551d1f82 I'm not checking existence here, but rather that the level is correct
<mup> PR snapcraft#1842: lxd: Change "Terminating" message to debug level <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1842>
<elopio> sergiusens: checking...
<elopio> kalikiana: I don't think that test is really necessary, mainly because as I said, we need to rethink our logger. I'm happy with tests that set the fake logger to debug, and check if the debug message is there
<elopio> even if that will miss the specific level of the message. But your test looks correct too, I don't see a problem to land it.
<kalikiana> elopio: A test that checks if the message is there won't fail without my change
<elopio> I know, I'm saying I don't mind that that line is not fully covered. But it's ok if you care about it, of course.
<mup> PR snapcraft#1832 closed: cmake plugin: update plugin details <codein> <Created by konrad11901> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1832>
<kalikiana> sergiusens: FYI I was certain there was a bug for this but couldn't find it... so I filed a new one in any case https://bugs.launchpad.net/snapcraft/+bug/1741082 This is for the permission issues with staged packages in conjunction with sshfs
<mup> Bug #1741082: sshfs breaks with serving user files to root in LXD <Snapcraft:Confirmed for kalikiana> <https://launchpad.net/bugs/1741082>
<kalikiana> elopio: I can also back it out and we plan for a better solution. This was a pretty quick hack anyway. I just feel a bit... uneasy committing untested code
<elopio> +1
 * kalikiana wrapping up for the day shortly - will have to push the sshfs PR in the morning since the tests aren't ready
<mup> PR snapcraft#1844 opened: Included fix for error messages <Created by Tanesh1701> <https://github.com/snapcore/snapcraft/pull/1844>
<sparkiegeek> hi snappy-devs! I'm a bit green when it comes to Golang coding, but am trying to just run the tests before making any changes and am hitting https://paste.ubuntu.com/26313885/
<sparkiegeek> any clues?
<Chipaca> sparkiegeek: your vet is newer or older than ours :-)
<sparkiegeek> Chipaca: â« go version
<sparkiegeek> go version go1.8.3 linux/amd64
<sparkiegeek> Chipaca: which one do I want?
<Chipaca> sparkiegeek: actually, i just checked and 1.6 and 1.9 are both happy with that file
<pedronis> Chipaca: it's interesting though that afaict Plug and Slot don't have a String
<pedronis> so that might be ok but not ideal
<pedronis> maybe pstolowski should look at that
<mup> PR snapd#4438 opened:  snap: add new `snap advice-command` skeleton <Created by mvo5> <https://github.com/snapcore/snapd/pull/4438>
<sparkiegeek> ok, so in the meantime... should I just ignore it? or should i use a different go version?
<sparkiegeek> I can't see anything in HACKING.md about what the supported Go version is
<mvo> sparkiegeek: just ignore the bet errors while we investigate, just run ./run-checks --unit in the meantime
<mvo> sparkiegeek: we support *all* (kidding, we should add go1.6+)
<mvo> sparkiegeek: a PR with the fix for the HACKING.md would be welcome :-D go1.6+ is what we support
<pstolowski> sparkiegeek, pedronis, will fix the code
<pedronis> Chipaca: afaict %s doesn't produce anything sane with a struct without String that doesn't have all fields that are strings
<pstolowski> although
<pstolowski> PlugInfo and SlotInfo do have String()
<sparkiegeek> mvo: on it
<zyga> re
 * zyga is more awake now, sorry for being absent earlier
<pstolowski> ah, it's Plug/Slot
<zyga> I was writing (but not code)
<zyga> about sanpd
<zyga> snapd
<mvo> sparkiegeek: \o/
<pedronis> Chipaca: otoh golang.org at the moment doesn't let me share my example
<pedronis> :/
<sparkiegeek> mvo: https://github.com/snapcore/snapd/pull/4439
<mup> PR #4439: Add documentation for supported Go versions <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/4439>
<pstolowski> pedronis, is it possible vet got confused? i'm looking at these lines and they are dealing with PlugInfo and SlotInfo (and these have String()), not interfaces.Plug/Slot as indicated by vet
<mup> PR snapd#4439 opened: Add documentation for supported Go versions <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/4439>
<pedronis> pstolowski: ah
<pedronis> interesting or sparkiegeek doesn't have master ??
<pstolowski> or that...
<zyga> pstolowski: I looked at that once and it looks like vet bug
<zyga> pstolowski: it's meaningless (the error)
<sparkiegeek> I'm running 55648cb8358825a18c6f926c38416703b48edd1f afaics
<sparkiegeek> but I'd definitely suspect PEBKAC if it's not reproducible? I'm just using Go from Artful
<pstolowski> sparkiegeek, ok, that's the latest
<pstolowski> sparkiegeek, looks more like a vet bug as zyga says. the error mentions wrong type, it's not the one used in the code
<sparkiegeek> pstolowski: I mean, I might well have screwed things up, I find myself battling $GOPATH quite often :)
<mup> PR snapd#4426 closed: snap: print friendly message if `snap keys` is empty <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4426>
<mup> PR snapd#4433 closed: interfaces: allow socket "shutdown" syscall in default profile <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4433>
<sparkiegeek> weird, now I've made my changes I don't get the vet complaint :/
<sparkiegeek> of course, now I have a newer version of shellcheck complaining about other things!
<mborzecki> iirc vet (and some other static analysis tools) may depend on whether the package archive files (*.a) are up to date with the code
<sparkiegeek> mborzecki: ah, that might explain it. Last time I built snapd was many months ago
<pmatulis> 'snap search' outputs a short list of snaps. why?
<zyga> pmatulis: those are 'curated chices' to show some snaps, akin to "browse the store"
<zyga> pmatulis: just very early version of that concept
<mvo> pmatulis: quite a few people are confused by this, we have https://github.com/snapcore/snapd/pull/4382 to help with that
<mup> PR #4382: snap: show header/footer when `snap find` is used without arguments <Created by mvo5> <https://github.com/snapcore/snapd/pull/4382>
<sparkiegeek> right see #1700560
<mup> Bug #1700560: âsnap findâ returns confusing results <Snappy:In Progress> <Snap Store:Invalid> <https://launchpad.net/bugs/1700560>
<mborzecki> sparkiegeek: more info about vet - https://github.com/golang/go/issues/20514 and https://github.com/golang/go/issues/16086
<mup> PR snapcraft#1845 opened: cli: implement help <command> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1845>
<sergiusens> elopio kyrofa ^
<mvo> pedronis: you have a review for the private refresh PR, I love the level of testing, great work!
<pmatulis> zyga, thanks. it's true that it's incredibly confusing. it can lead people to believe those are the *only* snaps available
<sparkiegeek> sergiusens: ð @ snapcraft help <command>
<mvo> pmatulis: *cough* thanks for the feedback, we aim the fix for 2.31
<mvo> s/aim/target/
<sergiusens> sparkiegeek oh yeah
<sparkiegeek> sergiusens: best Xmas ð yet :)
<noise][> sergiusens: what's the timeline for next stable release?
<sergiusens> elopio fixed
<sergiusens> noise][ as a snap, during CPT; as a deb, I'll need to do some bribing to avoid backporting new dependencies
<noise][> sergiusens: cool, i'm just eager to get the metadata editing stuff out the door, thanks!
<sergiusens> noise][ it sort of is already, most of are users are running from `edge`
<noise][> ~ 1/4-ish from stats
<sergiusens> ooh, they have changed. I'll need to take a look again
<sergiusens> noise][ so, elopio will be doing sanity checking of what is in beta and with that data we will have early data to promote to stable. These numbers make me want to have the current beta (2.38) in candidate sooner to have it go to stable even
<elopio> sergiusens: you didn't update the docstring.
<sergiusens> oh
<sergiusens> elopio done now
<pedronis> mvo: thanks, will look in my morning
<mup> PR snapd#4389 closed: overlord/snapstate: override Snapstate.UserID in refresh if the installing user is gone <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4389>
<mup> PR snapd#4337 closed: cmd/snap: use snap-exec from core with a classic snap when reexecing <Created by mwhudson> <Closed by mwhudson> <https://github.com/snapcore/snapd/pull/4337>
 * zyga waves at mwhudson 
<mwhudson> zyga: morning
<sergiusens> kyrofa pushed fixes
<mup> PR snapcraft#1840 closed: docker: instructions to build from the snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1840>
<pmatulis> mvo, ty
<mup> Issue snapcraft#1699 closed: snapcraft <help> command <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1699>
<mup> PR snapcraft#1845 closed: cli: implement help <command> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1845>
<mup> Issue snapcraft#1700 closed: snapcraft help <plugin>|<sources> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1700>
#snappy 2018-01-04
<mup> Issue snapcraft#1667 closed: Walk the prime directory for elf files and flag the glibc required version <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1667>
<mup> PR snapcraft#1843 closed: elf: warn if primed files will not work with the base's linker <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1843>
<lohroc> I installed the Brave browser using snapcraft but it changes my mouse cursor while its over it.
<lohroc> How do I keep the system cursor over it?
<Chipaca> lohroc: we're working on that still
<mborzecki> morning
<zyga> mborzecki: bad morning
<zyga> mborzecki: look at lwn and everywhere
<mborzecki> zyga: hey
<mborzecki> yeah, and we're not even past the blue monday
<mborzecki> btw. must be especially hard if you're a verification engineer at intel
<zyga> mborzecki: I think they can use speculative execution to live as if nothing had happened ;-)
<mborzecki> zyga: meanwhile, did you manage to go through #4313 by any chance? :)
<mup> PR #4313: timeutil: refresh timer take 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4313>
<zyga> mborzecki: not all of it, as I said yesterday I didn't sleep well and coundn't focus on reviews with meaningful results
<zyga> mborzecki: I'll sort out children & school and get back to it
<mborzecki> sure, no rush :) thanks for looking at it
<zyga> allright
<zyga> coffee and small school run, to pay for food, and I'll be back
<zyga> today I will sleep (slightly) better knowing that my destkop is an AMD machine
<mborzecki> zyga: nice technical writeup if you haven't read it yet: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
<zyga> mborzecki: thanks, very interesting and very scary
<jamesh> zyga: not all the vulnerabilities are Intel-only
<kalikiana> snappy good morning
 * kalikiana coffee
<zyga> jamesh: yes, I know that
<zyga> jamesh: but the low hanging fruit will go after intel first
<zyga> jamesh: spectre is fully generic
<jamesh> zyga: picking up from last year, what's the best way forward with the user mounts feature?
<zyga> jamesh: I need to review that, I don't rememer; I think it was green on tests and you addressed prior feedback
<zyga> jamesh: I'll collect my thoughts and respond today on the PR
<jamesh> zyga: it passed CI, yeah.  There was some discussion on the forum, but it died out as we hit the holidays.  It wasn't clear which things were "must be implemented before merge" and what was "should be implemented eventually"
<jamesh> zyga: I think this thread came up after you finished up last year too: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 -- it will probably have some impact on mount namespace construction should we adopt it
<mup> PR snapd#4439 closed: Add documentation for supported Go versions <Created by sparkiegeek> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4439>
<mborzecki> mvo: morning
<mvo> hey mborzecki - good monring
<mvo> mborzecki: feel free to releease test-snapd-classic anywhere you neeed it (re your question in the PR)
<mborzecki> mvo: great :) can you also approve the i386 snap?
<mvo> sure
<mvo> mborzecki: its there for you
<mborzecki> thanks
<mborzecki> hmm funny output from snapcraft, snap version seems to be printed as string or a number? https://paste.ubuntu.com/26318133/
<mvo> mborzecki: yeah, there is a bug about this in LP, let me check
<mvo> mborzecki: 1669291 where it behaves similarly
<mvo> mborzecki: you can workaround via `version: "1.0"`
<mborzecki> mvo: right, that's your PR with the test as well #4437
<mup> PR #4437: tests: add test that ensures we never parse versions as numbers <Created by mvo5> <https://github.com/snapcore/snapd/pull/4437>
<mup> PR snapcraft#1846 opened: Add files via upload <Created by Nissaar> <https://github.com/snapcore/snapcraft/pull/1846>
 * kalikiana coffee break
<jamesh> zyga: one other question: a while back you said you might be looking at implementing the content interface improvements (allowing multiple snaps to share content to one snap).  Was any progress made on that?
<zyga> jamesh: that is mostly ready and waiting for prerequsite to land, https://github.com/snapcore/snapd/pull/4068
<mup> PR #4068: interfaces/builtin: add support for content "source" section <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4068>
 * jamesh looks
<zyga> jamesh: yesterday I merged the code for writable mimic and it should unblock this PR later today, I have one more integration PR to land
<jamesh> zyga: awesome.  People were asking about theme support, so it'll be good to have something to build on top of
<zyga> I see there are two minor conflicts there but that's really not a problem
 * zyga needs more coffee, not sure if weather or something else but I feel like sleeping today :/
<kalikiana> zyga: yeah, felt oddly sleepy this morning as well, and it's raining lions and wolves to no end
<zyga> kalikiana: I actually woke up at 6:30 but then took a nap :/
<zyga> I'm terrible today
<kalikiana> naps are awesome. big benefit of working from your house that you can do that easily
<Chipaca> zyga: you misspelled "awesome"
<zyga> that's one awesome typo ;-)
<zyga> but while I'm terrible the world is more terrible so that's ok
<Chipaca> mvo: one problem i'm bumping into to easily use your approach at making things testable is that the database needs opening, and closing, around the searches
<Chipaca> mvo: i.e. we probably shouldn't hold it open for the duration (but we could, with the argument that 'snap advise' is short lived)
<mvo> Chipaca: I see, we can add open/close to the interface
<Chipaca> mvo: well... open is weird because it's usually a constructor, not part of the interface
<Chipaca> but if it makes things easier i could do that
<Chipaca> mvo: seems more natural to make ReplaceCommandsFinder(constructor) instead
<mvo> Chipaca: yeah, fine with me
 * Chipaca runs with it
<Chipaca> and, yes, adding Close() to Finder
<mvo> Chipaca: fwiw, there is a deb package for github-boltdb-bolt already so maybe we use that as the starting point (not the fork from coreos)
<Chipaca> mvo: can we rename the command to 'advise' instead of 'advice'?
<Chipaca> mvo: the former is a verb, the latter is a noun
<mvo> Chipaca: sure
<Chipaca> mvo: i'm not using the fork, fwiw
<mvo> Chipaca: cool
<Chipaca> mvo: on the grounds that it's unclear which one we want, but it's easier to move downfork than upfork in this case
 * mvo nod
<mup> PR snapd#4440 opened: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
 * sergiusens waves
 * sparkiegeek particles
<sergiusens> going to be starting a little later today though as I am home alone with my son who is just waking up
<sergiusens> sparkiegeek it was to early to make sense of that on the first read :-P
<sergiusens> duality ftw :-)
<sparkiegeek> sergiusens: just having to let off steam after seeing Meltdown/Spectre and the ensuing world burning
<kalikiana> sergiusens: o/
<pedronis> mvo:  I updated  #4392 , in some cases with test comments instead of code changes
<mup> PR #4392: many: refresh with appropriate creds <Created by pedronis> <https://github.com/snapcore/snapd/pull/4392>
<mvo> pedronis: thank you, I have a look. comments are fine of course
<mvo> pstolowski: do we have plans for making daemon starts options via some hook? context is lp 1664163
<ogra_> sergiusens, could we land the patch from Bug #1740882 soon into the edge snap ?
<mup> Bug #1740882: Missing initrd.img-core in os.snap <Snapcraft:New> <https://launchpad.net/bugs/1740882>
<pstolowski> mvo, it's already possible to stop/start services from hooks via snapctl start/stop, but of course the fact that they start automatically on install is an issue
<pstolowski> mvo, and yes, maybe we need a dedicated hook for start-services as now it's either install hook or refresh hook, not convienient
<mvo> pstolowski: sounds like we need to turn it into a feature request
<zyga> mborzecki: man you have a lot of types in that PR
<mborzecki> zyga: which one?
<zyga> mborzecki: the 1K one
<zyga> 4313
<mborzecki> right, it grew a 'bit'
<mup> PR snapd#4441 opened: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441>
<zyga> mborzecki: added one more comment, as my understanding of what the schedule is
<zyga> mborzecki: if it's inaccurate please comment
<zyga> (on it ;)
<Chipaca> to add a package to govendor, am i supposed to edit vendor.json directly?
<zyga> Chipaca: no
<zyga> Chipaca: I think you want to use the CLI to vendor one more entry
<zyga> Chipaca: otherwise vendor will likely rewrite your change and introduce an ever-conflicting change
<Chipaca> zyga: how do you do that?
<zyga> Chipaca: go get something and then govendor add
<Chipaca> zyga: 'govendor get thing...?'
<zyga> Chipaca: govendor --help has (to long) help
<pedronis> Chipaca: govendor fetch
<pedronis> see govendor fetch --help
<zyga> mborzecki: for readability I would perhaps reorder the stuff in schedule.go to have all the types first, followed by all the function
<zyga> *functions
<Chipaca> pedronis: thanks, that worked
<Chipaca> govendor fetch +missing
<Chipaca> this works despite 'govendor list +missing' getting confused with a 'context' package
<mborzecki> zyga: tried to keep the <type, type-methods, type .., parser-functions> order throught the file, it does take a bit of back and forth when reviewing though, that i agree with
<mborzecki> zyga: while you're doing review, can you a quick 2nd pass on #4434 ?
<mup> PR #4434: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4434>
<zyga> mborzecki: yep
<mborzecki> thanks
<zyga> mborzecki: approved
<mborzecki> zyga: great, thanks
 * kalikiana looking forward to lunch in a few minutes
<Chipaca> mvo: https://github.com/mvo5/snappy/compare/snap-advice-command...chipaca:commands-catalog
<Chipaca> mvo: piggyback material, or its own PR?
<mvo> Chipaca: looking
<mvo> Chipaca: own PR is my gut feeling, happy to review
<mvo> Chipaca: misspelling mispelling is ironic
<Chipaca> mvo: remember mod_speling?
<mvo> heh
<mup> PR snapcraft#1847 opened: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
<Chipaca> mvo: #4442
<mup> PR #4442: many: implement the advisor backend, populate it from the store <Created by chipaca> <https://github.com/snapcore/snapd/pull/4442>
<Chipaca> maybe i should close it and open it again when it's #4444 :-D
<mup> PR snapd#4442 opened: many: implement the advisor backend, populate it from the store <Created by chipaca> <https://github.com/snapcore/snapd/pull/4442>
<ogra_> cyphermox, mind taking a look at https://forum.snapcraft.io/t/standard-for-bootstrapping-network-on-raspberry-pi-and-similar-devices/3137 ? (we're wonderign how complex of a wpa-supplicant-only config you can have with plain netplan without NM installed on core)
<sergiusens> ogra_ there's a PR with failing tests from ppisati
<ogra_> sergiusens, damn
<ogra_> i'm really not eager to fiddle with a local build to be able to roll a kernel snap :/
<ogra_> but i guess that is what it boils down to then
<sergiusens> ogra_ or revert the breakage in the core snap ;-)
<ogra_> sergiusens, and get mvo grumpy at me at the 4th day of the year already ? naaaah
<ogra_> sergiusens, happy new year btw :)
<mvo> sergiusens, ogra_ reverting is not a bad idea actually, maybe not reverting but doing the symlink the other way around?
<ogra_> mvo, sounds fine too
<ogra_> eventually we want the one in /boot completely gone anyway and just use the other one
<mup> PR snapcraft#1848 opened: Fixes for Errors <Created by Tanesh1701> <https://github.com/snapcore/snapcraft/pull/1848>
<ogra_> (with split initrd)
<mborzecki> off to pick up the kids
<sergiusens> zyga are snap relocations a thing already?
<sergiusens> zyga I could really use it so I don't depend on the snap name for the path :-)
<sergiusens> ogra_ I cannot wait for split initrd, it has been 3 years since we said it should be done ;-)
<ogra_> sergiusens, i was nearly done and then changed teams ... now i'm busy with customers :/
<ogra_> it *will* happen though :)
<ogra_> (needs snapd changes )
<ogra_> jdstrand, bah, you are to fast ... i wanted to talk to you about usbmon after my meeting in 1h :P
<ogra_> err ... usbtop
<zyga> sergiusens: what are snap relocations?
<ogra_> zyga, snaps that move from barcelona to warsaw :)
<zyga> ogra_: hahaha
<zyga> ogra_: with children proceses
<ogra_> (happy new year)
<ogra_> indeed !
<zyga> ogra_: thank you, happy new year :)
 * zyga wrote a new thing http://fyke.local:1313/post/core-snap-refresh-and-your-app/
<ogra_> thx
<zyga> and should write code but writing text is easier today
<zyga> and I'm not feeling like tryin 5th coffee to feel awake
<ogra_> zyga, my desktop has a really hard time to resolve fyke.local ;)
<zyga> oh
<zyga> shit
<zyga> https://new.zygoon.pl/post/core-snap-refresh-and-your-app/
<zyga> I'm obviously not in my good working order today
<ogra_> well... it is early in the year :)
<kalikiana> re
<zyga> ogra_: with the trend I will die before the month is over ;-)
<ogra_> lol
<sergiusens> zyga if that is true, does that blog post require any proof reading?
<zyga> sergiusens: please, I'm always happy to accept correction
<zyga> s
<zyga> (see)
<zyga> sergiusens: there are more posts from the last two days if you want to see those too
<mup> PR snapd#4437 closed: tests: add test that ensures we never parse versions as numbers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4437>
<Chipaca> zyga: âit is still fundamental you pretty much every snap application out there.â
<zyga> Chipaca: ah, thanks, bad edit
<mup> PR core#67 opened: initramfs-tools: revert the symlinks generation to unbreak snapcrafts kernel plugin <Created by mvo5> <https://github.com/snapcore/core/pull/67>
<mvo> sergiusens: do you happen to know from what channel the snapcraft kernel plugin pulls?
<sergiusens> mvo I can check
<sergiusens> mvo stable... it used to be edge
<ogra_> yeah, sadly that means it wont speed up anything to fix it in core
<mvo> sergiusens, ogra_ hm, so we need a new stable core with the fix or an update to snapcraft to unbreak people?
<ogra_> right
<ogra_> https://launchpadlibrarian.net/352266605/0001-kernel-plugin-update-initrd.img-core-path-to-root-bo.patch
<ogra_> its  a one liner for snapcraft
<ogra_> but apparently some tests fail for the actual PR
<sergiusens> ogra_ just fix the tests in the PR ;-)
<ogra_> well, i need a kernel snap from some customer tree, atm i'm just reverting to the snapcraft deb and hack the one liner into it :P
<sergiusens> ogra_ I can look at it later today, but that's what I have been telling everyone lately and not getting to it ;-)
<sergiusens> ogra_ you can also just copy the kernel plugin to your snap and make the change there
<ogra_> sure ... but i'm lazy :P
<sergiusens> ogra_ then it keeps working for buildd
<mvo> sergiusens: it looks like ppisati already updated the unit tests, tests are running
<zyga> mborzecki: still here?
<mborzecki> zyga: yeah, what's up?
<zyga> mborzecki: I added some more comments
<zyga> mborzecki: the code is +1, I was just trying to help others that look at it without rich context
<zyga> mborzecki: not sure if you want me to +1 and let you consider any of the comments or rather wait
<mborzecki> zyga: you can go ahead and +1 :)
<mborzecki> my plan is to fix the format in the clockspan line and add the contst for LastWeek/EveryWeek
<zyga> mborzecki: thanks! I just found that cleaner
<mborzecki> zyga: btw. are you taking a day off tomorrow?
<Chipaca> zyga: https://forum.snapcraft.io/t/hello-world-snap-gives-cannot-bind-mount-the-mount-namespace-file-on-debian-testing/3410 says hi
<zyga> mborzecki: no,
<zyga> Chipaca: looking
<Chipaca> zyga: :-)
 * Chipaca feels he should be typing in all-caps because the wind is very loud atm
<mborzecki> zyga: me neither, i'll probably take it on some other date
<mborzecki> tomorrow's a bit unexpected
<zyga> hmm, what's tomorrow?
<pstolowski> zyga, it's for the holiday on jan 6th
<zyga> aah
<pstolowski> just learned this too ;)
<zyga> well
<zyga> no, I'll work, i need to finish stuff and I'm very slow :/
<mup> PR snapcraft#1848 closed: Fixes for Errors <Created by Tanesh1701> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1848>
<Chipaca> mvo: who should we hug harder to update snapd in debian?
<pedronis> Chipaca: maybe, though is probably worth waiting for 2.31
<pedronis> for that
<mvo> Chipaca: probably mwhudson
<mvo> Chipaca: but yeah, maybe 2.31 - maybe
<zyga> pedronis: in sid we can just keep on updating, no need to wait
<mvo> there will be good stuff in it
<zyga> and incrementals are easier (less dep churn)
<pedronis> zyga: from a less work pov
<pedronis> IÂ mean we definitely want some fixes coming with 2.31
<zyga> pedronis: not clear if less if there are deps it's the same amount, it's just a version bump
<mborzecki> pstolowski: would you mind taking a look at #4373 once more?
<mup> PR #4373: snap: app startup after/before validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4373>
<pstolowski> mborzecki, sure
<mborzecki> pstolowski: thanks
<oSoMoN> jdstrand, hey, I have renamed the âplay0adâ snap to â0adâ, and the process-control interface was automatically being connected for play0ad (required to make the game run with strict confinement), I'm wondering if that privilege can be transferred to 0ad?
<oSoMoN> or do I need to start a new thread on the forum to do the request again?
<mup> PR snapd#4438 closed:  snap: add new `snap advice-command` skeleton <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4438>
<kenvandine> mvo, any chance of getting your xdg-settings PR merged soon?  PR #4073
<mup> PR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
 * kalikiana wrapping up for today
<jdstrand> oSoMoN: nah. I'll just do it
<behalebabo> Making my first snap for a SDL2/OpenGL based game, atm all is working except audio. When in strict confinement, audio does not work and I receive the relevant errors: https://paste.ubuntu.com/26320346/ Adding browser-support to plugs or connecting process-control does work, but are these really necessary for a game?
<behalebabo> that's snapd 2.29.4.2 on ubuntu 16.04
<zyga> behalebabo: hey
<zyga> that will go away (as a necessity) with some upcoming work on EPERM from seccomp filters, this is not finished though
<oSoMoN> jdstrand, thanks
<behalebabo> zyga: alright, what do you recommend I use in the meanwhile?
<jdstrand> oSoMoN: done
<zyga> behalebabo: I don't know honestly, ideally we could get rid of setpriority call but that may not be trivially easy
<zyga> maybe we can use a preload trick to make that a no-op
<oSoMoN> thanks jdstrand
<oSoMoN> just in time for me to call it a day :)
<jdstrand> behalebabo: for now, use process-control and follow this https://github.com/snapcore/snapd/pull/3998
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<jdstrand> behalebabo: or adjust your snap to comment out setpriority
<sborovkov> Hi, why does snapcraft return non zero exit code when uploaded snap requires manual review?
<sborovkov> can I make it ignore this?
<mvo> Chipaca: quick brainstorm about bug #1665787 - this is about "snap install snap-with-no-revision-in-stable" shows a generic "not-found" instead of providing something more useful. right now the store does not give us any context, so to fix this after each 404 we would have to do another round-trip to the store and query with `channel=""` (any) or we need store support. how do you feel about this? do you think the extra roundtrip is worth it?
<mup> Bug #1665787: snap install with correct name and wrong channel gives misleading error <snapd:Triaged> <https://launchpad.net/bugs/1665787>
<Chipaca> mvo: are you sure the error message is the same, from the store?
<mvo> Chipaca: I think so, I did https://paste.ubuntu.com/26320508/
<Chipaca> mvo: i seem to recall it being subtly different
<mvo> Chipaca: oh, maybe too subtle for me, let me check
<mvo> Chipaca: that would be great if so
<Chipaca> mvo: yeah, the *message* is different
<mvo> Chipaca: indeed, the "message" is different
<Chipaca> which is rather brittle, but maybe enough until it's done properly
<mvo> Chipaca: not sure if we can/should rely on this :/
<mvo> Chipaca: yeah, I can add a store task to make this less brittle and run with it for now
<Chipaca> (i mean: as i understand, we want to be told "this snap exists in stable on armhf, or in beta on amd64" or somesuch)
<mvo> Chipaca: maybe, having a reliable way to just tell the user "try snap info <snap>" is already a big win
<Chipaca> mvo: note the 'this context' includes architecture, so if you were only going to check channels it might be wrong
<mvo> Chipaca: vs "not found"
<mvo> Chipaca: autsch, ok
<Chipaca> at least, i think it does
 * Chipaca checks
<Chipaca> mvo: yes, it includes arch
<Chipaca> mvo: that is, there's no way to tell if it means 'other arch' or 'other channel'
<Chipaca> mvo: however, if it doesn't say "in the given context", you know it's really not there
<mvo> Chipaca: hm, I think that is unfortunate
 * zyga -> tea
<pedronis> the store doesn't know either, it would need to do the equivalent of some other queries as well
<mup> PR snapcraft#1849 opened: tests: add snap not found tests <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1849>
<mup> PR snapd#4443 opened: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/4443>
<kyrofa> elopio, I finally realized what you were talking about regarding needing to allow community contributions for CC on youtube
<elopio> kyrofa: but I hate it, I want to move those contributions to github.
<kyrofa> elopio, we can do that by having a repo for timing files
<kyrofa> And then upload them ourselves
<kyrofa> Have you ever made one of those?
<elopio> kyrofa: working on that: https://github.com/elopio/snapcraft-videos
<kyrofa> Great minds apparently
<elopio> that's why I asked for your transcripts.
<kyrofa> elopio, how would you like me to get those to you?
<kyrofa> I have the latest one prepped
<elopio> kyrofa: you can make a pull request, or send them to my email.
<elopio> I have a big list of things pending to put in the repo, so both are fine.
<kyrofa> elopio, is the description.txt the script?
<kyrofa> Oh, I see script.txt in a few
<kyrofa> elopio, can I get some guidance on what these various files are?
<elopio> kyrofa: the idea is to have a readme per video, linking to a file with the description, a file with the script and a file with the english subtitiles
<elopio> then, translations will be added as new files with the language suffix on the subtitle file name
<elopio> the main readme is an index to all the videos.
<kyrofa> Okay very good
<kyrofa> Keep an eye out for PRs
<elopio> I'm still playing with the format, and maybe, we can integrate with transifex
<elopio> so if you want to move things around, go for it. It's still an early experiment
<mup> PR # closed: snapcraft#1814, snapcraft#1820, snapcraft#1824, snapcraft#1841
<mwhudson> mvo: i was sort of holding off snapd in debian because of that apparmor ptrace mess
<mwhudson> did that get resolved in the end?
<zyga> mwhudson: o/
<mwhudson> zyga: yo
<zyga> I don't know about that but I think just shipping more updates would help, our testing shows that 2.30 and master are pretty usable on sid
<mwhudson> ok
<mwhudson> tip of the branch on alioth has some updates that haven't been uploaded
<mwhudson> to 2.29.4.1 or something
<zyga> perhaps worth trying, also not sure if it's complex to go to .30
<mwhudson> well it merges cleanly
<mwhudson> where is the best place to get origs from for snapd?
<mwhudson> from github?
<zyga> yes, github release pages
<mwhudson> oh look there is a watch file already
 * mwhudson hits uscan with a stick until it does what he wants
<mwhudson> ok building
<mwhudson> zyga: dh_install: Cannot find (any matches for) "lib/udev/rules.d/80-snappy-assign.rules" (tried in ., debian/tmp)
<mwhudson> zyga: has that just gone away?
<jdstrand> that's weird
<jdstrand> https://github.com/snapcore/snapd/pull/4399 makes that go away, but it isn't merged yet
<mup> PR #4399: rewrite snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
 * jdstrand also updated the packaging for that
<mwhudson> er
<jdstrand> (but again, in the pr)
<mwhudson> well this is debian packaging with is still out of tree
<jdstrand> mwhudson: put more simply, that file should be there
<mwhudson> jdstrand: does that file get created as part of the build?
<mwhudson> it's not in the source tree nor has it ever been afaict
<jdstrand> I'm trying to figure that out
<jdstrand> $ dpkg -S /lib/udev/rules.d/80-snappy-assign.rules
<jdstrand> snapd: /lib/udev/rules.d/80-snappy-assign.rules
 * jdstrand looks in packaging
<jdstrand> my memory is hazy. I seem to have removed it
<jdstrand> mwhudson: gimme a sec
<jdstrand> ah right
<jdstrand> mwhudson: https://github.com/snapcore/snapd/pull/4374
<mup> PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4374>
<mwhudson> oh it was in cmd/snapd-confine not data/lib/udev/rules.d
<jdstrand> mwhudson: I was thinking I removed that file in 4399 and forgot about 4374
<mwhudson> oh ok so just drop it from the .install?
<jdstrand> mwhudson: so that file is now correctly gone
<jdstrand> mwhudson: so for the momentary confusion
<jdstrand> sorry*
<mwhudson> no problem :)
<mwhudson> bah the 'g' key on my keyboard is broken
 * mwhudson switches everything back to bzr
<jdstrand> haha
<mwhudson> or alias it='git' i guess
<jdstrand> lol
<jdstrand> I sure that'll work great for you
<mwhudson> building again
<kyrofa> Alright elopio, you have your first PR
<mwhudson> built successfully
<mwhudson> zyga: should i test this or just upload it and let sid be sid? :)
<kyrofa> cjwatson, my repo setup with build.snapcraft.io hasn't built the most recent commit that I made several hours ago (the most recent build was yesterday). Hitting the "build manually" button does nothing
<kyrofa> Any ideas?
<cjwatson> kyrofa: https://twitter.com/launchpadstatus/status/948688233029881856
<kyrofa> Ah :)
 * mwhudson uploads
<sergiusens> kyrofa elopio have either of you had a chance to look at kalikiana's PRs?
<kyrofa> Not yet, I will
<kyrofa> sergiusens, can you take a look at my responses to snapcraft#1831? I don't have clear guidance on what you want done there
<mup> PR snapcraft#1831: cli: add expiration option to export-login <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1831>
<sergiusens> kyrofa I would honestly go with the included module; when I proposed making the expiration times look more friendly I was told the strict format was desired
<sergiusens> we can improve it in the future if it comes to it; but this is not something one would do lightly anyways (and a very specific feature)
<kyrofa> sergiusens, alright, I'll keep everything 8601
<kyrofa> sergiusens, feel like commenting on the PR?
<sergiusens> kyrofa this same comment you mean?
<sergiusens> similar
<kyrofa> sergiusens, haha, whatever you want, but right now it looks like an open conversation to anyone who's not part of this conversation
<sergiusens> done
<elopio> sergiusens: I'll get the pending reviews done tonight.
<mup> PR snapcraft#1839 closed: kernel plugin: update initrd.img-core path to boot/initrd.img <bug> <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1839>
<mup> PR snapcraft#1850 opened: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850>
<sergiusens> kyrofa elopio I just pushed ^, while I didn't get a chance to write a unit test I did verify it works and if adt is enabled, the bionic tests should pass transparently now :-)
<sergiusens> can you do a review considering I need to add some unit tests here and there?
<sergiusens> the only thing that irks me is having to pass in another element into the plugin handler
<kyrofa> sergiusens, sure
<kyrofa> elopio, all the blog posts are done if you're up for a proof-reading session
#snappy 2018-01-05
<mwhudson> src/gopkg.in/mgo.v2/bson/json.go:320:7: constant 9007199254740992 overflows int
<mwhudson> grumble
<mwhudson> also the arch=all build failed
<mup> PR snapcraft#1851 opened: storeapi: add docstrings to _client <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1851>
<mup> PR snapcraft#1835 closed: Update _desktop.py <codein> <Created by Tanesh1701> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1835>
<mborzecki> morning
<zyga> good morning!
 * zyga feels much better today, maybe the weather is changing
<mborzecki> zyga: morning
<zyga> o/
<kalikiana> morning
<zyga> hey kalikiana, mvo
<mvo> hey zyga - good morning
<mborzecki> mvo: morning
<mborzecki> finally openend a PR with diff output in go-check: https://github.com/go-check/check/pull/99
<mup> PR go-check/check#99: many: return diff of stringified value when Equals/DeepEquals check fails <Created by bboozzoo> <https://github.com/go-check/check/pull/99>
<zyga> ohhh
 * zyga hugs mborzecki!
<mvo> mborzecki: hey, good morning! this looks great
 * zyga goes to reboot 
<mvo> mborzecki: curious, did you investigate using github.com/kr/pretty ? or is that inferior/unsuited for pr (iirc we talked about this briefly)
<mborzecki> mvo: i tried it in hope i could drop difflib, but the Diff() that's in kr/pretty is not what i wanted
<mvo> mborzecki: thanks, was just curious
<pedronis> mvo: I'm getting errors preparing Fedora 26 all the time but the log is not clear what is failing
<pedronis> https://travis-ci.org/snapcore/snapd/builds/325038662?utm_source=github_status&utm_medium=notification
<pedronis> it seems to fail installing our own built packages, but there's no error in the log
<mborzecki> mvo: example output http://paste.ubuntu.com/26324546/ with this code: http://paste.ubuntu.com/26324547/
<pedronis> mvo: master is red in the same way
<pedronis> did we break something on fedora ?
<pedronis> mmh, it's fedora preparing just taking too long?
<mvo> pedronis: I don't know, I have not checked yet but noticed as well that something is not right
<pedronis> no, it's failing after 239s that should be below the timeouts
<pedronis> we already have 25 and suse on manual :(
 * kalikiana need..more..coffee
<mvo> pedronis: I run spread against fedora now with -debug maybe that gives me a clue
<pedronis> ok, I'm turning it into manual in my branch for now but will make a PR that puts it back
<Chipaca> morning! is there something wrong with fedora 26 in linode? getting failed prepares
<mvo> Chipaca: yes, but its unclear what
<Chipaca> :-(
<mvo> Chipaca: it seems like dnf -q ... fails but it does not tell why
<mvo> (maybe because of the -q ?)
<Chipaca> i'll do a manual run and see
<mvo> Chipaca: I am in one right now, what I see is "dnf -q -y --refresh install glibc-static" apparently failed
<Chipaca> ah ok
<Chipaca> mvo: network/repo issues?
<mvo> Chipaca: I repeated the commmand manually and it worked :/
<mvo> Chipaca: also dnf history will not show me unsuccessful runs so I don't know why the previous one failed
<mvo> Chipaca: I guess we need to replace "dnf -q" with "quiet dnf" to get useful debug output
<Chipaca> mvo: +1
<mvo> it might be (wild guess) that the fedora repo is a bit overloaded due to the extra security updates pushing out for meltdown/spectre
<mup> PR snapd#4444 opened: tests: use "quiet" helper instead of "dnf -q" to get errors on failures <Created by mvo5> <https://github.com/snapcore/snapd/pull/4444>
<mup> PR snapd#4392 closed: many: refresh with appropriate creds <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4392>
<Chipaca> well that doesn't tell me much
<pedronis> Chipaca: ?
<Chipaca> Error: Failed to synchronize cache for repo 'updates'
<Chipaca> is the entirety of dnf's output
<pedronis> we have seen it before though
<pedronis> it's a clasic
<pedronis> classic
<zyga> darn, is there no way to have a mock variable for a recursive function?
<zyga> var func := impl
<zyga> and then call func inside impl (indirectly here)
<mvo> Chipaca: well, its much better than seeing nothing :)
<Chipaca> mvo: yeah
<Chipaca> zyga: ?
<Chipaca> mvo: not much >> nothing
<pedronis> you need a wrapper
<zyga> mvo: guess it's one more time to jump into OFTC
<mvo> Chipaca: and something that we can google for
<mvo> zyga: I'm in oftc, how does that help ;)?
<Chipaca> mvo: best answer i found so far is that we need to do 'dnf clean all' at the start
<mvo> meh
<Chipaca> mvo: i'm going to test that
<zyga> mvo: go to #linode and complain
<zyga> mvo: that their repo is periodically broken
<mvo> zyga: oh? it could be their mirror? fwiw, it seems like it is not always broken, I just have a run that seems to be doing fine
<zyga> yes, it is their internal mirror
<zyga> as neal suspected is is probably failing while it syncs to the outer mirror
<zyga> because it is removing files before, not after rsync is done
<zyga> so you can see partially broken mirror at that time
<mvo> maybe time to update their mirror script then?
<mvo> ubuntu fixed this a long time ago (to be fair it  was a problem for a long time too)
<pedronis> zyga: you are hitting an initialisation loop
<zyga> pedronis: yes
<zyga> ../../../go/src/github.com/snapcore/snapd/cmd/snap-update-ns/change.go:85: initialization loop:
<zyga> ... bunch of calls
<pedronis> I recommend just being naive
<pedronis> have a impl that calls implRec that calls itself or something
<pedronis> unless you really need the partial mocking, in which a func init() might help
<pedronis> *which case
 * zyga experiments
<Chipaca> mvo: part of the problem is that we do a dnf call per package, and any one of them can fail this way
<Chipaca> mvo: i'll see if i can resurface my branch that avoids this
<mvo> Chipaca: ok
<pedronis> zyga: these works:  https://play.golang.org/p/uihgox8C_RU
<zyga> pedronis: thank you!
<zyga> yep, that works for me
<mup> PR snapd#4445 opened: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
<BjornT_> i get an error when trying to install the maas snap in a bionic container. any ideas on what's wrong? https://paste.ubuntu.com/26325056/
<zyga> BjornT_: any denials?
<Chipaca> mvo: zyga: do you guys push core to staging, or is that somebody else?
<zyga> no idea about staging
<zyga> (staging store I assume)
<mvo> Chipaca: staging store ? I'm not familiar with the workflow, cachio is
<Chipaca> ah
<Chipaca> Facu: ^ so â¦ the person that could do it is still on holidays i think
<Facu> Chipaca, ack, thanks
<Chipaca> Facu: but when he gets back, let's make updating staging part of the release workflow
<Chipaca> Facu: (remind me?)
<Chipaca> Facu: (or talk to him! i ain't a manager :-p )
<Facu> Chipaca, :)
<BjornT_> zyga: not that i can see. this is 'journalctl -xe': https://paste.ubuntu.com/26325079/
<mvo> Chipaca: fun! pr#4444
<mvo> (its just a number but still fun)
<pedronis> mvo: you probably want to merge master into pr#4444 and remove the manual IÂ just added to spread.yaml
<Chipaca> mvo: #4445 is more fun :-p
<mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
<Chipaca> mvo: why isnt 4445 even allocating a fedora? :-/
<mvo> Chipaca: yeah, was just reviewing this one
<Chipaca> mvo: the review of that one gets a lot easier if you add ?w=1 to the url
<Chipaca> ('ignore whitespace')
<zyga> BjornT_: that doesn't ring any bells, sorry :/
<pedronis> Chipaca: I turned fedora to manual in my PRÂ to be able to land it fwiw
<mup> PR snapcraft#1811 closed: Add type hints cli/assertions.py module <codein> <Created by m4sk1n> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1811>
<mup> PR snapcraft#1851 closed: storeapi: add docstrings to _client <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1851>
<Chipaca> pedronis: o\
<Chipaca> pedronis: that would explain the lack of fedora in 4445 :-)
<pedronis> Chipaca: you and mvo probably need to turn it on again on your PRs
 * pedronis lunch
<mvo> pedronis: ohhh, ok
<mup> Bug #1741463 opened: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>
<BjornT_> zyga: ok, i filed a bug about it: ^^^
<mup> PR snapd#4446 opened: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <https://github.com/snapcore/snapd/pull/4446>
<zyga> BjornT_: thanks
<ackk> hi, does anyone know what could be causing this error: https://paste.ubuntu.com/ ?
<ackk> err
<ackk> https://paste.ubuntu.com/26325221/
<Chipaca> ackk: #1741463
<mup> Bug #1741463: Failure to install maas snap in a bionic container <Snappy:New> <https://launchpad.net/bugs/1741463>
<ackk> Chipaca, this is a different error, though?
<Chipaca> ackk: ah, perhaps
<ackk> this is in a bionic container, and the snap was built on bionic
<Chipaca> ackk: that error looks like the maas snap has been built on the wrong libc
<Chipaca> ackk: do not build snaps on non-xenial unless you really know why you're doing it
<Chipaca> ackk: your snap is now trying to use bionic libc, which isn't available to it
<Chipaca> bah, not sure if this is your snap -- the maas snap, i mean
<ackk> Chipaca, isn't there a bionic-based core image?
<Chipaca> ackk: no
<Chipaca> ackk: there will be, once 18.04 is out
<ackk> Chipaca, not even a daily build?
<zyga> ackk: no, because lots of stuff is missing, we want to make some things different, not just refreshed
<zyga> ackk: I think you will see 18.04 base snaps sooner but not meant for booting
<zyga> in fact mvo did some work on that in December
<Chipaca> ackk: when we get it working it'll be a Big Deal and announced in all the usual ways
<ackk> I see
<Chipaca> ackk: you're welcome to work on a 18.04 base if you want to thuogh
<ackk> Chipaca, how do I install it?
<Chipaca> ackk: sorry, by 'work on' i meant 'create one'
<ackk> ah :)
<Chipaca> ackk: why do you need 18.04 libc?
<Chipaca> ackk: doesn't maas work on pre-18.04?
<ackk> Chipaca, yes, but master just switched to bionic, so we're now building stuff on bionic
<zyga> Chipaca: there is a very premature one
<Chipaca> ackk: snapd does not yet support that; I'd disrecommend doing so until we do
<zyga> snapcore/base-18 AFAIR
<zyga> but super early stuff
<Chipaca> zyga: not a public snap fwiw
<zyga> public just not done
<zyga> it's on github ;)
<Chipaca> zyga: ah :-)
<zyga> https://github.com/snapcore/base-18
<Chipaca> right
<Chipaca> still, not supported, and i wouldn't recommend it at all
<zyga> yes
<zyga> agreed
<Chipaca> unless you really want to work on _that_ and not the thing you're working on
<ackk> ok, thanks for the info
<zyga> totally
<Chipaca> if it were easy it'd be done :-D
<mvo> ackk: we have some code for base-18, if you don't mind that things break I can push what we have to edge
<mvo> ackk: is our WIP branch https://github.com/snapcore/base-18
<mvo> aha, zyga said it already, sorry for the noise
<ackk> mvo, so, if you push that base to edge, installing a bionic-built snap should work, right?
<zyga> well
<zyga> how do you build that bionic-based snap?
<zyga> snapcraft probably cant because there's no real base 18 yet
<zyga> so ... ?
<ackk> it does build
<zyga> on bionic itself
<ackk> yes
<zyga> but then it looks at the core snap to resolve libs and whatnot
<zyga> and there's no base 18 to do that
<zyga> so something is wrong at the build stage already
<ackk> zyga, where does it look for the core snap?
<zyga> ackk: to resolve libs and dependencies
<zyga> ackk: kalikiana would know more
<ackk> zyga, no I mean where does it look it up
<ackk> locally or does it download it ?
<zyga> ackk: it downloads core snap AFAIK
<zyga> but I really don't know
<mvo> ackk: you will need to add "base: base-18" in your snap and install it manually beforehand. you can try that now via "https://code.launchpad.net/~mvo/+snap/base-18/+build/113575/+files/base-18_very-unstable_amd64.snap"
<ackk> ah nice
<ackk> thanks
<mvo> ackk: my hints cover the snapd side, snapcraft I'm not sure, but if it already builds inside a bionic env thats probably "fine"(ish) for now
<ackk> zyga, fwiw it seems snapcraft doesn't really look the base snap up. I had typo'd the base: entry, but the snap built anyway
<kalikiana> ackk: Snapcraft looks at /snap/core/current
<kalikiana> And it must be installed
<kalikiana> ackk: are you building a classic snap?
<ackk> kalikiana, but it doesn't fail if it isn't?
<ackk> kalikiana, no
<zyga> kalikiana: base-18 based snap
<ackk> so, the first time I built it, I didn't have the core snap installed
<ackk> still, the build succeded
<ackk> actually, that's not true
<ackk> it was installed
<ackk> $ sudo snap try --devmode build/dev-snap/prime/
<ackk> error: cannot perform the following tasks:
<ackk> - Mount snap "maas" (unset) (cannot find required base "base-18")
<ackk> kalikiana, ^ with base: base-18
<ackk> (and the base installed)
<ackk> https://paste.ubuntu.com/26325400/ for reference
<ackk> https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic is my snapcraft.yaml
<kalikiana> ackk: I'm afraid I don't know if this is expected to work. There's no code (yet) handling the base as far as I'm aware
<kalikiana> That is, in Snapcraft - `snap try` is not part of Snapcraft
<ackk> right, I guess that's more a question for mvo :)
<Chipaca> ackk: that's weird, bases work for sure
<ackk> Chipaca, do they require any flag at installation? I justwent with snap install --dangerous
<Chipaca> ackk: that base isn't a base! that's the problem
<Chipaca> ackk: note it doesn't say 'base' in the Notes column
<Chipaca> ackk: remove it, make sure it's type:base, try again
<Chipaca> ackk: you can try bases, also
<ackk> Chipaca, so that's a problem with the base build?
<ackk> mvo, ^
<ackk> Chipaca, wdym "you can try bases, also"
<Chipaca> ackk: 'snap try' works for bases
<Chipaca> ackk: so you can unsquash the .snap, tweak it, and don't need to repack it
<ackk> oh
<ackk> ok
<Chipaca> ackk: or you can mount it by hand somewhere, bind mount a tweaked snap.yaml, and try it there, for even less io work
<Chipaca> but that's getting weird :-)
<ackk> frankensnap
<zyga> Chipaca: snap-confine _may_ have issues with base snaps that are in try mode
<zyga> Chipaca: especially the new invalidate stale base snap code
<Chipaca> zyga: this worked for me at some point fwiw
<Chipaca> zyga: you broke my netscape snap /o\
<zyga> yes, it's just that specific aspect that may fail
<Chipaca> zyga: (jk, i broke it myself before you got to it)
<zyga> I blame weather, it's still not good IMO
<ackk> Chipaca, would it be possible to kick another build of the base with the metadata fixed?
<mvo> ackk: oh, so you ahve base-18 installed and it still complains? hmm, what snapd version
<ackk> mvo, 2.30 (bionic)
<mvo> ackk: strange, I have a look after my meeting (in a meeting right now)
<Chipaca> pedronis: http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html might be relevant
<ackk> mvo, ok got a different error now, after changing the base snap adding "type: base": https://paste.ubuntu.com/26325613/
 * kalikiana going to head out for lunch
<mvo> ackk: aha, right. iirc there is a problem with the snap build when if it is set to type: base (sorry that I did not remember that earlier)
<ogra_> slangasek, i have a slight ubuntu-image problem ... trying to build a multi-volume image like https://paste.ubuntu.com/26325509/ (u-boot lives in /dev/mtd on that device while the rootfs is on mmc so i need two flashable img files), i end up without a writable partition
<Chipaca> mvo: #4394 might be an easy one for you to re-review (and it's green, has one other +1, and is blocking a followup)
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<mvo> ackk: hm, thats an interessting error, out of curiosity does it help if you add a "type: app" to the mass snap ?
<mvo> Chipaca: oh, indeed, let me look at it again, iirc its long
<Chipaca> mvo: +729-1
<Chipaca> the followup is shorter but hairier
<ogra_> slangasek, is there any way to tell u-image where to put writable (definiing it in the structure just gives me an empty ext4 partition, the rootfs doesnt get copied)
<Chipaca> mvo: #4445's fedora thing just passed (the test overall failed because of a timeout downloading core...)
<mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
<mup> PR snapd#4447 opened: tests: fix test whoami, share successful_login.exp <Created by pedronis> <https://github.com/snapcore/snapd/pull/4447>
<pedronis> Chipaca: what you asked in the other PR  ^
<mvo> Chipaca: nice
<mvo> Chipaca: well, not that it fails but the fact that fedora didn't
 * Chipaca hugs pedronis 
<Chipaca> mvo: if 4445 passes and we agree to land it, i'll merge it into 4442 and add a rename from advice-command to advise-command to it
<mvo> Chipaca: +1
<mup> PR core#68 opened: hooks: fix shellcheck complains <Created by mvo5> <https://github.com/snapcore/core/pull/68>
<mborzecki> zyga: blog-post-january :)
<zyga> hmm?
<mvo> resolutions for the new year ;)
<mborzecki> looking at your blog, you've published something on Jan 02, 03, 04 :)
<zyga> mborzecki: ah, yes, :)
<mborzecki> zyga-daily :)
<zyga> mvo: just feeling bad about being useless this week, at least I can blog
<mvo> zyga: just kidding, I think thats great
<Chipaca> - Fetch and check assertions for snap "test-snapd-tools" (5) (Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-declaration/16/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw?max-format=2: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers))
<Chipaca> :-(
<mborzecki> agree with mvo, very nice read
<zyga> thanks, I'm trying to find the right balance of length/tech that can be casual to read yet useful
<ackk> mvo, lemme try
<mup> PR core#69 opened: hooks: add 28-command-not-found.chroot to create c-n-f handler <Created by mvo5> <https://github.com/snapcore/core/pull/69>
<mvo> Chipaca: for you -^ :)
<ackk> mvo, no difference
<Chipaca> mvo: is that the right way? what creates command_not_found_handler given /usr/lib/command-not-found?
<mvo> ackk: can you `snap remove maas` (if it is already installed?)
<ackk> mvo, it's not
<mvo> ackk: ok, let me look at the code
<ackk> although there's a leftover symlink in /var/lib/snapd/snaps/maas_x1.snap
<ackk> (this is something I noticed before, if snap try fails
<mvo> Chipaca: there is /etc/bash.bashrc which creates this
<mvo> ackk: oh, does it help if you remove that (wild guess)
<mvo> Chipaca: i.e. its part of the default bash in ubuntu
<ackk> mvo, no, I mean I remove it everytime otherwise snap try doesn't work the next time
<ackk> but then it still fails
<ackk> I think that link should be cleaned up on failures
<mvo> Chipaca: so we could do it differently and modify /etc/bash.bashrc to call snap advise-command directly
<Chipaca> mvo: this seems fine to me
<mvo> ackk: yeah, sounds like something we want to fix, could you write a bugrport or forum post with reproduce instructions please?
<mvo> ackk: I look at the code now, could you pastebin your snapcraft.yaml (or /msg it to me if its private)
<ackk> mvo, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic
<ackk> mvo, bugs go in LP, right?
<mvo> ackk: yeah
 * mborzecki is off to pick up the kids
<ackk> mvo, https://bugs.launchpad.net/snappy/+bug/1741486
<mup> Bug #1741486: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
<mup> Bug #1741486 opened: failed snap try leaves snap symlink around <Snappy:New> <https://launchpad.net/bugs/1741486>
 * zyga-ubuntu tries to unfreeze his desktop
<mvo> ackk: ta
<BjornT_> zyga-ubuntu: do you think you could give bug 1741463 some priority. turns out it happens in xenial containers as well, so a bit more severe than i thought
<mup> Bug #1741463: Failure to install maas snap in a container <Snappy:New> <https://launchpad.net/bugs/1741463>
<mvo> ackk: hm, if you `grep "type:" build/dev-snap/prime/meta/snap.yaml - does that show "type: app"? the only thing I can see is that "type" is missing (which is a snap try bug that it does not DTRT if it is missing, I'm just curious about if this maybe a workaround for you)
 * mvo tries to build the maas snap to `snap try` it
<ackk> mvo, ah yeah I haven't committed that, I tried locally
<mvo> ackk: thats fine
<mvo> ackk: I mean, did it propagate into prime/ (the type: app) setting?
 * ackk checks
<ackk> $ grep type build/dev-snap/prime/meta/snap.yaml
<ackk> type: app
<ackk> mvo, ^
<ackk> I have seen that error before but I can't remember what was missing
<mup> PR snapd#4447 closed: tests: fix test whoami, share successful_login.exp <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4447>
<ackk> mvo, btw, can you add "type: base" in base-18?
<mvo> ackk: I'm not sure I can without breaking the LP builds
<mvo> ackk: but I will try
<ackk> oh
<ackk> ok
<zyga-ubuntu> BjornT_: what was the host of the LXD container?
<mvo> ackk: I am running `snapcraft` now for the maas snap checkout. but it seems like it is taking a long time to pull all the deps
<ackk> yeah it does
<jdstrand> niemeyer: hi! I noticed when looking at https://forum.snapcraft.io/t/fonts-fail-to-load-when-desktop-plug-added/3414/3 that if I click '...' I no longer see a checkbox for marking it as a solution. I can normally do this. Is this intentional?
<zyga-ubuntu> jdstrand: note, gustavo is back next week
<jdstrand> niemeyer: oh, I forgot you were on holiday. answer next week in backscroll and I'll see it at some point
<jdstrand> zyga-ubuntu: thanks
<BjornT_> zyga-ubuntu: the host is xenial
<zyga-ubuntu> BjornT_: thanks, I can try on xenial vm tomorrow/monday
<ackk> mvo, so, if I make my bionic container privileged I get a different error:
<ackk> - Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --rbind /snap /snap: Permission denied
<ackk> in xenial I used to have security.privileged=true
<BjornT_> zyga-ubuntu: cool, thanks
<zyga-ubuntu> ackk: privileged containers == borken snapd
<zyga-ubuntu> totally unsuportable configuration
<ackk> it did work in xenial
<ackk> I mean, with xenial containers
<ackk> i've been using it for months :)
<mvo> ackk: the remount might be interessting for zyga
<mvo> heh
<mvo> he replied already
<zyga-ubuntu> ackk: by accident
<zyga-ubuntu> ackk: in such container the host and guest share apparmor namespace
<zyga-ubuntu> ackk: and nothing works sensibly
<zyga-ubuntu> ackk: what-reloaded-last takes control
<zyga-ubuntu> ackk: it's not supported but not actively detected by snapd
<ackk> ok
<ackk> I'm back to not-privileged
<zyga-ubuntu> ackk: it cannot ever work reliably, in the case where host==guest it can also break in some cases when packages don't match exactly
<mborzecki> wrapping it up for today, have a great weekend
<kalikiana> re
<mvo> ackk: when I run "snapcraft" from the git pull I get https://paste.ubuntu.com/26326002/ and I don't have a dir for trying AFAICT
<ackk> mvo, which branch are you using?
<ackk> mvo, the snap-bionic one?
<mvo> ackk: ah, maybe that is the problem, I might be on master, let me check
<ackk> mvo, that branch should fix the issue
<ackk> mvo, right, checkout snap-bionic :)
<mvo> ackk: *cough* thanks
<mvo> ackk: thanks, I can reproduce the failure (not exactly the same though) - I need to think a bit but this may well be something that requires a couple of days to fix as the base-18 work is still very much WIP
<ackk> mvo, cool, thanks
<ackk> mvo, fwiw I get the same error with both snap try and snap install
<mvo> ackk: (i.e. the issue is that no snapd/snap/snapctl/snap-exec is available inside base-18 currently, i.e. we need to mount that from snap-confine into the right places yet iirc)
<ackk> mvo, I see
 * mvo ponders a bit
<zyga-ubuntu> mvo: good observation, I was thinking that we need a version of the inside-ns tools that are linked statically and available
<zyga-ubuntu> mvo: I would not reuse the regular ones as there's no guartee those would work (snap-confine, snap-update-ns)
<zyga-ubuntu> (snapctl perhaps)
<mvo> zyga-ubuntu: +1 on that
<zyga-ubuntu> mvo: alternatively a new novel way of using them from within the core snap ns
<zyga-ubuntu> mvo: but this is problematic
<mvo> Chipaca: btw, do you have an opinion on lp 1737197 ? you worked in this area recently
<zyga-ubuntu> mvo: (because /run/snapd/ns)
<zyga-ubuntu> so, my destkop is in weird state
<zyga-ubuntu> all the software works
<zyga-ubuntu> GUI updates
<zyga-ubuntu> mouse moves
<zyga-ubuntu> but, input is broken, nothing gets passed to apps
<mvo> zyga-ubuntu: right, we should brainstorm about this monday
<zyga-ubuntu> mvo: sounds good
<mvo> zyga-ubuntu: sounds like something is grabing your input ?
<zyga-ubuntu> I can ssh in and despite some high ram usage (not even swapping though)
<zyga-ubuntu> nothing seems wrong
<zyga-ubuntu> maybe gnome-shell
<zyga-ubuntu> I'm reluctant to kill it
<mvo> zyga-ubuntu: that causes havoc :)
<zyga-ubuntu> yeah
<zyga-ubuntu> I'll keep it asis for now, let some software running finish
<mvo> zyga-ubuntu: in the old days, ctl-alt-f2 and then back to X helped with these
<zyga-ubuntu> I did that, I can go back to gnome login manager
<zyga-ubuntu> and login as myself
<zyga-ubuntu> but then it is stuck again
<zyga-ubuntu> (weird, right?)
<zyga-ubuntu> (by login I mean unlock the same session)
 * mvo nods
<Chipaca> zyga-ubuntu: could it be the thing where your input is grabbed by the console?
<Chipaca> or was that the other way around
<Chipaca> something about ^C in the terminal killing the session maybe
<zyga-ubuntu> Chipaca: console as in other vt?
<zyga-ubuntu> I only run irssi, vim and a few man pages there
<Chipaca> yes
<zyga-ubuntu> and no other vt is used
<Chipaca> https://forum.snapcraft.io/t/ctrl-c-in-terminal-logs-out-of-current-gdm-session/2162/21
<zyga-ubuntu> I think that was fixed a while ago (by now)
<zyga-ubuntu> but weirdly, nothing has focus
<zyga-ubuntu> and I cannot click to focus
<zyga-ubuntu> or alt-tab to focus
<ackk> mvo, FTR I get the same error if "snap try" a maas snap built on xenial
<ackk> (which of course doens't use base-18)
<mvo> ackk: hm, hm, I wonder if something funny happend to your /var/lib/snapd/state.json - can you install anything or is it realy just maas that is unhappy?
<ackk> mvo, I do have other snaps installed
<mvo> ackk: (careful with sharing the content of that file, it contains e.g. macaaron data which is sensitive)
<mvo> ackk: right, I mean, can you install other new snaps?
<ackk> trying now
<ackk> snap install hello-world worked
<mvo> ackk: ok, so its not that
<ackk> mvo, no, also I can install the stable maas snap in bionic
<ackk> (from the store)
<Chipaca> mvo: answered in 1737197
<mvo> Chipaca: ta
 * mvo steps out for some minutes
<ackk> mvo, not sure if I mentioned it before, but I'm doing all of this in a bionic container
 * Chipaca is >this< close to giving up on this fedora malarkey
<nacc> Chipaca: good use of malarkey
<kalikiana> :-D
<ackk> what's the proper way of fixing a failed snap removal inside a container?
<mup> PR snapd#4446 closed: snap: use stdout instead of stderr for "fetching" message <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4446>
<mup> PR snapd#4435 closed: snap: do not leak internal network errors to the user <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4435>
<mup> PR snapd#4434 closed: tests/main/confinement-classic: enable the test on Fedora <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4434>
<mvo> jdstrand: not sure how busy you are (super busy I guess) - if there is a spare cycle, a review for pr 4073 would be nice, only the security aspects of course. it should address the issues you outlined
<mup> PR #4073: snap: add io.snapcraft.Settings to `snap userd` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4073>
<ackk> mvo, fwiw https://paste.ubuntu.com/26326503/ is what I see from snapd debug
<mvo> ackk: thanks, interessting. it looks like the type="" is just a secondary error after "2018/01/05 16:26:21.967261 task.go:303: DEBUG: 2018-01-05T16:26:21Z ERROR cannot find installed snap "maas" at revision x1" but this one is also puzzling
<ackk> right
<ackk> mvo, could it have to do with --devmode?
<ackk> ISTR hitting this error before, but I can't remember how I got past it
<mvo> ackk: not sure, sorry, I setup a proper bionic env now to test fully (so far I only build the snap under bionic but not tested it there)
<ackk> kalikiana, if I don't specify a base: in my snap, but include all shared libs that binaries need manually, will snapcraft still look up stuff from the core snap?
<ackk> kalikiana, (just wondering if I could not use a base and include everything so that the snap then works on bionic)
<slangasek> ogra_: hum, it's certainly meant to be possible to define the location of writable in a multi-volume image, and have it correctly populated; so if you are seeing something different, it's perhaps a bug in un-exercised code; can you reach out to sil2100?
<ogra_> slangasek, yeah, i would have pinged him first but he seemed to be off
<ogra_> slangasek, oh, fun ... looking at gadget-yml.rst in the u-image source has:
<ogra_> XXX: how do we know which volume the writable partition is supposed to be
<ogra_> placed on?
<ogra_> :P
<ogra_> so obviously a missing feature
<ogra_> i guess we need something like a "has-writable: true" option for the volumes that triggers writable to be created there
<kalikiana> ackk: Not quite sure I grok the question. If you include all the libs that won't change how Snapcraft operates... but there will be no need to use anything from the core snap
<slangasek> ogra_: uh, the design that we documented is that you spell out in your yaml which image gets the writable partition
<ogra_> slangasek, yeah, seems that lacks implementation yet
<ackk> kalikiana, I'm wondering what is snapcraft looking at the core snap for
<ogra_> i suspect nobody needed that yet
<kalikiana> ackk: For classic snaps it needs to link against what's in core
<ackk> kalikiana, this is not a classic snap
<slangasek> ogra_: we certainly don't need any 'has-writable: true'.  what does your yaml look like?  Did you set role: system-data?
<ogra_> slangasek, ah ... no, i didnt ... this (with customer info removed) is my yaml https://paste.ubuntu.com/26325509/
<slangasek> ogra_: 'role: system-data', documented in https://forum.snapcraft.io/t/the-gadget-snap/696
<ogra_> i'll try with role
<kalikiana> ackk: Hmmm I can't think of anything else right now - kyrofa, any idea?
<ogra_> oh, wow ... that tellys you you can use an implicit fs label "or writable" ... our initrd wouldnt be happy about any other label
<ackk> kalikiana, basically to workaround https://paste.ubuntu.com/26325221/
<ackk> I'm wondering if we could manually include the libs we need from bionic
<ogra_> slangasek, thanks ! i think that will do it ... i didnt read the forum post but looked at the shipped docs in the source tree ... i guess they need some updating (or just a pointer to the forum)
<jdstrand> mvo: it's already high in the trello queue already. probably won't happen today though
<mvo> jdstrand: thanks, no worries!
<jdstrand> np
 * kalikiana wrapping up for the day/ week, tho probably idling on IRC for a little while
<mvo> ackk: with the following PR https://github.com/snapcore/base-18/pull/24 I get to https://paste.ubuntu.com/26326893/ - I suspect that maas is doing a chown to something that is not root in the configure hook? this is currently not supported unfortunately
<mup> PR base-18#24: hooks: fixes to make it usable as a real base snap <Created by mvo5> <https://github.com/snapcore/base-18/pull/24>
<mvo> ackk: I will also try to build with type: base, I hope lp/snapcraft support this now. sorry for this bumpy ride
<mvo> ackk: fwiw, the pastebin above is all using bionic
<mup> PR snapd#4448 opened: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <https://github.com/snapcore/snapd/pull/4448>
<ackk> mvo, np, we're all breaking new ground :)
<mvo> ackk: I requested a new build for base-18 but looks like the builds are very slow/busy right now (schedule in ~3h)
<ackk> mvo, can you paste the link to the built images again?
<Chipaca> mvo: do i have your +1 for #4445
<mup> PR #4445: tests: make less calls to the package manager <Created by chipaca> <https://github.com/snapcore/snapd/pull/4445>
<ackk> mvo, ah, yes https://paste.ubuntu.com/
<ackk> mvo, but that used to work before?
<ackk> mvo, can you try commenting those out (I don't have the updated base image here)
<mvo> Chipaca: yes
<mup> PR snapd#4445 closed: tests: make less calls to the package manager <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4445>
<Chipaca> :)
 * mvo hugs Chipaca 
<ackk> mvo, I meant https://paste.ubuntu.com/26326974/
<blake_r> ackk: here
<blake_r> ack: here
<ackk> blake_r, mvo was asking about those chown in the configure hook
<ackk> mvo, does snapd now support running as different users?
<blake_r> that is because squid will not allow you to run as root
<blake_r> so we spawn it with nobody:nobody
<blake_r> we have the sample problem with postgres
<ackk> mvo, ^
<ackk> blake_r, how do you actually spawn it as nobody? you can't really "su" right?
<ackk> blake_r, maybe maas should be a classic snap :)
<blake_r> supervisord runs it
<blake_r> ackk: no!
<ackk> actually it probably can't
<ackk> because other distros, right?
<blake_r> correct
<blake_r> it needs to go to strict
<blake_r> just have not got that far
<ackk> which it probably can without too much work
<ackk> but, digressing :)
<blake_r> yeah probably need some interfaces, but maybe its close
<blake_r> look at snap/conf/supervisord.conf.template
<blake_r> also we do some wierd stuff with sudo to use initdb for postgres
<blake_r> src/maascli/snappy.py also changes to run as nobody to perform the `maas init` command that initialized the database
<ackk> mvo, is that still suported? ^ running as nobody
<mvo> ackk: aha, thanks. I will try devmode then if that is a known thing
<mvo> ackk: and progress! it now fails with an error that it can't find /usr/share/distro-info/ubuntu.csv, not sure we can do much about this
<mvo> ackk: so this is all with my updated base-18 that still has a "starts in 3h estimate "
<ackk> mvo, I see, where can I get those builds once they're done?
<Saviq> hi all, is installing a local snap getting stuck at "copy snap data" (when the snap barely has any data outside of $SNAP_COMMON) a known issue? it's stuck at aborting that change now
<ackk> mvo, so you commented out the chmod?
<mvo> ackk: I used --devode
<mvo> ackk: here https://code.launchpad.net/~mvo/+snap/base-18
<ackk> mvo, oh so with devmode the chown works?
<mvo> ackk: correct
<mvo> ackk: I was trying to install it as a strict snap, that failed
<blake_r> mvo: ah yeah doesn't work in strict
<ackk> mvo, is there support in snaps now to run stuff as different users?
<blake_r> mvo: does snappy support users yet?
<mvo> ackk: so the next stumbling block is this ubuntu.csv
<mvo> blake_r: sorry, not yet :/
<blake_r> mvo: I can fix that ubuntu.csv
<mvo> blake_r: cool, thank you!
<blake_r> mvo: we can't go to strict until thats done, timeline on users?
<mvo> blake_r: if its trivial (the ubuntu.csv fix) then please share the diff then I can try again with the fix
<mvo> blake_r: no timeline yet, I expect this to be a topic in cape town though
<blake_r> mvo: okay
<ackk> please make sudo work in snaps! :)
<blake_r> mvo: http://paste.ubuntu.com/26327405/
<blake_r> mvo: can't really test, but that should work
<mvo> blake_r: ta
<mvo> blake_r: unfortunately your diff is not enough, it appears that the distro_info python module looks into /usr/share/distro-info but this data is now located in $SNAP/usr/share/distro-info
<mvo> blake_r: and looking at distro_info.py it appears to be hardcoded. we will soon have "layout" to remap bits of the filesystem dynamically. that will be an elegant way to fix this
<mvo> blake_r: fixing distro_info to look at a env for its datadir is also trivial of course, probably something to talk about on monday (getting late here in my TZ :)
<blake_r> mvo: okay we can look at it money, go enjoy your evening
<blake_r> monday*
<mvo> blake_r: alternatively we *could* add distro-info to base-18, but I would prefer to keep it as tiny as possible (though distro-info is tiny so maybe a worthwhile tradeoff)
<ackk> mvo, blake_r those .csv come from the distro-info part
<mvo> ackk: yeah, except that the python code hard-codes /usr/share/distro-info it seems
<blake_r> mvo: it would be nice to be in the base
<mvo> ackk: and in the snap that is not the location
<ackk> actually, used to
<blake_r> maybe that is why it worked on xenial
<blake_r> as we didn't have this issue
<mvo> blake_r: its in the range of <90kB so not too bad
<mvo> blake_r: correct
<mvo> blake_r: I checked, its there in the xenial based core we have today
<blake_r> yeah placing it in the base would be helpful
<ackk> blake_r, so we could probably kill that part altogether if it's in core
<ackk> core/base
<blake_r> probably need the python piece, but not the csv
<mvo> blake_r, ackk with the disto-info added to base-18 and my other PRs merged for base-18 I can install maas with --devmode now in bionic
<mvo> and the snap.maas.supervisor.service is up and running
<blake_r> mvo: can you try `maas init`
<blake_r> sudo maas init
<mvo> sure
<mvo> I used the defaults and it is now at "initializing database"
<mvo> how long should I wait for "init database"?
<blake_r> once its done
<mvo> fwiw https://github.com/snapcore/base-18/pull/26
<mup> PR base-18#26: hooks: also install the disto-info package in base-18 <Created by mvo5> <https://github.com/snapcore/base-18/pull/26>
<blake_r> shouldn't take to long
<blake_r> unless its stuck or something
<mvo> (this is a single core bionic vm with just 1gb ram, it is still at init)
<blake_r> ah then it might take a few
<mvo> strace shows its in futex(... FUTEX_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME...)
<mvo> I will leave it run for a bit and report back
<blake_r> if it finishes run `sudo maas status` to get the status of the services inside the snap
<blake_r> some should be off but none should be fatal
<ackk> mvo, \o/
<ackk> mvo, once it's all built, could that be pushed to edge?
<mvo> ackk: yes, I think at this point thats fine
<mvo> ackk: may take a bit, the one estimate just jumped from 3h to 8h
<mvo> ackk, blake_r: unfortunately still at init database, I will call it a day. lets look at this again monday. have a good weekend
<mup> PR snapcraft#1842 closed: lxd: Change "Terminating" message to debug level <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1842>
<blake_r> mvo: have a good weekend, thanks for the help
<remmusikm> exit
<kyrofa> elopio, are you around? And have you ever used circle CI before?
<maninalift> I have just installed Ubuntu Server 17.10 with snappy and set up the nextcloud snap - GREAT - really easy (which is a relief after giving up on setting up nextcloud in NixOS)
<elopio> kyrofa I am, and I have not. Just read the guides
<kyrofa> elopio, okay good, keep it that way. You can be the guinea pig for the tutorial I'm writing, I don't remember exactly what it looks like for new users
<maninalift> ...however I'm not sure the best way to set up different services under different subdomains
<wililupy> I want to add an environment variable to my application launcher. Would it be easier just to write my own wrapper or is this something that I can have set inside the snap?
<maninalift> e..g.    cloud.mydomain.com for nextcloud
<maninalift> and chat.mydomain.com for rocketchat
<maninalift> if I were setting up a web-server without the snappy container stuff I'd put an nginx instance in front  to proxy to different services
<maninalift> but I wondered whether there is a particular way I should be doing this that fits with snappy
<maninalift> there is a clear focus on giving a really simple setup exerience and I thought there might be something that "just works" when I setup multiple services without my having to manually configure the proxy
<maninalift> ...thanks for any help
<Chipaca> wililupy: you can declare environemtn in the yaml
<Chipaca> wililupy: whether it's enough for what you need  i don't know
<Chipaca> maninalift: sounds like a question for the forum tbh
<Chipaca> maninalift: if you could open a new topic on https://forum.snapcraft.io/ that'd be great
<wililupy> Chipaca: are there examples of this on snapcraft.io?
<Chipaca> wililupy: let me check
<elopio> kyrofa: good, I'll just stay ignorant ð
<mcphail> maninalift: I know setting up namevirtualhosts still requires doing things the old way and then proxying. I've asked about this recently
<wililupy> ideally, I would like to use 'snap set' to configure which configuration file to use for the device since the variable is read by the applicaation and the config file tells what port does what and how many ports there are on the device.
<maninalift> Chipaca: OK, thanks will do
<Chipaca> wililupy: i'm not very good at finding these things, but https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175
<Chipaca> wililupy: that does sound like the sort of thing the config hook was made for, yes
<Chipaca> wililupy: note 2.30 gives you the ability to stop/start services from hooks
<wililupy> Thanks Chipaca, that is what I was looking for. Do you have a good place I can read up on the "inner workings" of snap set command?
<Chipaca> wililupy: 'snap set' triggers the config hook; look that up -- i think kyrofa explained it in detail
<Chipaca> wililupy: https://kyrofa.com/posts/snap-configuration-the-configure-hook ?
<Chipaca> maybe :-p
<wililupy> Chipaca: Cool. I check that out.
<kyrofa> Chipaca, yeah, it's discussed there, certainly
#snappy 2018-01-06
<mup> PR snapd#4442 closed: many: implement the advisor backend, populate it from the store <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4442>
#snappy 2018-01-07
<baimafeima> Hi all
<baimafeima> does anyone know how https://github.com/snapcrafters/tor-browser is coming along?
<ikey> Anyone wanna help me design the steam-support snap interface? :P
 * ikey puts out begging cup
<ikey> fwiw i have most of it written i just need help with autoconnect foo
#snappy 2018-12-31
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#5982, snapd#6016, snapd#6025, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6243, snapd#6252, snapd#6258,
<mup> snapd#6270, snapd#6280, snapd#6281, snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6323
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#5982, snapd#6016, snapd#6025, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6243, snapd#6252, snapd#6258,
<mup> snapd#6270, snapd#6280, snapd#6281, snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6323
#snappy 2019-01-01
<mup> PR snapcraft#2432 opened: CMake specific parallel option <Created by deinok> <https://github.com/snapcore/snapcraft/pull/2432>
<mup> PR snapcraft#2432 closed: CMake specific parallel option <Created by deinok> <Closed by deinok> <https://github.com/snapcore/snapcraft/pull/2432>
<mup> PR snapcraft#2433 opened: Clone single branch and clone with "--recurse-submodules" <Created by deinok> <https://github.com/snapcore/snapcraft/pull/2433>
<antis> Hey, happy new year first! I am pretty new to the Snap world and trying to package a QML "app". So it utilizes CMake and C++â¦ and Qt. And the plugin seems dated and I am not too fond of the idea eitherâ¦ Is it possible to make my snap maybe depend on another snap that provides the "right" Qt runtime (5.12 in my case)? Primary target are Debian desktops btw.
<Shapeshifter> Hi. I run nextcloud as a snap application. It includes a service that renews letsencrypt certificates. I had closed a port accidentally and that service failed. I fixed the issue. How can I now restart that service or scheduler or whatever it is? I strongly assume that this is it: /bin/sh /snap/nextcloud/10314/bin/renew-certs And in journalctl it logs as 'nextcloud.renew-certs'.
<Shapeshifter> nvm, I figured it out: systemctl restart snap.nextcloud.renew-certs
<antis> Shapeshifter, LOL
<antis> How can I use libraries from the host system during the build process?
#snappy 2019-01-02
<vidal72[m]> uhm, I just found that firefox snap is a copy of firefox generic tarball, #lazyzilla :(
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#5982, snapd#6016, snapd#6025, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6243, snapd#6252, snapd#6258,
<mup> snapd#6270, snapd#6280, snapd#6281, snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6323
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#5982, snapd#6016, snapd#6025, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6243, snapd#6252, snapd#6258,
<mup> snapd#6270, snapd#6280, snapd#6281, snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6323
#snappy 2019-01-03
<phoenix_firebrd> Is signal-desktop secure?
<phoenix_firebrd> I mean is signal-desktop snap package secure?
<phoenix_firebrd> I have installed signal app on my android mobile to handle sms also, now I would like to use the signal app on desktop too and sync between the mobile client and the desktop one, so is the snap package of signal desktop  app safe?
<phoenix_firebrd>  I have doubts because in the android play store the app is provided by signal foundation,  but the snap package is by Snapcrafters
<Son_Goku> JamieBennett, niemeyer, zyga: I don't recall if I've said this in here before, but snapd is now available in Fedora EPEL for all EL7 distributions
<niemeyer> Son_Goku: \o/
<niemeyer> Son_Goku: Happy new year!
<Son_Goku> happy new year to you too
<niemeyer> Son_Goku: Thanks
 * Son_Goku is tired
<niemeyer> Son_Goku: People are still off this week.. activities kick off on Monday
<Son_Goku> ah
<Son_Goku> I guess that's why no one noticed that it's been available for two weeks now
<Son_Goku> I *was* originally going to wait until snapd 2.37 with the new selinux stuff
<Son_Goku> but when the notice about 2.37 being delayed went out, I figured I might as well
<niemeyer> Son_Goku: Yeah, that's super cool, thanks so much for working on this
<Son_Goku> and now that dnf is in el7, we can make base snaps of centos7 and fedora
<Son_Goku> though fedora base snaps will be smaller given the higher degree of modularization
<popey> \o/
<Son_Goku> now snapcraft just needs an rpm+dnf backend
<popey> does https://docs.snapcraft.io/installing-snapd/6735 and https://docs.snapcraft.io/installing-snap-on-fedora/6755 need updating as a result?
<Son_Goku> you'll need a separate page for RHEL/CentOS
<Son_Goku> popey: https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310/11?u=conan_kudo
<Son_Goku> RHEL/CentOS 7.6 or later is required
<Son_Goku> Amazon Linux 2 will become compatible once they merge in the 7.6 SELinux update
<popey> ok
<popey> we can deal with that when we're back next week, thanks
#snappy 2019-01-04
<sborovkov> Hi, what interface do I need to allow this? "Could not create AF_NETLINK socket (Permission denied)"
<mup> PR snapd#6324 opened: Fixing socket permissions on 4.15 kernels  <Created by kubiko> <https://github.com/snapcore/snapd/pull/6324>
<mup> PR snapd#6325 opened: Allowing avahi-observer/control slots from app snap also on classic <Created by kubiko> <https://github.com/snapcore/snapd/pull/6325>
<mup> PR snapd#6326 opened: interface: raw-usb: Adding ttyACM[0-9]* <Created by kubiko> <https://github.com/snapcore/snapd/pull/6326>
<mup> PR snapd#6327 opened: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327>
<om26er> ogra, around ?
<om26er> Seems UbuntuCore18 on RPi3 won't boot: https://forum.snapcraft.io/t/ubuntu-core-18-on-raspberry-pi-3-doesnt-bootstrap/9304
<om26er> Whats up with build.snapcraft.io -- seems armhf builders are busy. And I thought everyone was on holidays ;-)
<popey> Yeah, it is a little busy
<popey> Looks like a test-rebuild is eating them all
<popey> https://launchpad.net/builders
<om26er> hmm, can we build armhf snaps on arm64 systems popey ?
<popey> you can build them on a pi
<om26er> ,
<om26er> that would be slow
<om26er> lxd on the pi and build snap inside a container ?
<popey> more reliable than cross building in my experience :)
<om26er> scaleway offers arm64, need to find a PaaS that offers armhf
<popey> I think there's a few
#snappy 2019-12-30
<bdx> I would also like to reserve "slurmdbd" and "slurmd" if possible
<cjwatson> bdx: this isn't my area, but this sort of request on IRC is likely to get lost and I think people who process them always redirect people to the forum instead (see the channel topic)
#snappy 2019-12-31
<bdx> cjwatson: thanks!
#snappy 2020-01-01
<sdhd-sascha> hey, if so, then - happy new year :-)
<mup> PR snapcraft#2851 opened: .travis.yml Test Docker build <Created by abitrolly> <https://github.com/snapcore/snapcraft/pull/2851>
#snappy 2020-01-02
<sdhd-sascha> hi :-) i want to build a new kernel and a gadget to build a custom ubuntu-core. Where can i found the snapcraft.yaml for the kernel and gadget?
<sdhd-sascha> A kernel example i already found here: https://github.com/ogra1/linux-generic-allwinner/blob/master/snap/snapcraft.yaml
<sdhd-sascha> Now i have found an example of a gadget, too :-)
#snappy 2020-01-03
<currybullen> i installed a snap application called caprine (a chat client) on fedora. do i need to do something with snapd to be able to open links i click on in caprine in my web browser?
<cowsay_> hey.. I'm using the vs code snap in classic confinement.  I'm trying to edit a site that I have mounted via webdav.  It gets mounted to "/run/user/1000/gvfs/dav:host=neocities.org,ssl=true,prefix=%2Fwebdav" and vscode throws the error "cannot open path of the current working directory: Permission denied".  I believe this is due to the confinement preventing access to /run.  is there any way to circumvent this or force it to allow access to specific
<cowsay_> locations?
<cowsay_> nevermind, i worked around it by using davfs2 instead of the Nautilus plugin (I guess??) and mounting manually to /media instead
<ogra> cowsay_, yeah, gvfs is still an issue, see https://forum.snapcraft.io/t/difficulty-viewing-mounted-fileystems-via-samba-nfs-gvfs-interface/14680
<sdhd-sascha> ogra: can i sometimes ask you some questions about the rpi4 - kernel, gadget and core image ? here i have two arm cortex boards and want to build an ubuntu image for it ? They are rockchip and amlogic.
<sdhd-sascha> i wonder where the ubuntu-eoan/debian.raspi2/abi/5.3..../arm64/raspi2* files come from ?
<ogra> sdhd-sascha, from the kernel team :) it is one of the multiple snippets the debian package build creates its config from ... if you dont build for RPi i wouldnt care about it though ...
<sdhd-sascha> Thank you. I just copied and renamed the generic from arm for now
<ogra> sdhd-sascha, you dont need to copy anything ... just using "kconfigflavour: generic" in snapcraft.yaml is enough ... then you can use "kconfigs:" to override certain settings as needed
<sdhd-sascha> ogra: i already start building the kernel. And as next step. I want to figure out, where to modify the kconfigflavour. I started with your raspi2 snap
<sdhd-sascha> currently i have `kconfigflavour: rk3318`. But i think the build will now fail, because i don't know where the flavour comes from. I cloned the "debian.raspi2" directory to "debian.rk3318/"
<ogra> alternatively you can use upstream defconfigs like i do in https://github.com/ogra1/linux-multi-v7-snap/blob/master/snap/snapcraft.yaml#L31 ... with the patches from line 39 (https://github.com/ogra1/linux-multi-v7-snap/blob/master/patches/configs.patch)
<ogra> (thats a rockchip 32bit kernel btw)
<sdhd-sascha> really 32bit ? Oo
<ogra> yeah, arm64 on boards with less than (or equa to) 4GB ram is wasteful nonsense IMHO :) (others disaree :) )
<ogra> *disagree
<sdhd-sascha> ok, that's a good point. I didn't thought about the ram
<sdhd-sascha> :-)
<ogra> (arm64 binaries allocate nearly twice the amount of ram for no benefit)
<sdhd-sascha> oh
<sdhd-sascha> then i will change it back to "armhf"
<ogra> i.e. the core16 image on a dragonboard consumes ~90MB for the idling OS ... vs ~40MB on a rpi
<sdhd-sascha> u-boot i will took from here: https://github.com/rockchip-linux/u-boot
<ogra> (dragonboard runs wpa-supplicant by default thats accoutable for the extra10MB over doubling it i assume)
<sdhd-sascha> ok - i hope one of the boards will work. The other one is a amlogic S912
<ogra> for a rockchip 32bit one i have https://github.com/ogra1/tinkerboard-gadget ... for 64bit there is https://github.com/ogra1/rock64-gadget
<sdhd-sascha> wow, i didn't found this. thank you :-)
<sdhd-sascha> from one device i found the dtb and dtbo. I know, i can decompile the dtb? But what should i do with the overlay ?
<ogra> nothing for the start :)
<ogra> i assume you have seen https://ograblog.wordpress.com/2017/06/13/patching-u-boot-for-use-in-an-ubuntu-core-gadget-snap/ and https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ ?
<ogra> (old but should mostly still work fine)
<sdhd-sascha> thank you. Some months ago, i already experimented with rpi4 dtb and dtbo. But can't remember today :-D
<ogra> rpi is special ...
<ogra> thanks to the proprietary bootoader
<sdhd-sascha>  yes. we want uefi ;-)
<ogra> try to ignore it if you buuild something that supports plain ubot
<sdhd-sascha> Here is the thread for the rpi4 netboot stuff. https://www.mail-archive.com/u-boot@lists.denx.de/msg351580.html
<sdhd-sascha> Sometime i want to test netboot on rpi4 with u-boot. Without u-boot it works good.
<ogra> oh, thats quite some work ... i started working on that once before i changed teams ... take a look at alexander garfs work  https://www.raspberrypi.org/forums/viewtopic.php?t=169982
<ogra> *graf's
<ogra> netboot work work with core without some massive changes to the initrd scripts
<sdhd-sascha> Yes, in the past, i could boot rpi4 kernel and ubuntu root on nfs
<ogra> sure, you can still do that easily with a classic ubuntu server image
<sdhd-sascha> Did you work today or are you free ?
<ogra> but the initrd scripts of core make a lot of assumptions and do a very special mount setup to achieve writable dirs on top of a readonly squashfs that in turn lives on the writable partition (there are several loops involved in the mount process)
<ogra> i'm off til mondy like most of canonical :)
<ogra> *monday
<sdhd-sascha> nice :-)
<ogra> (the company officially shuts down from christmas to new year for two weeks)
<sdhd-sascha> i read about that, on the forum :-)
<ogra> yeap
<sdhd-sascha> I'm still looking for the right job. that's why I'm currently fill my knowledge gaps
<ogra> well, i assume you saw https://canonical.com/careers/all-vacancies already then :)
<sdhd-sascha> Yes ! :-) 6 or 7 years ago, i already wrote to canonical
<sdhd-sascha> didn't get an answer. So i think i need to become better first
 * ogra needs to go AFK again ... back later ...
#snappy 2020-01-04
<sdhd-sascha> ogra: From which team to which team did you switch? what did you do there?
<sdhd-sascha> Does anybody know's this error, on building a kernel with snapcraft: `Failed to generate snap metadata: 'adopt-info' refers to part 'kernel', but that part is lacking the 'parse-info' property.`
<sdhd-sascha> Already compared the yaml with others on github.
#snappy 2020-01-05
<sdhd-sascha> Really need to setup my own snapstore. The review process isn't very productive for development.
<noise][> sdhd-sascha: I'd like to hear your feedback on the pain points so we can improve
<sdhd-sascha> hey, noise][ . Of course . i will answer tomorrow in more detail. The timing is bad for ci/cd
<sdhd-sascha> noise][: when you're testing something. and then you have to wait until the build process is done. I really wish that a maximum of 3 or 4 tasks have to be done and nothing more remains.  nobody can do avoid the review process ;-) I like the security benefit !!!
<sdhd-sascha> Would be nice, to say, i want to build only 10 or 30 things per week, without publize them
<sdhd-sascha> publicize
<sdhd-sascha> it's super nice, to have a ci/cd like snapcraft ;-)
<sdhd-sascha> noise][: it's because anybody needs to learn firstly. But not anybody has the hardware or the time ...
<sdhd-sascha> today i want to build an core ubuntu-image. But couldn't proceed, because my kernel and my gadget wasn't finished. Locally my kernel and gadget has success. But to build my core-image i had to wait.
<sdhd-sascha> Hope, that i can help near future.
<sdhd-sascha> in
<sdhd-sascha> Hmm, just waiting, for my IO to delete files :-(( Hope i can install ceph soon, and upgrade the network
<sdhd-sascha> and before the pension buy a oscilloscope
<sdhd-sascha> for speed measurement
<sdhd-sascha> :-)
<sdhd-sascha> Many many years ago, if you do two things on a win xp. The two things were... Increase the process to realtime, then increase the current thread to realtime... then the mouse didn't hear ... the harddisk didn't store... the screen only draw's if you say drawing
<sdhd-sascha> At the same time i read books about system-programming, and didn't understand how user-space programs can do this !
