#snappy 2016-02-01
<blr> is there a way to use 'stage-packages' in isolation, i.e. I just want a 1-1 packaging of something already in the archive?
<vir17> what are the available "plugins" for the yaml file?
<dholbach> good morning
<fgimenez> good morning
<sturmflut> Good morning! Just out of curiosity: If I were to build my own self-hosted distribution based on Snappy Ubuntu Core, how would I do that?
<noizer> Hi an short question.
<noizer> i set some filesets into my part of the yaml file but they wont copy it to the part dir when im building my applicaiton
<noizer> kyrofa_ Hi have question about the yaml file. I want to snap an python application but do you have a good example how i need to work to get the job done
<JamesTait> Good morning all!  Happy Monday, and happy Freedom Day! ð
<noizer> Good morning :D
<ogra_`> mvo, if you do "Chroot chroot "foo" >chroot/foo.txt then your later commands that run outside the chroot would need to use chroot/chroot/foo.txt (assuming the first command actually creates the dir )
<ogra_`> ;)
<ogra_`> hmm, or not :P
<ogra_`> ignore that
<mvo> ogra_`: I'm confused, aha, ok
<ogra_`> trying to decypher the vivid build failures
<ogra_> ah, but i wasnt to wrong :)
<ogra_> we cd into the chroot dir before you try to cp from chroot/...
 * ogra_ fixes
<noizer> ogra_ Hi. just a short question im making an python application but what is the best way to copy alle the necessary files to a snap?
<ogra_> noizer, http://paste.ubuntu.com/14848777/ that will get you a basic python interpreter installation
<noizer> I understand that but the code how do I copy the files or does i neet to make a setup.py just lik pypi
<ogra_> noizer, how about that http://paste.ubuntu.com/14848791/
<ogra_> though i think you could also use a setup.py
<ogra_> but i'd have to refer to the examples for that, never did that
<noizer> ok can i copy a complete directory at one line?
<ogra_> sure
<ogra_> (at least in snapcraft 2.0 ... )
<noizer> yea im using snapcraft 2.0
<noizer> is the syntax like that ?:
<noizer> ?
<noizer> that:      /dir/ : bin/destinationdir/
<ogra_> drop a few slashes :)
<ogra_> http://paste.ubuntu.com/14848805/
<ogra_> that would copy opt from my snap dir into the package
<noizer> ogra_ thx for the help and the fast support all the time :D
<ogra_> :)
<ogra_> mvo, vivid rebuild running (FYI)
<mvo> ogra_: yay, thanks
<ogra_> ppisati, so for our dt problem on dragonboard ... i was wondering how hard it would be for you to cp it to apq8016-sbc-sdcard-boot.dtsi and add the one line patch, so we can use the sdcard version in snappy
<ogra_> (i suspect fixing the little-kernel to initialize the controller differently will cause boot issues)
<ppisati> ogra_: actually i'm chainloading uboot after LK
<ppisati> ogra_: but probably mine is slightly more recent
<ppisati> ogra_: look, i'm debugging a race in the wifi init
<ogra_> ppisati, where did you get the lk ?
<ppisati> ogra_: and if everything goes well i'll push another update out today
<ppisati> ogra_: hold on
<kyrofa> Good morning
<ppisati> ogra_: http://pastebin.ubuntu.com/14849122/
<ogra_> ppisati, hmm, i see you are using a newer u-boot ...
<ogra_> where did you get the lk though ?
<ogra_> i wonder why your alsa is messed up ... are you using the right DT ?
 * ogra_ had alsa only fail with the msm8916-mtp file
<asac> martintrojer_: hi!
<ppisati> ogra_: it's all your stuff
<ogra_> oh
<ppisati> ogra_: i compiled a new uboot to add bootz support
<ppisati> ogra_: and i'm using this dtb
<ogra_> hmm, my uboot should have that
<ppisati> ogra_: apq8016-sbc.dtb
<martintrojer_> asac: 'lo
<ppisati> ogra_: i'm going out for lunch, i can publish my uboot somewhere if you want
<ogra_> ppisati, yeah, thats the correct one.... why do i see the mmc1 init error then ... weird
<ogra_> ppisati, only the patch ... here is mine http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch
<ogra_> oh
<ogra_> seems you are right, bootz isnt set there
<ogra_> oh, wait ... because amr64 uses a special boot command
<ogra_> right
<ppisati> ogra_: sorry, can't find my patch ATM
<ogra_> booti
<ppisati> ogra_: here is the binary
<ppisati> ogra_: http://people.canonical.com/~ppisati/dboard_uboot/u-boot.img
<ogra_>  booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_add}
<ppisati> ogra_: i'm they just fixed it upstream
<ppisati> ogra_: i'm not using initrd either
<ogra_> turning booti into bootz ?
<ogra_> well, the initrd shouldnt have any influence regarding the mmc1 init error i would think
<ppisati> ogra_: no,. i was wrong
<ppisati> ogra_: i'm still using booti
<ppisati> ogra_: it's probably just the updated version then
<ogra_> ok, i'll check that
<ogra_> would be good to get along without patched DT
 * ppisati disappears for a bit
<ogra_> mvo, do you have your all-snap build scripts somewhere ?
<mvo> ogra_:  lp:~mvo/snappy/mksnap-os-kernel
<ogra_> thx
<mvo> ogra_: you probably need more stuff though, os snap, gadget snap
<ogra_> yeah
<mvo> ogra_: I can push you the ones I used for the previous image
<ogra_> cool, thanks
<mvo> ogra_: one sec, meeting right now
<ogra_> no hurry
<sergiusens> kyrofa, I made a better change https://github.com/ubuntu-core/snapcraft/pull/285/files
<kyrofa> sergiusens, ah, just move it down?
<kyrofa> sergiusens, good idea
<kyrofa> sergiusens, though honestly, I refactored that in my PR anyway... what if I just move it down?
<kyrofa> sergiusens, otherwise it'll just conflict
<kyrofa> sergiusens, ha! Actually, I already did
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/283/files#diff-0d5dc26743422dade0478e577247a141R124
<kyrofa> niemeyer, sorry it took so long, but I managed to document the application launching process here: https://docs.google.com/document/d/1eaXHeFMEKMoWKFjmr5XMOW1vLywCjzoXd5SNJOUi_GE
<kyrofa> niemeyer, mvo kindly filled in the u-c-l details (thanks mvo!)
<noizer> ogra_ Hi i just installed nginx in my snap but does i need to make a service of it or not?
<noizer> to get nginx started
<sergiusens> kyrofa, sure
<kyrofa> sergiusens, I have another STAGE_DIRECTORY-like suggestion: the source location when building the part. This particularly applies to the cmake plugin, which does an out-of-source build (as it should be, of course)
<kyrofa> sergiusens, but when configuring e.g. mysql, if I want to use things included in the src I need to say -DWITH_X=path/to/src/X-dir
<noizer> kyrofa can you look a moment to my question that i asked to ogra_ i think he is afk
<kyrofa> noizer, yes, any service you want to run within your .snap must be declared as such
<niemeyer> kyrofa: Thanks, let's talk this afternoon.. I need to step out to have lunch as we have the weekly Snappy meeting in a few minutes
<kyrofa> niemeyer, no problem :)
<noizer> kyrofa ok thx for the answer
<ppisati> ogra_: i'm building a new kernel for the dboard410c, it contains a couple of fixes (one for ethernet on usb dongle and another for a wifi init race)
<ppisati> ogra_: as soon as it's done i'll delete the previous one
<noizer> kyrofa i want to remove an application but it won't work completely. here is some output: http://pastebin.com/CqZDAuxU
<kyrofa> noizer, no clue what's happening there. It looks like you were in the middle of a commit when you built the snap?
<ogra_> ppisati, ok
<noizer> kyrofa not realy
<noizer> but that was installed previously xD
<jdstrand> beuno: hi! two questions: 1) do you have any objections with me doing some big code cleanups to the review tools with the snap.yaml updates I'll be working on (think, starting fairly anew with snap.yaml) and 2) is it cool for me to force that if you are a squashfs that you must use snap.yaml?
<beuno> jdstrand, +1 and +1
<Guest5410> jdstrand, FWIW, we have tests in the store to enforce that.
 * Guest5410 sighs
<JamesTait> Finally!
<JamesTait> jdstrand, while you're working on that, IIUC readme.md is no longer required (instead we take the summary and description properties from snap.yaml).
<JamesTait> mvo and/or sergiusens - feel free to correct me. ð
<sergiusens> JamesTait, jdstrand that is indeed correct
<sergiusens> jdstrand, I say +1 to squashfs implies snap.yaml (but not too tightly coupled in the code)
<jdstrand> JamesTait: yes-- I will be using the snap.yaml spec to implement this
<jdstrand> sergiusens: re coupling-- well, no more so than it already is. we said squashfs signifies 16.04. basically, I'd like to say no package.yaml in 16.04 as well right away if I can get away with that
<JamesTait> jdstrand, I assumed as much, just wanted to make sure it was on your radar. ð
<jdstrand> JamesTait: appreciated :)
<mvo> jdstrand: +1 for now package.yaml in 16.04
<sergiusens> jdstrand, right, just thinking about 16.10 and squashfs having a different snap.yaml
<beuno> there will be no 16.10!
<beuno> rolling until 18.04!
<sergiusens> beuno, well, rolling
<noizer> kyrofa what did I wrong. He installed flask but not tornado and yaml as library for python http://pastebin.com/xiXE78Sm
<kyrofa> noizer, huh?
<kyrofa> noizer, I don't see a problem there-- what went wrong?
<noizer> when im installing my application and then i look in my site-packages there isn't tornado installed
<noizer> :s
<kyrofa> noizer, do you have any errors when creating the snap?
<noizer> no
<noizer> wait i will try something again
<noizer> he is now building the snap again a moment please
<noizer> kyrofa got an error verry strange : Parts 'flask' and 'yaml' have the following file paths in common which have different contents:
<noizer> so it was an old snap file that i had installed :s
<kyrofa> noizer, please pastebin the build log
<noizer> kyrofa http://pastebin.com/fpJP1AL1
<sergiusens> elopio, should I give you time to look at https://github.com/ubuntu-core/snapcraft/pull/282 ?
<elopio> sergiusens: wow, that's big. I'm in a meeting with Federico. If you are happy with kyrofa's review, merge it.
<elopio> I'll take a look afterwards. Seemed good with my quick glance.
<sergiusens> elopio, yeah, I added lots of tests ;-)
<jdstrand> mvo: oh, btw, while I am going to focus on snap.yaml stuff first I think, I did want to let you know that with a patched squashfs I was able to verify an amd64 snap on a powerpc machine (so I'm not worried about endianess any more). need to work out a few other details, but if you were worried, don't be at this point
<noizer> kyrofa do you have any solution ps I'm using snapcraft 2.0
<elopio> fgimenez: I was trying to say that this create cloud image job doesn't take a lot of time.
<elopio> could we create one image per job, and then delete it?
<elopio> not per job, per test execution.
<fgimenez> elopio, we need to create the image, convert to qcow2 and upload to glance, less than 5min i think, but each image is valid until a new version is created
<elopio> fgimenez: right, that would be a lot of wasted resources when there are no changes.
<elopio> ok, lets figure out how to subscribe to new versions.
<elopio> fgimenez: do you know if there's a good plugin for jenkins that keeps polling?
<fgimenez> elopio, yes urltrigger, we are using it for the image creation jobs
<fgimenez> elopio, https://wiki.jenkins-ci.org/display/JENKINS/URLTrigger+Plugin
<noizer> kyrofa the error is at line 592
<elopio> fgimenez: great, it lets you even check the json response. I'll use it.
<kyrofa> noizer, ah, it seems that's bug #1531570
<ubottu> bug 1531570 in Snapcraft "Can't have two python3 parts using setuptools" [Undecided,New] https://launchpad.net/bugs/1531570
<noizer> kyrofa is there an solution for that?
<kyrofa> noizer, you can work around it as I mentioned in the comment, or you can try putting them all in one part using requirements.txt perhaps?
<noizer> kyrofa or install them manualy in an other os and copy them to the correct dir
<kyrofa> noizer, you might try the requirements.txt first, if that works for you
<noizer> kyrofa is there an example of that?
<kyrofa> noizer, not in snapcraft, it's a pip thing
<kyrofa> noizer, https://pip.readthedocs.org/en/1.1/requirements.html might be helpful
<pindonga> kyrofa, re: proper login on snapcraft... I just became aware snappy itself has login support as well
<pindonga> so I think you should attempt to mimick what's being done there
<pindonga> looked at the code and looks quite right to me
<kyrofa> pindonga, regarding the OTP etc.?
<pindonga> yes
<kyrofa> pindonga, excellent, we'll check it out! Thank you :)
<elopio> fgimenez: https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical
<pindonga> kyrofa, it might even make sense trying to read the config file written by snappy (so to avoid having multiple config files)
<kyrofa> pindonga, without having looked at it, why does snappy have a login option?
<pindonga> kyrofa, there are certain use cases that need it, eg downloading private packages
<kyrofa> pindonga, ahh
<kyrofa> pindonga, that makes sense then
<fgimenez> elopio, great! thx, that's all we need, the only thing missing is the version string to assign to the image, it should be compatible with our current schema (plain numbers from system-image) and the schema from official images (dates as in 20160129)
<lool> LefterisJP: hey!
<elopio> fgimenez: if we are listening to the three snaps, why don't we just use a timestamp?
<elopio> I mean one timestamp.
<LefterisJP> lool: hey :)
<fgimenez> elopio, we need to be able to know from snappy-cloud-image if we need to create a new image, we need some hint in the latest image name to be able to compare with the info from the snaps
<fgimenez> elopio, now the source is system-image, and the cloud images have the same version number that the images have there, so we can easily compare both
<elopio> fgimenez: but system-image is going away. So, we put three url triggers, one for each snap. When anyone fires, we create a new image, and put a timestamp on it.
<elopio> I might be missing something of course, because I don't get why we need to compare.
<fgimenez> elopio, yes, we could rely in the external trigger, now we are using it just for preventing the jobs to be executed by cron, the job itself checks again if we should create the instance or not
<elopio> fgimenez: got it. Well, I won't mind to collect the three versions and build a name from that. Whatever you prefer.
<mvo> jdstrand: \o/ thanks, that is great news
<elopio> fgimenez: last thing I wanted to talk today is about gocheck.
<jdstrand> np
<elopio> fgimenez: let's see how niemeyer resolves it, and if there's no progress at the end of the week I can propose again the ugly hack to get the list command for plars and team.
<fgimenez> elopio, ok, let me know if you need any help with that
<elopio> fgimenez: well, if you have a better implementation in mind and want to give it a go sending it upstream, I won't stop you. I wouldn't ask that of you either :)
<beuno> JamesTait, so, are you changing crt to not require readme.md for 16.04 snaps?
<sergiusens> beuno, mvo just triple confirming; I can land skills for snapcraft? Is there an OS already built?
<sergiusens> built/uploaded to the store
<JamesTait> beuno, I can do, if it won't interfere with what jdstrand is working on.
<beuno> sergiusens, I don't know. Will it affect the store in any way?
<sergiusens> beuno, well; only in the sense that everything might be denied or marked invalid
<beuno> sergiusens, if you get me a snap built with skills, I can run it through and check for you
<sergiusens> beuno, sounds good
<beuno> sergiusens, in all likelyhood, it'll be click-reviewers-tools
<beuno> so you can easily check locally as well
<jdstrand> JamesTait (and beuno): it would be incorporated in my larger work. if needed, JamesTait or I can make a quick change
<JamesTait> jdstrand, I realise it's still early days, but do you have a sense of ETA for the rework yet?
<jdstrand> sergiusens, beuno: I can say for sure the review tools won't like it
<jdstrand> JamesTait: I imagine this week. I am wholly focused on it
<JamesTait> Ack, thanks.
<sergiusens> jdstrand, if the error does not prevent manually putting into the store I'm fine
<sergiusens> putting/approving
<jdstrand> sergiusens: it would be no worse than other squashfs. if you give me a snap I can make super sure for you
<sergiusens> jdstrand, k, thanks
<JamesTait> jdstrand, just an additional heads-up: we've been discussing in OLS "outsourcing" the package metadata extraction wholly to click-reviewers-tools and having it return metadata in a standardised format, rather than having the whole click/snappy1.0/snappy2.0 detection logic in the store as well.
<JamesTait> jdstrand, letting you know just in case it's a really bad idea or makes things much more difficult.
<jdstrand> JamesTait: so, you give a snap to the review tools in some way, and it spits back something the store can consume?
<JamesTait> jdstrand, exactly.
<jdstrand> JamesTait: I think that is a really good idea
<jdstrand> keep this stuff in one place
<JamesTait> Excellent. âº
<JamesTait> I'll find out whose idea it was and route karma/beers appropriately. ð
<jdstrand> I imagine the review tools side would loop back to me (which is fine)
<mvo> sergiusens: there is no updated OS snap in the store yet but I will upload one now that the store is open
<sergiusens> mvo, great; do we have the opening/closing hours for the store? I hope it is not like the starbucks photo ogra_ posted on g+ :-) https://plus.google.com/+OliverGrawert/posts/fje7cEH4oa2
<ogra_> haha
<ogra_> wow
<ogra_> i just wiped the .ics files from my phone and clicked "sync" in the calendar app ....
 * ogra_ guesses he shouldnt recommend doing that to anyone .... flushed my whole gcal at google :P
<wigglewo1> Does anyone know of there are email posted somewhere that say snappy updates are available?
<wigglewo1> posted or emailed to general public
<ogra_> what kind of updates ?
<ogra_> to the snappy binary ?
<ogra_> (OS updates happen automatically on all images that are supported)
<ogra_> updates to the stable images are usually announced on the snappy-devel mailing list after they went out
<wigglewo1> i know that but if the automatic updates are diabled then how does one find out about updates?
<ogra_> well, if you run stable you m8ight want to follow that ML
<wigglewo1> what is ML
<ogra_> if you use any rolling channel ... well, you should check regulary by simply running "sudo snappy update ubuntu-core"
<ogra_> mailing list
<wigglewo1> thanks where do i find the mailing list
<ogra_> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
<wigglewo1> thank you
<ogra_> :)
<wigglewo1> are you familiar with apticron? and does that work differently?
<ogra_> no, never heard of apticron
<wigglewo1> ok thanks
<kyrofa> elopio, regarding the INFOs from requests-- are you suggesting I move that line into log.py? Or do something different altogether?
<elopio> kyrofa: yes, you can put this:
<elopio> logging.getLogger("requests").setLevel(logging.WARNING)
<elopio> in the log.configure.
<kyrofa> elopio, ah, that will be much nicer, I'm glad you caught that. I've never noticed log.py before, heh
<sergiusens> JamesTait, beuno jdstrand http://people.canonical.com/~sergiusens/snappy/shout_0.52.0_amd64.snap there's a skills snap
<JamesTait> Handy, thanks sergiusens!
<sergiusens> elopio, have time for a quick hangout?
<Chipaca> pitti, got a systemd ordering/dependency question for you
<Chipaca> pitti, when would be a good time?
<elopio> sergiusens: sure. I have a sore throat, so if it's not quick, we'll have to come back to text chatting. Snapcraft daily channel?
<sergiusens> elopio, yeah
<sergiusens> elopio, well this https://plus.google.com/hangouts/_/canonical.com/snapcraft
<Chipaca> pitti, basically we have a bunch of services depending on a target, and that target can take arbitrarily long to load. the services are being wanted by multi-user, but we don't want to block multi-user on these
<pitti> Chipaca: just ask, that's easier :) (drive-by, dinner now, but will come back for a bit later tonight)
<pitti> Chipaca: well, that sounds like a circular dependency then -- you must break it somewhere :)
<pitti> Chipaca: without knowing any details, conceptually they probably shouldn't be wanted by multi-user then?
<Chipaca> pitti, ah, maybe i didn't explain properly. go have dinner, i'll try to explain better in a bit
<jdstrand> sergiusens (fyi beuno and JamesTait): this is what the store should see with the skills snap: http://paste.ubuntu.com/14850654/. so 'yes' no worse than squashfs, readme.md, etc
<sergiusens> jdstrand, that's good enough for me.
<jdstrand> sergiusens: the review tools in the archive is oddly a little more grumpy with that over a snapcraft 2.0.1 build snap
<sergiusens> jdstrand, probably because 2.0.1 includes a package.yaml and readme.md for backwards compat; but already uses 'apps' instead of "services" and "binaries"
<jdstrand> sergiusens: don't you run the review tools automatically? if so, I should figure that out now and update the archive
<jdstrand> oh yes, that would make sense
<jdstrand> if no package.yaml, it will think it is a click
<jdstrand> ok, let me look at that MP from earlier today and upload that to xenial
<jdstrand> sergiusens: go ahead with your merge/landing/etc
<sergiusens> mvo, did you push already; or asked differently; does `snappy update` work on amd64?
<sergiusens> jdstrand, thanks, just waiting on OS support to make sure all the pieces work :-)
<noizer> kyrofa Is it possible to enter the container to test some things?
<kyrofa> sergiusens, should I --include-binaries in the copy-package?
<kyrofa> sergiusens, not super clear on what that does :P
<kyrofa> noizer, what container?
<noizer> the snap so i can do some python scripting for do some test
<noizer> kyrofa
<kyrofa> noizer, running xenial (rolling), right?
<noizer> kyrofa yes
<sergiusens> kyrofa, yes you should
<kyrofa> noizer, so first of all, the word "container" indicates something at least somewhat virtualized, e.g. lxc, etc. Snaps don't run in a container, they're just very confined. But to actually answer your question, there's no way to modify the squashfs mount, so you'd need to make some overlayfs games to do that
<kyrofa> s/need to make/need to play/
<kyrofa> sergiusens, otherwise it'd what... grab the source package only?
<sergiusens> kyrofa, yeah, and rebuild
<kyrofa> sergiusens, very good
<Chipaca> kyrofa, maybe 'snappy shell' is what noizer is looking for?
<kyrofa> Chipaca, perhaps, I don't have any experience with it (it doesn't show up as an option for me, must be new?)
<ogra_> sudo snappy enable-classic
<ogra_> snappy shell classic
<ogra_> ;)
<kyrofa> Ohh
<Chipaca> yes, but, snappy shell potato
<Chipaca> gives you a shell in the security context of potato
<kyrofa> Chipaca, interesting. But you still can't modify the install snap, right?
<kyrofa> installed*
<Chipaca> right. But you can 'try some things'
<kyrofa> Chipaca, hey, I learned something new. Thanks for that!
<ogra_> you can also spt-get install snapcraft ;)
<ogra_> and build your snaps in there
<Chipaca> ssh, don't tell people about spt-get yet
<ogra_> *apt
<ogra_> haha
<kyrofa> ogra_, yeah I've used classic, I just didn't realize snappy shell was a more generic command
<Chipaca> pitti, so: snappy-wait4network.service is a oneshot that runs and just waits for network. If a snap is installed that has a service with an external port, then that service is made to come after wait4network, and wanted by multi-user. If network never comes up, multi-user is never reached.
<Chipaca> pitti, that last little detail is purportedly a bug :-)
<Chipaca> pitti, basically we want the whole tree under wait4network to be "ignored", as far as reaching multi-user is concerned
<ogra_> well, you want loopback
<Chipaca> wait4network waits for a route
<ogra_> is that blocked by that service too ?
<ogra_> ah
<ogra_> right, thats the one that never finishes if we have auto in /e/n/i with no network cable attached
<Chipaca> and a snap with a service with an external port installed
<ogra_> does systemd not provide a simply way for timingt out a job ?
<ogra_> *simple
<ogra_> (like a timeout option :) ))
<Chipaca> yes
<Chipaca> but we don't want it to timeout
<Chipaca> (and it'd be in the minutes, this timeout)
<ogra_> hmm
<ogra_> what if i have a service i want to use through loopback only ? i suppose it would wait forever if there is no real network then ?=
<ogra_> (if assigning a port also makes it depend on that service file)
<Chipaca> ogra_, then you don't define an external port for it
<Chipaca> ogra_, there are internal ports
<ogra_> oh, i thought they were dropped
<Chipaca> they will be, once we move to caps
<ogra_> right
<Chipaca> the problem will remain :-)
<ogra_> indeed :)
<sergiusens> jdstrand, fwiw, the store accepted my app (failed reviews though)  https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/4/
<Chipaca> ogra_, hence head scratching, and pitti invoking
<ogra_> yeah
<Chipaca> i'd go ask in #systemd but last time i went they said we should have systemd in initrd
<Chipaca> which i agree on in principle, but in practice i'm not in a hurry to get there
<sergiusens> ogra_, kyrofa, Chipaca what noizer want is the yet to be made snappy try
<ogra_> yeah,
<kyrofa> sergiusens, yeah, I did know that one :P
<Chipaca> sergiusens, the tricky bit is the snappy except
<Chipaca> i'll let myself out
<kyrofa> Chipaca, the finally is really terrible
<sergiusens> Chipaca, because it should be catch? :-)
<jdstrand> sergiusens: cool. do you need me to accept it?
<sergiusens> jdstrand, if you want to, sure (it's the same snap, except I uploaded with the to be release snapcraft upload command)
<sergiusens> *d
 * sergiusens is still waiting for ubuntu-core to finish downloading
<Chipaca> sergiusens, kyrofa, i think we all should get each other big "NERD" mugs
<kyrofa> Hahaha
<ogra_> you dont have one yet ?!?
<jdstrand> sergiusens: if you request a manual review, I'll approve it
<jdstrand> sergiusens: fyi, uploaded review tools 0.36 to xenial so it won't be so grumpy
<sergiusens> jdstrand, :-)
<sergiusens> jdstrand, we plan on releasing snapcraft 2.1 today as well
<sergiusens> jdstrand, and this is our next milestone fwiw https://launchpad.net/snapcraft/+milestone/2.2
<jdstrand> sergiusens: cool
<jdstrand> sergiusens: fyi, accepted
<sergiusens> mvo, updating does not work in rolling in case it was unknown to you
<kyrofa> sergiusens, 1.0.1 release went smoothly. Thanks for answering my questions :)
<sergiusens> kyrofa, nice
<kyrofa> sergiusens, is https://github.com/ubuntu-core/snapcraft/pull/283 good to go, then?
<sergiusens> kyrofa, I am just missing a live upload; unless you have tried that yourself
<sergiusens> I will trust you ;-)
<kyrofa> sergiusens, only to staging
<kyrofa> sergiusens, but I can do live
<sergiusens> kyrofa, that should be good enough; don't you want to try against production
<sergiusens> kyrofa, one of the examples maybe
<kyrofa> sergiusens, verified-- works great :)
<sergiusens> kyrofa, the minute I press merge, I remember I didn't check the commit message :-P
<sergiusens> kyrofa, is this mentioned https://bugs.launchpad.net/snapcraft/+bug/1539814 or should I  just dup?
<ubottu> Launchpad bug 1539814 in Snapcraft "Upload not closing resource correctly" [Medium,New]
<kyrofa> sergiusens, it is :)
<kyrofa> sergiusens, question is, did I do it right? I wasn't sure whether to do LP: #1, #2 or use two different LP lines
<kyrofa> sergiusens, I went with two
<sergiusens> kyrofa, I think you did it right
<sergiusens> kyrofa, we'll see ;-)
<kyrofa> sergiusens, gbp dch picks it up both ways, but one way it's (LP: #1, #2) and the other it's (LP: #1)(LP: #2)
<kyrofa> sergiusens, for my future reference, if I need to do something asynchronously in python, is multiprocessing better than multithreading?
<kyrofa> sergiusens, the way I solved the progress bar problem was driven completely by my experience in C++
<kyrofa> sergiusens, but your comments from earlier lead me to believe there's a better way to do that in python?
<sergiusens> kyrofa, multithreading is not that good in python; Chipaca might spank you :-P
 * kyrofa runs away from Chipaca
<sergiusens> zyga, any idea how to test if my migration-skill built snaps actually work?
<sergiusens> zyga, or can you try and see if 'shout.sergiusens' on the store works?
<zyga> sergiusens: I'll check, mvo merged this yesterday
<sergiusens> zyga, yeah, but I have no idea to know if it is doing the right thing; I copied a snappy binary over but ubuntu-core-launcher fails to aa_*
<pitti> Chipaca: re
<pitti> Chipaca: snappy-wait4network.service sounds very similar to network-online.target
<kyrofa> sergiusens, why does the ROS example have all the exclusions now
<kyrofa> ?
<pitti> Chipaca: normally multi-user.target does/should not depend on network-online.target, unless you have things like /var or /home on NFS
<pitti> Chipaca: so if you want snappy-wait4network.service to not block multi-user.target, then you can't make it an one-shot that is  "starting" forever
<kyrofa> sergiusens, I seem to remember it having to do with shebang stuff
<pitti> Chipaca: option 1 is to make it daemon-like, i. e. not "oneshot" -- then it'll just block m-u for as long as it takes to start that listening thingy
<sergiusens> kyrofa, so it doesn't conflict with what catkin brings in
<pitti> Chipaca: option 2 is to make snappy-wait4network.service WantedBy=network-online.target instead of m-u.target
<sergiusens> kyrofa, and yeah, it is related; but I eventually want to get rid of the file migration thing
<kyrofa> sergiusens, didn't we fix that with the always-link change?
<sergiusens> kyrofa, no; but we also still remove useless stuff for a snap, so it should be fine
<pitti> ogra_: sure, units time out starting/stopping by default after 90s (units can tweak or disable that, but most don't)
<kyrofa> sergiusens, ohhh, the roscore plugin......
<kyrofa> sergiusens, okay good. This'll clean up nicely then
<sergiusens> kyrofa, yeah
<elopio> I'm going to have lunch.
<elopio> sergiusens: if you look for me to give you a hand with the release and I don't reply, insist pinging on telegram. I'm not feeling so well and might end up sleeping deeply.
<elopio> bbl
<sergiusens> elopio, no worries, I'm still debating if I should merge the migration skill stuff as there isn't a working image yet
<kyrofa> sergiusens, that would indeed make it difficult to test other changes built on top of master if it merged...
<kyrofa> Chipaca, what kind of parameters does `snappy shell` accept?
<kyrofa> Chipaca, oh you're probably eating or something huh
<kyrofa> Chipaca, you can ignore me :)
<sergiusens> lol
<sergiusens> kyrofa, yeah, that is why I didn't merge it
<sergiusens> just hoping mvo can answer when he gets back
<kyrofa> sergiusens, what incantation of u-d-f will create a rolling all-snaps amd64 image nowadays? I just realized the canonistack version is too old
<sergiusens> kyrofa, welcome to my world of not knowing and being blocked most of the evening :-P
<wigglewo1> hello - looking for direction on how to publish a snap to the snappy store - are there published instructions?
<rickspencer3> wigglewo1, well ...
<rickspencer3> the web page is pretty self-explanatory, I think
<rickspencer3> wigglewo1,  have you looked at https://myapps.developer.ubuntu.com
<rickspencer3> ?
<rickspencer3> once you sign in, click on Ubuntu Core at the top
<rickspencer3> and then fill in the form
<bdmurray> My beaglebone never seems to boot snappy. I've followed the steps at https://developer.ubuntu.com/en/snappy/start/#try-beaglebone although I didn't "remove the bootloader available in the eMMC" partition.
<zyga> bdmurray: hold the user button
<zyga> bdmurray: and do remove the other bootloader as otherwise you will never boot into the SD card
<bdmurray> zyga: hold the user button during boot?
<zyga> bdmurray: yes
<zyga> bdmurray: it forces the SoC to use SD card to boot
<bdmurray> and then you use dd on the device to remove the bootloader? the instructions don't make that clear.
<zyga> bdmurray: you can do that from uboot or after snappy boots
<zyga> bdmurray: AFAIR I used uboot's command to erace the mmc
<zyga> erase*
<bdmurray> zyga: okay, thanks I'm working on a snap of some python software and when I run it on the bbb I get a bad interpreter message.
<bdmurray> https://paste.ubuntu.com/14852967/
<zyga> bdmurray: did you use snapcraft?
<zyga> bdmurray: you can use snapcraft to build a snap with python
<bdmurray> zyga: yes, i did
<zyga> bdmurray: there are existing examples that do just that in snapcraft source
<zyga> bdmurray: try building one of them and ensure it works
<zyga> bdmurray: if that doesn't work, ask sergiusens
<zyga> bdmurray: note that beagle is no longer officially supported
<zyga> bdmurray: though I bet that python won't care here, the image you might be using might be out of date
<bdmurray> its still listed at the developer portal
<zyga> bdmurray: it is supported by the community, in practice it might lag behind our officially supported platforms, especially now when we are developing at a very rapid pace
<zyga> bdmurray: I have two beagles in my office, both running snappy, though I'm using raspberry pi for my daily development now
<bdmurray> Is there a way to get snapcraft to use my local mirror?
<zyga> bdmurray: perhaps but I don't know the details, ask sergiusens
<sergiusens> bdmurray, USE_LOCAL_SOURCES=1 and python is included in the snap, you need to build on the arch you want to target
<bdmurray> sergiusens: How do you recommend building on armhf?
#snappy 2016-02-02
<sergiusens> bdmurray, on 15.04 you can snappy install lxd; on 16.04 (probably the recommended target for new dev); snappy enable-classic
<wililupy> question: Is webdm still in the Snappy store? I try to install it with sudo snappy install webdm but I get webdm failed to install: snappy package not found
<torbit> Hi guys,
<torbit> I am trying to pull down the snappy core image for i386
<torbit> I cant seem to get it
<torbit> I get a 404 on this : wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz
<torbit> unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz
<torbit> does anyone have something that I can pull publicly ?
<torbit> anyone online ?
<torbit1> Ok seems like it was something on my network . sorry
<torbit1> thanks
<dholbach> good morning
<fgimenez> good morning
<renat> Hi all! It's Renat from Screenly again=)
<renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")?
<renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section.
<renat> assign: rules: - kernel: vhciq
<renat> But it device isn't accessible because of very strict access mode.
<JamesTait> Good morning all!  Happy Tuesday, and happy Hedgehog Day! ð
<torbit> Hi folks. I need some help
<torbit> I downloaded a generic x86 image
<torbit> I would like to know what the OEM part of the docs is exactly.
<torbit> I am not getting that part very wekk
<torbit> well I mean
<kyrofa> Good morning
<torbit> good morning kyrofa
<torbit> although on my end it is afternoon . Nice sunny day in Nairobi
<kyrofa> Hello torbit :) . I'm afraid I don't know much about OEM stuff right now, other than it's a bit in flux right now between 15.04 and 16.04
<ogra_> torbit, essentially it contains the bootloader
<torbit> ogra_ : hmmmm. I see
<ogra_> amd64 is a bit special here though ... unlike the arm arches it only ships the bootloader config http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/generic-amd64/
<torbit> well in my case I am working with some intel device.
<ogra_> (grub gets simply pulled out of the rootfs when the oem snap gets put into place by ubuntu-device-flash)
<torbit> oh.
<torbit> that I did not know
<mvo_> ogra_: how is the arm64 cdimage.u.c output looking? are we getting close to soemthing that we can consume :) ? u-d-f and the store are fixed so we can move again
 * mvo_ lunch
<ogra_> mvo_, oh, not done yet +
<mvo_> ogra_: ok
<mvo_> ogra_: just curious, no real rush
<ogra_> i need to do the rpi bootloader update today, then i'll move on to cdimage
<mvo_> ogra_: at least we can move forward now again with the store fixed
<mvo_> ogra_: \o/ ok
<ogra_> yeah :)
<ogra_> mvo_, we wont be able to build arm64 until we have a kernel package in the archive though
<torbit> ogra_: hmmmm. so I guess that means I need to create the root.tar.xz?
<ogra_> ppisati said there were still bits blocking it
<torbit> am I correct in assuming  this ?
<ogra_> torbit, for wghat exactly
<torbit> ogra_: in my case I am trying to create a bootable disk to flash a device
<torbit> so use snappy core
<torbit> the device is currently using ubuntu server
<ogra_> torbit, sure, but why does the existing setup not work for you
<ppisati> ogra_: yes, the dragonboard kernel won't enter the archive as it is, until we have a multi-arm64 kernel etc
<ppisati> ogra_: for now you'll have to use my ppa
<torbit> ogra_: so this is what I did, I took the generic image , made a bootable flash with DD
<ogra_> ppisati, i doubt we want that for cdimage builds ... but i can copy it to the snappy hardware PPA i guess
<ppisati> ogra_: k
<torbit> ogra_: I plug it in an nothing .
<ppisati> ogra_: i'm writing you an email right now
<torbit> so I am not too sure what I am doing wrong to be honest
<ppisati> ogra_: with uboot etcetc
<torbit> ogra_: it is my first time
<ogra_> torbit, well, it should work on any x86 system
<ogra_> ppisati, ok, thanks !
<torbit> ogra_: tell me does this platform need to have a screen to select this image in the boot loader or does it just boot into it
<ogra_> torbit, you might want to take a look at the kernel cmdline on the created usb stick, could be that the early boot defaults to do all output to the serial console
<ogra_> it should boot straight through
<ogra_> (the first boot takes a while though, it creates ssh keys and such)
<torbit> ogra_: hmmm. oooh I see. ok one sec I try this one more time
<ogra_> is that 32 or 64bit hardware ?
<torbit> ogra_: 32 bit
<ogra_> oh
<torbit> for sure
<torbit> ogra_: it is intel chip based
<ogra_> you might need to build an i386 image manually then
<torbit> ogra_: can we DM ?
<ogra_> the generic x86 image we offer pre-built is using UEFI and a 64bit kernel to boot
<torbit> aaaaah
<noizer> kyrofa Hi my snappy just rebooted automatically and some things dont work anymore just lik i installed python on my snap but when he executes a command he doesn't find python anymore :s
<kyrofa> noizer, I can't remember-- are you on 15.04 or rolling?
<ogra_> on rolling (snapcraft 2.0 snaps ;) )
<kyrofa> noizer, hmm, can you check the shebang of the python script you're trying to run? What does it look like?
<noizer> yea on rolling
<noizer> kyrofa wait i dont use the shebang the command looks like : python file.py
<noizer> and then the error is python not found
<kyrofa> noizer, is this a daemon, or no?
<noizer> no deamon
<noizer> but when i do snappy list i don't get the core anymore so I think my snappy is broken :s
<noizer> so I will install snappy again
<beuno> kyrofa, FYI, you can now upload multiple architectures and releases
<beuno> ogra_, ^
<kyrofa> beuno, woo hoo!
<kyrofa> beuno, do I need to do anything special? Or will foo_1.2_amd64.snap and foo_1.2_armhf.snap just magically go to the right place as long as the YAML is the same?
 * ogra_ hugs beuno 
<beuno> kyrofa, magically
<kyrofa> beuno, I like magic
 * beuno briefly naps in ogra_'s hug
<kyrofa> Man that's a long hug
<kyrofa> beuno, thanks for the hard work! I'm testing it out now
<noizer> Kyrofa i think i found an issue of snappy. The pythonpath is only directed to the dist-packages and not to the site-packages
<noizer> is that normal or?
<kyrofa> noizer, they should be a symlink
<noizer> when i putted some folders in the site-packages, they cant be imported :s
<beuno> kyrofa, I'll leave the thanks in its original packing until it's gotten a bit of mileage and people are still happy  :)
<kyrofa> beuno, haha
<kyrofa> noizer, can you run ls -l on the directory containing site-packages?
<renat> Hi guys! Let me repeat my question.
<renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")?
<renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section.
<renat> assign: rules: - kernel: vhciq
<renat> But it device isn't accessible because of very strict access mode.
<kyrofa> ogra_, renat's question may be best suited for you
<sergiusens> kyrofa, elopio https://github.com/ubuntu-core/snapcraft/pull/286
<ogra_> kyrofa, i have no clue about the capability system
<ogra_> kyrofa, all i knew about was hw-assign ... i kind of lost track when we dropped that
<kyrofa> ogra_, oh I thought OEM was 15.04
<kyrofa> ogra_, I'm getting confused so quickly :P
<ogra_> i dont even think in 15.04 there was a way to do it automated
<kyrofa> ogra_, ah, now that you mention it, I do remember hearing that
<ogra_> it was all a manual call to hw-assign asd i remember
<sergiusens> ogra_, that is all 15.04 renat is talking about
<sergiusens> ogra_, there was in the oem snap; mvo_ implemented
<ogra_> sergiusens, well, do you remember if there was a way to do it from the oem ?
<sergiusens> ogra_, surely asac knows about this since he wrote a guide
<ogra_> ah, i didnt know
<ogra_> i only ever used hw-assign back then
<kyrofa> sergiusens, do you know about the mode/group bits?
<ogra_> i dont think mode/group will help much ... apparmor will block before you even get to that
<sergiusens> ogra_, kyrofa in case it is of interest https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<ogra_> mode and group should be handled through udev-acl anyway
<sergiusens> kyrofa, no, I think it is just tagging
<sergiusens> renat, if it is not a service, use sudo
<renat> ogra_, not apparmor blocking me
<renat> sergiusens, it's a service. Is it possible in 16.04?
<sergiusens> renat, stick to 15.04 for now; if it is a service and blocked I don't know, seccomp maybe?
<sergiusens> renat, sudo snappy install snappy-debug
<renat> sergiusens, thanks. I will try.
<sergiusens> jdstrand, maybe you have ideas ^
<dholbach> sergiusens, kyrofa: let me know if you need snapcraft 2.1 uploaded to xenial
<dholbach> ah no... you have upload rights for it now, right?
<sergiusens> dholbach, hah, I don't need you for that anymore :-P
<sergiusens> dholbach, sorry ;-)
<dholbach> yeah... I know
<dholbach> go go go!
<sergiusens> dholbach, still waiting on pocketsphinx though ;-)
<kyrofa> sergiusens, so you were able to build a rolling image that worked?
<jdstrand> renat: if it is a service, it should be running as root so file perms shouldn't be an issue. I suggest 'sudo snappy install snappy-debug' and then 'sudo snappy-debug.security scanlog' in one console while trying to use the app in another.
<renat> jdstrand, understood. thanks.
<renat> Seems it's trying to access /proc/4212/mounts
<renat> For the some reason
<sergiusens> kyrofa, I downloaded from mvo_'s p.c.c
<sergiusens> kyrofa, just this morning
<kyrofa> sergiusens, ah okay
<jdstrand> beuno, mvo_: I saw something about uploads to the store going to the write place. I noticed on a 15.04 bbb system that it is trying to install hello-world.canonical 1.0.18 over and over and over again
<jdstrand> s/write/right/
 * sergiusens goes for a quick run
 * jdstrand is curious if these things are related
<beuno> jdstrand, good question. What we've enabled, FWIW, is multiple binaries for different architectures andreleases
<jdstrand> beuno: so that means that I can have an ar-snap for 15.04 and a squashfs-snap for rolling both targeting !edge and it all works?
<beuno> jdstrand, correct
<jdstrand> that sounds nice indeed
<asac> ogra_: check out the guide
<asac> it has that info
<jdstrand> mvo_: fyi, something weird is happening on bbb 15.04 and hello-world.canonical starting yesterday
<asac> ogra_: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<asac> search for assign:
<mvo_> jdstrand: what is it?
<mvo_> jdstrand: since yesterday you say? do you have some more details?
<mvo_> jdstrand: there were some changes to the store related to the multi-dimension uploads
<ogra_> asac, well, tell that renat ;)
<asac> mvo_: what are multi dimension upload?
<ogra_> 4D uploAds !
<asac> 5D at least
<asac> >(
<ogra_> :)
<noizer> kyrofa what was the update of the snappy build because it rebooted it for update (ubuntu 16.04)
<kyrofa> noizer, you'd have to ask mvo_
<awe__> hey, can any of you tell me how to view the kernel options for our latest snappy rolling ripi2 image?
<kyrofa> noizer, remember you're on rolling, so some instability is not surprising
<ogra_> awe__, isnt /proc/config.gz populated ?
<davmor2> asac, ogra_: you seem to missing the point, there is no limit to multi ;)
<ogra_> (i usually set that by default before giving ppisati my config)
<noizer> awe_ what is changed during the update with the rolling version?
<noizer> awe__ what is changed during the update with the rolling version?
<awe__> ogra_, nope
<kyrofa> noizer, can you pastebin your binary wrapper for me?
<ogra_> awe__, hmm, then you need to apt-get source the package i fear ...
<mvo_> asac: the same name for multiple architectures, i.e. no more ubuntu-core-armhf
<ogra_> awe__, https://launchpad.net/ubuntu/+source/linux-raspi2
<davmor2> asac, ogra_: What mvo_ was trying to create with that statement was "XD uploads" :D
<awe__> ogra_, thanks dude
<noizer> kyrofa http://pastebin.com/647GUD2q
<kyrofa> noizer, I mean the one in /snaps/bin/
<asac> mvo_: ok, i wouldnt call it |dimension"
<asac> that name is already taken
<asac> but just nit pikcing
<asac> ttyl
<noizer> kyrofa ok
<kyrofa> noizer, I know, there are a lot of wrappers :)
<mvo_> asac: I agree, we were calling it multi-arch before which is arguable way worse
<noizer> kyrofa haha yea there are many wrappers but when my snappy was done with the update he doesnt have any snapp dir anymore :s
<ogra_> http://foodnetwork.sndimg.com/content/dam/images/food/fullset/2012/9/25/0/ZB0307H_grilled-chicken-caesar-wrap_s4x3.jpg
<ogra_> ;)
<kyrofa> noizer, the /snaps directory is gone?
<noizer> kyrofa yea he is gone
<sergiusens> elopio, kyrofa time to stand
<kyrofa> noizer, huh... yeah I'd reflash. Not sure what's going on there
<kyrofa> sergiusens, ah, right thanks
<noizer> maybe i will try again build a new image and see what he is doing while he is updating?
<noizer> kyrofa
<jdstrand> mvo_: sorry, got pulled away
<awe__> ogra_, that branch was for wily...  and I can't seem to come up with the right source package name for 'apt-get source'
 * awe__ jumps to #ubuntu-kernel
<ogra_> awe__, just grab the .deb ... then dpkg -x /part/to/deb .
<ogra_> (that will extract it to the current dir, probably create some ./tmp or some such )
<mvo_> jdstrand: no problem, I'm am pretty busy myself with various issues
<awe__> I'm not sure where the .deb lives or what it's name is
<awe__> if I did, I certainly would do that!  ;)-
<ogra_> it is linked from the above page i gave you
<awe__> that's a wily branch
<ogra_> https://launchpad.net/ubuntu/+source/linux-raspi2 shows wily and xenial
<jdstrand> mvo_: http://paste.ubuntu.com/14857472/
<awe__> ah, my bad
 * awe__ goes and looks again
<ogra_> clicking on the version will get you to the package
<ogra_> (then click on "armhf" there to get the binary deb)
<mvo_> jdstrand: so its reinstalling hello-world evey 1h?
<ogra_> (under "Builds")
<awe__> got it
<jdstrand> mvo_: so, starting at 11:00 local (17:00 UTC), snappy started regenerating apparmor profiles on the hour, every hour for hello-world.canonical, but not other snaps
<kyrofa> beuno, so I have version X uploaded to the store for armhf. I tried "Upload a New Version" of version X for amd64, and it's complaining that the version is already uploaded. Do I have to change the version per arch?
<jdstrand> mvo_: the other snaps that are install (one sideload, snappy-debug and ufw) did not dual-land
<jdstrand> I believe ufw may be an ar-based snap in rolling, and snappy-debug you need edge
<jdstrand> oh, but his is all 15.04
<mvo_> jdstrand: I suspect its actually reinstalling this every hour?
<jdstrand> $ snappy list
<jdstrand> Name         Date       Version      Developer
<jdstrand> ubuntu-core  2016-01-20 13           ubuntu
<jdstrand> bind9        2016-01-20 IKaMHDSJATaY sideload
<jdstrand> hello-world  2015-12-27 1.0.18       canonical
<jdstrand> snappy-debug 2016-01-06 0.10         canonical
<jdstrand> ufw          2015-12-17 0.35         jdstrand
<jdstrand> beagleblack  2015-12-17 1.12         canonical
<jdstrand> mvo_: that is what I expect is happening
<noizer> kyrofa any idea how i force an update,
<jdstrand> s/expect/suspect/
<kyrofa> mvo_, it seems that canonistack hasn't built a rolling image since it moved to all snaps
<kyrofa> mvo_, do you know anything about that?
<ogra_> we build images in canonistack ?
<ogra_> since when
 * ogra_ thought we dont build rolling images at all ... you always need u-d-f for it 
<ogra_> kyrofa, nothing moved to all-snaps yet except mvos dir at people.c.c
<jdstrand> kyrofa: aiui, there is nothing that automatically builds the os, kernel and gadget snaps used with these images. that work, aiui, is planned
<ogra_> the cdimage builds still only produce the old setup
<ogra_> (on my list for this week)
<noizer> mvo_ is there a way to update the image with a command line?
<ogra_> snappy update ubuntu-core
<ogra_> (+ sudo )
<mvo_> jdstrand: will "snappy list -u" show you hello-world as upgradable?
 * jdstrand checks
<mvo_> jdstrand: I'm still puzzled by this :)
<kyrofa> jdstrand, ogra_ ah, I keep misunderstanding that. So rolling really is dead right now?
 * jdstrand taps fingers
<jdstrand> mvo_: it does not
<jdstrand> $ snappy list -u
<jdstrand> ...
<jdstrand> hello-world  2015-12-27 1.0.18
<jdstrand> ...
<mvo_> jdstrand: hrm, hrm, that is confusing
<jdstrand> mvo_: you said a change landed yesterday on the store. I imagine that change was between 1600 and 1700 UTC
<mvo_> jdstrand: worth checking with the u1 guys
<jdstrand> mvo_: it seems like this is perhaps something that needs to be backed out unless we know that it isn't affecting shipping devices
<jdstrand> this would likely disrupt a service for a snap that this is happening to
<ogra_> kyrofa, no, it is simply not moved to all snaps yet ... everything should work though
<ogra_> (but using system-image)
<mvo_> jdstrand: I forwarded your question
<kyrofa> ogra_, "dead" = not getting any updates, I mean
<ogra_> it is getting them daily ;)
<ogra_> in fact all-snaps isnt getting any currently :)
<ogra_> (apart from manual builds mvo_ does)
<jdstrand> mvo_: thanks
<kyrofa> ogra_, huh, okay. Yeah, I really misunderstood :P
<noizer> kyrofa now i updated the ubuntu core again and yet i dont have a snapps dir
<kyrofa> noizer, I'm afraid you've moved beyond my experience. sergiusens or mvo_ may be able to help you better
<sergiusens> stgraber, hey, looking at using pylxd, but stumbled upon something which you were on the path to fix https://github.com/lxc/pylxd/pull/53
<noizer> serguissens mvo_ Hi guys, i did just an update of my ubuntu core and now my snapps dir is totaly gone.
<noizer> sergiusens
<noizer> sergiusens mvo_ When i installed a snap with python he doesn't recognized the keyword python anymore
<noizer> sergiusens mvo_ Any suggestions
<noizer> ?
<mvo_> noizer: are you running 16.04 (rolling) ?
<mvo_> noizer: or is that on 15.04?
<ogra_> mvo_, 16.04 system-image
<noizer> mvo_ rolling
<sergiusens> noizer, oh, python 2 is not part of rolling; you will need to use snapcraft and the python plugin
<sergiusens> or use python3
<sergiusens> kyrofa, ^
<ogra_> sergiusens, i think he does use the python2 plugin
 * ogra_ gave him the runes 
<sergiusens> ogra_, when someone uses the copy plugin I always suspect ;-)
<noizer> sergiusens sorry i use the python2 plugin at this time
<ogra_> but if the /snaps dir is gone that wont help much :)
<kyrofa> sergiusens, yeah no shebang or anything
<ogra_> sergiusens, not copy ... just the same runes i use for mycroft
<ogra_>   config:
<ogra_>     plugin: python2
<ogra_>     source: .
<ogra_> and additionyl python packages via stage-ppackages in copy
<ogra_> geez .... my typing ...
<kyrofa> sergiusens, but the thing that's really confusing is is the /snaps dir
<noizer> ogra_ but is there now a way to install them with pip?
 * kyrofa went cross-eyed trying to read what ogra_ just said
<mvo_> noizer: hm, sorry that 16.04 is a bit rocky, we had some incompatible changes recently but its stabelizing all again now. we moved to the new /snaps dir (instead of the previous /apps dir) and we moved to a new snap.yaml layout. those may have broken the image.  easiest might be to reinstall using http://people.canonical.com/~mvo/all-snaps/ -  I am updating the images as we speak
<ogra_> kyrofa, like http://paste.ubuntu.com/14857655/ ... ;)
<kyrofa> ogra_, hahaha
<ogra_> config gets you the interpreter ... copy's stage-packages gets you extra modules
<ogra_> i know i'm cheap ;) but it works
<kyrofa> ogra_, ah, this is the "I don't want to write a setup.py" YAML?
<noizer> mvo_ can you update me when the image is there to download?
<ogra_> well, i dont want tio use sources if i can use prebuilt binaries ... :)
<kyrofa> ogra_, heh :)
<noizer> ogra_ can i install the packages then like a tornado?
<noizer> (stage-packages)
<ogra_> like a tornado ?
<ogra_> dressed like a funnel whirling around ?
<mvo_> noizer: sure, I will. I hope later today, there is one pending branch that needs review then I think all is in and the disruptions are over (fingers crossed)
<noizer> tornado the python library
<ogra_> ah
<ogra_> you shoudl be able to
<sergiusens> ogra_, nah, noizer use pip-packages; snapcraft help python2
<ogra_> ah
<ogra_> yeah, thats definitely different
<noizer> ooooh ok
<noizer> mvo_ i think i best need to wait until the problem is solved?
<noizer> mvo_ or can i revert my update so I can work a little further?
<mvo_> noizer: you can revert your update, just run "snappy rollback ubuntu-core"
<noizer> mvo_ thx allot xD
<noizer> mvo_ hopefully is it fixed soon :d
<noizer> dammed mvo_ :p no version to roll back :p
<mvo_> noizer: ha! of course
<mvo_> noizer: ok, this is a bit tricky but you can force it via "grub-editenv", grub-editenv list will show whats there
<mvo_> noizer: and if you look at /var/lib/snappy/snaps you need to set the snappy_os to the last os snap you have there
<mvo_> noizer: its a bit risky but should work :)
<noizer> mvo_ dammed i cant enter the classic mode anymore
<mvo_> noizer: grub-editenv should be available in normal mode
<mvo_> noizer: its all connected, the /snaps change also changed the data directory
<mvo_> noizer: appologizes again, the timming is very unlucky, this is probably the worst distruption we had in the entire snappy lifecycle
<noizer> mvo_ -bash: grub-editenv: command not found
<noizer> mvo_ np i appreciate the good help over here so no worries
<mvo_> noizer: hm, it should be under /usr/bin/grub-editenv
<opny> Hello, in snapcraft how can I inform make plugin that an additional configure is needed?
<kyrofa> opny, when you say "configure" I think autotools, not make. No?
<noizer> mvo_ it think i will make a new image of the previous version. but can i disable automatic updates?
<opny> kyrofa, yes, I'm not that good on the topic, sorry. I have a Makefile but requires a ./configure run first. Should I "extract" such ops from it ?
<kyrofa> opny, nahh, you just need to use the autotools plugin!
<kyrofa> opny, that will run configure for you (and allows you to specify configure options) as well as run make/make install for you
<opny> kyrofa, I'll try thanks :)
<kyrofa> opny, `snapcraft help autotools` will help
<opny> kyrofa, oh.. great.. I used to read the plugin source till now..
<kyrofa> opny, *cough* well that works, too...
<opny> kyrofa, *cough* ya kind of..
<ogra_> guys, stop sreading your germs in here !
<torbit> hey folks. What does this mean ? `Device generic_amd64 not found on server https://system-image.ubuntu.com channel stable`
<torbit> I run this command: ` ubuntu-device-flash core 15.04 -o my-snappy.img --channel stable`
<ogra_> torbit, try adding --oem generic-amd64
<torbit> ogra_: unkown flag
<ogra_> huh ?
<ogra_> cant be
 * ogra_ wonders how old your ubuntu-device-flash is 
<torbit> one sec I check for you
<ogra_> though --oem has been supported from day one i think
<torbit> well this may sound odd but I cant seem to get the version. However my -h flag gives me the following outout ```Usage:
<torbit>   ubuntu-device-flash [OPTIONS] <core | query | touch>
<torbit> Application Options:
<torbit>       --revision=        revision to use, absolute or relative allowed
<torbit>       --download-only    Only download.
<torbit>       --server=          Use a different image server (https://system-image.ubuntu.com)
<torbit>       --clean-cache      Cleans up cache with all downloaded bits
<torbit>       --tls-skip-verify  Skip TLS certificate validation
<torbit> Help Options:
<torbit>   -h, --help             Show this help message
<torbit> Available commands:
<torbit>   core   Creates ubuntu core images
<torbit>   query  Run queries against the image server
<torbit>   touch  Flashes ubuntu touch images ```
<ogra_> geez !
 * ogra_ points to paste.ubuntu.com 
<ogra_> :)
<ogra_> also: ubuntu-device-flash core --help
<ogra_> since you want to know the options for the core command
<torbit> ogra_: http://pastebin.com/BxcU6qzM
<torbit> same output as above
<noizer> mvo_ will the image be updated today?
<mvo_> noizer: thats my goal, I'm still waiting for one branch to land
<noizer> mvo_ ok but when im trying to use an previous version it will automic update but can i disable thath?
<mvo_> noizer: I disabled the new version for now on the server side
<noizer> thx a lot :D
<tsimonq2> dholbach: when I am using the guide here: https://developer.ubuntu.com/en/snappy/start/#snappy-local , can I get a newer image than 15.04?
<tsimonq2> oic
<tsimonq2> dholbach: is there a rolling image?
<dholbach> tsimonq2: I don't think there's an official one, but you can roll one yourself using ubuntu-device-flash
<tsimonq2> dholbach: how would I go about doing that?
<dholbach> or use http://people.canonical.com/~mvo/all-snaps/
<dholbach> which has the latest changes
<tsimonq2> dholbach: so is this rolling edge?
<ogra_> it will be
<ogra_> this is a new architecture that currently only gets manual updates
<ogra_> but shoulÃ¶d be implemented as default very soon
<tsimonq2> dholbach: so I'll get the 1504 image as specified on the page, but can I upgrade release and channel?
<tsimonq2> to rolling and edge?
<ogra_> you can get a rolling release by using ubuntu-device-flash and using the rolling (xenial) release to build your image
<dholbach> tsimonq2: ^ what ogra_ said
<ogra_> but that will stop to roll soon due to the above switch :)
<sergiusens> elopio, oh bummer
<elopio> sergiusens: what? what???
<sergiusens> elopio, mccabe
<ogra_> (i.e. you will have to switch to the all-snaps setup by re-flashing your device)
<dholbach> things will stabilise very soon and we'll recommend to use 16.04
<ogra_> yeah
<tsimonq2> ogra_: how does ubuntu-device-flash work_ is there a man page I can read?
<ogra_> nope
<ogra_> but it has multiple help options
<elopio> sergiusens: ahh, you worried me for a moment :)
<sergiusens> ogra_, u-d-f does have a man page, outdated, but there
<ogra_> "ubuntu-device-flash --help" for the basicv app options ... "ubuntu-device-flash core --help" for image build related stuff
<sergiusens> elopio, so on the tricky side; we might have to wing it for now with th examples
<ogra_> ok, i'm wrong then :)
<dholbach> all right, tsimonq2 - I leave you in good hands - I'm going to call it a day now - see you! :)
<tsimonq2> bye dholbach
<elopio> sergiusens: I'm not sure what does "wing it" means.
<sergiusens> elopio, not everything will work until the snappy folk iron out all the bugs; there are workarounds but the examples should eventually work as is
<sergiusens> elopio, I don't want to gross up the yaml just to workaround the ones that have no `uses`
<elopio> sergiusens: yeah, bad week for releases.
<elopio> sergiusens: here's an idea, let's release next monday :)
<sergiusens> elopio, https://github.com/ubuntu-core/snappy/pull/416
<sergiusens> elopio, well we need a tool for people to start finding bugs; and the all snaps images are already out
<sergiusens> elopio, the closer we get to feature freeze the harder this will be (for snapcraft at least)
<kyrofa> elopio, sergiusens I don't know what you guys are talking about. 1.0.1 works great
<elopio> sergiusens: I'm just thinking that the releases notes you'll have to send explaining how to get all the pieces to get this working are way too complex.
<tsimonq2> ogra_: okay, sorry, keyboard weirdness, so should I use the 16.04 image?
<elopio> but if you think the release will be useful, let's do it.
<ogra_> tsimonq2, depends what you are after
<tsimonq2> ogra_: I want the latest
<ogra_> sperfcifically if you plan to create snaps
<ogra_> -rf
<ogra_> it works different for the different releases
<noizer> mvo_ is the update fixed because he reboots automatically again :s
<ogra_> tsimonq2, if you can live with having to re-flash your device at some point, i'd go for mvo's images (you can also help to test the new setup) ... else stay with 15.04
<ogra_> for xenial/rolling you will have to re-flash at some point, no matter which setup you use
<tsimonq2> ogra_: I am just looking to have it in a KVM instance
<ogra_> sicne we will make incompatible changes to the image design
<ogra_> then grab the amd64 image from http://people.canonical.com/~mvo/all-snaps/
<tsimonq2> alright cool
<tsimonq2> downloading now
<kyrofa> beuno, I have a question regrading the multi-arch uploads if you're around
<tsimonq2> ogra_: for regular Ubuntu and flavors we have test cases, do you have manual test cases I can complete?
<ogra_> tsimonq2, i dont think there are nay manual ones, elopio might be able to point you to them if they exist
<ogra_> (but i thinnk snappy is all automated currently)
<elopio> tsimonq2: just a few that we haven't been able to automate. https://github.com/ubuntu-core/snappy/blob/master/integration-tests/manual-tests.md
<elopio> ogra_: I had to deautomate the image resize ones :'(
<ogra_> elopio, i need to change all that code anyway since it breaks the dragonboard images
<tsimonq2> ogra_: Okay, I have the Snappy image booted, what now?
<elopio> ogra_: ok, please keep me posted of your plans there.
<tsimonq2> and ssh'ed into
<ogra_> elopio, well, i'm largely planninf to rip out parted completely
<sergiusens> elopio, they will be complex either way
<tsimonq2> running snappy update, looks like there is updates
<sergiusens> elopio, in any case; shout works fine ;-)
<ogra_> elopio, and switch to sgdisk for better GPT support
<sergiusens> elopio, the other snaps using declared skills do as well
<ogra_> tsimonq2, dunno, whatever you want to do with it ... buuld snaps ... install existing snaps etc
<sergiusens> elopio, I think it will be
<tsimonq2> ogra_: aaand I have an error: http://pastebin.ubuntu.com/14858708/
<elopio> ogra_: dumb question. Why are we doing the resize during the boot and not after?
<ogra_> elopio, because you cant easily rezize a partiton thats mounted :)
<elopio> ogra_: not easily. But harder than do it during boot?
<ogra_> a lot and error prone
 * tsimonq2 just uses the 15.04 image for now
<ogra_> especially with our bind-mount_farm living on top
<elopio> ok, I was just wondering :)
<ogra_> we could do it after boot but would to have remove all bind mounts and stuff
<ogra_> and re-add them
<ogra_> thats super hackish
<ogra_> doing it cleanly before anything uses the partiton is a lot better
<elopio> I agree that doing earlier is better.
<elopio> I'm confused about where you draw the line on what's super hackish :D
<ogra_> well, thats easy ... if something requires ten lines of code in one condition and 100 lines in another, just to reach the 10 line condition first ... thats what i call hackish ;)
<elopio> but it works nicely, and moving away from parted sounds like a good thing anyway.
<ogra_> well, parted is the preferred tool if it comes to MBRs ... but it lacks a lot when it comes to GPT sadly
<ryanleesipes> Hello!
<kyrofa> Hey there ryanleesipes, welcome :)
<plars> ogra_: have you tried installing to emmc on the dragonboard? In particular, I'm wondering about the possibility of leveraging fastboot to write the needed partitions for snappy, and booting from that
<sergiusens> elopio, anything really broken aside from things we don't control?
<elopio> sergiusens: I'm still trying to get the autopkgtests running. It's reaaaly slow today, 75% creating the testbed.
<elopio> sergiusens: the tests went well, I built all the snaps examples.
<sergiusens> elopio, that is encouraging at least
<elopio> sergiusens: I haven't run the binaries yet.
<sergiusens> elopio, yeah, only the ones with migration-skill in them will work; the ones without won't ... yet
<sergiusens> elopio, this is the dilema either we release or don't release, things are going to be broken as the previous non migration-skill stuff doesn't work anymore ;-)
<elopio> sergiusens: well, release. Just explain that it's a safe point release to keep our cadence, but that people will have to wait to the next monday release to really use everything.
<sergiusens> elopio, hah, that is the thing; we don't need to do anything; with a new ubuntu-core release everything should start working
<zyga> sergiusens, elopio: we might have simple version if skills really working this week (at least in my tree), no real change for you guys but that made me think about one validation aspect, will we keep snapcraft aware of all the skill types and make it validate everything or is there some other plan?
<zyga> like having a way to delegate to snappy somehow
<zyga> "snappy check that skills make sense in snap.yaml"
<sergiusens> zyga, ah, that crossed my mind; but it would be increasingly complicated to do that
<elopio> sergiusens: also, keep an eye here: http://jenkins.elopio.net:8080/job/leo-snapcraft-test/11/console
<elopio> it's finally running the examples install tests in scalingstack.
<zyga> sergiusens: we don't have to solve it today but let's think about the approach we want to take
<elopio> zyga, sergiusens: I'm ok with the snap failing to install if it's using an unexisting skill
<sergiusens> zyga, in the end I think this goes closer to the review tools than snapcraft
<elopio> zyga: what I expect is to have one snapcraft file for each valid skill, so we can run the tests to make sure that they keep working.
<zyga> sergiusens: yes, that's true
<sergiusens> zyga, we just want a consistent structure; don't really care about the contents (unless used by snapcraft)
<sergiusens> just like we don't make sure every listed `stage-package` is valid until we need to use it
<elopio> and even if the skill is valid, after installing we can't be sure that it's the correct one to use.
<elopio> that's where we are missing the healthchecks.
<sergiusens> elopio, the jenkins instance times out for me, I will not bother it to not reduce bandwith more
<elopio> sergiusens: you can only access through the vpn.
<sergiusens> elopio, ah, since it had your domain there I thought you were proying or something
 * sergiusens might dissappear for a bit while connecting to the vpn
<elopio> ahh, it's running on an old version.
<elopio> I'll restart it with the hash of the latest.
<sergiusens> elopio, seems the build failed
<elopio> sergiusens: I launched the wrong revision.
<elopio> watch #12 now :)
<sergiusens> elopio, hah; but I need to disconnect :-P
<elopio> well, now it doesn't have any output ofcourse.
<sergiusens> irc is crappy on network switching
<sergiusens> I need to go to the doctor for a bit so I'll check when I get back
<elopio> sergiusens: I have an eye there, don't worry.
<elopio> sergiusens: just one thing. I'm now with mvo's latest all snaps image, installing the downloader snap.
<elopio> and when I run it, it says: aa_change_onexec failed with -1. errmsg: No such file or directory.
<elopio> sergiusens: is that what we are expecting?
<sergiusens> elopio, yes, that happens when the defaults are not taken into account
<elopio> good.
<elopio> I guess... :)
<sergiusens> lol
<sergiusens> elopio, network-client might become a mandatory key from what I heard, but we won't know until later (and I just heard about that now)
<sergiusens> so not adding it here just to remove it later
<sergiusens> elopio, change of plans, we are staying and going only tomorrow
<kyrofa> sergiusens, I'm seeing SNAP_USER_DATA defined for services to be //snaps/<name>/<version>, where the systemd %h doesn't seem to be replaced
<kyrofa> sergiusens, on the newest all-snaps. Can you verify?
<sergiusens> kyrofa, let me check
<sergiusens> hey jerryG
 * sergiusens also says a late hi to ryanleesipes 
<sergiusens> kyrofa, yeah, broken
<kyrofa> sergiusens, argh. This ROS change is taking far too long right now, I think it's time to move on and wait until I can reliably test the resulting package
<sergiusens> kyrofa, hmm, isn't that %h technically correct though?
<elopio> sergiusens: lucky kid, got one extra day.
<kyrofa> sergiusens, yeah that's been there forever. Something else is broken
<sergiusens> kyrofa, it is replaced by systemd itself
<kyrofa> sergiusens, right
<kyrofa> sergiusens, but it only replaces with what it knows. And it looks like it's a /
<sergiusens> kyrofa, oh, that means it replaced it for nothing
<sergiusens> Chipaca, ideas ^
<kyrofa> sergiusens, are you sure? Notice no leading slash: SNAP_USER_DATA=%h/snaps/ros-example.sideload/ILaUbGECDNAE
<kyrofa> sergiusens, and when evaluated, SNAP_USER_DATA=//snaps/rosblahblah
<sergiusens> kyrofa, that is indeed different
<sergiusens> kyrofa, maybe this is a plain systemd bug? "This is the home directory of the user running the service manager instance. In case of the system manager this resolves to "/root"."
<kyrofa> sergiusens, not outside the realm of possibility
<sergiusens> pitti, if still around any idea my %h would expand to `/` instead of `/root`?
<sergiusens> s/my/why/
<kyrofa> sergiusens, the %h is valid (at least it should be). Is the root home dir setup correctly?
<sergiusens> kyrofa, that might be it; but if the systemd man page says it will expand to /root maybe it is hardcoded somewhere :-P
<kyrofa> sergiusens, oh, interesting point
<kyrofa> sergiusens, yeah, root looks okay in my passwd
<jdstrand> beuno, matiasb: not sure what you guys did, but it appears that my device is no longer reinstalling hello-world.canonical over and over again
<matiasb> jdstrand, nothing? but if you get any more details or if it happens again, let us know
<kyrofa> matiasb, hey, do you know anything about the new multi-arch upload support?
<jdstrand> weird
<matiasb> kyrofa, o/ yes, what would you like to know?
<kyrofa> matiasb, I have version 1 of a given package released for armhf, and I tried uploading version 1 for amd64, but got a "this version is already uploaded" error. Do I need to have a different version per arch?
<matiasb> kyrofa, yes, at the moment different version numbers are required for each upload, we are working to update that to allow same version numbers for different archs
<kyrofa> matiasb, ah very good, thank you!
<pitti> sergiusens: no, not off-hand
<pitti> sergiusens: is that for a unit running as user who actually has / as home dir?
<kyrofa> pitti, no, it's for root with /root as home dir
<sergiusens> pitti, a system unit in /etc/systemd/system/.*.service
<Chipaca> kyrofa: sergiusens: where are you seeing this?
<kyrofa> Chipaca, newest all-snaps
<Chipaca> noice
<Chipaca> kyrofa: for apps, or for services, or both?
<kyrofa> Chipaca, services (though I didn't try binaries)
<Chipaca> is HOME set for services?
<robert_ancell> zyga, in https://github.com/ubuntu-core/snappy/pull/409 you say "documented constants". Do you mean constants for the PolicyKit actions?
<kyrofa> Chipaca, it at least used to be, but it was set for root. Remember those bugs a while back?
<sergiusens> Chipaca, the systemd.unit manpage says it defaults to /root
<awe__> hey guys, my snappy rolling image updated automatically today, and now my bluez snap seems to be broken
<awe__> is there a known breakage?
<awe__> basically all of the wrapper scripts can't seem to find the binaries anymore
<dustino> Is there a Snappy eMMC flasher image available for the Beaglebone Black?
<elopio> dustino: no, you'll have to flash it to the sd card.
<sergiusens> elopio, how did testing go?
<dustino> elopio: thanks. do you know if/when one will be made available?
<enoch85> kyrofa: hey man
<enoch85> kyrofa: long time no see...
<enoch85> kyrofa: sorry I didn't had the time, just been busy with my own stuff recently
<enoch85> kyrofa: but now all the VMs are done, finally
<enoch85> kyrofa: os your plan to rebuild the owncloud snap when 16.04 are released?
<jerryG_> sergiusens: hey sergiusens
<elopio> sergiusens: sorry, I'm back. I died for a while.
<elopio> I'm still not able to get the adt test bed working. Tried on xenial and wily, lxd and qemu. The four combinations give four diferent errors.
<elopio> I
<elopio> the rest looks as good as it gets. jenkins failed because of the missing locales, but only on the examples that seem to need utf8. I'm taking a look there to report a bug.
<elopio> not new though, with that we are a lot better than before..
#snappy 2016-02-03
<elopio> dustino: sorry, I missed your question. We are not working on making it installable on the emmc.
<fgimenez> good morning
<zyga> good morning
<dholbach> good morning
<noizer> good morning :D
<noizer> mvo do you know when the update will be available today?
<mvo> noizer: yes!
<noizer> mvo yihaaaa lets snap the world today :D
<mvo> noizer: xz is running right now
<noizer> mvo ok thx :D
<mvo> noizer: eta something like 15min
<noizer> mvo ok where can I find the release notes?
<mvo> noizer: I will send a mail on snappy-devel@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/snappy-devel
<mvo> noizer: later today
<noizer> ok
<noizer> mvo are there already products in production that uses snappy?
<mvo> noizer: https://people.canonical.com/~mvo/all-snaps/ its there now for amd64, enjoy and let me know if you notice any issues
<noizer> i saw but i need the Raspberry pi one xD
<mvo> noizer: yes erle robotics for example http://erlerobotics.com/blog/snappy-store/
<mvo> noizer: and https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
<mvo> noizer: those are all 15.04 based currently though. but 16.04 will be much better
<mvo> even better I should say :)
<noizer> haha :D thats why i'm developing on snappy 16.04 :D
<noizer> are you building the other images too (raspberry pi)?
<noizer> mvo
<mvo> noizer: yes, as we speak :)
<mvo> noizer: rpi2 will take a bit longer because of the manual testing I do on the sd card, but I think in 1h at latest it will be up too
<noizer> mvo thx thats best service with on going development i ever had :D
<noizer> :p
<mvo> :-D
<JamesTait> Good morning all!  Happy Wednesday and happy Carrot Cake Day! ð
<Mikaela> Where do you get thowe days?
<davmor2> JamesTait: ^ I think that one is directed at you and I can't remember the link
<JamesTait> Mikaela, various sources on the internet, some "official", some just silly.
<Mikaela> ack
<JamesTait> daysoftheyear.com and nationaldaycalendar.com both had today's.
<JamesTait> wellcat.com is another.
<Mikaela> I must take a look sometime
<mvo> noizer: rpi2 is available now as well on https://people.canonical.com/~mvo/all-snaps/
<noizer> mvo thx :D
<noizer> mvo writing the image to my sd card :D
<dholbach> mvo: did we drop 'snappy search'?
<dholbach> mvo: did you see anything like this before? http://paste.ubuntu.com/14864883/
<mvo> dholbach: what version of snappy are you on right now?
<mvo> dholbach: I'm preparing a mail for this right now
<dholbach> mvo: I used the amd64 all-snaps image from you
<mvo> dholbach: if you could give me the snappy list output that would be great
<dholbach> mvo: http://paste.ubuntu.com/14864906/
<mvo> dholbach: this is probably fallout from the switch from package.yaml to snap.yaml and/or fallout from the store changes. so I'm super keen to figure out the root
<dholbach> ok...
<dholbach> mvo: and 'snappy search' is gone as well?
<dholbach> or will there be a new incarnation of it?
<mvo> dholbach: yeah, its now "snap find"
<dholbach> ah, great - thanks
<mvo> dholbach: I prepare a mail now that explains the changes a bit more :)
 * dholbach hugs mvo
<mvo> dholbach: sorry for the trouble, it looks like the store is really confused - https://bugs.launchpad.net/software-center-agent/+bug/1541317 is causing the issues
<ubottu> Launchpad bug 1541317 in Software Center Agent "Returns incorrect channel data" [Undecided,New]
<mvo> dholbach: which means I may need to create new images because right now the all-snap image is defaulting to the stable channel for the os/kernel snaps. but maybe that is actaully not a bad thing :)
<didrocks> do we have an example of a seccomp override file?
<didrocks> it seems that snappy install isn't happy when parsing one, just containing "setpriority" for instance
<didrocks> mvo: maybe you would know a good example with an appamor and seccomp override?
<didrocks> (maybe it expects a yaml file?)
<mvo> didrocks: here are some examples https://github.com/ubuntu-core/snappy/blob/master/snappy/security_test.go#L832
<pitti> Chipaca, mvo: still any trouble with the wait4net service?
<mvo> pitti: I still did not manage to work on the proper fix :( the images were broken and I had to unbreak them first
<mvo> pitti: while you are here :) is there a trivial setting to make /tmp not a tempfs with systemd? for snappy we ran into various issues in the testsuite with /tmp being too small
<didrocks> mvo: isn't that supposed to point to a file rather?
<didrocks> (from the doc)
<pitti> mvo: it defaults to not being a tmpfs
<mvo> didrocks: that was in 15.04 iirc that it was a file
<didrocks> mvo: I saw "deprecated" in the tests, so I didn't dare trying
<pitti> mvo: so, revert whatever you do to make it a tmpfs -- most likely, /etc/fstab?
<mvo> didrocks: and in 15.04 its json
<mvo> pitti: aha, ok, thats good to know, I will dig around
<didrocks> mvo: hum, do you have one example?
<mvo> didrocks: a 15.04 example?
<pitti> mvo: could also be that snappy enables /usr/share/systemd/tmp.mount
<didrocks> yeah :)
<didrocks> with this file
<didrocks> I was expecting it to be a seccomp-like file
<pitti> mvo: but check /etc/fstab first
<pitti> mvo: but how would that work on snappy? isn't the root fs r/o?
<mvo> ta, will do
<pitti> mvo: or a tmpfs by itself?
<mvo> pitti: root is r/o but we can just bind mount the writable partition on top of /tmp
<mvo> the tmp of the writable partition
<pitti> mvo: I thought with "all snaps" you'd have an empty root tmpfs as /, and then bind-mount the r/o .snaps into it?
<didrocks> because if it's json, what do we put as a key?
<pitti> or did I misunderstand this?
<didrocks> I guess maybe something like: { "syscalls": ["setpriority"] }?
<pitti> mvo: ah, so I guess change /tmp in fstab to be a bind mount to /writable/tmp instead of a tmpfs?
<mvo> pitti: yeah, I think that is what we need to do. thanks. for some reason I was thinking that systemd would do that by default and we had to do something in ubuntu to disable it (it being the tmpfs on /tmp)
<mvo> didrocks: I need to check for the details, jdstrand is the master of this but I look for an exmaple now
<pitti> mvo: upstream does, but we don't in Debian/Ubuntu as that discussion is still ongoing and haven't decided yet
<mvo> didrocks: https://github.com/ubuntu-core/snappy/blob/15.04/snappy/security_test.go#L253 maybe?
<didrocks> mvo: thanks! yeah, an example would be awesome!
<mvo> pitti: thanks, thats super useful
<noizer> mvo i got a strange error http://pastebin.com/LnZW0TDA do you know what i did wrong?
<didrocks> mvo: trying in progress :)
<didrocks> (didn't spot that one in tests)
<didrocks> mvo: \o/
<didrocks> yeah, yaml it was :)
<didrocks> mvo: extra bonus question, our package needs to be configure for credentials before being able to work
<didrocks> so, we have a systemd service
<didrocks> I would like to set "only starts if file <foo> is present" with the correct service key
<didrocks> can we extend the systemd .service generated file?
<didrocks> (and extra bonus: apart from the config script calling sudo snappy service startâ¦<>, is there a less hackish way of restarting the service after a config change?)
<tsouza_> hello all, I'm trying to run latest stable snappy through vagrant. The VM won't boot, it keeps rebooting really fast and I can not see whats going on in the virtualbox gui... any clue anyone?
<mvo> noizer: unfortunately not, how can I reproduce this?
<mvo> didrocks: we can not expand the .service right now, the service itself would have to check that currently. we can talk about expanding our .service files of course
<noizer> mvo I try to install the plugin python2 and that don't works but when i try to install python3 then it works
<noizer> so i think python2 is bugged
<noizer> But i need python2 because one lib is only supported in python2 at the moment
<mvo> noizer: via snapcraft? sergiusens and kyrofa are your experts for that
<noizer> yea via snapcraft
<noizer> ok are the online at the moment?
<mvo> noizer: I suspect a issue with snapcraft, unfortunately I'm not a expert there
<noizer> ok np i will ask them :D
<mvo> noizer: not yet but should be soon, they on the americas
<noizer> ok thx
<didrocks> mvo: the thing is that the service checks, and so, it tries to restart
<didrocks> upon 3 times
<didrocks> then, nothing "triggers" it once properly configured
<opny> hi all! I'm using snapcraft with autotools plugin, I have an issue over libssl  (I guess) as it does not find openssl/bn.h May it be related to the snapcraft build?
<mvo> didrocks: right, lets talk about adding code for start conditions then in a bit (after lunch?)
<didrocks> mvo: sure!
<dholbach> sergiusens: should snapcraft pull in request_toolbelt from somewhere?
<dholbach> I got
<dholbach> No module named 'requests_toolbelt'
<noizer> sergiusens Hi, got a strange thing going with snapcraft. I want to install python2 as plugin but when i try i got this error: http://pastebin.com/LnZW0TDA
<noizer> sergiusens but i tried it now with python3 and it gave me the same issue
<didrocks> mvo: however, we don't have any /var/lib/appamor/profiles dir (or content anymore) :/
<didrocks> seems something burned it
<didrocks> not even sure how we can recreate it. We try to install an old snap, and nothing happens
<mvo> didrocks: its in /var/lib/snappy/apparmor now iirc
<mvo> didrocks: in 16.04
<mvo> didrocks: or is this on 15.04?
<dholbach> sergiusens: I'm also seeing this happening: http://paste.ubuntu.com/14865381/
<dholbach> which might not work when not running with sudo
<didrocks> mvo: it's 15.04, for mwc
<didrocks> mvo: /var/lib/snappy/apparmor/profiles was deleted
<didrocks> by installing a snap
<didrocks> (the whole directory)
<mvo> didrocks: *urgh*
<didrocks> yeah, doesn't sound "yummy" :/
<didrocks> is there any way to at least for now, tell apparmor to rebuild all profiles?
<mvo> didrocks: is this reproducable? I think its click-appamor handling this dir on 15.04
<mvo> didrocks: I don't know, jdstrand will know how to tell apparmor to rebuild all profiles
<didrocks> mvo: we did install it multiple times, we want the demo to work before reproducing (but apparmor/seccomp doc is a little bit of a PITA)
<kyrofa> Good morning
<torbit> good morning
<noizer> kyrofa good morning xD
<noizer> I have already a question for you :D
<noizer> since the update of the ubuntu core i can't install python anymore as plugin :s
<noizer> kyrofa here you get the error http://paste.ubuntu.com/14865381/
<kyrofa> noizer, I'm not really sure what I'm looking at, here. However, is your project publicly available? Can I give it a try?
<noizer> No it inst available i was developing for it :p
<noizer> wait I will give you a my yaml file
<kyrofa> noizer, yeah, whatever is causing the failure for you so I can reproduce it here
<noizer> wait i will test an other thing just only install python so i can see if it realy python
<kyrofa> noizer, for what it's worth seems seem a bit broken on the most recent all-snaps release for me as well
<noizer> kyrofa what can we do about it?
<noizer> kyrofa i minimized my snap and tested this and got the error http://pastebin.com/nz3pgysu
<noizer> and that is since the update from today( for you yesterday night)
<kyrofa> noizer, yeah I need to see your project if that's possible
<noizer> kyrofa i can't show it because its for the company that i work for
<noizer> but yesterday it worked all fine until the update came
<kyrofa> noizer, oh you put the YAML in the paste, okay I can work with that
<noizer> ok this yaml I tried but normally its correct but it doesn't work :s
<noizer> kyrofa do you get the same problem?
<kyrofa> noizer, one minute, I have to put out a fire dholbach found for me
<dholbach> kyrofa: sorry :)
<noizer> kyrofa ok np :D
<kyrofa> dholbach, super embarrassing :P
<opny> hello, I'm using snapcraft with autotools plugin to build rethinkdb, I have an issue over libssl  (I guess) as openssl/bn.h is not found May it be related to the snapcraft build?
<sergiusens> dholbach, sorry need context
 * sergiusens just got out of the dentist
<dholbach> opny: do you have libssl-dev installed?
<dholbach> sergiusens: err... context to which question?
<sergiusens> opny, add openssl to the stage-packages
<sergiusens> <dholbach> sergiusens: I'm also seeing this happening: http://paste.ubuntu.com/14865381/
<kyrofa> sergiusens, please accept my humble apologies for https://bugs.launchpad.net/snapcraft/+bug/1541349 . After that looks PR is merged I'd be happy to crank out 2.1.1
<ubottu> Launchpad bug 1541349 in Snapcraft "Should maybe depend on python3-requests-toolbelt?" [Critical,In progress]
<sergiusens> kyrofa, lets do a 2.1.1
<sergiusens> kyrofa, let me get that started
<kyrofa> sergiusens, I'm sorry man
<sergiusens> kyrofa, its fine
<opny> dholbach, sergiusens yes sure, I've tried to add the :i386 one either nut no luck
<dholbach> opny: it should be in libssl-dev
<sergiusens> kyrofa, I'll fix
<dholbach> opny:
<dholbach> daniel@daydream:~$ dlocate openssl/bn.h
<dholbach> libssl-dev:amd64: /usr/include/openssl/bn.h
<dholbach> daniel@daydream:~$
<sergiusens> kyrofa, unless you already have
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/288
<sergiusens> kyrofa, I can see that was quickly done ;-)
<kyrofa> *sigh*
<sergiusens> kyrofa, no worries!
<opny> dholbach, uhm, you're right.. It's not on my system, only in stage-packages
<kyrofa> sergiusens, fixed
<dholbach> opny: using build-packages: you can specify it in the snapcraft.yaml
<dholbach> opny: so others using the same recipe will surely have the package installed upon build
<sergiusens> dholbach, mind looking at https://github.com/ubuntu-core/snapcraft/pull/288
<opny> dholbach, oh, ok thanks... was using the wrong one!
<sergiusens> kyrofa, this just means we need integration tests for upload/login/logout
<kyrofa> sergiusens, indeed
<kyrofa> sergiusens, making the issue now
<dholbach> kyrofa: are all these packages required as build-deps?
<dholbach> I haven't checked in a while - is this because we run the unit tests during the build?
<kyrofa> dholbach, sergiusens perhaps they should be in the test control?
<kyrofa> I guess I'm not sure
<dholbach> let me check
<sergiusens> kyrofa, debian/tests/control pulls in the package deps
<dholbach> sergiusens: but that's only for the autopkgtest
<sergiusens> dholbach, yeah, I think kyrofa is just nervous now and wants to add the dep everywhere ;-)
<dholbach> kyrofa: they're still required - the unit tests are run during the build: https://launchpadlibrarian.net/236098042/buildlog_ubuntu-xenial-amd64.snapcraft_2.1_BUILDING.txt.gz (at about 90% of the log)
<kyrofa> sergiusens, yeah paste paste pate
<sergiusens> dholbach, it's still in Build-Depends iirc
<dholbach> sergiusens, kyrofa: looks like it's a good idea to keep them in build-depends too :-)
<sergiusens> in debian/control
<kyrofa> Haha, okay good
<sergiusens> well, I didn't see them removed
<dholbach> sergiusens: I just wanted to check if they're still required as build-deps and it turns out they are :)
<kyrofa> Yeah I think dholbach was just checking the whole thing
<sergiusens> dholbach, yeah, they are; just for module import if anything else
<opny> dholbach, oh no, after adding the build-packages, snapcraft has gone.. python says too many open files http://paste.ubuntu.com/14866019/
<dholbach> opny: that should be fixed in snapcraft 2.1
<kyrofa> opny, is that snapcraft 1?
<opny> dholbach, kyrofa ok, 1.0.1
<kyrofa> opny, yeah, that fix is only in 2 I'm afraid
<dholbach> kyrofa: maybe the fix for bug 1537705 should be backported?
<ubottu> bug 1537705 in Snapcraft "too many open files when using a heap of parts of plugin autotools" [High,Fix released] https://launchpad.net/bugs/1537705
<opny> kyrofa, where may I update my snapcraft to 2.0? git?
<dholbach> opny: where did you install snapcraft from?
<opny> dholbach, ppa as per docs
<sergiusens> kyrofa, while you are at it https://github.com/ubuntu-core/snapcraft/pull/289
<opny> dholbach, ppa:snappy-dev/tools
<dholbach> kyrofa, sergiusens: ^ where do we land snapcraft 2.x?
<sergiusens> dholbach, nice that you made kyrofa the official backporter
<sergiusens> dholbach, only on xenial
<sergiusens> dholbach, 2.x is only on xenial
<kyrofa> sergiusens, haha, I'm the 1.x maintainer, remember?
<dholbach> kyrofa: what what? I just asked him because he had just responded in the same context :-)
<sergiusens> or we break all 15.04 users; I'm not sure we will backport as soon our deps to xenial will increase
<dholbach> don't blame me for giving kyrofa all the hard work
<opny> is there a vagrant box for xenial ?
<ogra_> sergiusens, it wouldnt work anyway since the concept changed drastically between 15.04 and xenial
<kyrofa> opny, the side effect of using Snapcraft 2 is that you can only target 16.04 Snappy
<dholbach> sergiusens: isn't it just https://github.com/ubuntu-core/snapcraft/pull/268/files that needs backporting?
<sergiusens> dholbach, yes, I was replying in the context of where we publish 2.x
<sergiusens> dholbach, and I said, only xenial
<ogra_> dholbach, xenial snapcraft produces squashfs snaps by default .... there is no support for that setup in 15.04 images
<kyrofa> sergiusens, happy to backport if you give the OK
<dholbach> sergiusens: ok
<sergiusens> dholbach, backporting things from 2.x to 1.x should be ok :-)
<dholbach> ogra_: I know
<sergiusens> kyrofa, go ahead
<dholbach> guys... I was never suggesting we should backport EVERYTHING
<sergiusens> everyone calm down and keep on rolling :-)
<kyrofa> opny, thanks for catching that, I'm on it
<ogra_> well, we should ... but only if 15.04 stable goes EOL
<ogra_> which should happen with the xenial snappy release as i understand
<opny> kyrofa, no problem, I'm good a breaking stuff :)
<dholbach> ok... too many threads of discussion at the same time ;-)
<kyrofa> Hahaha
<kyrofa> sergiusens, is https://bugs.launchpad.net/snapcraft/+bug/1541353 the same issue you noticed?
<ubottu> Launchpad bug 1541353 in Snapcraft "'snapcraft upload' says 'Invalid package filename.'" [Undecided,New]
<opny> btw, is there a xenial image for amd64 and/or arm I can pick ?
<sergiusens> kyrofa, yeah, not sure why `-` is not allowed; maybe pindonga knows
<ogra_> kyrofa, thats just because dholbach produces that -buggy package ;) snapcraft is clever, wont let buggy things in ;)
<kyrofa> opny, yeah http://people.canonical.com/~mvo/all-snaps/
<sergiusens> kyrofa, that's going to 2.2; I'll release it while camping during carnaval ;-)
<opny> kyrofa, thank you. Is qemu for arm known to work?
<kyrofa> opny, I've used it, though it's dog slow
<ogra_> i dont think we actually produce usable snappy images for qemu-system, do we ?
<ogra_> (armhf thatis)
<pindonga> kyrofa, sergiusens in snapcraft/storeapi/_upload.py there's a regexp for validating the pkg file name
<pindonga> - is valid for name
<pindonga> so maybe the pkg is missing version or arch?
<kyrofa> pindonga, any ideas on bug #1541353 ?
<ubottu> bug 1541353 in Snapcraft "'snapcraft upload' says 'Invalid package filename.'" [High,Triaged] https://launchpad.net/bugs/1541353
<pindonga> kyrofa, we need to find out what the built pkg name is
<opny> ogra_, I've tried on 15.04 but network was never picked up and cloud-init failed
<ogra_> opny, oh, with what cpu emulation did you run qemu ?
<plars> ogra_: around? If you get a chance at some point, I was curious if you had any thoughts about installing snappy on db emmc via fastboot
<noizer> kyrofa do you already any idea with my problem :p
<kyrofa> ogra_, oh, I was just answering a general "yes, qemu can emulate arm" :P
<sergiusens> pindonga, kyrofa I say we remove the regexp, we already have a regexp when we json schema de hell out of it
<ogra_> kyrofa, yeah, vexpress and omap3 ;)
<kyrofa> noizer, I'm looking at it now
<pindonga> sergiusens, fine with me
<noizer> kyrofa htx xD
<kyrofa> sergiusens, I thought the regex was for extracting the name, not actually _validating_ anything
<pindonga> sergiusens, the regexp here was jut to avoid a failure after the file was uploaded (ie, during the scan)
<sergiusens> pindonga, in the case of dholbach's bug we might need the full yaml
<opny> ogra_, armhf https://github.com/muka/qemu-snappy-experiments#2-use-ubuntu-snappy-not-working
<pindonga> ie, a quick sanity check to avoid uploading the file only for the store to fail later
<ogra_> plars, only vaguely, i try to not touch any internal disks with our images until we have a recovery installer ... but it shouldnt be hard to modify the EMMc bootloader
<sergiusens> pindonga, yeah sounds good, but we fail on the yaml as soon as we load it, so its blocked earlier; I'd be fine with checks, but these regex's have changed so often I got weary of them :-)
<dholbach> sergiusens: attached: https://launchpadlibrarian.net/236141324/snapcraft.yaml
<plars> ogra_: all I'm really looking for is an automated way to provision it, regardless of what was on it before
<pindonga> sergiusens, I'm not opposed to removing the filename check
<pindonga> sergiusens, my bet is what's confusing the regexp is the - in the version
<ogra_> opny, yeah, you dont really want that ... what would work would be an image thats actually designed for vexpress ..  you cant just re-puropse a rpi image for this
<sergiusens> dholbach, try removing the - from the version (or change it to `.`)
<plars> ogra_: another option, of course, is using the sd to boot from. But the only control I've found over the sd so far is via the hard switch on the bottom of the board, which is going to be flaky to solder to
<pindonga> also, the yaml doesn't include an arch, is that correct?
<sergiusens> pindonga, not this one, the internal one has that; I don't think that is the problem as I've uploaded just fine
<dholbach> sergiusens: that made it work
<pindonga> sergiusens, all that said, I completely agree regexpes are a pain to maintain
<pindonga> up to you to remove it
<sergiusens> so confirmed, it is just the version check
<plars> ogra_: but it does look like I can probably get into fastboot automatically somehow, via the reset button controlled from the uart board, and power control. If I could use that to install to the emmc reliably, it would be something to consider
<ogra_> plars, you just need to replace the content of the "boot" partiton on the eMMC with a working u-boot binary ... the rest shoudl be scripting .... well and probably invalidate the u-boot on the SD, then it will always fall back to the internal uboot
<ogra_> nothing to solder here
<mvo> sergiusens: you mentioned an incorrect service file the other day that had no %h in the SNAP_USER_DATA - what snap was this again?
<opny> ogra_, ok thanks, has been interesting anyway
<plars> ogra_: I'd like to stay as close as possible to what u-d-f generates though, and not have to change the image we're testing
<ogra_> plars, well, u-d-f ignores the fact that an eMMC exists
<plars> ogra_: so booting an unmodified sd image would mean I need it to really boot from the sd
<ogra_> it will always focus on SD only
<plars> apparently that's controlled by gpio_81, but it doesn't seem to be exposed anywhere else as far as I can tell
<sergiusens> mvo, that was kyrofa ^
<sergiusens> mvo, so I mentioned, kyrofa has the issue
<ogra_> plars, did you ask in the #96boards channel ?
<plars> but if the image on the sd is bad, or if I need to overwrite it, I would need it to go back to booting something stable off the emmc
<kyrofa> mvo, o/
<plars> ogra_: not yet, some of this is pretty specific to snappy I think
<sergiusens> kyrofa, upload your snap to people.canonical.com if you can
<ogra_> plars, right, thjats automatic
<dholbach> pindonga: do you know which rev of click-reviewers-tools is used in myapps right now?
<kyrofa> sergiusens, sure thing
<ogra_> if the SD is broken my board here always falls back to eMMC in any case
<ogra_> which is why i said you can just use a clever u-boot on the MMC ... that could pull a new SD image and write it for example ... just invalidate the bootloader on the SD at the end of your test
<plars> ogra_: but I also need it to fall back if I'm trying to put a new image on there, so I'd like to have more control over it... or are you saying that for that, we should just dd some zeros to the sd card boot part to make it bad?
<ogra_> ... and a reboot would get you into the MMC uboot
<sergiusens> dholbach, btw, we have planning meetings on Friday's with kyrofa and elopio for snapcraft; someone once mentioned we could open those up to the public; I have to quarrel against that
<pindonga> dholbach, 567
<plars> ogra_: gotcha
<dholbach> pindonga: can you pull again?
<ogra_> plars, yeah, even just into the first partition of the Sd should be enough
<pindonga> dholbach, on prod, on staging we're on 572
<sergiusens> dholbach, I just have one requirement; hands off keyboard unless you are the triager
<opny> Let's say I would like to create an UI via a snap to handle networking or create an access point. Do you think is feasible via a snap?
<plars> ogra_: actually, right now with the snappy image, I only get one boot out of it. any boot after that goes to the emmc. Is that a known issue?
<dholbach> pindonga: 572 sounds great
<pindonga> right, we just need to deploy to prod
<pindonga> but you can test on staging
<kyrofa> sergiusens, who mentioned that?
<ogra_> opny, what kind of UI ... web-UIs surely work already
<sergiusens> opny, check the mir guide on the developer site
<dholbach> sergiusens: you quarrel against the calls being public? I'm not sure I understand
<sergiusens> kyrofa, not you; it was mentioned in one of the community hangouts
<kyrofa> sergiusens, oh interesting
<sergiusens> dholbach, oh, in one of the community things (video, text, something) someone mentioned making planning public
<sergiusens> dholbach, I thought it was you
<opny> ogra_ yes a web ui, with simple shell commands or more advanced (networkd?)
<sergiusens> dholbach, I am saying I don't mind if our planning meetings are public and open to everyone
<dholbach> ah ok, cool :)
<dholbach> yeah, let's think about how we can do that best
<sergiusens> dholbach, streamed is fine; joining the hangout has 2 reqs, hands off keyboard and see your face
<sergiusens> dholbach, seeing the face is a bit controversial; but it is sort of necessary to keep the face to face value
<opny> sergiusens, mir-snaps ?
<ogra_> opny, afaik there is a network-manager snap in the works ... i guess you could create another snap that talks to it via snapd on a socket or local network port to manipulate networking via snappy config then
<sergiusens> dholbach, and seeing someone's face provides a lot of feedback
<dholbach> I like that
<mvo> ogra_, ppisati: silly question, it appears that am335x-boneblack.dtb is not/no longer part of the kernel tree in xenial? do you happen to know about this? or am I looking at the wrong place?
<dholbach> yes, I agree
<noizer> kyrofa sorry i cant follow xD let me know when you have a sollution
<ogra_> mvo, oh, i havent touched the BBB in ages
<kyrofa> noizer, will do
<sergiusens> opny, yes https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
 * ogra_ has to defer to ppisati 
<rickspencer3> if I am running xenail, just $sudo apt-get snapcraft will get me and keep me on the latest, right?
<sergiusens> dholbach, speaking of that we should probably take this from mhall and put this into our repo https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<ogra_> rickspencer3, yes
<sergiusens> or it will get outdated fast
<sergiusens> rickspencer3, correct
<mvo> ogra_: no worries, I just wanted to build a "community" maintained one with all snaps and this is my blocker right now
<rickspencer3> thanks ogra_ and sergiusens
<ogra_> mvo, are you sure you grabbed the right binary ?
<dholbach> sergiusens: I'll file a bug for it - I have like 5 things I'm doing at the same time right now :)
<opny> sergiusens, ok nice but what is mir in practice? is it a webcontainer?
<mvo> ogra_: not entirely, I was still using the artifact from cdimage
<opny> sergiusens, found.. sorry
<ogra_> ogra@anubis:~/datengrab$ dpkg -x linux-image-4.4.0-3-generic_4.4.0-3.17_armhf.deb unpack/
<ogra_> ogra@anubis:~/datengrab$ find unpack/ -name am335x-*|grep boneblack
<ogra_> unpack/lib/firmware/4.4.0-3-generic/device-tree/am335x-boneblack.dtb
<ogra_> ogra@anubis:~/datengrab$
<ogra_> mvo, ^^^
<ogra_> seems to be there
<mvo> ogra_: hmmm, thanks, I will find out what is causing this
<ogra_> (thats the latest xenial binary package)
<sergiusens> dholbach, kyrofa https://github.com/ubuntu-core/snapcraft/pull/290
<kyrofa> jdstrand, I use your overlay notes every day, by the way
<sergiusens> opny, a display server
<sergiusens> opny, you have to be clear when you say ui ;-)
<sergiusens> opny, if youwant to do something over the web; just use nodejs or go or something you like (look at gopaste or shout in the snapcraft examples)
<mvo> ogra_: found the issue, I'm an idiot
<mvo> ogra_: but thanks!
<zyga> mvo: never, you are just tired :)
<ogra_> mvo, i disagree !!!
<kyrofa> mvo I just PMd you a link to the snap in question
<opny> sergiusens, awesome stuff! Yes I meant the web, sorry :) My doubt is how can I then interact with eg. if* or ip route or iptables et like
<opny> sergiusens,  with custom apparmor profiles?
<ogra_> opny, there is a ufw snap already
<ogra_> you shoudl be able  to talk to it via snapd or some such ... jdstrand might be able to tell you more
<ogra_> (for firewall config that is)
<kyrofa> mvo, adding an echo to the binary wrapper for ros-example.listener, you can see that SNAP_USER_DATA looks fine. But if you add an echo to $SNAP/command-rosmaster.wrapper (which is launched by systemd) it's missing the home directory
<sergiusens> kyrofa, walking back home to make it for standup
<kyrofa> sergiusens, sounds good
<sergiusens> hopefully the ci tests finish running by then
<opny> ogra_, ok thanks. Seems I need to upgrade to 16.04 first
<kyrofa> mvo, rather, the home directory seems to be /
<kyrofa> mvo, so echoing $SNAP_USER_DATA in the service wrapper gives me //snaps/ros-example.sideload/ILcTLfMVPLca
<opny> is there any documentation about 16.04 and topics like snapd or similar ?
<wiggleworm> Can someone point me to documentation on how to set a static ip address when using a wifi connection
<ogra_> opny, i guess Chipaca can point you to any snapd docs if they exist
<ogra_> wiggleworm, http://people.canonical.com/~ogra/snappy/dragonboard/README has some syntax for how to set up wifi with DHCP ... see "man interfaces" on an ubuntu desktop/server for the static part
<wiggleworm> ogra_ - thanks - so standard desktop settings for wifi should work for Snappy?
<opny> ogra_, is the source in launchpad?
<ogra_> wiggleworm, snappy uses /etc/network/interfaces.d â¦. so yes :)
<ogra_> opny, on github i think
<wiggleworm> thank you
<opny> Chipaca, hello, I was looking for docs about snapd. Do you have anything I could be read about it? Thanks
<opny> May use dbus for IPC in a set of snap I would build?
<wiggleworm> Can someone show me where on the snappy\Canonical site I submit my snap to the store?
<ogra_> wiggleworm, https://myapps.developer.ubuntu.com/
<ogra_> (you need to create an account first)
<wiggleworm> thank you - I found that site and it did not say it was for Snappy as well - good to know - thank you
<elopio> sergiusens: kyrofa: http://autopkgtest.ubuntu.com/packages/s/snapcraft/
<elopio> what's tricky is the s.
<kyrofa> elopio, ah! Favorited
<kyrofa> elopio, thank you :)
<sergiusens> dholbach, [ubuntu/xenial-proposed] snapcraft 2.1.1 (Accepted)
<dholbach> sergiusens: good work! :)
<sergiusens> dholbach, I hope the autopackage tests really work this time, we are so close
<dholbach> crossing fingers then :)
<jdstrand> didrocks: fyi, /var/lib/snappy/apparmor/profiles is not the right directory for 15.04. you are looking for /var/lib/apparmor/profiles
<jdstrand> didrocks: pcoca and I discussed the issues you guys were having. it seems you guys didn't see the notes for 15.04. I gave him all the info
<jdstrand> didrocks: as for rebuilding all the profiles on 15.04, you use 'sudo aa-clickhook -f'
<didrocks> jdstrand: excellent! Thanks a lot :) (I think we still have a cryptic issue as aa_exec_one or such error without any further info), but we'll keep you posted
<jdstrand> kyrofa: re overlay: cool! :)
<didrocks> jdstrand: oh great! (we should maybe add a symlink to aa-snappyhook :p)
<kyrofa> Chipaca, the other day you mentioned the ability to `snappy shell foo`. But it seems it only works for classic, not any other app. Did I misunderstand?
<jdstrand> opny (and ogra_): ufw is an 'app' snap, not a framework. snapd (or anything else in snappy does not expose interfaces for an app to drive in this manner
<jdstrand> opny: in other words, you need to do both the web frontend and the iptables/etc backend
<ogra_> jdstrand, oh, no snappy config interface you coudl use ?
<jdstrand> didrocks: are you trying to execute things from /apps/bin from you snap?
<ogra_> (if it exposes snappy config it should also be manageable through snapd)
<jdstrand> ogra_: ufw only has rudimentary snappy config. it will likely get some more, but that isn't exposed to other snaps, only the admin
<ogra_> ah
<didrocks> jdstrand: no, it's a systemd service, so it's a little bit more convoluted to debug
<jdstrand> I guess snapd could be used to drive such config, but that is a larger discussion that is happening with ricmm, et al. the whole networking story needs to be defined and then we can see if ufw fits, it at all
<jdstrand> (atm, I can only imagine this as shoehorning ufw, so not sure that is the way to go)
<jdstrand> anyhoo, that is being discussed elsewhere
<ogra_> yeah, i would imagine you can use snapd for this or even just a socket or network port directrly if the snap exposes it .... to flange a UI onto a snap
<ogra_> (from another snap)
<ogra_> after all it would just be talking to localhost here
<jdstrand> didrocks: if you give me the error, I can probably point you in the right direction. an aa-exec error is likely one of two things-- you are trying to execute something in /apps/bin rather than from SNAP_APP_DATA or the profile isn't loaded
<jdstrand> that flanging needs to happen in a very controlled manner, since it breaks application confinement
<jdstrand> ogra_: ^
<ogra_> sure, there needs to be auth or even the bottom servioce snap should define if thats allowed at all
<didrocks> jdstrand: will do for sure, thanks for hanging with us ;)
<ogra_> but in my imagination i can create a gadget snap that pulls in a handfull of service snaps and one UI snap on top that can manage the others
<ogra_> to c4reate my product
<mvo> jdstrand: fwiw, I pushed a bbb all-snap image too, I know you have some of those :)
<jdstrand> mvo: woo! I do :)
<jdstrand> mvo: thanks :)
<mvo> yw
<opny> jdstrand, ogra_ thanks. I'm looking on how to handle various configuration needs (over http ui). Currently thinking to have rest http proxy to dbus-connected handler/api, if this may work!?
<jdstrand> mvo: curious (and this is just curiosity since I have a device that would be fun to move to snappy for 16.04, but I can continue to use server), are we going to have i386 snappy images for 16.04?
<jdstrand> opny: you can do that within your snap, yes. you provide the dbus service backend and you provide the webui, then the webui can talk to the dbus service
<jdstrand> mvo: why can't I ever remember the answer to that question?
<jdstrand> mvo: you don't have to answer the 2nd question :)
<beuno> jdstrand, yes, i386 will be one of the supported archs
<jdstrand> oh, nice! :)
<beuno> 32 and 64bit intel
<jdstrand> \o/
<beuno> 32 and 64 bit arm
<ogra_> now we just need properly supported i386 images :P
<xnox> ogra_, beuno - why 32 bit? even atoms are 64-bit these days.
<xnox> (i386 that is)
<ogra_> xnox, to annoy you and to undermine your attempt of dropping i386 images indeed ;)
<beuno> yes.
<genii> "because we can"
<ogra_> xnox, we dont really have i386 images ... (we produce the artifacts and you can use ubuntu-device-flash to roll an i386 img file, but they are not tested or supported or anything )
<ogra_> so no worries :)
<beuno> but we will have to produce them for 16.04
<opny> jdstrand, Great.. Still, I miss one last thing.. if the snap is confined can I alter eg. interfaces.d/ files? I will need custom apparmor profilles?
<ogra_> there *are* intel 32bit only IoT platforms though
<beuno> ogra_, 32bit intel is very much a supported architecture for 16.04
<beuno> officially supported and tested
<ogra_> beuno, oh, thats news to me
<beuno> if that doesn't match reality, reality needs to be fixed
<xnox> ogra_, beuno, genii - you people hate the planet, build time, and CO2, and waste bandwidth budget =)
<ogra_> well, reality is that the hardware is rare :)
<beuno> xnox, some people use it as heat in their homes!
<ogra_> xnox, thats why i own three porsches ... indeed i do :P
<xnox> ogra_, can i hi-jack one, for testing purposes?
<ogra_> even two ;)
<ogra_> beuno, who came up with that ? sabdfl ?
<ogra_> i think actual i386 only HW is really rare
<olli> ogra_, our commitment is to deliver 4 reference images
<olli> which include 32bit intel
<genii> 32bit VM is more efficient and less wasteful than a 64bit VM
<mvo> jdstrand: I will clarify about i386 but we can certainly have unofficial ones
<ogra_> not sure what testing on 64bit HW will actually gain us to validate these images
<beuno> mvo, we totally, 100% have committed to having official i386 ones
<ogra_> beuno, and do we know how we will test them ? (we should have actual i386-only HW for that)
<ogra_> or do we think kvm testing will be enough
<beuno> ogra_, I don't know specifically, I'd expect you fine folks to come up with a great plan!
<beuno> we can help where needed
<mvo> beuno: oh, cool
<olli> mvo, ogra_ I would expect that the key target for 32bit intel is a VM so I am not sure we need to worry about the HW aspect
<ogra_> well, thats a QA question indeed .... i just wonder how valid such testing actually is if we dont use actual HW
<ogra_> or re-purpose 64bit HW for that
<ogra_> olli, ok
<mvo> beuno: thanks!
<olli> ogra_, I am already talking w/ slangasek about all the official images
<ogra_> that cealrifies it :)
<ogra_> *clearifies
 * olli offers "clarifies"
<olli> :)
<ogra_> olli, if the target is just 4 we should drop i386 for MIPS instead ;)
<ogra_> (will also make 4 in total then)
<kyrofa> I know of at least one company that uses 32-bit hardware and have asked me about i368 support in Snappy
<ogra_> ah, good
<ogra_> if there is demand and we can actually validate the images proper thats indeed fine
<beuno> ogra_, and cloud instances
<beuno> which is a pretty big market  :)
<kyrofa> ogra_, indeed, let me know if you need someone to give it a test drive and I can ping them
<ogra_> beuno, thats curious ... assuming the underlying HW is most likely 64bit i wonder what that gains you ?
<ogra_> slightly less ram use due to smaller binaries  ?
<jdstrand> ogra_, xnox: fyi, I administer a few actual 32 bit boxes. I'm asking cause one would be neat for snappy and it is not ancient (only a few years old)
<kyrofa> opny, any chance you could share the YAML that opened too many file descriptors?
<kyrofa> opny, I need a test case and the one I thought I had isn't breaking (hate it when things don't break correctly)
<opny> kyrofa, sure
<opny> kyrofa, here it is https://github.com/muka/rethinkdb.snap/blob/master/snapcraft.yaml
<kyrofa> opny, excellent, thank you!
<opny> kyrofa, has gone broken after adding build-packages list
<kyrofa> opny, but there's no build-packages in here
<opny> kyrofa, sorry I pushed my current stuff
<kyrofa> opny, I need stuff that makes snapcraft barf. Maybe push into a temporary branch?
<opny> kyrofa, here it is
<opny> kyrofa, in master, it's broken anyway
<kyrofa> opny, oh, I misunderstood-- I thought you said adding the build-packages made it break
<kyrofa> opny, so what you gave me should fail?
<kyrofa> opny, I'll give it a shot
<opny> kyrofa, I moved from stage-* to prod-* and python error popped out
<opny> kyrofa, Maybe I've used the wrong syntax?
<kyrofa> opny, prod-*? you mean build-*?
<opny> kyrofa, yes sorry...
<kyrofa> opny, that makes sense-- build-packages aren't installed the same way, so that should "fix" the fd leak
<kyrofa> opny, you understand the difference between stage- and build-packages?
<opny> kyrofa, not sure, they are 2 different phases and in stage I can hack stuff... right?
<kyrofa> opny, not quite-- check this out: https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
<kyrofa> opny, stage-packages get staged and end up in the final .snap. build-packages actually get installed on the host
<kyrofa> opny, so for example, if you wanted to keep your snap as thin as possible, have the -dev packages as build-packages, and runtime-only packages as stage-packages
<kyrofa> opny, what version of Ubuntu are you using to run Snapcraft?
<opny> kyrofa, I'm on 14.04 and used snapcraft 1.0.1. Now I'm trying to jump to 2.x with no luck..
<kyrofa> opny, hmm... I'm getting 404s when trying to get the packages
<opny> kyrofa, the docs on github are far more clear than on the ubuntu website
<opny> kyrofa, I messed badly on that..
<kyrofa> opny, dholbach has been working on making them autosync
<dholbach> kyrofa: we're still struggling with the deployment :-(
<dholbach> we're still very close
<kyrofa> dholbach, so close! That's alright, we'll get there :)
<opny> kyrofa, dholbach formatting seems still a bit incoherent
<kyrofa> opny, formatting of the github docs?
<opny> kyrofa, no on github is pretty structured. (This is the source of my snap https://www.rethinkdb.com/docs/install/ubuntu/#get-the-build-dependencies)
<opny> kyrofa, actually on ubuntu ws is pretty fine either (https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/). It's almost a RTFM problem :)
<opny> kyrofa, may I ask you how to get snapcraft 2.x ? I've tried from git / python setup.sh but error arise after install
<kyrofa> opny, it only works on xenial
<opny> kyrofa, it's ok for me, would like to get the most up to date stuff to work on
<kyrofa> opny, it's easy then-- install xenial and `apt-get install snapcraft`
<opny> opny, oh.. you mean I must run xenial not "snappy xenial"
<opny> kyrofa, oh.. you mean I must run xenial not "snappy xenial"
<kyrofa> opny, right
<ogra_> you can run snappy xenial and use the classic dimension though
<kyrofa> opny, both ways-- it only runs on xenial and it only builds packages for xenial
<kyrofa> opny, what ogra_ says is true as well
<ogra_> saves you from having to copy around your snaps and gets you the proper build for the architecture you  work on
<opny> kyrofa, ogra_ is it too early to try to install on my work pc (currently I'm stuck on 14.04 due to deps, will weep and move to 15.10 in the weekend )?
<kyrofa> opny, you can always put it in virtualbox
<kyrofa> (or similar)
<opny> kyrofa, ok, it is how I run snappy xenial. I'll keep it this way, so. Thank you!
<sergiusens> elopio, look at these https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/s/snapcraft/20160203_155457@/log.gz
<sergiusens> elopio, those are first time issues
<sergiusens> elopio, of course, new arch ;-)
<sergiusens> elopio, "s390x is not supported, please log a bug athttps://bugs.launchpad.net/snapcraft"
<sergiusens> elopio, yay, I have a bug in my "report a bug message" :-P
<elopio> sudo: no tty present and no askpass program specified
<jdstrand> mvo: so.. weird. I now see hello-world.canonical on a 15.04 bbb and a 15.04 amd64 vm 'upgrading' to 1.0.18 again
<elopio> I'm getting the same on the lxd runs.
<sergiusens> elopio, yeah, that too...
<jdstrand> mvo: this time, snappy list -u shows them as upgradable
<elopio> sergiusens: lol.
<jdstrand> mvo: note, that it stopped for a while yesterday. today it started 43 minutes ago
<jdstrand> matiasb: ^
<mvo> jdstrand: woah, no I need to check that on my bbb
<mvo> jdstrand: but dinner first
<mvo> jdstrand: fwiw, a i386 all-snap image is up now too
<matiasb> jdstrand, so, you have hello-world 1.0.18 installed, and it is trying to install it again?
<kyrofa> niemeyer, hey have you had a chance to go over that launching document?
<jdstrand> mvo: re i386> woo! :)
<jdstrand> matiasb: precisely
<jdstrand> matiasb:
<jdstrand> $ sudo snappy list -u
<jdstrand> Name          Date       Version
<jdstrand> ...
<jdstrand> hello-world*  2015-06-19 1.0.18
<jdstrand> Feb  3 10:00:21 cho systemd[1]: Started Ubuntu Core Snappy Autopilot.
<jdstrand> Feb  3 10:00:21 cho systemd[1]: Starting Ubuntu Core Snappy Autopilot...
<jdstrand> Feb  3 10:00:35 cho kernel: [1239804.724808] audit: type=1400 audit(1454515235.320:159): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="hello-world.canonical_usehw_1.0.18" pid=1234 comm="apparmor_parser"
<jdstrand> ...
<jdstrand> Feb  3 10:00:40 cho snappy[1165]: Name        Date       Version Developer
<jdstrand> Feb  3 10:00:40 cho snappy[1165]: hello-world 2015-06-19 1.0.18  canonical
<jdstrand> matiasb: snappy list -u output and syslog output
<matiasb> jdstrand, ack... that's weird, wondering how the update code decides it should update
<jdstrand> matiasb: the profile loads and the final to lines show it is installing
<jdstrand> yeah, not sure
<jdstrand> I find it particularly curious that it did it for several hours, then didn't, then is again
<jdstrand> (ie, yesterday, not last night, and just now)
<matiasb> yeah, that's really odd too
<mvo> matiasb: it uses the click-metadata endpoint and posts what it has to it
<jdstrand> Chipaca: hey, I just updated an allsnaps vm. snappy list doesn't show anything, even with -v. I expected the kernel, os and gadget snaps to be listed...
<matiasb> mvo, can you confirm you are passing the right arch/release headers when checking for updates? (since now we can return different values in those cases)
<mvo> jdstrand: uh, what image is that that does not show anything?
<jdstrand> mvo: amd64
<jdstrand> vm
<sergiusens> elopio, not sure if you are still bored with no tasks, but maybe you can run the snapcraft suite against the recently announced image ;-)
<jdstrand> mvo: Reboot to use ubuntu-core version 16.04.0-5.
<jdstrand> Reboot to use canonical-pc-linux version 4.3.0-2-3.
<kyrofa> sergiusens, are hyphens not allowed in the version?
<mvo> jdstrand: oh, you upgraded from an older all-snaps image to the latest?
<jdstrand> after reboot, I don't see anything
<sergiusens> kyrofa, they should be
<kyrofa> sergiusens, ah okay
<jdstrand> mvo: well, older-- I mean, it isn't terribly old
<mvo> jdstrand: is it more than a day old ;) ?
<sergiusens> kyrofa, schema/snapcraft.yaml has the correct things
<mvo> jdstrand: if so, its old :P
<elopio> sergiusens: no bored at all now. But that's just a command.
<jdstrand> it is more than 1 day old :)
<mvo> jdstrand: but seriously, there are some compatiblity issues because of the snap.yaml transition
<jdstrand> ok, let me just nuke that and create a new one
<mvo> jdstrand: I *think* some of this can be fixed, I need to look into the details in the morning
<jdstrand> no worries. just wanted to make sure it was expected
<mvo> jdstrand: I have not fully investigated what it takes
<mvo> matiasb: I will have to debug this by creating the right image etc, probably tomorrow morning
<matiasb> mvo, ack, let me know; I guess a possible confusion may be that if the headers are missing, we are returning there is an update (latest published revision), but then when requesting the package details passing the right headers, the latest available version for your config is returned (being the same you have already installed)
<jdstrand> didrocks: fyi, I updated https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement and it has a link to https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04. in the 16.04 doc cleanup, had some circular references (ie, snappy docs pointed to wiki and wiki pointd to snappy docs) for security-override
<jdstrand> didrocks: I told pcoca I would fix the docs, but he is offline atm, so letting you know :)
<mvo> matiasb: that sounds plausible, so we need to post to click-metadata "hello-world/edge" instead of "hello-world" ?
<mvo> matiasb: hm, actually we are doing this
 * jdstrand notes that both images are ubuntu-core/15.04/stable
<jdstrand> mvo: ^
<jdstrand> s/images/devices/
<mvo> jdstrand: \o/
<mvo> jdstrand: that might be it
<plars> dragon
<plars> err
<matiasb> mvo, you should pass the release and arch headers to click-metadata, to get the right latest version available for those arch/release, besides channel
<sergiusens> mvo, you joining the ho?
<plars> mvo: no dragonboard image for the new release?
<mvo> sergiusens: what HO?
<didrocks> jdstrand: excellent! Thanks a bunch :)
<sergiusens> mvo, the one david setup up
<mvo> matiasb: the code says we are doing this
<matiasb> mvo, ok, if that's the case, the issue is something else then
<sergiusens> elopio, seems there are still issues http://autopkgtest.ubuntu.com/running.shtml#pkg-snapcraft
<kyrofa> sergiusens, take a look at https://github.com/ubuntu-core/snapcraft/pull/291 when you have a sec? The backport wasn't quite as clean as I'd hoped, so I'd like a double-check
<niemeyer> kyrofa: I haven't, sorry.. I'll try to get to it before the end of my day tomorrow the latest
<niemeyer> kyrofa: With some chance of getting it done today still
<niemeyer> kyrofa: Sorry I didn't get to it before
<kyrofa> niemeyer, oh that's alright :) . Just a bug that keeps biting me!
<jdstrand> Chipaca: fyi, latest allsnaps image I tried to configure timeezone and have: $ sudo snappy config ubuntu-core /tmp/c
<jdstrand> unable to create /etc/localtime: open /etc/localtime: read-only file system
<jdstrand> Chipaca: known? should I file a bug?
<Chipaca> jdstrand, buuuuuuug
 * jdstrand files
<ogra_> i think we have one for that
 * ogra_ goes digging
<jdstrand> ogra_: https://bugs.launchpad.net/snappy/+bug/1541521
<ubottu> Launchpad bug 1541521 in Snappy "latest all snaps image does not allow configuring timezone" [Undecided,New]
<jdstrand> ogra_: I just filed that
<ogra_> yeah, the bug i remembered was for /etc/timezone
 * ogra_ adds a livecd-rootfs task
<jdstrand> ogra_: I don't suppose you'd be interested in fixing bug #1504657 and bug #1504645 while you are at it?
<ubottu> bug 1504657 in ubuntu-core-config (Ubuntu) "ntp servers should be configurable on snappy" [Medium,Confirmed] https://launchpad.net/bugs/1504657
<ubottu> bug 1504645 in ubuntu-core-config (Ubuntu) "please add syslog support to snappy config ubuntu-core" [Medium,Confirmed] https://launchpad.net/bugs/1504645
<ogra_> jdstrand, i totally am but i have some more importanmt tasks atm ... they are on my list to fix before 16.04 in any case
<ogra_> hmm,. i havent seen the last one yet
<ogra_> oh, i have :P
<jdstrand> ogra_: thanks
<kyrofa> sergiusens, elopio what's wrong with my migration skill here? http://paste.ubuntu.com/14868652/
<kyrofa> It doesn't like my security-policy
<sergiusens> kyrofa, nothing from what I see, but maybe this is more of a zyga question
<kyrofa> sergiusens, I get a snapcraft error on it though
<kyrofa> sergiusens, hold on
<sergiusens> oh, then it is probably a bug :-/
 * sergiusens is always confused on override, template and policy
<kyrofa> sergiusens, a json exception: "{'security-policy': {'apparmor': 'path/apparmor', 'seccomp': 'path/seccomp'}, 'type': 'migration-skill'} is not valid under any of the given schemas"
<kyrofa> sergiusens, but the json schema looked okay to me
<sergiusens> kyrofa, hmm, that is unit tested
<kyrofa> sergiusens, this is actually in another unit test. Let me push real quick and show you what's really going on
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/tests/test_yaml.py#L716
<kyrofa> sergiusens, yeah I saw that one, which doesn't help my confusion
<kyrofa> sergiusens, the test is still in development, but here: https://github.com/kyrofa/snapcraft/blob/bugfix/1524663/better_yaml_errors/snapcraft/tests/test_yaml.py#L335
<kyrofa> The SnapcraftSchemaError that's raised contains the error I pasted
<sergiusens> kyrofa, oh, remove mock_path_exists.return_value = False
<sergiusens> kyrofa, or change it to true
<sergiusens> kyrofa, this is what hits you https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L39
<kyrofa> sergiusens, that's actually what's under test here
<kyrofa> sergiusens, so that's the error I get from that? Sheesh!
<kyrofa> sergiusens, that's part of what I'm fixing, I just expected a different error I guess
<kyrofa> sergiusens, yeah you're right
<kyrofa> sergiusens, okay good, sorry about that. The test was failing for the reasons I expected, just not the _way_ I expected
<kyrofa> sergiusens, thanks for the help!
<didrocks> kyrofa: hey, we can't find your owncloud snap for 15.04 (which is without docker), are we missing something?
<didrocks> or it's not in the store and hidden in a git repo? :p
<kyrofa> didrocks, no it should be there
<ogra_> jdstrand, hmm, looking at the localtime issue thats actually caused by mvo's changes ... i'll see what i can do though
<didrocks> kyrofa: mind giving it a snappy search owncloud? (we only find the docker version there)
<ogra_> seems /etc/writable now lives inside the squashfs
<kyrofa> didrocks, for armhf it's `owncloud.kyrofa`, and amd64 it's `owncloud-amd64.kyrofa`
<kyrofa> didrocks, though multi-arch uploads were enabled yesterday, I'm actually working on making them both owncloud.kyrofa right now
<ogra_> kyrofa, does that still use docker ?
<kyrofa> ogra_, no
<ogra_> didrocks, note that docker snaps need docker installed first to even show you snaps using docker in snappy search
<didrocks> kyrofa: on pedro's box, it can't find it, weirdly
<sergiusens> kyrofa, np
<ogra_> ah, then nevermind
<didrocks> ogra_: yeah, we are trying the docker-less flavor
<sergiusens> didrocks, store has gone bonkers this week
<ogra_> didrocks, right, that should just show up
<kyrofa> didrocks, checking here, one moment
<didrocks> ahâ¦ that might be it
<didrocks> yeah, double confirmation will never hurt :)
<kyrofa> didrocks, huh, yeah I'm seeing that too
<sergiusens> didrocks, https://uappexplorer.com/app/owncloud.kyrofa  https://uappexplorer.com/app/owncloud-amd64.kyrofa
<sergiusens> matiasb, ^ 15.04; didrocks needs help
<kyrofa> didrocks, yeah myapps says it's published and stuff
<ogra_> ubuntu@localhost:~$ snappy search owncloud
<ogra_> Get https://search.apps.ubuntu.com/api/v1/search?fields=alias%2Canon_download_url%2Cchannel%2Cdownload_sha512%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Cicon_url%2Clast_updated%2Cpackage_name%2Corigin%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csupport_url%2Ctitle%2Ccontent%2Cversion&q=owncloud: dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:57121->[::1]:53: read: connection refused
<ogra_> WOAH !
<kyrofa> ogra_, oops...
<didrocks> ah, we didn't get that :)
<ogra_> thats a board with no network ...
<didrocks> we just got no output
<kyrofa> ogra_, hahaha
<ogra_> we really need to improve the error message ;)
<didrocks> and the board has network here :p
<kyrofa> didrocks, yeah no output here either
<didrocks> we can find and install the docker version
<didrocks> kyrofa: ah, we are not that crazy :)
<didrocks> even snappy install fails
<kyrofa> didrocks, must be store side
<didrocks> yeahâ¦ so, it's in the store, butâ¦ cannot be downloaded
<kyrofa> didrocks, apparently :P
<kyrofa> didrocks, curl https://search.apps.ubuntu.com/api/v1/package/owncloud.kyrofa
<didrocks> thanks for confirming sergiusens, kyrofa, ogra_ :)
<didrocks> oh good
<didrocks> let's do that
 * didrocks notes that down for later
<kyrofa> didrocks, err, owncloud-amd64.kyrofa
<didrocks> yeah, got it :)
<kyrofa> didrocks, sorry for the troubles!
<didrocks> no worry, and not your fault! ;-)
 * ogra_ files bug 1541530
<ubottu> bug 1541530 in Snappy "the error message for not network connected devices when using snappy search is awkward" [Undecided,New] https://launchpad.net/bugs/1541530
 * jdstrand hrms at https://bugs.launchpad.net/snappy/+bug/1541529
<ubottu> Launchpad bug 1541529 in goget-ubuntu-touch (Ubuntu) "can no longer create 15.04 ubuntu-core stable kvm images with ubuntu-device-flash" [Undecided,New]
<sergiusens> jdstrand, that's a bug for mvo ;-)
<ogra_> jdstrand, works here when attaching --oem=generic-amd64
<jdstrand> Determining oem configuration
<jdstrand> Starting download of generic-amd64
<jdstrand> it seems to have found it
<ogra_> hmm, yeah, works even without it
<ogra_> i'm on trusty using the xenial u-d-f though
<jdstrand> I'm on xenial, trying xenial's and wily's udf
<ogra_> so probably something with the surrounding tools like kpartx
<didrocks> kyrofa: ok, we got it installed. Did you try to add more apps, like calendar and such?
<didrocks> kyrofa: it seems that it doesn't find anything that isn't installed by default
<kyrofa> didrocks, hmm, no, but I'll look into it!
<jdstrand> ogra_: plausible: kernel: [ 956.113096] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
<ogra_> yeah
<didrocks> kyrofa: great! :-)
<kyrofa> didrocks, it was a little interesting getting ownCloud confined while still allowing for apps to be installed and config changed, so I may have missed something there
<jdstrand> ogra_: downgraded kpartx and it worked fine
<didrocks> kyrofa: yeah, I wonder what's up. It seems that we can't find any apps that aren't enabled
<didrocks> so I guess some networking cap?
<ogra_> jdstrand, i blame xnox ... he secretly snaks in that s390 code everywhere in xenial ;)
<kyrofa> didrocks, except that you're able to reach it
<didrocks> kyrofa: yeah, so it acts as a server, maybe not as a client?
<didrocks> let's look at denials from apparmor
<kyrofa> didrocks, ah, interesting theory
<kyrofa> didrocks, yeah let me know! That would be an easy fix indeed
<jdstrand> hmm, seems I didn't have the latest kpartx from xenial
<ogra_> ah
 * jdstrand tries again with ubuntu12
<coretex__> hello. what is this? https://uappexplorer.com/app/canonical-i386.canonical
<coretex__> This package contains a simple gadget snap for i386 systems
<coretex__> what's a snappy gadget?
<ogra_> it is the gadget for building i386 images
<ogra_> a gadget is a snap that describes your device
<coretex__> oh :D i see
<ogra_> and defines what kenrel is used etc
<jdstrand> meh, ubuntu10 (what I had) was bad, ubuntu12 is fine
<ogra_> heh, fun
<jdstrand> stupid out of date mirror
<didrocks> kyrofa: nothing network-related, just spawning access to /usr/sbin and /usr/bin
<kyrofa> didrocks, darn
<didrocks> oh wait one sec
<didrocks> one complain about not having "network-admin"
<xnox> ogra_, no clue mate. what's s390? i don't touch that acient 31-bit port, i touch s390x only ;-)
<ogra_> lol
<ogra_> is the X meaning four wheel drive ? (like BMW )
<didrocks> kyrofa: maybe that's it? Would worth a try
<didrocks> kyrofa: I'm wondering btw how you get access to the network, there is no network-service caps
<kyrofa> didrocks, you get network-listener by default in 15.04
<didrocks> ah, that makes sense!
<kyrofa> didrocks, I believe that encompasses the server permissions that are broken out in 16.04 ( jdstrand would know better)
<kyrofa> didrocks, when are you demoing this?
<didrocks> kyrofa: we want to demo it for mwc
<kyrofa> didrocks, yeah, when is that?
<didrocks> 2 weeks and half?
<kyrofa> didrocks, alright let me finish squashing some snapcraft bugs and I'll get it working. Does https://github.com/kyrofa/owncloud-snap/issues/10 seem to sum up the issue?
<kyrofa> didrocks, if you notice any other issues please do let me know (or log them there) and I'll look into them as well
<jdstrand> didrocks: the caps are all different in 15.04. install snappy-debug, then do: snappy-debug.security list -i
<jdstrand> didrocks: network-client is added if you don't specify 'caps', otherwise, you need to use it or network-service
<didrocks> kyrofa: perfect, yeah :)
<didrocks> jdstrand: ah great, thanks for the head's up
<kyrofa> didrocks, I appreciate your giving it a spin
<jdstrand> also, the 16.04 ones are still in flux
<didrocks> yw! thanks for looking at it :)
<didrocks> jdstrand: yeah, for mwc, we are only focusing on 15.04 due to that (moving target)
<didrocks> jdstrand: ok, so stupid quesiton (don't find any answer on the wiki), for the override-security, is this an addition to the apps security or do we have to copy the whole template?
<didrocks> sorry, found an example on https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04
<didrocks> I guess we have to reset the policy group, as caps would be ignored
<matiasb> sergiusens, didrocks, still having issues with owncloud and 15.04? let me check
<kyrofa> matiasb sounds like the framework issue
<didrocks> matiasb: yep
<matiasb> kyrofa, hmm... that's supposed to be fixed
<kyrofa> matiasb, i.e. the fix to https://bugs.launchpad.net/click-package-index/+bug/1540409
<ubottu> Launchpad bug 1540409 in Click Package Index "Snappy packages show as available to install on the Ubuntu Phone" [High,Fix released]
<kyrofa> matiasb, it's the side effect of that fix
<matiasb> nessita, fyi ^?
<kyrofa> matiasb, sounds like snappy needs to use slightly different search params
<nessita> kyrofa, would you please summarize the issue? is not clear to me from the backlog
<matiasb> kyrofa, didrocks, so the issue is that owncloud can't be found in 15.04?
<kyrofa> nessita, fabian sent out an email yesterday warning of this-- I think you received it as well?
<nessita> kyrofa, yes, I did, but as far as I know snappy CLI would remove the framework on searches, for 16.04 and that solves "all issues"
<nessita> kyrofa, so I'm not sure what this specific issue is
<nessita> kyrofa, and for 15.04 the snappy search would behave just like before and will find all packages with framework 15.04
<nessita> we assume snaps for 15.04 will declare the 15.04 framework in the manifest.json (deprecated in 16.04, but required for 15.04) file
<kyrofa> nessita, hmm... I thought the problem was that the snap wasn't declaring a framework dependency anymore
<kyrofa> nessita, which was why it was showing up on the phone
<beuno> kyrofa, well, 16.04 isn't
<beuno> 15.04 is still?
<kyrofa> beuno, I'm checking now
<nessita> kyrofa, so the *snap* for 16.04 does not need to declare a framework, the snap for 15.04 has to declare the "classic" framework
<nessita> a snap for 16.04 *could* declare a framework and that will (should) not break anything
<kyrofa> nessita, the package that caused bug #1540409 to be logged was built for 15.04. I just checked the manifest, and it does actually have framework: ubuntu-core-15.04-dev1
<ubottu> bug 1540409 in Click Package Index "Snappy packages show as available to install on the Ubuntu Phone" [High,Fix released] https://launchpad.net/bugs/1540409
<kyrofa> nessita, which means the description isn't quite right
<kyrofa> nessita, it also means now I'm confused what the problem was, and what the problem is now :P
<matiasb> didrocks, maybe you can make it clear what's the issue you are having?
<kyrofa> matiasb, the symptoms of the problem now is that `snappy search owncloud` returns nothing
<beuno> kyrofa, and you have docker installed?
<kyrofa> matiasb, similarly, `snappy install owncloud-amd64.kyrofa` returns "package not found"
<kyrofa> beuno, this one doesn't require docker
<didrocks> I guess kyrofa summed it up well :)
<matiasb> kyrofa, and this is for which arch/release configuration?
<matiasb> didrocks, ^
<beuno> kyrofa, and you are on amd64, right?
<kyrofa> matiasb, amd64, 15.04
<beuno> promise?
<beuno> :)
<kyrofa> beuno, promise!
<didrocks> yeah, can be easily confirmed in a vm
<matiasb> kyrofa, fwiw, I just did a search using the arch:amd64 + framework:15.04-core and I'm getting the result there: owncloud-amd64.kyrofa
<kyrofa> matiasb, using the snappy tool?
<matiasb> kyrofa, https://pastebin.canonical.com/149070/
<matiasb> kyrofa, using the search API ^
<kyrofa> matiasb, yeah curl works fine-- it's definitely in the store
<kyrofa> matiasb, but all of a sudden hidden from snappy
<kyrofa> matiasb, worked fine last time I tried... maybe two days ago
<matiasb> kyrofa, ok... if I explicitly pass the framework, I don't see any results
<matiasb> kyrofa, so this may be related to the bug you mentioned before <- nessita, fyi (not sure if the above is the expected behaviour)
<elopio> sergiusens: kyrofa: can you make sense of this one? https://paste.ubuntu.com/14870696/
<kyrofa> elopio, sorry I can't scroll that far to the right
<kyrofa> elopio, in all seriousness, no clue
<elopio> oh wait, I got this. It happened last week.
<elopio> if only I had good memory...
<elopio> ah, update-ca-certificates
<matiasb> kyrofa, didrocks, ok, can you try again? it seems that the amd64 binary didn't have a framework set, so 15.04 will never find it
<kyrofa> matiasb, hey, there it is!
<matiasb> :)
<kyrofa> matiasb, so wait... what did you do exactly?
<matiasb> so, yes, it was related to the bug above
<matiasb> kyrofa, that particular version for amd64 didn't have a framework set
<ryanleesipes> Hello
<matiasb> kyrofa, since 15.04 is searching passing the framework, the package coudn't be found
<kyrofa> matiasb, ah, the version is messed up though-- that's a super old version
<kyrofa> matiasb, owncloud.kyrofa should be at kyrofa5 and be armhf
<kyrofa> matiasb, owncloud-amd64.kyrofa should also be kyrofa5 and be amd64
<matiasb> kyrofa, ah, also there is that, there are 2 owncloud packages
<matiasb> kyrofa, so let me check the other one, owncloud-amd64
<matiasb> kyrofa, ok, I see, we have the same issue with this one, let me set the framework; also, not sure what you want to do with the previous one?
<kyrofa> matiasb, I'm not sure I undersand. Previous one?
<matiasb> kyrofa, there are 2 diff owncloud packages; I fixed one (owncloud.kyrofa), the one appears in searches now, and I'm fixing the other (owncloud-amd64.kyrofa)
<kyrofa> matiasb, they're both valid, they predate the multi-arch support
<matiasb> kyrofa, so now you should be having 2 results when searching
<noizer> Hi guys just got a little question
<noizer> i got an issue with my c++ on snappy
<sergiusens> elopio, network error maybe?
<noizer> locale::facet::_S_create_c_locale name not valid
<noizer> thats the error
<kyrofa> matiasb, ahh, I'm seeing kyrofa1 because of the multiarch!
<matiasb> kyrofa, right, but one uploaded binary from the owncloud.kyrofa package is for the amd64 arch too
<kyrofa> matiasb, that's actually awesome
<elopio> sergiusens: no, outdated certificates on the slave.
<kyrofa> matiasb, yeah don't worry
<matiasb> kyrofa, right! :)
<noizer> but it sais you need to export LC_ALL="en_US.utf-8"
<kyrofa> matiasb, I'll upload a new one and unpublish amd64
<noizer> but does not work
<elopio> sergiusens: that was the only error with the all snaps image. I still need to run more binaries, but looks good.
<matiasb> kyrofa, sounds good, let me know if you need any help, I'll check with nessita and fabian about the issue, to confirm we are ok there
<kyrofa> matiasb, okay so... I'm confused. Are we building the .snaps incorrectly?
<kyrofa> matiasb, or is this still a store bug?
<sergiusens> matiasb, it really is only one result on clients as arch counts
<matiasb> kyrofa, no, no, this is related to the fact that snaps are not having a framework set anymore, but 15.04 snappy is still sending it to filter searches in the store
<sergiusens> elopio, nice work!
<kyrofa> matiasb, okay good deal
<sergiusens> elopio, yeah, network error includes certs :-P
<matiasb> sergiusens, right, arch counts, but here we have 2 diff packages with published versions for amd64
<elopio> sure :)
<sergiusens> matiasb, oh, ignore me then ;-)
<matiasb> np!
<sergiusens> elopio, I can't see the adt results for 2.1.1 anywhere; any direct link hidden anywhere?
<elopio> sergiusens: it's running
<elopio> http://autopkgtest.ubuntu.com/running.shtml
<sergiusens> elopio, ah, it wasn't on update excuses anymore
<sergiusens> these polling systems drive me nuts
<sergiusens> elopio, wow this is slow :-P
<elopio> it is, yes. So cool, all the dependencies running.
<kyrofa> didrocks, heads up-- as soon as it finishes building owncloud-amd64 will be going away, to be replaced with owncloud.kyrofa for both armhf and amd64
<elopio> sergiusens: one integration test left to fix. But what does it mean?
<sergiusens> elopio, there are 11 errors though FAILED (failures=1, errors=11)
<elopio> oh, and where are the logs for them :(
<sergiusens> elopio, needs to finish building afaik
<didrocks> kyrofa: good! thanks for the head's up
<kyrofa> matiasb, whatever you did, will it remain in effect when I upload new versions?
<matiasb> kyrofa, unless you explicitly set the framework in your 15.04 package, yes (because while 15.04 snappy passes the framework filter in searches, packages without frameworks set will be excluded)
<kyrofa> matiasb, okay yeah, I'm not doing anything with frameworks
<nessita> sergiusens, mvo wanted to confirm that snaps for 15.04 are still being built in the "old way", where the deprecated framework value is always set
<renat> Hi! It's Renat again=)
<renat> Currently I'm unpacking squashfs and building a snap using snapcraft
<renat> But today saw somewhere that it's possible to create a squashfs snap
<renat> Where I can read about it?
<sergiusens> nessita, they should be if on 15.04 and 14.04
<sergiusens> nessita, only people on 16.04 can ONLY build for 16.04/devel
<sergiusens> the only problem would be someone not using snapcraft
<sergiusens> going out of their way to do it
<sergiusens> our 16.04 snaps don't work on 15.04 anyways; so it is fine if they don't show up ;-)
<kyrofa> renat, yeah, Snapcraft 2 builds squashfs snaps
<kyrofa> renat, but they're only compatible with Snappy 16.04
<renat> It it documented anywhere?
<nessita> sergiusens, ack, thanks. I needed to confirm that 15.04 snaps (built with snapcraft) are always declaring the proper 15.04-dev1 framework
<renat> Sorry. Is it documented anywhere?
<kyrofa> renat, https://github.com/ubuntu-core/snapcraft/tree/master/docs
<sergiusens> didrocks, still here? mind looking at http://paste.ubuntu.com/14871051/ ?
<renat> kyrofa, thanks. Will try to find there
<didrocks> sergiusens: mind if I push it tomorrow morning (first thing)?
<sergiusens> didrocks, no worries, I have it locally already ;-)
<didrocks> good, will sponsor it after a quick review then!
<sergiusens> thanks
<camako> My snap is failing to build with the following output : http://pastebin.ubuntu.com/14871088/
<camako> This is in a clean xenial container image that I installed today
<camako> with snapcraft 2.1.1
<sergiusens> camako, try adding libc6-dev to our build-packages
<camako> sergiuens, thanks
<kgunn> sergiusens: so haven't had need to do look at help in a while...but snapcraft --help in a pretty clean lxc just gives
<kgunn> https://pastebin.canonical.com/149075/
<kgunn> guessing the "suggested" pkgs for snapcraft might solve this
<kgunn> ?
<kyrofa> kgunn, how exactly did you make that lxc?
<kyrofa> kgunn, it's because you're missing locale, so it tries to use ascii
<kyrofa> kgunn, but I've had trouble duplicating so I haven't been able to fix
<kyrofa> kgunn, as for why help needs utf8, that's another problem
<kgunn> kyrofa: from images.linuxcontainers.org
<kyrofa> kgunn, that's what lxd does, right?
<kgunn> kyrofa: yeah, well...it's one way
<kgunn> kyrofa: i originally learend/followed from
<kgunn> https://linuxcontainers.org/lxd/getting-started-cli/
<kgunn> sergiusens: did you write the cmake plugin?
<sergiusens> kgunn, no, only improved it a bit for out of source builds
<kyrofa> kgunn, I think that was mterry
<mterry> kgunn, heyo
<mterry> kgunn, I don't know if it's still recognizable from my version, but shoot
<kgunn> mterry: hey, so i've a belief, but camako makes me doubt... my belief is the the snapcraft cmake plugin doesn't magically take care of the fact your includes/libs your snap
<kgunn> builds against are going to be local to your snap project
<kgunn> cmake is still thinking that by default stuff is installed on the host
<kgunn> ...so you gotta tinker with all the pathing
<kgunn> but camako says, no it should be magic
<mterry> kgunn, I thought snapcraft set environment variables like CFLAGS or whatever that is magic
<mterry> kgunn, yeah I think it's usually magic
<kgunn> mmm
<mterry> kgunn, but I don't know how that magic works anymore  :-/
<kgunn> my experience has been far different...and i just thot it was "Expected of me"
<mterry> kgunn, I think the magic is in snapcraft itself, not cmake
<mterry> kgunn, *not the cmake plugin* that is
<mterry> kgunn, well then maybe I'm just out of the loop these days
<kgunn> around last nov, i actually had a mir snap building mir from source and i had to do some major tinkering
<kgunn> mterry: nothing wrong with being out of loop, but raises the question is it a bug?
<kgunn> but that's a question for sergiusens and others i suppose
<mterry> kgunn, yeah I dunno intended behavior these days
<mterry> kgunn, at the time, the intention was that it was magic I think, as long as the plugin could handle standard CFLAGS and such
<kyrofa> kgunn, indeed, CFLAGS should be set etc
<kyrofa> kgunn, https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L280
<sergiusens> kgunn, mterry the problem comes when using things like pkgconfig where you can only have one sysroot; I'm working on fixing that; I am also working on allowing to just use build-packages and really need stage-packages unless it is for a runtime/dlopen thing
<kyrofa> matiasb, so I uploaded a new version and verified it via curl, but snappy search is still showing me kyrofa1 as the only option on amd64
<matiasb> kyrofa, ack let me check, I guess you are missing the framework in this case too (you aren't using snapcraft for 15.04 to build the package, are you?)
<matiasb> kyrofa, there, it should be set now
<kgunn> sergiusens: ok, so at least i'm not crazy
<kyrofa> matiasb, yes I'm using snapcraft for 15.04, and I verified the framework was set in the manifest
<matiasb> kyrofa, hmm... that's weird then, because the uploaded version doesn't have a framework set
<kyrofa> matiasb, here is the contents of DEBIAN/manifest of the exact package I uploaded: http://pastebin.ubuntu.com/14871277/
<sergiusens> matiasb, kyrofa so framework was never set in package.yaml; it was only ever set in the internal control part of the deb 'manifest'
<kyrofa> sergiusens, yeah... we much have been missing each other every time?
<sergiusens> kyrofa, /me cannot parse
<nessita> sergiusens, with that info, I see 2 options: on parse, we either always use manifest.json for 15.04 snaps, or package.yaml also includes the frameworks
<nessita> (on the store side)
<matiasb> I see...
<kyrofa> sergiusens, I mean we were all talking different things :P
<sergiusens> nessita, it is not my call, I don't work on this, I just know how it works
<nessita> sergiusens, oh, who works on this?
<sergiusens> nessita, mvo, niemeyer and Chipaca ; we only started building snaps in snapcraft starting 2.0 for xenial
<nessita> sergiusens, so what's the recommded path to build snaps for 15.04? so I review what we are producing with that
<kyrofa> didrocks, owncloud-amd64 is no more
<sergiusens> nessita, apt-add-repository ppa:snappy-dev/tools on 14.04 or 15.04 or 15.10 and install snappy-tools; then you can use snapcraft (which shells out to snappy) or snappy directly
<didrocks> kyrofa: \o/
<nessita> sergiusens, right, my question is which is the recommended way to see if the framework is always set and in which file
<nessita> or, let me ask a different question:
<nessita> * can we always expect a valid manifest.json on 15.04 snaps?
<sergiusens> nessita, yes to manifest in 15.04 snaps
<sergiusens> using debclick and all that cruft
<elopio> oh, sorry kyrofa. I totally ignored your migration-skills question
<elopio> did you get it working? Not that I know how to fix it, just feeling bad for not replying :)
<kyrofa> elopio, yup, all good! Thanks though :)
<kyrofa> elopio, turns out the gross "invalid schema" error I was getting was actually the one I wanted to fix. It was just worse than I thought it was
<awe__> kyrofa, sergiusens, jdstrand, can someone give me a hand with 'migration-skill'? cutover for bluez?
<kgunn> sergiusens: curious, do you have a bug for the find_package/sysroot issue with snapcraft?
<sergiusens> kgunn, no; but if you create one it will move faster ;-)
<sergiusens> working on cleanbuild now
<kgunn> camako: ^
<kgunn> :)
<kgunn> camako: we might wanna include what to mod on our branch to exhibit the issue (since we've got a temp w.a.)
<camako> kgunn, gotcha.. creating now
<kgunn> thanks
<noizer> how can i execute this command
<noizer> export LC_ALL="en_US.utf-8"
<camako> kgunn, https://bugs.launchpad.net/snapcraft/+bug/1541620
<ubottu> Launchpad bug 1541620 in Snapcraft "snapcraft can't find modules installed under 'stage' dir" [Undecided,New]
<kgunn> thanks
<camako> yw
<sergiusens> camako, kgunn that is weird, it pkg-config is indeed looking for things in stage_dir; can you please add the sources, this should just work
<camako> sergiusens, sure
<elopio> I'm going to leave earlier today to attend a class on kicad an pcbs. Telegram if you need me. BBL.
#snappy 2016-02-04
<oobartez> what's the status of snappy becoming the default package manager in Ubuntu Desktop? anywhere on the net I could find some up-to-date info?
<oobartez> I'm pretty excited about the idea but it's difficult to find a central point with current status, or info on how to get involved in this particular project
<olli> oobartez, it's currently not plan of record for Ubuntu Desktop
<olli> once 16.04 is out we might start working on a modern rendition of Ubuntu, which will incorporate technologies from the phone and be snappy based, but there is no specific & detailed plan yet
<oobartez> ok, I understand it's a long haul, in the mean time I also found this: http://ubuntuforums.org/showthread.php?t=2312045&p=13432475#post13432475
<oobartez> still, I personally find it super interesting. are there any conceptual discussions going that I could dig through?
<anpok_> hm where is an up to date documentation on writing an oem snap?
<anpok_> the doc in developer.ubuntu.com/en/snappy/guides/oem differs from examples in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<anpok_> is it gadget or oem currently?
<anpok_> whats the immutable-config good for?
<dholbach> good morning
<JamesTait> Good morning all!  Happy Thursday, and happy Create a Vacuum Day! ð
<anpok_> oem_snap/bananapi_1.0_all.snap failed to install: Signature verification failed: No signatures, or no origin signature. (exit code 10)
<anpok_> trying to create a new image using a just recently created oem snap..
<noizer> Hi, I want to make some services in snapcraft 2.1 but when I do that it tells met services was unexpected
<noizer> http://pastebin.com/zmisT1nt
<noizer> thats a part of my yaml
<noizer> any clues
<dholbach> hey beuno, do you know when the new reviewers tools will land in myapps? I think all new snaps are being rejected right now? at least the one I uploaded with 'snapcraft upload' got rejected.
<beuno> dholbach, hi. Rejected with what message?
<dholbach>  - meta/readme.md does not exist lint_snappy_readme.md
<dholbach>  - (NEEDS REVIEW) squashfs pkg lint_is_squashfs
<dholbach>  - unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown
<dholbach> with the most recent reviewers tool I think most of the above are fixed
<dholbach> beuno: ^
<beuno> dholbach, the readme is fixed, but I don't think squashfs verification has landed yet, has it?
<sergiusens> dholbach, hmm, there shouldn't be a package.yaml
<dholbach> sergiusens: lp:~dholbach/+junk/moon-buggy is what I tried to upload with 'snapcraft upload'
<beuno> dholbach, I think we'll need a week or so more until 16.04 snaps auto-approve
<dholbach> ok
<dholbach> auto-uploaded auto-approving snaps would be something really nice to demo :)
<beuno> dholbach, yes indeed  :)
<sergiusens> dholbach, maybe clean and rebuild, I don't see package.yaml in the latest snapcraft builds
<kyrofa> Good morning
<noizer> Hi
<sergiusens> kyrofa, morning
<noizer> short question i want to make services in snapcraft 2.1 but it seems i don't work with the normal services tag
<kyrofa> noizer, no, the syntax has changed in version 2
<noizer> kyrofa ok where can I find the syntax then?
<kyrofa> noizer, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md
<dholbach> sergiusens, kyrofa: I'm still seeing "sh -c /usr/lib/update-notifier/update-motd-updates-available 2>/d..." as a hanging process
<sergiusens> dholbach, I have no idea what you are talking about
<noizer> kyrofa how does it work with the ports then?
<dholbach> sergiusens: http://paste.ubuntu.com/14876880/
<sergiusens> dholbach, in what point of snapcraft does it hang?
<kyrofa> noizer, what do you mean?
<sergiusens> dholbach, or at what point is it called
<dholbach> sergiusens: that's in the 'pull' stage
<noizer> I need something with sockets but then i tought i need services. So services with the previous version there you can open some ports. But is it possible now with the deamons?
<noizer> kyrofa
<sergiusens> pindonga, question about the store; every time we upload with the store API through snapcraft  we have to re-set the supported releseases, is there a way to make that stick?
<dholbach> sergiusens: first apt-get update is called, then something calls /usr/lib/update-notifier/update-motd-updates-available
<dholbach> basically after "apt update" pull hangs
<kyrofa> noizer, sure it is. You just need to set the right permissions. If you're binding to a port you'll need network-service
<noizer> ok i will look in to it :p
<ogra_> mvo, somehow /etc/writable stopped working with the switch to squashfs
<sergiusens> dholbach, so if it is when installing build packages, we don't call update https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L60
<sergiusens> dholbach, but we do call it here: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L232
<sergiusens> dholbach, nothing fancy though, just using python apt in a different rootdir (this will go away soon for everything but ros)
<dholbach> sergiusens: when the apt lists are obtained in any case
<sergiusens> dholbach, yeah, you hit this when adding stage packages
<dholbach> I wonder how we can turn off bits like update notifier
<dholbach> it must be possible
<sergiusens> dholbach, maybe mvo knows
<dholbach> mvo: do you know an apt config option which would turn off update-notifier scripts and stuff (when using a local sources.list)
<dholbach> ?
<noizer> kyrofa is there already documentation of network-services?
<sergiusens> didrocks, hello there! Was there any issue with the upload? If you are too busy I can bother dholbach :-)
<dholbach> what what?
<sergiusens> dholbach, I just distro patched someting until a release is avail http://paste.ubuntu.com/14871051/
<sergiusens> for a broken package
<dholbach> ok...
<kyrofa> noizer, check out this example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/snapcraft.yaml
<ogra_> mvo, oh, ignore me ... /etc/writable is fine, it is the atomic write issue once again
<noizer> kyrofa thx
<dholbach> sergiusens: on it
<didrocks> sergiusens: please bother him, yeah! here, it's quite crazy :p
<kyrofa> noizer, does that make sense? You're just saying "my service needs to listen on the network"
<noizer> I think it make sense
<noizer> i will try it
<noizer> because when when I'm testing it with normal command the permission was denied kyrofa
<noizer> (tornado sockets)
<kyrofa> noizer, do you know about snappy-debug?
<noizer> i did not used it before
<kyrofa> noizer, this may be helpful, from our brilliant dholbach: https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md
<noizer> ok pray all dholbach :D
<sergiusens> didrocks, I imagined as much
<sergiusens> dholbach, thanks !!!
 * sergiusens hugs dholbach 
 * dholbach hugs sergiusens back
<dholbach> kyrofa, noizer: to be fair... the content was written mostly by Jamie IIRC :)
<mvo> dholbach: you can clean the dpkg::post-invoke, is snapcraft using "import apt"? if so I can provide an example in a bit (meeting)
<kyrofa> mvo, yessir it is
<mvo> kyrofa: please try apt.apt_pkg.config.clear("dpkg::post-invoke")
<anpok> is there a way to use an oem snap with ubuntu-device-flash without signing it?
<noizer> kyrofa what does the type migration-skill?
<kyrofa> Thanks mvo! dholbach it sounds like you have a good failing test case, think you can throw that in and give it a try?
<kyrofa> noizer, so for 16.04 the ability to share things between snaps is calls "skills"
<noizer> oooh ok :D
<kyrofa> noizer, there's still in development, so right now there's only a single skill called the "migration-skill" that essentially offers backward compatibility with the old stuff
<noizer> kyrofa ok thx :D
<kyrofa> noizer, thought not really backward as it changes the yaml anyway... but you get the idea
<noizer> yea
<kyrofa> noizer, there have been a few threads on snappy-devel regarding this. If you're using 16.04 snappy you might consider getting on there so you know what's happening :)
<noizer> kyrofa ok i will check it out today :D. first, I will take care of my application so it is working on snappy
<dholbach> kyrofa: I'm not quite sure where to throw it in to make it work - I tried in a couple of places, but it doesn't seem to have an effect
<dholbach> I tried L60 and L232 in snapcraft/repo.py, tried after the apt import and elsewhere
<mvo> dholbach: just anywhere in the code, its a global option
<mvo> dholbach: having said this, I have no idea if what I said actually made sense, maybe I should read backlog first ;)
<dholbach> mvo: /usr/lib/update-notifier/update-motd-updates-available is still being called
<dholbach> which in our context hangs (as non-root user)
<dholbach> (mv /tmp/tmp.HSo85YHW5T /var/lib/update-notifier/updates-a...)
<mvo> dholbach: hm, the apt.apt_pkg.config.clear() should prevent this. are there more ways that snapcraft drives apt in addition to the import apt?
<dholbach> mvo: these are all notable occurences: http://paste.ubuntu.com/14877293/
<mvo> dholbach: the subprocess call there looks suspicious :)
<mvo> dholbach: is that were it crashs and burns?
<dholbach> I think it's before: http://paste.ubuntu.com/14877327/
<dholbach> that's where it tries to install build-packages which is not my local case
<mvo> dholbach:  apt_cache = apt.Cache(rootdir=rootdir, memonly=True) will reset the config, could you please stick the clear() after thi sline?
<dholbach> mvo: no dice
<mvo> :(
<mvo> meh
<dholbach> printing out apt.apt_pkg.config.get("dpkg::post-invoke") before and after the clear() gives nothing
<dholbach> mvo: ah ok - I used .value_list now
<dholbach> it's "['adequate --help >/dev/null 2>&1 || exit 0; exec adequate --debconf --user nobody --pending', 'if [ -d /var/lib/update-notifier ]; then touch /var/lib/update-notifier/dpkg-run-stamp; fi']
<dholbach> " before the .clear()
<dholbach> and [] after
<dholbach> could it be that the motd bits are somewhere else?
<mvo> dholbach: hm, one sec
<dholbach> mvo:
<dholbach>  /etc/apt.conf.d/99update-notifier:APT::Update::Post-Invoke-Success {"/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";};
<mvo> dholbach: try APT::Update::Post-Invoke-Success:
<mvo> dholbach: try APT::Update::Post-Invoke-Success
<mvo> dholbach: yeah, if you clean that, it should be ok
 * dholbach crosses fingers
<dholbach> come on apt, make me happy :)
<dholbach> <3
<ogra_> what a day ... so much ap5t talk in the snappy channel
<kyrofa> ogra_, hahaha
<dholbach> sergiusens_, kyrofa: http://paste.ubuntu.com/14877432/
<dholbach> I need to run for a bit, so feel free to push this one
<kyrofa> dholbach, thanks for that!
<dholbach> anytime
<sergiusens_> anpok, with --developer-mode iirc
<sergiusens_> dholbach, mvo thanks
<dholbach> sergiusens_: I did a fresh build and upload of moon buggy - still the same errors/warnings from the reviewers tools
<dholbach> 1) meta/readme.md does not exist lint_snappy_readme.md - 2) (NEEDS REVIEW) squashfs pkg lint_is_squashfs - 3) unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown
<dholbach> really need to run now - see you later
<sergiusens_> dholbach, oh, now I recall mvo saying he mixup the error message; it should say snap.yaml there;
<sergiusens_> there is still support required for those tools though
<mvo> dholbach: yeah, the store is a bit confused, the click-reviewers-tools are not fully updated yet
<mvo> dholbach: eh, s/store/c-r-t/
<didrocks> sergiusens_: I have some snapcraft.yaml which just download debs and a shell script. I wonder if I can say "please create a armhf .snap" (with snapcraft1) easily?
<pindonga> sergiusens_, is this on subsequent uploads for the same pkg? ie, just new versions?
<didrocks> as I have no compilation at all
<pindonga> sergiusens_, this == having to re-set the releases
<kyrofa> didrocks, the problem will be pulling the .debs from the arm repos
<didrocks> kyrofa: exactly!
<kyrofa> didrocks, pretending you didn't have that to worry about, you can actually put the .snap together yourself and just run snapcraft snap <directory>
<kyrofa> didrocks, but I'm not sure there's a good way to get the .debs without running on target or hacking snapcraft
<didrocks> kyrofa: sounds like an option. I'm looking as well in the code if I can spoof your arch detection :p
<didrocks> (if you are using a chroot for download from the archive)
<didrocks> or are you using the system sources.list?
<kyrofa> didrocks, heh, going the hacking snapcraft route eh?
<kyrofa> didrocks, hold on, let me find you a link
<didrocks> kyrofa: seems to be in snapcraft/common.py
<didrocks> heh 'dpkg-architecture', '-qDEB_BUILD_ARCH'
<didrocks> and the arch triplet
<kyrofa> didrocks, check out snapcraft/repo.py
<didrocks> ah nice, it seems you not relying on system sources.list
<didrocks> but rather building one
<kyrofa> didrocks, right. stage-packages and build-packages are different
<kyrofa> didrocks, you want the stage-packages stuff, which is repo.py
<didrocks> kyrofa: thanks for the pointer! going to mess from there! :-)
<kyrofa> didrocks, good luck! Interested to hear how it goes
<didrocks> yeah, wellâ¦ snapcraft1 and it's changing with the classic dimension then
<kyrofa> didrocks, remember you can always download the .debs yourself and unpack them
<didrocks> so, more of a stop gap :)
<didrocks> yeah
<didrocks> in download/ from the part
<anpok> sergiusens_: ah that worked .. now it cannot find the package.yaml in the gadget snap
<didrocks> but 134 of them
<didrocks> so getting lazy! :)
<kyrofa> didrocks, ugh!
<sergiusens_> anpok, I'll refer to mvo for that
<sergiusens_> pindonga, yes, new versions of the same package
<pindonga> sergiusens_, I guess we could default to any release set for the latest published version
<pindonga> sergiusens_, could you file a bug on lp:software-center-agent please?
<beuno> well
<beuno> or maybe store it locally?
<beuno> in a local config
<sergiusens_> didrocks, your code is old, we removed the dep on dpkg-dev hence we don't have dpkg-architecture anymore either
<beuno> last release targeted?
<sergiusens_> pindonga, I agree on that
<sergiusens_> beuno, well I was asking about the store api at first ;-) Since I need to add 'release' to snapcraft.yaml to support cleanbuild anyways
<beuno> sergiusens_, I worry a bit about the server auto-filling data
<beuno> but only a bit
<beuno> :)
<anpok> i creates a gadget/oem? snap that has a meta/package.yaml .. u-boot binary .. now it ubuntu-device-flash fails with 'Determining oem configuration\nno oem package found'
<anpok> *created
<pindonga> beuno, this being for new version uploads only, I thought relying on existing releases if none is specified was ok
<pindonga> of course if the pkg contains the releases in the metadata, we should grab it from there
<beuno> it's probably ok, yeah
<beuno> it just feels like the wrong place to define intention
<sergiusens_> beuno, it's not autofilling
<sergiusens_> beuno, or not less than it used to
<sergiusens_> beuno, if I upload the snap from the ui it is filled in with the previous stuff; at least it was a week a go
<sergiusens_> beuno, I don't mind if it is an api; maybe this can also play with the stability level (grade) in snap.yaml
<didrocks> sergiusens_: it's snapcraft v1
<sergiusens_> beuno, I'd much like to define which pockets to upload to, something like 'snapcraft upload --releases ubuntu-core,ubuntu-personal,...'
<didrocks> sergiusens_: from git
<sergiusens_> didrocks, oh, right
<didrocks> sergiusens_: we have to use it for mwc :p
<awe__> mvo, I tried installing hello-world.mvo on my new amd64 rolling image and it fails.  Is this a known issue?
<kyrofa> didrocks, oh yeah, that reminds me-- snapcraft snap <directory> is in version 2. If you're using 15.04 that functionality still exists in snappy itself, which you can use via snappy build
<awe__> sergiusens, I managed to get everything re-worked last night
<kyrofa> didrocks, works the same way though
<awe__> one question... since I can't get hello-world working, what's the name of the user-specific writable env var?
<kyrofa> awe__, $SNAP_USER_DATA
<kyrofa> (if 16.04)
<awe__> great, thanks
<awe__> did SNAP_APP_DATA_PATH also get shortened?
<awe__> ( for 16.04 )?
<kyrofa> awe__, $SNAP_APP_USER_DATA_PATH if 15.04
<kyrofa> awe__, indeed, $SNAP_DATA
<ogra_> SNAP_DATA ?
<ogra_> yeah
 * ogra_ still cant memorize them 
<awe__> is the old env var still supported though in the latest images?
<kyrofa> ogra_, it's okay, me too
<kyrofa> awe__, yes, just deprecated
<awe__> ok, great; will change now
<sergiusens> awe__, I guess email subjects are a thing of the past; https://lists.ubuntu.com/archives/snappy-devel/2016-January/001392.html :-)
<ogra_> ppisati, mvo, i'm nearly readey witrh my rpi firmware update for gadget and oem snap .... i was wondering if we should perhaps bump the default kernel version to the latest xenial one though (which means i'd need to update the dtbs in the snap)
<sergiusens> awe__, what fails with hello-world? If it is installation, try snappy install hello-world/edge
<ogra_> (that is ... 4.2 to 4.3)
<awe__> sergiusens, ok, one sec
<ppisati> ogra_: +1
<ogra_> ppisati, any possible regressions (i.e. config changes) i shold be aware of ?
<kyrofa> mvo, did you ever learn anything about that weird systemd %h thing?
<awe__> sergiusens, that works
<awe__> mvo, never mind my last statement about hello-world
<kyrofa> matiasb, I uploaded another version of that owncloud snap, but I'm not seeing it in snappy again. When you get a sec would you mind patching that framework thing on it?
<matiasb> kyrofa, ack, sure, in a bit
<ppisati> ogra_: nothing on purpose at least :)
<ppisati> ogra_: let me check one thing
<ogra_> ppisati, heh, ok
<kyrofa> matiasb, thank you!
<matiasb> kyrofa, fyi, we expect to get a fix for this deployed today, hopefully
<kyrofa> matiasb, excellent! Thanks for letting me know :)
<anpok> the problem seems to be that the oem/gadget snap looks different.. when in stalled in temp the package.yaml ends up being here:
<pindonga> sergiusens, +1 to the idea of passing releases via api
<anpok> ./apps/bananapi.sideload/ILfDRVXaWFBX/meta/package.yaml
<anpok> s/in stalled/installed
<matiasb> kyrofa, updated, you should see latest revision now
<kyrofa> matiasb, perfect, works!
<diwic> I rebooted - which apparently installed some new rootfs? - and now pulseaudio doesn't start:
<kyrofa> didrocks, try the new version of owncloud.kyrofa when you get a sec, app store should be working
<ppisati> ogra_: http://paste.ubuntu.com/14877727/
<ppisati> ogra_: that's the config diff between latest 4.2 and x/master 4.3 raspi2 kernel
<ppisati> ogra_: other than that, it works fine on my board and in my test
<ogra_> ppisati, do you plan to bump to 4.4 before final ?
<ppisati> ogra_: we make use of =m as mush as possible, so it should be fine
<ogra_> (giving us the free graphics driver)
<ppisati> ogra_: we already have a 4.4
<ppisati> ogra_: but it's the first cycle
<ppisati> ogra_: so it's marked as unstable
<ogra_> not on rpi yet
<ogra_> ah, k
<ppisati> ogra_: yep, on rpi2 too
<ogra_> well, but you plan to bump it ?
<ppisati> ogra_: ys
<ogra_> ppisati, hmm, then i'll probably push the update til 4.4 is consumable
<diwic> the wrapper script claims it cannot find the executable
<ogra_> and stay with 4.2 til then
<ppisati> ogra_: probably yes
<ppisati> ogra_: i really like X because we syncronized with an upstream LTS kernel
<ppisati> ogra_: so align nicely
<ppisati> when everyone moves there
<ogra_> yeah
<didrocks> kyrofa: oh nice! will definitively do:)
<elopio> ping pitti. I need help trying to reproduce the snapcraft autopkgtest. Canonistack has timed out all week before starting to run the tests.
<elopio> do you have any tips to reproduce locally?
<pitti> elopio: it works in qemu?
<pitti> elopio: looks like it's trying to contact https://repo.maven.apache.org/maven2
<pitti> elopio: possibly it's not respecting $https_proxy for that?
<pitti> tests need to use the proxy in the environment, they can't talk directly to the network
<elopio> pitti: I haven't even gotten there with qemu: https://paste.ubuntu.com/14863428/
<elopio> I have everything timing out in different ways :(
<pitti> elopio: wow, how big is that tree?
<pitti> elopio: you can try with --timeout-copy=3000 (default is 300, i. e. 5 mins)
<pitti> but I guess something else is wrong, unless your tree really is Gigabytes big
 * pitti runs "adt-run snapcraft --- qemu /srv/vm/adt-xenial-amd64-cloud.img"
<elopio> pitti: ummm, we pollute the repository when we build snaps. I'll try cleaning everything up first.
<pitti> elopio: ah, in your ./ ? yes, do that, or run "snapcraft" instead of ".//" to use apt-get source
<pitti> elopio: I started it, and I now see ".......EEE..."
<pitti> elopio: i. e. some tests fail, but it's runing
<pitti> elopio: wrt. trying to download from maven: don't we have tha particular module packaged? we have hundreds of maven packages
<pitti> elopio: i. e. if you add this as a test dependency, then it would avoid having to call out to the internet
<elopio> pitti: ok! seems promision. /me tries.
<elopio> pitti: we decided for some reason to use upstream. Not sure about what was that reason now.
<elopio> sergiusens: ^ ?
<pitti> elopio: ok, then I figure you either don't respect $https_proxy, or something cleans the environment
<sergiusens> elopio, pitti well one of the purposes for those examples is to use upstream; I I can look into seeing if http_proxy gets wiped or not
<sergiusens> thanks
<elopio> thanks pitti! it's running now locally. I can start debugging now.
<jdstrand> mvo: hey, fyi, both systems are continuing to install hello-world.canonical 1.0.18
<jdstrand> I didn't check to see if they stopped during the night
<jdstrand> I can if you need me to
<mvo> jdstrand: meh, thanks
<kyrofa> mvo, sergiusens much simpler reproducible case for the broken $SNAP_USER_DATA here: https://bugs.launchpad.net/snappy/+bug/1541898
<ubottu> Launchpad bug 1541898 in Snappy "Broken $SNAP_USER_DATA for services" [Undecided,New]
 * dholbach hugs sergiusens
<kyrofa> sergiusens, jsonschema question (context: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L343)
<kyrofa> sergiusens, if I load the YAML via yaml.load (which gives me a dict) and hand the dict to jsonschema, how can jsonschema _possibly_ back that out to a line number in the yaml?
<noizer> kyrofa what is the correct syntax for the copy plugin?
<kyrofa> noizer, copy has one parameter, "files", which is a map of source->destinations
<kyrofa> noizer, so something like: http://pastebin.ubuntu.com/14878198/
<noizer> kyrofa ok but in Private chat you said i did it wrong for my nginx.conf file
<kyrofa> noizer, right, you have a copy plugin with no files-- just a stage-package
<noizer> yea ok that was wrong but the part under that it will copy the nginx.conf over the other one but it don't work
<kyrofa> noizer, you may need to exclude that conf file from the stage-packages
<kyrofa> noizer, if two parts try to write the same file but they differ, snapcraft will throw a fit
<kyrofa> noizer, since it doesn't know which one you actually want
<noizer> ok
<kyrofa> noizer, look in that syntax file for the `stage` and `snap` keywords for the parts
<kyrofa> noizer, you can use those to exclude the config file
<sergiusens> kyrofa, it is impossible
<sergiusens> kyrofa, but you can get the key that cause the issue
<kyrofa> sergiusens, yeah okay, that's what I thought
<kyrofa> sergiusens, gotcha
<renat> Hi guys!
<renat> We have application. Screenly Viewer. Slide Show application which uses opengl to show it's slides.
<beuno> renat, hi!
<renat> When I start the binary - everything works well, and it works. But when I'm trying to start it as a systemd service. I loads. Shows the first asset and stops. Just using 100% cpu.
<renat> beuno, Hi!
<beuno> renat, lets start off with some basic information
<beuno> what release of snappy are you using?
<renat> 15.04
<renat> stable
<renat> It doesn't show any apparmor and seccomp warnings
<beuno> renat, ok, lets ping some folks who might be better suited to help debug
<renat> beuno, thanks!
<beuno> jdstrand, sergiusens, kyrofa, any pointers? ^
<beuno> kgunn, maybe you have some thoughts?
<apw> mvo, yo, you know things ... ubuntu-core 15.04 has extended support relative to 15.04 which is just EOL'ing
<apw> mvo, as i understand things you have an overlay PPA which will take over to supply updates for things after EOL of 15.04 ...
<kyrofa> renat, are you using mir or something?
<apw> mvo, so we are trying to confirm that you are needing vivid kernel updates for that, and how those would make it to you
<renat> kyrofa, hi! No. I'm now 100% sure how it works. But it uses Qtt OpenGL
<kgunn> renat: and what exactly are you running on ? amd64? vm? arm?
<renat> kyrofa, it's Raspberry Pi2 ARM
<renat> kyrofa, it's Raspberry Pi2 armhf
<beuno> apw, ricmm might be better suited to answer that
<kyrofa> renat, are you using the qml plugin in snapcraft, then?
<apw> ricmm, ^^
<renat> kyrofa, no. We use our patched version of Qt as I know. Build everything into squashfs using buildroot. I create a snap by extracting everything from the squashfs and setting appropriate paths in LD_LIBRARY_PATH and all other libraries.
<kyrofa> renat, oh
<kyrofa> hmm
<beuno> I think 15.04 doesn't support squashfs?
<beuno> does it?
<kyrofa> beuno, right
<kgunn> but he says it loads/works....
<kgunn> only until he tries to start it as a systemd service does it not work (stalls on first frame)
<kgunn> iiuc
<kgunn> renat: if it shows 100%cpu...what's the process using cpu?
<renat> kgunn, executable itself
<kgunn> renat: mmm, but seems you have a ton of stuff inside that snap...
<renat> kgunn. I'm placing logging functions to different places. But don't get any output.
<renat> What is difference between running as executable and as a systemd service?
<kgunn> renat: that i really don't know...others would be better to speak
<kyrofa> renat, I'm confused. You say it's Qt and OpenGL. You must be using a display server of some kind?
<renat> kyrofa, it uses framebuffer
<kyrofa> renat, ah, okay
<renat> It should be something systemd or cgroups related.
<kyrofa> renat, have you tried running this as an app with sudo?
<renat> kyrofa, Yes. It works
<kyrofa> renat, have you tried via su as well?
<kyrofa> renat, real=effective uid
<renat> kyrofa, worked again
<kyrofa> renat, when running as a service, I'm assuming it doesn't fork right?
<renat> No. It doesn't I use exec in all wrappers
<renat> No. It doesn't.  I use exec in all wrappers
<kyrofa> renat, by running under su you've eliminated the differences as far as I can tell. I'm really not sure why it's not working when running as a service. Everything else should be the same
<kyrofa> renat, what you need is gdb :(
<renat> kyrofa, no. 1 more difference. Different slice. system.slice vs user.slice.
<kyrofa> renat, hmm, yeah you can either start adding prints to the application to figure out where it's looping, or wait for sergiusens or mvo to give you some more pointers
<sergiusens> renat, snappy service logs [snap] gives no output?
<jdstrand> renat (otoh, I can't think of something. however, it is possible you aren't seeing security denial due to kernel rate limiting. I suggest: sudo snappy install snappy-debug ; sudo reboot ; login ; sudo snappy-debug.security scanlog ; exercise your snap
<renat> Thanks. trying.
<jdstrand> beuno: awe__ asked me to upload bluez to rolling using the shared acount (fine). there is an amd64 and an armhf snap with the same version number. anything special I need to know when doing this?
<kyrofa> jdstrand, they can't have the same version right now
<kyrofa> Unless that's changed since yesterday
<jdstrand> awe__: fyi, ^
<kyrofa> jdstrand, so I just append -amd64 and -armhf to the versions
<awe__> ok; so  build one as -1
<awe__> and the second as -2
<kyrofa> jdstrand, other than that, seems to work great!
<awe__> or that
<kyrofa> awe__, yeah, whatever doesn't imply that the versions are actually different, you know?
<jdstrand> kyrofa: thanks!
<jdstrand> beuno: nm
<awe__> sure
<sergiusens> awe__, kyrofa wait, for 16.04 we have multi arch pockets in the store since monday
<sergiusens> is that right matiasb ^ ?
<sergiusens> maybe for 15.04 two; the store doesn't care about releases
<kyrofa> awe__, yeah multi arch uploads work, but the versions need to be different (same package)
<kyrofa> sergiusens rather, sorry
<sergiusens> right version~$arch seems saner than diffrent package names to me
<kyrofa> sergiusens, yeah
<ogra_> shudder
<kyrofa> sergiusens, that's what I was trying to say-- sorry I wasn't clear
<sergiusens> "this is the armhf version of the snap"
<ogra_> we should really have a meta field for that
<sergiusens> it even matches how you would mention it
<sergiusens> ogra_, we do ;-)
<ogra_> why do i then need $version-arch ?
<matiasb> sergiusens, awe, yes, you can upload multiple versions for different arch/release combination in the same package
<sergiusens> ogra_, because the store doesn't upload every arch atomically
<sergiusens> ogra_, it's like setting an arch in a deb and uploading N times swithing the arch field
<ogra_> sergiusens, yeah, nothing you would ever do with a deb :)
<renat> sergiusens, snappy service logs doesn't give more information unfortunately.
<ogra_> but i guess thats a price we have to pay for binary uploads
<renat> jdstrand, already tried scanlog. Nothing related to apparmor or seccomp
 * awe__ ducks out for a bit; bbl
<jdstrand> renat: ok, so if you did the reboot (that is important so the kernel forgets about what it rate limited) and scanlog gave no output, it is something else
<jdstrand> renat: the first place I would look is 'snappy service logs <foo>'
<jdstrand> that will give all the systemd log output
<renat> jdstrand, already done. Unfortunately somewhere infinite loop appeared. And it doesn't give additional logging
<renat> Is it possible to start process inside custom cgroup hierarchy?
<kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/296 when you're able
<kyrofa> Huh. I can't reach github all of a sudden
<kyrofa> Ah, and as soon as I say something, it's back
<renat> kyrofa, What if I try to move to 16.04 snappy version? Can I just chroot to our squashfs there, and run program from inside the chroot?
<kyrofa> renat, no not really-- you'd need to run it with ubuntu-core-launcher, with the right environment, etc.
<kyrofa> renat, though that brings up my `snappy shell` question again. Chipaca, you around?
<kyrofa> elopio, coveralls doesn't seem to be reporting back to https://github.com/ubuntu-core/snapcraft/pull/296
<kyrofa> elopio, travis says it submitted it successfully, but coveralls keeps saying "no data"
<kyrofa> elopio, any ideas?
<elopio> kyrofa: no, seems just to be dumb. I re-ran it.
<kyrofa> elopio, ah, okay
<kyrofa> sergiusens, the fix to bug #1541353 is to just parse the snapcraft.yaml, yes?
<ubottu> bug 1541353 in Snapcraft "'snapcraft upload' says 'Invalid package filename.'" [High,Triaged] https://launchpad.net/bugs/1541353
<kyrofa> sergiusens, or would you go so far as to unsquashfs and extract metadata from the snap itself?
<LefterisJP> beuno: Hey mate, I am uploading my snap to the MWC store and no matter what I do it seems that the icon.png from the snapcraft.yaml is not included.
<elopio> kyrofa: one more time. Now it's travis with a mismatch hash
<LefterisJP> beuno: if I upload the snap to a local snappy device the icon shows up fine in the WebDM interface, so it's probably an error with the store.
<beuno> LefterisJP, hi
<sergiusens> kyrofa, the fix is to remove the regex
<beuno> LefterisJP, is this a 15.04 snap or a 16.04 snap?
<kyrofa> sergiusens, but the upload code needs a name
<kyrofa> sergiusens, it's not just a validation
<sergiusens> kyrofa, oh, doesn't the upload code contruct a name in the code itself?
<kyrofa> sergiusens, via the regex
<sergiusens> kyrofa, oooh
<sergiusens> kyrofa, one second, I'll get you pointers
<kyrofa> sergiusens, so I figure, get the name from the yaml
<sergiusens> kyrofa, extract these two functions https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/commands/snap.py#L47
<sergiusens> kyrofa, and also figure out why it refers to 'package.yaml' and how it works :/
<sergiusens> put them in common
<kyrofa> sergiusens, uh oh :P
<kyrofa> sergiusens, but yeah, okay, same page
<sergiusens> kyrofa, expose format snap_name with docstrings and all tat magic
<sergiusens> kyrofa, I don't understand how it works though; given all tests still pass
<kyrofa> sergiusens, indeed, I'll look into it
<sergiusens> kyrofa, oh, that first function is not used
<kyrofa> sergiusens, perhaps the tests setup that directory with a package.yaml
<sergiusens> kyrofa, just export format_snap_name in common
<kyrofa> sergiusens, it's used if called with DIRECTORY
<kyrofa> sergiusens, but yeah
<sergiusens> kyrofa, ah, we have no test for that!
<kyrofa> sergiusens, oops
<LefterisJP> beuno: It's a 15.04 snap that's going in the MWC store
<kyrofa> sergiusens, making bug now
<sergiusens> kyrofa, units yes, not tests tests
<sergiusens> kyrofa, even if we did, our prelayed out dir wouldn't of catched this
<sergiusens> kyrofa, the easy way to have a test for this is to run `snapcraft snap` and then `snapcraft snap snap`
<beuno> LefterisJP, while I look into that, can you add the icon separately to the app in the store?
<kyrofa> sergiusens, oo, I like it
<sergiusens> kyrofa, it may have merit for a separate bug
<kyrofa> sergiusens, yeah I think so
<LefterisJP> beuno: I think I can but then I won't be able to confirm it works fine when it does :)
<beuno> LefterisJP, I can do that separately  :)
<LefterisJP> kk
<kyrofa> sergiusens, yeah, just a bad test setup: https://github.com/ubuntu-core/snapcraft/pull/297
<kyrofa> sergiusens, old, rather-- not bad :)
<elopio> kyrofa: sergiusens: I'm going to lie in bed for the rest of the day.
<kyrofa> elopio, feel better!
<awe__> so earlier this morning, I installed hello-world using: 'sudo snappy install hello-world/edge
<awe__> when I try now
<awe__> I get snappy package not found
<ogra_> blame beuno ?
 * ogra_ guesses the store was fixed during the day
<awe__> kyrofa, is there anyway around a full rebuild of a autotools based snap when you only change a single file?
<awe__> right now I find myself having to do a clean first
<awe__> and this takes forever on a ripi2
<kyrofa> awe__, yeah I feel your pain. Unfortunately not, but it's something I'm hoping to solve soon
<kyrofa> awe__, my ownCloud snap takes literall all day (or night) long to build on the rpi
<sergiusens> kyrofa, right, which goes down to the fact that only units can't save you ;-)
<sergiusens> elopio, get better
<kyrofa> sergiusens, indeed. I added an integration test as well
<kyrofa> sergiusens, so hopefully that doesn't bite us again
<kgunn> jdstrand: ping
<jdstrand> hey
<kgunn> jdstrand: hey, was just updating to skills...and wanted a sane eye
<kgunn> http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snapcraft2.1/view/head:/snapcraft.yaml
<kgunn> that format look right?
<kgunn> like the "migration-one/two" can just be random/meaningless to me?
<jdstrand> kgunn: you want to uses caps and not security-template
<jdstrand> kgunn: plus you can combine those into one skill
<jdstrand> migration-stuff:
<jdstrand>   type: migration-skill
<jdstrand>   caps: [display-server, unix-listener\
<kgunn> i get it
<kgunn> altho...interesting, i thot the whole reason was to get rid of the "caps" nomenclature
 * kgunn didn't really get the passion of the move to term "skill"
<kgunn> but thanks!
<jdstrand> kgunn: it is, this is a 'migration-skill'
<pedronis> well migration-skill is just an interim thing, so it crosses the old and new world (also terminology wise)
<kgunn> i figured
<kgunn> "interim"
<jdstrand> when the security parts of skills a worked out, that can go away
<jdstrand> are*
<kgunn> jdstrand: just looking ahead, is the goal to be nailed down at 16.04?
<jdstrand> zyga and I will be talking soon to sync up once I get the review tools changes done for 16.04
<kgunn> thanks again
<jdstrand> kgunn: everyone wants that. from my side, I'm good with doing it for 16.04, but there might be things on the skills side I'm not aware of that might prevent it
<jdstrand> I think it is ok to assume 'yes'
<kgunn> :)
<robert_ancell> elopio, around?
<Chipaca> kyrofa, i'm around now, what was the question?
<sergiusens> kyrofa, you should join the fun and get onto the slack channel :-P
<sergiusens> ETOOMANYCHANS
<sergiusens> Chipaca, I think I know
<sergiusens> Chipaca, systemd service units are not replacing %h properly
<sergiusens> Chipaca, convert hello-world.env into a daemon and you will see
<sergiusens> Chipaca, %h should be /root, instead it's plain `/`
<Chipaca> sergiusens, can you pastebin the output of hello-world.env-as-a-daemon?
<sergiusens> Chipaca, ok, first I need to unxz the latest image; give me 2'
<Chipaca> sorry i'm being lazy
<Chipaca> rough day
<Chipaca> thinking of taking tomorrow off or somehting
<zyga> jdstrand: with pleasure
<sergiusens> Chipaca, look at SNAP_USER_DATA http://paste.ubuntu.com/14883057/
<sergiusens> Chipaca, notice the double `/` there
 * sergiusens heads out for aikido
<Chipaca> sergiusens, yes yes. But is that *all* the output from env? (I want to see the environ :-) )
<Chipaca> sergiusens, my suspicion is that for some reason HOME isn't set
<sergiusens> Chipaca, it is
<Chipaca> drat
<sergiusens> Chipaca, don't units set HOME accordingly or is that some sort of system setting?
<sergiusens> the manpage says %h resolves to /root by default
<sergiusens> I need to go
<sergiusens> will bbl
<sergiusens> if you want to drop lines here I'll read later :-)
<Chipaca> sergiusens, go go
<plars> elopio: I've cherry-picked your older patches into current trunk, and I'm trying to also cross-build the test binary for arm but I'm getting an error. Have you seen anything like this?
<plars>  /tmp/gotestbuild/src/github.com/ubuntu-core/snappy/progress/progress.go:200: undefined: isatty
<grim__> does anyone know if there are snappy images archived anywhere?  The core updates cause some of our snaps to fail to install.  We'd like to try to install on core versions 1-current to figure out what is going on.
<neutrino> Any way to create self hosted snappy store for private snapps?
#snappy 2016-02-05
<neutrino> Looks like private snapps will be supported in 16.04 LTS
<qengho> I'm trying to test a new snap on my Ubuntu classic machine. I get an error at snap install that "sc-filtergen executable not found". Is there a Dependency I should fulfill manually? Is that a bug?
<Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
<Tenacious-Techhu> neutrino, you keep popping in and out; are you sure you aren't a virtual particle?
<dholbach> good morning
<Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
<JamesTait> Good morning all!  Happy Friday, and happy Doodle Day! ð
<noizer> Good morning :D
<qwebirc389725> In what ways is Snappy secure by default, and in what ways is it not?
<Tenacious-Techhu> In what ways is Snappy secure by default, and in what ways is it not?
<Chipaca> zyga, pedronis, do you know of any reason not to merge mvo's branches? the ones that move things to the overlord
<Chipaca> they have two +1's and are all green and lurvely
<pedronis> ?
<Chipaca> pedronis, in the list of pull requests, the last four
<Chipaca> actually all of mvo's branches
<Chipaca> (there are five of 'em)
<pedronis> the SetActive one doesn't seem to have two +1
<Chipaca> yep
<Chipaca> but i can provide that :-)
<pedronis> the Install one seem to need an added TODO: about w.Sync
<Chipaca> and the one that drops meta repos has no +1s
<pedronis> not a strong reason not to land it, but a small branch to do after or something
<pedronis> IÂ mean the branch for adding the TODO
<Chipaca> yep
<pedronis> not solving the problem
<Chipaca> with him away until tuesday, i'd merge as is and then push a branch with the todo :-)
<pedronis> 395, 397, 398 seems landable
<Chipaca> ok, merging the ones with two +1's, then i'll review the diffs for the last two
<pedronis> I'm not sure about the rest
<Chipaca> yeah, without the first three merged it's tricky to review the last two :-)
<Chipaca> ooooh, conflicts!
<pedronis> life is hard
<Chipaca> i guess i'll be fixing those first then :-)
<Chipaca> hmm, how do i merge in a branch from somebody else?
<pedronis> ?
<Chipaca> I'm on my master, and I want to merge in https://github.com/mvo5/snappy/tree/refactor/remove-details-from-repo
<Chipaca> to then fix the conflicts and propose
<pedronis> you fetch it and merge
<Chipaca> i guess i've got to add mvo as a remote first
<pedronis> you can do that or not
<pedronis> not works too, you get a FETCH_HEAD
<pedronis> that you can merge
<pedronis> if yous setup the proper remote
<pedronis> you can pulled down the nicely named branch
<Chipaca> yeah, doing that
<Chipaca> funny how so many months in these things still trip me up
<Chipaca> strange, that merged with no conflicts
<sergiusens> Chipaca, morning, did you have a chance to look at the %h thing?
<Chipaca> sergiusens, no
<Chipaca> sergiusens, does the systemd service file have %h in it?
<sergiusens> Chipaca, yes
<Chipaca> pitti, why would a systemd unit not replace %h?
<sergiusens> Chipaca, from the go template we have in snappy
<Chipaca> sergiusens, yep, was wondering if it was us messing things up, or if it was systemd
<Chipaca> oh, hold on
<Chipaca> %h doesn't work when systemd is pid 1?
<noizer> Hi, got a short question how can I install python-dev on a snap. it is for installing uwsgi.
<Chipaca> sergiusens, %h doesn't work when systemd is id 1
<sergiusens> Chipaca, ah
<sergiusens> Chipaca, "Please note that specifiers "%U", "%h", "%s" are mostly useless when systemd is running in system mode. PID 1"
<sergiusens> kyrofa, ^
<sergiusens> Chipaca, should we change %h in snappy to /root?
<Chipaca> sergiusens, yes
<Chipaca> sergiusens, if we mean /root, yes :-)
<sergiusens> Chipaca, we do
<sergiusens> Chipaca, for your consideration https://github.com/ubuntu-core/snappy/pull/442/files
<Chipaca> sergiusens, hero
<Chipaca> sergiusens, oops, tests fail
<zyga> Chipaca: no, I don't know but I wasn't really looking at all of mvo's branches lately
<dholbach> sergiusens, kyrofa: what do you suggest we do about images in snapcraft docs?
<jdstrand> Chipaca: hey, I'm making review tools updates for snap.yaml and trying to understand which of the 'apps' options can be used together. now that there is no separate structure for services and binaries, the trigger for 'is a service' is app.Daemon, correct? Looking add addPackageServices in click.go, that seems to be the case
<Chipaca> jdstrand, yes
<Chipaca> jdstrand, and binaries have exec=
<jdstrand> do they?
<Chipaca> don't they?
<jdstrand> exec isn't documented in meta.md
<Chipaca> i'm reporting from memory, not from code
<jdstrand> and addPackageBinaries says !app.Daemon
<Chipaca> so believe the code
<jdstrand> ok
<Chipaca> :-)
<jdstrand> Chipaca: I'm going to also assert in the tools that ports, bus-name and the socket options all require daemon. any objections? (obviously, this can be changed going forward)
<kyrofa> Good morning
<noizer> kyrofa good morning :D
<noizer> I have already a question for you
<noizer> kyrofa i want to install uwsgi with the pip packages. but got all the time an error
<noizer> this error means something like that i need python-de
<noizer> *python-dev
<noizer> but when i put python-dev in an other part so i would be sure that it is installed before the other part( the part with the uwsgi)
<noizer> this can't work because then I have duplicated files from python :s
<noizer> I will send you a yaml file
<noizer> kyrofa http://pastebin.com/u9S3unUD
<kyrofa> noizer, if you want to use a stage package within a part, it should probably be specified within that part instead of another
<noizer> ok I tried that too but it doesn't work :s
<noizer> he needs to get python.h kyrofa
<ogra_> should that be in "build-packages" then instead of "stage-packages" ?
<kyrofa> ogra_, probably
<kyrofa> noizer, though linux is case-sensitive-- do you actually mean Python.h, or are you really saying python.h?
<kyrofa> noizer, because python*-dev only gives the former
<noizer> Python.h
<noizer> excuse me typo
 * ogra_ isnt sure we even copy /usr/include into the snap for stage-packages, might be only /usr/lib|share and /usr/bin|sbin
<ogra_> (like we rip  out documentation and other unusable stuff)
<kyrofa> ogra_, we unpack the deb... I don't remember seeing code to clean it at all-- though I may be wrong
<ogra_> well, i know we dont copy over manpages and stuff
<ogra_> so perhaps you need an explicit line under "files" in the copy plugin to copy usr/include
<ogra_> should be easy to check with the installed snap what actually ends up in place
<kyrofa> matiasb, I uploaded the new version of the owncloud snap (for armhf this time) which also needs the framework fix. Would you mind looking at that when you have a minute?
<matiasb> kyrofa, sure, checking!
<noizer> kyrofa if you need more testers i want to test it too if needed xD
<kyrofa> noizer, hey, feel free! `sudo snappy install owncloud.kyrofa`
<noizer> kyrofa I will test it tonight when i'm at home (Belgium hour)
<kyrofa> sergiusens, what are your thoughts on dholbach's images?
<kyrofa> noizer, since you don't really get much of a manual with the .snap, might be worth reading this: https://github.com/kyrofa/owncloud-snap/blob/master/README.md
<mvip> didrocks1: Here you go: https://bugs.launchpad.net/snappy/+bug/1500755
<ubottu> Launchpad bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Confirmed]
<noizer> kyrofa ok intresting
<didrocks> ogra_: hey, do you mind looking at that one? ^ those guys have to roll out their own image due to this
<ogra_> didrocks, as i'm saying since monday i'm actively working on it, yes
<ogra_> should land later today
<ogra_> patience ;)
<didrocks> ogra_: oh, great! we didn't get any info from the bug report or didn't check IRC enough :)
<mvip> ogra_ awesome. :)
<mvip> ogra_ thanks man
<ogra_> didrocks, well, i commented on the bug on friday ;)
<didrocks> ogra_: a week ago! it's ages in our industry as asac would say! :p
<sergiusens> kyrofa, your branch idea is good
<didrocks> anyway, thanks for looking at it! :)
<kyrofa> sergiusens, it leaves them under our control, anyway
<kyrofa> sergiusens, dholbach another option is to upload them on the github wiki and link to them there
<kyrofa> Then they wouldn't be pulled down in a clone
<dholbach> hey alecu :-)
<alecu> hey dholbach! :-)
<dholbach> kyrofa: I'm happy either way
<dholbach> kyrofa: I don't expect crazy amounts of images anytime soon :)
<kyrofa> dholbach, ah, it doesn't actually look like you can upload images on the wiki, scratch that
<dholbach> ok... images branch then? or link to rawgit?
<kyrofa> dholbach, well, rawgit needs a branch anyway
<dholbach> so they could live in the same branch and be part of the same commits, right?
<kyrofa> dholbach, I'm not actually sure what it gives you-- am I missing something?
<dholbach> kyrofa: I was just wondering if we would actually need a separate branch
<kyrofa> dholbach, perhaps not. We could make an images folder within the docs folder
<kyrofa> dholbach, perhaps that would indeed be easiest
<kyrofa> dholbach, as long as you're not expecting tons and tons of images
<dholbach> if we just put them in master or 1.x it should be clearer which commit they're part of, etc
<dholbach> yeah, I don't expect that to happen :)
<kyrofa> dholbach, yeah go for it
<kyrofa> dholbach, just remember, when you change binary files (I'm assuming git will treat images as binary files) they'll conflict every time
<dholbach> ok, I'll adapt my current PR and do another one to move the image on README.md
<kyrofa> dholbach, if git ever tries to merge them, I mean
<dholbach> ok
<dholbach> I have no idea about that :-/
<dholbach> is this something we need to workaround?
<kyrofa> Nah, we can deal with it. We'll only hit it if multiple people try to change the image, etc.
<kyrofa> But it's something to keep in mind if you get into that situation
<dholbach> ok
<dholbach> updated
<kyrofa> dholbach, that markdown looks fishy. Have you verified that it works?
<dholbach> on it
<dholbach> sorry
<kyrofa> dholbach, would you mind terribly if I asked you to change the URLs temporarily to your branch so we can see the end result?
<dholbach> kyrofa: https://github.com/dholbach/snapcraft/blob/1541404/docs/mir-snaps.md
<kyrofa> dholbach, hey, yeah, there we go
<kyrofa> dholbach, I like the foot note style
<dholbach> updated :)
<kyrofa> dholbach, ah, so you are going with rawgit?
<dholbach> hum... isn't that what we wanted :)
<kyrofa> dholbach, well, that's a cache, right? If we upload it into master we can just use the githubusercontent URL, can't we?
<kyrofa> dholbach, actually I suspect we can directly use images/image_name
<kyrofa> dholbach, then it's branch-independent
<dholbach> can we maybe go with githugusercontent for now? O:-) the markdown importer of developer.u.c hasn't learned how to import images and store them in swift storage yet :-)
<kyrofa> dholbach, ah! Yeah I can see how that might be _slightly_ problematic
<dholbach> it's planned, it's just not done yet
<kyrofa> dholbach, tough feature
<kyrofa> dholbach, so yeah, totally. Do you agree that using github directly instead of rawgit is better? Might be more reliable
<dholbach> I'm happy to change rawgit.com to raw.githubusercontent.com - I haven't worked with github enough yet to be able to say anything about either of the two :)
<kyrofa> dholbach, yeah let's do that.
<dholbach> ok cool, done
<sergiusens> kyrofa, btw https://github.com/ubuntu-core/snappy/pull/442
<kyrofa> sergiusens, wait wait... what?
 * kyrofa goes to read the manpage
<sergiusens> kyrofa, just search for the second %h
<sergiusens> kyrofa, at the end of the table
<sergiusens> the second %h is at the end of the table
<kyrofa> sergiusens, why has this ever worked?
<sergiusens> kyrofa, how has it ever worked? I don't think it was ever used
<kyrofa> sergiusens, I've used it in the path. The SNAP_USER_DATA path has always been buggy in services since that directory isn't created, but it was indeed previously valid
<kyrofa> i.e. was replaced with /root
<kyrofa> sergiusens, "so the specifiers only work as shortcuts for things which are already specified in a different way in the unit file"
<kyrofa> sergiusens, I'm still not really up to speed on systemd, but after reading that maybe we had something defined elsewhere that was making this work
<kyrofa> sergiusens, also, things like 'This is the home directory of the user running the service manager instance. In case of the system manager this resolves to "/root".' give me the impression that it should be hard-coded when running in system mode
<sergiusens> kyrofa, right, that is the case for systemd user sessions
<sergiusens> root may indeed be a user of such systemd session
<sergiusens> this is the problem of root as a role and root as a user fwiw
<sergiusens> brb
<kyrofa> sergiusens, huh, yeah interesting. Thanks for the fix :)
<ogra_> well, i guess we still export SUDO_USER into the env ... you could indeed mangle the path of SNAP_USER_DATA based on tht
<ogra_> *that
<ogra_> (in a wrapper script or so)
<sergiusens> ogra_, no, SUDO_USER is not exported in a systemd unit from pid 1 ;-)
<ogra_> ah
<p1gmale0n> hi all @here
<sergiusens> kyrofa, i need to reboot, will be there in a sec
<kgunn> sergiusens: mornin' ....wondering if something else changed in 2.1 i didn't quite catch
<kgunn> so i can build my snap just fine
<kgunn> but on install attempt i get
<kgunn> mir-server_0.19_amd64.snap failed to install: open /tmp/read-file291427386/unpack/meta/package.yaml: no such file or directory
<kgunn> wondering if i need to rearrange my files?
<kgunn> you can see what i'm pkging here
<kgunn> http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snapcraft2.1/files
<noizer> I'm trying to install uwsgi but now i got following error. Somebody knows how to fix this?
<noizer> error            :/home/ubuntu/software/stage/usr/include/wchar.h:395:47: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
<florent-tengio> According to https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-packaging-ros-snaps/ , I need the plugin catkin but snapcraft saids that it doesn't exist. Do you know why?
<matiasb> kyrofa, fyi, owncloud last upload should have been fixed a while ago; and also, we just deployed a fix so there is no manual intervention needed anymore for 15.04 uploads
<kyrofa> matiasb, 8.2.2kyrofa6-armhf still has no frameworks my myapps, and I can't find it via snappy search
<kyrofa> matiasb, but great news on the fix, thank you!
<matiasb> kyrofa, hmm... let me re-check
<sergiusens> kgunn, we kill package.yaml
<sergiusens> kgunn, as ubuntu-core for devel has too; I sent an ANN email, have you seen it?
<sergiusens> kgunn, https://lists.ubuntu.com/archives/snappy-app-devel/2016-February/000580.html
<kyrofa> florent-tengio, hey there
<matiasb> kyrofa, ok, there we go, fixed now; and future uploads should just work (TM)
<kyrofa> matiasb, verified, thank you so much :)
<matiasb> yw
<kyrofa> florent-tengio, the catkin plugin should indeed exist in ever remotely recent version of snapcraft. Can you pastebin your YAML and the error you're seeing?
<florent-tengio> hey kyrofa
<sergiusens> florent-tengio, please don't PM general questions which can benefit the greater community ;-)
<kgunn> sergiusens: you didn't look at my branch did you?
<florent-tengio> ok sorry about that. Apparently I got a too old version of snapcraft
<kgunn> i've a snapcraft yaml
<kgunn> and documentation still seems to match
<kyrofa> florent-tengio, what version are you on?
<kgunn> https://developer.ubuntu.com/en/snappy/build-apps/
<kgunn> unless i am missing something
<florent-tengio> it is 0.3
<kyrofa> kgunn, it's like you're running on an old image of ubuntu core
<kyrofa> kgunn, one that's still expecting the package.yaml, but snapcraft isn't adding it in
<kgunn> kyrofa: ah crap...
<kgunn> i bet i pulled it the day of 2.1
<kyrofa> florent-tengio, oh yeah.. update :)
<kgunn> prolly just before
<kyrofa> kgunn, yeah this week has kinda sucked as far as releasing features at the same time... *cough*
<kgunn> sergiusens: kyrofa ....apologies, nvmd
<kgunn> ;) kyrofa
<kgunn> tell me brother
<sergiusens> kgunn, not yet, havne't looked at it
<kyrofa> florent-tengio, what version of ubuntu are you running?
<kyrofa> kgunn, no need to apologize by the way. Sorry for the instability :)
<florent-tengio> kyrofa it is solved now thanks
<kyrofa> florent-tengio, excellent. Let us know if you need any more help!
<joc_> florent-tengio: hi, you have newer snapcraft working now?
<kyrofa> joc_, are you having troubles?
<kgunn> kyrofa: so anyone using snapcraft 2.0 (not 2.1) will they really be able to run that anywhere? e.g. are we producing 16.04 core images somewhere...where people can "go back in time" ?
<joc_> kyrofa: hi, no i was just chatting (in person) to florent, hoping he is sorted now :)
 * kgunn just thinking about mir snap on 2.0 post...
<florent-tengio> joc_ I have on the virtual machine but apparently it is full now... due to ros install
<kgunn> prolly irrelevant today :)
<qengho> I'm trying to test a new snap on my Ubuntu classic machine. I get an error at snap install that "sc-filtergen executable not found". Is there a Dependency I should fulfill manually? Is that a bug?
<kyrofa> kgunn, no, rolling really just rolls on, you know?
<kyrofa> kgunn, sort of the nature of the beast
<kyrofa> kgunn, once it's actually released though, I doubt such disruptive changes will continue to be made
<kyrofa> qengho, you're trying to install a .snap on a normal ubuntu desktop?
<qengho> kyrofa: yes
<kgunn> just feels weird, like snapcraft2.0 came out...then immediately (effectively) broke with 2.1
<sergiusens> kgunn, it tries to catch up with the system; 2.0 snaps wouldn't work on the latest core anyways
<kyrofa> qengho, that will made you sad
<kyrofa> qengho, it's not supported right now
<qengho> :(   <- sad
<kyrofa> qengho, try installing Ubuntu Core in a virtual machine instead
<kyrofa> sergiusens, just got voip working... seems the conference call is over? :(
<sergiusens> kyrofa, yeah; just just now
<kyrofa> kgunn, yeah, it's a bit of a moving target right now
<sergiusens> kyrofa, at least you have it working now ;-)
<kyrofa> sergiusens, thanks for the info. Pretty slick, actually
<sergiusens> kyrofa, well now you can call me over sip :-P
<kyrofa> sergiusens, what, and miss seeing your face?
<sergiusens> lol
<plars> ogra_: what's the current status of dragonboard images? Should I be using yours? mvo's newer one that's currently in obsolete/old? :)
<plars> ogra_: with both of them, I can only seem to get it to boot one time, then after that it will only boot to emmc
<Guest7789> sergiusens I am having an ither isssue with catkin plugin CMake Error: your C compiler: "/home/florent/falcon/snapp/parts/foo/install/usr/bin/gcc" was not found
<kyrofa> beuno, I've made several uploads since you introduces the multi-arch support. Other than requiring separate versions, it works exactly the way I would expect. Great job :)
<beuno> kyrofa, woooo
<beuno> matiasb, ^
<elopio> kyrofa: can you tell me the variables to set to connect to staging?
<elopio> ah, nevermind. Found it in HACKING. I was looking in docs.
<kyrofa> sergiusens, add gcc to your build-packages
<kyrofa> Oops. I meant florent_tengio ^^
<matiasb> beuno, kyrofa, fyi, with the latest rollout (from a few minutes ago), you should be able to reuse version numbers for diff archs :)
<sergiusens> kyrofa, me? florent_tengio ^
<kyrofa> matiasb, oh that was rolled out too? Awesome!
 * sergiusens goes for a quick bite
<florent_tengio> kyrofa How to you do that?
<kyrofa> florent_tengio, which version of snapcraft are you on now, then?
<ogra_> plars, works fine for me with both, mvo's latest only has half a kernel, so no wifi
<florent_tengio> kyrofa 1.0.1
<plars> ogra_: oh... is there some reason you can think of that it would only boot once to snappy? I have the switch set to sd boot, obviously since it does boot once. But after that, it only boots what's on the emmc, regardless of whether I soft-reboot, or pull the power cord and hard reboot
<ogra_> plars, sounds liek your bootloader gets messed up somehow on the SD
<noizer> Hi, I want to install uwsgi with pip. when im doing that on the classic one. it works fine for me but when im trying to install it on snappy i got always the same error. (my snapcraft is 2.1)  http://pastebin.com/bqhNGgrs
<plars> ogra_: it happens every time for me, on both images
<plars> ogra_: I don't even do anything while I'm booted, just test that it boots
<ogra_> plars, right, the only thing i can imagine is that the bootloader gets messed up
<ogra_> oh
<kyrofa> florent_tengio, https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
<ogra_> thats a 4G card, nothing bigger,. like described in the README, right ?
<kyrofa> noizer, have you successfully build this standalone?
<ogra_> (bigger cards will get messed up, thus the warning to only use 4G)
<plars> ogra_: hmm.. actually it might be bigger. I need to double check.  So it could be a resize problem?
<plars> ogra_: I'll check that, I bet that's it. Thanks!
<ogra_> yes, the resize function needs to be ported to sgdisk
<plars> I *think* I still have a 4G card around here somewhere, may have to do some digging
<kyrofa> noizer, it looks like the build system is setup to treat warnings as errors
<noizer> only a snap with just uwsgi on? No I did not tried that before
<ogra_> (and probably also get a cmdline option we can set to disable it)
<kyrofa> noizer, no, I mean just by itself, without snappy or snapcraft at all
<kyrofa> noizer, these are compile errors-- they have nothing to do with snapcraft
<noizer> yes then it works well
<noizer> when you try pip install uwsgi
<noizer> then it works great
<kyrofa> noizer, can you paste your YAML as well?
<noizer> kyrofa yes offcourse
<kyrofa> noizer, and you'r encountering this in the classic dimension, or on regular xenial?
<noizer> pip install on the classic dimension there works it fine. but when i try to snap it then it gave me this crash
<kyrofa> noizer, and you're running snapcraft on the classic dimension?
<noizer> http://pastebin.com/FYYEDRk7
<noizer> yes
<kyrofa> noizer, in the future, http://pastebin.ubuntu.com/ is a little less add-heavy
<noizer> oooh ok sorry kyrofa
<kyrofa> noizer, no apologies necessary! Just wanted you to know :)
<noizer> :p
<kyrofa> noizer, alright let me give this a shot
<kyrofa> florent_tengio, did you get that working?
<florent_tengio> kyrofa no
<kyrofa> florent_tengio, have you tried the build-packages?
<florent_tengio> kyrofa yes I have added build-packages: - gcc
<florent_tengio> with the correct indentation
<kyrofa> florent_tengio, and you get the same error?
<florent_tengio> kyrofa yes
<kyrofa> florent_tengio, oh, looking at your error message again, try adding it to stage-packages instead
<elopio> pindonga: do you know if there's a way to test getpass with subprocess?
<elopio> I see there's the pexepect module, but I wouldn't like to add it if there's another way.
<pindonga> elopio, no idea... but I don't see why not, as long as stdin/stdout are properly captured by the subprocess
<elopio> pindonga: no, getpass does something different. I can capture the email prompt, but not that one.
<elopio> I think I could tell get pass to use stdout, not the tty, but that doesn't sound to good. Or get a test tty, but I guess that's what pexpect does for me.
<elopio> I'm trying...
<ogra_> ... therefore i am
<elopio> I'm test therefore I am.
<ogra_> :D
<qengho> Hi again. Help? How do I get the Snappy Dimension on Classic installed and working?
<ogra_> sudo snappy enable-classic
<ogra_> snappy shell classic
<qengho> Oh man. That's good. Though, the man page and help has all sorts of things that should never be known to a user like "booted" and "grub-migrate", and that's not mentioned.
<ogra_> if you just run "snappy" without any options it tells you about it though :)
<qengho> Ah, maybe it's my version of snappy. No option.
<ogra_> well, thats 16.04
<ogra_> 15.04 didnt have classic iirc
 * ogra_ curses
<qengho> ogra_: 0.3.7-1.1? What does your "apt-cache policy snappy" say?
<Sweet5hark> so ...
<ogra_> qengho, there is no apt on snappy
<ogra_> qengho, you are not trying to use classic on a desktop, do you ?
<Sweet5hark> I have build LibreOffice with debug symbols, threw strace and gdb into the snap for fun, sneaked in an additional disc mounted on /apps to have enough space and then looked at what LibreOffice does.
<qengho> ogra_: oh, yes. I thought that was it was for. Maybe I have it inside-out.
<ogra_> qengho, classic is a container that sits on top of the readonly rootfs, adding a writable overlay and re-adding the missing apt bits to make it behave like a "normal" ubuntu
<Sweet5hark> (with LD_LIBRARY_PATH set and under strace that is)
<ogra_> so it enables you to use apt in a container (with bind mounts into the relevant dirs ... i.e. ~/ is shared)
<qengho> ogra_: Ah, yeah, I thought it was backwards. Snappy inside a container running on old-timey Ubuntu.
<ogra_> yeah, thats different
<ogra_> isnt that called purtine ?
<ogra_> (ask bregma, i think his team works on that stuff)
<bregma> Libertine
<ogra_> ah, that uses snappy ?
<bregma> not yet
<Sweet5hark> turns out it hangs with EAGAIN on trying to read/dlopen a libdesktop_detectorlo.so. at least ldd says it finds all libs. any hint what might wrong?
<ogra_> i thought that was just a wrapper for apt packagews
<Chipaca> Sweet5hark, 'audit' logs do you get?
<qengho> ogra_: thank you for explaining. I have a snap that hope will display to X. Does "Snappy Dimension on Classic" provide X?
<ogra_> qengho, no, i doubt you will ever see native Xorg support in snappy ... XMir is the way to go
<elopio> pitti: is there a way to pass secrets to the autopkgtests ?
<elopio> I have a test that requires a password. I can run it on travis, but I think I'll have to skip it in autopkg.
<dholbach> all right my friends - I call it a day - have a great weekend! :-)
<elopio> bye dholbach
<ogra_> ppisati, hulp !
<ppisati> ogra_: ???
<ogra_> ppisati, i cant load any dtb from 0x100 on the rpi with the new bootloader firmware tree
<ogra_> do you know where it moved to ?
<ogra_> (fdt addr 0x100 throws a "bad magic" error)
<ppisati> ogra_: what's your version? because i update the fw in Jan and it was ok
<ogra_> ppisati, i'm on the "next" branch
<ppisati> ogra_: oh, then you are into the future :)
<ppisati> ogra_: sorry, don't know
<ogra_> (default for the 4.4 kernel)
<ppisati> ogra_: dump the memory from uboot until you find something resembling it
<ppisati> ogra_: that's what i did
<ogra_> ppisati, well ... bug 1500755
<ubottu> bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Confirmed] https://launchpad.net/bugs/1500755
<ogra_> apparently someone has it working by just replacing start.elf and fixup.dat
<ppisati> ogra_: hold on
<ogra_> (though it might already work in "master" (vs next) ... i see there were some recent changes to their dtb)
<ppisati> ogra_: try if this helps
<ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/raspberrypi2-firmware_4.1.15-b70b451-1_armhf.deb
 * ogra_ tries
<ppisati> ogra_: i don't have my raspi2 hooked up
<elopio> sergiusens: kyrofa: no planning today?
<kyrofa> elopio, yeah sorry, baby hugs
<code1o6> Hello guys, is there a way to add a login screen to webdm?
<ogra_> ppisati, at least no bad magic error
<ogra_> but ... [   12.665908] unexpected IRQ trap at vector 00
<ogra_> (during initrd)
<ppisati> ogra_: panic?
<ogra_> nope, just this message in a loop
<ppisati> ogra_: ah
<ogra_> let me try with a newer dtb
<ppisati> ogra_: i'm using it with the 4.3 kernel (and people reported success with 4.4 too)
<ogra_> ppisati, well, the bug is specifically about missing device support
<ppisati> ogra_: actually, i got the camera working fine in 4.3 + that firmware
<ppisati> ogra_: even 4.2 actually
<ogra_> via /dev/vchiq ?
<ppisati> ogra_: i used raspistill
<ogra_> (seems to be a node for some "hat" board)
<ppisati> ogra_: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
<ubottu> Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New]
<ogra_> yeah, doesnt use that device node
<ppisati> ogra_: i don't know, my raspi2 is not hooked ATM
<ppisati> ogra_: if you want we can debug this further
<ogra_> we surely have to if i dont get it to work :)
<ppisati> ogra_: k, i'm about to beer'o time
<ppisati> ogra_: ping me first thing monday and we can have some fun
<ogra_> yeah, i'll try my luck over the weekend, if i cant get it going i'll sit on your lap on monday
<ppisati> ogra_: ack
<ogra_> enjoy the beer and thanks for the help :)
<ogra_> (btw, the error is gone using the latest dtb file)
<ppisati> ogra_: updating the dtb ususally helps :)
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls -l /dev/vchiq
<ogra_> crw------- 1 root root 245, 0 Feb  5 17:13 /dev/vchiq
<ogra_> \o/
<sergiusens> elopio, oh my, I completely missed the time it is
<sergiusens> elopio, so sorry
<kyrofa> sergiusens, that's alright, this one wasn't huge since we're not releasing on cadence next time around
<didrocks> kgunn: hey, I think you know more on that area than I, do you mind answering this: http://askubuntu.com/questions/729540/can-i-run-any-other-display-server-on-ubuntu-core-except-for-mir?
<didrocks> sergiusens: kyrofa: I would be interested (personally) if you can give an answer on http://askubuntu.com/questions/729762/snapcraft-make-plugin-change-directory :)
<kyrofa> didrocks, ah, thank you! I don't have the snapcraft tag setup
<didrocks> kyrofa: one more to add to get more badges! :-)
<kyrofa> didrocks, and yes, answering now
<sergiusens> kyrofa, ok, I'll +1 if it is good enough ;-)
<ogra_> elopio, so there is a new pi2 oem snap for 15.04 in the store ... would be nice if that could get some testing on 15.04/edge so we are sure i didnt regress anything before next 15.04 release
<ogra_> didrocks, ^^ thats your fix for the vhciq device stuff btw
<elopio> ogra_: sure, I was planning to do the testing this evening.
<ogra_> cool
<elopio> ogra_: can you move it to alpha? That makes things easier.
<ogra_> elopio, it will be used on all 15.04 builds now (thats the oem snap u-d-f pulls from the store at image creation time)
<ogra_> (this includes alpha as well as edge and stable)
<elopio> got it.
<kyrofa> sergiusens, didrocks how's that?
<didrocks> kyrofa: perfect! :)
<didrocks> kgunn: thanks as well
<didrocks> ogra_: wooooo
<xnox> ogra_, who shall i assign bug about unity-scope-snappy?
<xnox> ogra_, can i like drop the package from the archive?
<ogra_> xnox, no idea, never heard of it
<kyrofa> xnox, ask alecu about that
<ogra_> is that the store scope ?
<kyrofa> xnox, what's the problem with it? ogra_ yeah
<xnox> kyrofa, alecu, hi! unity-scope-snappy FTBFS in xenial, because of golang-go 1.6 (cgo argument has Go pointer to Go pointer), which has become invalid Go. And it has invalid Built-Suing metadata. It says "Built-Using: golang-go.tools (= )" there must be a version after '='
<xnox> kyrofa, alecu: and there are test suite failures.
<xnox> somehow i think it does not work at all with current snappy.
<xnox> bug #1542376
<ubottu> bug 1542376 in unity-scope-snappy (Ubuntu) "invalid golang-go.tools Built-Using dependency generated" [Critical,Confirmed] https://launchpad.net/bugs/1542376
<xnox> bug #1534346
<ubottu> bug 1534346 in unity-scope-snappy (Ubuntu) "FTBFS with golang-go 1.6 beta2" [Undecided,New] https://launchpad.net/bugs/1534346
<xnox> who shall I assign these bugs to?
<kyrofa> xnox, yeah it's a bit old nowadays. I would suspect it's okay to drop given the prioritization of Ubuntu Personal, but yeah I'd hear from alecu and maybe kgunn about it first
<xnox> kyrofa, $ seeded-in-ubuntu unity-scope-snappy
<xnox> unity-scope-snappy's binaries are not seeded.
<xnox> ..
<xnox> i don't think it's in use.
<kyrofa> xnox, yeah it was only ever seeded in personal
<olli> ogra_, late night Fri ping
<alecu> xnox: yes, I think it's fine to drop it, since it was coded against an old version of the snappy rest interfaces
<ogra_> olli, whats up ?
<olli> ogra_, mind checking 1 mail for me pls?
<alecu> and we are not updating it for now.
<olli> sorry about the late ping
<xnox> alecu, kyrofa - let me file an RM bug, and please comment on it. One moment.
<sergiusens> elopio, kyrofa http://paste.ubuntu.com/14894403/
<elopio> sergiusens: :o
<sergiusens> xnox, Built-Using is generally auto added by dh-golang
<kyrofa> sergiusens, niiice
<xnox> sergiusens, sure. but in this case it's borked up. and it's impossible for me to rebuild to see if a rebuild would fix the built using =/
<xnox> sergiusens, and this trips up germinate.
<xnox> kyrofa, alecu - please comment your approval on https://bugs.launchpad.net/ubuntu/+source/unity-scope-snappy/+bug/1542451
<ubottu> Launchpad bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged]
<xnox> approval to remove the package.
<sergiusens> xnox, k, I'm just saying that maybe other packages have broken Built-Using's ;-)
<xnox> sergiusens, =) true. So far this is the only one like that, that i found.
<xnox> well, tripped on.
<genii> BTW, may want to increment the copyright year to 2016 soon. I just built from git and still says 2015
<sergiusens> genii, only for files we changed in 2016 or where is this coming from?
<sergiusens> kyrofa, elopio if you are feeling it https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1480144/cleanbuild-lxd
<sergiusens> you can start looking ;-)
<genii> sergiusens: Sorry, that was for #quassel
<elopio> sergiusens: s/2015/2016
<sergiusens> elopio, yeah, done already ;-)
<sergiusens> some had some didn't :-p
<elopio> sergiusens: what's the most simple valid snapcraft.yaml that generages a valid snap?
<sergiusens> elopio, I think it is the webchat one or gopaste
<elopio> sergiusens: can't we cut it even further?
<sergiusens> elopio, something with the copy plugin maybe
<tyhicks> has anyone gotten the latest all-snaps rpi2 image to work?
<tyhicks> the bbb image works for me but not rpi2
<elopio> tyhicks: let me flash and try.
<tyhicks> elopio: thanks - I get 7 blinks of the ACT led
<elopio> tyhicks: do you have at hand the name of the kernel and gadget?
<tyhicks> elopio: I don't
<tyhicks> elopio: I was trying these images: https://people.canonical.com/~mvo/all-snaps
<elopio> I wanted to generate it with that u-d-f. but I'll just download it.
<elopio> pindonga: https://bugs.launchpad.net/snapcraft/+bug/1542476
<ubottu> Launchpad bug 1542476 in Snapcraft "snapcraft upload forbidden for user without signed agreement" [Undecided,New]
<pindonga> elopio, right
<pindonga> not sure if I mentioned it in the docs or not
<pindonga> but it's a requirement
<elopio> pindonga: sure, that's clear. We need a better message for when the user doesn't meet the requirement, but I'm not sure what's feasible to ask.
<elopio> tyhicks: works for me: https://paste.ubuntu.com/14895861/
<pindonga> I think we should start by showing a link and asking them to login via the web ui
<pindonga> and sign it there
<pindonga> that's the minimum we can do
<tyhicks> elopio: ok, thanks for testing - I'll keep trying to hunt down the issue on my end
<elopio> tyhicks: do you have a serial cable?
<elopio> well, THE serial cable.
<tyhicks> elopio: no :/
<elopio> tyhicks: https://www.adafruit.com/products/954
<tyhicks> ah, nice
<tyhicks> that would be helpful
<tyhicks> elopio: do you know if this applies to the rpi2? http://elinux.org/R-Pi_Troubleshooting#Green_LED_blinks_in_a_specific_pattern
<elopio> tyhicks: I don't know. I know that it wasn't working as expected on the bbb: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1510165
<ubottu> Launchpad bug 1510165 in linux (Ubuntu Wily) "heartbeat module is not loaded" [Undecided,Fix released]
<elopio> so I wouldn't trust it too much.
<tyhicks> elopio: ok
<elopio> pindonga: why is my uploaded snap saying this in the store? (NEEDS REVIEW) squashfs pkg lint_is_squashfs
<pindonga> elopio, squashfs based snaps don't get automatically approved yet
<elopio> pindonga: oh, sad, I can't finish my test. Can't we have autoapprove at least for staging, like today? :)
<pindonga> so they're flagged for manual review
<pindonga> elopio, nopes
<pindonga> like, I'm literally EODing right now :)
<elopio> pindonga: oh well, then lunch time for me :D let's talk on monday.
<pindonga> elopio, afaiui it's still missing some pieces in click-reviewers-tools
<elopio> thank you, and enjoy the evening.
<pindonga> so not something we control in the store
<pindonga> elopio, as soon as the proper supports lands in click-reviewers-tools we can pull it and get the store to auto-approve those snaps
<pindonga> anyway... bye!
<pindonga> see you on monday
<elopio> ack. There will be a test eagerly waiting for that day.
<elopio> beuno: just so you put it higher in the queue, for me ;) ^
<sergiusens> elopio, https://github.com/ubuntu-core/snapcraft/pull/303
<sergiusens> kyrofa, too ^
<elopio> sergiusens: how does this work with two spaces? --output  SNAP
<elopio> I thought I read on docopt that the two spaces were for the help
<sergiusens> elopio, I don't know, but it does
<sergiusens> elopio, I'm fixing it anyways
<elopio> sergiusens: maybe an integration test with --output, just to be extra safe
<sergiusens> elopio, sure
<sergiusens> elopio, ah, can't do subtests
<sergiusens> AttributeError: 'NoneType' object has no attribute 'result_supports_subtests'
<sergiusens> elopio, done
<elopio> sergiusens: interesting. I thought testtools would just support that. Maybe it's an outdated version.
<elopio> sergiusens: you can do testscenarios.
<sergiusens> elopio, I split it in two tests for now
<elopio> but the duplication is not much. Do it as you wish.
<sergiusens> elopio, testscenarios are so confusing if you don't know the semantics though
<elopio> sergiusens: I think you are right. I'm slowly liking subtests.
<sergiusens> I used to use it, but I it's one of those things that is not straightforward
<sergiusens> elopio, look at pylxd, it has an interesting scenario based testing using annotations which look super straightforward
<elopio> with annotations if I put two, I never get the order right.
<elopio> I'll kae a look.
<sergiusens> elopio, so I need a release with this before I can move on with cleanbuild
<sergiusens> elopio, right that is the problem when using @
<sergiusens> :-)
<elopio> woa, it's late.
<elopio> <- lunch
<sergiusens> elopio, I think it is this or to not enable mvn testing for adt https://github.com/ubuntu-core/snapcraft/pull/305
#snappy 2016-02-06
<dasjoe> TIL about rng-tools
<Tenacious-Techhu> To what extent is Snappy secure by default, and in what cases is it not?
<anpok> do gadget snaps require a special way of snappy build invocation?.. ubuntu-device-flash seems to expect a oem/name/verson/meta/package.yaml in the snap, but the one I created with snappy build has an apps/name/somechecksum/meta/package.yaml
<anpok> or do i need a newer udf that looks for apps instead of oem
<Tenacious-Techhu> To what extent is Snappy secure by default, and to what extent is it not?
#snappy 2016-02-07
<Tenacious-Techhu> Where mah humans at?
<maxxy> -copylocalfrom isnt working
<maxxy> der ?
<maxxy> anyone
<maxxy> -copyfromlocal doesnt work in my system
<maxxy> ??
<maxxy> waiting for ure reply
<maxxy> -copyfromLocal: Unknown command
<maxxy> dis is the error
#snappy 2017-01-30
<nacc> stokachu: np
<mup> Bug # changed: 1627893, 1632124, 1632306, 1642257
<mup> PR snapd#2740 closed: releasing snapd version 2.22 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2740>
<mup> PR snapd#2738 closed: spread: remove state tar on project restore <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2738>
<mup> PR snapd#2691 closed: tests: allow to install snapd debs from a ppa instead of building them <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2691>
<mup> PR snapd#2693 closed: cmd: rename mountinfo to sc_mountinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2693>
<mup> PR snapd#2742 opened: tests: fix typo in systems name <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2742>
<mup> PR snapd#2676 closed: cmd: collect string utilities in one module, add missing tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2676>
<zyga> good morning
<zyga> sorry for joinling late, forgot I turned my server off
<popey> http://askubuntu.com/questions/877850/error-cannot-deliver-device-serial-request-unexpected-status-400 <- any snappy people can help this person out?
<zyga> popey: hey
<zyga> popey: most of the time when this happens is when people build their own model
<zyga> popey: or use a board outside of the supported set
<mup> PR snapd#2742 closed: tests: fix typo in systems name <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2742>
<mup> PR snapd#2713 closed: cmd: fix issues uncovered by valgrind <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2713>
<mup> PR snapd#2416 closed: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2416>
<mup> PR snapd#2739 closed: tests: remove (some) garbage files found by restore cleanup analysis <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2739>
<mup> PR snapd#2698 closed: asserts,interfaces/policy: add support for $SLOT()/$PLUG()/$MISSING in *-attributes constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2698>
<mup> PR snapd#2743 opened: debian: move the snap-confine packaging into snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2743>
<mup> Bug #1648777 changed: writing a (3GB sized) x86 image to a 3GB SD card makes the filesystem resizing being skipped <Snappy:Invalid> <initramfs-tools-ubuntu-core (Ubuntu):Invalid by ogra> <https://launchpad.net/bugs/1648777>
<mup> PR snapd#2658 closed: cmd: add mount / unmount helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2658>
<kalikiana> Hrm
<kalikiana> Cannot find the definition for part 'desktop-ubuntu-app-platform'.
<kalikiana> It may be a remote part, run snapcraft update to refresh the remote parts cache.
<kalikiana> ^^ This seems to be a regression? Cloud parts used to be pulled in automatically
<kalikiana> I was quite confused and it took me a bit to realize the part name wasn't wrong
<didrocks> ogra_: hey! what do you think about adding a configure/install hook on the classic snap running apt update to initialize the apt database for the user?
<ogra_> didrocks, not much since that forces you to be online
<ogra_> didrocks, well, we could add it with an online check i guess ... but the whole thing is designed so that you can also use it witouth being online at all
<didrocks> ogra_: well, when you install the snap, you are online already, correct? :)
<ogra_> true indeed
<didrocks> and it we can try to make it ran only at that time?
<didrocks> I'm happy to have a shot at it
<didrocks> (not today)
<didrocks> but just wanted to know if you were +1 first on it
<ogra_> sure, the script that gets executed is actually shipped in the core snap
<ogra_> and is only executed the first time you run "sudo classic"
<icey> seems like a snap installed app can't read from the keyboard?
<didrocks> ah, I was more thinking as a hook in the classic snap itself
<icey> also, can't click on a link in the snapped app and open it in the system browser
<ogra_> "read from the keyboard" ?
<ogra_> do you have a camera attached ? :P
<ogra_> didrocks, nah, it should just become part of the setup script ... the classic snap only calls this
<didrocks> ogra_: ok, do you have the repo reference handy? If not, no worry, I'll have a shot later anyway
<ogra_> no repo ... it is part of the livecd-rootfs package in the image PPA
<icey> ogra_: copying text into a snapped app is weird
<didrocks> ogra_: ok, which ppa? (if you prefer to do it yourself, feel free ;))
<ogra_> didrocks, http://paste.ubuntu.com/23893526/
<ogra_> didrocks, from https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<didrocks> ogra_: excellent! Thanks a lot :)
<ogra_> (note that the pasted one is outdated, use the actual one from the PPA)
<didrocks> yeah, I'll be able to find it, I'm sure :)
<jdstrand> davidcalle: ping re security whitepaper (I asked a question probably after your eod on friday)
<zyga> jdstrand: hey
<jdstrand> zyga: hey :)
<zyga> jdstrand: I'm working on the kernel bug and also on the string changes you suggested
<zyga> jdstrand: I think the outcome will be much safer, thanks for that!
<jdstrand> zyga: gret! :)
<jdstrand> great even!
<davidcalle> jdstrand: I'm on it today, pdf is live already
<jdstrand> davidcalle: hi! :) ok, so is https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ the correct url for the whitepaper? it is out of date, but the pdf it links to is up to date
<davidcalle> jdstrand: indeed, I've uploaded the new pdf, updating the page as we speak (will be live in a short moment)
<jdstrand> davidcalle: ah, I see. ok, thanks! :)
<om26er> what should I do if I want some feedback from the user once a snap is installed ? I am working on a selenium based twitter bot that is going to run on xvfb. For twitter login I need to request username/password from the user to login.
<om26er> is there probably a way to run a script once a snap is installed ?
<mup> PR snapd#2558 closed: snapstate: move refresh from a systemd timer to the inernal snapstate Ensure() <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2558>
<kirkland> sergiusens: is that perhaps why my snap isn't showing up in the store?  because it's classicly confined?
<mup> PR snapd#2744 opened: move configstate.Transaction stuff into configstate.transaction <Created by mvo5> <https://github.com/snapcore/snapd/pull/2744>
<stokachu> kirkland, snap find conjure-up works though it returns a bunch of results
<kirkland> stokachu: can you "snap find hollywood"?
<stokachu> snap find hollywood
<stokachu> The search "hollywood" returned 0 snaps
<stokachu> kirkland, is our snap published/public in the webui?
<stokachu> your*
<kirkland> stokachu: yes, it looks like it
<stokachu> kirkland, not sure if this helps but here is what mine looks like from the webui: http://imgur.com/a/pEiEp
<stokachu> kirkland, oh do you have a stable snap published?
<stokachu> i have at least one stable
<kirkland> stokachu: ah, maybe that's it?
<kirkland> stokachu: so, I need to change "grade: devel" to "grade: stable" in snapcraft.yaml?
<kirkland> stokachu: rebuild, reupload?
<stokachu> kirkland, try just releasing it to stable channel from the webui
<stokachu> jdstrand, is kirkland's hollywood snap not showing up in the snap search results b/c it hasn't been approved?
<kirkland> <jdstrand> 00:40:01> kirkland: done. approved but you'll need to release it
<kirkland> I got that on Friday
<kirkland> and then I did release it
<stokachu> kirkland, ah ok
<jdstrand> stokachu: it is in beta and edge. 'stable' is the only channel 'snap find' will give results for
<jdstrand> kirkland: fyi, I see 1.12 is uploaded but not released anywhere
<kirkland> 1 kirkland@x250:/tmp/sandbox.hwgfBlQv/hollywood/snapâ« snapcraft release hollywood 1 stable
<kirkland> Revision 1 (classic) cannot target a stable channel (stable, grade: devel)
<kirkland> aha!
<kirkland> now that worked
<kirkland> (bumped the rev)
<stokachu> kirkland, \o/
<jdstrand> kirkland: you seem to have specified 'grade: devel' which means it will never go to stable
<jdstrand> kirkland: ah, you fixed that in 1.12
<jdstrand> and snap find now finds it
<stokachu> kirkland, haha nice snap
<qengho> What does hollywood do, kirkland?
<kirkland> qengho: https://www.youtube.com/watch?v=rVMn3xk5mcY
<qengho> Ah! I remember this.
<qengho> This reminds me of a tool I remember from my early unix days, when I was just an egg. Our auditory processing is as good or better than visual attention. An app would convert network traffic into sound. You'd start it and maybe hear that something seems a little off today.
<cos-> what's the trick to create a desktop launcher with snap? i have desktop: entry in app: but no icon appears in menu
<cos-> a working example would be nice
<zyga> cos-: it's tricky, ask sergiusens
<cos-> also having a desktop in setup/gui doesn't seem to work, as examplified here https://github.com/ubuntu-core/snapcraft-examples/blob/master/03-hello-world-desktop-devmode/setup/gui/hello-world-desktop.desktop
<ogra_> cjwatson, hey ... we need some expert opinion ... in the core images we used to use a profile.d snippet to extend the PATH with /snap/bin (we do that in classic still), for remote ssh commands without login shell that didnt work, so we moved the /snap/bin to the global PATH in /etc/environment ... now it turned out that some tests actually use su ...
<mup> PR snapd#2745 opened: cmd: add sc_must_stpcpy <Created by zyga> <https://github.com/snapcore/snapd/pull/2745>
<zyga> jdstrand: hey, could you please have a look at this pull request: ^^ this is the safe stpcpy we've discussed.
<ogra_> cjwatson, i remember you being opposed to change ENV_SUPATH (and i'm slightly reluctant to touch login.defs at all) ... should we or should we not change it there ?
<zyga> jdstrand: my only comment was to perhaps use memmove just to be super paranoid safe
<ogra_> cjwatson, or rather ... what would be the drawbacks
<cjwatson> ogra_: just /etc/environment is supposed to work for su as well; this is basically https://wiki.ubuntu.com/OneTruePath
<kirkland> stokachu: okay, we're there now :-)
<ogra_> ah, i didnt find the wikipage
<cos-> and for qt5 app should i have after: desktop/qt5, desktop-qt5 or qt5conf? all are used in different examples
<cjwatson> ogra_: I don't think you should change it there, but rather you should chase down why su's use of pam_env apparently isn't working?
<stokachu> kirkland, cool man
<ogra_> cjwatson, well, it seems it doesnt
<kirkland> stokachu: thanks for your help
<cjwatson> ogra_: I'm not arguing with that, but from the config file on my system it seems that it should
<stokachu> np anytime
<cjwatson> ogra_: so that seems worth tracking down rather than working around and forgetting
<ogra_> ok, thanks
<mup> PR snapcraft#1092 opened: meta: properly get the icon extension from splitted name <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1092>
<cos-> sergiusens: i'd appreciate any help with creating a .desktop launcher. my current code is here https://github.com/vranki/siilihai-client
<ogra_> cjwatson, hmm, are you actually sure su should use pam_env for PATH ? the manpage sounds like some vars wont be read from there http://paste.ubuntu.com/23894355/
<cos-> hmm, maybe the used files should be in the git repository and having them in the build directory isn't enough.. i'll try recreating the package with files in git
<ogra_> cjwatson, note the "Other" in there
<cjwatson> ogra_: see /etc/pam.d/su
<cjwatson> I see no reason to assume the manual page is up to date with the intended PAM configuration :-)
<ogra_> lol
<ogra_> ok
<mup> PR snapcraft#1093 opened: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093>
<stokachu> sergiusens, ^ will that fix classic install on trusty?
<elopio> ogra_: you are scheduled for the linaro open hours on feb 23th, 8am pacific time.
<ogra_> elopio, ok, i'll add that to my calendar
<elopio> Chipaca: zyga: would you like to join them for an episode and talk about ubuntu core 101? it would be feb 16th.
<elopio> ogra_: thanks. Robert will send you an email with the details.
<ogra_> great
<Chipaca> elopio, can i think about it?
<zyga> elopio: yes, gladly
<elopio> Chipaca: yes, and you can also say no :) This is the thing: http://www.96boards.org/OpenHours/
<zyga> elopio: can you please send me an invite? I forget everything otherwise :)
<elopio> thanks zyga.
<ogra_> elopio, huh, saying no is an option ?!?
<ogra_> :P
<elopio> ogra_: it was an option for you last week. Not anymore :p
<ogra_> haha
<elopio> kgunn: are you around now? I'm not sure if you got my ping, maybe email is better.
<elopio> jamiebennett: and this is the thing you signed up for: https://www.youtube.com/watch?v=P1_HjzcnJ-s
<kgunn> elopio: what's up
<elopio> you will be the main panelist on the march 9th.
<kgunn> about to go for a run....but at least i got your most recent ping
<jamiebennett> elopio: I did ;)
<jamiebennett> ogra_: is also going so maybe we can tag team
<elopio> kgunn: hello! go and run. I'm sending you an email to see if you want to show the kiosk on linaro openhours and ubuntu testing days.
<kgunn> ah, elopio ok.... cc AlbertA ;)
<elopio> will do.
<elopio> jamiebennett: ogra_: Robert said rsalveti will be in the panel too. I can only imagine the party afterwards :D
<ogra_> elopio, lol
<ogra_> and i know in which bar it will happen !
<zyga> elopio: my pleasure :-)
<zyga> elopio: lol :)
<rsalveti> o/
<ogra_> hah, the lurker !
<zyga> rsalveti: hey :)
<zyga> rsalveti: how are you doing?
<rsalveti> good :-)
<rsalveti> who are going to be at connect?
<ogra_> o/
<zyga> rsalveti: I think only ogra_
<rsalveti> how are things at the snappy land :-)
<zyga> connect is in US so I cannot go :/
<rsalveti> ogra_: oh! that would be awesome
<ogra_> rsalveti, it will !!!
<ogra_> zyga, huh ? budapest i thought ...
<zyga> rsalveti: reliable little by little
<zyga> ogra_: oh
<zyga> ogra_: the vegas thing confused me
<zyga> then I could go
<zyga> (if someone would want me there)
<ogra_> i guess the US is dead territory for conferences for the next 4 years
<rsalveti> hahah, indeed
<rsalveti> ogra_: going to drive there?
<ogra_> nah
<rsalveti> don't remember if you did that last time
<ogra_> i did
<rsalveti> right, I had some good memories :-)
<zyga> ogra_: or 16
<ogra_> but i largely gave up on cars ... so it would be rental or train ...
<zyga> ogra_: 4 + 4 then after the war with canada and mexico is over ;)
<ogra_> its a lovely ride thogh ...
<ogra_> zyga, if it is only canada and mexico, yeah
<rsalveti> get a new porsche
<ogra_> nah, i still need to get rid of the three others :P
<zyga> ogra_: then china invades and all connects will be in china ;-)
<ogra_> you mean "berlin - china" or "paris -china" ?
<ogra_> :)
<zyga> ogra_: just bejning east, west, central, etc...
<ogra_> lol ...
<zyga> ogra_: on the upside, aliexpres will ship locally
<ogra_> everywhere
<zyga> from the moon :D
<ogra_> apart from UK though ... because of brexit
<zyga> I still wait fo brexit for electricity, to stop the immigration of electrons from mainland
<ogra_> haha
<zyga> UK could switch to 100VCD
<mup> PR snapd#2712 closed: interfaces/builtin: refine the content interface rules using $SLOT <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2712>
<blackboxsw> sergiusens
<blackboxsw> sorry my bad. was search the responses in the irc term
<blackboxsw> was searching*
<blackboxsw> was looking for hints as to why "service snap" namespace in trusty doesn't seem to map to a given snap running snap.  For example, "sudo service snapd status" works on xenial, but not on trusty
<mup> PR snapd#2746 opened: interfaces: remove some syscalls already in the default policy plus comment cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2746>
<mup> PR snapd#2747 opened: interfaces/mount-observe: add quotactl with arg filtering (LP: #1626359) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2747>
<mup> PR snapd#2748 opened: seccomp-support.c: add PF_* domains which can be used instead of AF_* <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2748>
<zyga> jdstrand: hey, still around?
<mwhudson> wtf, i think i've found a glibc bug
<zyga> mwhudson: hey
<zyga> mwhudson: long time, how are you?
<mwhudson> zyga: ok!
<mwhudson> zyga: well right now i am in a rabbit hole but otherwise :)
<zyga> mwhudson: what are you up to? do you need a garden elf assistant? :)
<mwhudson> zyga: i'll have a bug comment in a minute
<mwhudson> zyga: i hope you didn't say 'elf' there by accident
<zyga> hehehe
<zyga> such a versatile word :) works both ways
<mwhudson> oh heh i commented by email so i can't show it to you yet
<mwhudson> zyga: it will be here in a few minutes: https://bugs.launchpad.net/snapd/+bug/1657504/comments/18
<mup> Bug #1657504: asciinema 1.3.0 snap is segfaulting on 14.04 <Snapcraft:In Progress by sergiusens> <snapd:New> <https://launchpad.net/bugs/1657504>
<mcphail> I could never get dlopen() to work in a snap I was making
<mwhudson> zyga: it's there now
<mwhudson> mcphail: a classic or strict snap?
<mcphail> mwhudson: strict
<mwhudson> mcphail: probably something a bit different from this then, i think
<mcphail> mwhudson: aah, OK
<zyga> mwhudson: oh, intereting
<zyga> mwhudson: looking
<zyga> I was working on that part so very keen to get to the bottom ofthat
<mwhudson> zyga: the code in glibc is around here https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-load.c;h=a5318f9c8d1d42745a254479cf6bb1cd2acd516f;hb=HEAD#l2035
<mwhudson> zyga: DT_RUNPATH is only like 15 years old, of course there are still loads of obscure bugs when you try to use it
<zyga> mwhudson: do you know if nss works by loading modules into the process or by doing IPC to something that loads the modules?
<mwhudson> zyga: it just calls dlopen
<mwhudson> this is one of the reasons static linking with glibc don't work good
<mwhudson> zyga: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nsswitch.c;h=0a65f6ad0c640ae144cbe9d7c2edf9d67e67a245;hb=HEAD#l358
<zyga> mwhudson: that makes sense, I recall a warrning from the linker when one does that to name resolution functions
<zyga> mwhudson: so what should we do to have libc load the nss modules from the core snap?
<mwhudson> zyga: fix glibc to look at DT_RUNPATH in the executable, i think
<mwhudson> zyga: which is of course going to be loads of fun
<mwhudson> zyga: you could also try turning off the flags that make ld emit RUNPATH vs RPATH
<zyga> mwhudson: and good fun of work
<zyga> fun kind of work :)
<mwhudson> well at least you don't have to argue with mr drepper any more
<zyga> mwhudson: actually I don't know why I suggested to use the newer version of those flags
<zyga> mwhudson: for the initial experiment rpath worked just as well
<mwhudson> zyga: if you use RPATH, LD_LIBRARY_FLAGS is ignored
<zyga> mwhudson: but AFAIK we don't need LD_LIBRARY_FLAGS for classic snaps
<zyga> mwhudson: (for those that are linked properly)
<mwhudson> oh heh this dude found the same thing as me http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/
<mwhudson> (and i'd read that post before too)
<zyga> mwhudson: question: would it be possible to invoke the dnyamic linker to ask it to load an executable without rpath/dtrunpath?
<zyga> mwhudson: e.g. to load /bin/true from the core snap that is just vanilla /bin/true in an odd location
<mwhudson> zyga: i don't understand, sorry
<mwhudson> zyga: you don't feel like writing something that adds DT_RUNPATH (and edits the ELF interpreter) to all binaries in the core snap? :)
<mwhudson> (i presume in strict snaps the core snap is available at both / and /snap/core/current ?)
<zyga> mwhudson: that's the problem actually, it's not
<zyga> mwhudson: and we want one core snap, not two (one for classic and one for strict confinement)
<zyga> mwhudson: in strict confinement core snap is / and you cannot read /snap/core/*
<mwhudson> zyga: ah
<mwhudson> zyga: fun times
<zyga> mwhudson: in classic confinememt core snap is /snap/core/* and you can read anything
<zyga> mwhudson: goal: make it possible to run stuff from the core snap in both cases
<zyga> mwhudson: I was thinking about having snap-exec run the dynamic linker (even patched one since it's the one from the core snap)
<mwhudson> zyga: don't see how that's possible
<zyga> mwhudson: and load the application with some fancy defaults
<mwhudson> oh
<mwhudson> something like that might work
<zyga> mwhudson: but that breaks down when we exec something from the core snap (e.g. we run bin/sh but then we run bin/ls)
<zyga> mwhudson: because then the system (wrong) linker gets used
<mwhudson> yeah
<zyga> mwhudson: I don't know of a way to force "gimme that linker" somehow
<zyga> mwhudson: unless
<zyga> mwhudson: we do some hackery around exec in the libc that ships in the core snap
<zyga> mwhudson: then it might just work allright
<zyga> mwhudson: it'd be a simple case of path comparison, if starts with /snap -> use fancy linker mode
<zyga> mwhudson: crazy? certainly! possible? maybe
<mwhudson> can you bind mount something over /lib/ld-linux.so.2?
<mwhudson> uh not that one
<zyga> mwhudson: no, because in confinement: classic mode we don't have a mount namespace so everything in the system would sere that
<zyga> mwhudson: we can but that's hurt us
<mwhudson> yeah
<zyga> mwhudson: and distros would be looking at us carefully if we bind mount over /lib for eveyone to see just to run
<zyga> mwhudson: I think we need some linker work to make this play ball
<mup> PR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<mwhudson> i think so too
<zyga> mwhudson: at the very least to fix nss issue
<mwhudson> well also this running /snap/core/bin/ls uses the host elf interp thing
<zyga> mwhudson: hmmm
<mwhudson> no?
<zyga> mwhudson: yes
<zyga> mwhudson: that's true
<mwhudson> this is all very confusing
<zyga> mwhudson: unless we never allow that to happen
<zyga> mwhudson: remember that we control all entry points
<mwhudson> zyga: you mean, just don't let classic snaps exec things from the core snap?
<zyga> mwhudson: snap-run -> snap-exec: we can run a patched dynamic linker at that stage
<zyga> mwhudson: exec: we can use a patched glibc that uses an alternate linker if the target is in the core snap
<zyga> mwhudson: I think we should not restrict what classic confinement snaps can run
<zyga> mwhudson: it would limit their usefunless heavily IMHO
<mwhudson> yeah it's a pretty blunt instrument
<jdstrand> zyga: hey, yes
<zyga> mwhudson: do you see any alternative ideas?
<zyga> jdstrand: hey :)
<zyga> jdstrand: I just commented on your PR :)
<mwhudson> zyga: seccomp-bpf? :)
<mwhudson> zyga: anyway, i think the nss issue is easier than the interpreter issue
<zyga> mwhudson: hmmm, curious
<mwhudson> zyga: "just" patch libc (well libdl) in the core snap to respect RUNPATH in the executable, like the docs say
<zyga> mwhudson: how would that work? we'd attach a seccomp profile that patches exec?
<mwhudson> zyga: yeah
<mwhudson> zyga: i have no idea if that's easily possible
<mwhudson> er -easily
<mwhudson> zyga: i worry about statically linked go binaries :)
<zyga> mwhudson: but taht profile carries across exec right? would it not clash if someone wanted to run something that already uses seccomp for other things?
<zyga> mwhudson: oh, interesting
<zyga> mwhudson: don't those use their own name resolver stack?
<mwhudson> zyga: for the elf interpreter stuff i mean
<zyga> jdstrand: if you could give me some feedback on the sc_must_stpcpy branch I would really appreciate it
<zyga> mwhudson: mmmm
<zyga> mwhudson: wait, what's the problem there? there are no libaries to cause issues
<zyga> mwhudson: and and golang's dlopen just needs to be fixed somehow (if broken)
<zyga> I must be missing something
<zyga> jdstrand: is that branch changing our dependency on base seccomp version in any way? (both in kernel and in the userspace)
<mwhudson> zyga: it's possible i am
<mwhudson> zyga: this is all very confusing, and you've spent longer thinking about it than i
<zyga> mwhudson: (offtopic, I find it funny that I just opened IRC by accident and joked about "garden elf" and here we are talking about this issue that's currently also close to my heart as I was working with sergiusens earlier trying to figure out what's going on)
<zyga> mwhudson: (any) statically compiled binary will work OK (or not) but is beyond our control, if it includes a dynamic linker inside we also have no way to influence it
<zyga> mwhudson: I was thinking about extending the auxilliary vector to set a bit that indicates a given process uses classic confinement
<zyga> mwhudson: and that would change how linker behaves
<blackboxsw> hi folks, question out of left field. I'm on trusty, how do I check the status of the snapd process and my snaps. I was accustomed to using systemd w/ "service snapd status" and "service snap.<snap_name> status" on xenial.
<mwhudson> zyga: and what behaviour would it change ?
<zyga> mwhudson: I think we could use it to change default search path
<zyga> mwhudson: my goal would be to leverage that to have pre-compiled software (e.g. debs) work as classic confinement snaps
<blackboxsw> I see snapd package on trusty pulls in systemd as a dependency, I'm just not sure how that shakes out as far as checking ths snap processes via tools like services, initctl  etc. I *could* check ps easily enough, but I wondered what expected behavior is.
<mwhudson> zyga: oh, so you wouldn't need to set DT_RUNPATH in the binaries in a classic snap?
<zyga> blackboxsw: on 14.04 we have a deputy systemd
<mwhudson> zyga: just the elf interpreter ?
<zyga> mwhudson: exactly
<zyga> mwhudson: because we probably cannot just (not sure) easily rewrite a random executable to have it "gain" runpath and a different dynamic linker path
<mwhudson> well not even the elf interpreter, because you jam a custom interperter in via snap-exec
<zyga> mwhudson: the dynamic linker path is also problematic but if we do it upstream it could work elsewhere too
<zyga> mwhudson: yes, that's true
<zyga> blackboxsw: and you should be able to use regular systemd commands to control services
<mwhudson> and you'd also have a hook in exec that does if exe_path.startswith("/snap/core"): jam_custom_interp_in()
<zyga> blackboxsw: there might be some bits missing; I don't know if journald is wired, for example
<zyga> mwhudson: yes
<mwhudson> zyga: well sounds crazy, and not inherently impossible
<zyga> mwhudson: the idea with the extra bit in auxv is to have clean transitions from snaps to classic world
<zyga> mwhudson: but perhaps we can do that with snap-exec each time and this is not required
<zyga> mwhudson: (all transitions are out of snap world, snap-exec brings us back)
<mwhudson> zyga: not if the classic snap just invokes /snap/core/bin/python3 directly?
<zyga> mwhudson: that's true, I forgot about side-stepping the apps system
<zyga> mwhudson: then we need patched glibc
<zyga> mwhudson: or seccomp-bfp
<zyga> mwhudson: I think that we will either 1) spec this and JFDI or 2) reconsider classic confinement
<zyga> mwhudson: as right now the edges feel pretty sharp :/
<blackboxsw> zyga, thanks for the suggestion. yeah, what I'm seeing from trusty-proposed seems like it's missing a little bit of glue. I'll try digging a bit more, but running "service snapd status"  errors with "unrecognized service" though I see /lib/systemd/system/snapd.service defined
<zyga> blackboxsw: I think you want to talk to tvoss, he was working on this feature
<mwhudson> zyga: yeah, in some ways the "mixed world" of classic snaps is trickier than isolated snaps
<zyga> mwhudson: if we do the magic right it will seem easier
<zyga> mwhudson: but I totally agree with what it is today
<blackboxsw> good reference zyga thanks will continue the conversation with him.
<tvoss> blackboxsw: o/
<blackboxsw> tvoss, isn't it 22:35?
<sergiusens> mwhudson: zyga well I fixed all env var leaking for classic snaps (even PATH), use a little shebang trick to chose the right interp and added a way to provide your own python in stage for the plugin to use
<tvoss> blackboxsw: so for snapd itself and services from snaps, systemctl should do the right thing
<tvoss> blackboxsw: yup, it's 22:35
<blackboxsw> yowsa.
<tvoss> blackboxsw: so systemd is not running as pid 1 on trusty, upstart is still the init system
<tvoss> blackboxsw: so using sudo service will end up querying upstart, instead of systemd
<blackboxsw> tvoss, ahh got it! thanks, looks like I needed "sudo" on trusty too
<blackboxsw> without sudo it gives things like "No such interface" etc.
<tvoss> hmmm, I can give that a spin tomorrow my morning, on my tablet right now
<tvoss> I'll take a note, thanks for testing it out
<blackboxsw> thanks for the response. tvoss. solved my initial hurdle
<tvoss> blackboxsw: cool, later then :)
<tvoss> o/
<blackboxsw> \o
<sergiusens> mwhudson: if it helps http://paste.ubuntu.com/23895943/
<mup> PR snapd#2750 opened: interfaces/default: don't allow TIOCSTI ioctl <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2750>
<mup> PR snapcraft#1091 closed: tests:  add ubuntu user to sudoers on every adt platform  <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1091>
#snappy 2017-01-31
<seshu> cwayne: How can I import self signed certificates into Ubuntu Core 16 system?
<cwayne> seshu: what exactly is it you're trying to do?
<seshu> cwayne: Our EDM server allows user to upload self signed certificates to talk over https. So the user will have to import/export the same certificates to their devices so they can talk over https.
<cwayne> seshu: hmm, I'm not 100% sure how we could do that, would be worth a mail to the list so some more security-minded people could take a look
<stokachu> how far away is series (or branch?) support for multiple versions of a snap?
<popey> ogra_: my laptop just died (battery) and when it came back, packageproxy didn't load, I suspect because /var/snap/packageproxy/1/lockfile.lock still exists. Perhaps needs a sanity check when it launches?
<zyga> good morning
<mup> PR snapd#2751 opened: 14.04/integrationtests: rely on upstart to restart ssh <Created by vosst> <https://github.com/snapcore/snapd/pull/2751>
<Son_Goku> gah
<Son_Goku> I hate being awake this early
<zyga> Son_Goku: hey
<zyga> Son_Goku: good morning :)
<Son_Goku> hi
 * zyga goes to dig into the kernel 
 * Son_Goku grumbles about zsync and garbage fire build systems
<Son_Goku> I hate autotools
<zyga> Son_Goku: I share the sentiment
<Son_Goku> I'm porting zsync to use meson as an exercise to learn meson and also because DNF upstream wants to libify zsync to use with librepo for doing zsync downloads of metadata
<Son_Goku> might as well kill two birds with one stone
<Son_Goku> but holy crap the source autotools build system is annoying to figure out
<ogra_> popey, well, there is a check (that is why it doesnt start) ... the prob is that i'd need access to the process-control interface to actually check if the pid still exists to kill the potentially hanging former process ... when i created that snap there was no such interface ... :)
<popey> ogra_: :)
<ogra_> i'll try to come up with something though, that behaviour is indeed not acceptable :)
<popey> jdstrand: http://askubuntu.com/questions/873495/how-do-i-use-snappy-debug-to-debug-a-snap/878204#878204 - perhaps snappy-debug description should be updated to remove mention of tools it doesn't contain? :)
<popey> ogra_: thanks
<cos-> hm, my .desktop file appeared in the menu today (=after reboot). perhaps some command must be run after snap installation to update the menu.
<om26er> Where can I find documentation regarding paid snaps ? I didn't see a reference to that on snapcraft.io
<om26er> popey: ^ do you know ?
<popey> om26er: not landed yet
<om26er> popey: hmm, what does `snap buy`  do ?
<popey> om26er: nothing yet, as it hasn't all landed yet
<jamespage> anyone know whether the launchpad builders can build classic snaps yet?
<mup> PR snapd#2732 closed: snapenv: do not append ":" to the SNAP_LIBRARY_PATH <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2732>
<mup> PR snapd#2596 closed: tests: parameterize kernel snap channel <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2596>
<mup> PR snapd#2731 closed: store: always log retry summary when SNAPD_DEBUG is set <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2731>
<bulld> guys how to play youtube in snap packaged app??
<bulld> anyone on ??
<bulld> hi popey
<zyga> bulld: can you be more specific please?
<bulld> zyga, flash support in snap packages
<bulld> how my qt app with qwebviw cant play youtube videos
<flexiondotorg> zyga You were on one of the Hangouts recently and we talked about running snapd on a kernel without AppArmor.
<flexiondotorg> My memory was that you said something to the effect that it would "work" albeit without confinement.
<flexiondotorg> Is my memory wrong?
<ogra_> flexiondotorg, that is how it works on fedora for example
<flexiondotorg> OK, so I've made a "Ubuntu" image with a 3rd party kernel.
<flexiondotorg> Which has no AppArmor patches at all.
<ogra_> bad idea :P
<flexiondotorg> I know it's a bad idea.
<flexiondotorg> :-)
<zyga> hi
<zyga> (re)
<flexiondotorg> This was the outcome
<flexiondotorg> http://paste.ubuntu.com/23899188/
<zyga> flexiondotorg: no, that's accurate
<zyga> flexiondotorg: but it needs some hand-holding to enable
<zyga> flexiondotorg: specifically there's no runtime detection yet, you'd have to do two things:
<flexiondotorg> OK, can you point me at something.
<zyga> flexiondotorg: (both can be done permanently later)
<zyga> flexiondotorg: snap-confine needs to be rebuilt without apparmor, simply pass the --disable-apparmor switch and that should do it
<zyga> flexiondotorg: then snapd may need to be patched slightly depending on the state of your apparmor userspace
<jdstrand> popey: done (it wasn't in the 15.04 snap. the series 16 and yaml was fine)
<zyga> flexiondotorg: if changing snap-confine is not sufficient you need to edit (in snapd tree) release/release.go
<zyga> flexiondotorg: and in there look at the function ForceDevMode
<zyga> flexiondotorg: and have it return true for "ubuntu"
<flexiondotorg> zyga OK, thanks for the info.
<zyga> flexiondotorg: it would be good to give your system a different /etc/os-release
<zyga> flexiondotorg: so that it doesn't register as ubuntu, that will kick in devmode automatically
<flexiondotorg> zyga So this is "ubuntu" userspace right now.
<zyga> flexiondotorg: (you still need to rebuild snap-confine but there are patches there (see debian/rules) to do that
<flexiondotorg> But the end game here is the vendors own distribution.
<zyga> flexiondotorg: a proper fix would be to fix snap-confine and snapd to do runtime detection
<ogra_> then tweaking os-release should happen anyway
<flexiondotorg> We spoke to them yesterday, they have agreed to work together to add snapd support to their distro.
<zyga> flexiondotorg: btw, if you change the kernel and it's that wildely different you should not call it ubuntu anymore
<ogra_> that too ...
<zyga> flexiondotorg: would you mind waiting a little (~hour)
<zyga> flexiondotorg: I have a meeting soon and my family calls me for lunch
<flexiondotorg> It is a very popular SBC manufacturer with a distro based on Debian, with a similar sounding name.
<zyga> flexiondotorg: (still not ubuntu)
<flexiondotorg> I  know :-)
<popey> jamespage: jdstrand nice one
<flexiondotorg> zyga I'll be here later. Enjoy lunch.
<ogra_> flexiondotorg, in the snappy core team we dont have lunch ... we have meetings instead :P
<flexiondotorg> Ah yes, meetings. The practical alternative to work ;-)
<ogra_> and to lunch :)
<jdstrand> flexiondotorg: I don't think you could call a system Ubuntu if it doesn't have the Ubuntu kernel (ie, apparmor, etc)
<ogra_> but zyga lives in spain anyway ... lunch time isnt before 4pm there :)
<ogra_> jdstrand, tell that to OpenVZ :)
<ogra_> (they offer ubuntu on 2.6 kernels :) )
<flexiondotorg> jdstrand It is not Ubuntu.
<ogra_> we recently had some support fun here with that
<jdstrand> ogra_: that can't possibly meet the trademark standards
<flexiondotorg> It was the quickest way for me test test their kernel with our userspace and snapd.
<ogra_> FSVO "fun"
<jdstrand> but, I'll let others decide on that
<ogra_> jdstrand, https://openvz.org/Download/template/precreated
<jdstrand> ogra_: I don't doubt they have things called 'ubuntu', I doubt that they should be able to do that. IANAL
<ogra_> yeah
<ogra_> i fully agree, especially after wasting 2h to support someone trying to run snappy on such an image
<jdstrand> but to me, a system isn't Ubuntu unless it has apparmor and our kernel configs. that is especially true for snappy. again, IANAL
<jdstrand> yeah
<ogra_> i couldnt really belive the uname output when i first saw it
<jdstrand> I wrote 'check-requirements' for ufw all those years ago because of people saying ufw didn't work on some hosted machine. "yep, it doesn't, you don't have connection tracking in your kernel"
 * jdstrand shakes head
<zyga> jdstrand: hey :)
<zyga> jdstrand: looking at the kernel and the apparmor bug, trying to reproduce it with a smaller test case, interestingly it doesn't fail there
<zyga> jdstrand: I'm trying to grow the test case to the point where the same behavior we have in snap-confine happens and the failure re-surfaces
<jdstrand> that is annoying
<zyga> jdstrand: I wasted some time because /home is nosuid for me but now progressing
<mup> PR snapcraft#1094 opened: core: switch to using rpath for clasic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1094>
<bulld> zyga, how application get access to flash player when snapped ??
<bulld> my qt app cant play videos from youtube
<bulld> project is based on qt 5.5.1
<ogra_> did you include flash in your snap ?
<ogra_> i guess you'd need the player inside
<bulld> ogra_, it wont work
<bulld> ogra_, flash player installer as stage package wont install flash layer
<bulld> ogra_, flash player installer as stage package wont install flash player
<ogra_> no, indeed
<ogra_> and i didnt say flashplayer-installer :)
<bulld> ogra_, how to install f.p then ?
<stokachu> does snapcraft require the CLA for people to contribute?
<ogra_> teh same way you would do it without flashplayer-installer on a desktop ... put the binaries in the right place etc
<bulld> ogra_, also my qt 5 app cursor dont look as  it looks in the normal deb install
<mup> PR snapcraft#1080 closed: python plugin: avoid the use of PYTHON* env vars <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1080>
<mup> PR snapcraft#1090 closed: core: classic with no exported variables <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1090>
<sergiusens> stokachu: yes
<bulld> sergiusens, hi
<stokachu> sergiusens, thanks
<mup> PR snapd#2749 closed: interfaces/default: allow mknod for regular files, pipes and sockets <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<sergiusens> jamespage: they cannot yet
<bulld> ogra_, i placed the libflashplayer.so in the right place and it still dont work
<zyga> bulld: hey
<sergiusens> hi
<zyga> bulld: if you bundle the flash player in your snap it should jsut work
<bulld> sergiusens, my qt 5 app mouse cursor looks odd
<ogra_> bulld, well, you'Ãd have to ship the right cursor theme in your snap (not sure there is an interface planned for that in the future, but for today you'd have to ship it)
 * zyga goes to debug kernel issues, please ping/mention me explicitly if you need my attention
<bulld> ogra_, sergiusens   http://paste.ubuntu.com/23899428/ here is my snapcraft file
<sergiusens> jamespage: for one reason or another, it is good as these need to happen https://github.com/snapcore/snapcraft/pull/1093 https://github.com/snapcore/snapcraft/pull/1094
<mup> PR snapcraft#1093: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093>
<mup> PR snapcraft#1094: core: switch to using rpath for clasic confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1094>
<sergiusens> bulld: I cannot help you with that, no idea about GUIs
<bulld> ogra_, i also tried [desktop-qt5] to build
<bulld> sergiusens, thanks
<ogra_> that should at least give you a themed cursor
 * mvo hugs popey for his emoj snap
<bulld> sergiusens, am having issues with youtube video playback my project is using qt5.5.1 and qwebview
<bulld> ogra_, same happedned with my previous application
<ogra_> note that i have no clue how to make flash work, but i'd start with placing libflashplayer.so inside the snap in a place where the app can find it and then stracing the whole thing to see what it tries to do and how it actually fails
<bulld> ogra_, did you checked my craft file ??
<ogra_> i'm also not sure if qtwebkit would even have support for flash at all
<ogra_> yes, i see it
<bulld> ogra_, it works fine when i play video in normal deb install
<ogra_> why are you building qt from source ?
<bulld> am not building qt from source
<bulld> thats the name of part , my app source code is in /src folder
<ogra_> oh, right, thats just your app
<bulld> yeah
<bulld> ogra_, am bulldog you remember me ??
<ogra_> yes
<bulld> ty
<bulld> hehe
<ogra_> well, for the cursor thing i'd include the qt desktop bit ... and for flash i'd debug it like i said above
<ogra_> but as i said, i'd be surprised if qtwebkit could even woirk with it
<bulld> ogra_, konqueror webbrowser works with flash
<ogra_> libflashplayer is built for being used with a plugin framework and i doubt qtwebkit provides that
<bulld> and qwebview works with flash am sure about it
<ogra_> well, then you know more than me ... just make it work :P
<bulld> QWebSettings::globalSettings()->setAttribute(QWebSettings::PluginsEnabled, true);
<bulld> this line enable webview to use external plugins
<bulld> ogra_, i will open this url in my snapped application from webview to verify whats wrong https://helpx.adobe.com/flash-player.html
<bulld> it is saying Sorry, Flash Player is either not installed or not enabled.
<mup> PR snapd#2748 closed: seccomp-support.c: add PF_* domains which can be used instead of AF_* <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2748>
<zyga> jdstrand: I ased in one of the reviews but I was wondering if there's any specific thing you'd like to do with seccomp
<zyga> jdstrand: (any changes to default policy or some kind of new interface)
<jdstrand> zyga: that is very open ended. I saw the question about quotactl and answered it. did you have another question?
<mup> PR snapd#2752 opened: snap: add support user-sessions from snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2752>
<jdstrand> zyga: all of the PRs (except the PF_* one, which was just an omission in the original implementation) are to meaningfully improve policy
<jdstrand> well and the cleanups one
<jdstrand> ok, so the quotctl, mknod and ioctl ones are all to fix real world issues
<jdstrand> once I fix mknod I' going to work on chown/setuid/friends to 'daemon'
<jdstrand> zyga: I don't know if any of that answers your question, but there you go
<bulld> ogra_, how i can trace what my app looking for ??
<zyga> jdstrand: thanks, yes, that answers it
<zyga> jdstrand: I was just curious about where this is going
<ogra_> bulld, put strace into your snap and run the app under strace
<bulld> guys any working example snap with flashplayer and html5 video playback ??
<bulld> ogra_, i have no idea how to do that :(
<ogra_> "and html5" ?
<ogra_> it is either/or
<jdstrand> zyga: mostly everywhere where there is a TODO in the policy to fix it with seccomp arg filtering, fix it. then fix bugs, then fix other things I noticed. fix, fix, fix :)
<ogra_> there is no and ...
<bulld> ogra_, html5 video playback
 * ogra_ wouldnt use flash at all for youtube ... 
<zyga> jdstrand: I was thinking about changing how some of the tests look like, it'd be good to add a few lines of documentation to each one
<bulld> ogra_, yes
<ogra_> i'D just use the ubuntu webbrowser-app isnide my snap
<ogra_> that works fine with youtube
<zyga> jdstrand: I grok them after a while but I have to double check each time if my feeling is right
<bulld> ogra_, qwebkit support html5 video playback idk if youtube is trying with html5 why cant my app play videos
<ogra_> no idea, really... it is your app
<bulld> ogra_, it work with debian install man
<ogra_> and we never used qtwebkit in ubuntu anywhere so i have no clue about it
<bulld> :D
<bulld> damn
<jdstrand> zyga: can you give an example of a test that was hard to understand?
<zyga> jdstrand: I specifically mean each of the seccomp test
<bulld> ogra_, you telling me to include ubuntu webbrowser app in my snap ??
<ogra_> on the phone we use oxide inside a webapp-container or the webbrowser-app ... if we want tio use Qt based stuff
<jdstrand> zyga: yes, I figured, but like, what is hard to understand about it? (I'd like to clarify meaningfully rather than guessing)
<zyga> jdstrand: hard is perhaps an overstatement but making it obvious like "check that $SYSCALL is denied when it is not in the filter" or something like this would help, I think
<ogra_> https://github.com/fcole90/fcole-hexgl-webapp is an example i think
<bulld> omg :9
<bulld> :(
<jdstrand> zyga: as a comment or test output?
<zyga> jdstrand: the name encodes the meaning but it's also limietd by length/readability
<zyga> jdstrand: as a comment really
<ogra_> (i actually thougth qtwebkit was dead since years)
<bulld> ogra let me check
<bulld> ogra_,  no
<bulld> :D
<jdstrand> ok, I'll add a todo for that. I'll do that after I finish my policy updates
<zyga> jdstrand: I was wondering if we could stick most of those tests into spread with preapre/execute and details section (details would be that comment)
<ogra_> anyway, thats all i know about web apps
<bulld> hehe
<bulld> you are so nice :)
<bulld> lol
<zyga> jdstrand: thanks, this is not urgent in any way :)
<jdstrand> zyga: I think we need to always have these build tests to make sure the C code is right. adding spread tests on top is fine of course. I am also working on a snap to test various parts of policy that I figured a spread test could drive
<jdstrand> in fact, it was that exercise where I found bug #1658219
<mup> Bug #1658219: flock not mediated by 'k' <AppArmor:Triaged> <https://launchpad.net/bugs/1658219>
<bulld> ogra_,  my app http://imgur.com/a/o2GPq
<zyga> jdstrand: yes, ideally we could run those via spread (like unit tests)
<zyga> jdstrand: I wish there was a "more declarative" way of defining them
<bulld> ogra_, how is it ??
<zyga> jdstrand: nice
<zyga> jdstrand: btw, it would be helpful if you or anyone you know could answer a question with authority: is it possible to reliably determine that something is a bind mount by looking at /proc/self/mountinfo
<mhall119> sergiusens: is there any way to inject version numbers into a snapcraft.yaml at build time?
<zyga> jdstrand: not urgent but something that will block update-ns when we return there
<jdstrand> zyga: I would have to investigate. perhaps tyhicks or jjohansen would know
<zyga> jdstrand: I can post this to a mailing list (not sure where) so that others can reply
<jdstrand> zyga: stgraber might be someone else otoh
<bulld> mhall119, hi
<bulldog> mhall119,  my new app http://imgur.com/a/o2GPq
<bulldog> mhall119, is not talking with me on telegram either :(
<balloons> any suggestions in trying to debug what's happening with my config hooks? I'm trying to use the dump plugin to put files on the filesystem for a classic snap
<didrocks> balloons: I did just echo to $SNAP stdout from a shell script personally
<didrocks> (and look in /var/log/syslog for denials)
<didrocks> $SNAP_DATA
<mhall119> bulldog: in a call atm
<balloons> hmm, I was thinking a script might be easier to see what's happening. I need to kick a service anyway
<mhall119> bulldog: what was your question?
<mhall119> balloons: if you have a non-daemon app defined in your snap, you can "snap run --shell <command>" to get a shell promot in the snap environment
<balloons> mhall119, interesting
<zyga> balloons: that's true for shell apps as well
<zyga> er
<zyga> daemon apps
<zyga> jdstrand: I don't know if you saw my earlier ping about that but I'd love if you could review https://github.com/snapcore/snapd/pull/2745
<balloons> so what I'm trying to do actually is get bash completion to work, along with installing a sysctl file
<mup> PR snapd#2745: cmd: add sc_must_stpcpy <Created by zyga> <https://github.com/snapcore/snapd/pull/2745>
<zyga> jdstrand: I plan to use that for all "strcat" like code
<jdstrand> yes. I'll look at it after I fix the mknod branch
<zyga> jdstrand: thanks!
<mhall119> zyga: oh? Is that a recent change? When I tried to do that with a daemon in the past it didn't work
<zyga> mhall119: it doesn't care if it's a daemon or not, --shell just causes us to run /bin/bash
<zyga> mhall119: you get the same confinement as whetever would run otherwise
<mup> PR snapd#2753 opened: tests: install ubuntu-core from the same channel as core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2753>
<zyga> mhall119: if you saw otherwise I'd love to know more
<mhall119> zyga: well I can't reproduce that error now, so I guess it was user-error all along :)
<bulldog> mhall119, you there ?
<bulldog> mhall119, my app uses qwebview to play youtube videos , on normal debian install it plays well and when i snap it the youtube player saus videos cant be played n this device
<mardy> pstolowski: hi! got a minute?
<pstolowski> mardy, hello! sure, what's up?
<mardy> pstolowski: I'm trying snapd from master, + your interface hook branch (step 3)
<pstolowski> brave man ;)
<mardy> pstolowski: if I run snapd with SNAP_DEBUG=1, should I see the lines "Run hook %s of snap %q" in the output?
<mardy> pstolowski: or, to make the question more meaningful, how can I check whether my hook is being run?
<pstolowski> mardy, I think (but haven't actually used debug mode) you would see 'Running task ...'. but isn't it SNAPD_DEBUG (not SNAP_DEBUG)?
<pstolowski> yeah, it's SNAPD_DEBUG
<mardy> pstolowski: indeed, sorry, I launched the proper command, just misspelt it here on IRC
<zyga> mardy: look at syslog/journal
<zyga> mardy: how are you running snapd?
<mhall119> bulldog: have you tried adding the browser-support plug?
<mhall119> the qwebview might need that
<mardy> zyga: sudo SNAPD_DEBUG=1 ./snapd
<bulldog> mhall119, yes
<jamespage> sergiusens, ack - thanks for confirming - have a few classic snaps landing into /openstack today - but holding off on the auto-build to edge bit for now then!
<zyga> mardy: (funny that it works like that now, we used to require socket activation)
<mardy> zyga, pstolowski: I see quite a few lines there, including "Run configure hook of "amazon-webapp" snap if present" but nothing about interface hooks
<bulldog> mhall119,  my craft file http://paste.ubuntu.com/23899846/
<mardy> pstolowski: are the hooks run for interfaces which do autoconnect?
<pstolowski> mardy, they will only run when you connect (sorry if that's obvious)
<mhall119> bulldog: I'm not sure then, I imagine it has something to do with the html5 video playback, have you checked dmesg for DENIAL?
<pstolowski> mardy, no, not yet
<mardy> pstolowski: ah, that explains it
<bulldog> mhall119, how to do that ?
<pstolowski> mardy, also, this branch doesn't actually use the attributes you set in hooks. this will come in the next branch
<mardy> pstolowski: you mean the "step 3" branch, or another one?
<bulldog> ok let me check
<pstolowski> mardy, the upcoming 'step 4' should (hopefully) make it possible to apply the attributes to the interface
<mhall119> bulldog: dmesg |grep DENIAL
<mhall119> bulldog: are you running in --devmode or in strict confinement?
<bulldog> mhall119, strict
<mhall119> ok,then if it's confinement causing your errors,it should show up in dmesg
<bulldog> mhall119, i installed with --devmode flag too but it still says this device cant play videos
<pstolowski> mardy, although with step 3 branch it's already possible to exchange data between slot and plug side, as you can see in the attached spread tests
<mhall119> hmm, might be a configuration thing then, not sure
<mhall119> or a missing dependency
<mardy> pstolowski: ok, thanks
<mhall119> bulldog: does it need flash to work?
<mardy> pstolowski: and about running hooks for interface which are autoconnected, is that planned?
<bulldog> mhall119, this is very sad that my some of apps are still not running fine with snap
<pstolowski> mardy, yes, afaict this needs to be supported (I don't see a reason why we wouldn't support this). it'll just come separately as for some reason autoconnect currently bypasses this execution path completely and needs to be treated separately
<ogra_> mhall119, he is using his own custom webapp built around qt-webkit and trying to use adobe-flash ... (instead of just using an oxide webapp container ... i already pointed to the hexgl snap but ...)
<bulldog> what support  browser-support gives :D
<pstolowski> mardy, (separately as in a separate PR)
<bulldog> ogra_, mhall119 , its not a webapp
<ogra_> ita an app to play back youtube videos, no ?
<ogra_> *it's
<bulldog> ogra_, my app is a qt gui qpp , with more then 5k lines of code
<ogra_> ok
<mardy> pstolowski: ok, thanks a lot, I'll keep an eye on your branches :-)
<ogra_> well, you wrote it,. you should know how to debug it too then
<bulldog> yes it does , the question is if my app  can play video in normal install why it cant do that in snap
<pstolowski> mardy, sorry it's taking so long... but we're making progress
<ogra_> first of all strace it to see how/where it looks for libfalshplayer ... if it finds it ... if it execs it etc etc ... the standard stuff you do for debugging
<bulldog> qt is not changing its api for snap right after compilation right ?
<bulldog> ogra_, i think it is not looking for flash player
<ogra_> well, find out why ... and fix that
<bulldog> i renamed the libflashplayer.so in my system and it plays videos
<bulldog> ogra_, yes i will :(
<bulldog>  i renamed the libflashplayer.so in my system and it plays videos that mean app not looking for flash layer
<ogra_> so it likely simply uses html5 and you dont need the flash player at all ...
<bulldog> yes
<ogra_> (like i said in the beginning of our conversation)
<bulldog> hmm
<tyhicks> zyga: no, I don't know of a reliable bind mount check from userspace :/
<zyga> tyhicks: I see, thanks
<zyga> tyhicks: is there any place better than mountinfo to see the mount table?
<bulldog> so i added - libavcodec-ffmpeg56 - ffmpeg in stage-packages but still no luck
<zyga> tyhicks: I'm reading kernel documentation but I'm not that far yet
<ogra_> anyway, look at the hexgl snap that i pointed to, try to add the same interfaces and connect them ... also try to build your app unconfined and see if it works tghen
<tyhicks> zyga: nope, that's the best
<ogra_> if it doesn, thats not a confinement issue
<zyga> tyhicks: thanks
<ogra_> not sure why you would add ffmpeg
<bulldog> ogra_, it even wont play , when i install app with  --devmode
<ogra_> so its an issue with your app ... debug it
<bulldog> libffmpeg.so is what makes play H264 vids
<ogra_> and fix the errors you find
<bulldog> ogra_, i said it is running fine on normal system
<bulldog> i do not write buggy code :D
<zyga> bulldog: I'd suggest doing as ogra_ suggested earlier, use strace to figure out what happens when your app runs outside of a snap (it probably accesses something on your host and uses that to work)
<bulldog> zyga, ok
<zyga> bulldog: then do the same inside a snap
<zyga> bulldog: and compare to get an idea of what is missing
<bulldog> ok :(
<zyga> bulldog: remember that snaps run in a chroot of sorts
<zyga> bulldog: why the sad face?
<zyga> bulldog: so I suspect you just rely on the fact that something on your host is being automatically loaded
<bulldog> i dont knnow strace and chroot and sorts
<bulldog> idk
<zyga> bulldog: and that thing is not present in the core snap (or your own snap) and it doesn't work
<zyga> bulldog: strace works like strace
<zyga> bulldog: just strace ./program
<bulldog> ok
<zyga> bulldog: --help and manual page has useful things,
<tyhicks> zyga: from a real quick scan, MS_BIND is missing in fs_info struct in show_sb_opts() of fs/proc_namespace.c
<zyga> bulldog: my suggestion is to limit it just to open() so that you see a very small set of data
<tyhicks> zyga: I assume that is intentional but don't know why
<mup> PR snapd#2744 closed: overlord: move configstate.Transaction stuff into configstate.config.Transaction <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2744>
<bulldog> zyga, am trying
<zyga> tyhicks: interesting, thanks
<zyga> tyhicks: I'll build a test kernel with a change there, maybe I can get some insight
<bulldog> zyga, i got my terminal filled with stuff
<bulldog> zyga, do i need to play video to find what it is using to play video ?
<zyga> bulldog: strace -o is useful
<zyga> bulldog: yes, use a realistic test case (do what it usually does)
<bulldog> ok
<tyhicks> zyga: one last idea about it... I can't fully remember but MS_BIND may not actually be set in the superblock's flags when you do a bind mount. It may just clone the mount flags from the source superblock.
<zyga> tyhicks: I see, I'll read that code and see what I can find
<tyhicks> zyga: that'll be the case if your test kernel doesn't end up showing "bind" in mountinfo
<bulldog> zyga, i got something interesting man :)
<bulldog> zyga, please check this out http://imgur.com/a/TFoCm
<bulldog> ogra_, grep ffmpeg and flash of strace of my application http://imgur.com/a/TFoCm
<bulldog> mhall119,
<bulldog> :(
<zyga> bulldog: I'm sorry I cannot check it out now
<bulldog> zyga, ok
<bulldog> zyga, you cant check image ??
<bulldog> zyga, i want to know how to create those mimes files i think the player first read the mime files and then choose what codec is needed to play video and then call ffmpeg
<bulldog> i added shared-mime-infot to stage-package now
<zyga> bulldog: no, I'm digging through kernel code, sorry
<zyga> bulldog: mime files don't do anything on ubuntu-core
<zyga> bulldog: and I doubt they are related
<bulldog> zyga, plyer tries to find he mime type am sure of this
<zyga> bulldog: the server sends the mime type
<bulldog> or it may be dynamic at runtime
<zyga> it always is as the server sends it
<bulldog> if it was not why strace showing mime stuffs
<zyga> I'm sorry but I cannot dig into your code right now
<bulldog> server sends several url to playable streams
<bulldog> my code has nothing to do with that
<mhall119> bulldog: are you using desktop-launch from the desktop-qt5 remote part?
<bulldog> i have to pack it in deb :(
<bulldog> yeah
<bulldog> mhall119, yes
<bulldog> mhall119, two things not working , video playback and mouse cursor looks odd
<bulldog> rest of application works fine
<zyga> wow, MS_BIND is really used just twice in the whole kernel
<bulldog> and both issues are when i pack with snap
<bulldog> mhall119, can i run update-mime-database before my app starts ??
<bulldog> oh it is already done by desktop-launcher
<flexiondotorg> zyga I've been asked what the RAM overhead for adding AppArmor to a kernel is. Any idea?
<tyhicks> flexiondotorg: I've got no numbers for that off the top of my head
<flexiondotorg> OK, thanks.
<mup> PR snapcraft#1095 opened: Plainbox providers run validate <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1095>
<ogra_> pstolowski, poke ...
<pstolowski> ogra_, hey
<ogra_> pstolowski, so i'm trying to extend our core snap for an option to turn syslog on/off ...
<ogra_> looking at https://github.com/snapcore/snapd/wiki/hooks
<ogra_> apparently i cant get any info about what option the snap set that hands over the value was called with
<ogra_> there is nothing in the shell env or in the arg list
<ogra_> does that mean that ... if i would package ... say postfix which can easily have 500 config options the confgure script would have to parse each single of them with a snapctl call ?
<mup> PR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<ogra_> (and would also set all these options every time i change one of them)
<ogra_> that doesnt look actually scalable ... is there a way for the configure script to find out what was called in snap set ?
<zyga> flexiondotorg: no
<zyga> flexiondotorg: I think jjohansen is the person to ask but you can measure that yourself
<zyga> flexiondotorg: boot ubuntu on x86
<zyga> flexiondotorg: then disable apparmor
<zyga> bschaefer: (you have to pass somthing on command line, I could check later)
<zyga> er
<zyga> flexiondotorg: ^^
<zyga> bschaefer: sorry, tab-mistake
<zyga> flexiondotorg: then you can compare
<zyga> flexiondotorg: but I don't suspect it is significant
<flexiondotorg> zyga OK, thanks.
<flexiondotorg> From some research papers is indicates maybe 1Mb of RAM.
<flexiondotorg> But I'll need to test.
<tyhicks> flexiondotorg: apparmor=0 is the kernel command option, which zyga is referring to, that disables apparmor
<zyga> thanks :)
<flexiondotorg> Yep :-)
<zyga> flexiondotorg: once you do find out can you please give us a note
<flexiondotorg> Yeah, will post on the ML.
<zyga> flexiondotorg: include the test procedure as well, could be useful to repeat and measure
<zyga> great, thanks
 * ogra_ gives zyga a â«
<flexiondotorg> Won't be for a couple of days though.
<tyhicks> flexiondotorg: just to check that you've properly disabled apparmor after booting, run aa-enabled and make sure that it doesn't print "Yes"
<ogra_> flexiondotorg, he has a note now, no hurry, that will persist for a few days ;)
<flexiondotorg> :-)
<flexiondotorg> tyhicks Thanks for the tip.
<pstolowski> ogra_, hmm, not really
<ogra_> do we plan to extend that in the future ?
<pstolowski> ogra_, i know this is not answer to your question, but I feel like it's worth mentioning - you can structure your options in a map, and then get them all in one go
 * ogra_ imagines shell script hooks with 100s of lines of snapctl get at the top
<pstolowski> ogra_, e.g. snapctl set author='{"name":"pawel", "age":18}'
<ogra_> yeah, that doesnt help much ... especially in the context of the core snap where i probably only want to toggle a few options of the OS
<pstolowski> ogra_, and then "snap(ctl) get -d ... author" will give you a formatted json document will both options
<ogra_> right
<pstolowski> s/will/with/
<ogra_> i think we need a way to make the script knwo what option is being changed
<pstolowski> ogra_, i think the idea was to use that as input to generate the target config
<ogra_> thats fine for initial install
<ogra_> but not if you want to change a single value
<pstolowski> ogra_, I don't know of any plans to do that. this is the first time I hear about this limitation. but I think you're right
<ogra_> in a snap that has tons of options
<pstolowski> ogra_, yes.. sounds like a lots of work for script author to handle anything more complex than a few options
<ogra_> well, i'm already stuggling with more than one :)
<pstolowski> ;)
<ogra_> morphis_ created a configure script for the core snap
<ogra_> i'm trying to add a second option but seemingly cant do that without also parsing his option every time i set mine
<pstolowski> ogra_, yeah, it's worth discussing. i'm about eod, need to pack things for the trip. back on monday but feel free to discuss tomorrow on standup
<morphis_> ogra_: yeah you don't get a info which option is set
<ogra_> i'll drag it to the ML
<morphis_> ogra_: niemeyer talked about something to improve this
<ogra_> morphis_, yeah, imagine you package postfix ... 500-800 possible options ...
<morphis_> ogra_: but currently the only optio is to save state ..
<morphis_> ogra_: I know, configure hook is pretty limited
<ogra_> the configure script would probably end up bigger than the whole postfix source
<morphis_> :-)
<morphis_> ogra_: and my problem is that it is sometimes orthogonal to existing configuration systems as both can change and then don't match anymore
<ogra_> yeah
<morphis_> so you need to go state both ways etc.
<morphis_> pretty complex
<ogra_> yup
<morphis_> raised that already back when the hook was introduced but I guess this is still just the beginning and to be improved in the future
<ogra_> i hope so :)
<ogra_> well, i'll just add my option to it then ...
<pstolowski> it sounds to me like snap config options should only be used for some fundamental settings and not try to replicate all apps settings
<pstolowski> e.g. what port to listen to or some such
<morphis_> ogra_: wait, snapd does not update gadget snaps?
<ogra_> morphis_, nope
<morphis_> wooot?
<ogra_> yeah
<morphis_> awe_: ^^
<ogra_> i was the same :)
<morphis_> ogra_: why is that the case?
<ogra_> safety net i think
<ogra_> ask mvo
<morphis_> so if a vendor updates its gadget snap in the store it doesn't get pulled and installed?
<ogra_> we actually have a bug (though regarding the config.txt on the pi, but it applies to all gadget content afaik)
<morphis_> ogra_: so lets say I add another plug to the gadget snap for a serial-port it doesn't get available on the device ever?
<zyga> morphis_: plugs are processed (that's snap.yaml)
<ogra_> i dont know if any parts get updated ... if there are any they are selectz bits
<zyga> morphis_: but we don't process any of the gadget artefacts
<bulldog> good night guys , i was not able to play videos in qwebview :(
<zyga> morphis_: we don't bundle the equivalent of what ubuntu-image does
<ogra_> yeah, you wont get a new grub config or a fix in the grub binary today
<morphis_> zyga: right, so just gadget.yaml is ignored, correct?
<zyga> morphis_: yes
<morphis_> zyga: but lets say I change my configure hook in the gadget snap its still being updated and executed?
<ogra_> thats in the snap.yaml, right ?
<zyga> morphis_: yes
<zyga> morphis_: it's just like any other snap
<morphis_> good
<zyga> morphis_: we just don't have code that goes over what is done by the gadget at build time
<ogra_> we need that though :)
<mvo> morphis_: there is a bit of a misunderstanding here it seem. we update the gadget snaps, we just don't update the bootloader bits and apply them to /boot/{uboot,grub}
<morphis_> ogra_: then your comment on the bug does not apply
<ogra_> morphis_, yeah, sorry
<ogra_> seems i misunderstood
<morphis_> mvo: yeah I just figured that ..
<mvo> aha, thanks zyga, you already said this
<morphis_> ogra_: can you correct that on the bug?
<ogra_> done
<zyga> mvo: thinking about it
<zyga> mvo: perhaps it would be better in general
<zyga> mvo: to have a special hook that gadgets could have
<zyga> mvo: that lets them upgrade themselves
<zyga> mvo: this feels more flexible than teaching snapd to understand all the random devices out there
<zyga> mvo: and we could then leverage ubuntu-image codebase to construct gadget update hooks
<ogra_> that sounds like a plan
<zyga> mvo: (where the hook would run a new tool built from the same codebase)
<zyga> mvo: and since the hook can inspect the system (kernel, what not) it could be smarter about hard cases
<zyga> mvo: it could even be the configure hook though I somewhat share ogra_'s opinion about scalability
<zyga> (as in what the hook is supposed to do when invoked)
<zyga> mvo: and over time this could do other funky stuff like push a new gadget to update firmware on some oddball attached device
<zyga> (e.g. reflash arduino with new program)
<ogra_> well, i'd already be happy to be able to update bugfixes in the bootloader binary
<ogra_> we do that all the time on classic
<ogra_> so there is no reason to not do it on core
<mvo> zyga: interessting idea, I think this aligns with the discussions we had at the sprint
<seb128> sergiusens, what email client are you using? those colored lines in your replies are weird :-)
<sergiusens> seb128: I am using dekko :-P
<sergiusens> seb128: I've been notified
<seb128> k, it's just weird looking :-)
<DanChapman> sergiusens: I presume that's the wonky reply quoting your talking about? where you get loads of >>>>> in place of text. A fix for that will be landing shortly.
<sergiusens> DanChapman: \o/
<Pharaoh_Atem> Yo all
<mup> PR snapd#2753 closed: tests: install ubuntu-core from the same channel as core <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2753>
<Pharaoh_Atem> sergiusens: have you had a chance to take a look at breaking up the (stage|build)-packages backend up like we discussed at the October sprint?
<Pharaoh_Atem> in snapcraft
<jdstrand> zyga: I think it would probably be a good idea to do 'sysctl -w kernel.printk_ratelimit=0' for all spread tests. where would be the best place to put that in your opinion (otoh only). "I'm not sure" is an ok answer
<zyga> jdstrand: ... in tests/lib/prepare.sh
<zyga> tyhicks: you were right about MS_BIND, I patched the kernel a little bit (though this is a dead-end IMHO) to learn how things work
<zyga> tyhicks: I've added MNT_BIND that gets set on bind mounts and printed in mountinfo
<zyga> tyhicks: I kicked off another build
<zyga> tyhicks: I start to think that I could use the tree structure to figure things out, I'll write a small helper for that tomorrow (to graph the mount structure)
<zyga> tyhicks: if you know of one already then please drop me a line, otherwise I'll write one tomorrow (probably based on the existing mountinfo parser and dot/graphviz)
<jdstrand> zyga: findmnt -a?
<jdstrand> of maybe some other incantation
 * zyga trie
<zyga> tries
<zyga> oh, groovy
<jdstrand> zyga: thanks for prepare.sh
<zyga> jdstrand: findmnt seems to do _something_ to figoure out bind mounts :)
<zyga> jdstrand: that's very promising
<jdstrand> cool
<zyga> jdstrand: my patch actually worked
<zyga> 257 24 8:1 /hacking/source /hacking/target rw,relatime,bind shared:1 - ext4 /dev/sda1 rw,errors=remount-ro,data=ordered
<zyga> not very pretty but ... it shows bind mounts ;)
<jdstrand> neat :)
<zyga> jdstrand: http://paste.ubuntu.com/23901026/
<jdstrand> huh
<zyga> jdstrand: what?
<jdstrand> just surprised that wasn't done already
<zyga> jdstrand: I had a look at findmnt
<zyga> jdstrand: and it treats anything that has mnt_root != "/"
<zyga> jdstrand: it doesn't technically list bind mounts
<zyga> jdstrand: it just has special syntax for btrfs and bind mounts
<zyga> jdstrand: in any case this may be sufficient
<zyga> jdstrand: do you think I should try to submit my MNT_BIND patch anywhere?
<jdstrand> zyga: you might want to ask the kernel team about that
<ogra_> jdstrand, you totally missed the classic snap that installs the classic dimension in which you can then develop classic snaps with classic confinement !
<ogra_> (in your list in the mail)
<jdstrand> ogra_: heh, I did actually think about it, but I was trying to focus on the two things that he may have been conflating
<ogra_> yeah, i wasnt serious :)
<jdstrand> :)
<jdstrand> it is pretty overloaded :)
<zyga> ogra_: that's a classic joke now
 * zyga hides
<ogra_> LOL
<jdstrand> oh, boo :P
<balloons> jdstrand, do all classic snaps have to have an initial manual review?
<jdstrand> balloons: yes
<stokachu> jdstrand, can i pm you about something?
<jjohansen> flexiondotorg, zyga, jdstrand: the amount of ram overhead is highly dependent on policy, and cpu count. apparmor preallocates some per cpu work buffers. so a no policy base cost is you are looking at 2-4 pages/cpu + a few other small allocations. Policy is a lot harder to pin down, as it can vary drastically by what rules are used, how many profiles are loaded etc. Each profile will vary from just a few kb up to say a few 100 kb. 
<jjohansen> It also depends on what compiler options are used. The policy is compiled and usually minimized and then compressed. There are flags to tune at each stage (they usually don't make huge differences, unless you disable a given stage entirely) but I have seen differences as large as 40%. We try to set the compiler to a good default, that balances cpu time for policy size.
<jjohansen> And yes, kernel side the policy stays compressed, its a compression that allows us to directly us the data, (more of a packing but it can do state differences etc)
<zyga> jjohansen: hey
<jjohansen> hey zyga
<zyga> jjohansen: I was working on a smaller test case for the bug you may remember, so far no luck (it works)
<zyga> jjohansen: the original test is still broken
<zyga> jjohansen: I'll continue this work tomorrow
<jjohansen> zyga: ack, poke me to look at it again, I have been side tracked by other work
<zyga> jjohansen: I asked a question in #ubuntu-kernel about a small patch, not sure if you want to review it (not sure if it makes sense to track MS_BIND flags)
<zyga> jjohansen: I'll poke you tomorrow (hopefully with a simple C program that shows this issue)
<jjohansen> zyga: I'll have a look
<jdstrand> stokachu: of course
<jdstrand> nessita: fyi, https://myapps.developer.ubuntu.com/dev/click-apps/5570/rev/652/ is stuck with "Automated review not yet completed.". These are coming from balloons' LP build and ther are now 80 revisions queued cause r652 is stuck. I granted classic confinement, hopefully if r652 gets unwedged, everything will just flow
<jdstrand> nessita: Submission date for r652 is 2017-01-28 06:15 - 3 days, 14 hours ago
<nessita> jdstrand, hum, checking
<stokachu> nessita, hi! sent you and michael an email
<nessita> stokachu, hi! is that a snap that we really want canonical to "sponsor"?
<stokachu> nessita, yes
<nessita> as in, is a canonical product?
<HumbleBeaver> Hello gents, I'm chasing down a Seccomp issue my program seems to be triggering
<stokachu> nessita, ah yes it is a canonical product
<nessita> stokachu, ack, thanks; as soon as mvo replies with some ack I will do the transfer (likely tomorrow, is late for him and I'm close to EOD). Is that ok?
<stokachu> nessita, yea that's great ty! also ill still have upload rights to it?
<jdstrand> HumbleBeaver: do you have a denial in syslog? eg, grep -F type=1326 /var/log/syslog
<nessita> stokachu, yes, the transfer automatically give you collaborator rights
<stokachu> nessita, perfect ty!
<HumbleBeaver> @jdstrand:yes
<nothal> HumbleBeaver: No such command!
<jdstrand> HumbleBeaver: can you paste the output to paste.ubuntu.com? (you might also be interested in 'sudo snap install snappy-debug ; sudo snappy-debug.security scanlog')
<kyrofa> ogra_, what is the state of SPI on ubuntu core?
<HumbleBeaver> jdstrand its been pasted, and I've got the debugger installed.
<jdstrand> HumbleBeaver: can you give me the link with the paste?
<HumbleBeaver> jdstrand yes one moment
<HumbleBeaver> jdstrand http://paste.ubuntu.com/23901389/
<jdstrand> HumbleBeaver: cat you paste the contents of /var/lib/snapd/seccomp/profiles/snap.codebreakers.<your command>?
<jdstrand> s/cat/can
<HumbleBeaver> jdstrand http://paste.ubuntu.com/23901416/
<sergiusens> Pharaoh_Atem: I am going to take a spike at it this week or weekend; was thinking about it this past weekend but I got sick (two weekends in a row)
<jdstrand> HumbleBeaver: ok, you have two choices. adjust your code to use 'sched_setscheduler(0, ..., ...)' or add 'plugs: [ process-control ]' to your snapcraft.yaml
<jdstrand> HumbleBeaver: is this an open source project? if so, is the code hosted somewhere?
<Pharaoh_Atem> sergiusens: I know that feeling well
<Pharaoh_Atem> I was sick the entire month of December
<Pharaoh_Atem> it sucked a lot
<HumbleBeaver> jdstrand Yes its on github, https://github.com/bflanagin/CodeBreakers
<jdstrand> HumbleBeaver: we allow sched_setscheduler to be used with '0' as the first argument because that limits changing the scheduler to a process for this snap. other values for the first argument allow changing the scheduler for other pids that aren't from your snap
<HumbleBeaver> jdstrand do you know how I might have caused the issue. It only occured when I tried to use the LocalStorage
<jdstrand> HumbleBeaver: the process-control interface allows you to use sched_setscheduler with any arguments. looking at your code, it seems that it is something in the qt libraries that might be doing this. are you explicitly setting the scheduler in some way?
<jdstrand> maybe it is sqlite
<HumbleBeaver> It must be, I have timers for some things, for animations but thats it
<HumbleBeaver> jdstrand I've got it repackaged, let me see what happens now
<jdstrand> HumbleBeaver: this is a thread scheduler unrelated to timers
<HumbleBeaver> jdstrand I figured as much, its really a simple game.
<jdstrand> I see sqlite3 uses sched_setparam but not sched_setscheduler
<nessita> jdstrand, I gotta run now, Daniel (roadmr) is helping me debugging but I may unblock the revision tomorrow, sorry
<jdstrand> nessita: thanks, sorry for pinging you at your eod. balloons, fyi ^
<nessita> jdstrand, long story short I can file an RT to get that unblock, but would like to fidn what caused the blockeage first to be able to fix
<jdstrand> makes sense
<nessita> jdstrand, will keep you posted
<HumbleBeaver> jdstrand I've added process-control to plugs, as well as network-control (this was suggested by the debugger)
<HumbleBeaver> both seem odd for a QML app that only uses javascript to make it do what it does
<jdstrand> HumbleBeaver: you shouldn't need network-control. what was the denial?
<balloons> ty all
<HumbleBeaver> jdstrand I thought it was odd too, one moment
<kgunn> ogra_: fwiw, the link to db image seems broken from this page
<kgunn> https://developer.ubuntu.com/core/get-started/dragonboard-410c
<HumbleBeaver> jdstrand I removed network-control but left network (I'm going to need it later anyway). It was the debugger that suggested I add network-control, but I don't know what it was complaining about.
<jdstrand> HumbleBeaver: the debug command will make several suggestions. it's possible there was a cascasding failure since you didn't have process-control
<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>
<jdstrand> HumbleBeaver: I've taken a todo to look into why qml apps need sched_setscheduler
<HumbleBeaver> jdstrand That makes sense, with process control my app still fails to start, but there are no more debug errors when in devmode
<HumbleBeaver> thanks for looking into this I'll see if I can set the scheduler like you suggested
<mup> PR snapcraft#1088 closed: Release changelog for 2.26 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1088>
<jdstrand> HumbleBeaver: I don't think there is anything for you to do. I think it is in the guts of QThread: http://sources.debian.net/src/qtbase-opensource-src/5.7.1%2Bdfsg-3/src/corelib/thread/qthread_unix.cpp/?hl=721#L721
 * jdstrand hugs sergiusens for releasing 2.26 ('desktop' in snap.yaml has been annoying :)
 * sergiusens hugs back
<sergiusens> jdstrand: would of pushed on Friday, but we had unexpected adt failures which were sorted
<jdstrand> sergiusens: no worries, it hasn't been too bad
<HumbleBeaver> jdstrand I hate it when that is the case, and I forgot to connect process-control to codebreakers. It now works in Scrict mode
<HumbleBeaver> Forgive my ignorance, but will other users have to do that as well to use the application on their system?
<jdstrand> HumbleBeaver: yes. like I said, I need to look into what is happening and see what to do to fix it
<HumbleBeaver> jdstrand thanks for your help, I'll rewrite the code to use an online leader board while you get things sorted.
<ogra_> kgunn, bah, looks like slangasek's re-arranging for automatic builds broke all links ... there was a new "/current" layer added
<slangasek> ogra_: what links?
<ogra_> i'm not actually sure we need current and pending there
<ogra_> slangasek, https://developer.ubuntu.com/core/get-started/dragonboard-410c
<slangasek> mmk
<slangasek> the extra layer is there by discussion with QA (jibel)
<slangasek> we have the same promotion process for images for the stable channel as elsewhere: we produce the image, it's put through QA, then it's published as current after it's been confirmed to work
<ogra_> except that they (used to) test candidate
<slangasek> we can retrofit some compat symlinks, but can we also please update the pages?
<ogra_> yes
<slangasek> the candidate image is a separate image build
<slangasek> because the channel has to be changed within the image
<slangasek> and we want QA of the actual output of the image build
<ogra_> of snaps that get promoted through the store levels
<ogra_> the only thing you woulld test there is ubuntu-image :)
<slangasek> maybe you have confidence that ubuntu-image will always produce correct output
<slangasek> I am more conservative about my own code ;)
<ogra_> heh, k
<slangasek> (also, jibel wanted it ;)
<ogra_> the thing is that we are duplicating the processes ... snaps should layer through the store
<ogra_> https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<slangasek> ogra_: so, I'm willing to do this any way that the team thinks is correct, but when I asked jibel how he wanted these done this is what he asked for
<ogra_> the snap is identical in candidate and stable ... that should be true for kernel, core and the gadgets
<slangasek> anyway, compat symlinks are now in place
<ogra_> thanks
<slangasek> will you take care of updating the documentation?
<ogra_> i'll file the PRs yeah
<ogra_> thanks
<ogra_> kgunn, ^^ all back
<kgunn> ;)
<ogra_> kyrofa, hmm, should all work on a low level, though i'm not sure if we might need extra interface love ...
<kyrofa> ogra_, just saw this pop up: https://askubuntu.com/questions/878445/error-illegal-arguments-for-construction-of-exports-spi
<kyrofa> ogra_, which is from classic mode, which should be devmode
<ogra_> bah
<ogra_> sigh
<ogra_> ogra@localhost:~$ grep spi /boot/uboot/config.txt
<ogra_> #spi=on
<ogra_> ogra@localhost:~$
<ogra_> i'll fix that tomorrow ... can you tell him to remove the comment for now
<kyrofa> ogra_, that's writable? Will do
<ogra_> yeah, it is ... but isnt upgraded when we update the gadget
<ogra_> so he would have to re-install an edge image ... just uncommenting is the least painless
<stokachu> do we know if the launchpad snap builds support the /snap directory now?
<kyrofa> ogra_, perfect, thank you for investigating. Shall I log a bug?
<ogra_> kyrofa, nah, i'll do it with the next gadget update
<kyrofa> stokachu, I don't think so-- that's snapcraft 2.26 which isn't quite out yet
<kyrofa> stokachu, but once it's in -updates LP will support it
<stokachu> kyrofa, ok thanks, ill continue building manually until then
<ogra_> the fact that installed gadgets do not get updated is known and has bugs
<kyrofa> ogra_, alright, sounds good
<sergiusens> wgrant: do you remember the snap directory conversations? ^
<wgrant> sergiusens: ie. having buildds mount the core snap for classic builds?
<sergiusens> wgrant: no, snapcraft.yaml inside snap/snapcraft.yaml
<wgrant> Oh that.
<wgrant> sergiusens: I don't think LP needs specific support for that, does it?
<sergiusens> wgrant: not out yet, but lp detection of that as a valid thing might be a thing; both you guys are subscribed to the bug, not sure if I need to do more next time
<wgrant> It doesn't use snapcraft.yaml except via snapcraft itself.
<wgrant> So it should Just Work.
<sergiusens> wgrant: I think, I don't know; does the +Create a snap button show regardless?
<wgrant> Oh right.
<wgrant> buildd doesn't, but the app does, to autoparse the name.
<wgrant> cjwatson is working on some stuff in that area atm, so might be able to sort it out.
<wgrant> sergiusens: IIRC /snapcraft.yaml, /.snapcraft.yaml and /snap/snapcraft.yaml are all valid now?
<wgrant> Anything else?
<kyrofa> wgrant, you got it
<sergiusens> wgrant: correct
<wgrant> Great.
<sergiusens> ok, I am EODing now!
<sergiusens> cheers
<wgrant> Note that all this breaks is the name autodetection when creating a new snap.
<wgrant> Builds will work fine, and when creating a new snap that uses a new location you'll just need to enter the name manually.
<sergiusens> wgrant: good to know, I won't block on releasing then
<mhall119> bzoltan: zbenjamin: have you guys had any issue with QML/SDK apps running as fully confined snaps? HumbleBeaver is experiencing a problem related to SQLite
<odysseywestra> Hi I was wondering if someone could help me package MyPaint. I read through the tutorial, but I would like someone to help me walk through the process so I can get it.
<HumbleBeaver> odysseywestra Howdy, I'm still learning too, but I've got one or two snaps under my belt.
<HumbleBeaver> I'll try my best to get you running, where are you at in the process
<HumbleBeaver> and then my dogs demand I take them on a walk.
<odysseywestra> Yeah, and one of my family member came over unexpectedly.
<HumbleBeaver> odysseywestra lol, well I'll hit you up after the walk, if someone isn't helping you I'll see what I can do for you
<odysseywestra> Okay thank you.
<zyga> jdstrand: replied on must_stpcpy, I think I misunderstood you initially, strncat is mostly useless for preventing bufer overflows IMO
<zyga> jdstrand: if you want we can discuss this here quickly or back in the pull request slowly
<PugnaciousOne> Anyone awake in this channel?  I'm having some issues installing snapd.  The error i'm getting is: failed to synchronize cache for repo 'zyga-snapcore'
<kyrofa> PugnaciousOne, what OS?
<PugnaciousOne> CentOS
<PugnaciousOne> i would have used ubuntu but the company i work for has issues if i use anything other than centos
<kyrofa> zyga, can you take a look at that? ^^
<PugnaciousOne> i'm trying to adapt the fedora guide to it
<zyga> PugnaciousOne: hey, centos is not supported yet
<kyrofa> PugnaciousOne, understood, I've been in that situation as well
<zyga> PugnaciousOne: I'm sorry but I didn't build a centos package
<zyga> PugnaciousOne: we're trying to get a working package but it's been somewhat starved by other things
<zyga> PugnaciousOne: if you want to help I could use someone to work on a centos package
<PugnaciousOne> ah, i'll have to try and get them to make an exception then.  it's very similar to fedora though.
<PugnaciousOne> what type of help do you need?
<zyga> PugnaciousOne: just on the packaging itself
<zyga> PugnaciousOne: I can work with you, I think we could reuse some of the work that went into the (incomplete because of selinux) fedora package
<PugnaciousOne> i have about 4 hours.  i can test whatever, but i'm currently vpn'd back into my company network so i can access the server through ssh
<PugnaciousOne> if it makes you feel any better, i run selinux in permissive mode so it shouldn't be an issue on my end
<PugnaciousOne> the vpn connection means that i'm a bit slower than i normally would be.  i'm on a little laptop at home
<zyga> PugnaciousOne: right now the package that I was trying to build for fedora is a few releases behind and stuck on selinux policy; there's no centos package available as that was planned as the next step
<zyga> PugnaciousOne: which version of centos do you need to use?
<PugnaciousOne> 7
<PugnaciousOne> the security guys have a cow even if linux is mentioned.  it took me months to get permission to use centos 7
<zyga> PugnaciousOne: ok, I cannot give you anything concrete but have a look at this: https://github.com/snapcore/snapd/wiki/Distributions#centos
<zyga> PugnaciousOne: if you want to contribute and help make the package happen I can giude you
<zyga> PugnaciousOne: but I cannot work on it full time yet
<zyga> PugnaciousOne: I wish I had better news
<PugnaciousOne> i'll help as much as i can.  just let me know what info/input you need from me
<zyga> PugnaciousOne: well, to work on the package itself
<PugnaciousOne> i was hoping to setup a rocketchat server to demo to the guys visiting from corporate tomorrow.  trying to get them to move out of the stone age and use actual communication
<PugnaciousOne> let me check and see if i have the dependencies first and i'll get back to you in a few minutes
<zyga> PugnaciousOne: if you cannot work on the package then don't worry, I'll get around to work on it soon (~1-2 weeks probably)
<zyga> PugnaciousOne: you may want to talk to Pharaoh_Atem
<zyga> PugnaciousOne: he was working with me on the initial fedora package and has helped me a lot with RPM specific knowledge
<PugnaciousOne> ok.  i'll look into it.  to be honest my coding is rusty and i don't use linux enough.  do you think it would be possible to build it from source?
<zyga> PugnaciousOne: yes although you'd have to glue the bits together manually
<zyga> PugnaciousOne: that doesn't sound like a good demo material
<zyga> PugnaciousOne: I'd recommend trying this out on debian/ubuntu for now
<PugnaciousOne> sadly, i'm familiar with gluing bits together.  i'll just see if i can build a debian install tomorrow
<zyga> PugnaciousOne: on sid you can apt-get install snapd
<zyga> PugnaciousOne: or xenial, that's the most tested release
<PugnaciousOne> yeah.  the info sec team is going to have a field day, but...if i strip the install down enough i should be able to get them to accept it
<PugnaciousOne> what's xenial?
<zyga> PugnaciousOne: codename of ubuntu 16.04
<mup> PR snapcraft#1096 opened: schema,copy plugin: better errors when item has no value <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1096>
<PugnaciousOne> ah
<PugnaciousOne> i've mostly been using arch for the past 3 years
<zyga> PugnaciousOne: there's an arch package but it is outdated as well
<PugnaciousOne> i'll stick with debian i think
<PugnaciousOne> it'll be the easiset for me to get them to accept
<zyga> PugnaciousOne: on xenial you will get much stronger security than on ubuntu
<zyga> PugnaciousOne: on debian the confinement system is not enabled as apparmor patches are not all available in the kernel there
<kyrofa> zyga, how does snapd work on openembedded and/or yocto? Do we have recipes upstreamed for snapd, snap-confine, etc?
<zyga> PugnaciousOne: s/than on ubuntu/than on debian/
<zyga> PugnaciousOne: it's a matter of time but for now ubuntu is the best host for snapd
<PugnaciousOne> ok
<zyga> kyrofa: I didn't work on openembedded
<kyrofa> zyga, do you know who did?
<zyga> kyrofa: no, I'm sorry
<zyga> kyrofa: that may have been asac
<kyrofa> Wonder who's maintaining that nowadays
<zyga> I suspect nobody
<kyrofa> As do I
<kyrofa> zyga, are there any other distros on snapcraft.io that you're uncertain about?
#snappy 2017-02-01
<zyga> kyrofa: look at the wiki link above
<zyga> kyrofa: that's the accurate state of the packaging support
<zyga> kyrofa: I think only ubuntu and debian are up-to-date and maintained
<zyga> kyrofa: everyting else is not
<kyrofa> zyga, that works, thanks
<mup> Bug #1660865 opened: [interface] hardware-observe should allow broader access to  /proc/bus/pci <Snappy:New> <https://launchpad.net/bugs/1660865>
<HumbleBeaver> odysseywestra anyone get around to you?
<HumbleBeaver> sorry it took so long to get back
<HumbleBeaver> I took a look at your project, I think it will pretty easy to snap. Is there a step you are confused about?
<bso> Hi I would like to ask if I can install avahi-daemon on Ubuntu Core.
<bso> On Ubuntu Desktop, I can install by "sudo apt install avahi-daemon".
<bso> On Ubuntu Core, "snap find avahi" returned 0 snaps.
<bso> So, I installed the classic snap.
<bso> On the classic prompt, I tried to install avahi-daemon with "sudo apt install avahi-daemon", but it seems it failed.
<bso> I saw the following message at the end of installation.
<bso> invoke-rc.d: policy-rc.d denied execution of force-reload. invoke-rc.d: policy-rc.d denied execution of start.
<bso> So, it seems it failed to install avahi-daemon.
<bso> Does anybody know why I can't install this package on classic snap?
<odysseywestra> HumbleBeaver: Basically, how to put it together really. Maybe it would help If I could see what other have done?
<bso> Does anybody know how to install avahi-daemon on Ubuntu Core?
<HumbleBeaver> odysseywestra, thats basically how I got started,
<HumbleBeaver> the snapcraft.yaml file is stupid easy once you get over the initial "now what" about it.
<HumbleBeaver> odysseywestra http://paste.ubuntu.com/23903144/ <--this is one I got help with here today, by mhall119 and jstrand
<HumbleBeaver> odysseywestra http://paste.ubuntu.com/23903151/ <--heres one I'm still messing around with its probably closer to what you need.
<HumbleBeaver> Note the source is a git repository.
<odysseywestra> okay. I'll take a look at those, and go from there. I'll show you what i have in a bit. Thanks for giving me a starting point.
<mup> Bug #1660879 opened: snap refresh with more than one argument produces poor error message <Snappy:New> <https://launchpad.net/bugs/1660879>
<bso> ping
<bso> Anybody used avahi on Ubuntu Core?
<olympionex> does anyone know if there is a bug that prevents the classic flag from functioning in 'try' mode.  I'm using version 2.20.1ubuntu1 on 16.04 and it seems to ignore the classic flag
<olympionex> same on 2.21
<mup> PR snapcraft#1097 opened: lifecycle: print the command needed to clean the dirty part <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1097>
<zyga> olympionex: yex, it was already fixed in master AFAIK
<zyga> olympionex: I think that you can switch to edge (snap refresh --edge core) to use nightly builds on your machine (even on classic :-)
<zyga> olympionex: (classic distro)
<zyga> olympionex: and this bug, I believe, is gone there
<zyga> olympionex: for more on this please ask chipaca
<zyga> olympionex: he should be around in a few hours
<olympionex> zyga: thanks very much!
<mup> PR snapd#2724 closed: overlord,tests: have enable/disable affect security profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2724>
<mup> PR snapd#2754 opened: tests: improve debug when the core transition test hangs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2754>
<mup> PR snapd#2727 closed: overlord/ifacestate: register all security backends with the repository <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2727>
<mup> PR snapd#2755 opened: interfaces: port the mount backend to new APIs while retaining snippets <Created by zyga> <https://github.com/snapcore/snapd/pull/2755>
<core-snappy> Do we have support for ubuntu 16.04 on dell gateway 5000
<core-snappy> can I upgrade from 15.04 to 16 ubuntu core
<mup> PR snapcraft#1094 closed: core: switch to using rpath for clasic confinement <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1094>
<mup> PR snapcraft#1092 closed: meta: properly get the icon extension from splitted name <Created by 3v1n0> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1092>
<mup> PR snapcraft#1086 closed: print snapcraft's version on startup when running with --debug <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1086>
<timp> is it possible with snap to compile different versions of binaries to have an optimized version for different CPU generations?
<mcphail> timp: I don't know if the automatic snapcraft building can do that, but you can certainly hand-roll a snap to meet those requirements. Sounds like a lot of work for ? how much reward, though!
<timp> would I then include different binaries inside a single snap? Or can different snap packages be selected depending on the CPU? (not just the architecture, but also the generation)
<timp> I'm asking for a project that is meant for scientific computations. Doing eigen analysis and such. The reward there can be big, because the computations for full datasets can take hours
<mcphail> I'm not sure of the latter option, but you could certainly pack multiple binaries in a single snap and have a wrapper script pick the correct one
<mcphail> I don't know how easy it would be to automate, though, as I don't know if confinement would give you access to /proc/cpuinfo (or similar) to autodetect
<zyga> timp: you can do that inside your snap
<timp> right. Sounds like a bit of a hassle though.
<zyga> timp: one binary that uses appropriate function based on the cpu
<zyga> timp: this is a gcc feature
<zyga> timp: and it should be pretty easy to use
<timp> ah, that sounds cool.
<timp> I got the question here http://community.mrtrix.org/t/provide-mrtrix3-as-a-snap-package-for-linux/687/2
<zyga> timp: so that one binary will work good everywhere
<zyga> timp: https://gcc.gnu.org/wiki/FunctionMultiVersioning
<zyga> timp: try that, good luck :)
<timp> in particular they want to use the -march=native flag.
<timp> thanks for the info :)
<zyga> timp: well, that particular flag is pretty pointless
<zyga> timp: as the resulting snap will be optimized for whoever builds it
<zyga> timp: for binary packages that's the totally wrong way to go
<timp> right, that's why they provide sources now instead of binary packages
<zyga> timp: I think that with this gcc feature you can deliver performant binaries anywhere
<timp> I will propose that to them.
<timp> I would say that is good enough for binaries. And the source will anyway be available for people who want to compile it themselves.
<mup> PR snapcraft#1096 closed: schema,copy plugin: better errors when item has no value <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1096>
<Hanonim> Hi folks !
<Hanonim> Does anyone have experience running Snappy on a raspberry? :)
<jamiebennett> Hanonim: yes, classic Ubuntu or Ubuntu Core?
<Hanonim> jamiebennett: Ubuntu Core
<Hanonim> jamiebennett: I'm new to snaps so I'm at that stage where it's quite frustrating not to have apt
<Hanonim> My first question is this one : is it possible to use wiringpi on snappy core ? I've searched a lot and the one thing i found show it's quite impossible (or really hard?)
<ogra_> you can surely use it inside a snap
<ogra_> snap interfaces exposes all GPIOs, you just need to connect the interface as needed and wiringpi should be able to manage it
<Hanonim> ogra_: is there a proper tutorial somewhere ?
<ogra_> the interfaces are named after http://pinout.xyz/#
<ogra_> i sthink http://snapcraft.io should have everything teaching you how to roll a snap and use interfaces with it
<ogra_> (if you run into issues, just ask here :) )
<ogra_> also https://docs.ubuntu.com/core/en/ ...
<Hanonim> ogra_: ok, i better study it better. now, my goal is to run a java app using pi4j, do you think it is "snapable" ?  raspbian can run my stuff
<ogra_> sure ...
<ogra_> you might need to tweak some paths etc to make it work in the snap context, but if it runs on raspbian it will run on core too
<Hanonim> ok well, i'll come back if i'm stuck
<Hanonim> thanks very much for your help !
<ogra_> that is why we are here ;)
<Hanonim> a somewhat "simpler" solution might be to install ubuntu server, but then there is not support for the GPIOs, is there ?
<ogra_> Hanonim, i dont know i must admit ... you have to try :)
 * ogra_ hasnt used classic installs on Pi in a long time
<Hanonim> ogra_: the issue i see is that wiringpi writes to /dev/mem which is, i beleive, read-only in snappy core. is it the kind of problems snapcraft resolves ?
<ogra_> snapcraft just helps you to roll a snap ... device access is managed through interfaces ...
<ogra_> (the second link i gave above describs the security system and interfaces)
<Hanonim> okay, i'll study it and stop asking too much questions :)
<Hanonim> i'm surprised there is almost nothing on how to use gpios/pi4j on snappy core, i expected it to be a hot topic
<zyga> Pharaoh_Atem: ouch on gitlab
<zyga> Pharaoh_Atem: do you have the repo of the policy somewhere?
<mup> PR snapd#2756 opened: snapctl: add config in client to disable auth and use it in snapctl <Created by mvo5> <https://github.com/snapcore/snapd/pull/2756>
<mup> Bug #1660957 opened: Need a way to get aa_is_enabled() and aa_query_label() to function <Snappy:New> <https://launchpad.net/bugs/1660957>
<Son_Goku> zyga, the repo is fine
<Son_Goku> I can push it elsewhere, yes
<Son_Goku> zyga, do you need it now?
<zyga> Son_Goku: it would be good to keep it safe
<zyga> Son_Goku: just worried that gitlab will go belly up
<Son_Goku> they're in the middle of recovery right now: https://www.youtube.com/watch?v=nc0hPGerSd4
<zyga> Son_Goku: wow, nice that they do it live
<zyga> Son_Goku: but pretty terrible with the defunct backups and rm -rf mistake :/
<Son_Goku> that was pretty damn unlucky, yeah
<Son_Goku> https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub
<zyga> I read the report
<zyga> the used space graph is depressing
<zyga> rm -rf /internet
<zyga> nohup ;)
<Son_Goku> yep
<Son_Goku> mvo: woo!
<Hanonim> i'm confused ! in this video
<Hanonim> https://www.youtube.com/watch?v=VbDAvTEBxew
<mvo> hey Son_Goku! in a meeting right now, but I will read backlog and reply async :)
<Hanonim> it's not ubuntu snappy core, it's ubuntu server ?
<Hanonim> he uses apt and everything
<Son_Goku> yeah, he's not using snappy core
<Son_Goku> that stuff doesn't work there
<zioproto> hello there, I have a problem pushing to the store staff with classic confinement. Can I get help here ?
<zioproto> https://myapps.developer.ubuntu.com/dev/click-apps/6815/
<mup> PR snapd#2757 opened: tests: add regression spread test for #1660941 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2757>
<Hanonim> This list of interfaces :
<Hanonim> http://snapcraft.io/docs/reference/interfaces
<Hanonim> shows "gpio" and "i2c" interfaces
<Hanonim> on my raspberry pi 2 i only see "io-ports-control", which is not referenced
<Hanonim> is there a link between gpio and i2c provided by the RPI and the io-ports-control interface ?
<ogra_> Hanonim, http://paste.ubuntu.com/23905508/
<ogra_> this is only in the edge channel builds currently though ... but shoudl migrate to stable eventually
<roadmr> jdstrand: hello! hey, we got hit by malformed 'name': '00-test-snap-build' lint-snap-v2_name_valid
<ogra_> daily edge builds can be found here http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> the interface names follow http://pinout.xyz/#
<roadmr> jdstrand: (but the store allowed the name registration and as far as some knowldgeable people think, it should be a valid snap name. Do you recall the status of converging on one snap name regex to rule them all?
<Hanonim> ogra_: nice, too bad it's not fully stable. what about i2c ?
<Hanonim> what does io-ports-control do ? i can't find info
<ogra_> in the works
<ogra_> i think morphis knows about io-ports ... likely nothing you want to use
<ogra_> iirc thats some legacy thing
<Hanonim> ogra_: hmmm, for now i'm a bit disappointed with the current state of affair. i might keep using raspbian unfortunately
<ogra_> Hanonim, well, come back eventually :) it is constantly improving ...
<ogra_> (and has many advantages over an apt based system ... )
<Hanonim> ogra_: yes, the idea is really good, just too restrictive right now (at least for my projets)
<ogra_> restrictive but secure :)
<roadmr> jdstrand: I have the regex that snapd is supposedly using and it allows the name I posted, so maybe the tools need to update the regex they use? let me know and I can share it
<ogra_> your devices wont be conquered by a botnet :)
<roadmr> ... yet :)
<ogra_> and reliable ... it is nearly impossible to break it
<ogra_> roadmr, pessimist :P
<Hanonim> ogra_: yup, and documentation will help. for instance, i can't even find one example on how to create a java snap. maybe i didn't look properly
<ogra_> Hanonim, https://github.com/ogra1/jtiledownloader ... thats a desktop app though
<ogra_> but headless apps wont be much different to package
<jdstrand> roadmr: we should be using the same snapd regex as snapd now. Did snapd change?
<roadmr> jdstrand: maybe! the regex is this ^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$
<Hanonim> thanks
<roadmr> jdstrand: (I don't follow snapd that closely, my report is mainly about what the package submitter observed with that name)
<jdstrand> this is what the review tools use: ^[a-z](?:-?[a-z0-9])*$
<jdstrand> let me check snapd
<roadmr> jdstrand: yes, your regex doesn't like the name I reported, while the one I gave, which should be snapd's, does
<jdstrand> snapd is using: var validSnapName = regexp.MustCompile("^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$")
<jdstrand> it looks like they changed
<roadmr> jdstrand: /o\
<jdstrand> I'll adjust the tools
<roadmr> thanks jdstrand!
<jdstrand> yeah, it changed in 88665e9a
<roadmr> jdstrand: oh! yes, that's about when we had that discussion on names, I think.
<roadmr> (early sept 2016)
<jdstrand> roadmr: this has been an ongoing conversation, cause I distinctly remember updating the tools to have precisely what snapd has. In fact, before 88665e9a, snapd used ^[a-z](?:-?[a-z0-9])*$ (the same as the tools)
<jdstrand> regardless, fixing it
<roadmr> jdstrand: thanks!
<roadmr> jdstrand: sorry it took so long to find this discrepancy and alerting you in such an indirect way :(
<jdstrand> it's fine. I'll have a fix in just a moment
<roadmr> many thanks :)
<jdstrand> roadmr: can you pull r835?
<roadmr> jdstrand: sure, coming up
<Kaleo> jdstrand, hey, (I think it's you I should ask), can you approve uploads #39, #40 and #41 of the ubuntu-terminal-app snap? it's
<zyga> jdstrand: hey
<zyga> jdstrand: going through the apparmor issue, trying to wrap my head around what is going on
<zyga> jdstrand: no luck yet but I'm trying more thigs
<zyga> jdstrand: I replied on the stpcpy branch, not sure if you replied back yet
<jdstrand> zyga: I saw and I did. bummer on reproducing
<jdstrand> zyga: I'm having the fun time of debugging an intermittent spread failure. I run it from here. fine. from travis, fail
<jdstrand> at least got some nice debugging improvements for snap-confine out of it
<jdstrand> snap-confine testsuite*
<zyga> jdstrand: when you ran it locally, which spread version did you use?
<zyga> jdstrand: fgimenez found some issues in how some of the tests are ran that would explain some of the failures we saw (e.g. no core snap)
<zyga> jdstrand: there was a new release of spread lately, perhaps upgrade to see if this is consistent with what you see on linode
<jdstrand> I may be out of date. thanks for the tip
<fgimenez> jdstrand, zyga hopefully will be fixed very soon
<zyga> jdstrand: HA
<zyga> jdstrand: I just got a super trivial way to reproduce this :)
<zyga> jdstrand: snap install snapd-hacker-toolbelt --devmode
<jdstrand> zyga: nice! :)
<zyga> jdstrand: snapd-hacker-toolbelt.busybox sh
<stokachu> nessita, am i not supposed to be able to see my conjure-up package in the snap store?
<zyga> jdstrand: nsenter -m/proc/1/ns/mnt
<zyga> jdstrand: this gives me the following error in syslog:
<zyga> jdstrand: Feb 01 16:25:13 xenial-server audit[22275]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/nsenter" name="" pid=22275 comm="nsenter" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> jdstrand: I'll adjust the test case to simplfy this
<zyga> jjohansen: ^^ if this helps you to have a look as well
<zyga> jdstrand, jjohansen: (above please prefix Feb 01 16:25:13 xenial-server audit[22275]: AVC apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.snapd-hacker-toolbelt.busybox//null-/usr/bin/nsenter" name="" pid=22275 comm="nsenter" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> er
<zyga> jdstrand, jjohansen: above please prefix snapd-hacker-toolbelt.busybox sh with sudo
<nessita> stokachu, checking, one sec
<zyga> jdstrand: this essentially takes my patch out of the loop
<zyga> jdstrand: as it is simply nsenter that fails
<zyga> jdstrand: and the snap is installed in devmode so apparmor should be in complain mode
<zyga> jdstrand: and snap-confine is out of the way (after setting up the namespace initially)
<zyga> jdstrand: and also its apparmor profile is out of the way
<stokachu> nessita, thanks, i just tested an upload and it seems to be going through
<jdstrand> zyga: note that apparmor is really out of the way if it is in complain mode. please give your finding to jjohansen
<jdstrand> (there could be a complain mode bug)
<nessita> stokachu, how are you uploading?
<nessita> because I don't see you being defined as collaborator, which is weird
<stokachu> nessita, snapcraft push ./conjure-up_2.1.0_amd64.snap --release edge
<stokachu> nessita, it's still uploading so it may complain
<zyga> jdstrand: it is! (snap install with --devmode)
<nessita> stokachu, let me know how that does please
<zyga> jdstrand: yeah, I'll prep a mail
<nessita> goes*
<zyga> oh, need to run to pick up kids from school
<jdstrand> zyga: I'm saying that just cause it is in devmode doesn't mean that an apparmor complain mode bug isn't causing trouble
<stokachu> nessita, http://paste.ubuntu.com/23905726/ did show an error
<nessita> stokachu, asking for some advice, one sec
<stokachu> nessita, ok ty!
<sitter> heya, zyga, kyrofa: any tips on how I would go about running the xdg-open shim from ubuntu-core? the way I see it a snap would have no way to get ahold of ubuntu-core stuff given http://snapcraft.io/docs/reference/env
<sergiusens> sitter: I get to open just fine for konversation (using now); only thing missing is to set it as the default action
<sergiusens> sitter: http://imgur.com/a/aArpk
<sergiusens> sitter: there is a host side bug though which is that nothing is currently depending on snapd-xdg-open; I thikn zyga was looking into that
<sitter> hm
<sergiusens> sitter: aside from not being able to set it as a default action, only other thing I am missing is proper icons; I get `?` most likely due to the Icon entry having a value of a name that doesn't exist on my host.
<sitter> sergiusens: indeed. I think it is only QDesktopService::openUrl that falls over
<sitter> sergiusens: e.g. try help -> about konversation and click any link
<sergiusens> sitter: yeah, that doesn't work
<sitter> which supposedly comes back false here https://github.com/qt/qtbase/blob/5b1f18b0f1cd07f2dfcafe79b456338f908de531/src/platformsupport/services/genericunix/qgenericunixservices.cpp#L91
<didrocks> yeah, we did develop snapd-xdg-open and a fake xdg-open in core snap side for that reason
<didrocks> dependency was still to be sorted out, zyga is owning this AFAIK
<sitter> ah, I get it. usr/local/bin is missing from PATH ^^
<didrocks> oh? I remember to have mentioned it on the ML and I thought after all our discussions that was fixed
<sitter> certainly isn't when using `snap run --shell` nor is it documented at http://snapcraft.io/docs/reference/env
<nessita> stokachu, so seems like what I promised about you being added automatically as a collabortor was not true, sorry. Could you please ping mvo and ask him to invite you as collaborator for that snap?
<didrocks> no, I guess that wasn't fixed after it was removed from PATH after all (and you're right)
<nessita> stokachu, mvo  should fill the form under https://myapps.developer.ubuntu.com/dev/click-apps/5479/collaboration/
<mvo> nessita: sure, I can add stokachu
<stokachu> ok
<sergiusens> sitter: didrocks if I get a bug report on snapcraft I can easily add the PATH
<stokachu> mvo, oh thank you
<stokachu> mvo, do you need my email or anything?
<Hanonim> okay, i've read quite a bunch of docs about ubuntu core and snapcraft and i don't see how i could use wiringpi (that needs to write to /dev/mem)
<mvo> stokachu: yes, your ubuntu-one primary mail would be nice
<didrocks> sergiusens: yeah, I wonder if that's the right place, but it can help for now as it seems it doesn't have traction snapd-side :)
<mvo> stokachu: just /msg it to me
<didrocks> sitter: mind opening the bug for sergiusens?
<didrocks> I can add it to desktop-launch as well for Qt apps for now
<didrocks> (but doesn't help on KDE's one as you are using your own launcher)
<sitter> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1661023
<mup> Bug #1661023: PATH does not include /usr/local/bin and /usr/local/sbin <Snapcraft:New> <https://launchpad.net/bugs/1661023>
<sitter> didrocks: yeah, easy enough to work around for now
<stokachu> nessita, thanks for you're help, im good to go now
<stokachu> your*
<sitter> about dialog links work like a charm with modified PATH. thanks for the help :)
<nessita> stokachu, excellent, sorry for the "honest" lie yesterday
<didrocks> sitter: nice! btw, we are going to promote your KDE snaps in the "top snaps of the month" for January :-)
<sitter> \o/
<mup> PR snapd#2756 closed: snapctl: add config in client to disable auth and use it in snapctl <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2756>
<zyga> re
<zyga> jdstrand: I agree, I think you are exactly right
<zyga> didrocks: hey
<zyga> didrocks: so the snapd-xdg-open bug
<zyga> didrocks: AFAIR there was some discussion and it didn't culminate with a decision as to how the dependency should be injected
<zyga> didrocks: I don't feel I own this bug actually, I think it belongs to foundations/desktop or if it belongs I don't have a plan to solve it anytime soon; adding the dependency is easy but it would be complex on server/headless installs
<HumbleBeaver> Morning everyone, Is anyone here using the snap version of Telegram?
<pachulo> I do HumbleBeaver
<stokachu> which one? telegram-latest or telegram-sergiusens
<HumbleBeaver> stokachu: Both actually
<stokachu> oh are they both required to be installed?
 * stokachu doesn't know which one to use
<pachulo> I'm using telegram-sergiusens and no, you don't need them both
<HumbleBeaver> No I had one installed and when it started to mess up, I uninstalled it and tried the other
<HumbleBeaver> I'm thinking it might have something to do with an extension I added when I installed the kconnect ppa.
<zyga> jjohansen: hey, can you please ping me when you are around. I have some good progress on the bug we've been talking about
<HumbleBeaver> pachulo have you had any issue with it not allowing attachments?
<HumbleBeaver> If not its something on my system and I'll do some digging.
<stokachu> only issue ive seen with this telegram app is the tray icon is missing
<HumbleBeaver> thanks stokachu, I've been fighting with an issue on my system and I'm starting to see a pattern.
<HumbleBeaver> Why it affect the snaps I'm not sure
<zyga> HumbleBeaver: the tray icon issue?
<zyga> HumbleBeaver: because it's a broken protocol, it's been researched by a few folks AFAIK. The actual icon is saved to /tmp and /tmp is private for each snap.
<zyga> there are a few other ways to show an icon there so it depends on the toolkit/app
<stokachu> so that requires a user talking to upstream to get that fixed?
<zyga> we should have /tmp-IPC backend for cases like this
<zyga> stokachu: it's a complex issue, I think
<zyga> stokachu: part of legacy protocols, old agrements, not sure
<stokachu> ok, wasn't sure if it was something we could workaround in the snapcraft
<stokachu> with organize or something
<zyga> stokachu: there's a bug that tracks this with a lot of details
<zyga> stokachu: doubtful
<zyga> stokachu: more likely in snapd
<stokachu> ah ok
<zyga> stokachu: or at a toolkit level
<zyga> stokachu: but then telegram bundles qt so you'd have to fix it and advertise the fix
<stokachu> would a classic snap work ootb for now?
<zyga> yes
<zyga> no
<zyga> we found some issues with the design of classic snaps
<stokachu> it is a nitpick detail but a lot of users would probably not like having a default icon there
<zyga> we know how to fix them but the work has not started
<stokachu> zyga, ah ok
<zyga> I think I'd stick for strict/devmode for now
<HumbleBeaver> zynga, no the file attachment bug. I'm starting to think that installed something that has caused snap packages and others to behave strangely
<HumbleBeaver> I've asked a few others and they say it works fine. I can also drag an drop file into telegram without issue
<zyga> jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/13
<mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:Confirmed> <https://launchpad.net/bugs/1656121>
<zyga> HumbleBeaver: I don't know anything about file attachment bugs but I could say that since the snap works in a different namespace it doesn't see the same filesystem as your desktop
<zyga> jdstrand: the last thing on that comment is key I think
<zyga> jdstrand: note that we don't see the disconnected profile anymore
<zyga> er, path
<zyga> jjohansen: if you have a branch I could test with a locally built kernel I'd like to keep digging
<mup> PR snapd#2758 opened: overlord/devicestate: implement policy about gadget and kernel matching the model <Created by pedronis> <https://github.com/snapcore/snapd/pull/2758>
<zyga> jjohansen: this is my top priority now
<kyrofa> ogra_, how would one enable SPI on the joule?
<ogra_> kyrofa, oh, no idea
<ogra_> never seen a joule
<zyga> kyrofa: is /dev/spi* around?
<kyrofa> ogra_, turns out that's the hw being used in that askubuntu question I pinged you about yesterday :P
<ogra_> yeah
<kyrofa> zyga, no idea
<kyrofa> ogra_, any idea who made the gadget for that?
<ogra_> i remember but i have no idea about joule ... you have to ask someone knowing the HW
<zyga> kyrofa: do you have a joule?
<ogra_> kyrofa, JohnAgosta might be able to point you to someone
<kyrofa> zyga, I'm afraid not
<zyga> kyrofa: meh, too bad then
<kyrofa> JohnAgosta, any idea who made the Joule gadget?
<JohnAgosta> kyrofa, are you referencing the gadget snap in the Joule image?
<JohnAgosta> https://developer.ubuntu.com/core/get-started/intel-joule
<mup> PR snapcraft#1078 closed: tests: do not rely on project_dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1078>
<kyrofa> JohnAgosta, sorry, internet flaked on me. Yes, that's what I'm referring to
<JohnAgosta> kyrofa, that was created by either of Robert Liu or Tim Chen. They are on Chinese New year break
<kyrofa> JohnAgosta, do you know of anyone around who might know how to enable SPI?
<JohnAgosta> kyrofa, please make sure you are looking at the correct one...this was all updated to beta4 images in the past week
<JohnAgosta> kyrofa, my brain is flaking out -- what is "SPI"?
<kyrofa> JohnAgosta, Serial Peripheral Interface
<kyrofa> JohnAgosta, hardware interface protocol
<kyrofa> Like i2c
<kyrofa> JohnAgosta, at least in e.g. the rpi, it needs to be enabled in the gadget
<kyrofa> JohnAgosta, we have an askubuntu question about it seemingly not being enabled on the joule, and no one knows how to enable it :P
<JohnAgosta> kyrofa, let me look...i cannot remember if it is enabled in this image...do you have access to private LP project https://bugs.launchpad.net/tuchuck?
<JohnAgosta> looking now
<kyrofa> I do
<ondra> kyrofa were discussing SPI for other project, and there is no SPI interface
<JohnAgosta> kyrofa, it will be listed as i2c
<ondra> kyrofa but we defo need it
<ogra_> +1
<ogra_> we need it on the pi too
<ogra_> (the interface)
<ondra> ogra_ do it! :P
<ogra_> well, i'm busy with other stuff
<JohnAgosta> kyrofa, ok, found it... it is now there in latest image https://bugs.launchpad.net/tuchuck/+bug/1607195
<JohnAgosta> kyrofa, we just updated the image on the website a week ago -- early image did not have it enabled yet
<JohnAgosta> kyrofa, one thing missing from our website is a pointer to the required BIOS (174).  I have an open request to Intel for a public share with that required BIOS
<kyrofa> JohnAgosta, this is i2c-- are you saying that covers spi as well?
<JohnAgosta> kyrofa, beyond my knowledge area... i was stating i2c only based upon your earlier comment referring to i2c as an example
<kyrofa> JohnAgosta, yeah it seems like i2c works
<kyrofa> But SPI does not
<kyrofa> JohnAgosta, mind if I create a new bug? Perhaps those guys can look into it once they return?
<JohnAgosta> kyrofa, please wait -- i am still researching
<kyrofa> JohnAgosta, sure thing
<kyrofa> ondra, thanks for the info by the way
<ondra> kyrofa no worries :)
<kyrofa> tvoss, https://askubuntu.com/questions/878750/package-conflicts-whith-snapd-on-ubuntu-14-04
<kyrofa> tvoss, might be of interest to you
<JohnAgosta> kyrofa, ok, I don't see anything in our project plans for SPI. Please create a "tuchuck" bug and I will track first with Intel to understand their module support as I don't even see anything from Intel.
<JohnAgosta> kyrofa, you can assign to me jagosta
<kyrofa> JohnAgosta, will do, thank you for investigating
<kyrofa> ogra_, ondra thanks for your help
<ogra_> np
<kyrofa> JohnAgosta, just FYI, this lists two SPI buses: https://software.intel.com/en-us/iot/hardware/joule
<mup> PR snapcraft#1098 opened: Ignore .tox directories when creating cleanbuild tar <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/1098>
<JohnAgosta> kyrofa, doesn't mean Intel has finished the linux driver yet. :)  Also, not sure why Intel did not include in project plan
<JohnAgosta> this is all still in development -- audio drivers not done yet either
<kyrofa> JohnAgosta, ah interesting, indeed that may be the case
<kyrofa> JohnAgosta, I created https://bugs.launchpad.net/tuchuck/+bug/1661067 but I don't seem to have permission to assign it to you
<JohnAgosta> kyrofa, interesting... I see WiFi LEDs on this sheet too and Intel is still discussing whether they even have WiFI LEDs.  :)
<kyrofa> Hahahaha
<tvoss> kyrofa: thanks for the hint, answering right now
<kyrofa> tvoss, of course, thank you!
<tvoss> kyrofa: https://askubuntu.com/questions/878750/package-conflicts-whith-snapd-on-ubuntu-14-04/878770#878770
<tvoss> ^ and others reading backlog :-)
<kyrofa> tvoss, user83107?!
<kyrofa> At least you have a picture :P
<jdstrand> zyga: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/14
<mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:Confirmed> <https://launchpad.net/bugs/1656121>
<zyga> jdstrand: thank you for the tip, I'll check that out
<zyga> jdstrand: honestly this makes me worried, we should investigate 1648903 and understand what is going on
<zyga> jdstrand: if this doesn't work then why should we assume other rules are respected
<jdstrand> that's why I filed the bug, though just cause one complain rule isn't working right doesn't mean they all aren't
<zyga> jdstrand: but when something as fundamental as this misbehaves a red flag gets raised in my mind
<zyga> jdstrand: I'll try the workaround to see if this helps
<zyga> jdstrand: perhaps jjohansen's kernel fixed one issue just to uncover another
<jdstrand> well, that is why I filed a bug. I'm just saying I don't think it requires panicking cause I only ever saw this with namespaces. we'd have tons of bug for devmode if it was wider spread
<zyga> jdstrand: that's true
<jjohansen> zyga: that is what I think is going on, the behavior changed with the kernel patch. So I think we move forward with it being a separate issue. I have already sent the patch for the complain issue up to the kt
<zyga> jjohansen: I agree, I think this is the right course of action
<zyga> jjohansen: did you look at the other issue, the one that jdstrand suggested?
<zyga> jjohansen: do you have any insight into that issue?
<jdstrand> to be clear, I only asked a question :)
<zyga> (a very plausible idea though)
<jjohansen> zyga: I'm looking
<zyga> jjohansen: btw: did you see the script I've attatched to the bug report?
<jjohansen> yes
<tvoss> kyrofa: hmmm, I logged in with my launchpad account, I had assumed that would give me a reasonable username
<tvoss> wow, that was more complicated than I expected :) kyrofa: managed to change my profile name
<kyrofa> tvoss, haha! Much better
<stokachu> so trying to get a config file to be included during my python part build http://dpaste.com/2T9HYX7
<stokachu> the filesets section isn't getting included though, the only way i could was make it seperate and add the dump plugin
<stokachu> is there a way to do both on a single part?
<kyrofa> stokachu, let me make sure I understand
<kyrofa> stokachu, the `conjure-up` part contains a `etc/conjure-up.conf` file that the setup.py doesn't install, so you want snapcraft to install it?
<stokachu> kyrofa, yea exactly
<kyrofa> stokachu, easy: use the `install` scriptlet
<stokachu> but in the same part (if possible)
<kyrofa> stokachu, are you familiar with that?
<stokachu> kyrofa, reading snapcraft help plugins now :)
<kyrofa> stokachu, it's part of the core, not a plugin: https://snapcraft.io/docs/build-snaps/scriptlets
<kyrofa> davidcalle, you're rocking on those docs, by the way
<stokachu> kyrofa, so would it just be `cp etc/conjure-up.conf $SNAP/etc/conjure-up.conf`?
<kyrofa> stokachu, almost-- $SNAP is a runtime-only variable
<stokachu> oh SNAPCRAFT_PART_INSTALL
<kyrofa> stokachu, you got it
<stokachu> cool! thanks ill give this a whirl
<stokachu> and yes davidcalle++ for the docs
<kyrofa> stokachu, just FYI, `filesets` does nothing by itself
<kyrofa> stokachu, it gives you the ability to define filesets that can be used by name in the `stage` and `prime` keywords
<stokachu> ah thats all? i think i was treating it like snap
<kyrofa> Yeah, the format isn't even correct-- you're using it like `organize`
<stokachu> kyrofa, hah ok thanks for clearing that up
<kyrofa> Well, not even that. But yeah, you can safely toast that line
<stokachu> kyrofa, so one more thing, where you see organize under spells:
<stokachu> i basically want to just put that whole repo into a directory in the snap
<stokachu> is that the right way?
<kyrofa> stokachu, indeed, that should work
<stokachu> should i just use an install scriptlet
<stokachu> ok cool
<davidcalle> kyrofa: stokachu: hey, thanks o/
<kyrofa> davidcalle, it's taken me a while to start referring people there instead of in-source docs, but man. So professional
<davidcalle> There should be a small blog post going live tomorrow on how MySQL uses scriptlets
<kyrofa> Nice!
<stokachu> kyrofa, do you know if there are a lot of big changes still needed for https://github.com/snapcore/snapcraft/pull/1093?
<mup> PR snapcraft#1093: python plugin: do the right thing with classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1093>
<stokachu> im itching to get conjure-up running on trusty
<kyrofa> stokachu, nope, just about there
<stokachu> cool
<kyrofa> stokachu, rather, yes, I know, and no :P
<kyrofa> Man that's a hard question to answer
<stokachu> :D
<mup> Bug #1631270 changed: running a command for a snap in try mode fails on trusty <trusty> <Snappy Launcher:Invalid> <Snappy:Fix Released by thomas-voss> <snap-confine (Ubuntu):Invalid> <https://launchpad.net/bugs/1631270>
<mup> PR snapcraft#1099 opened: catkin plugin: don't pass args to setup.sh <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1099>
#snappy 2017-02-02
<mdye> is there a status page for snap services in case of outtages or such? (I have automated testing of download and installation of my snap and it's been slow or timed out the last few hours; is this a problem on my end or in store services?)
<kyrofa> mdye, check http://status.snapcraft.io/
<mdye> thx
<kyrofa> mdye, ah, some firewall maintenance is happening today, I wonder if that is affecting things
<kyrofa> But I'll admit, that status page is quite a bit more optimistic about things than my experience has been. I have snaps uploading to CI daily and it's about 50/50 whether I'll get an email about a failed upload
<mup> PR snapcraft#1100 opened: repo: remove symlinks to libc <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1100>
<olympionex> when installing the app, it seems like the daemon in my snap is being started before the configure hook gets a chance to run.  I use the configure hook to setup the config and a few other things.  As a result, the daemon fails to start and the whole snap then seems to fail to install because of that.  Is this an error or the expected behavior?
<olympionex> *when installing the snap
<kyrofa> olympionex, that's expected behavior. When you consider running a hook upon install, there are two possible scenarios:
<kyrofa> 1. Run the hook after services start. This gives the hook a chance to query the running services, make sure everything is running correctly, and modify configuration if necessary. If something is wrong, it can error and rollback installation
<kyrofa> 2. Run the hook before services start. Which allows the hook to do some setup required by included daemons, but makes it useless for querying them and checking their health
<kyrofa> olympionex, honesty I think this is a good case for an install hook instead of making the configure hook do everything
<kyrofa> olympionex, but that's the reason the configure hook runs when it does-- it's closer to its purpose
<kyrofa> olympionex, would you mind logging a bug?
<olympionex> kyrofa: agreed, just making sure I don't have an option.  I'm trying to snapify a troublesome daemon that I can't modify unfortunately and need to do some setup upon install
<kyrofa> olympionex, currently your only option is to write a shell wrapper that makes sure it's setup correctly when run. That wrapper should be your daemon, and after it ensures things are setup, it should run the real binary
<kyrofa> olympionex, if we had an install hook that ran before the services did, you could use that instead
<olympionex> kyrofa: yeah, makes sense -- snap seems to have a lot of development going on, so maybe I can look forward to it soon
<kyrofa> olympionex, the configure hook stands alone in this regard because no one has asked for anything else. Please log a bug if you feel you need this
<olympionex> kyrofa, for snapcore/snapd?
<kyrofa> olympionex, right here: https://bugs.launchpad.net/ubuntu/+source/snapd/+filebug
<kyrofa> olympionex, if you want some examples of other snaps that go the wrapper route, check out the nextcloud snap. A good example is the `mysql` daemon: https://github.com/nextcloud/nextcloud-snap/blob/master/snapcraft.yaml
<kyrofa> olympionex, notice that it doesn't run mysqd directly, it runs start_mysql: https://github.com/nextcloud/nextcloud-snap/blob/master/src/mysql/start_mysql
<olympionex> kyrofa: thanks - I actually already have a wrapper to handle some of the required pid file requirements of my daemon
<kyrofa> Which makes sure a database is generated, etc.
<kyrofa> Good dea
<kyrofa> l
<htafdresgi> i snap installed docker, how do I docker pull?
<htafdresgi> like I know I can cd into the /snap/docker/bin but is that how I'm supposed to do it, or is there a different way?
<htafdresgi> never mind i fiugred it out
<htafdresgi> figured*
<olympionex> I'm having a catch-22 with classic confinement and snapcraft.  It won't let me run snapcraft unless I install the core snap, and there is no way to do that b/c it conflicts with the immovable ubuntu-core snap
<olympionex> this is on 16.04, weird that it works fine on my other pc
<olympionex> same versions of everything, including the ubuntu-core snap
<olympionex> i had to end up purging snapd and reinstalling
<Mirv> oSoMoN: can you retest bug #1642900 vs. https://github.com/ubuntu/snapcraft-desktop-helpers/pull/40 ?
<mup> PR ubuntu/snapcraft-desktop-helpers#40: Use also ubuntu-app-platform's lib/$ARCH dir for LD_LIBRARY_PATH (LP:â¦ <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/40>
<mup> Bug #1642900: libgcc_s.so.1 not found by app using ubuntu-app-platform content snap <Ubuntu App Platform:In Progress by timo-jyrinki> <https://launchpad.net/bugs/1642900>
<Mirv> oSoMoN: note that you'd need edge version of platform snap to have the libgcc_s.so.1
<oSoMoN> Mirv, will do
<zyga> o/
<mup> PR snapd#2692 closed: spread: add unit suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2692>
<mup> PR snapd#2741 closed: store: enable download deltas on classic by default <Created by squidsoup> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2741>
<mup> PR snapd#2751 closed: 14.04/integrationtests: rely on upstart to restart ssh <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2751>
<mup> PR snapd#2743 closed: debian: move the snap-confine packaging into snapd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2743>
<zyga> jjohansen: hey
<zyga> jjohansen: which timezone do you live in?
<jjohansen> zyga: uhm UCT-8 (portland, OR area)
<jjohansen> but well, I can't say I uhmm follow the tz all that well
<jjohansen> zyga: I haven't gotten to testing the test kernels against your bug yet. I have been chasing it as a regression for 1661030 and jdstrand's bug 1648903
<mup> Bug #1648903: Permission denied and inconsistent behavior in complain mode with 'ip netns list' command <AppArmor:New> <https://launchpad.net/bugs/1648903>
<jjohansen> I was about to get around trying your reproducer
<zyga> jjohansen: haha, that explains a lot :)
<zyga> jjohansen: I'm already running the test with the kernel you indicated
<jjohansen> ah nice
<zyga> jjohansen: btw, where is your tree, I could follow your patches and learn a few things
<jjohansen> zyga: ha which tree? I have a whole bunch of trees, sadly most are more stale than I like
<jjohansen> there are the set on kernel.ubuntu.com/jj/
<zyga> jjohansen: s/tree/repo/
<zyga> let's see
<jjohansen> 1 for each release + the backport kernels (which is work I need to get back too)
<zyga> hmm, that's a 404
<zyga> jjohansen: do you use multiple repositories for that/
<zyga> I'm not familiar with kernel development process
<jjohansen> http://kernel.ubuntu.com/git/jj/
<jjohansen> its git://kernel.ubuntu.com/jj/  from git
<jjohansen> zyga: I was trying to get a base set of backport kernels setup in a single repo, sadly its in poor shape as I just haven't had enough to do it properly
<jjohansen> I also have an upstream tree
<zyga> thanks, I'm looking a the xenial tree now
<jjohansen> but I don''t push to that one often because a lot of bots watch it, and if I push dev code there I get slammed with emails from bots complaining about any and every little thing
<jjohansen> great some times, but not when you are in the middle of dev
<jjohansen> zyga: the proposed patch hasn't been pushed yet
<zyga> jjohansen: where is it?
<jjohansen> give me a minute
<zyga> ah
<zyga> sure :)
<zyga> jjohansen: curious, what do bots do when you push there?
<zyga> (so far fetching from git://kernel.ubuntu.com/jj/ubuntu-xenial.git fails on corrupted repository)
<zyga> jjohansen: the test passed!!!
<zyga> jjohansen: it's fixed :)
<zyga> jjohansen: when can you land that in the ubuntu kernels and upstream?
<jjohansen> zyga: okay its pushed, I will send the patch out in a few minutes. It will land into -proposed with the other fixes (it fixes a regression)
<jjohansen> so it should land in the next kernel release in 2.5 weeks
<zyga> jjohansen: understood, thank you!
<zyga> jjohansen: did you push it to git://kernel.ubuntu.com/jj/ubuntu-xenial.git?
<zyga> I still get: remote: error: Could not read 162e766089a4fdbbb6626f39cc23da92fdb2204e
<jjohansen> zyga: yes, on the master branch
<jjohansen> gah, I need to reset my master-next as its been rebased and the ref no longer exists
<jjohansen> this happens all the time
<jjohansen> gah, no something else is broken
<mup> PR snapd#2759 opened: asserts: support for correctly suggesting format 2 for snap-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2759>
<zyga> jjohansen: btw, I'll break my userspace code and see if I can trigger an oops that I ran into earlier
<zyga> jjohansen: I was trying to use a O_PATH fd to do something that wasn't meant for it (setns)
<zyga> jjohansen: and that oopsed
<jjohansen> zyga: sounds good, I am still trying to figure out what is wrong with the tree, something broke
<zyga> jjohansen: what are your typical work hours?
<jjohansen> O_o the tree has lost all its heads
<zyga> jjohansen: this one? http://kernel.ubuntu.com/git/jj/ubuntu-xenial.git/log/ ?
<jjohansen> zyga: yes
<jjohansen> zyga: my work hours drift but for the last few weeks they have been roughly 07:00-11:00 UCT and 20:00-02:00 UCT
<mup> PR snapd#2760 opened: merge release 2.22.1 into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2760>
<jjohansen> if I got the conversion right
<jjohansen> thats 23:00-4:00 and 12:00-18:00 local time
<zyga> are you doing this to stay in touch with devs in europe?
<jjohansen> zyga: some times, but not atm, I'm a night owl and tend to work at nights when things quiet down here
<jjohansen> I do try reseting my hours every once and a while but then something comes up, I push and they drift ...
<zyga> jjohansen: I know how this feels :)
<jjohansen> :)
<zyga> jjohansen: thank you for fixing this and a host of other issues
<zyga> jjohansen: I'll check if the oops happens and let you know if it does (with a test case if I can)
<jjohansen> sounds good
<mup> PR snapd#2761 opened: vendor: move gettext.go back to github.com/ojii/gettext.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/2761>
<mup> PR snapd#2762 opened: debian: update breaks/replaces for snap-config->snapd  <Created by mvo5> <https://github.com/snapcore/snapd/pull/2762>
<zyga> jjohansen: no more oops
<zyga> jjohansen: so whatever it was, one of your patches fixed it
<jjohansen> zyga: \o/
<mup> PR snapd#2763 opened: store: retry on 502 http response as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/2763>
<sergiusens> ogra_: where did the livecdrootfs stuff live?
<mup> PR snapd#2762 closed: debian: update breaks/replaces for snap-confine->snapd  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2762>
<ogra_> sergiusens, image PPA
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<sergiusens> ogra_: so download source deb and the push? Might I just ask you to do something? xdg-open is in /usr/local/bin, would be nice to get that in the default PATH
<ogra_> sergiusens, well, see my comment on the bug :)
<ogra_> sergiusens, we have /usr/local/bin in the default path on images ... and the calling user on a classic system should also have it in his default PATH ... the only way to *not* have it in the default PATH is if a desktop wrapper redefines PATH
<ogra_> sergiusens, so IMHO the desktop wrppers need a fix here
<ogra_> *wrappers
<ogra_> ogra@localhost:~$ echo $PATH
<ogra_> bah
<ogra_> ogra@localhost:~$ echo $PATH
<ogra_> /home/ogra/bin:/home/ogra/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
<ogra_> thats on my Pi
<ogra_> (and i get the same thing on my desktop classic install)
<sergiusens> ogra_: http://paste.ubuntu.com/23910571/
<sergiusens> ogra_: I wonder if snap-confine is wiping it then
<sergiusens>  oops
<ogra_> that would be a question to zyga i guess
<sergiusens> oh, no oops, I pasted the paste bin and confused by your output :-)
<zyga> ogra_: hey
<zyga> how can I help?
<ogra_> zyga, does snap-confine reset PATH ?
<zyga> yes it does
<ogra_> aha
<zyga> for snaps other than classic confinement that is
<zyga> otherwise you don't know what PATH you may see
<ogra_> zyga, can we add /usr/local/bin then ?
<sergiusens> zyga: then it needs /usr/local/bin and didrocks was right, you do need to fix it ;-)
<ogra_> zyga,  we need to find xdg-open there
<zyga> ogra_: does that path exist on core?
<ogra_> yes
<zyga> ogra_: oh, curious
<zyga> ogra_: sure I can fix this quickly
<ogra_> for apt, dpkg palceholders and for xdg-open
<zyga> ogra_: is there a bug for reference?
<ogra_> yeah
<sergiusens> zyga: do you use gui snaps at all???
<zyga> sergiusens: not that much, my local setup is in a weird state for content testing
<zyga> sergiusens: and I don't want to rely on snaps on a dev machine
<zyga> sergiusens: I use them on other machines though
<zyga> sergiusens: why?
<ogra_> Bug 1661023
<mup> Bug #1661023: PATH does not include /usr/local/bin and /usr/local/sbin <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1661023>
<zyga> ogra_: thank you
<ogra_> zyga, nad it needs to be first ... before /usr/bin
<ogra_> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
<ogra_> like that
<zyga> ogra_: noted
<ogra_> else it wont override
<zyga> ogra_: actually without /snap/bin
<ogra_> heh, yeah, i guess
<ogra_> (that was just tghe PATH from ym Pi)
<oSoMoN> didrocks, when IÂ build a webbrowser-app snap locally and install it, the app wonât start, Iâm getting this error:
<oSoMoN> This application failed to start because it could not find or load the Qt platform plugin "xcb"
<oSoMoN> in "".
<sergiusens> zyga: I would strongly recommend you do dev in a VM and leave your main system as a dog fooding one to enjoy the pain and fix stuff as they show (some sort of stress testing)
<didrocks> oSoMoN: did you snapcraft update since tuesday?
<didrocks> oSoMoN: pat confirmed that updating to latest works
<oSoMoN> didrocks, no I hadnât, let me try that
<zyga> sergiusens: I'm already working in a VM but I don't use the host as much, that's my "main" vm that moves from host to host as I change devices
<zyga> sergiusens: I also use snaps but I don't use gui snaps that much
<zyga> sergiusens: (I'm mostly a terminal + browser person
<ogra_> use a snapped browser and a snapped terminal !!
<ogra_> :)
<oSoMoN> didrocks, confirmed, that fixed the issue
<didrocks> oSoMoN: phew, same fixed issue then :)
<didrocks> (the issue being part definition is cached, but the parameters used in the git repo has changed/been added)
<oSoMoN> can snapcraft be improved to handle this better?
<didrocks> unsure, I guess we have to think that the definition can be async compared to code
<didrocks> so handling backward compatibility and not treating as one unit, but 2
<didrocks> (I didn't think about the caching at the time)
 * didrocks really needs to take a lunch break, ttyl
<ogra_> but if you already cache you know the local version
<ogra_> so its just a matter of comparing to the remote and notifying the user
<sergiusens> oSoMoN: handle what better?
<ogra_> remote parts updates
<sergiusens> oSoMoN: so you want the latest and greatest always no matter if what is locally works and what is remote doesn't?
<ogra_> i guess jst a notification that there is a new remote version would help
<sergiusens> ogra_: we could do that on `pull` as it is an online operation; don't think it would be wise to anywhere else
<sergiusens> and notify, not auto update
<ogra_> right
<ogra_> just let the user know "hey, there is a newer version of this remote part"
<ogra_> prevents support questions because of outdated local revisions
<sergiusens> oSoMoN: if you log a bug, we can do it ;-)
<oSoMoN> didrocks, mind filing the bug? you have a better understanding of the problem, and you would explain it better than I could
<HumbleBeaver> jdstrand, mhall119 after all that help day before yesterday you two gave me I have found out that my system is to blame.  Every snap installed on my system exhibits some sort of issue.
<HumbleBeaver> But if I add process-control to the program and connect them they work fine.
<HumbleBeaver> I'm currently trying to sort out the issue.
<jdstrand> HumbleBeaver: its still just the one program?
<mup> PR snapd#2764 opened: tests: disable ubuntu-core->core transition on ppc64el (its just too slow) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2764>
<HumbleBeaver> jdstrand no, another program I wrote is now exhibiting the same issue. (main screen never displays) , but hexchat locks up, blender-tpaw doesn't launch, Krita doesn't load, and both Telegram snaps won't allow me to attach files via the attach clip.
<stokachu> tvoss, you around?
<jdstrand> HumbleBeaver: and for all of them, if you connect 'process-control' it fixes the issue?
<HumbleBeaver> jdstrand I've only added it to numnom so far, and yes it fixed the problem.
<jdstrand> HumbleBeaver: can you give the output of 'grep type=1326 /var/log/syslog' after you see all these denials?
<jdstrand> s/denials/failures/
<HumbleBeaver> jdstrand sure can,  stand by
<tvoss> stokachu: yup, I am
<HumbleBeaver> jdstrand paste.ubuntu.com/23911024
<zyga> ogra_: https://github.com/snapcore/snapd/pull/2765
<mup> PR snapd#2765: cmd: add /usr/local/* to PATH <Created by zyga> <https://github.com/snapcore/snapd/pull/2765>
<zyga> ogra_: review appreciated :)
<mup> PR snapd#2765 opened: cmd: add /usr/local/* to PATH <Created by zyga> <https://github.com/snapcore/snapd/pull/2765>
<zyga> jdstrand: if you are around I'd like to quickly discuss where to take the sc_must_stpcpy branch,
<zyga> jdstrand: we talked but I'm not sure what the bottom line was
<zyga> jdstrand: I'm +1 on the rename to sc_append_string (or similar) and +1 to drop the size limit if you want to as well;
<zyga> jdstrand: and +0.5 on the simplification (from stpcpy-like to strcat-like)
<ogra_> zyga, looks fine, though not sure we need games actually :)
<zyga> ogra_: I felt the same, added it for completeness
<ogra_> yeah
<zyga> ogra_: but I can remove it if you feel we don't want to have it
<ogra_> well, we have it everywhere else, seems more consistent in the end
<jdstrand> zyga: I am here, I'll need to circle back though
<jdstrand> zyga: it sounds like you are in favor of basically everything then. I think going to strcat-like is going to be more useful long term. already you have to reset the pointer at the end of all the stpcpy calls to send the string off to be used, so this will remove that requirement
<zyga> jdstrand: yes, it makes it simpler and more reliable at a irrelevant cost in performance
<zyga> jdstrand: if you agree I'll folow up and do just that
<zyga> jdstrand: and apply this across the tree to kill the static char buffers
<jdstrand> HumbleBeaver: telegram, numnom, krita and codebreakers are all sched_setscheduler and that is a regression in 2.22
<jdstrand> HumbleBeaver: hexchat is fchown which was never allowed
<zyga> ogra_: if you reviewed that branch can you please add a comment; that helps
<jdstrand> zyga: sounds fine
<zyga> jdstrand: thanks! :)
<ogra_> zyga, yeah, sorry distracted
<zyga> ogra_: no worries, thank you :)
<HumbleBeaver> jdstrand, well that explains why they still work on other people's computers.  Thanks for your help
<jdstrand> HumbleBeaver: right, you have 2.22, other people only have 2.21
<jdstrand> HumbleBeaver: for each of telegram, numnom, krita and codebreakers, can you add 'sched_setscheduler' (without the quotes) to the botton of /var/lib/snapd/seccomp/profiles/snap.<your snap>, then relaunch the app and let me know if it works?
<jdstrand> bottom*
<jdstrand> HumbleBeaver: fyi, bug 1661265
<mup> Bug #1661265: [regression] sched_setscheduler denied with Qt/QML applications <snapd (Ubuntu):New> <https://launchpad.net/bugs/1661265>
<jdstrand> mvo: fyi, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1659522/comments/10
<mup> Bug #1659522: [SRU] 2.22 <verification-failed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Trusty):Fix Committed> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1659522>
<mvo> jdstrand: oh, so we need a 2.22.2?
<zyga> mvo: \o/
<jdstrand> mvo: I've assigned that to me, but I would like to do a little digging first
<zyga> mvo: l.oo.l release
<jdstrand> mvo: yes, sorry
<mvo> jdstrand: no worries
<mvo> jdstrand: I caused 2.22.1 myself :/
<mvo> jdstrand: do you have a rough estimate about times?
<jdstrand> mvo: let me PR a fix right this second that way you aren't blocked on my investigation. I will want to augment the comment for this syscall pending my investigation
<mvo> sounds good
<mup> PR snapd#2766 opened: tests: improve snap-env test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2766>
<mup> PR snapd#2767 opened: interfaces: allow sched_setscheduler again by default (LP: #1661265) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2767>
<jdstrand> mvo: ^
<jdstrand> mvo: I did it to master. will you get it to 2.22.2 or should I do something extra?
<mvo> jdstrand: I can cherry-pick it into the 2.22 branch
<jdstrand> HumbleBeaver: in addition to trying all that, can you point me to your hexchat snap? I'd like to see how it is using fchown
<HumbleBeaver> jdstrand, tingping is the developer of hexchat. It's the one in the store.
<jdstrand> HumbleBeaver: great, thanks!
<mup> PR snapd#2768 opened: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2768>
<zyga> jdstrand: FYI, I found this insteresting: https://github.com/snapcore/snapd/pull/2768/files#r99141379
<mup> PR snapd#2768: interfaces: miscellaneous updates for hardware-observe, kernel-module-control, unity7 and default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2768>
<jdstrand> zyga: yes, that occurred to me to. we'll have to design it to support snapd policy versions if we are going to allow different series core snaps on the same device. note, this isn't the only issue with this-- I suspect there will be a lot of things that will need to be done differently based on the core series
<zyga> jdstrand: after writing this I realized that we can see the slot so we can identify 16 and 18 series but I totally agree with what you just said
<jdstrand> zyga: I'd rather not try to predict all that right now though. when series 18 core snaps are a thing and we want to pull the trigger on something different, we should see how we want to do that
<jdstrand> it's kinda scary if you really think about it-- series 22 with series 16-- how will snap-confine/snapd have changed?
<zyga> jdstrand: I bet we will be asked for continuity so that 16-based snaps can be installed aon 18
<zyga> jdstrand: yes
<zyga> jdstrand: I think it is worth to think about what we will do with multi-base snaps when we start to split that sometime soon
<jdstrand> zyga: that request will need to also consider positive change moving forward
<zyga> jdstrand: (I suspect we'll make ubuntu-base-16 before EOY)
<zyga> jdstrand: backwards compatibility will win ous many hearts and I think it's not impossible to do
<zyga> jdstrand: we'll just recommend devs to update to 18-base
<jdstrand> eg, it is perfectly correct to evolve and deprecate. series 16 should always work, but does that mean series 18+ need to not evolve? interesting questions
<zyga> jdstrand: I suspect that we may phase out series over time (e.g. a given snapd will only support 16 and 18 and maybe 20 but not 22 and 16 at the same time)
<zyga> jdstrand: no, I didn't mean that
<zyga> jdstrand: in 18 we should change what that interface does
<zyga> jdstrand: (or to be precise) when that interface is connected to a 16-base snap it should behave as it does
<zyga> jdstrand: but not in 18-base snap
<zyga> jdstrand: from the same snapd process
<zyga> jdstrand: (curious issues with >1 base snap and snap interfaces and auto-connection)
<zyga> jdstrand: lots of fun things ahead :)
<jdstrand> well, I think this needs to be all thought through at the appropriate time. there is a lot to consider
<jdstrand> yes
<kalikiana> Hmmm 'snapcraft push' just gabe me '502 Bad Gateway'
<kalikiana> Basically a bunch of raw HTML
<kalikiana> Tried again, now it seems to have worked
<kyrofa> kalikiana, I get that every other day when LP tries to push as well
<ogra_> jdstrand, did you see my comment on the remote syslog bug ? would be nice to have /etc/rsyslog.d writable by the core-support interface
<ogra_> i can then add the needed script bits to the config script
<jdstrand> ogra_: I thought I saw the comment, and I thought I saw you say you were going to do that, and I meant to say 'thank you' to you :)(
<jdstrand> :)
<ogra_> oh
<ogra_> i only made the dir writable on an image level yet
<mup> PR snapd#2769 opened: snap-exec: support nested environment variables in environment: <Created by mvo5> <https://github.com/snapcore/snapd/pull/2769>
<jdstrand> ogra_: oh, I see what you mean
<jdstrand> ogra_: let me take that onto an existing PR
<ogra_> awesome !
<ogra_> thanks ... i'll care for the rest then
<jdstrand> ogra_: is there a particular path or naming convention you are going to use? ie, we have a choice to allow modifying anything in there (eg, 50-default.conf) or to only modify [0-9][0-9]-snap*.conf (or something)
<ogra_> well, i made the whole dir writable on the image level ... if you want to restrict the interface to a particular filename, feel free to do so, just tell me the name then
<mup> PR snapd#2767 closed: interfaces: allow sched_setscheduler again by default (LP: #1661265) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2767>
<ogra_> jdstrand, the latter sounds sane though ... also in the light that we might want to be able to add more options later
<ogra_> and i'd like to keep one file per option to not have to do sed stunts in the scripts
<ogra_> (rm $filepath is so much easier than in-place editing of a big config file)
<jdstrand> ogra_: I was going to do this: http://paste.ubuntu.com/23911801/
<ogra_> perfect
<jdstrand> that at least namespaces it a bit
<ogra_> yep
<jdstrand> I figure you might want some flexibility on 00-snap-foo.conf vs 99-snap-bar.conf vs snap-baz.conf
<ogra_> yeah
<jdstrand> cool
<jdstrand> I'll send it up. I think I will do a separate PR since I already have approval on the other one
<jdstrand> ogra_: this is exciting! :)
<ogra_> :D
<jdstrand> for some reason I'm a bit of a logging nerd :)
<ogra_> and i love to save wear levelling of my SDs
<ogra_> directing all my boards to a central place surely helps that
<mup> Bug #1661265 opened: [regression] sched_setscheduler denied with Qt/QML applications <snapd-interface> <Canonical System Image:In Progress by pat-mcgowan> <Snappy:Fix Committed> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1661265>
<mup> PR snapd#2758 closed: overlord/devicestate: implement policy about gadget and kernel matching the model <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2758>
<mup> PR snapd#2770 opened: interfaces/core-support: allow modifying snap rsyslog configuration <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2770>
<jdstrand> ogra_: since you mentioned you forgot about the remote logging bug, I'll remind you of bug #1504657 too since it is all in the same area
<mup> Bug #1504657: ntp servers should be configurable on snappy <Snappy:Confirmed> <ubuntu-core-config (Ubuntu):Won't Fix by ogra> <https://launchpad.net/bugs/1504657>
<ogra_> geez !
<jdstrand> ogra_: sorry! feel free to prioritize how you want, just wanted to get it back on your radar. I don't have any more, I promise! :)
<ogra_> jdstrand, no, that was about me also missing this one
<jdstrand> oh, heh :)
<ogra_> my LP search doesnt show it because the task assigned to me is wont-fixed
<jdstrand> ogra_: makes sense
<jdstrand> ogra_: this one is interesting. In addition to being able to set the time servers for core, I suspect that eventually people will want an ntp, chrony, openntpd, etc snap and therefore will want to be able to disable systemd-timesyncd so they can just use their snap
<jdstrand> ogra_: so I think in the config (at least at this time) should include enable (default)/disable, and setting the timeservers
<ogra_> jdstrand, well, afer my last change ro tezh configure script that just means adding systemd-timesyncd to a variable list ... thats trivial
<ogra_> the way i changed it we only need to add the service names to the list now
<jdstrand> cool. I figures from a snapd security policy perspectivy, it was covered with the systemctl changes
<ogra_> right
<jdstrand> figured*
<jdstrand> jeez I can't type :)
<jdstrand> ogra_: thanks for this too, now I'm really, really excited! :)
<jdstrand> :)
<ogra_> https://code.launchpad.net/~ogra/core-snap/more-flexible-service-handling/+merge/316116
<ogra_> we just can add to SERVICES= as needed
<jdstrand> neat :)
<BLu2> is there a way to start a snap without network and device access? like "snap run hello --strict" or whatever if I don't fully trust the application?
<noise][> FYI we are experiencing some network issues that are leading to slow response times for some Store endpoints, see http://status.snapcraft.io/ for details and updates as we have them. Currently affecting mostly snapcraft release for a subset of snaps.
<zyga> BLu2: you can disconnect the network / network-bind interface but due to the way seccomp works today that is not ideal (the app will be killed if it tries to use the network)
<zyga> BLu2: ideally we'd not kill the app and just reject those calls
<zyga> BLu2: and perhaps even offer an "offline" zone or something where we could connect the app there instead and it would just be in an empty network
<zyga> jdstrand: ^^ I always wanted to do this use case
<mup> PR snapd#2771 opened: debian: update changelog from releases 2.22.{1,2} <Created by mvo5> <https://github.com/snapcore/snapd/pull/2771>
<BLu2> zyga, sounds good enough
<zyga> BLu2: note that soon we will not kill an app in that case but this feature is still not merged in the upstream kernel AFAIK
<zyga> (or merged but not released)
<jdstrand> zyga: you are in luck. tyhicks has patches that are going upstream for seccomp ERRNO with logging (ie, deny with EPERM (for example) but log). today we kill because that is the only one that logs
<kyrofa> jdstrand, ahhhhh \o/!
<jdstrand> yeah, cool stuff
 * kyrofa hugs tyhicks 
<kyrofa> That will change my life
<kyrofa> jdstrand, judging from the regression bug I saw you log, can I assume that arg filtering is supported now as well?
<jdstrand> zyga: I guess the use case you are talking about is running without network? (cc BLu2) interface connections are absolutely the way to do that. killing is not unreasonable if you don't trust the app, but that point is moot, we won't be killing soon
<tyhicks> hey kyrofa :)
<jdstrand> kyrofa: yes, it has been for some time. the first policy that used it came in Dec for network-control and interfaces
<kyrofa> Very cool, good work guys
<jdstrand> kyrofa: 2.22 had some small changes. I have several PRs open now for more arg filtering policy and working on a few more things
<jdstrand> kyrofa: thanks!
<kyrofa> jdstrand, one of the things pushing that was setpriority. Are some args whitelisted for that?
<jdstrand> tyhicks: can you remind me-- do your patches include logging the value of the args?
<tyhicks> jdstrand: the first set did but the audit people didn't like it
<tyhicks> jdstrand: they see the audit message format as being set in stone :/
<kyrofa> :(
<jdstrand> kyrofa: that is one of the ones that is up for review
<jdstrand> actually, was that 2.22...
 * jdstrand looks
<jdstrand> actually, no, that is still on the list, but it will be in 2.23
<jdstrand> tyhicks: that annoying
<jdstrand> that's*
<tyhicks> oh
<jdstrand> tyhicks: is there anything more that we can do?
<tyhicks> jdstrand: oh, I misunderstood you
<jdstrand> maybe I asked unclearly
<tyhicks> jdstrand: I thought you were asking if the errno value would be logged - that's what the audit folks were against
<jdstrand> oh no
<jdstrand> sorry
<kyrofa> jdstrand, sounds good. What is the plan there-- only allowing setting priority for yourself and only specific priority ranges?
<jdstrand> I meant if we allowed setpriority 0-19 and -1 was blocked, can we log that arg2 was -1
<tyhicks> jdstrand: that's not in the patch set - that looks very hard to do
<tyhicks> jdstrand: I think the BPF that libseccomp generates would have to be modified to support that
<zyga> jdstrand: I've updated https://github.com/snapcore/snapd/pull/2745
<mup> PR snapd#2745: cmd: add sc_string_append <Created by zyga> <https://github.com/snapcore/snapd/pull/2745>
<jdstrand> kyrofa: we will allow setpriority(PRIO_PROCESS, ..., 0-19) by default. other uses will require process-control
<kyrofa> jdstrand, good deal. MySQL wants -20, I wonder how they actually snapped it
<kyrofa> Maybe the require process-control
<kyrofa> Yup, they do
<jdstrand> kyrofa: they use process-control
<kyrofa> How cool will it be when mysql will request process-control, the user doesn't want to give it, so mysql simply says "okay, I just won't run at that high a priority then" instead of dying?
<jdstrand> kyrofa: well, today it has a snap declaration that auto-connects it
<jdstrand> kyrofa: but it will be cool when disconnected that it won't die, yes
<kyrofa> jdstrand, yeah, I'm really talking about the one I embed in nextcloud
<kyrofa> jdstrand, I'm still maintaining a mysql fork to compile that setpriority out
<jdstrand> fun!
<jdstrand> :)
<kyrofa> jdstrand, although if I asked for a snap declaration to connect it, think I'd get it?
<kyrofa> I guess it would probably perform better
<zyga> jdstrand: I heard about that feature, I wonder if we can detect if the kernel supports this; the seccomp backend should do runtime detection
<jdstrand> I doubt it :P
<zyga> jdstrand: (as should apparmor perhaps)
<jdstrand> zyga: what are we detecting?
<jdstrand> zyga: the log vs not log?
<zyga> jdstrand: capabilities of the implementation in the kernel
<jdstrand> zyga: we'll just add that to the list of patches that need to be in a kernel. it'll be upstream, eventually it'll flow down. distros that don't want to patch their kernel can use kill instead. perhaps that should be a compile time flag...
<zyga> jdstrand: that won't be very nice, I'd rather detect that (for a few reasons)
<zyga> hmmm
<zyga> than again
<zyga> maybe for seccomp that's not relevant
<zyga> unless there's new syntax
<zyga> or new API that defines this in C
<jdstrand> the policy won't change
<zyga> I was mostly after being able to take snapd binary from a snap
<zyga> and run in it somewhere
<zyga> and not see issues
<zyga> oh, drat, we will see issues already as snapd in debian will be affected by this
<zyga> I'll add a card
<jdstrand> that sounds like crazy talk :P
<jdstrand> more seriously, I need to get to other thngs before eow
<zyga> jdstrand: mmm think carefully
<zyga> jdstrand: that's a good idea :)
<zyga> jdstrand: if you +1 the sc_string_append branch I'll have easier life for the next few days
<kyleN> hey, anyone know how to install core snap when ubuntu-core is already isntalled on xenial desktop?  http://pastebin.ubuntu.com/23912890/
<kyrofa> kyleN, purge snapd or wait for the new release that will migrate it for you
<kyleN> kyrofa, as in apt-get remove --purge snapd?
<kyrofa> kyleN, apt purge snapd is more new-agey, but yeah
<kyleN> ok, thanks
<kyrofa> kyleN, but note that'll kill any snaps you have as well
<kyleN> kyrofa, I already kill them off hoping that might fix it ;)
<kyrofa> kyleN, ha! Easy fix then
<kyrofa> kyleN, note that core will automatically be pulled in once you reinstall and attempt to install a snap
<kyrofa> (instead of ubuntu-core)
<kyleN> kyrofa, i also note that now snap install *requires* sudo (on xenial desktop)
<kyrofa> kyleN, yeah that whole thing is beyond me. I always used sudo
<kyleN> anyway, it worked, thanks kyrofa
<kyrofa> kyleN, good deal, no problem
<kyleN> kyrofa, can I 'sudo snap try prime' with a classic snap? I get: snap "make-system-user" requires consent to use classic confinement
<kyleN> and passing --classic does not change that
<kyrofa> kyleN, not sure, try passing-- oh
<kyleN> (I like snap try : )
<kyrofa> kyleN, hmm... might be a bug, I'm not sure about that
<kyrofa> I would like it if I could use it
<kyrofa> Darn encrypted homes
<mup> PR snapcraft#1101 opened: misc: consistently use a dash for copyright years <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1101>
<jdstrand> roadmr: can you pull r837 whenever it is convenient. not urgent in the least
<roadmr> jdstrand: totally. r836 is in the queue, just awaiting a deployment but it probably won't happen until Monday...
<roadmr> jdstrand: so for now the consequence is that production doesn't yet accept those number-first snap names. On the upside, we never deployed to production the "name of death" revision, so we're safe there.
<roadmr> anyway... 837 coming up
<jdstrand> roadmr: cool, thanks. r837 covers the all-numeric case that pedronis mentioned is not supported
<roadmr> neat!
<jdstrand> which the name of death regex handled, but the new one didn't
<roadmr> cool! ok jdstrand I see a deployment containing r836 was requested and may happen today.
<jdstrand> r837 is really corner case so again, just whenever is fine
<roadmr> thanks :)
<mhall119> sergiusens: does "snapcraft cleanbuild" ignore local directories named "snap"?
<kyrofa> mhall119, yes it does, we just noticed that
<mhall119> :/
<mhall119> is it a regex, or just "snap" ?
<kyrofa> Just snap (remember `prime` used to be called `snap`)
<kyrofa> It's a carry-over from that
<mhall119> thanks, I'll rename to snappkg then
<kyrofa> mhall119, wait, what's in there?
<mhall119> a config file and wrapper script
<kyrofa> mhall119, because the newest release is making the 'snap' directory special
<mhall119> this is a directory I made
<kyrofa> Yeah you'll want to rename it anyway, then
<mhall119> thanks kyrofa
<sergiusens> elopio: you need to test cleanbuild with every release ;-)
<mup> PR snapcraft#1102 opened: cleanbuild: include snap directory in tarball <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1102>
<kyrofa> sergiusens, there you go ^^
<mup> PR snapcraft#1103 opened: meta: support for the environment keyword <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1103>
<icey> what do I execute to get into a shell in a specific snap's sandbox?
<cooksey> hello all
<kyrofa> icey, snap run --shell <appname>
<kyrofa> Hey there cooksey
<cooksey> i want to build snapd on a yocto based linux (build from git source). has anyone done this?
<icey> thanks kyrofa :)
<mup> PR snapd#2772 opened: interfaces: allow nice/setpriority to positive values by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2772>
<icey> I knew it was something like that but couldn't tease it out
<kyrofa> cooksey, not that I know of. It should work fine, but keep in mind snapd's dependencies as well
<jdstrand> kyrofa: fyi ^ PR
<kyrofa> jdstrand, hey thanks!
<cooksey> that's what I was looking for. trying to find a list of dependencies and basic instructions/best practices to build from source
<cooksey> can't find any build from source documentation
<kyrofa> cooksey, building won't be an issue so much, but you need to make sure you have a kernel with an up-to-date apparmor, and make sure seccomp is enabled
<kyrofa> cooksey, zyga can probably give you some guidance
<cooksey> ah
<cooksey> just found the document that i think i need
<kyrofa> cooksey, but I think he's gone for the day. You might consider pinging him earlier tomorrow
<cooksey> thank, kyrofa. I will if I need him.
<kyrofa> cooksey, sounds good
<teward> who do I stab for issues wrt what's on the snapcraft.io site
<kyrofa> teward, what's going on?
<teward> kyrofa: I'm a moderator on Ask Ubuntu, which is linked as a 'support medium' for Snapcraft, but we're Ubuntu-centric, not "snapd" centric.
<teward> would love to have that link 'removed' or at least have a comment next to it about "(if on Ubuntu Core)" since we don't support non-Ubuntu distros there
<kyrofa> teward, snapcraft only runs on ubuntu
<teward> kyrofa: what about snapd?
<teward> does it only run on Ubuntu too?
<teward> we're getting broad questions regarding snapd on non-Ubuntu
<kyrofa> teward, no, but you complained about snapcraft, not snapd :)
<teward> kyrofa: i'm complaining about the *site*
<teward> not snapcraft or a specific component
<teward> related: http://meta.askubuntu.com/questions/16672/do-we-support-snapd-on-other-distros
<kyrofa> teward, perhaps an email to the snapcraft mailing list would be best
<teward> list address?
<kyrofa> teward, the link is right next to the AskUbuntu one
<kyrofa> teward, https://lists.snapcraft.io/mailman/listinfo/snapcraft
<mup> PR snapd#2755 closed: interfaces: port mount backend to new APIs, unify content of per app/hook profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2755>
<kyrofa> teward, indeed, the link should probably mention "only if using on ubuntu" or something similar
<kyrofa> teward, note also that there are two separate tags: snap and snapcraft
<kyrofa> But snapcraft.io only mentions one
<cory_fu> Hey, I'm hitting a strange error trying to build a classic snap
<cory_fu> "classic confinement requires the core snap to be installed. Install it by running `snap install core`."
<cory_fu> However, when I try to install that, I get this:
<cory_fu> cannot install core snap "core" when core snap "ubuntu-core" is already present
<zyga> cory_fu: hey
<zyga> cory_fu: you can update snapd on your system
<zyga> cory_fu: and track candidate/edge
<kyrofa> cory_fu, yeah known issue. The newest snapd will migrate you from ubuntu-core to core
<teward> kyrofa: https://github.com/ubuntudesign/snapcraft.io/issues/271 is relevant, and i have hailed someone on the rocket chat server apparently who pointed me to filing issues there
<zyga> cory_fu: then some code will migrate ubuntu-core to core
<teward> but you're not wrong
<kyrofa> cory_fu, building a classic snap requires core
<zyga> cory_fu: and you will be good to go
<cory_fu> zyga: Sure.  I'm currently using the snapd that came with xenial.  How would I switch to candidate/edge?
<kyrofa> cory_fu, do you have any snapd installed?
<kyrofa> err, any snaps*
<cory_fu> kyrofa: charm, snap-codelabs, and ubuntu-core
<zyga> kyrofa: you don't have to purge state anymore
<zyga> kyrofa: snapd does the migration
<kyrofa> zyga, so he just needs to switch to ubuntu-core from edge?
<zyga> kyrofa: yes
<kyrofa> zyga, will that install the core snap from edge, then?
<kyrofa> cory_fu, try `sudo snap refresh --edge ubuntu-core`
<cory_fu> kyrofa: It said refreshed, but I still have ubuntu-core listed and snapcraft still fails missing core
<kyrofa> cory_fu, then I refer you to zyga for the nice migration. I personally just purged snapd and reinstalled it
<kyrofa> But that toasts your snaps too
<cory_fu> kyrofa: I'm fine with that approach
<kyrofa> cory_fu, then it'll install the `core` snap from the beginning, instead of `ubuntu-core`
<cory_fu> Sounds good.  After I apt remove snapd, how do I install the edge?
<kyrofa> cory_fu, you don't need to
<kyrofa> Just install snapd again, and install a snap
<kyrofa> Or just `sudo snap install core`
<kyrofa> cory_fu, refreshing to edge was an attempt to get that migration to run
<kyrofa> But it didn't. Not sure how it works
<cory_fu> Ah, gotcha
<stokachu> is $SNAP* exposed in the hooks/configure scripts?
<pedronis> zyga: notice IÂ think that once you have switched it probably takes 5 minutes or so for the update to happen
<kyrofa> stokachu, yes
<stokachu> kyrofa, cool thanks
<kyrofa> pedronis, good to know, thank you
<cory_fu> kyrofa: That worked fine.  Thanks.  Is there any plan to backport that in some way so that lxd containers (I'm using ubuntu-xenial) or other new xenial instances will be able to use classic snaps out of the box?
<kyrofa> cory_fu, yeah, eventually that migration will hit everyone
<kyrofa> cory_fu, you're just riding the wave ;)
<cory_fu> kyrofa: Is it possible to use the core snap inside a lxd container?  I'm getting a mount error when trying to install it, even when using -c security.privileged=true
<kyrofa> cory_fu, you're a little beyond my expertise. Have you seen https://www.stgraber.org/2016/12/07/running-snaps-in-lxd-containers/ ?
<cory_fu> kyrofa: I hadn't, thanks.  Possibly I need newer versions of lxd, or such.  I will continue to investigate tomorrow.
<cory_fu> For now, have a good evening.  o/
<kyrofa> cory_fu, you as well!
<mup> PR snapcraft#1097 closed: lifecycle: print the command needed to clean the dirty part <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1097>
<mup> Bug #1661436 opened: snap download can't find gadget or kernel snap from a branded store <Snappy:New> <https://launchpad.net/bugs/1661436>
#snappy 2017-02-03
<mup> PR snapcraft#1093 closed: python plugin: do the right thing with classic <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1093>
<mup> PR snapcraft#1104 opened: repo: refactor into package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1104>
<cokebottle> God day
<cokebottle> good day
<cokebottle> Please after readinng a lot of info about snappy ... i still don't understand what it is about
<cokebottle> can anyone help me out , as i am confused i about what snappyy is about    Thankyou
<zyga> good morning
<mup> PR snapd#2773 opened: interfaces/mount: generate per-snap mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/2773>
<mup> PR snapd#2774 opened: interfaces/mount: add dedicated mount entry type <Created by zyga> <https://github.com/snapcore/snapd/pull/2774>
<mup> PR snapd#2775 opened: cmd: add functions to load/save fstab-like files <Created by zyga> <https://github.com/snapcore/snapd/pull/2775>
<mup> Bug #1661533 opened: show the snap app size info <Snappy:New> <https://launchpad.net/bugs/1661533>
<mup> PR snapd#2776 opened: cmd: use per-snap mount profile to populate the mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/2776>
<abc_> any?
<mup> PR snapd#2759 closed: asserts: support for correctly suggesting format 2 for snap-declaration <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2759>
<mup> PR snapd#2777 opened: cmd: fix autogen.sh on fedora <Created by zyga> <https://github.com/snapcore/snapd/pull/2777>
<mup> PR snapd#2745 closed: cmd: add sc_string_append <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2745>
<mup> PR snapd#2778 opened: cmd: use safer functions in sc_mount_opt2str <Created by zyga> <https://github.com/snapcore/snapd/pull/2778>
<bulldog> guys my qt5 application have font and mouse cursor issues how to solve them ?? some fonts looks odd , and mouse cursor do not follow system cursor theme , am having [deskto-qt5] already in my craft file
<liuxg> bulldog, you need to package the needed fonts into your snap to get it working..
<mup> PR snapd#2779 opened: tests: gruntwork backend and suite; task for sync snapd with vendor <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2779>
<bulldog> liuxg, which package have ubuntu default fonts ??
<bulldog> and what about mouse cursor
<liuxg> bulldog, I have designed a Chinese Qt app, and I packaged the needed Chinese fonts. for example https://github.com/liu-xiao-guo/rssreader_slim/blob/master/snapcraft.yaml
<bulldog> liuxg, my app uses qwebview so i need almost all fonts cause there are almost all languages user can browser webpage into
<liuxg> bulldog, in that case, you probably need to package all of the needed fonts into your snap. In my example,  I packaged   - fonts-wqy-zenhei
<liuxg>       - fcitx-frontend-qt5, and make the Chinese input method working.
<bulldog> i dont know why snap dont want use system fonts :D
<bulldog> snap package seems to be turning into operating system them self
<bulldog> now they should ship kernels and other system components so that they can run on anyting
<liuxg> bulldog, in that case, your probably can try the "classic" snap, which basically it can use the system founts.
<bulldog> what is a classic snap ??
<bulldog> :O
<liuxg> bulldog, you can refer to my example at https://github.com/liu-xiao-guo/helloworld-classic/blob/master/snapcraft.yaml
<bulldog> liuxg, my application cant play youtube videos in qwebview , and some people here were syaing thats my coding fault LOL
<liuxg> bulldog, if I remember correctly, in the Qt SDK, there is an example for that.
<liuxg> bulldog, you can refer more about classic on our document at https://snapcraft.io/docs/reference/confinement
<bulldog> liuxg, also the content in qwebview is little bit weired , after packaging in snap format there are white lines around the <table> tag in the html page qwebview is loading into its webframe
<liuxg> bulldog, ideally, we want everything packaged into the snap, but if you cannot, you may do a classic snap, which does not have strong confiment in the seense.
<bulldog> liuxg, i have coded the application correctly to play videos , now idk why the hell eaach applications need to ship their own flash players and media codecs
<bulldog> liuxg, i want my snap in store , will classic confinement will work ??
<liuxg> bulldog, the idea behind Snap is that it packaged everything it needs into a single package so it does not reply on the core and other apps. a snap is a self-contained app!
<bulldog> and i shipped with flash player , and it wont work in snap i dont know wth is wrong with that
<bulldog> liuxg, i understand that , but they should atleast allow to use some system stuffs like flash player damn
<liuxg> bulldog, if you package everything into a single snap, it can be installed on multiple distos and run them without the dependence on the distros. however, if you release an app in "classic", it may not work on some of the distros if the dependence is not there.
<bulldog> now if this is possible , where can i find example of application which is playung video using flash player ??
<bulldog> developers are saying its fault in my code , oh god , what ??? few are saying qwebkit cant use falsh player omg
<bulldog> lmao
<bulldog> liuxg, take windows and macos as example , they ships dependencies in packages , but they use systems codecs and flashlayer
<bulldog> liuxg, with confinement: classic ubuntu snap store will accept my package ???
<liuxg> bulldog, it needs to have manual review.  yeah, it can be published :)
<bulldog> i first time come to know about confinement: classic
<bulldog> liuxg, btw here is my application http://bit.do/ktweb
<bulldog> i packaged with appimage , and debian format , everything works fine
<liuxg> bulldog, thanks. it looks very cool
<bulldog> classic confinement look like what appimage project is trying to do
<liuxg> bulldog, if you already have the debian package, you may use "dump"plugin to install it in the snapcraft.yaml.  this is one of the example at https://github.com/liu-xiao-guo/wechat
<bulldog> liuxg, i will try ,
<bulldog> liuxg, with classic confinement i cant install snap  it says error: cannot perform the following tasks: - Mount snap "ktube-media-downloader" (unset) (snap "ktube-media-downloader" requires consent to use classic confinement)
<liuxg> bulldog, sorry, this is a better example http://blog.csdn.net/ubuntutouch/article/details/53078713
<mup> PR snapd#2780 opened: tests: increase snap-service kill-timeout <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2780>
<bulldog> liuxg, am able to make snap but the problem is it wont play videos and mouse cursor and qwebview odd rendering of pages
<liuxg> bulldog, did you try to install it with "devmode"? which removes all of the confinement.
<bulldog> ok am trying
<bulldog> Snapcraft returned error: cannot perform the following tasks: - Mount snap "ktube-media-downloader" (unset) (snap "ktube-media-downloader" requires consent to use classic confinement)
<bulldog> with --devmode  flag
<liuxg> bulldog, for that error, I do not know how to help you.. for classic app, you do not need to have the devmode option to install it.
<bulldog> liuxg, seems like a bug https://bugs.launchpad.net/snappy/+bug/1656820
<mup> Bug #1656820: snap try with classic confinement doesn't work <Snappy:Fix Committed> <https://launchpad.net/bugs/1656820>
<liuxg> bulldog, are you able to upgrade to snapd, I am now having 2.22. you may need to use the proposed channel
<bulldog> am having snapd   2.21
<bulldog> liuxg, how users will able to install this snap if they will not having snapd 2.22 ??
<liuxg> bulldog, http://paste.ubuntu.com/23917232/
<liuxg> bulldog, it seems that you need to use the --classic option to install it.
<bulldog> okay let me  try
<liuxg> bulldog, classic is supported from 2.20 onwards :)
<bulldog> okay
<liuxg> bulldog, sounds good. is it working now?
<bulldog> let me chk
<bulldog> installed
<bulldog> trying to run
<bulldog> liuxg, wow
<bulldog> videos are playing now :)
<liuxg> bulldog, what happened?
<bulldog> and theme issues are gone
<liuxg> bulldog, it seems great :)
<bulldog> liuxg, can i upload it to store ??
<liuxg> bulldog, as said before, you can upload it, however, it is up to manual review since it does not have the confiment in practice. ideally, it should have the confinementt working. that is the ultimate goal :ï¼
<bulldog> i mean will someone manually review it ?
<mup> PR snapd#2765 closed: cmd: add /usr/local/* to PATH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2765>
<bulldog> is the softwares app of ubuntu able to find the way to install packages with classic confinement :D ??
<bulldog> okay i dont have to worry about it thanks alot man
<liuxg> bulldog, it cannot be found in the stable channel, I think. you definitely have a way to get it installed.
<liuxg> bulldog, you are most welcomee..
<bulldog> liuxg, i have to update my GUI Snapcraft GUI tools with these updates :), so you know https://github.com/snapcraft-gui/snapcraft-gui
<bulldog> *do
<mup> PR snapd#2781 opened: overlord/devicemgr: fix test: setup account-key before using the key for signing <Created by pedronis> <https://github.com/snapcore/snapd/pull/2781>
<mup> PR snapd#2782 opened: timeutil: a bunch of helpers for the scheduled refreshes <Created by mvo5> <https://github.com/snapcore/snapd/pull/2782>
<mup> PR snapd#2781 closed: overlord/devicemgr: fix test: setup account-key before using the key for signing <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2781>
<xiaoji_> è¯·é®ããsnappyçåå®è£åï¼å¦ä½æ¹ååªè¯»ï¼åè®¸å¯å å¯æ°å»ºç®å½ï¼
<xiaoji_> hello, excuse me?
<mup> PR snapd#2783 opened: Add an interface for use by thumbnailer <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/2783>
<xiaoji_> hello, excuse me?
<BadCodSmell> I am confused by snappy
<BadCodSmell> Is there a pure snappy ubuntu distro/os release?
<BadCodSmell> Right now it just looks like another bolt on package manager
<sergiusens> BadCodSmell: yes, Ubuntu Core is a pure snappy based system
<sergiusens> BadCodSmell: https://www.ubuntu.com/core
<BadCodSmell> ugh it requires an online account with ubuntu though
<BadCodSmell> enterprise fud
<BadCodSmell> Can I install it without that?
<BadCodSmell> Otherwise I might as well just go windows 10 for a managed OS.
<BadCodSmell> Ah confirmed it's some enterprise fluff
<BadCodSmell> I don't understand though
<BadCodSmell> it is not necessary and apparantly only bootstrapping
<BadCodSmell> It looks like security gone mad
<sergiusens> BadCodSmell: if windows works for you, by all means use it. I don't know how you got to "requires login" so fast though...
<BadCodSmell> it wants some SSO rubbish just to bootstrap.
<BadCodSmell> But I don't want that.
<ogra_> well, it is rather IoT focused than "enterprisey" ... thats one of the ways to prevent botnets
<BadCodSmell> It's not the linux way to deprive users
<sergiusens> I will refrain from helping if that is the attitude for things you don't like
<BadCodSmell> That's not ubuntus concern
<ogra_> but as sergiusens said, if windows suits you better, go for it ... and enjoy getting hacked
<BadCodSmell> If governments want to shutdown companies that fail to have security practices as basic as setting defaults passwords...
<BadCodSmell> Unfortunately that's not how hacking works.
<BadCodSmell> Since I used to be one.
 * sergiusens feels like someone just came here to vent
<ogra_> yeah
<sergiusens> already knowing the answers to the questions asked even
<BadCodSmell> Maybe I can just edit the image or something, annoying.
<ogra_> you can just use a classic image and install snapd on it if you feel better with that
<BadCodSmell> I would really like to see it out of the box and if it's using it for kernel, etc
<BadCodSmell> With classic image there's the question of jumping from apt to snapd for everything.
<ogra_> then create some random SSO account and live with it
<BadCodSmell> There's no minimal image but meh
<ogra_> ??
<ogra_> i dont think there is a more minimal image than the snappy one (even way smaller than the smalles classic one)
<ogra_> https://developer.ubuntu.com/core/get-started ... http://releases.ubuntu.com/ubuntu-core/16/ ...
<BadCodSmell> I think my own stripped down debian is around 1GB but I guess the USB is live and stuff.
<ogra_> ogra@localhost:~$ df -h /
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/loop0       65M   65M     0 100% /
<BadCodSmell> for core?
<ogra_> plus
<ogra_> ogra@localhost:~$ df -h /writable
<ogra_> Filesystem      Size  Used Avail Use% Mounted on
<ogra_> /dev/mmcblk0p2   29G  468M   27G   2% /writable
<ogra_> but i have a bunch of extra packages installed
<BadCodSmell> that's not bad
<ogra_> right after install the writable bit is rather around 300MB
<ogra_> you can roll back the rootfs in case something doesnt work on upgrades ... it does auto-rollback after a kernel upgrade if something goes wrong etc etc ...
<BadCodSmell> The annoying thing with the image being almost 4GB
<mup> PR snapd#2784 opened: image: check kernel/gadget publisher vs model brand, warn on store disconnected snaps  <Created by pedronis> <https://github.com/snapcore/snapd/pull/2784>
<BadCodSmell> I have a 4GB USB stick and everywhere jumps from KiB to KB etc without telling you
<ogra_> the image is 300MB and gets resized to full disk size on first boot ...
<BadCodSmell> cant tell off the bat if itll fit
<ogra_> except for the KVM images
<ogra_> (whihc cant easily resize because the img is actually the "physical disk"
<ogra_> )
<BadCodSmell> Are snaps differentially updated?
<ogra_> you mean in deltas ?
<BadCodSmell> basically
<ogra_> thats currently landing ...
<BadCodSmell> best kind is not of the package download
<BadCodSmell> but of the files, ie you send your version and it sends fs deltas
<BadCodSmell> or wholesale if it doesn't have
<ogra_> well, i find the 100% reliable rollback a better feature personally :)
<BadCodSmell> I've created some systems like that myself
<BadCodSmell> but it's a nightmare to maintain
<ogra_> but yeah, package delta downloads are ready to land (you can already enable them with aan env var while they arent default yet)
<BadCodSmell> I wonder if rdiff or xdelta
<ogra_> xdelta
<simosx> https://bugs.launchpad.net/snappy/+bug/1661590
<mup> Bug #1661590: When launching a snap from Ubuntu Software, it runs the first command alphabetically <Snappy:New> <https://launchpad.net/bugs/1661590>
<ogra_> snaps are signed, compressed squashfs'es ... i dont think rdiff works well in that context
<BadCodSmell> should do
<simosx> https://bugs.launchpad.net/snappy/+bug/1650689
<mup> Bug #1650689: Channel switching (track new channel) does not work if the two channels happen to have identical snap packages <Snappy:New> <https://launchpad.net/bugs/1650689>
<mup> Bug #1661590 opened: When launching a snap from Ubuntu Software, it runs the first command alphabetically <Snappy:New> <https://launchpad.net/bugs/1661590>
<BadCodSmell> I run it against compressed archives (custom tar like internally)
<BadCodSmell> still
<BadCodSmell> it's not good to run it against archive (ie tar)
<ogra_> simosx, hmm, works for me on core images ... snap refresh --<channel>  <snapname> ...
<BadCodSmell> most efficient to make list of files removed, files new, and diffs for files changed, if it can't diff it effectively, then just treat the changed file as a new file
<simosx> ogra_, tried it on ubuntu-core in LXD, did not work. The snaps in both channels have to be identical.
<ogra_> in lxd ... hmm
<BadCodSmell> small compressed things it will suck but for large things I think eventually with the blocking it will start again so one difference up front wont go down the whole stream
<simosx> ogra_, and on Ubuntu 16.04 (desktop).
<ogra_> simosx, i do it with the core snap all the time on my installs to test something in the edge channel and then go back to the stable install later
<ogra_> and these are definitely never identical :)
<mup> PR snapd#2785 opened: Provide a more interesting pitch for upstream developers using snaps <Created by evandandrea> <https://github.com/snapcore/snapd/pull/2785>
<simosx> ogra_, try it with 'snap info network-manager'. Switch between 'stable' and 'beta'.
<BadCodSmell> if it rdiffs the whole squash fs, you have to keep both in memory or on disk at one time at some point unless you have a good dedupe fs under it
<BadCodSmell> or unionfs :D
<BadCodSmell> etc
<ogra_> BadCodSmell, well, i didnt work on the implementation but not messing up the gpg signature and needing to work with compressed squashfs binary diffs was a requirement that rdiff seemed to not fulfill
<BadCodSmell> weird
<BadCodSmell> maybe one day I will look at it
<ogra_> or at least didnt fulfill at tthe performance level that was desired
<BadCodSmell> I have had to make a bunch of strange things
<BadCodSmell> like a kind of rsync that creates jumbo patches and works in bulk rather than comparing differences between two machines (using versioning)
<Son_Goku> sergiusens: does snapcraft only support merged source projects?
<Son_Goku> (aka, debian style packaging)
<ogra_> snapcraft supports anything you want :P
<ogra_> limitless :)
<ogra_> just a matter of how you use it ;)
<ogra_> (read: i guess you have to give more context)
<sergiusens> Son_Goku: sorry, I don't understand
<Son_Goku> sorry, let me explain better
<Son_Goku> one complaint I received recently about snapcraft is that it seemed to expect that the source tree is where the snapcraft packaging data is
<sergiusens> Son_Goku: oh, you want out of tree snapcraft?
<Son_Goku> yes
<sergiusens> if so that works
<Son_Goku> how?
<Son_Goku> I couldn't figure it out via the docs
<sergiusens> the `source` entries just need to point to the upstream you want to consume
<ogra_> just use source:
<ogra_> right
<Son_Goku> also, when using source, is there a way to apply patches?
<ogra_> or use the make plugin and have a git pull in your Makefile ... or ... or ...
<ogra_> there are many ways
<sergiusens> Son_Goku: you can now with `prepare`
<Son_Goku> sweet
<Son_Goku> so we do have an equivalent of the %prep stage
<sergiusens> Son_Goku: it is just script in yaml to run whatever you want or need (not patch specific to not force anything on anyone)
 * ogra_ also always just uses Makefules and calls patch from there ... works too
<sergiusens> so if your patch is a `sed` so be it
<Son_Goku> right
<ogra_> *Makefiles
<Son_Goku> I didn't know we had a prepare stage :)
<ogra_> thats pretty new
<sergiusens> Makufiles go well with Goku though :-P
<ogra_> haha
<Son_Goku> snapcraft.yml seems to become more like rpm-spec each day :)
<sergiusens> Son_Goku: prepare, build and install
<Son_Goku> that's... exactly how it works in rpm-spec
<Son_Goku> %prep, %build, %install
<sergiusens> Son_Goku: https://snapcraft.io/docs/build-snaps/scriptlets
<Son_Goku> they're even called the same thing :)
<Son_Goku> did you read some rpm docs before you implemented that :P
<ogra_> just to make you feel at home ... we thought of you specifically ;)
<BadCodSmell> versus debs
<BadCodSmell> rpms are far far easier
<sergiusens> build just might do something different than what you might expect ;-)
<BadCodSmell> the deb format is tremendously bloated in comparison
<Son_Goku> BadCodSmell: I totally agree
<BadCodSmell> first time I downloaded the skeleton after rolling rpms for years I almost died
<Son_Goku> which is why I now build my debs using rpmspec
<Son_Goku> I despise debian source control packaging
<BadCodSmell> there's the patch issue too, they have two systems of patching
<sergiusens> Son_Goku: just alien-ate it :-P
<ogra_> heh
<Son_Goku> sergiusens: actually, I do something far worse (in debian folks' eyes)
<sergiusens> anyways, need to go and drop off my son at daycare, bbiab
<ogra_> is alien still a thing ?
<Son_Goku> it is, but deadish
<sergiusens> it is on slackware :-)
<ogra_> yeah, upstream developmennt stalled years ago
<Son_Goku> I generate native debian packages with rpmspec using debbuild: https://github.com/ascherer/debbuild
<Son_Goku> I've even written macros that replace useful aspects of debhelper
<ogra_> thats probably fine as long as you dont actually upload to an archive
<ogra_> s/archive/official archive/
<Son_Goku> nah, Debian people hate me anyway
<Son_Goku> at least, that's what it was like the last time I tried to get involved there
<ogra_> the big advantage of debs over rpms is not ease of packaging but strickt packaging policy ...
<Son_Goku> the strict policy *does* exist in some distributions
<Son_Goku> Mageia has always had Debian-like strictness in its policies
<ogra_> its a hrd req. to upload something to an official archive
<Son_Goku> well, likewise for Mageia
<ogra_> and its a pain to learn the debian policy ... which is a req. to become a debian/ubuntu developer
<Son_Goku> core, tainted, nonfree sections for Mageia mirror those of Debian (main, contrib, nonfree)
<Son_Goku> ogra_, sadly, I know Debian Policy well, but it took years to figure it out
<ogra_> but after all having upload rights gives you root access on all users boxes ... in both cases, rpm and deb
<Son_Goku> right
<ogra_> unlike snaps ;)
<ogra_> thats the beauty about them :)
<Son_Goku> that's why Mageia has a mentorship program to ensure people do things right: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager and Debian has the whole Uploaders->Maintainers->Developers thing
<Son_Goku> ogra_, well, there's a trade-off there
<ogra_> yeah, same thing as debian or ubuntu have
<Son_Goku> you pay a price for having confined applications
<ogra_> indeed
<ogra_> but its just a matter of getting used to
<Son_Goku> yes
<Son_Goku> though interestingly, it has come up before to have something like this in rpm itself, too
<Son_Goku> it's just tricky because people *expect* systemwide access
<Son_Goku> breaking that expectation is hard
<ogra_> thats why we have interfaces now ...
<ogra_> it wasnt always like that :)
<ogra_> but you know that
<Son_Goku> yep
<Son_Goku> I was there for some of the planning sessions :)
<ogra_> :)
<Son_Goku> I suspect that the first distribution I'll manage to get snappy *fully* working on will be Mageia
<BLu2> Can the libreoffice snap access my documents folder?
<Son_Goku> because the community is already leaning towards AppArmor as a MAC (as it's better oriented for desktop user focus)
<Son_Goku> but everything is on ice until multi-dist base/core snaps are possible
<Son_Goku> and once sergiusens does the thing with the making the repo engine pluggable, I can add a DNF backend for RPM based distros (including Mageia)
<Son_Goku> for snapcraft
<ogra_> BLu2, afaik it should ... you might need to connect the home interface if it isnt connected though
<BLu2> ogra_, I'm using symlink to another HDD for most Home folders
<BLu2> would that still be an issue?
<ogra_> ah, that might be a problem ... ask SweetShark in #ubuntu-desktop ...
<ogra_> he maintains the snap
<ogra_> (and is LibreOffice upstream)
<BLu2> but it seems to be more of a snap "issue" in my case
<ogra_> yes, he manages the snap ... he will know if there is a bug open for that etc
<simosx> Just tried the stable Libreoffice snap and it appears that "Gtk-Message: Failed to load module "unity-gtk-module". The snap in the "edge" channel the other day was OK. Can someone do "snap install libreoffice", then run from the terminal "libreoffice.writer"? It should not complain about modules failing to load.
<ogra_> simosx, there is Sweet5hark
<willcooke> Sweet5hark, error is " "Gtk-Message: Failed to load module "unity-gtk-module"."  (via simosx)
<willcooke> wasnt like that from edge the other day
<Sweet5hark> Failed to load module "unity-gtk-module" -- is usually harmless, does libreoffice start then?
<simosx> Sweet5hark, libreoffice does start, but it gets lots of issues with the menus. Some menu items are missing, etc.
<simosx> I am running snap/snapd 2.12 (Ubuntu 16.04).
<Sweet5hark> simosx: the message is unrelated. missing menus is unrelated to that, and not reproducable here. What host system are you on?
<ogra_> 2.12 ?!??
<simosx> Sorry, 2.21 version.
<ogra_> ah :)
<simosx> On Ubuntu 16.04 (all updates).
<Sweet5hark> simosx: hmm, same host here. which menu are you missing exactly.
<simosx> I did several installs and uninstalls of the snap earlier today while updating https://blog.simos.info/how-to-install-libreoffice-5-3-on-ubuntu-16-04-from-snap/ . I wonder whether I need to reboot.
<simosx> Here are the startup errors, https://paste.ubuntu.com/23918221/
<simosx> I'll reboot just to be on the safe side. brb.
<Sweet5hark> simosx: All those messages are seen here too, but not critical, as I see no problem here. so likely unrelated.
<ogra_> you should wait til he returns ;)
<simosx> Sweet5hark, The issue still persists. I still get https://paste.ubuntu.com/23918221/
<Sweet5hark> (15:09:58) Sweet5hark: simosx: All those messages are seen here too, but not critical, as I see no problem here. so likely unrelated.
<Sweet5hark> simosx:  whichs menu are you missing exactly?
<simosx> okay, will make screenshot of menus. when I move the mouse through the menu items, those menu items appear.
<mup> PR snapcraft#1102 closed: cleanbuild: include snap directory in tarball <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1102>
<simosx> Sweet5hark, hmm, something is wrong with my desktop. In the Ubuntu Settings, some textboxes are not showing.
<simosx> Will need to make sure that no PPA leftovers are installed, then come back to you.
<simosx> Sweet5hark, can you check the update at https://blog.simos.info/how-to-install-libreoffice-5-3-on-ubuntu-16-04-from-snap/ There are two usability issues, and those happen with snap/snapd 2.21 (Ubuntu 16.04 default snap version).
<ogra_> simosx, what graphics card ?
<simosx> ogra_, Intel(R) HD Graphics Haswell GT2 Desktop
<ogra_> perhaps a driver issue ?
<Sweet5hark> simosx: updates look good to me (not too much an expert on how the snap commands are supposed to be used, for that stuff Im just a user like everyone else ;) )
<simosx> ogra_, I had the Intel drivers from 01.org and uninstalled recently per https://blog.simos.info/how-to-completely-remove-a-third-party-repository-from-ubuntu/ I noticed leftovers.
<simosx> Sweet5hark, if you type "snap info libreoffice", do you get every time a different order for the commands? This probably affected Ubuntu Software, because if you click "Launch" in Ubuntu Software for LibreOffice, you get everytime a different LibreOffice programm starting up.
<simosx> ogra_, the intel driver package from 01.org would install their own libcairo packages.
<simosx> $ apt policy libcairo-gobject2
<simosx> libcairo-gobject2:
<simosx>   Installed: 1.15.2-0intel1
<ogra_> lovely
<mup> Bug #1661626 opened: GSettings/dconf reports incorrect values on setting change under confinement <Snappy:New> <https://launchpad.net/bugs/1661626>
<mup> PR snapd#2785 closed: Provide a more interesting pitch for upstream developers using snaps <Created by evandandrea> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2785>
<mup> PR snapd#2736 closed: Initial unity8 interface <Created by mikix> <Closed by mikix> <https://github.com/snapcore/snapd/pull/2736>
<mup> PR snapd#2786 opened: Initial unity8 interface <Created by mikix> <https://github.com/snapcore/snapd/pull/2786>
<mup> PR snapd#2787 opened: Add unity8 plug permissions <Created by mikix> <https://github.com/snapcore/snapd/pull/2787>
<simosx> I managed to narrow down the issue with menus I had earlier. It was not specific to snaps.
<simosx> The offending package appears to be light-themes. I have this leftover version:
<simosx> $ apt policy light-themes
<simosx> light-themes:
<simosx>   Installed: 16.10+16.04.20161205-0ubuntu1
<simosx> It does not downgrade, because  unable to open '/usr/share/themes/Ambiance/gtk-3.0/assets/backdrop-button-toolbar.png.dpkg-new': No such file or directory
<flexiondotorg> sergiusens Is there an ETA for snapcraft on 14.40?
<flexiondotorg> I've got an ISV with their CI on 14.04 and snapcraft would help seal the deal :-)
<simosx> From the three provided themes in Ubuntu 16.04, this weird version of light-themes affects Ambience and Radiance. A workaround was to enable "High contrast" for now.
<mup> PR snapd#2788 opened: store,osutil: use new osutil.ExecutableExists(exe) check to only use deltas if xdelta3 is present <Created by chipaca> <https://github.com/snapcore/snapd/pull/2788>
<cjwatson> sergiusens: snap/snapcraft.yaml support deployed on Launchpad production now
<mup> PR snapd#2789 opened: overlord/devicestate: backoff between retries if the server seems to have refused the serial-request <Created by pedronis> <https://github.com/snapcore/snapd/pull/2789>
<stokachu> cjwatson, \o/
<stokachu> balloons, ^
<balloons> stokachu, what's this?
<stokachu> <cjwatson> sergiusens: snap/snapcraft.yaml support deployed on Launchpad production now
<mup> PR snapcraft#1079 closed: Add snapcraft plugin for Qt Build Suite (qbs) <Created by dpniel> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1079>
<balloons> do we know who might be able to change the owner of a snap in the store?
<balloons> basically I want to move my snap to a different ubuntu one account
<mup> PR snapcraft#1104 closed: repo: refactor into package <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1104>
<Zap12344> Hello. What is the best place to ask help packaging an application? Here or the mailing list?
<kyrofa> Zap12344, either works!
<popey> if using shell snippets to do configure / make / make install, what would you set --prefix to, so that it doesn't try to write to / during make install?
<popey> balloons: ness ita  can
<balloons> popey, thank you. Not sure if nessita is around; if not I'll poke later
<Zap12344> Ok so, since the new snapcraft allowed mixed architecture I tried to build a snap for pcsx2 (just for "fun").  The compilation is successful and all runtime dependencies seems satisfied, but it segfault.  log: https://drive.google.com/open?id=0B-kthB5RpM8kOFBsak5mU0NHRzg | snap: https://drive.google.com/open?id=0B-kthB5RpM8kNHZ3LU1JVTNxUFk  | snapcraft.yaml : https://drive.google.com/file/d/0B-kthB5RpM8kZk5wbzEyOEVRMFk/view?usp=shari
<popey> Zap12344: might be easier to build in an i386 vm or in a real i386 builder in launchpad tbh
<Zap12344> I tried in a i386 lxc container but then I'm not able to install it because it's not an x86_64 snap, anyway the compilation works just fine, but it's probably dangerous to compile it since it will mess up with a lot of libraries
<kyrofa> Zap12344, you might be able to get away with specifying `architectures: [amd64, i386]` in the snapcraft.yaml
<Zap12344> thanks kyrofa, I will try that. Anyway Pcsx2 supports a multiarch build, I managed to compile it as a snap, and now that is possible to specify the architecture of the stage-packages everything build nicely. But it seems there are problem finding the locale and libpangoxft segfault.
<kyrofa> Yeah I got nothing on the segfault... would require some strace and gdb sessions, likely
<popey> kyrofa: any idea about my question? :)
<kyrofa> popey, I missed your question, so sorry!
<popey> np
<kyrofa> popey, you're referring to scriptlets?
<popey> yes
<kyrofa> popey, that depends. You can install with DESTDIR set to $SNAPCRAFT_PART_INSTALL
<popey> ahh, of course
<kyrofa> In that case, prefix is usually appended to it
<kyrofa> So / is okay
<kyrofa> Some build systems don't work quite that way though, and ignore DESTDIR (or similar variables)
<popey> if i dont specify prefix in configure then it tries to install to the normal place /usr/share etc
<kyrofa> popey, so in that case you can straight-up use $SNAPCRAFT_PART_INSTALL as the prefix and just `make install` with no DESTDIR
<popey> I'll try setting DESTDIR
<popey> ah okay
<popey> thanks
<kyrofa> popey, either of those options are good ones, perhaps try DESTDIR first, if that doesn't work, try the prefix
<Zap12344> kyrofa, I thought so, I guess I'll try compiling it in a i386 vm first to see if something change.
<kyrofa> popey, for example, PHP ignores DESTDIR, so it must be installed by prefix
<kyrofa> popey, that's actually the whole story behind the autotools plugin supporting `install-via`
<davmor2> popey: you having fun with snaps again?
<popey> always
<popey> kyrofa: that worked, thanks
<kyrofa> popey, any time :)
<mup> PR snapcraft#1100 closed: repo: remove symlinks to libc <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1100>
<cory_fu> If I'm looking for where to file bugs or contribute to a particular snap in the store, how can I find that info?
<kyrofa> cory_fu, great question
<kyrofa> cory_fu, see https://bugs.launchpad.net/snappy/+bug/1624829
<mup> Bug #1624829: There is no way to contact snap package developer <store> <Snapcraft:Confirmed> <Snappy:In Progress> <Software Center Agent:New> <https://launchpad.net/bugs/1624829>
<kyrofa> cory_fu, the only way I know of is to use uappexplorer, where it actually shows the store details
<kyrofa> cory_fu, for example, you can see the support URL for nextcloud: https://uappexplorer.com/app/nextcloud.nextcloud
<cory_fu> kyrofa: I'd also like to note that I can never find that site, because it doesn't show up when I search for "snap store" or similar
<kyrofa> cory_fu, it's a third-party site, not official
<cory_fu> Oh
<cory_fu> Is there any official way to browse snaps on the web?
<kyrofa> Not that I know of
<cory_fu> Any particular reason for that?
<kyrofa> No, no idea. Would sure be nice
<cory_fu> Yeah it would
<kyrofa> But in this case, I'd settle for `snap info` showing me some more info
<cory_fu> kyrofa: So, I'm specifically trying to find the repo for the juju-act snap, but that doesn't come up for me on uapp explorer
<kyrofa> cory_fu, is it in the stable channel?
<cory_fu> kyrofa: Yeah.  But it is a classic snap
<kyrofa> Oh, uappexplorer may not support that yet... no idea
<cory_fu> kyrofa: How does that third-party site get access to the info that it displays?  Is there some way I can recreate the proper query?
<kyrofa> cory_fu, using this I believe: http://search.apps.ubuntu.com/docs/
<kyrofa> cory_fu, and yeah, you might have some luck with curl
<cory_fu> kyrofa: Thanks
<johanhenselmans> I tried the beaglebone black core image from http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/, got it running, added my (admittedly rather old 2001) DSA key to login.ubuntu and tried to login via SSH. The machine comes up with the message I should use that key, but it still refuses it. Anyone else that experience?
<kyrofa> johanhenselmans, I seem to remember rsa only being supported
<cory_fu> kyrofa: I'm having some trouble pushing my first snap to the store.  From the CLI, I get http://pastebin.ubuntu.com/23921229/ but I also set up a LP project for it and most of the builds failed: https://code.launchpad.net/~johnsca/+snap/juju-crashdump
<kyrofa> cory_fu, if you login to the store, you can see the logs from the review tools
<kyrofa> cory_fu, mind sharing the snapcraft.yaml? I might be able to spot issues
<cory_fu> kyrofa: https://github.com/juju/juju-crashdump/blob/master/snapcraft.yaml
<kyrofa> cory_fu, first of all, classic snaps currently don't build on LP. We're working on it
<cory_fu> Ah, ok
<cory_fu> kyrofa: It looks like the other error is just from it pending manual review.
<kyrofa> Other than that, I don't see anything obviously wrong here, so you'll need to check the store for the output of the review tools
<kyrofa> Oh. Does classic require manual review, then?
<cory_fu> Apparently so.  And the first time I did a push, it told me that.  But the second push (with --release candidate) gave me an unhelpful error
<cory_fu> Anyway, happy to wait on manual review.  It's quittin' time anyway.  :)
#snappy 2017-02-04
<mup> PR snapd#2777 closed: cmd: fix autogen.sh on fedora <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2777>
<VatamanuVD> hy :)
<VatamanuVD> is someone ho can help me a little ?
<VatamanuVD> i need some help please
<oky> VatamanuVD: just ask your question
<VatamanuVD> i i have an error but i dont know why :/
<VatamanuVD> vatamanuvd@vatamanuvd-Lenovo-ideapad-100-15IBY:~$ sudo classic mount: devpts is already mounted or /dev/pts busy        devpts is already mounted on /dev/pts sudo: unknown user: vatamanuvd sudo: unable to initialize policy plugin vatamanuvd@vatamanuvd-Lenovo-ideapad-100-15IBY:~$
<VatamanuVD> that is happen when i want to do sudo classic
<VatamanuVD> i want to try a ubuntu tutorial, im a novice :/
<oky> VatamanuVD: now you might have to wait a bit for people to respond
<mup> PR snapcraft#1105 opened: tests: rename the integration test snaps <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1105>
#snappy 2017-02-05
<paradisaeidae_> Is there somewhere where there is info on migrating from using apt-get to snap? When I have previously installed with apt?
<lutostag> paradisaeidae_: not sure quite what you are looking for... they are two separate ways to install software. They can be used together on the same system if you'd like
<lutostag> paradisaeidae_: are you on ubuntu core? Or just looking at how to install snaps in general?
<paradisaeidae_> I've just done a 'snap install inkscape' on Lub:16.04:E20... then apt-get riove inkscape, now bash does not find inkscape binary
<paradisaeidae_> ....apt-get remove inkscape...
<lutostag> theoretically that should work... I didn't know inkscape was snapped, I'll try on my end and see if I hit anything myself. Gimme just a sec
<lutostag> paradisaeidae_: works for me -- I didnt uninstall my apt-version of inkscape
<lutostag> paradisaeidae_: for me I have a binary in /snap/bin/inkscape
<paradisaeidae_> thX! Looks like the apt-get install snap did not add the /snap/bin to $PATH
<lutostag> paradisaeidae_: cool, yeah, I have /etc/profile.d/apps-bin-path.sh on my system that does it for me
<paradisaeidae_> ok, so how does the command execute? I get ~/snap/inkscape/1880: Bad file descriptor
<paradisaeidae_> When invoking the sof t link: /snap/bin/inkscape
<lutostag> yeah, that's all I have to do...
<paradisaeidae_> What's in your /etc/profile.d/apps-bin-path.sh?
<lutostag> paradisaeidae_: do you have a directory at ~/snap/inkscape/1880 ? I do, which was installed by the snap install command
<lutostag> paradisaeidae_: http://pastebin.com/QDzTxPVv
<lutostag> paradisaeidae_: out of curiosity, what distro are you on?
<paradisaeidae_> I'm on Lubuntu 16.04 with E-0.21
<paradisaeidae_> I do, but it is empty. Just did PATH=$PATH:/snap/bin at cli.
<paradisaeidae_> Now I see cannot create user data directory: ~/snap/inkscape/1880: Bad file descriptor
<lutostag> hmm... curious indeed
<lutostag> if you do an $ ls -ld ~/snap/inkscape/1880 #is it just a regular dir owned by your user (non-root)?
<paradisaeidae_> Looks like it: drwxr-xr-x 2
<lutostag> and looks like that directory was created on first run of /snap/bin/inkscape ... rather than on installation as I first said
<paradisaeidae_> yep
<lutostag> paradisaeidae_: same here
<paradisaeidae_> # /snap/inkscape/1880/bin/inkscape files are root.root
<lutostag> same again
<lutostag> tedg_: is the maintainer of that snap looks like, he might be able to help further
<paradisaeidae_> When I try to run it: /snap/inkscape/1880/bin/inkscape: error while loading shared libraries: libpotrace.so.0: cannot open shared object file: No such file or directory
<lutostag> paradisaeidae_: I've got a different one, but similar "/snap/inkscape/1880/bin/inkscape: error while loading shared libraries: libpoppler.so.58: cannot open shared object file: No such file or directory"
<lutostag> paradisaeidae_: which is probably because the snap wrapper sets the library directories correctly along with a bunch of other stuff
<paradisaeidae_> OK, thanks again. It's possibly a packaging thing. I'm sure it will get sorted.
<lutostag> paradisaeidae_: well you got me using the inkscape snap now at least, so thanks :)
<lutostag> (althought not quite what you were hoping I'm sure :/)
<paradisaeidae_> yep, good result there. It is an oarsome proggy.
<paradisaeidae_> Does Inkscape run at all for you?
<lutostag> paradisaeidae_: yep, both do -- side-by-side even https://imgur.com/a/QJamv
<lutostag> kinda neat
<paradisaeidae_> Yes, hmmm. Was hoping to see that here. Will get it going sometme.
<paradisaeidae_> Have to break for the day. Monster warm here in SYD. Sleep on beach evening. Cya!
<lutostag> yeah, this channel is a little quiet at the moment, if you stick around and try again later, I'm sure someone with more knowledge will figure it out for us
<lutostag> paradisaeidae_: feel free to make a https://askubuntu.com/ too, have a good one!
<paradisaeidae_> Ciao!
<zap12344> Hello. I managed to build a working snap package for pcsx2 https://drive.google.com/drive/folders/0B-kthB5RpM8kb0h2eGpoRllWZDA I had to compile it in a 32bit vm and made a small edit in the desktop-gtk launcher. There are some problems, but when using sdl audio output the emulator works. It doesn't work with nVidia driver and it doesn't found automatically the configuration paths
<mcphail> zap12344: the nvidia driver thing is a pain. You can probably work around it by dumping the needed files in the snap. I had to do that for a dosbox snap
<zap12344> macphail: my intuition is that snapd only exports the 64 bit nVidia driver and this snap is a 32bit software running on a 64bit architecture. what files did you put in the snap?
<mup> PR snapd#2790 opened: Add a check for an empty argv in snap-confine.c <Created by eriksjolund> <https://github.com/snapcore/snapd/pull/2790>
<mcphail> zap12344: ages since I made the snap, but this is the contents of my lib directory: http://termbin.com/4ct6
<mcphail> zap12344: I had to keep adding various bits of mesa etc until it "worked". Never quite sure why it worked, though. Some of it was copies from the qt snaps which were around at the time
<zap12344> mcphail: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L26 they added this bit if you use a launcher to use nVidia driver, but in my case since I need the 32bit version I'm out of luck
<mup> PR # closed: snapd#2230, snapd#2236, snapd#2251, snapd#2302, snapd#2421, snapd#2475, snapd#2477, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2558, snapd#2570, snapd#2588, snapd#2592, snapd#2604, snapd#2624, snapd#2626, snapd#2644, snapd#2654, snapd#2677, snapd#2680, snapd#2707,
<mup> snapd#2714, snapd#2718, snapd#2723, snapd#2737, snapd#2746, snapd#2747, snapd#2749, snapd#2750, snapd#2752, snapd#2754, snapd#2757, snapd#2760, snapd#2761, snapd#2763, snapd#2764, snapd#2766, snapd#2768, snapd#2769, snapd#2770, snapd#2771, snapd#2772, snapd#2773, snapd#2774, snapd#2775, snapd#2776,
<mup> snapd#2778, snapd#2779, snapd#2780, snapd#2782, snapd#2783, snapd#2784, snapd#2786, snapd#2787, snapd#2788, snapd#2789, snapd#2790
<mup> PR # opened: snapd#2230, snapd#2236, snapd#2251, snapd#2302, snapd#2421, snapd#2475, snapd#2477, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2558, snapd#2570, snapd#2588, snapd#2592, snapd#2604, snapd#2624, snapd#2626, snapd#2644, snapd#2654, snapd#2677, snapd#2680, snapd#2707,
<mup> snapd#2714, snapd#2718, snapd#2723, snapd#2737, snapd#2746, snapd#2747, snapd#2749, snapd#2750, snapd#2752, snapd#2754, snapd#2757, snapd#2760, snapd#2761, snapd#2763, snapd#2764, snapd#2766, snapd#2768, snapd#2769, snapd#2770, snapd#2771, snapd#2772, snapd#2773, snapd#2774, snapd#2775, snapd#2776,
<mup> snapd#2778, snapd#2779, snapd#2780, snapd#2782, snapd#2783, snapd#2784, snapd#2786, snapd#2787, snapd#2788, snapd#2789, snapd#2790
<AleksandrG> hey guys, does anybody have issues with running a command for a snap in try mode?
<AleksandrG> it always fails with a message like this:
<AleksandrG> cannot snap-exec: cannot read info for "hello-world-desktop": stat /var/lib/snapd/snaps/hello-world-desktop_x1.snap: no such file or directory
<zyga> hi
<zyga> hmm
<zyga> that's odd
<zyga> can you please tell me which version of snapd are you using (snap version)
<shuduo> mwhudson: hi
<zyga> AleksandrG: ^
<zyga> also if this is on the recent version, can you please report it at launchpad.net/snapd
<zyga> shuduo: mwhudson is in a timezone far-far away, maybe I can help you?
<AleksandrG> just a sec..
<shuduo> zyga: hi, i'm investigating why mwhudson's go snap can't be execute on my side. https://lists.ubuntu.com/archives/snapcraft/2017-February/002950.html now i think i found the problem is /snap/core is not exist on my machine. after i link /snap/ubuntu-core to /snap/core it works now. i wonder when /snap/core be generated. thanks. :)
<AleksandrG> snap    2.21+16.10 snapd   2.21+16.10 series  16 ubuntu  16.10
<zyga> shuduo: I see,
<zyga> shuduo: snapd 2.22 hadnles the transition form ubuntu-core to core automatically
<zyga> shuduo: you can probably switch to the candidate channel (of ubuntu-core)
<zyga> shuduo: to have that happen
<zyga> shuduo: just remove the symlink :-)
<AleksandrG> zyga: is this the bug that causes snap-exec error? https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1631270
<mup> Bug #1631270: running a command for a snap in try mode fails on trusty <trusty> <Snappy Launcher:Invalid> <Snappy:Fix Released by thomas-voss> <snap-confine (Ubuntu):Invalid> <https://launchpad.net/bugs/1631270>
<zyga> AleksandrG: no, that is unique to 14.04
<shuduo> zyga: good to know that root cause. could you please point me what's best way to swtich to candidate?
<zyga> AleksandrG: and systemd / upstart and how they change sharing of /
<zyga> shuduo: sudo snap refresh ubuntu-core --candidate
<zyga> shuduo: then wait for a sec (observe snap changes)
<shuduo> zyga: oh got it. i thought i should switch everything to another channel.. thanks. :)
<AleksandrG> so if I install snapd 2.22, the error should be gone, right?
<AleksandrG> nevermind, I'll try 2.22 and will see. Thanks for the help!
<shuduo> zyga: seems candidate's ubuntu-core still use /snap/ubuntu-core. i even refresh latest version from edge channel.
<shuduo> zyga: seems candidate's ubuntu-core still use /snap/ubuntu-core. i even refresh latest version from edge channel now it works.
<shuduo> zyga: i tried candidate's ubuntu-core on 1610. it works to transition to core as expected. thanks.
<mup> Bug #1661966 opened: snapd should also have a 32bit nVidia mount point  <32bit> <i386> <nvidia> <snap-confine> <Snappy:New> <https://launchpad.net/bugs/1661966>
<thresh> so.. how does versioning in ubuntu store workds?
<thresh> works
<thresh> right now I have the version, ahem, "daily" for VLC
<thresh> I would like to move to something like 3.0.0-$date, maybe followed by 3.0.0-release when the release version is there
<thresh> is it the same as in dpkg?
<thresh> can I just bump the version the way I want, and it will automagically be updated for the end users?
<thresh> sorry for asking noob questions, I'm still the old fart using apt :-)
<palasso> thresh: every time you make a new snap a counter increases. There's also a version field but that's not related to updating, it's there to give context to a human person
<palasso> thresh: I mean every time you publish a new snap for your application
<palasso> thresh: Revision is the counter being updated. Every new snap you upload increases revision by one. The version field can be anything
<palasso> thresh: there's also a thing called channels. There's stable, candidate, beta and edge. You can upload snaps on each channel depending on how stable they are. For example nightly releases could be in the edge channel, beta releases in the beta channel, RC releases in the candidate channel and stable releases in the stable channel
<thresh> thank you palasso, it is now very clear
<oky> can someone point me to the list of available snaps? i'm trying to determine how to name the snap i am creating
<oky> (snap find times out for me, on my machine. btw)
<oky> oops, there it goes!
<palasso> oky: https://uappexplorer.com/apps?type=snappy
<oky> perfect, thanks palasso
<oky> i'm trying out 'snapcraft cleanbuild', but the network is not getting attached to the lxc container
<oky> i'm googling around, looking for troubleshooting tipcs, etc. any keywords that would help? i'm looking for 'snapcraft lxc network' and 'lxc network', etc.
<oky> ok, i installed dnsmasq, restarted my machine, etc. now cleanbuild can see my network, but it errors saying something like 'missing snapcraft.yaml, did you try to run snapcraft init'
<oky> so far, snapcraft is really cool - i like the idea of containment + wiring up multiple packages together
<oky> i think the issue re: missing snapcraft might be related to this link i found: https://github.com/snapcore/snapcraft/commit/e35826ed401a7ed05a9c2046346307bc3fb76217, bc i noticed that the 'setting up container with project assets' is missing my snap/ dir. i will wait for next release of snapcraft, i think
<swluo> hello?
<swluo> anyone here?
#snappy 2018-01-29
<bashfulrobot> Is there a way to utilizr a bz2 file in the source directive?
<bashfulrobot> utilize*
<bashfulrobot> I'm working on a snap for restic in which the author prefers that the snap use the "official" binary (hope to change that later). But his releases come out as a bz2 file. When targeting the file I get an error stating that there is no handler for the bz2 file.
<bashfulrobot> I'm in the middle of working on it - so was hoping for a quick ping type answer, otherwise I will move this over to the forum.
<bashfulrobot> Thanks all.
<Son_Goku> bashfulrobot: atm, there's no bz2 support in snapcraft, iirc
<Son_Goku> debian doesn't generally encounter bz2 that much anymore, so I would guess they didn't think about it
<bashfulrobot> Son_Goku: thanks for the info. I had pretty much came to that same answer. I guess I'll have to figure out the best way to maybe wget the file in the build, and extract, then just use `organize` to getit where it needs to go.
<mborzecki> morning
<Son_Goku> morning
 * Son_Goku needs to sleep
<Son_Goku> anyway, if anyone sees robert-ancell, can someone poke him about this? https://github.com/snapcore/snapd-glib/issues/32
<zyga-ubuntu> o/
<mborzecki> Son_Goku: zyga-ubuntu: morning guys
<zyga-ubuntu> hey, good morning
<zyga-ubuntu> uefi greeted me today with "ubuntu (disk not present)"
<zyga-ubuntu> I think this is not a happy day
 * zyga-ubuntu boots from usb and hopes the disk isn't dead yet
<mborzecki> zyga-ubuntu: whad did you do? another dead disk?
<zyga-ubuntu> mborzecki: no, just booted it again today
<zyga-ubuntu> man, I'm not lucky
<zyga-ubuntu> it shows up and mounts from live media
<zyga-ubuntu> drive not present...
<mborzecki> sounds like bad news
<bashfulrobot> Hey guys (morning to those of you in Europte, etc)
<bashfulrobot> I have a snap that I'm getting ready for snapcrafters.
<bashfulrobot> It is going to need classic confinment as it is a backup program.
<bashfulrobot> Going through the checklist it states "Convert the snap to `strict` confinement, or `classic` confinement if it qualifies". Is there some sort of qualifier process to allow a classic confiment for hte store?
<bashfulrobot> And then a few lines down it states to move it into beta once it has been made either strict or classic. Do others generally just do locally testing in devmode nad hten call the comminuity in for review?
<bashfulrobot> once in the beta channel?
 * bashfulrobot getting sleepy - almost bed time.
<zyga-ubuntu> bashfulrobot: hey
<bashfulrobot> hello
<zyga-ubuntu> bashfulrobot: you can request classic confinement on the forum (forum.snapcraft.io), there is a process to follow there
<bashfulrobot> I'll search it up then.
<zyga-ubuntu> bashfulrobot: if you can become a strictly confined snap it is much easier, obviously, but for a backup program it may be challenging, depending on the use-cases
<zyga-ubuntu> bashfulrobot: you can test in classic mode as well, though devmode and classic are quite different
<bashfulrobot> Well basically you need ot be able to backup any location on the file system
<bashfulrobot> I was under the impression classic was the onbly way to do that
<zyga-ubuntu> backup and restore, which is read and write anywhere
<zyga-ubuntu> yes, I think so
<bashfulrobot> exactly
<zyga-ubuntu> you *can* do that in devmode
<zyga-ubuntu> but it's more tricky
<bashfulrobot> ok, I'm going to apply for classic then
<zyga-ubuntu> and there's no interface for backup programs yet
<bashfulrobot> ah ok.
<zyga-ubuntu> sorry for brief answers, I think monday doesn't like me (my computer is not working)
<bashfulrobot> hey - nooo worries
<bashfulrobot> It's almost 11 pm Sunday for me... so my brain is giving up on me. :-)
<zyga-ubuntu> "logical sector size is zero"
<zyga-ubuntu> my ESP partition is broken
<zyga-ubuntu> ok, that's it
<zyga-ubuntu> I'm turning this machine off and I'll go and buy a new computer today
<zyga-ubuntu> I'm so so so fed up with it
<zyga-ubuntu> bashfulrobot: enjoy your evening and thank you for making snaps!
<bashfulrobot> no worries! Last questoin - I see that the requests for classic seem to be in the store category. I'll put my request in there. Appreciate the direction!
<bashfulrobot> zyga-ubuntu: hope the day gets better!
<zyga-ubuntu> yes, the store category is right
<zyga-ubuntu> good mornin mvo
<mvo> hey zyga-ubuntu - good monring
<mvo> morning even
<mvo> zyga-ubuntu: shall we continue with this systemd shared unit today?
<bashfulrobot> zyga-ubuntu: appreciate the help. Classic has been requested. Have a good day. I'm off to bed.
 * bashfulrobot zzzzzzz
<zyga-ubuntu> mvo: yes, let's do that; though please forgive me for being grumpy today as my computer has a broken ESP partition and I'm on the backup laptop without my work
<zyga-ubuntu> mvo: I'm throwing the towel on my desktop today
<mvo> zyga-ubuntu: "esp"?
<mvo> zyga-ubuntu: sorry to hear that things are broken :(
<zyga-ubuntu> mvo: the system boot partiotion on efi systems
<mvo> zyga-ubuntu: ohhh, ok
<zyga-ubuntu> my disks are failing on me :(
<mvo> zyga-ubuntu: get ssds :P
<zyga-ubuntu> I can boot the live media but I cannot boot the disk anymore
<mvo> zyga-ubuntu: when they fail, they fail faaaaster
<zyga-ubuntu> mvo: yeah, I'm considering just getting out and going to buy a new computer now
<zyga-ubuntu> hahaha
<mup> PR snapd#4558 opened: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>
<mborzecki> mvo: morning
<mborzecki> zyga-ubuntu: get intel ssds, they got crazy 5y warranty
<mborzecki> already had 2 disks replaced under warranty :) not a single complaint
<mvo> mborzecki: goooood morning
<mborzecki> yocto segfault thing, i can reproduce it on 2.31 too
<mborzecki> a simple fix that resolves/masks the problem is moving progress bar Finished() call in store dowload to happen after checking the errors
<mborzecki> good run log with breadcrumbs; https://paste.ubuntu.com/26482312/
<mborzecki> otherwise the crash looks like this: https://paste.ubuntu.com/26482304/
<mborzecki> 2018/01/29 07:16:11.641340 progress.go:71: progress adapter--- &{task:0x967d8780 unlocked:true label:core total:8.0797696e+07 current:2.784677e+06}
<mborzecki> 2018/01/29 07:16:11.641850 task.go:248: -- in task 0xb77006fc set progress, state 0xe3f
<mborzecki> these 2 lines are interesting, the first one is pbar.Finished() in store.go, the second is a call to task.SetProgress() inside pbar.Finished()
<mborzecki> somehow the pointer to the task changed from 0x967d8780 to 0xb77006fc
<zyga-ubuntu> mborzecki: which golang is used on that yocto build?
<mborzecki> 1.9
<zyga-ubuntu> mborzecki: is it a compiler bug maybe?
<zyga-ubuntu> mborzecki: any patches in ubuntu or debian or any patches in yocto that may be relevant?
<mborzecki> update to 1.9.3 is on my list, but the interaction cycle is long
<mborzecki> looked through commits between 1.9 and 1.9.3 nothing that looks relevant
<zyga-ubuntu> mborzecki: do you think this is something in our code?
<mborzecki> not sure yet
<mborzecki> for instance, no clue why we try to do Kill() on the tomb twice, but the same sequence is visible in the 'good' run :/
<mborzecki> albeit in the good run there's no call to pbar.Finished()
<mvo> mborzecki: oh, doing the Kill twice sounds wrong, do you have more info?
<mvo> mborzecki: also no call to Finish sounds wrong :(
<mborzecki> mvo: take a look at the logs i posted
<mborzecki> this is the diiff i'm working with: https://paste.ubuntu.com/26482348/
<mborzecki> mvo: in taskrunner.Ensure() there's a call to tomb.Kill() for the running task
<mborzecki> aiui that kill will trigger cancel on the context
<mvo> mborzecki: interessting
<mvo> mborzecki: I guess I'm stating the obvious, it looks like task.state is corrupted, might be interessting (no idea how painful it is to do one of those runs) to output the value of the task.state pointer to see when it becomes invalid
<kalikiana> morning snappy
<zyga-ubuntu> hey kalikiana
<mborzecki> kalikiana: morning
<mborzecki> zyga-ubuntu: mvo: forcing a static build of snapd makes the problem go away https://paste.ubuntu.com/26482426/
<mvo> mborzecki: oh, this is also interessting. how dynmaic is the dynamic build? i.e. what is linked?
<zyga-ubuntu> hmm ...
<mborzecki> mvo: nothing special, libc and  libstd (that's go)
<pstolowski> good morning!
<mborzecki> pstolowski: morning
<zyga-ubuntu> mborzecki: I wonder if that would fail if you used a ubuntu-build of snapd
<mborzecki> btw. also according to the forum post the problem is only on x86, does not appear on x86-64
<zyga-ubuntu> mborzecki: I read about some peculiar crash of golang when gentoo used new kernel optimization flag and broke the vsdo
<mborzecki> i've tried rebuilding snapd locally, with same flags but no success
<zyga-ubuntu> mborzecki: that was a golang bug, assuming too much about kernel behavior
<mborzecki> i mean, GOARCH=386 GO386=387 CGO_ENABLED={0,1} all worked fine when deployed to the vm
<mborzecki> hoped to use -race but it's 386 ;) so no race for me
<zyga-ubuntu> mborzecki: can you try a i386 kernel from ubuntu there?
<zyga-ubuntu> and see if the same binary of snapd tests wokrs
<zyga-ubuntu> *works
<zyga-ubuntu> just a long shot but somethig that could help bisect the area that is broken
<mborzecki> zyga-ubuntu: can you take a look at #4558? this is an easy one
<mup> PR #4558: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>
<zyga-ubuntu> yep
<zyga-ubuntu> mborzecki: you could use | there
<zyga-ubuntu> to make it an ordering-only rule
<zyga-ubuntu> mborzecki: just add a | before the new dependency
<zyga-ubuntu> either way +1
<mborzecki> yocto does out of the source builds by default, and this came up there :)
<mborzecki> there's actually a separate class for packages that have broken separation
<mborzecki> zyga-ubuntu: mvo: could you take another look at 4487?
<mvo> mborzecki: sure
<zyga-ubuntu> looking
<mvo> mborzecki: heh, sorry that my suggestion to use "internal" error was wrong
<mvo> mborzecki: looks good to me! zyga-ubuntu can merge once he finished (unless he has more suggestions of course)
<mborzecki> mvo: thanks
<zyga-ubuntu> yes, I'm just re-reading
<zyga-ubuntu> mborzecki: done, have a look please
<zyga-ubuntu> brrr, cold, let me make some more tea
<mborzecki> zyga-ubuntu: thanks, good catch
<zyga-ubuntu> mvo: I'm juming into lxd issue now
<zyga-ubuntu> mvo: I don't have anything to do before 4471 lands
<mvo> zyga-ubuntu: cool I'm working on xdg-settings final touches and then ~rc2
<mvo> zyga-ubuntu: but let me know if I can do anything to help with that, happy to tweak the packaging
<zyga-ubuntu> mvo: land 4471
<mvo> zyga-ubuntu: but my feeling is right now the solution is not clear
<zyga-ubuntu> I think we're wasting time now
<zyga-ubuntu> it's blocking everything related to mount work
<mvo> zyga-ubuntu: don't we need gustavo for this?
<zyga-ubuntu> well, I am waiting
<zyga-ubuntu> I'm just saying it's a bit unreasonable now
<zyga-ubuntu> (that branch hasn't been touched in weeks)
 * mvo nods
<Chipaca> moin moin
<zyga-ubuntu> ho ho
<Chipaca> zyga-ubuntu: http://i.imgur.com/AAGJvD1.png
<mvo> Chipaca: \o/ you made my morning
<Chipaca> mvo: woo!
<Chipaca> mvo: how tho :-)
<mvo> Chipaca: the subway map
<Chipaca> it's rather brilliant, isn't it
<zyga-ubuntu> neat
<mvo> Chipaca: oh yes
<mvo> love it
 * kalikiana going for a short walk, need a little fresh air
<mup> PR snapd#4559 opened: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
 * ikey now unblocks solus sync. :p
<zyga-ubuntu> ikey: <bring on the kraken!>
<ikey> pretty much lol
<ikey> we were gonna sync last night, but i couldnt get the snapd patch (above) working
<ikey> turns out i was missing a comma -_-
<ackk> mvo, hi, it seems base-18/edge is still missing the distro-info csv that the version you gave me a while ago has. any chance you could push that fix?
<zyga-ubuntu> ikey: it's better to miss a comma than to miss the point
<ikey> hah
 * zyga-ubuntu gets back to being reasonable
<niemeyer> zyga-ubuntu: I apologize for the delay. My #1 priority last week was to get our CI in good shape, as that unblocks and improves everybody's daily workflow.
<niemeyer> zyga-ubuntu: This week I should get back to reviews and discussions
<zyga-ubuntu> niemeyer: I understand that, no apologies needed; I think that code is critical enough to warrant the wait
<zyga-ubuntu> niemeyer: I'm trying to get useful in other areas
<zyga-ubuntu> niemeyer: and I think the new spread work is brilliant and we will benefit tremendously mid/long term
<zyga-ubuntu> niemeyer: (and rest of canonical and anyone who uses it as well)
<zyga-ubuntu> I always wished spread either did queueing or do dynamic allocation and now it does
<niemeyer> zyga-ubuntu: I hope the benefit is immediate..
<zyga-ubuntu> niemeyer: it is, I meant that it's not just short term benefit
<niemeyer> zyga-ubuntu: The practical consequence is ~23 minutes runs, and no more limiting on the number of runs, so everybody gets more productive..
<niemeyer> I postponed that for quite a while last year, but now it was getting a bit unreasonable..
<zyga-ubuntu> and less issues hand holiding systems and re-starting failed tests due to overuse
<niemeyer> Anyway, I hope that's now done
<ikey> i dont understand how or why my PR failed
<zyga-ubuntu> ikey: concurrent non-deterministic software that is connected to the internet has that property a lot
<ikey> :D
 * kalikiana re
<zyga-ubuntu> ohh
 * zyga-ubuntu has an insight
<ikey> .ubuntu.com?
<ikey> >_>
<zyga-ubuntu> no, maybe a fix for the bug mvo and me were fighting for a long time
<zyga-ubuntu> mvo: no double mounts!
<mvo> zyga-ubuntu: tell me more!
<zyga-ubuntu> mvo: hold on, just a teaser, let me do more experiments first
 * zyga-ubuntu fiddles thumbs while package builds
<mvo> if I could get a review for 4342 that would be great. its the last bit of polish I would like to get in for ~rc2
<kalikiana> ikey: you drank some punny water this morning? :-P
<ikey> perhaps. :p
<zyga-ubuntu> mvo: still no double mounts, things look good so far, let me do some more and then try a spread run
<mvo> zyga-ubuntu: what is the gist of the alternative idea?
<mvo> zyga-ubuntu: I'm really curious
<zyga-ubuntu> mvo: well, ... it's silly really
<zyga-ubuntu> mvo: one char less than yours probably
<mvo> zyga-ubuntu: hu?
<mvo> zyga-ubuntu: was there a typo in my unit?
<zyga-ubuntu> not really, I don't quite know if you got the double entries because of that
<zyga-ubuntu> so so far so good, I'll try to cause the problem by doing what you initially did to confirm
<mvo> zyga-ubuntu: so this is a mount unit, we still need all the scaffolding ? i.e. write out from snapd.postinst etc?
<zyga-ubuntu> mvo: yes
<mvo> zyga-ubuntu: ok - what does this one look like :) please, I'm really curious
<zyga-ubuntu> mvo: hold on, one test will tell me if this makes sense,
<zyga-ubuntu> hmmmmm
<zyga-ubuntu> mvo: so, no double mounts but now I did what you did
<zyga-ubuntu> unless lxd is doing something magic
<zyga-ubuntu> ok, to be sure I'll just reboot
<zyga-ubuntu> brb
<zyga-ubuntu> mvo: sorry to keep you waiting, I don't want to say "got it" before it really works and I know *why*
<mvo> zyga-ubuntu: no double mounts inside lxd? or no double mounts inside *and* outside of lxd?
<zyga-ubuntu> mvo: so, let me check something, I'm on artful now, the container is xenial
<zyga-ubuntu> mvo: I disabled reexec to test my build easily
<zyga-ubuntu> mvo: (and it works so far)
<zyga-ubuntu> mvo: did you do anything different?
<zyga-ubuntu> mvo: I'll try to remove the package now, wonder if that will crash like it did before
<zyga-ubuntu> but no double mounts, right sharing and snaps can be removed allright
<zyga-ubuntu> so that counts as an improvement
<zyga-ubuntu> now the last bit is packaging
<mvo> zyga-ubuntu: no double mounts outside as well?
<zyga-ubuntu> nope
<zyga-ubuntu> mvo: actually, I didn't run many snaps and now I see that:
<zyga-ubuntu> (though I doubt this is related, probably a bug)
<zyga-ubuntu> ubuntu@experiments:~$ hello
<zyga-ubuntu> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<zyga-ubuntu> but I heard that there was a bug in lxd+apparmor about recently
 * zyga-ubuntu looks at loaded profiles
<zyga-ubuntu> ha
<zyga-ubuntu> indeed
<zyga-ubuntu> only snapd-managed profiles are active
<zyga-ubuntu> we didn't load the profile for snap confine
<zyga-ubuntu> mvo: that's a separate bug manifested if you disable re-exec
<zyga-ubuntu> Jan 29 11:15:49 experiments apparmor[85]:  * Not starting AppArmor in container
<zyga-ubuntu> Jan 29 11:15:49 experiments apparmor[85]:    ...done.
<zyga-ubuntu> jdstrand, stgraber: ^
<zyga-ubuntu> is this reported or am I dreaming things?
<zyga-ubuntu> mvo: once I load snap-confine's profile manually things are ok
<zyga-ubuntu> mvo: also inside process namespace
<zyga-ubuntu> mvo: ok, let me get back and make this into a proper patch I can share with you
<zyga-ubuntu> mvo: and see if I can run the test I wrote a while back against it
<zyga-ubuntu> jdstrand, stgraber: this is with apparmor 2.10.95-0ubuntu2.7
<zyga-ubuntu> mvo: this still makes little sense to me, it works but the difference between your branch seems meaningless
<zyga-ubuntu> hmmm
<zyga-ubuntu> mvo: wow, it even removed the package allright
 * zyga-ubuntu is so confused now
<zyga-ubuntu> mvo: it only printed tihs
<zyga-ubuntu> dpkg: warning: while removing snapd, unable to remove directory '/snap': Device or resource busy - directory may be a mount point?
<zyga-ubuntu> and purged cleanly
<zyga-ubuntu> :-))
 * zyga-ubuntu has a happy monday now
<ikey> zyga-ubuntu, https://www.youtube.com/watch?v=SsmVgoXDq2w :)
<mvo> zyga-ubuntu: did it actually stop your mount unit?
<mvo> zyga-ubuntu: it sounds a bit dubious :)
<mvo> zyga-ubuntu: but I'm keen to see your PR
<zyga-ubuntu> mvo: yes
<mvo> zyga-ubuntu: woah, ok
<zyga-ubuntu> mvo: it's totally clean
<zyga-ubuntu> mvo: it's so weird
<mvo> zyga-ubuntu: looking forward to the diff
<mvo> zyga-ubuntu: I have a small test in my PR that will be fun to test against
<mvo> zyga-ubuntu: by all means, if we have a solution and I will sing and dance and hug you :)
<zyga-ubuntu> me too :)
<zyga-ubuntu> I'll build another package that doesn't involve any hand-holding anymore
<zyga-ubuntu> and re-test
<zyga-ubuntu> and then send a PR
<zyga-ubuntu> and then find and cherry pick those tests we wrote
<ogra_> you're so unromantic !
<zyga-ubuntu> ogra_: ?
<ogra_> <zyga-ubuntu> I'll build another package that doesn't involve any hand-holding anymore
<zyga-ubuntu> but first, my tea has run out
<zyga-ubuntu> mvo: btw I have t otell you
<zyga-ubuntu> haha
<ikey> banning hand holding, and we're coming up to the 14th soon enough
<ikey> sheesh
<zyga-ubuntu> ogra_: but there will be hugging instead
<ogra_> ah !
<zyga-ubuntu> mvo: my favourite tea is in stock again, it is called ...
<ogra_> thats an improvement then :)
<zyga-ubuntu> sir adalbert's tea, soursop green tea
<zyga-ubuntu> it has a big elephan on a decorative green box, not sure if you know it
<mvo> zyga-ubuntu: I don't let me search for it
<mvo> zyga-ubuntu: the downside of not sharing an office, I would love to try it :)
<zyga-ubuntu> it's awesome, I can bring you a bag next time we meet
<zyga-ubuntu> mvo: the trick is that fruit they added, soursop
<zyga-ubuntu> maybe if you like traditional tea it's "meh flavoured" but there's something really tasty about it
<mvo> zyga-ubuntu: I'm a bit of a traditionalist :) but also open so I'm certainly curious
<mvo> zyga-ubuntu: *cough* diff *cough* ;)
<mvo> zyga-ubuntu: else I'm gone for lunch and will be curious all the time
<zyga-ubuntu> mvo: here it is
<zyga-ubuntu> https://github.com/zyga/snapd/tree/fix/fix-snap-share-v3
<zyga-ubuntu> don't open PR yet please, I didn't touch packaging
<zyga-ubuntu> mvo: if you build that and run it, does it show duplicates or misbehaves for you?
<zyga-ubuntu> I'll proceed with proper tests now
<mvo> zyga-ubuntu: heh
<mvo> zyga-ubuntu: ConditionVirtualization=lxc
<zyga-ubuntu> that's just making it easy to ship
<mvo> zyga-ubuntu: I was thinking something like this this morning, if we should make it conditional
<mvo> zyga-ubuntu: and it works fine inside?
<zyga-ubuntu> yes
<zyga-ubuntu> just try it
<mvo> zyga-ubuntu: awesome
<zyga-ubuntu> I'll fix packaging and get that spread test that tried it merged
<zyga-ubuntu> mvo: note
<zyga-ubuntu> mvo: the conditional part is irrelevant
<mvo> zyga-ubuntu: thank you
<mvo> zyga-ubuntu: hu? how so?
<zyga-ubuntu> mvo: there's no difference from what you wrote
<zyga-ubuntu> mvo: (your unit was started the same way in the end)
<zyga-ubuntu> mvo: I really don't know why this works yet
<mvo> zyga-ubuntu: it was, but mine ran on classic as well
<zyga-ubuntu> mvo: I used a different wants
<zyga-ubuntu> ahhhhh
<mvo> zyga-ubuntu: and caused all sorts of problems there
<zyga-ubuntu> oh, that's it then
<mvo> zyga-ubuntu: yeah, thats it :)
<zyga-ubuntu> on classic it's not sane
<zyga-ubuntu> heh
<mvo> zyga-ubuntu: (I think at least)
<zyga-ubuntu> sounds like a good day then :)
<mvo> zyga-ubuntu: very nice, thank you!
<zyga-ubuntu> ok, let me finish the polish on this
<mvo> zyga-ubuntu: good luck, I get dinner now
<zyga-ubuntu> enjoy!
<ackk> mvo, should I file a bug about that missing file?
<zyga-ubuntu> spread running
<zyga-ubuntu> kyrofa: IT'S HAPPENING
 * zyga-ubuntu thinks about lunch
<mup> PR snapd#4560 opened: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>
 * pstolowski lunch
<zyga-ubuntu> hmmm
<zyga-ubuntu> - Download snap "lxd" (5522) from channel "stable" (sha3-384 mismatch for "lxd": got 3ed1910ba0d678da4820c74e35f288db4feb6dcad637466ab6c2bee26fca363b1cdb42e6b81e3f4fb834b672c64457c2 but expected 05ca4d0b5cd936beff0323dd786f2787fdf1783fbb7ffb89c09143c49a6e2269aca4a76e12d34422ea59826129f6009f)
<zyga-ubuntu> Chipaca: ^
<zyga-ubuntu> is this store being funky or do I have a bad day?
<sitter> is there a way to switch all of snapd to a different default channel? (e.g. install all future snaps and refresh all existing everything from edge)
<mborzecki> zyga-ubuntu: mvo: disabling optimizations and inlining resolves the problem
<zyga-ubuntu> sitter: no, not at present
<zyga-ubuntu> mvo: things passed in my spread
<zyga-ubuntu> mvo: I think it's a winner, let' see how the PR fares
<Chipaca> I got called out of physio to go pick up one of the boys who's being sick all over school (apparently)
<Chipaca> will miss the standup
<Chipaca> ttfn
<zyga-ubuntu> mvo: 4560 is ready for review
<zyga-ubuntu> brb, see you at the call
<zyga-ubuntu> ls
<zyga-ubuntu> mvo: that pr needs one more patch, to give the mount unit the right name (following snap mount dir)
<zyga-ubuntu> I'll do that
<mvo> zyga-ubuntu: ok
 * kalikiana going for lunch break in a few minutes
<mup> PR snapd#4561 opened: tests: generic detection of gadget and kernel snaps <Created by plars> <https://github.com/snapcore/snapd/pull/4561>
 * kalikiana off for lunch now
<pstolowski> mvo, hey, any specific reason why we abandoned these build stamp / system key branches?
<cachio> mvo, hey
<mvo> hey cachio
<mvo> pstolowski: no specific reason, happy to pick them up again and/or work with you on them. the main issue was that we had too many open PRs and a lack of reviewers so I closed to postpone
<cachio> mvo, is the rc2 comming today?
<mvo> cachio: thats my goal, however I need a review for the xdg-settings UI branch
<mvo> cachio: https://github.com/snapcore/snapd/pull/4342
<mup> PR #4342: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>
<cachio> mvo, good, I'll take a look
<cachio> mvo, I am also working on the test i18n which is failing on master for debian 9 and trusty
<pstolowski> mvo, i see. okay, it seems like a requirement now
<mvo> cachio: thank you
<mvo> pstolowski: yeah, let me finish my current task, then I can merge master and see how bad the conflicts are :)
<mvo> pstolowski: there is also a forum discussion - have you seen that one?
<pstolowski> mvo, not yet, but I think it's linked in one of the PRs
<zyga-ubuntu> mvo: another random failure
<zyga-ubuntu> (on lxd / 4560)
<zyga-ubuntu> I re-started
<kenvandine> mvo, has the ship sailed for 2.31 yet?
<zyga-ubuntu> timeout
<zyga-ubuntu> kenvandine: no, just initial RCs
<kenvandine> great
 * zyga-ubuntu goes to cook some lunch and then gets back to mount magic
<kenvandine> i thought jamesh's per-user mounts PR would be included
<kenvandine> any chance of that?
<zyga-ubuntu> kenvandine: that's possible but unlikely
<kenvandine> :(
<zyga-ubuntu> kenvandine: and even if so it won't be "live"
<zyga-ubuntu> kenvandine: it will only be useful once we have interfaces using that
<kenvandine> yeah
<zyga-ubuntu> kenvandine: I asked jdstrand to review it
<kenvandine> can we get a milestone set on the PR?
<zyga-ubuntu> kenvandine: and I will jump onto it soon as now (just this minute) I have my review on my only pending work
<zyga-ubuntu> kenvandine: no, I think it's premature
<zyga-ubuntu> kenvandine: there are things to do there and it's not something that benefits users yet
<kenvandine> yeah, but we need it in place for other things that we need for 18.04
<zyga-ubuntu> kenvandine: as it will only be used by interfaces and it's not yet, so I can merge it now and it's not changing anything yet
<kenvandine> quickly running out of time
<kenvandine> yeah
<zyga-ubuntu> kenvandine: sure but that's not related to merging
<zyga-ubuntu> kenvandine: development, sure
<kenvandine> but i'd like to get that stuff in for 2.32
<zyga-ubuntu> kenvandine: I will work on that branch (and related branches) this week for sure
<zyga-ubuntu> kenvandine: it's aggressive but we'll see what needs to be done
<kenvandine> i'll talk to james as well, but I think he's already working on stuff that depends on it
<zyga-ubuntu> kenvandine: yes, I'm in contact with james
<zyga-ubuntu> kenvandine: and we discussed it (james and me) with niemeyer
<mvo> kenvandine: for what? session startup?
<kenvandine> freeze is march 1, so we'd really like to land his desktop portal work before then
<kenvandine> mvo, this is for portals
<mvo> okay
 * mvo reads backlog
<kenvandine> i'm just trying to make sure all the pieces we need fall into place before feature freeze
<kenvandine> or soon after if we can get a freeze exception
<zyga-ubuntu> kenvandine: understood
<zyga-ubuntu> kenvandine: are those on halt now?
<zyga-ubuntu> or can they be deveoped while this gets ready?
<kenvandine> but we really don't want an LTS release to pass without the portal work
<kenvandine> they can still be worked on
<kenvandine> it's just over a month away though, so i'm getting stressed :)
<zyga-ubuntu> niemeyer: ^ FYI
<kenvandine> we can still fix bugs in anything related after of course
<kenvandine> but we prefer not to beg for freeze exceptions for features :)
<kenvandine> which are harder to get for an LTS
<ackk> what's the $PWD a "daemon: simple" app is run from? is it $SNAP?
<zyga-ubuntu> ackk: I think it could be /root but ... I forgot, sorry
 * zyga-ubuntu -> kitchen
<ackk> a "command: bin/mybinary" works so I had thought it was $$NAP
<zyga-ubuntu> ackk: no, those are reslved and that doesn't matter
<ackk> ah I see
<zyga-ubuntu> ackk: those would work regardless of working directory
<ackk> zyga-ubuntu, so if snap run --shell gives you the same env I guess it's /root
<zyga-ubuntu> ackk: ok, that's good then
<zyga-ubuntu> we tried to be consistent
<zyga-ubuntu> but for services we wanted to be a bit special
<zyga-ubuntu> HOME depends on user
<zyga-ubuntu> anyway,
<zyga-ubuntu> lunch is ready now
<kalikiana> re
<ikey> $HOME is where the <3 is
 * ikey ducks
<kalikiana> zyga-ubuntu: but are you ready for it? ;-)
<kalikiana> ikey: me $HOME es su $HOME
<ikey> d'aww
<ikey> lol
<kalikiana> that shoul've been "mi...", my Spanish spelling is terrible
<zyga-ubuntu> HOME is when you don't have to change your namespace
 * zyga-ubuntu gets back to lunch
<cachio> mvo, how should I make to reproduce the scenario with the ui for xdg-settings?
<cachio> mvo, I would like to manually test it
<cachio> mvo, is there any snap that I could use?
<zyga-ubuntu> mvo: man
<zyga-ubuntu> luck hates me today
<zyga-ubuntu> /dev/stdin: line 2: `<head><title>504 Gateway Time-out</title></head>
<zyga-ubuntu> maybe you can hit the restart button
<mup> PR snapcraft#1889 opened: tests: remove plainbox part from plugin tests <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1889>
<mvo> cachio: sorry for the delay. you can run "$ go build && ./snap userd" and then install the brave snap
<mvo> cachio: and brave will ask you
<mvo> cachio: to make itself default browser
<cachio> mvo, great, tx
<mvo> cachio: you may need to killall snap first if there is one already running in your session
<cachio> mvo, ok
<jdstrand> kenvandine: you do realize that you got the review of that PR preempted by another PR, right? ;)
<jdstrand> I guess now that the reprioritized one is done, it is time to have the other one preempt things :P
<jdstrand> anyway, it is on the list. it isn't for 2.31 at this point, so I put it behind the steam one for the moment, but I'll get to it soon
 * jdstrand notes that he will be at the snapcraft sprint this week so will likely not get to everything this week
<zyga-ubuntu> jdstrand: o/
<zyga-ubuntu> jdstrand: did you notice my earlier ping about an apparmor bug in apparmor inside lxdd?
<niemeyer> zyga-ubuntu, kenvandine: What are the dependencies for the user mount PR?
<zyga-ubuntu> niemeyer: I want jdstrand's ack on it, then we merge and iterate on small chunks
<zyga-ubuntu> niemeyer: on specific points to iterate on: maybe handling /media, handling root user, handling updates, etc
<jdstrand> I started to look at that pr on friday, but it is massive
<niemeyer> Yeah, that's not a good thing
<jdstrand> (in terms of interelated changes)
<mborzecki> hmm yocto uses `-linkshared ink against installed Go shared libraries (experimental).`
<mborzecki> taking snapd and linux_386_dynlink/libstd.so to artful i386 i can reproduce the segfault
<mborzecki> the address that ends up replacing task pointer is within a region like:
<mborzecki> b770f000-b7753000 rw-p 012cc000 fd:00 1371       /usr/lib/go/pkg/linux_386_dynlink/libstd.so
<jdstrand> zyga-ubuntu: I saw your comment re lxd. it sounds like the thing that I mentioned last week and alerted mvo to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738/comments/2
<mup> Bug #1744738: snapd 2.29.4.2 ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>
<mup> PR snapd#4562 opened: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
<jdstrand> zyga-ubuntu: ie https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34. my understanding is that jjohansen sent up a pr for the hwe kernel
<jdstrand> zyga-ubuntu: is what you're seeing on an hwe kernel?
<zyga-ubuntu> jdstrand: I saw this on artful kernel
<zyga-ubuntu> jdstrand: with xenial userspace
<jdstrand> zyga-ubuntu: that is essentially the same thing, yes. the hwe kernel is 4.13, like artful
<jdstrand> zyga-ubuntu: it should just naturally fix itself once the patch makes it into the Ubuntu kernel
<jdstrand> zyga-ubuntu: that said, I don't have the timing of this work. jj is traveling. tyhicks, do you happen to have details on the 4.13 kernel fix for apparmor profiles not loading inside lxd containers?
<zyga-ubuntu> jdstrand: ack, thank you!
<kenvandine> jdstrand, indeed, totally understand
<kenvandine> jdstrand, just getting things lined up so we have no surprises as feature freeze approaches
<mvo> zyga-ubuntu: I added some comments on 4560, would be awesome to have for 2.31
<mvo> zyga-ubuntu: do we need jamie for 4559?
<mvo> can someone please review 4342? it soft blocks 2.31~rc2
<zyga-ubuntu> mvo: I saw, thanks
<tyhicks> jdstrand: no, I'm not sure how far along the 4.13 kernel fix is
<jdstrand> kenvandine: note that snapd is not bound by feature freeze
<jdstrand> kenvandine: I'm not sure if the portals side is, but a ffe would certainly be possible
<kenvandine> jdstrand, exactly... but the portal work is
<kenvandine> yeah, possible
<zyga-ubuntu> kenvandine: is the portal work something that is ubuntu specific
<jdstrand> and I think that the portals side could continue without it
<kenvandine> jdstrand, just trying to plan ahead :)
<zyga-ubuntu> kenvandine: we also have to have portals and snaps work on fedora and debian and opensuse and elsewhere
<kenvandine> zyga-ubuntu, we're doing it with upstream
<jdstrand> kenvandine: sure, I understand. it it just more of the 'everything it critical priority, so nothing is' syndrome
<kenvandine> but it's enabling snaps
<zyga-ubuntu> kenvandine: there are no freezes upstream!
<kenvandine> zyga-ubuntu, but to get it in ubuntu :)
<zyga-ubuntu> (kudos to upstream work)
<kenvandine> thx
<mup> PR snapd#4517 closed: data: add systemd unit that unshares /snap <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4517>
<zyga-ubuntu> mvo: yes
<zyga-ubuntu> jdstrand: low hanging fruit on https://github.com/snapcore/snapd/pull/4559
<mup> PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
<zyga-ubuntu> literally one line of lstat of unlink to review
<mborzecki> disablink -linkshared makes the segfault problem go away
 * zyga-ubuntu feels ... sleepy... must coffee
<mborzecki> everything else is enabled
<zyga-ubuntu> mborzecki: that's something mwhudson may want to know
<zyga-ubuntu> he likely wrote it
<zyga-ubuntu> niemeyer: please look at https://travis-ci.org/snapcore/snapd/builds/334699893?utm_source=github_status&utm_medium=notification
<zyga-ubuntu> niemeyer: linode hicckup
<zyga-ubuntu> niemeyer: returning HTML on api request
<zyga-ubuntu> Our development team has been alerted to this error.  If you continue to have problems please contact support:
<zyga-ubuntu> eee
<zyga-ubuntu> gee
<zyga-ubuntu> they could _at least_ return that in a RPC response
<ackk> mvo hi, around?
<mvo> ackk: yes
<zyga-ubuntu> with X-Linode-Coupon-Code: header
<ackk> mvo any chance you could push the changes to include the distro-info csvs in base-18/edge ?
<cachio> mvo, when I set the default browser on brave, then I open a url, it is opened on chrome
<niemeyer> zyga-ubuntu: Thanks, this is the issue I mentioned earlier..
<niemeyer> zyga-ubuntu: Shouldn't affect the run
<mborzecki> haha once linshared is disabled even remote gdb magically started to work
<niemeyer> But needs fixing as the machines stay around
<mvo> ackk: yes, its tiny, let me add it
<mvo> cachio: oh? what do you get with "xdg-settings get default-web-browser" ?
<cachio> google-chrome.desktop
<cachio> mvo,
<mvo> cachio: did you get the dialog from snap userd asking for confirmation? it sounds for some reason it did not work. are you on the edge core?
<cachio> mvo, beta
<cachio> mvo, using the one I just built
<mvo> cachio: hm, you *might* need edge, I'm not 100% certain
<cachio> mvo, updating
<mvo> cachio: you can check if you have /snap/core/current/usr/bin/xdg-settings - it should consists of a bunch of dbus- calls
<cachio> refreshing
<mvo> cachio: but updating is easier :)
<mvo> ackk: pushed, let me trigger a built
<cachio> mvo, in progress
<cachio> mvo, tx
<ackk> mvo, thanks!
<mvo> ackk: I pulled in distro-info-data (so just the csv) should be availalbe in ~30min (once the build is finished)
<ackk> mvo, is it automatically published?
<mvo> ackk: it should be, yes
<ackk> ah, cool
<ackk> thanks
<zyga-ubuntu> kyrofa: https://github.com/snapcore/snapd/pull/4560
<mup> PR #4560: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>
<ackk> mvo, it seems some builds failed
<mvo> ackk: yeah, the ports nameserver lookup failed, looks very internal to me
<mvo> ackk: meh, all failed
<mvo> ackk: looking at it now
 * zyga-ubuntu afk but will be back, needs to refresh
<niemeyer> lxd pr reviewed
<mup> PR snapcraft#1889 closed: tests: remove plainbox part from plugin tests <bug> <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1889>
<kyrofa> zyga-ubuntu, yeeeeesssssss
<zyga-ubuntu> kyrofa: indeed
<zyga-ubuntu> kyrofa: we're just polishing the details
<zyga-ubuntu> but it works for real
<kyrofa> zyga-ubuntu, no security review yet, does it have security implications?
<zyga-ubuntu> kyrofa: nope
<zyga-ubuntu> kyrofa: it's all good
<kyrofa> So happy to hear it, thanks for sticking with it zyga-ubuntu
<zyga-ubuntu> kyrofa: it will be in 2.31 for sure (next RC)
 * kyrofa subscribes to PR
<zyga-ubuntu> kyrofa: I only did that because I had a terrible morning where another HDD broke and it was monday and it was raining and kids were crazy about returning back to school
<zyga-ubuntu> kyrofa: it turned out to be a good day after all :)
<kyrofa> Haha, good!
<stgraber> zyga-ubuntu: there is a bug with apparmor in containers when running on some > 4.4 ubuntu kernel, tyhicks is aware and jj was supposed to look into it
<tyhicks> stgraber: that's the bug that he's referring to
<jdstrand> stgraber: I pointed him to the relevant conversation
<zyga-ubuntu> yes, thank you everyone!
<stgraber> perfect :)
<tyhicks> jdstrand: now that I think about it, didn't jj say that he had test kernels available for testing?
<zyga-ubuntu> it's not an immediate probem because snapd manages its own profiles and reexecs but it will bite some people sooner or later
<tyhicks> jdstrand: does that ring any bells for you? if so, I can try to dig up the conversation
<jdstrand> tyhicks: well, yes, it does, but I couldn't remember the deatils so came to you :)
<jdstrand> tyhicks: I don't even know if there is a bug tbh
<zyga-ubuntu> jdstrand: the error message seems like it's a deliberate thing
<zyga-ubuntu> jdstrand: but unexpected
<zyga-ubuntu> jdstrand: it looks like apparmor thinks the container is privileged and doesn't do apparmor stacking
 * kalikiana wrapping up after a frustrating day of debugging symlink issues
<zyga-ubuntu> kalikiana: ln -s kalikiana /dev/bed
<zyga-ubuntu> or was it the other way around
<zyga-ubuntu> I hate "ln -s" syntax
<kalikiana> zyga-ubuntu: haha. you know, I've written a love poem about it, because that command annoys me so much (not a joke in fact)
<jdstrand> zyga-ubuntu, tyhicks: what I recall is that lxd is using a funky way to detect things because libapparmor doesn't provide something better. the kernel never meant to have what lxd is currently checking be depended on. the kernel changed this for some other reason and the check broke
<stgraber> jdstrand: the problem is that the broken kernel return an empty string at /sys/kernel/security/apparmor/.ns_name rather than the profile name
<stgraber> jdstrand: and the apparmor init script uses that string being non-empty as a way to detect stacking and so fails
<jdstrand> zyga-ubuntu, tyhicks: so jj was going to fix the kernel for now. I suspect he is going to also provide a libapparmor change, but I don't know that for a fact
<jdstrand> stgraber: right
<stgraber> jdstrand: the LXD side of the detection actually does work fine, LXD does setup stacking and everything but the container itself can't detect it
<jdstrand> and that was never meant to be 'the right check'
<jdstrand> but it is all you have
<jdstrand> ok, right, it was /lib/apparmor/functions that was wrong
<stgraber> jdstrand: so it's either a kernel bug that this string is now empty or it's an apparmor init script bug that it's relying on something which is meant to be empty :)
<jdstrand> but it was changed for lxd. anyway...
<jdstrand> stgraber: I think I said as much
<stgraber> yep
<pstolowski> niemeyer, pedronis I'd be useful to conclude #4401 (but #4400 first) as it will clear the way for interface hooks PR (and will help me a bit with resolving the issue of running hooks on refresh). AFAIR the most problematic point in 4401 was conflict resoluton, I've improved it and looking forward for feedback
<mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<mup> PR #4400: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4400>
<zyga-ubuntu> jdstrand: quoting linus, "fu... nvidia"^H^H "never break userspace" :-)
<zyga-ubuntu> I'm sure it will be resolved quickly
<pstolowski> niemeyer, pedronis ah, mistake, not after 4400, but after #4440
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<niemeyer> pstolowski: #4440 LGTM
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<pstolowski> niemeyer, thanks
<kyrofa> zyga-ubuntu, have you messed with snapd in docker lately?
<zyga-ubuntu> kyrofa: no, never
<zyga-ubuntu> kyrofa: like literally never ever
<kyrofa> Yeah me neither, but I seem to remember other people running into issues
<zyga-ubuntu> kyrofa: is docker the deb something that I can try to use? or should I use docker the snap
<zyga-ubuntu> guess I should try today
<kyrofa> zyga-ubuntu, no idea :D
 * zyga-ubuntu handles some important errand at home and will be back to snapd in a moment
<mup> PR snapcraft#1890 opened: Fixed typo <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1890>
<zyga-ubuntu> niemeyer: can you please look at 4560 again please?
<zyga-ubuntu> too much pleasure ;-)
<zyga-ubuntu> niemeyer: I changed how I generate the unit and made the name dynamic
<zyga-ubuntu> and fixed some silly things in that makefile while I was at it
<zyga-ubuntu> spread is in progress, local testing was ok
<zyga-ubuntu> man, where is everyone, no chipaca, no mvo :/ I should sleep at night and work during the day more
<bashfulrobot> Question - staged packages in a confined snap.. are they updated when apt is run? Or only when the snap package is refreshed/
<kyrofa> bashfulrobot, anything in the snap is only updated when the snap is updated
<kyrofa> Remember the snap is read-only
<bashfulrobot> I suspected. I have a use case for a snap at my work, but I know it will likely have to be classic (display related - remoting protocol). But the base software does not need to be updated often. So I was trying to figure out if there si a negative aspect to snapping it.
<cachio> <cachio> zyga-ubuntu, about the hidraw interface
<cachio> <cachio> zyga-ubuntu, I cannot see it as part of the interfaces in my machine
<cachio> <cachio> zyga-ubuntu, do you
<cachio> <cachio> ?
<cachio> zyga-ubuntu, I got disconnected
<zyga-ubuntu> cachio: re
<zyga-ubuntu> cachio: AFAIK it's juts added in gadget snaps, it's not implicit
<zyga-ubuntu> bashfulrobot: snaps can be updated as often as you want
<zyga-ubuntu> bashfulrobot: you just have to do the update
<zyga-ubuntu> bashfulrobot: snapcraft.io can help, you can just rebuild your pacakge
<zyga-ubuntu> *package
<cachio> zyga-ubuntu, ok, tx
<bashfulrobot> Ah ok, so you almost need to rebuild regularly in this case regardless of the packaged software itself.
 * ikey issued "normal" updates for the lsi edge snaps..
<bashfulrobot> Thanks for the info zyga-ubuntu
<mup> PR snapcraft#1891 opened: lifecycle: use in-snap mksquashfs if running from snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1891>
<roadmr> jdstrand: hi there! would it be OK for me to update the reviewer tools to r978? or would that need the extra packages for the resquash work? my reason for asking: there's at least one snap using a 2.30 interface which is failing review because said interface is not yet known by tools r950 which is what the store has
<ackk> there is a typo in base-18 Makefile: s,curren/t,current/
<ackk> * s,curren/t,current/,
<ackk> mvo ^ in case you're around
<ackk> FTR: https://github.com/snapcore/base-18/pull/36
<mup> PR base-18#36: Makefile: fix typo in base URL <Created by albertodonato> <https://github.com/snapcore/base-18/pull/36>
<zyga-ubuntu> ackk: looking
<zyga-ubuntu> ackk: I cannot merge it, tests failed, I'm looking at why but this looks like something mvo knows better
<ackk> zyga-ubuntu, ok. it's probably not related to this change, though
<ackk> zyga-ubuntu, can you kick a build on current master to see if it hits the same error?
<zyga-ubuntu> ackk: I restarted that test
<zyga-ubuntu> chroot: failed to run command â/tmp/999-clean-resolv-conf.chrootâ: Permission denied
<zyga-ubuntu> hmm hmm
<zyga-ubuntu> ackk: is this https://github.com/snapcore/base-18/blob/master/hooks/999-clean-resolv-conf.chroot file +x in your branch?
<zyga-ubuntu> cna you please check that
<ackk> zyga-ubuntu, it's not
<ackk> nor in master
<ackk> zyga-ubuntu, should I chmod it?
 * ackk tries
<ackk> let's see if tests pass now
<zyga-ubuntu> yes
<niemeyer> zyga-ubuntu: First comment wasn't addressed or responded
<ackk> zyga-ubuntu, tests passed
<zyga-ubuntu> niemeyer: oh, let me check
<zyga-ubuntu> hmm, that's odd, I responded but my response is gone now
<zyga-ubuntu> niemeyer: let me respond again, I certainly didn't ignore it
<zyga-ubuntu> and odd
<zyga-ubuntu> I cannot respnd to the thread there
 * zyga-ubuntu reloads
<zyga-ubuntu> niemeyer: anyway, let's do it here so that we can reach an agreement
<zyga-ubuntu> my initial response was that I'd prefer to fail close and early rather than notice the situation we don't support and fail open later when snap is refreshed or removed
<zyga-ubuntu> if you think this is too grave concern we can reomve that whole section now, it's not doing anything apart from checking and failing when the externally satisfied precondition is not met
<zyga-ubuntu> niemeyer: let me know what you think
<niemeyer> zyga-ubuntu: Yeah, I found it awkward that there's no way to add comments there indeed
<niemeyer> zyga-ubuntu: My concern (and mvo's I think) is not that it's better to fail one way or the other, but rather that we have existing logic and no clue whether people are depending on it today or not
<zyga-ubuntu> niemeyer: yes, that's a valid concern, as I said I responded to the comment (somehow) and I wanted to discuss it more hence no changes
<niemeyer> zyga-ubuntu: Before, there was nothing there.. then, in an automatic update, we go from "no worries!" to "BOOM!"
<zyga-ubuntu> niemeyer: I think for now we can make the die go away and land this, to the happiness of LXD uses
<zyga-ubuntu> and we could look at a way for snapd to measure the environment say "gee, I cnanot work here" perhaps
<niemeyer> zyga-ubuntu: And we need some kind of heads up before we do hard changes
<niemeyer> zyga-ubuntu: So we have a clue if we're breaking any existing environment for which we don't currently have tests for
<zyga-ubuntu> niemeyer: shall we printf something or just do nothing at all now?
<zyga-ubuntu> (as in rip that code path out)
<niemeyer> zyga-ubuntu: I would not touch that kind of logic right now
<niemeyer> zyga-ubuntu: There's just too much going on
<niemeyer> zyga-ubuntu: Just add a note of what the intention is for the near future and why
<niemeyer> zyga-ubuntu: Then, when everything else settles, we can poke at it and see what happens
<niemeyer> zyga-ubuntu: Certainly with a warning before we do anything aggressive
<zyga-ubuntu> ok
<zyga-ubuntu> niemeyer: updated
 * zyga-ubuntu doesn't like old make :/
<cachio> zyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test
<niemeyer> zyga-ubuntu: Looking again
<cachio> zyga-ubuntu, any idea if it is an error or a message that could be discarded?
<zyga-ubuntu> cachio: that looks like one of those go bugs we had
<zyga-ubuntu> I thought those were fixed
<zyga-ubuntu> are those on 14.04?
<niemeyer> zyga-ubuntu: Can we please not touch that logic right now instead?
<cachio> zyga-ubuntu, yes, it is making the i18n test fail
<zyga-ubuntu> niemeyer: no
<zyga-ubuntu> niemeyer: that logic as it was was broken
<zyga-ubuntu> niemeyer: it was either inactive or it was broken
<zyga-ubuntu> niemeyer: (see the original bug description from stgraber)
<niemeyer> zyga-ubuntu: Why?
<zyga-ubuntu> niemeyer: it was running to late, creating mirror entries
<cachio> zyga-ubuntu, it is also failing on debian-9
<niemeyer> zyga-ubuntu: I won't re-read the *whole* bug right now trying to guess hints of this :)
<zyga-ubuntu> cachio: so on 14.04 and on debian-9 we probably have the bug still, I don't know really
<zyga-ubuntu> niemeyer: essentially the self-bind mount would duplicate existing mount entries
<zyga-ubuntu> niemeyer: and then apply sharing over them
<zyga-ubuntu> niemeyer: but keep the old entries intact
<cachio> zyga-ubuntu, do you remember in which PR it was fixed for the other systems? so I can take a look
<zyga-ubuntu> niemeyer: there were two lines there: a rbind and a rshare
<zyga-ubuntu> niemeyer: the rbind gives us a thing that can control sharing (sharing is per mount entry not per directory)
<zyga-ubuntu> niemeyer: and the sharing is obvious
<zyga-ubuntu> niemeyer: but at that time /snap was already populated
<zyga-ubuntu> niemeyer: the result confuses systemd and mount units cannot stop correctly
<zyga-ubuntu> niemeyer: that's about it
<zyga-ubuntu> cachio: it was a (perhaps more than one) update to the golang compiler, but perhaps I don't recall correctly; mwhudson would know
 * zyga-ubuntu will snap ancient make for self-punishment and testing
<niemeyer> zyga-ubuntu: Yes, I get that.. I thought that was exactly what was fixed
<niemeyer> zyga-ubuntu: and this path shouldn't be reachable given that
<zyga-ubuntu> niemeyer: yes!
<zyga-ubuntu> niemeyer: that's why I used die
<zyga-ubuntu> and argued we could rip it out
<niemeyer> zyga-ubuntu: Well.. now you are saying that if we preserve the logic we have a bug..
<zyga-ubuntu> no no, sorry, we have a comms problem over irc
<zyga-ubuntu> if we keep the old bind mount + share code there we will have problems on systems that the new snap.mount unit doesn't fix (e.g. on a non-container with that behavior)
<zyga-ubuntu> essentially, that whole code was wrong and it should be removed regardless
<zyga-ubuntu> but for initial version of this patch in the morning I used die to see if it would fail anywhere
<zyga-ubuntu> one place we could perhaps explore is 14.04 as a non-container
<niemeyer> zyga-ubuntu: If we have code that the change doens't fix, then you'd be blowing it up with die()
<zyga-ubuntu> yes
<mwhudson> zyga-ubuntu: hmmm
<zyga-ubuntu> niemeyer: but 14.04 is using a different mechanism to fix it
<zyga-ubuntu> niemeyer: so nothing (apart from build failure now with make) was broken
<zyga-ubuntu> niemeyer: either way, I would leave: printf (as it is now) or nothing; I would not keep that mount rbind, mount rshare code as we used to have
<zyga-ubuntu> we *could* keep it
<zyga-ubuntu> and it would not alter behavior
<zyga-ubuntu> *behaviour
<zyga-ubuntu> but I think it's just buggy
<mwhudson> zyga-ubuntu: +?
<zyga-ubuntu> we can do that on another iteration if you are worried about something unanticipated
<zyga-ubuntu> mwhudson: hmm?
<mwhudson> zyga-ubuntu: "mwhudson should know" -- know what? :)
<niemeyer> zyga-ubuntu: I've been saying that for some time :)
<zyga-ubuntu> mwhudson: ah, sorry, cachio saw "cgo runtime" thing again
<mwhudson> zyga-ubuntu: cgo runtime?
<zyga-ubuntu> mwhudson: and asked if we there was a patch for that somewhere
<zyga-ubuntu> 22:18 < cachio> zyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test
<mwhudson> zyga-ubuntu: i'm just back from leave so have no context at all
<niemeyer> zyga-ubuntu: We have several concurrent ideas of what's supposed to happen:
<niemeyer> 1. Nobody will ever reach this logic
<niemeyer> 2. We want to kill those who reach this logic
<zyga-ubuntu> niemeyer: sure, I just wanted to explain the motivation of the patches I sent so far so that my ideas are clear
<niemeyer> 3. We want to preserve the behavior of those reaching this logic
<niemeyer> Those are all incompatible with each other
<zyga-ubuntu> I agree
<cachio> mwhudson, hey
<cachio> mwhudson, https://travis-ci.org/snapcore/snapd/builds/334699893#L2129
<mup> PR snapcraft#1890 closed: Fixed typo <Created by chrisglass> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1890>
<zyga-ubuntu> niemeyer: 1 can still happen on systems that don't use systemd to boot but we don't support that
<mwhudson> zyga-ubuntu: i don't know what that means
<cachio> mwhudson, when we run a test that tries the different languages with the command snap
<zyga-ubuntu> mwhudson: I was under the impression that we ran into a bug in golang where exec + fork were racing
<zyga-ubuntu> mwhudson: but perhaps that was fixed in the kernel, I don't recall
<niemeyer> zyga-ubuntu: I don't want to go hunting that sort of bugs *right now*
<cachio> mwhudson, we can see an error "runtime/cgo:"
<niemeyer> zyga-ubuntu: Or to burn mvo with late releases to fix serious issues in unexpected environments
<zyga-ubuntu> niemeyer: understood
<niemeyer> zyga-ubuntu: We need to focus on delivering the few things which are high prio at the moment.. layouts, interface hooks, etc
<zyga-ubuntu> I'll restore the code and leave a todo to remove this after the release
<niemeyer> Thanks!
<mwhudson> cachio: oh well i18n is disabled entirely in debian
<zyga-ubuntu> niemeyer: thank you! :)
<cachio> mwhudson, it is just happening on debian-9 and ubuntu-14.04
<mwhudson> zyga-ubuntu: aaah the fork/exec thing
<mwhudson> wait one version of that is just a warning
<zyga-ubuntu> cachio: was it failing or just printing and you noticed?
<cachio> zyga-ubuntu, it is printing
<niemeyer> zyga-ubuntu: Why was the unit file embedded in the makefile?
<cachio> zyga-ubuntu, If I reexec it doesn't fail
<mwhudson> hmmm i thought that was fixed in debian though
<niemeyer> zyga-ubuntu: That sounds a bit less nice than what you had there earlier
<mwhudson> oh wait, probably only in buster
<zyga-ubuntu> niemeyer: it was nice when it worked, no need to sed, just expand variables
<cachio> mwhudson, zyga-ubuntu if I exec the command that failed in a debug session, it works well
<zyga-ubuntu> niemeyer: but given that old make sucks I think I must go back to sed
<mwhudson> cachio: it's only ever a 1 in a 1000 type thing, it's a race
<zyga-ubuntu> niemeyer: the advantage was that we didn't have to duplicate a rule for a file with variable target name
<zyga-ubuntu> niemeyer: anyway, I'll sort it out
<cachio> mwhudson, it seems so
<mwhudson> there is also the kernel bug where a setuid executable doesn't get uid=0, no idea if that's fixed in debian yet
<niemeyer> zyga-ubuntu: I don't see the relationship
<niemeyer> zyga-ubuntu: Embedding everything in the Makefile isn't so nice, whether make rocks or not
<zyga-ubuntu> niemeyer: it was nice for this case IMO, because I could didn't have to duplicate rules that sed the vars in and get the new filename I had to use
<zyga-ubuntu> almost there...
<cachio> mwhudson, something that I already tried is to add a sleep between different tries and the issue also happened
<cachio> mwhudson, any idea where I could start looking at to fix it?
<mwhudson> cachio: it's a race within the go start up routines
<cachio> mwhudson, ah, ok
<cachio> zyga-ubuntu, is it ok if we ignore these kind of errors or set this to manual?
<cachio> zyga-ubuntu, also we could skip the failing systems until the issue is resolved
<cachio> mwhudson, how did you deal with these kind of issues in the past?
<zyga-ubuntu> cachio: well, it's not really honest, we should get the relevant fixes to those systems if that makes snapd work better
<jdstrand> roadmr: it is probably ok but I haven't fully verified it
<roadmr> jdstrand: oh ok... I'd rather wait until you greenlight it properly then
<cachio> zyga-ubuntu, of course, but the fixes should go in snapd?
<jdstrand> roadmr: right now most of that is behind env vars
<roadmr> jdstrand: what can cachio do in the meanwhile, with that interface he wants to use that the old tools don't grok?
<jdstrand> roadmr: but we/I can be responsive to the queue for now too
<zyga-ubuntu> cachio: no
<roadmr> jdstrand: ok... hm this snap was marked as "failed review", not as "held for manual review", whic was odd
<zyga-ubuntu> cachio: to kernel/golang AFAIK
<jdstrand> roadmr: he can request a manual review
<roadmr> cachio: ^^ oh yay!
<mwhudson> cachio: hm the fix for this is https://go-review.googlesource.com/c/go/+/33894 which is in go 1.8 which i thought was what stretch had...
<mwhudson> ah no 1.7
<cachio> mwhudson, ok
<zyga-ubuntu> niemeyer: I think this is it
<zyga-ubuntu> lets see if tests pass
<cachio> roadmr, sure, I'll do
<cachio> roadmr, done
<roadmr> whee :0 cachio that way no need to wait for the tools upgrade because it might be a bit longer than expected
<roadmr> cachio: great, that puts it in the queue and someone will look shortly.
<cachio> roadmr, I'll have to request also for all the other arquitectures
<cachio> architectures
<cachio> roadmr, np, thanks
<jdstrand> cachio: if it is test-snapd-gpio-memory-control, I just approved it, but you'll need to publish
<cachio> jdstrand, yes, thanks
<cachio> zyga-ubuntu, i18n is making snapd fail 1/3 executions, so, what do you think is the best idea to deal with this one
<zyga-ubuntu> cachio: well, it depends, we could just ignore that result, ideally we'd try to get the fix released if the frequency is that high people will also hit that bug often
<cachio> zyga-ubuntu, it is often because the test is going through all the langs and trying LANG=xxx snap
<zyga-ubuntu> I see
<zyga-ubuntu> well
<zyga-ubuntu> I don't think that changes anything
 * zyga-ubuntu reads about dell vmware merger
<zyga-ubuntu> imagine a laptop with "vmware" logo on it :)
<zyga-ubuntu> on the other hand vmware metal servers would be fun
<niemeyer> zyga-ubuntu: LGTM assuming it works :)
<zyga-ubuntu> thank you!
<zyga-ubuntu> I'll get the other branch working now
<zyga-ubuntu> and in some alternative universe we're all running dell VMs using dell workstation which is a program
<zyga-ubuntu> ....
<zyga-ubuntu> dell and vmware watch too many mirror universe trek episodes
<roadmr> haha
<roadmr> good one
<zyga-ubuntu> but, at least dell fusion makes sense, with vmware, that is
<zyga-ubuntu> niemeyer: tests are green :)
<zyga-ubuntu> we need a 2nd review
<zyga-ubuntu> I'll ask mvo for one in the morning
<zyga-ubuntu> hmm, no vmware would probably not be affected
<zyga-ubuntu> that's curious, I wonder if I could reproduce that
<zyga-ubuntu> kyrofa: it looks like I will have clean plate soon (I will work on per-user mounts with jamesh and on layout policy with jdstrand) but this can be my backburner task
<kyrofa> zyga-ubuntu, no problem, just comment on that issue when you're able, I'll leave it open
<zyga-ubuntu> kyrofa: actually, with my gazillion tabs lost on my desktop
<zyga-ubuntu> do you have a link?
<jamesh> zyga-ubuntu: fwiw, I'm in UTC-8 this week (rather than UTC+8)
<kyrofa> zyga-ubuntu, https://github.com/nextcloud/nextcloud-snap/issues/425
<kyrofa> Haha, no problem
<roadmr> jamesh: oh what happened :( who multiplied you by -1?
<zyga-ubuntu> jamesh: oh, cool, sprinting?
<zyga-ubuntu> kyrofa: thank you
<zyga-ubuntu> roadmr: LOL
<jamesh> zyga-ubuntu: yeah.  At the Snapcraft Summit with kyrofa and others
<zyga-ubuntu> cool, is jdstrand there too?
<zyga-ubuntu> jamesh please talk to jdstrand about your PR, if he acks it I'll merge and we can iterate
<jamesh> zyga-ubuntu: I think he's arriving later in the week
<zyga-ubuntu> excellent, don't let him leave without that :)
<zyga-ubuntu> ;-)
<jdstrand> zyga-ubuntu, jamesh: fyi, I just reviewed it
<kyrofa> jamesh, yeah, Thursday
<zyga-ubuntu> ooooh
 * zyga-ubuntu is looking
<jdstrand> I'll be there Wed and Thu
<jdstrand> (leaving tomorrow)
<mwhudson> what https://paste.ubuntu.com/26486123/
<mwhudson> (tldr snapcraft.storeapi.errors.StoreReleaseError: <exception str() failed>)
<zyga-ubuntu> jdstrand: nice, thank you!
<zyga-ubuntu> kyrofa: ^
<kyrofa> Oh right, was thinking Thursday/Friday
<kyrofa> Glad you said something :P
<mwhudson> hm i tried running snapcraft login again and now it's just hanging
<kyrofa> mwhudson, hmm... what version
<kyrofa> ?
<mwhudson> 2.35 (stable channel)
<mwhudson> ... because snap install --edge --classic snapcraft was failing too :)
<mwhudson> clearly i shouldn't be near computers today
<kyrofa> Huh, sounds like the store is having issues then
<zyga-ubuntu> mwhudson: snap install weekend -> EMONDAY
<mwhudson> kyrofa: could be
<zyga-ubuntu> where is that apt thing
<zyga-ubuntu> where it prints something odd once in blue moon
<zyga-ubuntu> when something else fails
<zyga-ubuntu> it's a bit insane
<zyga-ubuntu> ah, past midnight something
<mwhudson> zyga-ubuntu: it's a 'man after midnight' think i think
<mwhudson> (and cj-watson's fault)
<zyga-ubuntu> ah :D
<zyga-ubuntu> it was man
<mwhudson> https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030
<mwhudson> kyrofa: it's working now
<kyrofa> Weird
#snappy 2018-01-30
<mup> PR snapcraft#1891 closed: lifecycle: use in-snap mksquashfs if running from snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1891>
<cachio> jdstrand, I have requested manual review for the other architectures of snap test-snapd-gpio-memory-control
<cachio> jdstrand, when you have a minute, could you please approve them
<cachio> tx
<jdstrand> cachio: done
<cachio> jdstrand,  tx
<mup> PR snapd#4563 opened: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563>
<mborzecki> morning
<mborzecki> forum is down?
<mborzecki> mvo: morning
<mvo> mborzecki: good morning
<mvo> mborzecki: yeah, looks down from here as well
 * mvo still needs a review for 4342
<zyga-ubuntu> good morning
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4560 is ready for 2nd review
<mup> PR #4560: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>
<zyga-ubuntu> and I'll work on breakfast for kids, see you soon
<mup> PR snapd#4560 closed: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4560>
<mvo> zyga-ubuntu: I already commented, one tiny nitpick about a comment but that should be a followup, no need to hold this PR back
<mvo> zyga-ubuntu: I need a review for 4342, its blocking ~rc2 currently
<zyga-ubuntu> I know, I will do your review after kids go to school
<mvo> ta
<mborzecki> zyga-ubuntu: morning
<zyga-ubuntu> oka
<zyga-ubuntu> daughter is all set and ready for school
<zyga-ubuntu> mvo: thank you for the feedback, I'll update the PR and merge it
<zyga-ubuntu> ah, it's merged now :)
<zyga-ubuntu> k, looking at that zenity branch
<zyga-ubuntu> mvo: btw, I'm very sorry for not looking at it yesterday, I saw your requests but I was busy with the feedback from gustavo
<zyga-ubuntu> mvo: will you do a RC3 for 2.31?
<mup> PR snapd#4564 opened: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564>
<zyga-ubuntu> mvo: I really want to land 4471 today
<zyga-ubuntu> mvo: and make it into the release
<zyga-ubuntu> otherwise we should probably back out the new content interface features
<zyga-ubuntu> gustavo approved the design but requested tweaks on how that code operates to drop the helper function (tryIt etc)
<mvo> zyga-ubuntu: if 4471 is ready today +1, if not I think we need a revert PR
<mvo> zyga-ubuntu: how was the feedback yesterday? all looking good to fix it today?
<zyga-ubuntu> mvo: yes
<bashfulrobot> Is the forum down for anyone else? Nginx 502 bad gateway.
<zyga-ubuntu> mvo: I need to inline that function back
<zyga-ubuntu> mvo: nothing major
<mvo> ok
<zyga-ubuntu> bashfulrobot: it's down for me too
<bashfulrobot> zyga-ubuntu thanks for the confirmation!
<zyga-ubuntu> woah, the wind today is very strong
<zyga-ubuntu> trees are swinging like grass!
<zyga-ubuntu> jdstrand: are you in US or still sprinting somewhere?
<oSoMoN> good morning
<oSoMoN> I'm getting a 502 on forum.snapcraft.io
<oSoMoN> is it just me?
<zyga-ubuntu> no, it's everyone
<mvo> jdstrand: if you could moderate the updated base-18 in the store that would be great
<zyga-ubuntu> mvo: what is %[1]q - is that golang syntax for fmt?
<zyga-ubuntu> hey there spineau
<spineau> morning zyga-ubuntu
<zyga-ubuntu> mvo: nitpick 2018 in your new files
<pstolowski> mornings
<zyga-ubuntu> hey pawel
<pstolowski> the forum is borked?
<zyga-ubuntu> yes
<zyga-ubuntu> mvo: so I get what \0 is but \00 ? is that the same thing or {'\0', '0'} in C syntax?
<zyga-ubuntu> man, today is windy :/
<kalikiana> sliff
<mvo> zyga-ubuntu: %[1]q is fmt syntax
<mvo> zyga-ubuntu: \00 should be \0, let me check, maybe I made a silly mistake
<zyga-ubuntu> mvo: at line ... 43 and 44
<zyga-ubuntu> mvo: so meta-comment, nothing -1, I want to play with it
<zyga-ubuntu> but we need the desktop team to help and I don't know, roll this into gnome settings
<zyga-ubuntu> or into other appropriate place
<zyga-ubuntu> right now it feels like a hack that keeps us walking till we can run
<pstolowski> mvo, hey, shall I squash #4440 for easy cherry-picking into 2.31?
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<mvo> pstolowski: its fine as is, I looked over master this morning and all is fine for .31
<pstolowski> mvo, ok
<mvo> zyga-ubuntu: aha, sorry. this should read \0\0
<mvo> zyga-ubuntu: i.e. a double \0 marks the end of a command
<mvo> zyga-ubuntu: let me fix this
<zyga-ubuntu> thank you!
 * zyga-ubuntu reads rest
<mborzecki> zyga-ubuntu: hmm looking at 4565 i was wondering why i'm ending up with snap.mount on arch
<ackk> mvo, hi, it seems there was an issue uploading the base-18 build: https://code.launchpad.net/~mvo/+snap/base-18/+build/138724
<mup> PR snapd#4440 closed: state: unknown tasks handler <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<mborzecki> zyga-ubuntu: turns out i'd really like to switch data to autotools
<zyga-ubuntu> mborzecki: no objection, fire a PR and let's do it
<zyga-ubuntu> mvo: and in strings, is \000 just {'\0'} or is it something else
<zyga-ubuntu> e.g. here:  +call = strings.TrimSuffix(call, "\000")
<mvo> ackk: yeah, I ask jamie to moderate the upload, it is currently stuck in the review queue
<mvo> zyga-ubuntu: this should be \0 as well, sorry for this
<ackk> oh ok, thanks
<zyga-ubuntu> mvo: did you run it in practice?
<mvo> zyga-ubuntu: just running the tests
<mvo> zyga-ubuntu: but the zenity tests use \n in their args
<mvo> zyga-ubuntu: so it should work
<zyga-ubuntu> mvo: how about setting this thing in practice, getting the prompt and all of that
 * zyga-ubuntu is still reading the code
<sparkiegeek> do we have to wait for niemeyer to get the forum back up?
<zyga-ubuntu> sparkiegeek: I'm afraid so, we're not sure what caused it
<mvo> zyga-ubuntu: I tested this with the brave browser
<mvo> zyga-ubuntu: sorry for the delay in answering
<mvo> zyga-ubuntu: if that is what you mean with "testing in practise" or do you mean something else?
<zyga-ubuntu> no that's fine
<zyga-ubuntu> did you test both kde and non-kde paths?
<mvo> zyga-ubuntu: yeah, i tested once with kdialog and once with zenity
<mvo> zyga-ubuntu: I think mborzecki has a point that ideally it would check the desktop env too, I can make a PR for that too
<zyga-ubuntu> mvo: yeah, I responded to that part as well
 * kalikiana coffee
<zyga-ubuntu> mvo: reviwed
<zyga-ubuntu> reviewed*
<zyga-ubuntu> mvo: can you have a quick look at https://github.com/snapcore/snapd/pull/4564 please
<mup> PR #4564: data/systemd: tweak comment <Created by zyga> <https://github.com/snapcore/snapd/pull/4564>
<zyga-ubuntu> let's either merge it or tell me to tweak the install code
<mup> PR snapd#4564 closed: data/systemd: tweak comment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4564>
<mvo> zyga-ubuntu: I think its fine, we can always tweak further
<zyga-ubuntu> thanks!
<pedronis> hi, is the forum down (502)Â ?
<zyga-ubuntu> yes
<zyga-ubuntu> I think we need a post mortem on the forum and some plan for gustavo being on holidays
<zyga-ubuntu> *cough* IS *cough*
<zyga-ubuntu> kalikiana: https://regexper.com/
<mborzecki> `/home/ubuntu/goroot/pkg/tool/linux_386/link: running gcc failed: exit status 1` uhh not my lucky day
<zyga-ubuntu> mborzecki: it's your NaNth lucky day
<mborzecki> oh hey, also gnome-shell crashed out of the blue
<mborzecki> pff strace to the rescue: [pid  8615] write(2, "/usr/bin/ld", 11) = -1 ENOSPC (No space left on device)
<zyga-ubuntu> uhh
<zyga-ubuntu> careful with those torrents
<zyga-ubuntu> qemu can eat a lot of space on -snapshot
<mborzecki> zyga-ubuntu: it's xenial cloud image
 * zyga-ubuntu takes a break to look through bugs befor jumping onto PR feedback
<mborzecki> didn't know those are 2gb
<zyga-ubuntu> hey Chipaca!
<zyga-ubuntu> mborzecki: uh
<mborzecki> Chipaca: morning
<Chipaca> mborzecki: zyga-ubuntu: hiya
<zyga-ubuntu> pstolowski: can you please look at https://bugs.launchpad.net/snapd/+bug/1611638
<mup> Bug #1611638: snap upgrade hook <snapd:Fix Committed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1611638>
<zyga-ubuntu> I think it's fixed so we can just update the bug but I wanted you to confimr
<zyga-ubuntu> *confirm even
<pstolowski> zyga-ubuntu, looking
<kalikiana> zyga-ubuntu: Hmmm looks quite nice. Although it seems very "analyze afterwards". It's not live and there's no test string
<zyga-ubuntu> mborzecki: I assigned a bug about testing on arch to you (since you're doing that anyway)
<zyga-ubuntu> kalikiana: yeah, not perfect but it's nice to see those cute railroad diagrams
<mborzecki> zyga-ubuntu: ack
<pstolowski> zyga-ubuntu, commented on the bug, it's implemented, although now as I checked only on of those was released (post-refresh) and pre-refresh will come with 2.31
<zyga-ubuntu> pstolowski: perfect, thank you!
 * Chipaca carries on refactoring unseen code
<zyga-ubuntu> Chipaca: I do that a lot though sometimes I think I'm doing the coding version of modern art ;)
<Chipaca> zyga-ubuntu: not art, but craft
<Chipaca> zyga-ubuntu: the difference is mostly around how we get paid :-)
<zyga-ubuntu> haha
<mborzecki> art is when you don't get paid
<zyga-ubuntu> I often write a piece of code and the refactor it, sometimes many many times, before sending out the first PR
<zyga-ubuntu> pstolowski: another one for you https://bugs.launchpad.net/snapd/+bug/1664155
<mup> Bug #1664155: Interface hooks slots should know the name of the client snap <snapd:Triaged> <https://launchpad.net/bugs/1664155>
<zyga-ubuntu> mvo: trivial conflict on https://github.com/snapcore/snapd/pull/4443
<mup> PR #4443: [RFC] snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/4443>
<Chipaca> pedronis: you around?
<mup> PR snapd#4565 opened: httputil: include Go runtime version in user agent string <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>
<mborzecki> trivial PR ^^
<zyga-ubuntu> kalikiana: can you look at https://bugs.launchpad.net/snapd/+bug/1669291, perhaps a low hanging fruit
<mup> Bug #1669291: 'snap info' does not handle versions that end in 0 well <Snapcraft:New> <snapd:In Progress> <https://launchpad.net/bugs/1669291>
<zyga-ubuntu> kalikiana: at least triage it please
<pstolowski> zyga-ubuntu, k, will comment on it when forum is back, I think it was discussed long time ago (and Gustavo was against doing it)
<zyga-ubuntu> mborzecki: nie!
<zyga-ubuntu> nice!
<zyga-ubuntu> :)
<zyga-ubuntu> pstolowski: just give some feedback on the bug report, we don't have to move the discussion elsewhere
<zyga-ubuntu> mborzecki: what is the runtime string like?
<mborzecki> zyga-ubuntu: added a comment in the PR
<zyga-ubuntu> mborzecki: and another hint, send it in the / request so that (perhaps) snap version can show it
<pstolowski> zyga-ubuntu, sure, I just need to try find that discussion
<zyga-ubuntu> mborzecki: looks good
<kalikiana> zyga-ubuntu: Aye
<pedronis> Chipaca: yes
<Chipaca> pedronis: hiya, welcome back :-)
<pedronis> hi
<Chipaca> pedronis: while you were away I was wondering whether a local snapd could "sign" stuff
<zyga-ubuntu> kalikiana: thank you
<Chipaca> pedronis: and thought you were the person to ask
<pedronis> Chipaca: sign stuff in which sense?
<zyga-ubuntu> pstolowski: perhaps another bug for you https://bugs.launchpad.net/snapd/+bug/1672747 -- feel free to ignore, I'm just combing the bug tracker
<mup> Bug #1672747: configure hook missing reason it was invoked <snapd:Triaged> <https://launchpad.net/bugs/1672747>
<mborzecki> hm good news, i can reproduce the segfault when building snapd on xenial with go1.9.3
<Chipaca> pedronis: as a way of ensuring not only the integrity of a snapshot, but also its origin
<pedronis> ah
<pstolowski> zyga-ubuntu, the bug makes sense, but it's slowly improving with new hooks
<pedronis> Chipaca: if it has a serial yes, then it has a device key
<pedronis> that can be tracked to the serial
<Chipaca> pedronis: snapshots have a metadata file with hashsums of the archives themselves, so AFAIUI if I signed that (relatively small) file and included the signature, I'd be able to warn or block people from restoring snapshots that weren't created by their own host
<pedronis> should be doable in some way
<Chipaca> (i imagine adding a --ignore-signature or something)
<Chipaca> pedronis: ok, good to know. I'll pester you about it once everything else is shipshape.
<pedronis> depends on the attack you are trying to avoid, or is just not mismatching stuff?
<mborzecki> guys, is #4487 good to be merged now?
<mup> PR #4487: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<zyga-ubuntu> mborzecki: looking
<zyga-ubuntu> with 4 +1s, sure!
<Chipaca> pedronis: the attack is fairly contrived, in that you'd have to either be able to write to the spool directory where snapshots live (and in a properly configured system users won't even be able to read it), or convince an admin to accept a snapshot file somehow
<mup> PR snapd#4487 closed: cmd/snap: snap refresh --time with new and legacy schedules <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4487>
<zyga-ubuntu> mvo: can we do something about seccomp before 18.04?
<mvo> zyga-ubuntu: do somethng about it in what sense?
<pedronis> Chipaca: just saying that if you are root you can get the key that is used for signing
<Chipaca> pedronis: yeah
<zyga-ubuntu> mvo: make it so that on 18.04 we can enable the non-kill behavior
<pedronis> Chipaca: anyway IÂ suppose if people ship them somewhere and back it's a bit more interesting
<Chipaca> pedronis: I expect snapshots will be part of a backup solution that includes remote backups, yes
<Chipaca> but those things should be signed at a separate layer anyway
<Chipaca> pedronis: I think I'll check with jamie, and if he agrees it's too tenuous, i'll forget it
<pedronis> ok, np
<Chipaca> pedronis: thanks
<mvo> zyga-ubuntu: its tricky the updated libseccomp  is not out, but we might be able to split out this part of the work in a separate pr
<ikey> idk theres something charming about a security stack that opts to commit seppuku to protect the user
<zyga-ubuntu> mvo: upstream has not released it or it hasn't found its way into ubuntu?
<zyga-ubuntu> ikey: did snap-confine refuse to run for you? :)
<zyga-ubuntu> ikey: (hey :-)
<ikey> hey :) nah not recently, i meant the seccomp thing
<zyga-ubuntu> ikey: ah
<zyga-ubuntu> well, that's not seppuku, IMO it's like us shooting a thread because it asked to go to the loo
<zyga-ubuntu> the thread _asked_
<zyga-ubuntu> just saying no wasn't in the vocabulary
<ikey> yeh but i mean, going to the loo, during class time
<ikey> idk man..
<ikey> >_>
<zyga-ubuntu> yeah, so mean
<zyga-ubuntu> it's an _internal_ problem ;)
<ikey> lol
<zyga-ubuntu> I'd love to see that bug fixed, I'm wondering what we can do
<zyga-ubuntu> the kernel part is done now
<zyga-ubuntu> and everyting else is just userspace
<ikey> so distros just need to update libseccomp?
<zyga-ubuntu> it's complicated
<zyga-ubuntu> yes
<zyga-ubuntu> and golang bindings on top
<zyga-ubuntu> and it seems it's not even out upstream yet
<ikey> orite
<mup> PR snapd#4565 closed: httputil: include Go runtime version in user agent string <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>
<zyga-ubuntu> mborzecki: make sure the store team can parse that ^ talk to ... perhaps noise][ ?
<mvo> zyga-ubuntu: upstream has not released an new golang-seccomp
<ikey> its looking likely im going to need to rework my nvidia PR to account for some fedora weirdness
<zyga-ubuntu> mvo: is the upstream for the C and golang lib the same?
<ikey> looks like they stuff their entire tree under /usr/lib64/nvidia-304xx/*
<ikey> so idk if i need to do that as separate PR, commit or what
<ikey> given the one i have is marked accepted..
<zyga-ubuntu> ikey: no, just stack on top there
<zyga-ubuntu> thank you for caring about fedora!
<ikey> well we're all cousins in this world
<ikey> (not literally. that'd make christmas so freakin awkward)
<zyga-ubuntu> with RMS and linus smiling from a family photo on the wall
<zyga-ubuntu> ...
<zyga-ubuntu> weird silence
<ikey> XD
<mborzecki> hmm no segfault with go1.8.3
 * Chipaca gives up on emacs and goes back to paper
<mvo> zyga-ubuntu: its two different people. but the upstream C is also not released yet
<mvo> zyga-ubuntu: its just part of git
<mvo> zyga-ubuntu: and the golang is not yet part of git because there is no libseccomp yet released with the bits needed
<zyga-ubuntu> mvo: aha, I see; we can ask them to release or distro patch in ubuntu but I wonder how that complicates building the packages and the snaps
<zyga-ubuntu> mvo: craazy idea: what if snap-seccomp was a .. snap itself
<zyga-ubuntu> and we could pull it in to build the profiles
<zyga-ubuntu> (it's a bit chicken-eggy)
<zyga-ubuntu> but would work around building issues
<mvo> zyga-ubuntu: we distro patchi n ubuntu already, thats fine. but e.g. fedora is not distro patching
<ikey> aha. smoke break granted me the wisdom to fix the gl thing..
<pedronis> zyga-ubuntu: mborzecki:  that format is not standard afaik  (it would need to be system/version)
<mvo> zyga-ubuntu: if fedora would allow us to bundle the problem would also not exist
<zyga-ubuntu> mvo: I think we can bundle but we could also patch the packages there if maintainers agree
<zyga-ubuntu> pedronis: oh, thank you for noticing
<zyga-ubuntu> pedronis: so golang/...
<Chipaca> the forum seems very 502y today
<zyga-ubuntu> (or similar)
<pedronis> something like that
<pedronis> yes
<zyga-ubuntu> Chipaca: yes, it's 100% reliably 500s today
<pedronis> Chipaca: input on #4565
<mup> PR #4565: httputil: include Go runtime version in user agent string <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4565>
<pedronis> it's merged but IÂ think it needs tweaks
<mborzecki> pedronis: opening a followup with fixes in a minute
<Chipaca> hmmm
<Chipaca> that should be go/xyz
<mborzecki> Chipaca: pedronis: runtime.Version() already returns `go1.9.3`, that would make it golang/go1.9.3
<Chipaca> mborzecki: what does it look like with gccgo?
<pedronis> also a bit unclear whether it's useful?
<pedronis> mborzecki: what's the goal here?
<Chipaca> I'd be ok with go/goX.Y.Z if goXYZ is what runtime.Version returns
<pedronis> getting this in the logs?
<mborzecki> pedronis: yes
<Chipaca> pedronis: it'd be in error reports also
<pedronis> both could be done without changing the user agent
<pedronis> it's a bit strange to put the compiler there
<pedronis> otoh it's also the standard lib
<pedronis> mborzecki: what does go itself does?
<pedronis> it has a default user-agent afaik
<mborzecki> pedronis: also stdlib carries the http client
<pedronis> that we are overriding
<pedronis> we probably should do something similar
<mborzecki> pedronis: probably Go-http-client/1.1 (that's what they expect in the tests anyway)
<pedronis> mborzecki: zyga-ubuntu: anyway I fear this will also break the store
<pedronis> we need to be a bit careful
<mborzecki> Chipaca: pedronis: `golang/go1.9.3` then?
<pedronis> why the repeated go?
<pedronis> anyway I also need to check where to put it if at all
 * zyga-ubuntu -> important errand
<Chipaca> hmm
<Chipaca> mborzecki: problem
<mborzecki> i can always move the go runtime version string to daemon.go and log it there, after all i just want to see the version somewhere, don't really care if it's the user agent string
<Chipaca> go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]
<Chipaca> ^ runtime.Version() with gccgo
<pedronis> fun
<mborzecki> right, and go returns go1.9.3
<mborzecki> oh, w8, that's the whole string?
<Chipaca> mborzecki: "go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]"
<Chipaca> mborzecki: that's printed with %q for your enjoyment
<mborzecki> damn
<mborzecki> ok, i'll log it in the daemon
<mborzecki> and the store can keep guessing which buggy version of go http.Client was that :)
<pedronis> mborzecki: anyway, indeed as it is it would break the store parsing of it
<mborzecki> ok, i"ll open a pr reverting the change
<pedronis> the issue there is mostly putting it at the end IÂ think
<mup> PR snapcraft#1892 opened: meta: warn if version is not a string <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1892>
<mup> PR snapd#4566 opened: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4566>
<ikey> what do you use to format the C files in snapd?
<mborzecki> ikey: indent
<ikey> any sample invocation? i tried indent but it mangled the file
<mborzecki> don't laugh though please :)
 * ikey is only used to clang-format
<mborzecki> there's .indent in cmd
<mborzecki> `make fmt` should do the trick
<pedronis> mborzecki: or not, maybe I'm confused (regexps are fun that way)
<ikey> ah ty
<ogra_> mvo, i see xnox just made systewmd default to persistent journald logging ... https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 for your base 18 you might want to turn it off to not wear out MMCs
<mup> Bug #1618188: systemd journal should be persistent by default: /var/log/journal should be created <upgrade-software-version> <systemd (Ubuntu):Fix Released by xnox> <systemd (Ubuntu Xenial):Confirmed> <systemd (Ubuntu Zesty):Confirmed> <systemd (Ubuntu Artful):Confirmed> <systemd (Ubuntu
<mup> Bionic):Fix Released by xnox> <https://launchpad.net/bugs/1618188>
<pedronis> mborzecki: https://golang.org/pkg/runtime/#Version  says it could also be a hash and date
<ogra_> (oh, and indeed make sure /var/log/journal is writable
<ogra_> )
<mvo> ogra_: base-18 has everything writable
<ogra_> ouch
<ogra_> will you keep it that way ?
<mvo> ogra_: we will see if it works out, but whats the downside?
<niemeyer> https://forum.snapcraft.io/t/forum-offline-today-post-mortem/3760
<mvo> ogra_: thanks for the heads up, I will look into making sure this is not written to disk by default then
<Chipaca> niemeyer: Apologies for any inconvenience this may have cause*d* you.
<Chipaca> niemeyer: and thank you for getting it back up :-)
<zyga-ubuntu> niemeyer: hey
<zyga-ubuntu> niemeyer: woot, thank you for for the post morterm
<niemeyer> Chipaca: Thnaks
 * zyga-ubuntu makes lunch and reads
<niemeyer> Chipaca: *Thanks* :)
<Chipaca> niemeyer: I thought that was on porpoise
<Chipaca> :-)
<zyga-ubuntu> niemeyer: it's at least very comforting to know the forum died while making a backup :)
<pedronis> Chipaca: afaict runtime.Version() can be whatever :/
<niemeyer> zyga-ubuntu: Yeah
<Chipaca> pedronis: well, at least we know it's a string :-D
<niemeyer> zyga-ubuntu: We also have daily backups stored since August
<niemeyer> of the data, plus daily and weekly backups of the whole machine
<niemeyer> We have so many backups that I killed the system doing it
<zyga-ubuntu> niemeyer: sweet
<mborzecki> pedronis: Chipaca: #4566
<mup> PR #4566: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4566>
<Chipaca> I could use another review on #4556 and #4557 i think
<mup> PR #4556: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4556>
<mup> PR #4557: osutil: add DirExists and IsDirNotExist <Created by chipaca> <https://github.com/snapcore/snapd/pull/4557>
<mup> PR snapd#4566 closed: Revert "httputil: include Go runtime version in user agent string" <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4566>
<kalikiana> Hmmmm
<kalikiana> "snap lxd cannot use current base snap core because existing process are still using the old revision"
<kalikiana> That's a weird error. Was doing `lxc exec` there
<Chipaca> mborzecki: I did +1 it, but zyga merged it before github took my +1 and i think it then lost it
<Chipaca> Â¯\_(ã)_/Â¯
<zyga-ubuntu> kalikiana: that's a warning
<zyga-ubuntu> kalikiana: it means you could hop onto new core
<zyga-ubuntu> kalikiana: but you're using the old one because some lxc process is still alive
<Chipaca> zyga-ubuntu: you're on fire :-)
<mup> PR snapd#4556 closed: strutil/quantity: new package that exports formatFoo (from progress) <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4556>
<zyga-ubuntu> Chipaca: _high voltage_ :)
<zyga-ubuntu> kalikiana: if you restart your lxc things it should go away and you will see new core being used
<zyga-ubuntu> kalikiana: all processes belonging to a given snap see consistent filesystem
<kalikiana> zyga-ubuntu: I feel the message should've told me exactly that :-)
<kalikiana> zyga-ubuntu: Does the error come from snapd? Or LXD?
<zyga-ubu1tu> so
<kalikiana> zyga-ubuntu: I'll file a bug. Let's see if it can be improved
<zyga-ubu1tu> my machine crashed because when I went out of range BT went nuts
<zyga-ubu1tu> kissiel: ^
<zyga-ubu1tu> kalikiana: re
<zyga-ubu1tu> kalikiana: so about that, how would you rephrase that so that it's more useful
<zyga-ubu1tu> kalikiana: just tell me :)
<zyga-ubu1tu> or open a forum thread
<zyga-ubu1tu> it's a sub-optimal situation, we could perhaps have a hook for this
<zyga-ubu1tu> if there's no hook we could print a short line of text + forum link
<zyga-ubu1tu> and if there's a hook we could signal snapd and not print anything
<kalikiana> zyga: first of all it should reveal itself as a warning, for example by starting with "Notice:"
<kalikiana> zyga: although by showing me this message every single time I practically consider it an error since I can't actually ignore it
<kalikiana> zyga: It'd also be nice if it was phrased more like 'Notice: The "lxd" snap will continue to use "core" 3958 as a base until all its processes have been restarted via "snap restart lxd".'
<zyga> kalikiana: it's not true
<zyga> kalikiana: that's the problem :)
<zyga> kalikiana: the first part is okay
<zyga> but the remainder is not accurate
<zyga> snap restart lxd is not sufficient
<zyga> _all_ processes, including non-services, must terminate
<kalikiana> zyga: Well, if it's not accurate it's because I had to guess since it did not in fact tell me :-D
<zyga> (I lost my log) can you paste the original message again please?
<kalikiana> zyga: `snap lxd cannot use current base snap core because existing process are still using the old revision`
<ikey> phew. back to working snapd..
<mvo> zyga: 4342 is ready for a re-review (cc mborzecki I addressed your comments as well iirc)
<ikey> 4559 will need re-review too
<zyga> kalikiana: hmm hmm
<kalikiana> zyga: The "cannot use" wording makes it look like an error. And it's not telling me how to fix it.
<zyga> mvo: ack
<zyga> kalikiana: I don't dismiss the wording could be better
<zyga> just pondering on what it should be
<ikey> decided to be nice to those darn pesky fedora kids :p
<kalikiana> zyga: This is why I suggested to file it, didn't expect you to fix it on the spot :-P
<kalikiana> Oh, forum's back. I could also make a topic for it then
<zyga> kalikiana: yeah, let's do a forum topic, we can tweak that message before 2.31
<zyga> thank you for rising this
<greyback> jdstrand: hey, thank for the review of https://github.com/snapcore/snapd/pull/4545 Question on the AppArmorConnectedSlot advice - each snap has it's own /tmp - I was stuck on how a file in x11's /tmp is made available to another snap's /tmp. Is the rule label causing snapd doing some fancy /tmp combining? Or is it up to the plug's launch script to dig into the slot's /tmp and find the socket it needs?
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<greyback> s/it's/its/
<zyga> greyback: if you put the socket in $SNAP_COMMON
<zyga> you could use new content sharing features to inject that anywhe
<zyga> *anywhere
<zyga> so for the snap holding the socket and being the server it can be in $SNAP_COMMON
<zyga> and for any client snaps it could be in /tmp/somethingappropriatethatisdefault
<zyga> *magic*
<ikey> does snapd expose changelog functionality? like when i publish a new revision can i inform users of changes?
<zyga> you can do that in the store but I don't know if this is visible in many places
<ikey> ah ok
<ikey> future stuffs then
<zyga> it's a nice thing if it was accessible
<zyga> I mean
<zyga> you can fill it for each release
<ikey> sure
<ikey> and at some point in the future hook up UI bits
<kalikiana> zyga: https://forum.snapcraft.io/t/cannot-use-current-base-snap-core/3763
<zyga> ack
<greyback> zyga: I would if I could, but I'm snapping x11. It has /tmp/.X11-unix/X* hardcoded in
<kalikiana> zyga: I can't actually seem to get rid of it
<kalikiana> very broad use of killall doesn't help
<zyga> greyback: no, you didn't understand
<zyga> greyback: you can do that without touching x11
 * greyback re-reads
<zyga> greyback: the content interface lets you do those bind mounts
<zyga> greyback: I haven't tried this on a socket though so you may run into a limitation
<zyga> greyback: but even a tiny patch in x11 (or config tweak) to store the socket in $SNAP_COMMON is enough
<greyback> zyga: ack. I see what you mean. I'll give that a go.
<zyga> greyback: you must use master though
<zyga> greyback: and stick to $SNAP_COMMON for now
<greyback> ok
<zyga> greyback: (or edge)
<zyga> greyback: try it with dummy snaps and a writable file
<zyga> greyback: and the content interface
<zyga> in the end we can move this into the x11 interface properly
<greyback> *nod*
<greyback> more toys to play with!
<zyga> :D
<zyga> indeed
<zyga> and my child so let's see how it works, I'm eager to get feedack
<zyga> *feedback
<niemeyer> popey: Seen the announcement of godot 3.0 final being released yesterday.. did you ever get that to work?
<pedronis> mvo: Chipaca: can the 2_32 tag be created in the forum
<Chipaca> sure
<Chipaca> pedronis: but i can only create it by tagging something
<Chipaca> pedronis: ideally something that needs to be there for 2.32 :-D
<pedronis> ok, I suppose IÂ should talk with mvo about the when of those
<mup> PR snapd#4558 closed: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4558>
<Chipaca> pedronis: i think i have something i can tag
<Chipaca> pedronis: there
<Chipaca> and now, lunch
 * ogra_ grins about zygas comments on #4563 ... you should really talk to the devmem2 developers to have this fixed upstream :)
<mup> PR #4563: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563>
<ogra_> (that c file is just devmem2.c renamed ;) )
<zyga> ahh
<zyga> well, I'm just a C coder
<ogra_> :)
<mborzecki> bisecting go toolchain, so much fun
<Chipaca> pstolowski: you can't fallthrough a type switch
<pstolowski> Chipaca, aha! thanks, still learning about some corners of Go
<Chipaca> pstolowski: you also can't usefully enumerate things (i.e. if you do "case typeA, typeB:" you'll get the interface-y object in the case
<Chipaca> )
<pstolowski> k
<mup> PR snapd#4567 opened: cmd/snap-confine,tests: hide message about stale base snap <Created by zyga> <https://github.com/snapcore/snapd/pull/4567>
<jdstrand> greyback: you're right about the per-snap /tmp. if these were named sockets, there would be a problem, but they are abstract sockets (path starts with '@') so they aren't file backed and not affected by the mount namespace
<mup> PR snapd#4567 closed: cmd/snap-confine,tests: hide message about stale base snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4567>
 * kalikiana off for lunch, back soon
<kalikiana> zyga_: but before I leave, great to see this extremely quick PR , you are awesome:-D
 * kalikiana now really off for lunch
<greyback> jdstrand: aha. Ok. I didn't know that
<Beret> can someone remind me why I have multiple (more than 2) loop devices for a snap?
<Beret> I understand 2 for the theoretical purposes of rollback
<Beret> but why more than 2?
<mborzecki> bisecting the -linkshared segfault, the first bad commit is https://github.com/golang/go/commit/4808fc444307fa683bf3df6d55f9ad1828891a36
<mup> PR snapd#4568 opened: tests: new spead test for openvswitch-support interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4568>
<Chipaca> Beret: 3, so you can always rollback even in the worst case
<Chipaca> Beret: we might make it tunable at some point (there's a feature request for this already)
<Chipaca> Beret: but in any case you can already remove the prior ones with "snap remove <snapname> --revision <revno>"
<Chipaca> Beret: (the worst case is: you're on a "good" revision, you refresh to something newer, but it's a dud so you manually revert back to the known-good one; because we keep 3, you can still revert from there as well)
<Chipaca> Beret: hth
<cjwatson> sergiusens: is anyone on your team in fact working on the project to convert LP to be able to consume snapcraft as a snap?  I'm concerned about that having possibly fallen between the cracks
<Beret> Chipaca, ok, thanks
<mup> PR snapd#3456 opened: many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/3456>
<zyga_> brb
<sergiusens> cjwatson no, no one is; sorry, the communication has. I did discuss this with sparkiegeek
<cjwatson> sergiusens: was that today?  I talked about this with sparkiegeek this morning
<sergiusens> cjwatson capetown sprint
<cjwatson> sergiusens: must have slipped his mind.  I can take it over if it will otherwise end up not being done, just didn't want to duplicate work
<zyga_> re
<zyga_> sorry, small interrupt for kids
<sergiusens> cjwatson that would be appreciated. I am sorry it fell through the comm cracks
<cjwatson> all right, let's see what I can fit in
<pedronis> pstolowski: sorry it took a bit,  looks it's going in the right direction, did a pass over #4401
<mup> PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<pstolowski> pedronis, hey, no problem, and thanks!
<kalikiana> sliff
 * kalikiana seems to be online again, for some reason wlan didn't see any network for a while
 * kalikiana once again fell for the DENIED messages caused by the telegram snap looking for helpful logs
<pedronis> zyga: what's the status of #4471 ?
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga> pedronis: refactoring after feedback from a call, I'll push it in ~hour
<pedronis> thx
<mup> PR snapd#4550 closed: cmd/snap: improve output when snaps were found in a section or the section is invalid <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4550>
<seb128> jdstrand, hey, just for info I started as topic as discussed in CT, https://forum.snapcraft.io/t/confined-snaps-dont-work-on-live-images-due-to-apparmor-path-mapping/3767
<zyga> seb128: interesting, it's probably the same problem that prevented us from using overlayfs
 * zyga reads
<seb128> zyga, right
<zyga> seb128: replied
<seb128> zyga, thanks
<niemeyer> mvo: #4342 reviewed.. trivials only, thanks
<mup> PR #4342: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>
<mvo> niemeyer: \o/ thank you
<niemeyer> mvo: Thank you!  Nice abstractions
<blackboxsw> pedronis: do you know offhand about seeding --classic snaps? https://forum.snapcraft.io/t/seed-yaml-documentation/3050/4
<pedronis> blackboxsw: on a classic image?
<blackboxsw> on non-snappy environments
<pedronis> classic: true  in the seed entry for the snap  afair
<blackboxsw> so stock ubuntu cloud-images
<blackboxsw> ahh nice
<blackboxsw> will try that
<blackboxsw> thanks
<blackboxsw> and will update the post with the results
<pedronis> blackboxsw: I'm just back from holidays,  I put looking at that post in my queue
<blackboxsw> cheers. yeah I heard. Welcome back :)
<zyga> hmm mhmm
<jdstrand> seb128: thanks, noted and commented
 * jdstrand -> travel
<Chipaca> Q: what happens if you accidentally switch the implementations of, in essence, 'rm' and 'md5sum -c'?
<Chipaca> A: giggles
 * Chipaca takes a break
<zyga> jdstrand: safe travels!
<zyga> Chipaca: A: backups
<Chipaca> zyga: dude
<zyga> yes?
<Chipaca> zyga: i'm implementing snapshots
<Chipaca> ie backups
<Chipaca> zyga: :-)
<zyga> Chipaca: snap my home directory ;)
<Chipaca> i had the handlers for 'lose' and 'check' reversed
<Chipaca> :-)
<Chipaca> happy to have tests :-)
<zyga> lose drops the snapshot?
<Chipaca> zyga: yes
<zyga> Chipaca: just document it, it's not a bug if it's documented ;)
 * Chipaca takes note
<mvo> ikey: is 4559 good to go?
<ikey> em
<ikey> is that the one i did today i cant remember
<mvo> pr #4559
<mup> PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
<ikey> ah
<ikey> so the thing i wanted clarification on from Son_Goku was the libdir stuff
<ikey> like are we making this a compile time option or is it being vendor patched or what
<ikey> or do we just do more of the populate calls? cheap and cheerful
<Son_Goku> more of the populate calls
<Son_Goku> the issue with the other two is the multi-base snap nature of things
<ikey> so do you have a lib32 directory in fedora?
<Son_Goku> nope
<Son_Goku> and we really don't have any more permutations to worry about
<ikey> so populate isnt going to be the right approach
<Son_Goku> we have /usr/lib and /usr/lib64
<ikey> because you're going to get inverse libraries
<ikey> 32s in the 64
<Son_Goku> ah, right
<ikey> i mean it'll still technically *work* but its not "right"
<ikey> and i think the rest of the world is lib64/lib32
<Son_Goku> most of the world is lib/lib64
<ikey> with lib + lib64 being the same thing
<ikey> eh idk about that
<ikey> even arch uses lib32
<Son_Goku> Arch and Solus are lib32 / lib64
<ikey> right
<Son_Goku> Gentoo is fuck all
<ikey> lol
<Son_Goku> though they default to lib / lib64
<ikey> so ok we need to use --libdir as our /usr/lib there atm
<Son_Goku> Fedora, SUSE, Mageia, et al are lib / lib64
<ikey> and we need a new option for emul32
<ikey> so that we no longer assume
<ikey> assuming ofc on fedora you configure --libdir=/usr/lib64
<Son_Goku> right
<ikey> and we add like --with-emul32-libdir=/usr/lib ?
<Son_Goku> sure
<ikey> alright
<ikey> gimme a wee second here
<ikey> ty btw :]
<Son_Goku> you could also do detect-y things for this
<ikey> eh
<ikey> the smartest way to be smart is by not being smart
<Son_Goku> just sayin'
<Son_Goku> heh
<ikey> hm. autotools crap.
<ikey> so libdir will be wrong
<zyga> what is emul32?
<ikey> -m32
<Son_Goku> zyga: it's Solus' term for secondary arch
<ikey> i.e. 32-bit library
<ikey> no its the proper term
<ikey> emul32 == -m32 :P
<ikey> you're emulating 32-bit vdso on x86_64
<Son_Goku> well, -m64 also exists, are you saying that's emul64?
<ikey> with -m32
<ikey> no
<zyga> is that like x86
<ikey> because you have native binaries and libraries
<ikey> well you guys pick a name
<Son_Goku> zyga: on multiarch architectures, you can build from the same compiler for 32-bit and 64-bit
<ikey> idc what its called :P
<zyga> is that like x86? <- question
<Son_Goku> so on x86, you have x86_64 and x86_32
<ikey> -m32 will spit out x86 on x86_64 toolchain
<ikey> technically i686
<ikey> but ya
<Son_Goku> on aarch64 you have aarch64 and aarch32
<zyga> ikey: sure, but but that's a compiler switch
<Son_Goku> (which technically is also known as armv8hnl)
<ikey> sure and we're talking about biarch here
<zyga> what is the relationship to a filesystem path
<ikey> not multiarch
<ikey> biarch is locked to the notion of -m64 vs -m32
<Son_Goku> ikey: we could get into x32
<zyga> ikey: I see
<ikey> which is why -m32 is the emulated vdso
 * zyga likes multiarch
<ikey> someones gotta :P
<Son_Goku> zyga: debian platform libdirs has other issues
<zyga> everything has issues
<ikey> so what we calling this emul32 dir
<ikey> just lib32 ?
<ikey> --with-lib32-dir
<ikey> before i get dead cats mailed to me from gentoo devs
<Son_Goku> ikey: --with-lib32-dir, --with-lib64-dir
<ikey> why --with-lib64-dir?
<zyga> --i-wish-we-had-fat-objects-like-apple-did-decades-ago
<Son_Goku> ikey: Gentoo dev dead cat avoidance :)
<ikey> but --libdir is the native arch
<Son_Goku> true
<zyga> back to work
<ikey> lol
<Son_Goku> ikey: meeeby --with-alt-libdir ?
<Son_Goku> god damn naming things is hard :/
<Son_Goku> fuck it
<ikey> XD
<ikey> Son_Goku, "defaults"
<ikey> lol
<Son_Goku> --lib32dir
<ikey> #define NATIVE_LIB_DIR "${exec_prefix}/lib"
<ikey> i hate your face autotools
<zyga> man
<zyga> fat objects
<zyga> that's so simple :/
<ikey> nope
<Son_Goku> zyga: then make it happen
<ikey> don't want your bloat :P
<ikey> ah mind you i can use -D defines
<ikey> for native libdir
<zyga> Son_Goku: impossible, no way to reach consensus on something that is x10 nicer and x0.1 slower or more "computer has to do work" vs "humans need to do work" in our our community
<zyga> niemeyer: can you look at https://github.com/snapcore/snapd/pull/4471/files again please
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<niemeyer> zyga: Looking
<zyga> niemeyer: I'm trying to balance it so that I don't have to re-architect my stacked unit tests heavily and we can ship it in 2.31 with confidence; I postponed the idea to check if we need to poke holes
<zyga> niemeyer: I can do that after this RC because it will have impact on existing unit tests
<zyga> (sequence of things will change, churn, can cause bugs)
<zyga> niemeyer: I'll cherry pick the spread test into this PR so that it is really tested
<niemeyer> zyga: My suggestions would not involve any test changes at all
<zyga> niemeyer: yes, but we also discussed the idea to look at the filesystem to see if it's read only ahead of time
<zyga> and those would (we test the syscalls we do)
<zyga> (the order of syscalls would change and that's churn I want to avoid for 2.31)
<niemeyer> zyga: I understand.. just saying that the real goal was simplifying it
<niemeyer> zyga: Rather than changing behavior
<Chipaca> pedronis: do you remember in what situation a task's change could be nil? when looping over all tasks from state
<zyga> yeah, I think it's shorter now, we can go further but I want to not break it
<pedronis> Chipaca: looping how?
<zyga> I will now look at that spread tets and then at the PR with individual new unit tests
<Chipaca> pedronis: for _, tsk := range st.Tasks() {...}
<pedronis> Chipaca: that should filter out tasks that have no change
<pedronis> see its code
<Chipaca> pedronis: i see
<pedronis> it might be we are paranoid in a couple of places because historical reasons
 * ikey has a potential fix for that patch now
<ikey> just gonna test it..
 * zyga runs the new tests and waits for them to finish
<zyga> tea time :)
<Chipaca> pedronis: in snapstate's CheckChangeConflictMany there's an explicit check for nil which threw me :-)
<Son_Goku> ikey: thank god no one here cares about /usr/libx32 right now
<Chipaca> i guess that's one of the places
<Son_Goku> ikey: and yes, that's a thing
<pedronis> Chipaca: I don't think, it's needed nowadays
<ikey> i know it is
<ikey> but in our context no we dont care
<Chipaca> pedronis: thanks
<pedronis> we have the lock and Tasks() check for us
<Son_Goku> ikey: --with-alt-libdir is the best I can come up with
<ikey> doesn't make sense
<ikey> its strictly for "im 64-bit and need 32-bit"
 * ikey finds out if patches are borked from that
 * kalikiana wrapping up for today, can't decide if this was a productive day where trying to fix one bug lead to several other bug reports without solving the first one
<Son_Goku> ikey, fuck it, --with-32bit-libdir?
<ikey> cool, didn't hose it
<ikey> well my patch has --with-lib32-dir=DIR
<ikey> lol
<ikey> ill change
<ikey> though im not sure how good autotools is with numeric prefixes?
<ikey> guess we'll find out
 * Son_Goku groans at autotools
<Son_Goku> why isn't this Meson already...?
<ikey> --with-32bit-libdir       -- Use an alternate lib32 directory
<ikey> works
<Son_Goku> oh right, because 14.04 isn't dead yet
<zyga> Son_Goku: hold on, what are you tweaking?
<ikey> ive had to safe guard this change..
<ikey> you'll see in a sec
<Son_Goku> ikey: I'm guessing it defaults to lib64 and lib32?
<ikey> not /quite/
<ikey> you'll also need to change autogen for fedora i imagine
<Son_Goku> fuck
<Son_Goku> that's going to suck
<zyga> oho, linode handshake timeouts
<zyga> that's fine, I'll push the spread test on top anyway
<ikey> Son_Goku, https://github.com/snapcore/snapd/pull/4559/commits/c724c06a6a58e64c0a701cc78f9f5154164abe32
<mup> PR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>
<ikey> so instead of assuming /usr/lib, we set native libdir to `--libdir=` from configure time
<ikey> i.e. host arch
<ikey> if we're 64-bit, we'll then try to mount/copy the 32-bit alt set.
<ikey> otherwise don't do anything
<Son_Goku> right
<Son_Goku> so that looks roughly sane
<ikey> because we could clobber ourselves on 32-bit pure
<ikey> its about the only dumb-clever way i can think of right now
<Son_Goku> ikey: this means you need to add the logic to the Fedora spec :)
<Son_Goku> otherwise it can't test :P
<ikey> and i cant test fedora
<ikey> so idk what you want me to do there
<Son_Goku> spread will do that
<ikey> help a brutha out
<Son_Goku> I can give you a patch to add to your PR, if that helps
<ikey> i wont object
<ikey> lol
<ikey> as long as your autogen uses libdir logic (which it should already) you should be fine
<ikey> but for your packaging you'll want to expressly set 32bit-libdir now
<ikey> or w/e the hell we caleld it
<ikey> *called
<ikey> as the day closes, so does my mind.
<Son_Goku> hehe
<Son_Goku> I regenerate the autofoo on every build
<niemeyer> zyga: Definitely nicer.. sent another round
<zyga> niemeyer: thanks, looking now
<niemeyer> zyga: Sorry, please ignore my comment on the for loop
<niemeyer> zyga: I removed it, but not quickly enough
<niemeyer> zyga: This is much simpler as a recursive call
<zyga> niemeyer: ok
<zyga> niemeyer: I think you reviewed an earlier version I pushed and then I pushed the patches that dropped flags
<zyga> niemeyer: so some of your questions as in places that got removed now
<zyga> I'll start with the low hanging fruit and iterate, let's see what remains
<niemeyer> zyga: Ouch, thanks
<zyga> error: received an unexpected http response code (504) when trying to download https://api.snapcraft.io/api/v1/snaps/download/eFe8BTR5L5V9F7yHeMAPxkEr2NdUXMtw_6.snap
<zyga> hmm, store hicckups
<Son_Goku> ikey: http://kinginuyasha.enanocms.org/downloads/0001-Enable-support-for-handling-the-NVIDIA-proprietary-g.patch
<niemeyer> zyga: I still don't understand your comment on why lowLevelPerform is there
<niemeyer> zyga: It's a very awkward side effect whihc would be nice to avoid
<ikey> what in the shite is that
<zyga> niemeyer: mount and umount don't care if the medium is read only
<zyga> niemeyer: symlink needs to drop a new inode
<niemeyer> zyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me
<zyga> niemeyer: it is there to triggere the read-only-filesystem fallback
<ikey> Son_Goku, honestly i dont feel comfortable applying that which i dont know
<Son_Goku> ikey: a patch you apply with git-am ?
<ikey> alright
<ikey> but everyone saw that Son_Goku made me do it
<Son_Goku> ikey: unconditionally turns on nvidia-biarch
<zyga> oh, did I, sorry, I meant mounting
<Son_Goku> and also sets the libdir in arches that are configured for multilib
<niemeyer> zyga: I realize it's there for that reason.. I don't understand why it's there for that reason
<ikey> gotcha
<ikey> i pushed it Son_Goku and now we'll wait for the sound of screams
<Son_Goku> :D
<ikey> cheers :]
<Son_Goku> kanpai!
<Son_Goku> well, I'm a dumbass
<zyga> niemeyer: right, the reason is that the code is like <create inodes><handle read only and retry><mount>
<Son_Goku> ikey: can you fix the title of the patch
<Son_Goku> it should be prefixed with "packaging/fedora:"
<zyga> niemeyer: both mount and create symlinks is in the low-level part
<niemeyer> zyga: Again, per above, zyga: You say file creation relies on existing inodes, which doesn't make a lot of sense to me
<zyga> niemeyer: now if you had a path like /rofs/symlink -> target
<zyga> niemeyer: ^ (I meant *mounting*, not file creation)
<ikey> Son_Goku, but
<ikey> but i pushed it
<Son_Goku> rewrite it :P
<zyga> niemeyer: and assuming that /rofs exists
<ikey> and they get angry when i force push
<Son_Goku> meh
<Son_Goku> just do it
<ikey> but they can hear us
<ikey> ._.
<zyga> niemeyer: that won't do anything in the <create inodes> part
<Son_Goku> XD
<zyga> niemeyer: it will proceed to c.lowLevelPerform where we just create the symlink
<niemeyer> zyga: Again, can we please talk about the difference between these branches
<zyga> niemeyer: and that's when we will notice EROFS
<niemeyer> zyga: how can  +		err = secureMkfileAll(path, mode, uid, gid)
<ikey> zyga, humbly request permission to force push fixed patch to PR
<niemeyer> zyga: do the right thing, but  +		err = secureMkdirAll(path, mode, uid, gid)
<niemeyer> not?
<ikey> Son_Goku, but now your commit message is too long
<Son_Goku> fuck
<ikey> ima leave it. :3
<zyga> niemeyer: those both do the right thing, the problem is not between directories and files but between the actual symlink at the end of some directories;
<niemeyer> zyga: I see.. so this links with the other part of the code
<niemeyer> zyga: Regarding the comment below on "Curious that this isn't the case for files. What's the catch?"
<zyga> hold on, I didn't read that comment yet
<Son_Goku> ikey: noooo
<zyga> ah
<niemeyer> zyga: Looks like a special case is creating more special cases
<ikey> lol @ describing hacker news
<Son_Goku> ikey: http://kinginuyasha.enanocms.org/downloads/0001-packaging-fedora-Enable-support-for-the-NVIDIA-propr.patch
<Son_Goku> there, fixed title
<ikey> but it runs off
<zyga> niemeyer: files and directories are completely created by secureMk* helpers, you end up with the complete thing, the error is correct if something goes wrong
<ikey> like a terrified thomas the tank engine suddenly bereft of child to push it
<niemeyer> zyga: I understand :)
<Son_Goku> ikey: it won't run off in GH
<zyga> niemeyer: for symlinks we don't have a helper like that, we use the secure dir helper to create the parent, that's it
<Son_Goku> and that's all that matters :)
<ikey> Son_Goku, but zyga didnt give me a yay
<niemeyer> zyga: These comments are supposed to raise awareness and discuss ceratin things
<Son_Goku> zyga: >:|
<niemeyer> zyga: I can tell that createFlie creates a file :)
<ikey> lol..
<Son_Goku> damn it, I've burned my entire lunch period on this :(
<Son_Goku> I gotta go get food
<niemeyer> zyga: In this case, we have a special case that chains up into more special cases, which cause functions to be called in different places, which creates more special cases
<ikey> disappear, its not like i do anything or go anywhere
<niemeyer> zyga: This is part of the reason why we get white hair
<zyga> niemeyer: but we reuse code that was reviewed for security, this is deliberate
<niemeyer> zyga: /o
<niemeyer> \
<zyga> niemeyer: I think it can be simplified but post 2.31, by doing the "look before you try"
<zyga> then we can drop the low-level perform exception paths
<zyga> and the special case for symlink will go away
<niemeyer> zyga: We can do whatever we want later, sure.. but we want this logic to not suck to begin wiht
<niemeyer> zyga: https://hangouts.google.com/hangouts/_/canonical.com/snappy-devel?authuser=1
<zyga> joining
<zyga> or
<zyga> joined
<zyga> empty?
<niemeyer> That's also part of why we get white hair
<zyga> niemeyer: can you hear me
<cachio> zyga, I am installing uuid-runtime package in a snap and it is not starting the uuid daemon
<cachio> zyga, should it happen automatically as if I install the deb package, or I need to manually do it ?
<sergiusens> how do I debug this error "error: cannot install snap file: snap is unusable due to missing files; contact developer"... I am the developer :-)
<niemeyer> sergiusens: Looks like you have a completely broken snap
<niemeyer> sergiusens: you should use snapcraft ;P
<bdx> hey, random question, has the concept of "serverless snaps" ever been discussed?
<zyga> cachio, ikey, Pharaoh_Atem: I if you can wait for a few quarters I would like to finish this branch for 2.31 first please
<cachio> zyga, sure
<ikey> quarters?
<Pharaoh_Atem> quarters?
<nacc> bdx: what do you mean by that?
<cachio> mvo,  I am installing uuid-runtime package in a snap and it is not starting the uuid daemon
<ikey> like, a few quarters would be years
 * ikey is puzzled
<cachio> mvo, should it happen automatically as if I install the deb package, or I need to manually do it ?
<nacc> Pharaoh_Atem: ikey was responding to zyga
<cachio> mvo, should I do it with the configure hook?
<zyga> hmmm hmm sorry,
<bdx> nacc: like a snap that is built to run on a serverless architecture
<Pharaoh_Atem> nacc: I was highlighted too?
<zyga> I meant few multiples of 15 minutes
<ikey> oh
<ikey> xD
<zyga> how do I say that properly?
<Pharaoh_Atem> ahhh
<Pharaoh_Atem> quarters is right, it's just no one says it
<Pharaoh_Atem> in that context
<ikey> idk id say like "half hour" "45 minutes" "feck off im busy"
<zyga> :D
<ikey> etc
<cachio> mvo, or in a wrapper?
 * zyga hugs ikey 
<zyga> ikey: yes, go push
<nacc> bdx: you mean without a store?
 * ikey doesn't do normal though
<ikey> lol
<zyga> cachio: dunno, I will check soon, if you need uuid's you don't need a daemon tho, maybe there's a cheaper way?
 * ikey coughs while -f goes through
<cachio> zyga, I want to test that
<niemeyer> nacc: No, he's likely thinking of Google AppEngine, Amazon Lambda, etc
<nacc> niemeyer: oh
<nacc> niemeyer: seems like you'd have a better answer for that than me :)
<niemeyer> bdx: The purpose of snaps is to install software on a machine, so it's not a great fit for the idea of not having a machine. With that said, ...
<nacc> heh
<bdx> take aws lambda for example
<niemeyer> bdx: We've been working from day one with the idea of minimalist operating systems that are built entirely around the idea of snaps
<bdx> ahh I guess it wouldnt be a snap because a snap needs snapd huh
<bdx> ahh I see
<niemeyer> bdx: That's what Ubuntu Core is, for example.. there's very little other than snaps in the machine
<ogra_> cachio, cat /proc/sys/kernel/random/uuid
<ogra_> (if your snap has access to that node indeed)
<bdx> niemeyer: totally, I see
<niemeyer> bdx: Even the root filesystem itself is a snap, so read-only and mostly unchangeable
 * ikey suddenly twigs that all parts of ubuntu core are segregated into domains with ACL and is impressed
<zyga> cachio: test the daemon?
<bdx> niemeyer:
<bdx> I see
<zyga> ogra_: yep, thanks! cachio, that was my suggestion (I didn't spell it out)
<cachio> zyga, I need to see if the daemon is able to read from /run/uuidd/request
<ogra_> cachio, then our snap will need an app entry for the daemon
<ogra_> in snapcraft.yaml
<zyga> cachio: I see, that's for some interface test?
<cachio> zyga, yes
<bdx> nacc, niemeyer: it was just a wild idea, I've been using lambda quite a bit lately, and getting to put my eyes on how the packaging is done via different serverless frameworks
<mup> PR snapd#4569 opened: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569>
<nacc> bdx: sure, interesting question
<cachio> I have the service script in /etc/init.d/uuid
<ogra_> yeah, not useful
<ogra_> check what the iit.d script calls and translate that into an app entry
<ogra_> see the bottom of  https://forum.snapcraft.io/t/how-to-set-hwclock-on-a-realtime-clock/3684
<sergiusens> niemeyer thanks for getting back to me, I stripped everything and even simplified the command https://paste.ubuntu.com/26490731/ (I am beta for core btw)
<sergiusens> I still see the issue
<niemeyer> bdx: Yeah, it's a nice idea, but that kind of platform almost always requires custom coding towards it
<bdx> entirely
<niemeyer> bdx: Which conflicts a bit with the underlying goal of snaps.. snaps need to support people's software as their developers choose to work
<niemeyer> This is also an advantage, as the approach encourages less lock in
<bdx> right, i see that, but what if there was a "snap type"
<bdx>  lets say, a "serverless" snap type, would package for a targeted serverless platform
<bdx> https://github.com/Miserlou/Zappa/#how-zappa-makes-packages
<niemeyer> bdx: Sure, that would work fine.. but most of the problem of creating a "serverless" platform is still there
<bdx> zappa (though young) has an interesting approach of just swapping out the packages with ones for the target serverless platform (just aws right now)
<cachio> ogra_, trying that, tx
<bdx> but other serverless frameworks will build the deps on a docker target platform and etc etc
<niemeyer> bdx: I doubt it
<bdx> ?
<niemeyer> bdx: The hard problem in serverless is the software lifecycle.. you want something lightweight, and you need to control when it comes and goes very tightly.. often you need to be in the loop for controlling sockets, etc, because you don't want these aspects to be visible to the world
<bdx> ah yes
<niemeyer> bdx: You can put that software inside a snap, docker image, rpm, deb, tarball.. it matters little
<bdx> totally
<niemeyer> bdx: It ends up just as an implementation detail on something that you need to cook for from the ground up
<niemeyer> bdx: You could use snaps as a lightweight confined space for the application, but that would be 3% of the problem IMO
<bdx> so I have snap/ dir in my projects now, and also a serverless.yml file ... I feel like the packaging the serverless frameworks are doing is such small subset of what snapcraft can do
<bdx> just an idea
<bdx> niemeyer: thanks for the insight
<bdx> nacc: ^
<niemeyer> bdx: No problem.. and yeah, the packaging is indeed the easy part of serverless, but it's also the hard part of solving software distribution
<niemeyer> bdx: We focus on the latter
<bdx> I see that, totally
<niemeyer> bdx: As a side note, I deploy all of the services I'm responsible for as snaps in tiny machines
<niemeyer> bdx: Not serverless, but cheaper than serverless, and almost as neat
<niemeyer> bdx: and nicer, from the perspective of giving me freedom of technology
<ikey> yay for marketing misnomers
<ikey> "serverless"
<bdx> neimeyer: totally
<zyga> ikey: I will drop my job and work electricityless cloud
<niemeyer> ikey: It's like "sugar free".. :)
<zyga> I will call it "BYOM"
<ikey> niemeyer, nah that one makes sense
<ikey> they don't charge you any extra for the sugar
<niemeyer> ikey: Until you figure what they use instead
<ikey> mm
<zyga> niemeyer: please have another look
<zyga> niemeyer: I'll double check I didn't miss anything
<niemeyer> zyga: Thanks
<ikey> btw apparmor made my boot slow. :P
<ikey> its half of my boot time in a VM now
<zyga> I will do the proper secure symlink next, though it won't affect this code, just the implementation of secureMklinkAll
<ogra_> assertions assertions ...
<zyga> ikey: caching can be improved
<ikey> im tackling it this week
<zyga> ikey: apparmor has a cache, maybe you're not using it?
<ikey> solus isn't known for slow boot lol
<zyga> ikey: each time a profile is compiled it can (optionally) be cached
<zyga> ikey: also loads can use cache (even exclusively, without compilation)
<ikey> ya im gonna teach usysconf to recompile them
<ikey> and then an early unit to load the cache
<ikey> already got plans, just wanted to complain :P
<zyga> niemeyer: I think it's all done (except the ", or create" typo I didn't push to let this spread batch finish)
<zyga> niemeyer: I'll work on itty bitty more secure mksymlink now that I have it un utils
<zyga> niemeyer: oh, and one more thing, please look at the new spread test as well
<zyga> I'll warm my tea up and be back in a moment
<niemeyer> zyga: Haven't seen the test, but what I've seen look GREAT, thank you!
<niemeyer> zyga: Just one final note there and LGTM
<zyga> niemeyer: thank *you* :)
<zyga> niemeyer: that's not an error there, it's a "was it present" flag, I guess we can just error out if it's empty but we don't usually do that kind of validation here (we just try and fail)
<niemeyer> zyga: I don't understand what the code is suggesting right now
<niemeyer> zyga: It surely doesn't seem sensible to create symlinks with completely wrong values
<niemeyer> zyga: Sending garbage to the kernel for validation is unwise
<zyga> Chipaca: problem with snap validation (CC sergiusens)
<sergiusens> posted to the forum
<zyga> mvo: ^ we may need rc3 if we relase with this bug
<zyga> https://forum.snapcraft.io/t/snap-is-unusable-due-to-missing-files-contact-developer-i-am-the-developer-no-idea-what-to-do/3771
<zyga> now that this is approved I will pull in unit tests, too many changes for critical feature not to test this
<zyga> I'll make a separate PR and mark it for 2.31
<zyga> mvo: do you plan to release tonight?
<sergiusens> stgraber Odd_Bloke the simplestream images on Ubuntu seem to have lost their aliases (lxc launch ubuntu:xenial works no longer, does by hash)
<sergiusens> sorry, bad first root causing of that, there are aliases, but `lxc launch ubuntu:xenial` does not work, using `images:` does
<sergiusens> confirmed that the aliases are there `lxc image info ubuntu:069b95ed3a60`
<zyga> ah, I know what I broke now ^_^
<sergiusens> stgraber a reinstall of the snap solved it, but I disabled ipv6 and switched from zfs to dir
<cprov> elopio: when you have a minute, can you take a look at https://travis-ci.org/snapcore/snapcraft/jobs/335296918 ? I am trying to fix the snapstore pre-rollout checks (broken since snapcraft started using stages). Apparently I have no access to the cache where the snapcraft is stored.
<elopio> cprov: yes, give me a minute. I'm sorry we broke you :S
<cprov> elopio: no worries, in theory, it's much simpler to do what we need now
<elopio> cprov: I'm not quite sure, because we were able to use the cache by not using the environment variables. I totally forgot that you sent environment variables to set the credentials.
<elopio> maybe it's that. I'm digging into the logs.
<cprov> elopio: `error: cannot open: "snaps-cache/snapcraft-prfalse.snap"` from `sudo snap install snaps-cache/snapcraft-pr$TRAVIS_PULL_REQUEST.snap --dangerous --classic`, I assume
<elopio> cprov: can you show me the script that you are calling to trigger the api?
<cprov> elopio: moreover I don't think we need the snapcraft snap installed to run `snapcraft/tests/integration/store` tests, do we ?
<elopio> cprov: yes, it uses the snapcraft command. What you don't need is to build the snap, you could just install from edge.
<elopio> cprov: but this one is different than the one you linked: https://travis-ci.org/snapcore/snapcraft/builds/335153368 I was wondering if you are doing something to select the stage.
<cprov> elopio: the job you linked was the 'old' way that didn't consider stages, it was running everything and taking 4h+
<elopio> right. We could readd the skips, and make sure that we install from edge, not from cache.
<elopio> cprov: so, you added that "stage" keyword?
 * zyga eats supper, secure symlink helper almost done :)
<mup> PR snapcraft#1893 opened: cli: use C.UTF-8 if locale not set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1893>
<cprov> elopio: yes, I am overriding 'jobs' completely, but the 'cache' config is preserved, I think I just don't have perms to access it
<elopio> cprov: what would you think about this? https://paste.ubuntu.com/26491166/
<elopio> you send SNAPCRAFT_COMMAND_INSTALL="sudo snap install snapcraft --edge --classic"
<Chipaca> sergiusens: journalctl -u snapd | grep container <- should show you the errors from 'snap try'
<Chipaca> sergiusens: I'll push a PR to make snap try log to stderr instead of journal, I think
<Chipaca> but not today, mostly because I think it might be tricky :-)
<ali1234> is there an example of snapping a php/composer application?
<cprov> elopio: looks good, let me know when it lands in trunk
<zyga> re, :)
<zyga> one last patch and I'm goooood :)
<zyga> and I celebrate
<elopio> kyrofa: cprov: https://github.com/snapcore/snapcraft/pull/1894
<mup> PR snapcraft#1894: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894>
<elopio> please double check my bash ^_^
<mup> PR snapcraft#1894 opened: tests: allow to overwrite the snapcraft install command <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1894>
<stgraber> sergiusens: hmm, might have been a bad cache of the streams, would have self-corrected after an hour, restarting the daemon (systemctl reload snap.lxd.daemon) would also have done the job if that was the issue
<zyga> SIGH
<zyga> there is no syscall.Symlinkat in golang
<zyga> .. but why golang, why :/
<Chipaca> zyga: because it's in x/sys/unix
<Chipaca> zyga: but before you get too excited, that means it's not buildable on ppc
<zyga> Chipaca: I just found https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L111
<zyga> thank you for pointing out x/sys/unix, let me see if it works
<zyga> I need it
<zyga> or I need that single generated function
<Chipaca> zyga: grab the generated one for now until we drop ppc
<zyga> Chipaca: yeah, sounds like a plan
<Chipaca> zyga: but
<Chipaca> zyga: SYS_SYMLINKAT will be per-something
<Chipaca> but you have a ppc box so you should be able to figure it out
<zyga> hehe yes :)
<zyga> it's allright
<Chipaca> the weirder ones might require you go grep includes :-)
<zyga> Chipaca: or ... you know... put -
<zyga> -1
<zyga> not that someone will test them, right?
<zyga> ;-)
<Chipaca> zyga: autopackagetest is a harsh mistress
<Chipaca> autopkgtest*
<Chipaca> haven't seen it fail in too long, already forgetting its face
<zyga> offtopic
<mvo> Chipaca: hey, this `snap try` issue from the forum, what is your take on it? sorry, missed some discussion so just want to get up-to-speed
<zyga>  // mksyscall.pl -tags linux,amd64 syscall_linux.go syscall_linux_amd64.go
<zyga> FRELLING PERL?
<Chipaca> zyga: ideal for the job
<zyga> Chipaca: ... but... python
<Chipaca> frobbing text? hell yeah perl
<zyga> hell no cobol
<Chipaca> zyga: not as widely available as perl
<zyga> it's like cobol but misassociated wiht the text tool
<zyga> Chipaca: not buying that
<Chipaca> mvo: the snap wouldn't work with the older snapd
<zyga> Chipaca: especially at google where they don't give a *** about non google arches
<Chipaca> mvo: (i know not only because i wrote the verifier, i also checked :-) )
<Chipaca> zyga: Â¯\_(ã)_/Â¯
<mvo> Chipaca: ok, so anything that needs to be done for 2.31 there? or can I ignore it for 2.31?
<Chipaca> zyga: you work for a company that doesn't give a flying asterisk for some architectures, but you still don't paint yourself into a corner just in case the company has a change of heart
<zyga> Chipaca: I mean python works anywhere, BSDs, windows, macos, you name it
<Chipaca> mvo: there's an argument for making 'snap try' write the errors to stderr for the same reasons 'snap pack' does
<zyga> it's not like it's less portable than perl
<zyga> and people who write competent perl are ... older
<Chipaca> zyga: you're talking about people that worked on the implementation of plan 9
<zyga> oh
<mvo> Chipaca: that sounds reasonable, is that something I should wait for? i.e. will it happen soon(ish)?
<Chipaca> zyga: I don't think they think perl is for older people
<zyga> that's a very valid point
<mvo> Chipaca: i.e. before tomorrow lunchtime :)
<zyga> Chipaca: perl is that new thing :)
<Chipaca> mvo: it's not going to be a simple change
<mvo> Chipaca: ok, then I will not wait
<mvo> Chipaca: out of curiosity, why is it not simple?
<Chipaca> mvo: there's another argument for changing the error message
<Chipaca> mvo: but nobody has suggested changing it to _what_ :-)
<Chipaca> mvo: because 'snap try' is async, meaning the logs would need to get shipped, and it might mean we need to make the roundrobin logs in tasks be bigger, and some tweaks to how 'wait' prints them
<mvo> Chipaca: meh, sounds horrible. ok
<zyga> Chipaca: just error with the 1st error :)
<Chipaca> tasks have logs, but they're either informational (in which case if you miss printing them, oh well), or errors in which case they're not changing (because the thing died)
<mvo> Chipaca: I will ignore this for now until I'm told otherwise. especially if this is a broken snap (not a false positive)
<Chipaca> I _could_ make the whole thing die, yes
<zyga> Chipaca: we don't vendor x/sys/unix today, do we?
<Chipaca> return strings.Join(allTheErrors, " Â¯\_(ã)_/Â¯ ")
<zyga> it'd be a re-addition?
<mvo> Chipaca: its all good, I need to rest anyway
<Chipaca> zyga: it does not build on ppc
<cachio_> mvo, is rc2 comming?
<zyga> meh meh
<zyga> ok
<mvo> cachio_: :( tomorrow, sorry
<zyga> I think today is my time
<Chipaca> zyga: i'm sure they take patches though
<zyga> I'll watch and merge 4471
<mvo> cachio_: there is this one PR from zyga  that we want in
<zyga> and fight the symlinkat problem tomorrow
<zyga> Chipaca: as self-documenting perl files ;)
<cachio_> mvo, sure
<Chipaca> zyga: hey, i've written literate perl
<Chipaca> zyga: wait
<Chipaca> zyga: you called me old!
 * Chipaca is old
<cachio_> hehehe
 * zyga is old 
 * zyga hugs Chipaca 
 * mvo hugs Chipaca and zyga 
 * Chipaca hides http://ftp.tudelft.nl/cpan/authors/00whois.html
 * cachio_ laugh
<zyga> OMG :D
<zyga> the journey of each generation
<Chipaca> the internet does not forget
<Chipaca> sadly
<zyga> ok
<zyga> I'll break now
<zyga> travis is stuck
<zyga> please merge 4471 if green
<pedronis> Chipaca: did you see the original code was about java and PATH: $SNAP/... ?Â IÂ suppose it doesn't change anything
<Chipaca> pedronis: yes; the commands are not looked up in the path
<Chipaca> that seems to be the source of the problem
<Chipaca> or rather, of the misunderstanding
<Chipaca> sergiusens: you around?
<Chipaca> zyga: 4471 not green
<Chipaca> getting lots of failed prepare project :-(
<zyga> yeah :/
<zyga> I'm watching
<zyga> like a western with intense action :///
<sergiusens> Chipaca at the snapcraft summit currently, might be faster if we do a call
<Chipaca> sergiusens: I should be in bed. Tomorrow?
<sergiusens> Chipaca ok; also tired the completer changes using the snap name and it still doesn't work; I'll send you the link to the built snap
<Chipaca> sergiusens: thanks
<sergiusens> tabs are for UI purposes
<Chipaca> sergiusens: _vertical_ tabs?
<sergiusens> Chipaca yes
<Chipaca> 013 is \v is vertical tabs; a very strange choice (but then, if that's indeed what they're doing, it should be fine)
<Chipaca> ok :-)
<zyga> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga> tar: /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz: Cannot open: No such file or directory
<zyga> hmmmmm
<Chipaca> zyga: everything is terrible
<zyga> Chipaca: mvo will _love_ the release tomorrow
<zyga> wililupy: 11
<zyga> (also known as window 11)
<wililupy> ?
<zyga> wililupy: sorry, bad tab completion
<zyga> THERE IS NO MISSILE INCOMING TO HAWAII
<wililupy> zyga: no worries ha
<mup> PR snapcraft#1895 opened: docker: beta should use beta, edge use edge <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1895>
<mup> PR snapcraft#1894 closed: tests: allow to overwrite the snapcraft install command <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1894>
<mup> PR snapcraft#1893 closed: cli: use C.UTF-8 if locale not set <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1893>
<mup> PR snapcraft#1895 closed: docker: beta should use beta, edge use edge <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1895>
<cprov> sergiusens: thanks, let me try the test suite hack
<nacc> so i've got a snap (git-ubuntu) that builds its own python3 (we need a version more recent than 16.04's)
<nacc> what is the "right" way to CI the code upstream so that our tests are running against hte version in the snap
<mup> PR snapcraft#1896 opened: elf: do not strip rpaths that contain $ORIGIN <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1896>
<mup> PR snapcraft#1897 opened: docker: user proper tags in Readme.md <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1897>
#snappy 2018-01-31
<mup> PR snapd#4471 closed: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4471>
<mup> PR snapcraft#1897 closed: docker: user proper tags in Readme.md <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1897>
<mup> PR snapcraft#1898 opened: docker: don't rely on snapcraft-classic <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1898>
<zyga> kyrofa: the fixes are merged, please try edge and report any weird stuff
<zyga> kyrofa: rc2 tomorrow
<zyga> kyrofa: (early morning)
<zyga> so you can be on beta to see it
<mup> PR snapd#4561 closed: tests: generic detection of gadget and kernel snaps <Created by plars> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4561>
<kyrofa> zyga, you got it, thanks man :)
<kyrofa> Yeah looks like RC1 now, when I see RC2 I'll give it a shot
<zyga> kyrofa: tomorrow morning
<zyga> I'm baby sitting the last PR
<mup> PR snapd#4559 closed: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4559>
<mup> PR snapd#4342 closed: userd: add support for a simple UI that can be used from userd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4342>
<mwhudson> i wonder what's going on here https://launchpadlibrarian.net/355232767/buildlog_snap_ubuntu_xenial_armhf_go-tip_BUILDING.txt.gz
<mwhudson> i bet it's made an arm64 binary for some reason
<zyga> mwhudson: hey
<mup> PR snapcraft#1898 closed: docker: don't rely on snapcraft-classic <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1898>
<mwhudson> zyga: hello
<zyga> exec format error, never saw that one
<zyga> yeah, feels like wrong arch
<zyga> (but how?)
<mwhudson> no idea
<zyga> mwhudson: offtopic, can you please look at https://bugs.launchpad.net/snapd/+bug/1745584 - maybe it's just a missing policykit file in packaging?
<mup> Bug #1745584: pkexec dialog doesn't appear for 'snap install' on Debian <snapd:New> <https://launchpad.net/bugs/1745584>
 * zyga should go to sleep 
<mwhudson> zyga: mmm could be
<Son_Goku> mwhudson, i dunno, it doesn't work in centos even with the polkit file installed
<mwhudson> yeah, looks like the polkit file is installed in debian too
<mwhudson> data/polkit/io.snapcraft.snapd.policy /usr/share/polkit-1/actions/
<Son_Goku> same goes for Fedora
<Son_Goku> I've been installing it for a while, no effect
<Son_Goku> mwhudson: wait, this bug is about "snap install"?
<Son_Goku> snap install doesn't query polkit at all
<Son_Goku> like, zilch
<Son_Goku> only GNOME Software does
<Son_Goku> if that's supposed to work with "snap install" too, then this is horrifically broken
<kyrofa> Hey tyhicks, if you're around, what is the status of using errno instead of kill for seccomp denials?
<Son_Goku> mwhudson: https://src.fedoraproject.org/rpms/snapd/c/98b119302ae0d8d502f20877e0ecbf76a64ac1c9
<Son_Goku> yeah, I've been installing it and it doesn't have effect :/
<tyhicks> kyrofa: hey - it sounds like it is stuck waiting for a libseccomp-golang release and for other distros to include that release :(
<tyhicks> kyrofa: https://github.com/snapcore/snapd/pull/3998/#issuecomment-358028579
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<tyhicks> kyrofa: I haven't had a chance to look into falling back to KILL if the available libseccomp-golang isn't new enough
<tyhicks> all underlying work upstream and in Ubuntu is done
<kyrofa> tyhicks, excellent, thank you very much :)
<tyhicks> no problem
<tyhicks> I wish it was already working but there were a lot of moving parts
<kyrofa> Oh totally, glad to see it moving along though
<kyrofa> We were just chatting about it at the sprint and none of us knew where the work stood. So now we do!
<Son_Goku> kyrofa: either you or zyga could poke the maintainers of libseccomp and golang-github-seccomp-libseccomp-golang about backporting these things to current Fedora releases if it's ready to go
<Son_Goku> (since both of you have FAS accounts, you're also able to do PRs against the packaging repos for both of these
<Son_Goku> )
<mup> PR snapcraft#1899 opened: elf: readelf dependency <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1899>
<mborzecki> morning
<Chipaca> mborzecki: morning
<mborzecki> Chipaca: hey
<mborzecki> Chipaca: sorry :)
<zyga> o/
<zyga> drat
<zyga> I wanted to sleep
<Chipaca> mborzecki: :-)
<mborzecki> Chipaca: fwiw will looking at ProcessState be enough?
<zyga> last night tests were utterly broken on networking
<zyga> let's see how if today they fare better
<Chipaca> mborzecki: not really, i think using a flag variable is the only way
<Chipaca> mborzecki: the command just knows it was killed, not by whom
<mborzecki> Chipaca: right
<mborzecki> Chipaca: otoh maybe it's not worth it, unless the caller does something silly with the error the way it's now should be fine
 * zyga has zero PRs open, that's ... new
<Chipaca> mborzecki: that was what I thought when I wrote it, but then I thought maybe we want to behave differently if the Run error is context.Canceled
<mborzecki> Chipaca: imo adding a comment instead of a flag will be ok too :)
<pstolowski> good morning
<zyga> hey paweÅ!
<mborzecki> zyga: pstolowski: morning
<doko> https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on most archs
<Chipaca> mborzecki: it'd look like https://pastebin.ubuntu.com/26493696/
<zyga> doko: thank you for the heads up, we'll look into it
<kalikiana> mornin'
<zyga> hey kalikiana
<doko> zyga: now given back. but seriously, hit the uploader for each day and one arch that this wasn't given back ...
<mborzecki> Chipaca: right, so there's still a race but at least you'll get ctx.Err() if cancel was called or timeout was hit
<Chipaca> mborzecki: I _could_ check that if the flag is set, the exec error looks like a 'killed' error
 * Chipaca bbiab
<mup> PR snapd#4570 opened: release: snapd 2.31~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4570>
 * Chipaca grins as he writes TestRunRace
<pedronis> mvo: Chipaca: hi, what's the status of #4459
<mup> PR #4459: snap: add support for `snap advise-snap pkgName` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4459>
<Chipaca> pedronis: what do you mean?
 * Chipaca looks
<pedronis> it seems to be sitting there
<pedronis> since a while
<pedronis> but is not blocked
<Chipaca> huh, i thought this was merged
<pedronis> see
<Chipaca> pedronis: the status is it only has one +1
<mvo> Chipaca, pedronis I think it should get a ack/nack from gustavo
<Chipaca> i guess :-)
<pedronis> mvo: it was not marked as such though
<pedronis> I suppose IÂ cand do that
<mvo> Chipaca, pedronis it might be considered as redundant functionality. thanks, if you mark it that would be great, otherwise I will do it
<pedronis> mvo: I requested a Gustavo reivew on it
<Chipaca> mvo: redundant with what?
<pedronis> probably needs a poke also
<mvo> Chipaca: redundant with snap advice-snap --comand
<mvo> Chipaca: oh, hold on a sec
<mvo> Chipaca: I'm looking at the wrong PR, I think this one is uncontroversial mostly
<pedronis> heh
<pedronis> too many PRs
<mvo> sorry, I was looking at the `snap run` one that advises on available commands
<mvo> pedronis: yes :(
<pedronis> mvo: I still recommend(very gently) trying to be a bit more agressive about closing PRs, otherwise it gets confusing
<mvo> pedronis: agreed, let me start right now!
<pedronis> close as in get merged or close as in close, whatever makes sense
<mup> PR snapd#4424 closed: corecfg: pam_env can only handle 1024 byte <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4424>
<pedronis> to be clear
<mvo> :+1:
 * Chipaca hugs mvo
<mup> PR snapd#4477 closed: snapenv: add SNAP_ARCH_TRIPLET <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4477>
<zyga> o.
<zyga> (which is like o/ but with me being more sleepy)
<zyga> mvo: so I woke up at 7 ... and ... yeah
<zyga> man
<mvo> 4521 needs a second review probably an easy win
<Chipaca> zyga: I woke at 4
<Chipaca> zyga: neener neener
<mvo> zyga: good morning (and you looked at this already)
<mvo> zyga: good morning
<zyga> haha :)
<mvo> zyga: rc2 is branched and uploaded to the ppa, waiting for the build
<Chipaca> that's what peeking into scary finances does to you
<zyga> excellent
<mvo> I wonder if openoffice is building right now, build slots are in short supply it seems :/
<zyga> Chipaca: I was merging things at 3am
<mvo> Chipaca: :( that sounds scary
<Chipaca> zyga: i saw you restarting things at my 1am, so yeah :-)
<zyga> Chipaca: yeah, travis and spread didn't love each other last night
<mvo> very ironc that 2.31~rc2 is only build on powerpc yet (which used to be one of the slowest arches)
<zyga> ;D
<Chipaca> mvo: no spectre for ppc
<mvo> heh, yeah
<mvo> i was wondering if it is build on a 32bit chroot on ppc64el or something, that would also explain it
<mvo> anyway
<zyga> mvo: someone just pressed the "turbo" button
<mvo> haha
 * zyga remebmers his 386 now
 * Chipaca -> physio
<mwhudson> mvo: yes, pretty sure powerpc builds in a chroot on a 64 bit box now
<mvo> ha!
<mvo> thanks mwhudson
<mwhudson> Kernel version: Linux bos02-powerpc-008 4.4.0-103-powerpc64-smp #126-Ubuntu SMP Mon Dec 4 16:57:45 UTC 2017 ppc64
<mup> PR #126: Ensure squashfs snaps keep all uid/gid and permissions on build <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/126>
<ogra_> ogra@localhost:~$ htop
<ogra_> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<ogra_> hmm
 * ogra_ reboots the board
<zyga> hmmm?
<ogra_> edge ... not sure if i tinkered the istall to death here or if there is actually a prob in the core snap from tonight
<zyga> ogra_: let me know if it happens, I can look at my boards
<mvo> Chipaca: hm, silly question. when we run command-not-found (snap advise-snap --command echo) - should we return test-snapd-tools because we have echo in there as a command? even though its not a toplevel?
<zyga> mvo: btw, doko said that snapd 2.30 builds are failing
<zyga> 09:05 < doko> https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on
<zyga>               most archs
<mvo> zyga: checking
<Chipaca> mvo: no, i don't think so, not unless it's got an alias
<mvo> zyga: fwiw https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 is all green afaict
<zyga> indeed
<zyga> no idea, not very helpful today
<zyga> (yet)
<doko> mvo, zyga: yes, given back.  you should not upload and run away, but read your build failure messages
<doko> but maybe snaps don't have those anymore ...
 * mvo wonders why he did not get those
<Chipaca> mborzecki: pushed a tweak to RunWithContext, including a test for the race
<Chipaca> and now yes, to physio
<mborzecki> Chipaca: thanks, will take a look
<mup> PR snapd#4571 opened: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<mborzecki> zyga: ^^
<ogra_> zyga, i had temporary disabled the apparmor init script on that device (because apparmor stalls the boot for ~1min), apparently snapd doesnt create the snap-confine (i think on core it simply should do that)
<ogra_> *doesnt create the profile for ...
<ogra_> that actually seems the only thing this init script is needed for
<zyga> ogra_: it does and that thing you disabled loads it
<ogra_> zyga, well, it seems to be the only profile this is needed for ... IMHO snapd could simply invoke the parser directly on core installs
<ogra_> core does not have any other profiles outside of snap apps ... where snapd already takes care correctly
<zyga> ogra_: it has to be done on boot
<zyga> ogra_: by that script
<zyga> that script compiles and loads all the profiles (including snapd generated ones)
<ogra_> i understand that it has to be done o boot for classic installs ...
<zyga> no
<zyga> on all installs
<zyga> I mean, snapd doesn't handle that at all
<ogra_> but on core there is only one profile that gets generated
<ogra_> which is the snap-confine one
<zyga> no, all the per-snap profiles are handled by that guy
<zyga> we could remove it but it's ... already doing it
<ogra_> hmm, i dont see it doig that
<zyga> and there's no clear reason why that would help
<zyga> (look at /var/lib/snapd/apparmor
<zyga> that's also loaded by the script
<ogra_> well, the profiles are generated during snap install
<ogra_> just not for snap-confine
<zyga> yes but on reboot they are not loaded
<zyga> ogra_: I'm telling you the script does useful work on boot, if we drop that script we have to put some thing on early boot, before _any_ snap can start
<zyga> ogra_: I'm not sure that should be snapd; it could be but I don't see a clear advantage
<zyga> ogra_: not on boot speed for sure
<ogra_> well, thats different to what i see :) but i belive you :)
<zyga> ogra_: there's a variable somewhere that makes it look at /var/lib/snapd/apparmor/profiles
<zyga> ogra_: we also load profiles on startup if they _changed_
<ogra_> (all snaps functioned fine for the last week while the script was off ... only a core refresh made snap-confine fail then)
<ogra_> ... but probably the profiles simply never changed in that time despite me randomly installing/removing7refreshing apps
<ogra_> anyway, re-enabling the script gets me 3min boots back but also makes snap-confine work again ... so its a user error
<zyga> ogra_: how slow is it btw?
<cjwatson> Chipaca: ppc does suffer from Spectre, FWIW (maybe not the actual 32-bit-only chips, I'm not sure, but certainly more modern ones)
<zyga> maybe there is something wrong?
<zyga> cjwatson: hey, I still _run_ one :)
<ogra_> zyga, lol ... yes ... thats what i'm trying to find :P
<zyga> ogra_: maybe add a echo to the script (or something like that)
<zyga> ogra_: so that we know when it starts and when it stops
<zyga> ogra_: not sure if that's clearly readable from logs
<ogra_> (it is a 200-500MHz 256M ram board ... but 3mins are definitely to long even for that)
<zyga> ogra_: so, there's a cache thing there but maybe it's broken and not used
<ogra_> systemd-analyze is usually pretty correct in its timings
<zyga> ogra_: normally apparmor should read the profile, check with the cache and insert a cached compiled blob if one is recent
<ogra_> yeah, the cache is definitely empty on all my boards
<zyga> ogra_: otherwise it would compile the profile, which is slow, save the cache and load it in the kernel
<ogra_> jamie pointed that out before
<zyga> ogra_: not sure how much of that is done in intrd
<zyga> ogra_: and how much in early systemd
<ogra_> (seems there is some general issue with the cache )
<zyga> ogra_: oh?
<ogra_> initrd doesnt do any apparmor stuff
<ogra_> only the mounting
<zyga> there are two cache locations
<zyga> for some historic reason AFAIR
<zyga> did you check both?
<ogra_> well, jamie pointed me to /etc
<zyga> look at /var/cache/apparmor
<ogra_> and that one is definitely empty on all boards i have
<ogra_> yeah, there are files
<zyga> see if it makes any difference
<zyga> even with a hand watch
<zyga> if you remove them
<zyga> if so then the cache works
<zyga> if not ... well, slow boards are slow
<ogra_> well
<ogra_> snapd probing mmcblk1rpmb devces for assertions takes quite some time too ;)
<ogra_> there are some obvious issues (like this one) ... but they are not enough to get me to a sane boot speed yet
<zyga> how much?
<ogra_> dunno, several tens of seconds
<ogra_> 15-20 i'D say ... thats sadly a service that doesnt log anything ...
<zyga> is that blocking boot or does it happen in parallle?
<zyga> *parallel
<ogra_> (i havent debugged that one yet, its an obvious one)
<ogra_> others are 30sec for mounting loop devices
<ogra_> thats more worrying
<ogra_> console-setup 20sec ... keyboard-setup 15sec ...
<ogra_> the device probing is blocking boot
<mvo> ogra_: could you run systemd-analyize plot and copy the output somewhere?
<ogra_> well, the system is havily modified atm ... i'll do that once i flashed it freshly ... here is a top list of blame though https://paste.ubuntu.com/26494246/
<zyga> ogra_: the probing issue
<zyga> ogra_: I honestly think it should not be a toggle
<zyga> ogra_: but there should be a way to tweak this in the gadget
<ogra_> zyga, ?
<zyga> ogra_: so that you can use udev tagging to blacklist media
<ogra_> ah
<ogra_> yeah
<zyga> ogra_: so that certain internal devices are just skipped
<zyga> ogra_: it's a simple system, extensible to devices and makes sense as a design IMO
<ogra_> well, you never ever want to probe mmcblkXrpmb or mmcblkXbootX
<zyga> ogra_: I don't think that's true, that's absolute and those rarely turn out true
<ogra_> but thats also something systemd needs to learn, not only snapd
<mvo> ogra_: thanks, the plot would be nice at some point but not urgent
<mup> PR snapd#4572 opened: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572>
<zyga> ogra_: as long as you can set an attribute that makes it skip probing and you can express that in the gadget it feels sufficient
<ogra_> zyga, right ... systemd doesnt have such a flag yet ... which is why i ignored that bit for now for snapd as well
<ogra_> i'll get to that later ...
<ogra_> thats one of the bits that are understood :)
<zyga> ogra_: it's not a systemd flag
<zyga> ogra_: it's an udev attribute
<ogra_> (i have many in this particular boot process that arent :) )
<zyga> ogra_: like MM_SKIP_PROBING (or whatever it was called)
<ogra_> zyga, hmm, i only know UDISKS_IGNORE ... but that wouldnt help with systemd fsck or snapd autoimport
<zyga> ogra_: fsck I cannot speak of, those are separate issues
<zyga> ogra_: but the job that tries to look for assertions is under our control
<zyga> ogra_: so it could just skip devics with a given attribute
<ogra_> zyga, would be helpful if the autoimport udev rule could mention the variable in the comment somehow ... how would porters know about it ?
<ogra_> (without reading snapd's source)
<zyga> ogra_: sure that's documentation; I'm describing a feature that doesn't exist
<ogra_> oh
<zyga> ogra_: it's just something that we would doucment in device maker's book or similar
<ogra_> i thought you said there is "MM_SKIP_PROBING"
<zyga> ogra_: I'm saying that such an attribute, IMO, makes more sense than a big bool flag for _users_
<ogra_> well
<zyga> ogra_: that was a reference to existing similar attribute for modem manager and serial ports
<ogra_> that flag will only make the udev rule skip
<ogra_> it wont prevent the unit fro running
<ogra_> *from
<zyga> yes but we could make that unit run the prober with a device, so that control is reversed
<zyga> systemd picks the devices, prober probes one
<ogra_> most customers i worked with til now want that stuff completely off so people cant tinker with USB sticks
<zyga> those could then even run faster as they would happen in parllel
<zyga> ogra_: that's okay, but it should be a gadget decision, not a toggle for users
<ogra_> it simply wastes cycles, even if it is a no-op
<ogra_> yeah
<ogra_> indeed it should be a gadget thing
<ogra_> (like rsyslog or disabling ssh access)
<ogra_> though here the issue is more of a subsequent thing ... i want the deices to be hidden completely during boot so fsck will ignore them too ...
<ogra_> (autoimport is just the next thing in the chain here ... )
 * zyga -> physical activities
<zyga> ogra_: I'm so mentally tired I will do some house chores to vent my mind
<zyga> ogra_: I agree on fsck
<zyga> ogra_: though I would discuss it separately
<mvo> cachio: good morning! 2.31~rc2 for armhf/arm64 is ready, the other ones are still building
<cachio> mvo, good morning, already downloading images
<mvo> cachio: great, I publish the other ones as soon as I can
<cachio> mvo, great
 * zyga hopes for one smooth release 
<mvo> 2.30 was not too bad
<zyga> mvo: going out with rc2 would be awesome :)
<mvo> cachio: i386/amd64 ready now as well
 * zyga refreshes to beta
<zyga> mvo: oh
<zyga> mvo: we didn't do one thing
<zyga> that piece of code that wrote the snap.mount unit (under proper name
<zyga> we don't have that
<zyga> for reexec
<zyga> but I guess it's okay for now, as long as packages are coming out, not a regression in any way
<mvo> zyga: yeah, it will only be fixed in lxd hosts with the right snapd version
<mvo> zyga: eh deb/rpm
<mvo> zyga, pstolowski there is a bugreport that we should document that hooks use dash - I wonder if we should just switch them to bash. wdyt?
<ogra_> oh, please dont
<mvo> pstolowski: do you think you could check 1745015?
<mvo> ogra_: why not?
<ogra_> (dealing with a 200MHz 256M single core device here ... such a switch would have some impact)
<zyga> mvo: is there any mandate for the hooks to be anything? they are just executables, could be dash, python or elf
<ogra_> bash eats about 5Mb while dash lives in the kilobyte range
<ogra_> (and used to be massively slower as well, back when debian did the research ... that might have changed since 2007 though)
<mvo> zyga: there is no mandate for this
<ogra_> mvo, assuming you dont mean live-build hooks here but app hooks
<pstolowski> mvo, interesting. will look into 1745015
<mvo> ogra_: snap hooks, yes. well, fair enough.
<ogra_> mvo, most upcoming ubuntu core customers in the near future will be in a similar HW range, every byte of ram counts here
<pstolowski> mvo, I agree with zyga; i think documenting is enough
<mvo> pstolowski: ok
<ogra_> (and on single core-low-speed cpus also every herz :) )
<ogra_> s/herz/hertz/
<ogra_> mvo, oh, during my debugging i noticed that "systemctl list-dependencies" on core devices shows quite a bunch of red dots, i wonder if we need to handle some units more gracefully or need to disable them
<ogra_> i.e. "systemd-machine-id-commit.service" ... completely useless since we set the machine-id from the initrd ... but it gets run nontheless
<ogra_> or systemd-hwdb-update.service ... (the hwdb is readonly)
<cjwatson> mvo: I think the thing that bug reporter is missing is that /bin/sh is the default in normal Ubuntu too
<cjwatson> mvo: err /bin/sh -> dash
<cjwatson> they've obviously just configured it differently
<Chipaca> cjwatson: wrt spectre on ppc, I was thinking exclusively of the pre-2006 chips (have there been 32-bit ppc chips since then?)
<Chipaca> also I thought powerpc meant 32 bits, and the newer ones were ppc64le or w/e
<cjwatson> yeah but you said ppc which is a bit ambiguous
<Chipaca> ah, my bad then (i meant powerpc i think)
<Chipaca> in my defence my only powerpc machine was a nubus-ppc one
<cjwatson> there've certainly been embedded 32-bit chips since then, and e.g. the e600 has out-of-order execution, branch prediction, and such; wouldn't surprise me if you could get something like Spectre to work but I don't know if anyone's bothered
 * zyga starts to see the light at the end of the tunnel :)
<zyga> my office gets messy quickly
<Chipaca> somebody's got to be trying to get spectre to work on a router
<Chipaca> mborzecki: you around?
<mborzecki> Chipaca: yeah, trying to go through #4551
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<Chipaca> mborzecki: just a quick Q: your version of the if in #4569 implies two class assertions, right?
<mup> PR #4569: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569>
<mborzecki> Chipaca: sadly yes
<Chipaca> ie one to get a ExitError, one to get a WaitStatus; that's why you said more verbose
<Chipaca> mborzecki: fair enough. I'll rewrite it that way. i had it like that (except I didn't know about Signal() which makes it more readable, and probably worthwhile)
<mborzecki> Chipaca: didn't know about it either, actually read through the exec code in stdlib :)
<pstolowski> mborzecki, thanks!
<mup> PR snapd#4557 closed: osutil: add DirExists and IsDirNotExist <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4557>
<zyga> ok, one last power strip
<zyga> and I should be ready
<niemeyer> Hey hey
 * ogra_ puts a dollar in zyga's waistband for that power strip ...
<Chipaca> ogra_: I did _not_ need that image
<ogra_> lol
 * zyga googles waistband
<zyga> oho
<zyga> *gulp*
 * zyga hugs ogra_ and Chipaca *together*
<ogra_> no, no ... we didnt order that lapdance !!!s
 * Chipaca steals the dollar and goes to get lunch
<zyga> the dollar is actually a beer bottle cap
 * zyga looks at unit tests again
<Chipaca> zyga: guess lunch is roaches then
<zyga> Chipaca: fry slowly
 * Chipaca squints at Failed tasks: 1
<Chipaca>     - linode:ubuntu-14.04-64:tests/main/server-snap:pythonServer
<zyga> what's the failure?
<ogra_> oh
<ogra_> is bpf a hard kernel requirement nowadays ?
<zyga> ogra_: yes, I think so
<ogra_> aha
<ogra_> ppisati, seems our default configs in the sample kernels do not enforce bpf ^^^
<mup> PR snapd#4573 opened: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573>
<zyga> mvo: if this passes please drop it into final release
<zyga> I forgot about it yesterday
 * zyga is very excited about content sharing getting a huge boost in 2.31
<zyga> but first let's drop those unit tests :)
<mvo> zyga: which one, 4573?
<zyga> yep
<zyga> it just enables a test that I wrote ahead of time
<zyga> and rigged to skip one case
<zyga> now it should all pass
<mup> PR snapd#4570 closed: release: snapd 2.31~rc2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4570>
<mup> PR snapd#4569 closed: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4569>
<ppisati> ogra_: i'm going to add it to the list of configs in the snapcraft/kernel_plugin
<zyga> mvo: please merge https://github.com/snapcore/snapd/pull/4573
<mup> PR #4573: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573>
<zyga> it's green now
<ppisati> ogra_: which BPF options? i guess the BPF_SYSCALL filtering option
<ogra_> ppisati, yeah, i guess so ... all i justz noticed is that on a misbehaving device /proc/filesystems doesnt list bpf ... mnot sure what options are exactly needed ... i know the pi kernels have all of them though
<ppisati> ogra_: well, when you figure it out, add it to the list of required options here and send a pull req
<ppisati> ogra_: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py
<ppisati> 'required_snappy' i guess
<mup> PR snapcraft#1900 opened: Parent relative symlinks <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>
<zyga> jjohansen: o/
<jjohansen> hey zyga
<zyga> jjohansen: long time no see, how are you doing
<jjohansen> zyga: well I was doing well, but I have a feeling that is about to change
<jjohansen> :)
<pstolowski> mvo, so my spread test for that install hook bug just produced 'mesg: ttyname failed: Inappropriate ioctl for device' and hung; waiting to see if the hook gets aborted as it should.
<zyga> oh? what's going on?
<mvo> pstolowski: aha, interessting
<jjohansen> zyga: oh I was just assuming you pinged me because you have a bug for me :)
<zyga> ah, no :)
<jjohansen> zyga: ah, well then I am good :D
<mup> PR snapd#4573 closed: tests: enable content sharing test for $SNAP <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4573>
<zyga> thank you
<pstolowski> mvo, ok. puzzling. install hook got killed eventually, install was aborted. all as expected.
<cachio> mvo, https://paste.ubuntu.com/26495194/
<pstolowski> mvo, ah wait, he is not installing, he is using snap try
<cachio> this is what Ii see in the pi21
<cachio> mvo, there is no /snap/core/current
<cachio> mvo, and many tests failing because of that
 * kalikiana lunch
<cachio> mvo, also the test-snapd-tools snap is not in /snap
<mvo> cachio: that is strange, what does your state.json look like? i.e. python3 -m json.tool /var/lib/snapd/state.json
<mvo> mborzecki: just to double check, the license for local snaps is displayed if these snaps have a "license:" field in their snap.yaml?
<cachio> mvo, https://paste.ubuntu.com/26495214/
<mvo> cachio: strange, looks like state.json and content is toally out of sync
<mvo> cachio: I wonder if this is a fluke or if we somehow broke the testsuite
<zyga> mvo: maybe backup/restore is messed up
<zyga> we sometimes see that the state was modified while it was being saved
<mvo> zyga: yeah, something along these lines
<cachio> mvo, not sure yet, something similar is happening in dragonboard
<cachio> pi3 is working fine
<mvo> strange
<zyga> it's a race
<zyga> it doesn't matter where it failed
<cachio> mvo, same issue with test-snapd-tools
<mvo> Chipaca: does https://github.com/snapcore/snapd/pull/4531#pullrequestreview-92931228 capture the discussion during the standup? if so I will merge the PR and cherry-pick for 2.31
<mup> PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>
<mvo> cachio: and its also in the state I assume? so the same out-of-sync issue(?)
<Chipaca> mvo: except for the very last commit, i think
<cachio> mvo, checking
<mborzecki> mvo: it should, there's a /v2/snaps/<name>, as long as the response contains the license it will be shown, i can try and add a quick test case for it
<mvo> Chipaca: commit or comment?
<mvo> mborzecki: yeah, I think if we could have a test case that would be best
<Chipaca> mvo: commit
<Chipaca> mvo: ie the one that removed the âlicense: unknownâ
<mvo> mborzecki, Chipaca: indeed, sorry for this. lets just revert 60074f0 and the following one now that we have agreement on that it should be part of the snap
<cachio> mvo, yes
<cachio> mvo, also I see in the syslog many of these errors ---> Jan 31 11:15:58 localhost snapd[1369]: 2018/01/31 11:15:58.355309 stateengine.go:101: state ensure error: devicemgr: snap "core" has "install-snap" change in progress
<mborzecki> mvo: just to be clear, revert the last 2 commits right?
<mvo> mborzecki: yes
<mvo> mborzecki: sorry for the confusion about this one, I was under the (wrong) impression that the store should be the authority and I'm happy that its the snap
<mborzecki> mvo: also the text that was shown there is `(undefined)`, should I change it to unknown instead?
<mvo> mborzecki: yeah, I think "unkown" is slightly better
<mvo> niemeyer: for unknown licenses, "license: unknown" in `snap info` output? sounds reasonable?
<doko> mvo, zyga: snapd has autopkg test regressions
<zyga> where can we see them?
<mvo> zyga: I think we have this problem that the store categories changed :( so the searching test fails now
 * ogra_ scratches head about unlogical kernel config naming 
<ogra_> # CONFIG_BPF_JIT is not set
<ogra_> CONFIG_HAVE_BPF_JIT=y
<ogra_> how can the second one be true if the first one is false ...
<zyga> you have it (it's supported in arch) but not enabled
<zyga> that's how I see it
<ogra_> hmm
<ogra_> so that would mean userspace you think ?
<zyga> no, I mean the kernel has code to emit jit for bpf on this architecture (that's the HAVE part does)
<zyga> (just guessing though)
<ogra_> ah
<ogra_> ok
 * ogra_ gets it
<zyga> but the config option to enable it is off
<ogra_> anyway ... just curious ... i'll just enable it anyway
<Chipaca> pstolowski: I got a panic in config, suspect I'm doing something wrong :-) do you have a moment to take a look?
<pstolowski> Chipaca, what is it?
<Chipaca> pstolowski: I'm doing : tr.Set(aSnap, "", aConfig)
<Chipaca> pstolowski: and overlord/configstate/config/helpers.go:80 throws an 'index out of range'
<niemeyer> mvo: Yeah, sounds good
<niemeyer> mvo: I'm half-way through typing out a proposal for custom licenses too
<mvo> mborzecki: -^ so "license: unknown" is fine, very happy that this gets pulled in :)
<pstolowski> Chipaca, key cannot be "", I'm sure we prevent it in snap/snapctl set, but apparently not at this level
<mborzecki> mvo: pushing update in a short while, turns out the biggest issue is forging the data that snapd returns
<Chipaca> pstolowski: then how do I set the whole config? (because key is "" for get to get the whole config)
<pstolowski> Chipaca, well, I've implemented "" on the get side for convienience to make it easy to discover config keys. but we don't have an equivalent for setting all at once
<pstolowski> Chipaca, I mean - not for transaction.Set at least
<pstolowski> Chipaca, you can of course workaround that by iterating over root elements and calling tr.Set(..) for them manually
<Chipaca> pstolowski: that sounds very additive
<pstolowski> Chipaca, or just make tr.Set smarter :}
<pedronis> well you need also to remove all them
<pedronis> which we don't quite support either
<Chipaca> I need to set the config to the thing in the snapshot, not add to it
<Chipaca> if the config is empty, empty it
<pedronis> seems you need to bypass transactions
<pedronis> or teach Set about "" or something like that
<Chipaca> I don't mind bypassing transactions :-D
<pedronis> replacing the whole thing is not quite the use case for transaction
<pedronis> s
<pedronis> then it's more  matter of not breaking too many abstractions
<pstolowski> ah, I see, yes it's additive that way
<pedronis> Chipaca: sounds we need configstate.Set or something
<Chipaca> augh
<pedronis> for your use case
<Chipaca> I need to step away for a bit
<pedronis> well configstate/config.Set
<pedronis> maybe
<pstolowski> yes, that should be very straightforward
 * pedronis doesn't remember the how the code org looks like exactly
<mup> PR snapcraft#1896 closed: elf: do not strip rpaths that contain $ORIGIN <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1896>
<mvo> mborzecki: oh, a spread test is fine, just adding "license: ..:" to one of the test snaps
<mborzecki> mvo: well, i've updated the unit tests anyway :)
<mvo> mborzecki: .) ok
<niemeyer> mvo, mborzecki: https://forum.snapcraft.io/t/support-for-custom-license-text/3671/16
<niemeyer> Chipaca: ^
<kalikiana> re
<greyback> it possible for one snap app to call another snap app? Something like a poor-man's socket activation?
<zyga> greyback: not without an interface
<greyback> zyga: even inside the same snap?
<greyback> i.e. appA & appB in the snap, I want appB to call appA
<zyga> greyback: that's more subtle: if you want to go through the activator then you won't be able to
<zyga> greyback: if you call the same command as that activator then sure
<zyga> greyback: but you won't get the permissions of the other app
<greyback> zyga: yeah, it was the permissions I was hoping to keep separate
<greyback> so xwayland has tight security, and then my x app has more freedom
<greyback> guess I'll give that up for now
<zyga> 10 failures left
<zyga> 7 failures :)
<mup> PR snapd#4531 closed: cmd/snap: display snap license information <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4531>
<mvo> thanks mborzecki
<zyga> libreoffice 6.0 is out, will the snap be refreshed?
<zyga> hhh
<zyga> ah :)
<zyga> man that was silly
<zyga> 3 errors left, will be done in a moment
<Chipaca> pstolowski: pedronis: I think I'm going to add a helper to do just this set/unset to config; should I add it to config, or to configstate?
<Chipaca> it'll be a separate pr
<pedronis> Chipaca: config
<Chipaca> ok
<Chipaca> pedronis: is config sorta-kinda the 'backend' of configstate?
<pedronis> otherwise it cannot be used from snapstate
<Chipaca> this is for use from snapshotstate, but ok
<pedronis> Chipaca: no, it's mostly the accessor that can be used by any other *state
<pstolowski> +1 (config)
<Chipaca> k
<pedronis> Chipaca: confistate itself imports a bunch of *state
<pedronis> so that's why config exists
<pedronis> otherwise circular imports
<Chipaca> is there any reason a snapshot should save a revision-config?
<Chipaca> the "what happens if you restore a revision that isn't current" question comes to mind
<pedronis> those are used one revert I think
<pedronis> no?
<pedronis> are you snapshotting a revision? or all of them?
<Chipaca> pedronis: a single one
<Chipaca> the current one
<pedronis> and you restore the current one?
<pedronis> in that case IÂ don't think revision-config is relevant
<Chipaca> no, restore restores whatever was snapshot
<pedronis> but puts it backa as current?
<Chipaca> no
<pedronis> then it's complicated
<Chipaca> yes
<pstolowski> in that case i think you should restore your snapshot into whatever is current rev
<pedronis> you need to care about about revision-config
<pedronis> I think
<pstolowski> (so,just config)
<Chipaca> maybe restore should block restore unless the revision is current
<Chipaca> then the problem goes away :-)
<Chipaca> at least for now
<Chipaca> maybe in a followup it can restore to current always, but doing that to a 'live' snap makes me nervous
<Chipaca> anyway, going with "config" for now
<mup> PR snapd#4574 opened: tests: add integration for local snap licenses <Created by mvo5> <https://github.com/snapcore/snapd/pull/4574>
<mup> PR snapd#4575 opened: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <https://github.com/snapcore/snapd/pull/4575>
<Chipaca> pedronis: pstolowski: ^ a quickie  (i hope)
<pstolowski> looking
<zyga> 2 lef
<zyga> 2 left :)
<Chipaca> zyga: 2 leffe?
<zyga> Chipaca: two tests failing; almost done :)
<zyga> 0!
<pstolowski> Chipaca, +1
<Chipaca> why can i edit your review summary
<mup> PR snapd#4576 opened: cmd/snap-update-ns: large refactor / update of unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4576>
<zyga> big n boring
<zyga> but had to be done
<zyga> now I feel good about that code :)
<zyga> I also tweaked a few strings based on one more patch I had, the error messages are nicer
<zyga> mvo: ok, I think I can close that chapter for today, I can do code reviews or I can write about the content interface improvements
<mup> PR snapcraft#1901 opened: elf: check if file exists before checking if ELF <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1901>
<mvo> zyga: writing sounds good
<zyga> mvo: okay, let's get that done :)
<zyga> if you include that PR in ~rc3 (if there is one) that's okay but it's not mandatory, I only added a load of unit tests and tweaked some error strings
<mvo> zyga: yeah, just looking at it
 * zyga tries to recall why x.snapd.symlink=foo is not conveyed through Entry.Name, hmm hmm
<zyga> maybe it would be nicer to read
<zyga> but I did that for *some* reason, I remember that much
<zyga> well, did it the way it is now
<zyga> those tests took about two days to write in this final form
 * kalikiana going to wrap up for the day
<zyga> o/
<zyga> Chipaca: question on 4575
<Chipaca> zyga: or is there
<Chipaca> zyga: (i don't see a question)
<zyga> Chipaca: hmmmm
<zyga> it got eaten
<Chipaca> github is hungry today
<ogra_> omnomnom
<zyga> I was asking why are we returning json.RawMessage by value
<Chipaca> zyga: it's a []byte; it's already a pointer
<zyga> and if that is safe actually (shallow copy)
<zyga> ah, perfect
<zyga> thanks! LGTM
<Chipaca> I don't know why config uses *json.RawMessage (and it might, because it does some funky stuff), but these two functions are un-funky
<Chipaca> might need to*
<ogra_> sigh ...
<zyga> Chipaca: was that related to some bug in json
<zyga> where you need the pointer to get some methods right
<zyga> something like that echoes in my head
<Chipaca> it might be; if it is, pedronis will know :-)
<zyga> + snap install test-snapd-control-consumer
<zyga> error: cannot install "test-snapd-control-consumer": cannot get nonce from
<zyga>        store: store server returned status 418
<zyga> 418?
<Chipaca> aw, so close to 419
<zyga> is that my bus home? :)
<Chipaca> ah no
<Chipaca> 418 is the one
<zyga> what is it?
<zyga> should we retry that?
<Chipaca> 418 I'm a teapot
<ogra_> jdstrand,  (or any other securiteer ) ... looking at different core kernels i see "bpf" in /proc/filesystems ... the kernel i'm currently working on does not show it and i cant find what Kconfig option would enable the bpf filesystem, do you happen to have any hint (google isnt helpful either)
<Chipaca> zyga: which in our tests means it is (hopefuly!) not talking to an actual server
<zyga> haha, cute :)
<pedronis> it's talking to the fakestore and trying to setup a device session
<pedronis> or something like that
<pedronis> why is it doing that though?
<pedronis> only now
<zyga> it is in here https://api.travis-ci.org/v3/job/335552657/log.txt
<zyga> in this PR https://github.com/snapcore/snapd/pull/4562
<mup> PR #4562: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
<pedronis> it is using the fakestore
<pedronis> wondering why we never got this kind of error
<pedronis> it's a while since the situation in which we might try to create a device session have increased
<ogra_> mvo, hmm, did the service disabling in the core config hook regress ? (seems to not mask aymore but just disable)
<ogra_> lrwxrwxrwx 1 root root   35 Jan 28 11:50 syslog.service -> /lib/systemd/system/rsyslog.service
<ogra_> ogra@localhost:~$ snap get core service.rsyslog.disabled
<ogra_> true
<ogra_> ogra@localhost:~$ ps ax|grep syslog
<ogra_>  2195 ?        Ssl    0:00 /usr/sbin/rsyslogd -n
<zyga> mvo: do we need https://github.com/snapcore/snapd/pull/4562 for the final release?
<mup> PR #4562: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
<cachio_> mvo, well I discovered the problem in dradonboard and pi2
<cachio_> mvo, old core snaps
<cachio_> it is weird because I  created the images after the cores were uploaded to the store
 * Chipaca afk for a while
<mup> Bug #1746564 opened: snapd should not allow --classic installation for snaps with strict confinment mode <Snappy:New> <https://launchpad.net/bugs/1746564>
<cachio_> mvo, this seems to be an issue
<cachio_> https://paste.ubuntu.com/26496402/
<cachio_> mvo, it happens in the refresh scenario
<cachio_> when we refresh from stable (factory release)
<cachio_> I'll debug it once the execution finishes
<zyga> hmm
<zyga> in test-snapd-tools expected to have a key 'license'
<zyga> that looks like the recently added thing
<cachio_> mvo, it failed in both 32 and 64 bits
<zyga> yes, it's not something that's arch dependent
<cachio_> zyga, ok, I'll take a look in that case
<zyga> cachio_: look at the newly merged patches
<cachio_> zyga, yes, this issue was not happening in rc1
<cachio_> it is quite new
<cachio_> I am debuging
<cachio_> zyga, any idea which PR was included the code that could be causing that?
<mvo> ogra_: hm, I remember code to mask it but I will double check in the morning
<ogra_> cyphermox, slangasek, am i correct assuming that the only reason for not using signing for the initrd in secure boot is that we dynamically re-generate it ? or is there any grub-sided restriction as well ?
<mup> PR snapd#4575 closed: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4575>
<mvo> zyga: 4562 is not super urgent, suggests are weak and in most cases where we will use the UI one of the two (zenity or kdialog) will be installed
<slangasek> ogra_: what does signing an initrd mean to you?
<ogra_> slangasek, well, having a signed img file
<ogra_> and grub verifying that
<mvo> cachio_: meh, I think its my fault :/
<mvo> cachio_: I cherry-picked the license display PR into 2.31
<mvo> cachio_: so there is a test for it in git
<mvo> cachio_: but this cherry-pick is not included in ~rc2
<mvo> cachio_: that explains the failure
<slangasek> ogra_: grub verifying it using what code?
<ogra_> slangasek, dunno, thats why i ask :) would that be a kernel thing ?
<slangasek> ogra_: possibly.  in practice verification of initrds has consistently been punted to "that's a TPM thing"
<ogra_> i assume there is a way to have a signed initrd too ... along with a signed kernel
<ogra_> slangasek, the issue is ... we wanted to use u-boot.FIT for secure boot on arm for a project, but it turned out that this only allows a giant blob that contains kernel. initrd and dtb in a single file ... that doesnt go so well with snaps, so i'm looking into the possibility to instead use grub-uboot for that
<ogra_> ... in the hope it allows me to have single files i can load
<ogra_> (but still keep a secure chain of verified images)
<ogra_> aha
 * ogra_ finds https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd
<cachio_> mvo, I noteced that :)
<cachio_> np
<slangasek> ogra_: right, so initrd is difficult because it's generated outside the archive, and the UEFI signing keys are quite intentionally only in the archive
<ogra_> slangasek, right, but thats not the case in snap-land :)
<slangasek> ogra_: it's still not generated in the Ubuntu archive, AFAIK?
<cachio_> mvo, also we need a strace-static snap for i386
<cachio_> mvo, could you please share it to me?
<ogra_> slangasek, yeah, but thats the x86 UEFI world ... here we'll have a customer with his own key that gets burned into the trust zone on the arm board ... so all i need to care about is that the snaps get signed with the right key when the customer builds them in-house
<ogra_> so no archive key involved
<slangasek> ogra_: ah, I see. so, then the problem is, the initrd is not a PE object, which means the usual secureboot signature verification code can't do anything with it
<ogra_> s/that the snaps/that the binaries in the snaps/
<ogra_> right, but i the case of a custom key that wont matter ... great ...
 * zyga dinner
<jdstrand> ogra_: otoh, I don't... tyhicks *may*, but jjohansen probably would (though he is traveling and may not be available)
<jdstrand> tyhicks, jjohansen: question from ogra is when does "bpf" show up in /proc/filesystems?
<zyga> hey jdstrand o/
<jamesh> zyga: hi.  Is there any particular reason why snap-update-ns only logs failures to mount/unmount file systems rather than treating it as a failure?
<mup> PR snapcraft#1901 closed: elf: check if file exists before checking if ELF <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1901>
<tyhicks> ogra_, jdstrand: is there more context? (I don't have backscroll handy)
<tyhicks> ogra_, jdstrand: filesystem types show up in /proc/filesystems when filesystems of that type are available in the kernel (I doubt that answers your question and that you already know that)
<tyhicks> s/and that you already know that/and suspect that you already know that/
<mvo> cachio_: sure thing, let me fix the strace-static thing
<jdstrand> hey zyga
<jdstrand> tyhicks: right. let me give the whole question
<zyga> jamesh: that's a good question, I think it was decided long ago
<zyga> jamesh: I'm not super fond of it as we probably don't do things correctly then
<jdstrand> tyhicks: 11:09 < ogra_> jdstrand,  (or any other securiteer ) ... looking at different core kernels i see "bpf" in /proc/filesystems ... the kernel i'm currently working on does not show it and i cant find what Kconfig option would enable the bpf filesystem, do you happen to have any hint (google isnt helpful either)
<tyhicks> aha
<tyhicks> I can answer that with some investigation
<jdstrand> zyga: considering that snap-update-ns tries to do things in order, failing somewhere along the way and continuing as if it succeeded seems incorrect
<jdstrand> ogra_ (cc zyga): I just looked at 3 different core systems, and none of them have a populated /etc/apparmor.d/cache
<tyhicks> ogra_: the bpf filesystem was first added in kernel 4.4 with this commit: https://git.kernel.org/linus/b2197755b2633e164a439682fb05a9b5ea48f706
<jdstrand> ogra_ (cc zyga): /var/cache/apparmor is correctly populated with snap cache (and nothing else)
<tyhicks> ogra_: from what I can tell, it is only hidden behind CONFIG_BPF_SYSCALL
<jdstrand> ogra_ (cc zyga): /etc/apparmor.d/cache is a writable path, so for giggles I unmounted it and /etc/apparmor.d/cache was also empty. if I were to guess, I would say that the ordering of the apparmor unit and the writable-path is wrong and that /etc/apparmor.d/cache is still readonly at the time that the parser is run
<zyga> jdstrand: oho
<zyga> jdstrand: nice find
<mvo> jdstrand: with me "empty-etc" hat on> why is etc used to write a cache?
<jdstrand> ogra_ (cc zyga): iirc this used to work. I don't know when it would have regressed. we should probably have a spread test to make sure
<zyga> mvo: your question is spot on
<jdstrand> mvo: hi! terribly longtime historical reasons
<mvo> jdstrand: fair enough, just like 80% of etc
<jdstrand> mvo: right
<jdstrand> mvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var)
<zyga> mvo: you probably know better than I do that /etc used to hold *binaries*
<jdstrand> mvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is)
<jdstrand> mvo: it comes up from time to time on the mailing list. there is a general desire to move it, but it gets complicated wrt to early boot, distros, etc. however for core, there is no reason we couldn't put it somewhere else, but we'd have to be careful about early boot
<jdstrand> mvo: it comes up from time to time on the mailing list. there is a general desire to move it, but it gets complicated wrt to early boot, distros, etc. however for core, there is no reason we couldn't put it somewhere else, but we'd have to be careful about early boot
<mvo> jdstrand: ok
<jdstrand> mvo: I'm not sure how much you saw before you dropped off...
<mvo> jdstrand: I missed this, thanks for pasting
<mvo> jdstrand: my machine is a bit unstable recently, I wonder if I need to purge the intel-microcode package :(
<jdstrand> mvo: here are two more:
<jdstrand> mvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var)
<jdstrand> mvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is)
<mvo> jdstrand: ta
<jdstrand> mvo: maybe-- mine made suspend not work at all
<jdstrand> well, it would suspend. it wouldn't come out ;)
<jdstrand> I'm hopeful new microcode will be available
<mvo> jdstrand: thanks for the apparmor, for core18 we may need to tweak this, but its only one of many potential things we need to tweak :)
<mvo> jdstrand: I will purge it for now :(
<jdstrand> mvo: can you think of what might've caused the cache to not be populated?
<jdstrand> mvo: do you also recall this used to work?
<mvo> cachio_: I create a proper lp:~snappy-dev/strace-static-snap/trunk project with an auto snap build
<cachio_> mvo, awesome, tx
<jdstrand> ogra_: can you file a bug for /etc/apparmor.d/cache and we can contineu there?
<mvo> jdstrand: I don't recall this used to work and I think the most plausible is what you said, if this run very early the location might still be read-only
<mvo> jdstrand: fwiw, I hope we won't have writable-paths for core18 just a plain writable etc
<jdstrand> it certainly is meant to work, otherwise those poor arm devices are grumpy
 * jdstrand -> gotta run. bbiab
<mup> PR snapd#4574 closed: tests: add integration for local snap licenses <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4574>
<mup> PR core#80 opened: hooks: c-n-f is expected in /usr/lib/command-not-found <Created by mvo5> <https://github.com/snapcore/core/pull/80>
<zyga> mvo: +1
<mvo> zyga: ta
<mup> PR core#80 closed: hooks: c-n-f is expected in /usr/lib/command-not-found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/80>
<mup> PR snapd#4577 opened: snap: fix command-not-found on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4577>
<zyga> mvo: so... it wasn't tested in practice before?
<zyga> mvo: hmm
<zyga> mvo: why
<zyga>  +cmd.Positionals.CommandOrPkg = os.Args[2]
<zyga> I don't get it
<zyga> you iterate over all args except 0th
<zyga> and then you can have a chain of --
<zyga> and the first one that doesn't will set a _fixed_ answer
<zyga> is that correct?
<mvo> zyga: meh, incomplete push
<mvo> zyga: sorry
<mvo> zyga: please reload
<mvo> zyga: originally I wanted to just hardcode os.Args[2]
<mvo> zyga: but then though checking for "--" would be more robust if the handler that calls c-n-f ever changes
<mvo> zyga: I guess it shows that I should stop for today :)
<mvo> zyga: the integration on a real shell on a core device was not tested until today :/ many moving parts
<geekgonecrazy> Greetings guys.  Back with more snap/snapcraft related issues. :)
<geekgonecrazy> In the rocketchat-server snap we do an npm install.  One of the packages seems to always have issues getting properly snapped up
<geekgonecrazy> So most of the time we can explicitely install it and it'll make it through.  But we're running into the issue again.  It seems as if for some reason snapcraft decides that the binaries don't need to be included so skips them
<geekgonecrazy> > Unable to determine library dependencies for b'/build/stable/prime/programs/server/npm/node_modules/grpc/src/node/extension_binary/node-v57-linux-x64-glibc/grpc_node.node'
<geekgonecrazy> we see this ^ and that exact same file is then complained about being missing when we try to start it
<geekgonecrazy> does "Unable to determine library dependencies" really mean... "Can't figure out what to do with this so skipping" ?
<zyga> geekgonecrazy: this is something for sergiusens, kyrofa and kalikiana
<zyga> though they are sprinting this week so conditions apply
<geekgonecrazy> zyga: ok fair enough.  I'll roll back our armhf build.  Typically if there is an error building it errors out.  But seems that the skipping of the files isn't an error just a silent thing :(
<geekgonecrazy> i'd keep digging tonight, but gotta prep to head out to fosdem tomorrow.  Do you know if any of the snap/snapcraft team will be attending?
<zyga> geekgonecrazy: I don't know, sorry
<zyga> geekgonecrazy: they have a sprint now in US so probably not
<zyga> though maybe someone else is going
<geekgonecrazy> zyga: no biggie.  Just figured someone around might know :D
<mup> PR snapcraft#1902 opened: many: use in-snap unsquashfs and readelf if running from snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1902>
<ogra_> jdstrand, thanks for the investigation, will file it ...
<ogra_> tyhicks, thanks for the research ! i have the BPF_SYSCALL option set here but still dont see it in /proc/filesystems ... will dig further myself ...
<tyhicks> ogra_: kernel version?
<jdstrand> greyback: hey, you probably saw but I approved your /dev/shm/# pr, but can you add the requested comment?
#snappy 2018-02-01
<mup> PR snapcraft#1902 closed: many: use in-snap unsquashfs and readelf if running from snap <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1902>
<mup> PR snapcraft#1899 closed: elf: readelf dependency <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1899>
<greyback> jdstrand: ack, thank you, I'll add comment tomorrow
<jdstrand> greyback: thanks!
<jjohansen> jdstrand: I am not sure I understand the question, but I'll give it a go. the bpf filesystem is registered during fs init on kernel boot
<mup> PR snapcraft#1903 opened: elf: use surrogate escape when decoding readelf output <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1903>
<mup> PR snapcraft#1885 closed: Release 2.39 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1885>
<mup> PR snapd#4578 opened: Expose payment and account URLs in /v2/system-info <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4578>
<Ender__> Hello
<Ender__> I love Snapcraft !! Does anyone else think this might be a revolutionary design idea ?
<mborzecki> morning
<mvo> zyga: good morning
<mborzecki> mvo: zyga: morning guys
<zyga> morning
<zyga> prepping kids for school
<mvo> hey mborzecki
<zyga> aaand they've gone :-)
<zyga> rain rain rain, but my mood is great today
<zyga> mvo: did you restart https://github.com/snapcore/snapd/pull/4577 ?
<mup> PR #4577: snap: fix command-not-found on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4577>
<mvo> zyga: yes
<mvo> zyga: it had header timeout errors
<mvo> zyga: what is gone?
<zyga> mvo: ah, that was just a reference to my kids and wife, they've all gone to school
<mvo> zyga: :) ok
<zyga> greyback: hello
<zyga> greyback: https://github.com/snapcore/snapd/pull/4572 can land, just add a comment
<mup> PR #4572: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572>
<zyga> hmmm
<zyga> irc spam
<zyga> that's new
<zyga> error: cannot find snap "core": Get
<zyga> https://api.snapcraft.io/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Clicense%2Cbase%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdev
<zyga> eloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<mup> PR snapd#4568 closed: tests: new spead test for openvswitch-support interface <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4568>
<mborzecki> zyga: can you try to install this snap locally? http://apps.syncloud.org/apps/rocketchat_180201_amd64.snap
<mborzecki> zyga: i'm seeing this https://paste.ubuntu.com/26499308/
<mborzecki> core  16-2.31~rc2+git528.a129e36  3982  canonical  core
<zyga> mborzecki: sure, one moment
<zyga> or... 20 minutes
<zyga> slow server?
<zyga> nah, ramping up
<zyga> ~250KB/s
<zyga> 8 minutes
<mborzecki> tmaybe it's capped
<mborzecki> anyway, take a look at the log, install hook fails, ale last line `cannot snap-exec: no such file or directory`
<mvo> mborzecki: what does the install hook look like? a shell script? a binary?
<mborzecki> omg, it's a python script, `#!/snap/platform/current/python/bin/python`
<mborzecki> platform?
<zyga> mborzecki: so, since we established that this hook depends on a snap called "platform" and thus won't work (it cannot execute anything from snaps other than itself) shall I still install it?
<mborzecki> zyga: no, thanks though :)
<zyga> mborzecki: actually, that's something that could be checked store-side
<pstolowski> hey o/
<zyga> hey hey :)
<zyga> reading your PR now :0
<kalikiana> morning
<pstolowski> zyga, thanks! which one?
<zyga> pstolowski: 4551
<mup> PR snapd#4577 closed: snap: fix command-not-found on core devices <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4577>
<mvo> greyback: looks like 4572 is good except for this one comment that jamie asks for, once that it is added this can go in
<mup> PR snapd#4459 closed: snap: add support for `snap advise-snap pkgName` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4459>
<mvo> 4049 needs a second review
<mup> PR snapd#3456 closed: many: add interfaces.SystemKey() helper <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3456>
<mup> PR snapd#4579 opened:  many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4579>
<greyback> mvo: I just pushed the requested comment to 4572
<zyga> thank you
<greyback> thank you!
<mup> PR snapd#4580 opened: tests: ensure disalbled services are masked <Created by mvo5> <https://github.com/snapcore/snapd/pull/4580>
<mvo> ogra_: we have code that masks the rsyslog/ssh units, I added an explicit integration test above. if this does not work for you, I need to know the version of snapd and what command you use and the output of systemctl status rsyslog.service and the output of ls -l /etc/systemd/system
<ogra_> mvo, note that this install comes with rsyslog disabled from the gadget by default ... it definitely was off on fresh install so it must have enabled itself during an upgrade (running edge with locally built gadget and kernel)
<ogra_> mvo, https://paste.ubuntu.com/26499622/
<mvo> ogra_: was it an old install with a core that would not mask on diable?
<ogra_> nope, thats a few days old
<mvo> ogra_: fwiw, because of "synced" for /etc/systemd/system when it is not masked it will come back
<mvo> ogra_: is this fresh image available somehwere? i.e. I wonder if there is a way to boot it and then inspect the state right after boot
<ogra_> mvo, i know ... but i checked that it is off right after install ... so i'm confident it was originally off ... i didnt check the link explicitly though
<mvo> ogra_: afaik the codepath for "snap set core service.rsyslog.disable=true" and the gadget disable is the same but maybe not
<mvo> ogra_: also, the gadget.yaml would be great
<ogra_> mvo, you wouldnt have the HW to run it but i can push the rootfs somewhere
<pedronis> Chipaca: I have some post-facto comments on #4575
<mup> PR #4575: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4575>
<mvo> ogra_: in snap changes, did you see a core refresh around jan 28, 11:50 ?
<Chipaca> pedronis: hm, i can do a followup
<ogra_> phew ... there were a bunch of refreshes ... /me checks
<Chipaca> pedronis: is that why the other ones take *s?
<pedronis> yes
<pedronis> see snapstate.Set for example
<mvo> ogra_: the mtime of the symlink looks different from most other times in this dir
<Chipaca> ok, i'll take a stab at it
<mvo> ogra_: so I suspect writable-path re-creating it
<Chipaca> in a bit
<mvo> ogra_: the rootfs will not be that useful as the disable will happen on firstboot
<pedronis> Chipaca:  IÂ don't think element of config can be nil but good to double check
<ogra_> mvo, thats long scrolled off ... changes starts only at 2018-01-31
<mvo> ogra_: so just by looking at the rootfs I will not see much unfortunately
<mvo> ogra_: ok
<ogra_> mvo, sadly non-registered devices spam changes very regular, changes is pretty unusable during development through that " Error   2018-02-01T09:10:37Z  2018-02-01T09:10:40Z  Initialize device" every few mins
<mvo> :/
<zyga> no exp backoff?
<ogra_> i'll have to do a re-install later today ... i'll see what i can do to trigger it again
<mvo> zyga: sure, from seconds to minutes :P
<mvo> ogra_: an ls -l /etc/systemd/system right after firstboot would be great. ideally using the image you had
<mvo> ogra_: I mean the same image as you used for this one
<ogra_> ok
<zyga> :)
<pedronis> Chipaca: also notice that Get can give you nil bu Set will not take it, so it's probably a problem either way
<pedronis> the lack of symmetry
<ogra_> mvo, oh, crap i just notice i have overwritten that specific image ... but i'll try the oldest one i have
<Chipaca> pedronis: I don't need the * to make the nil check on save though
<mvo> ogra_: no worries, iirc masking was added a little bit later, i.e. for a brief time there was a bug in our new corecfg when it did not mask, let me check when it was fixed
<ogra_> ah !
<pedronis> Chipaca: that's true
<Chipaca> pedronis: a nil json.RawMessage is unserialisable, so I can just check that
<pedronis> Chipaca: the code is broken right now though
<mvo> ogra_: it was added 2017-11-30
<pedronis> if you pass a nil
<ogra_> mvo, well, the image was on auto-update and was definitely built this week ...
<mvo> ogra_: the masking
<pedronis> various things will likely end up unhappy
<Chipaca> pedronis: yep, noticed that :-) was checking on the caller side
<Chipaca> pedronis: will address in a followup and then tweak my callers
<mvo> ogra_: one week indicates something else is going on, I look forward to your ls and servicectl output
<ogra_> mvo, that could match, i built it onday or tuesday morning
<ogra_> *monday
<Chipaca> pedronis: do you remember why the cleanup task waited for an ensure run to kick in? (am I forgetting something non-obvious, or has it always been like this?)
<pedronis> Chipaca: in which sense?
<pedronis> all tasks get triggered by an Ensure cycle
<Chipaca> pedronis: right, and in api.go we do an EnsureBefore(0) to kick them off
<pedronis> yes
<pedronis> but there is also logic in taskrunner
<pedronis> to also do that
<Chipaca> pedronis: but the cleanup task (one added with "AddCleanup") waits for the _next_ ensure before running
<pedronis> if there are dependents
<pedronis> Chipaca: might be missing a kick in task runner
<pedronis> in some cases
<pedronis> or maybe it's hard to decide
<pedronis> to do the kick
<Chipaca> pedronis: ok, when i can push to github i'll pester you about this again; i'm probably missing something silly :-)
<pedronis> I know IÂ have a test where this is an issue
<pedronis> but there is more related to not having all the right managers
<pedronis> around
<pedronis> Chipaca: have you run run-checks --static locally recently?  it logs a lot about tests/lib/snaps/test-snapd-validate-container-failures/hell
<pedronis> it doesn't error but it's a bit on the noisy side
<Chipaca> i put that thing there to stress test some checkers, but not sure which one is getting tricked in --static
<pedronis> seems spell checking afaict
<mup> PR snapd#4581 opened: overlord/configstate/config: make SetSnapConfig delete on empty <Created by chipaca> <https://github.com/snapcore/snapd/pull/4581>
<Chipaca> pedronis: ^
<apply55gx> Hello, is there a way to transfer a snap with all of it's data to another server?
<mborzecki> Chipaca: ^^ snapshots?
<Chipaca> ish
<Chipaca> yes :-)
<Chipaca> except user data might make things weird
<Chipaca> apply55gx: currently, in released snapd, you could do it manually with some care
<apply55gx> @mborzecki do you mean whole server snapshots or is there a way to create a snapshot just of the snap?
<Chipaca> apply55gx: I'm working on a feature to do snapshots of a snap
<Chipaca> apply55gx: but it's not even up for review yet
<Chipaca> so at least a month before it's on stable
<apply55gx> Chipaca: Thank you for your answer. How would you manually do this?
<mup> PR snapd#4582 opened: many: at seeding try to capture cloud information into core config under "cloud" <Created by pedronis> <https://github.com/snapcore/snapd/pull/4582>
<Chipaca> apply55gx: assuming the snap is public, I'd install the snap in the new server, disable it (snap disable $thesnap) so it's there but the services are all stopped, and then rsync /var/snaps/<thesnap> over
<apply55gx> Just copying it won't work, does it?
<Chipaca> apply55gx: if the snap uses 'snap set' to do config there's an extra step
<Chipaca> apply55gx: just copying the snap? it could; you'd need the assertion as well as the snap but you have it
<Chipaca> apply55gx: simpler to just re-get it if you can, but otherwise yes you can just copy it and the assertion, then 'snap ack <the assertion>' and 'snap install <the .snap>'
<Chipaca> apply55gx: if you don't want to figure out which assertion to ack, you _could_ copy everything and ack the whole lot :-)
<Chipaca> apply55gx: that's /var/lib/snapd/assertions/asserts-v0/
<apply55gx> Chipaca: Ok, I'm gonna try getting the snap and just copy the /var/snap/ folder. The other thing seems a bit too complicated for me :-)
<apply55gx> Chipaca: Thank you for your quick answer :)
<Chipaca> apply55gx: if you're able and have the time to describe what you want to do as a feature request, it'd be neat to have it documented
<Chipaca> apply55gx: but no rush for that :-)
<Chipaca> it's just that as far as I know we don't currently have a user story for "copy this snap and all its data to that machine"
<Chipaca> it'd be a step further down the snapshot road
<Chipaca> and enable some nifty migrations, i reckon
<Chipaca> anyhow, back to coding snapshots
<apply55gx> Chipaca: I'll try to document it as good as possible :) Where should I put the documentation afterwards?
<Chipaca> apply55gx: if it's story-ish, https://forum.snapcraft.io; if it's bug-ish, https://bugs.launchpad.net/snapd/+filebug
<Chipaca> apply55gx: if in doubt, chose one at random and we'll sort it out :-)
<apply55gx> Ok, thank you :-)
<ogra_> mvo, ok ... fresh re-install of the oldest image i have here (and in fact the core is from yesterday) ... https://paste.ubuntu.com/26499992/
<ogra_> mvo, so i guess something with applying the gadget config on first boot goes wrong
<mvo> ogra_: this is first-boot?
<mvo> ogra_: i.e. nothing else was run yet?
<ogra_> only ran through console-conf yet ... didnt reboot
<mvo> ogra_: what is the output of "snap changes"?
<ogra_> ogra@localhost:~$ snap changes
<ogra_> ID   Status  Spawn                 Ready                 Summary
<ogra_> 1    Done    2018-02-01T10:27:24Z  2018-02-01T10:28:13Z  Initialize system state
<ogra_> 2    Error   2018-02-01T10:28:10Z  2018-02-01T10:29:24Z  Initialize device
<ogra_> 3    Error   2018-02-01T10:34:24Z  2018-02-01T10:34:27Z  Initialize device
<mvo> ogra_: great, yeah, it looks like first-boot config is broken just not running, the output of journalctl -u snapd might be good
<mvo> ogra_: *maybe* there is an error in there
<ogra_> mvo, nothing in journald https://paste.ubuntu.com/26500004/
<ogra_> (the chopped off likes are just "installing kernel" and "installing gadget"
<ogra_> )
 * kalikiana coffee break
<mvo> ogra_: ta
<mvo> ogra_: looks like a real bug :(
<ogra_> yes
<greyback> any recommendation on how to give someone a custom snapd to test?
<ogra_> write it to a USB key ... get a padded envelope ... put stamps and an address on ... write a note with instructions and send it ?
<mvo> greyback: a binary build for their target arch? push to a url, then ask $person to "wget $url", systemctl stop snapd.socket snapd.server; sudo cp custom-snapd /usr/lib/snapd/snapd; sudo systemctl start snapd.socket snapd.service
<greyback> mvo: ok, so the obvious. Thanks
<greyback> ogra_: you sir need some sugar, you're getting grumpy
<ogra_> lol
<Chipaca> https://pastebin.ubuntu.com/26500106/
 * Chipaca might be having a little too much fun
<mborzecki> Chipaca: at least you're having fun :)
<Chipaca> :-)
<mborzecki> i like the 'probably *fine*'
<ogra_> mvo, https://bugs.launchpad.net/snapd/+bug/1746714
<mup> Bug #1746714: regression: gadget defaults are not applied with latest snapd <snapd:New> <https://launchpad.net/bugs/1746714>
<mup> PR snapd#4583 opened: many: pull apart develoepr and publisher <Created by mvo5> <https://github.com/snapcore/snapd/pull/4583>
<mvo> Chipaca: -^ we talked about the developer/publisher entanglement. the above may help, feedback welcome (cc pedronis)
<mvo> ogra_: thanks, I have a look this afternoon, just wanted to finish the above PR
<ogra_> mvo, yeah, i just wanted a papertrail
<Chipaca> mvo: have you talked with snapcraft and store people about that?
<pedronis> mvo: developer_id in the store is the publisher ATM
<pedronis> and we don't track the developer much really (it's an open task but IÂ don't see it happen soon)
<pedronis> mvo: basically without starting from the store this will just confuse us more
<greyback> zyga: quick qn: I accidentally pushed a commit to my branch, and have commited a revert. Would you rather I redo the branch to have a cleaner history? (https://github.com/snapcore/snapd/pull/4545/commits)
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<zyga> greyback: nah, just --force push
<zyga> greyback: drop that commit and push the right one
<mvo> pedronis: uh, developer_id is publisher_id? and developer_name is also publisher_name?
<pedronis> yes
<pedronis> in the new APIs
<pedronis> they will be called publisher
<pedronis> basically I don't think this makes much sense
<pedronis> until we have a new details API
<mvo> pedronis: fair enough, I will extract the interessting bits from the PR and close it after
<pedronis> mvo: the only place where we get the developer would be snap-revision, but that is also not true atm
<pedronis> because of historical reasons
<mvo> pedronis: what do we get there?
<pedronis> again the publisher
<mvo>  /o\
<mvo> ok
<pedronis> as I said until it is fixed/improved in the store
<pedronis> adding the distinction in snapd is not super useful
<pedronis> we could start adding publisher ==Â developer in packages.go
<pedronis> I suppose
<pedronis> but not much else
<mvo> pedronis: so you think we should not expose ddeveloper at all in the rest api? or just not yet ?
<mvo> pedronis: I'm fine starting with developer = publisher for now and provide publisher via the rest api and then users can transition to the new field. does that make sense?
<pedronis> yes, that make sense
<pedronis> the changes in store/ are problematic
<mvo> pedronis: great, I will update the PR accordingly and add some big  explanation  around this to avoid further confusion
<mvo> pedronis: sure, I will revert those
<mvo> pedronis: well, revert and add comments
<mvo> pedronis: thanks for your input!
<pedronis> it's a bit my fault
<mup> PR snapd#4583 closed: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4583>
<pedronis> PublisherID
<pedronis> and -	info.PublisherID = d.DeveloperID
<pedronis> at some point
<pedronis> but didn't add a comment
 * mvo nods
<pedronis> mvo: also we don't capture the string because we  go from id to strings using the account assertion
<mvo> pedronis: should we remove the string then?
<pedronis> we didn't have it before
<pedronis> there was no publisher
<pedronis> I mean all of store changes need to be reverted
 * zyga takes a break to lay down, back pain
<mvo> pedronis: aha,ok, I misunderstood
<mvo> pedronis: yes, will do that
<pedronis> and maybe added comments
<pedronis> that means also some bit of snap/info.go go away
<pedronis> as well
<mvo> pedronis: thanks, I will do that (and revert bits in info.go too)
 * zyga will skip standup today, not so fun from bed; I'm not feeling good for the last few hours and I'm trying to write docs and examples on new features
<kalikiana> zyga: clearly writing docs is bad for your health :-P
<mup> PR snapd#4584 opened: Introduce LimitedWriter to limit the number of data read from the stdâ¦ <Created by stolowski> <https://github.com/snapcore/snapd/pull/4584>
<Odd_Bloke> I'm seeing some really weird issues trying to use snapcraft ATM.
<Odd_Bloke> I have lxd installed as a deb, but `snapcraft cleanbuild` fails with: subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/daniel/snap/lxd/common/snapcraft_8v82248/core_3887.assert', 'local:snapcraft-paretically-cressiest-elana/run/core_3887.assert']' returned non-zero exit status 1.
<Odd_Bloke> That path looks extremely suspicious.
<Odd_Bloke> (Also, when using a remote lxd, there's no reason to believe that the local path will exist at all snap or otherwise.)
<Odd_Bloke> So I think to myself, "fair enough, let's just build locally for now", and then pip segfaults: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp9uadnku3', '/home/daniel/dev/cloud-test-framework/parts/cloud-test-framework/install/usr/bin/python2', '-m', 'pip']' died with <Signals.SIGSEGV: 11>.
<Odd_Bloke> I see the lxd issue on both the edge and stable snaps; it looks like the stable snap might not have the local-build issue.
 * kalikiana moving to coffee shop for lunch
<ackk> hi, is there a way to get locales to work in a snap? can they be included in the snap itself?
<ogra_> ackk, while this is a very old snap, the wrapper stuff should still work i the new world http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh
<ogra_> (check the stage-packages in snapcraft.yaml too)
<ackk> ogra_, thanks
<mup> PR snapd#4583 opened: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4583>
 * pstolowski lunch
<mborzecki> pstolowski: left you some comments in 4584
<mup> PR snapd#4585 opened: daemon: refactor snapFooMany helpers a little <Created by chipaca> <https://github.com/snapcore/snapd/pull/4585>
<pstolowski> mborzecki, thanks
<sergiusens> kalikiana please look into Odd_Bloke's issue with lxd
<kalikiana> re
<mup> PR snapd#4586 opened: cmd/snap: add completion conversion helper to increase DRY <Created by chipaca> <https://github.com/snapcore/snapd/pull/4586>
<kalikiana> Odd_Bloke: Did you see any errors from lxc? That is, before the Python error message
<kalikiana> Odd_Bloke: Also, what are you finding suspicious there? Snapcraft creates a temporary folder in ~/snap/lxd/common to store files that will be pushed into the container
<sergiusens> kalikiana both kyrofa and popey saw this yesterday too
<Odd_Bloke> kalikiana: Well, I don't have the lxd snap installed, so that's a weird path to use.
<Odd_Bloke> (Also, this isn't the lxd snap, so that's a weird path to use even if I did have it installed.)
<Odd_Bloke> Surely that should be in ~/snap/snapcraft... ?
<mup> PR snapcraft#1904 opened: lxd: raw.idmap expects host and container id respectively <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1904>
<Odd_Bloke> But also, the path it thinks should exist there doesn't, which is a definite problem.
<kalikiana> Odd_Bloke: That path is used so the lxd snap can read the files despite confinement when you use it. It's removed after Snapcraft is done, so it would indeed be empty if you're looking for it afterwards
<kalikiana> sergiusens: Is it related to bug 1746612 ? I tried it with the lxd in Xenial earlier. I still need to try with the backports version as well to see if that's different
<mup> Bug #1746612: Snapcraft cleanbuild doesn't work if you're not using the LXD snap <Snapcraft:New> <https://launchpad.net/bugs/1746612>
<Odd_Bloke> kalikiana: https://paste.ubuntu.com/26501059/ is the full log.
<Odd_Bloke> Basically the file that snapcraft is telling lxd to use isn't present.
<kalikiana> Odd_Bloke: Thanks!
<kalikiana> Odd_Bloke: Actually, does ~/snap/lxd not exist at all? Snapcraft should be creating it
<Odd_Bloke> It does.
<kalikiana> Or is it empty?
<Odd_Bloke> I wiped it out earlier, and it does still have stuff in there.
<Odd_Bloke> /home/daniel/snap/lxd/common/snapcraftyu2pnqwq looks like it was just created by my cleanbuild run.
<kalikiana> Odd_Bloke: It should've re-created folder regardless of the lxd snap being there
<kalikiana> Although I can appreciate that it seems a little "odd"
<kalikiana> Odd_Bloke: On my system I can see ~/snap/lxd/common with no contents even after removing ~/snap/lxd
<kalikiana> Not sure if there's some other intermediary step I'm overlooking
<kalikiana> Odd_Bloke: btw which version of lxd are you using? ie. `apt show lxd | grep Version`
<Odd_Bloke> Why would ~/snap/lxd/common exist if you've removed ~/snap/lxd?
<kalikiana> Odd_Bloke: Because Snapcraft creates it :-)
<Odd_Bloke> That is all sorts of crazy, IMO.
<Odd_Bloke> But whatever.
<Odd_Bloke> I'm running lxd 2.21-0ubuntu2 (in bionic).
<kalikiana> Odd_Bloke: If LXD is confined, it can't read arbitrary stuff in your ~
<Odd_Bloke> Sure, but my lxd isn't confined, nor is it even local, so snapcraft shouldn't create random folders in my filesystem.
<Odd_Bloke> But I don't particularly care about that ATM, it doesn't work even doing that. :p
<Odd_Bloke> kalikiana: OK, hold on, that file does exist locally.  But /var/lib/snapd/hostfs/ is empty.
 * kalikiana wishes Launchpad's search wasn't so terrible, trying to confirm if this is related to another known issue
 * kalikiana can't even find *this* bug report by searching for it...
<zyga> kalikiana: hey
<zyga> zyga@fyke:~/content-interface-2.0/hub-app$ snapcraft
<zyga> Issues while validating snapcraft.yaml: Additional properties are not allowed ('license' was unexpected)
<zyga> where can I specify the license?
<kalikiana> zyga: Where did you try to put it? It should be a toplevel item like summary or description
<zyga> kalikiana: yeah, there
<zyga> snapcraft, version 2.34+17.10
<zyga> kalikiana: I put
<zyga> license: MIT
<kalikiana> zyga: can you paste the YAML somewhere? then I can double-check if it works here
<zyga> sure
<zyga> http://paste.ubuntu.com/26501365/
<kalikiana> zyga: Doesn't seem to work indeed.... not sure tbh
<zyga> seems like something that fits the overal license work now
<zyga> niemeyer: ^ FYI (on license)
<niemeyer> Can we please not have yet another thread here?  We have two topics in the forum active right now on this topic.
<zyga> niemeyer: not a thread, just pointing out that it seems setting license via snapcraft doesn't work
<niemeyer> zyga: Sounds like something worth pointing out in the right topic, in the forum?
<zyga> sure, I'll add it to snap-license-metadata thread
<zyga> niemeyer: thank you!
 * zyga feels better now, gets back to work
 * kalikiana feeling a little exhausted from all the debugging today, going to wrap up
<niemeyer> zyga: Thanks for reporting
<greyback> anyone mind hitting merge on this, it should be good to go: https://github.com/snapcore/snapd/pull/4572
<mup> PR #4572: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572>
<zyga> greyback: looking
<zyga> ah
<zyga> yes
<zyga> merged :)
<mup> PR snapd#4572 closed: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4572>
<zyga> thank you! :)
<greyback> zyga: sweet, thank you
<greyback> and I'll just leave https://github.com/snapcore/snapd/pull/4545 hovering in the background :)
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<jdstrand> jjohansen: thanks. I think tyhicks gave ogra_ the additional details he needed
<zyga> greyback: will that shirnk when you merge master?
<zyga> jdstrand: hey, do you have 2 minutes for a quick chat?
<ogra_> jdstrand, yeh, but i dont see the filesystem either way (though at least htis kernel now has syscall filtering enabled which is missing in the sample-kernels tree)
<jdstrand> zyga: I think so
<jdstrand> zyga: go ahead
<greyback> zyga: no unfortunately
<greyback> it's a non-trivial one
<greyback> no rush though
<zyga> ok
<tyhicks> ogra_: what do you mean by "can't see the filesystem"? it isn't in /proc/filesystems or it isn't mounted at /sys/sys/bpf/ ?
<ogra_> tyhicks, /proc/filesystems
<tyhicks> ogra_: what kernel version?
<ogra_> btw it is a 4.1 tree
<tyhicks> ogra_: ah, I mentioned yesterday that the bpf filesystem first showed up in 4.4
<ogra_> (and effectively a throw-away kernel ... we'll get a 4.4 later)
<ogra_> ah, ok
<tyhicks> the code isn't there in 4.1
<mup> PR snapd#4587 opened: osutil: make MkdirAllChown clean the path passed in <Created by chipaca> <https://github.com/snapcore/snapd/pull/4587>
<ogra_> well, at least the missing of it in /proc/filesystems got me on the right track :)
<tyhicks> :)
<Chipaca> 4 small (biggest is ~100 lines) and easy (sez me) PRs up by me if you're feeling like doing reviews
<cachio_> pedronis, hey, I see this error on dragonboard after I refresh to beta from stable
<cachio_> https://paste.ubuntu.com/26501684/
<cachio_> pedronis, any idea what could be causing that?
<niemeyer> I've just found out that apparently "skype" and "snap" is a trigger for adult content in social media
<mup> PR snapd#4588 opened: Snapshots! <Created by chipaca> <https://github.com/snapcore/snapd/pull/4588>
<Chipaca> <<<<< ^^^^ >>>>>>
<Chipaca> or something
 * Chipaca goes for a cuppa tea
<Chipaca> before I go just let me say that <+2,226 â77> might be a little intimidating (but read the description)
 * ogra_ finally runs "snap alias snapcraft sergiusens"
<Chipaca> ogra_: snap alias --internal install remove
 * Chipaca runs to see about that tea
<ogra_> uuuh, mean !
<ogra_> (i was just reacting to niemeyer's typo and sergios funny comment here )
<mvo> Chipaca: wooo!
<mup> PR snapd#4583 closed: many: pull apart develoepr and publisher <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4583>
<niemeyer> ogra_: typo?
<ogra_> niemeyer, you called him "@snapcraft" ;)
<ogra_> freudian typo :)
<ogra_> (on the forum)
<niemeyer> ogra_: I see.. "typo" :)
<ogra_> heh
<niemeyer> Would be nice if snapcraft could respond.. would make things easier
<ogra_> well... all w need is a mycroft snap and teach it to react to "snapcraft" ...
<mup> PR snapd#4589 opened: many: remove "content" argument from snaptest.MockSnap() <Created by mvo5> <https://github.com/snapcore/snapd/pull/4589>
 * ogra_ looks forward to "voice based yaml validation"
<pedronis> cachio_: my guess is that something is off with the time on that board
<mup> PR snapcraft#1905 opened: Remove dangling symlink from JDK plugin (LP Bug #1617296) <Created by ARostovsky> <https://github.com/snapcore/snapcraft/pull/1905>
<zyga> FAIL: cmd_userd_test.go:62: userdSuite.TestUserd
<zyga> cmd_userd_test.go:84:
<zyga>     c.Assert(err, IsNil)
<zyga> ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'")
<zyga> hmm
<mup> PR snapcraft#1903 closed: elf: use surrogate escape when decoding readelf output <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1903>
<mup> PR snapcraft#1906 opened: remote_parts: handle connection errors <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1906>
<mup> PR snapcraft#1907 opened: tests: setup the correct environment for adt <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1907>
<bartkmq> how do i get firefox to open snap:// links (from snapcraft.io) on Arch? is that an ubuntu only feature?
<kyrofa> Yeah that's typically handled by the software center
<bartkmq> kyrofa, thanks for the tip, installing gnome-software fixed the problem
<mup> PR snapd#4590 opened: cmd/snap-confine: allow constructing layouts (phase 1) <Created by zyga> <https://github.com/snapcore/snapd/pull/4590>
<zyga> :-)
 * zyga ends with working layouts :)
<zyga> I think it's time to EOD
<zyga> kyrofa: hey
<zyga> kyrofa: is LXD okay for you now?
<zyga> bartkmq_: please open a forum topic, we'll get it to work on arch as well
<zyga> bartkmq_: one of the snapd developers uses arch as his main system
<zyga> we'll get it fixed
 * zyga is super excited
<zyga> *layouts*
<zyga> jjohansen: o/
<zyga> Chipaca: o/
<Chipaca> zyga: \o
<Chipaca> zyga: you suck at EODing
<zyga> yeah
<zyga> have you EODed?
<zyga> if not, would you like to eyeball that PR above?
<jamesh> zyga: hi.  I've been looking at trying to verify that a mount occurred as expected via /proc/self/mountinfo.  It works for the simple cases, but seems to get tripped up when it gets called while creating writable mimics.
<jamesh> zyga: I'm trying to work out if this code is a lost cause, and jdstrand suggested you might have an idea
<zyga> jamesh: I'm about to close my laptop, can you please write me a small example (email/forum) and I will help you out tomorrow
<zyga> jamesh: IMO it's hard
<jamesh> zyga: sure.
<zyga> jamesh: based on my experience and prior analysis
<zyga> because the mountinfo shows what is mounted
<zyga> not how it was achieved
<zyga> while fstab-like entries show how to achieve something
<zyga> but doesn't describe the prior state or capture how the state is tranformed
<zyga> so it's non-trivial to answer a question "has <fstab-mount-entry> been mounted"
<zyga> and that's why the design of update / undo logic in snap-update-ns is focused on the fstab profiles alone
<zyga> and not on mountinfo as that is very complex (also because snap-confine does a lot of stuff)
<zyga> but I may have misundertood your question as it's super late now
<zyga> give me an example to work with and I'll help as much as I can
<jdstrand> zyga: he's trying to verify we mounted correctly
<jdstrand> zyga: the dst mountpoint is easy to verify since it has the full path of the mountpoint
<jdstrand> zyga: but the source mount gets truncated in various scenarios. so, if he mount $XDG_RUNTIME_DIR/foo/bar, he might only see /foo/bar instead of /run/user/1000/foo/bar
<zyga> jdstrand: !
<zyga> thanks
<zyga> I see
<zyga> how is mount source truncated
<zyga> mount source is always <device,filesystem,subtree>
<zyga> jdstrand: *thank you for the review*
<jdstrand> zyga: so, XDG_RUNTIME_DIR is a tmpfs already which may be part of it. jamesh can give specific examples
<jamesh> jdstrand: I was able to handle that case by combining the mount source with the mount destination of the parent mount
<jdstrand> ah, cool
<zyga> jdstrand: I replied on the review, I'll tweak the things that are simple but check one of the things I contended with
<jamesh> it seems the be the writable mimic tmpfs that was causing the problem.  I was expecting to compute "/snap/test-snapd-content-advanced-plug/x1" as a source and got "/tmp"
<zyga> jamesh: how do oyu compute that?
<zyga> jdstrand: about your main question, we could just abort startup if mount fails
<zyga> jdstrand: not ignore and carry on
<zyga> jdstrand: I'd like that actually
<jamesh> zyga: I first search through mountinfo for an entry that matches the destination mount point.  I then search for the parent mountinfo entry, and combine the parent's mount point with the original entry's root field
<jamesh> that seemed to be enough for the simple cases
<zyga> jamesh: hmm, I'm not sure yet; I will need an example with some data to read and think through
<jamesh> zyga: I'll put together an email for you to read tomorrow
<zyga> thank you
<jamesh> it must be almost midnight for you
<zyga> jdstrand: please recheck my responses
<zyga> jdstrand: I think it's correct as-is unfortunately
<jdstrand> zyga: abort startup would be fine. layouts aren't dynamic like content interface connections
<zyga> jdstrand: I can tag layouts with x.snapd=mandatory
<zyga> and abort on such entries
<zyga> should we abort on content things as well?
<zyga> I'm not sure why we didn't
<jdstrand> zyga: aborting makes sense anyway-- if it doesn't get the layout it needs, it has little chance of working correctly
<zyga> yeah
<zyga> I think that's sensible
<jamesh> it'd probably be simpler to abort on the other mount failures
<zyga> and would be better in case if prior mount is a base for next operation
<jdstrand> it is nice when logic and security go hand in hand :)
<zyga> it's uncertain what happens in that case
<jdstrand> btw, I responded to your comments
<zyga> jamesh: Day changed to 02 lut 2018
<zyga> :)
 * zyga checks
<zyga> jdstrand: I'm happy we got here
<zyga> I wish we had more vocabulary in appamor
<zyga> and I know it's not a 2.31 goal anymore
<zyga> I think we need those per-snap profiles, yeah
<zyga> otherwise this is very open and broad
<jdstrand> apparmor is great, but yeah, like so many other parts of snapd, we are pushing the limits
<zyga> jdstrand: on the other hand
<jdstrand> zyga: per snap profiles would make this way more palatable, yes, but we can tightly control what is added
<zyga> *it works* :)
<jdstrand> because*
<jdstrand> the fact that it works is excellent!
<zyga> I wrote a test snap with layouts, I will use it as a base for spread test tomorrow
<jdstrand> I wouldn't mind this being committed to master once the other points go through on the precondition that a 2.32 milestoned second PR adds snap-update-ns profiles
<zyga> jdstrand: wait, which other points?
<zyga> the comment?
<jdstrand> we forgot to talk about what that would look like
<zyga> and wait, are you saying it's okay to merge this for 2.31?
<jdstrand> the comments and the fixes to the rules you agreed to. the small stuff
<jdstrand> I am expressly *not* saying to merge this for 2.31 :)
<jdstrand> I'm saying it is good for *master* now so long as 2.32 has a milestoned second PR to add per-snap s-u-n profiles
<jdstrand> s/now/now, so long as the other bits are addressed/
<zyga> jdstrand: ah, I understand now
<jdstrand> but I'll let mvo decide on that
<zyga> jdstrand: can you please add a comment about which things require no changes (for me and mvo)
<jdstrand> ok
<zyga> thank you
<zyga> jdstrand: so 2.32 will have per snap s-u-n profiles and will be ok for release, right?
<zyga> (and now it's not)
<zyga> http://paste.ubuntu.com/26502895/
<zyga> this is what I changed so far
<zyga> (based on the discussion above)
<jdstrand> zyga: +1
<zyga> pushed
<jdstrand> zyga: I've commented in the PR. since it is so late for you, maybe we pick up on monday how to implement the per-snap s-u-n profiles?
<zyga> jdstrand: if you tell me now it will be read tomorrow :)
<zyga> (or just write it, I will read it again in the morning)
<jdstrand> zyga: I think the only sane way is to create a template that removes the fixme rules (and any others that are too general), then construct it like the other profiles
<jdstrand> zyga: ideally they would live in /var/lib/snapd/apparor/profiles, but that isn't a strict requirement
<zyga> jdstrand: yeah, I plan to do that
<zyga> jdstrand: we have a namespace
<zyga> jdstrand: the tricky thing (for me, it's probably easy) is how to construct the header
<zyga> and what's the apparmor C api to switch to a named profile (probably in the man page)
<zyga> I would call the profiles "snap-update-ns for $SNAP_NAME" (with proper syntax, suggestions welcome)
<jdstrand> zyga: you'll need to update the code to change_onexec/change_profile (I can't remember otoh which you are using) to this profile for the s-u-n operation
<jdstrand> zyga: snap-update-ns.$SNAP_NAME ?
<jdstrand> zyga: both on disk and the profile name
<zyga> +1
<zyga> yeah, looks good and doesn't clash
<zyga> and I would do it for *all* snaps
<zyga> no need to fall back
<jdstrand> you technically don't need to do it for all snaps.
<zyga> mmm,
<jdstrand> you *could* use the child profile for non-layouts snap-update-ns calls, and the other for layouts calls
<zyga> but snap-confine will now have to *explicitly* set profile for snap-update-ns
<jdstrand> but I think that is apremature optimization
<zyga> yeah, I agree
<jdstrand> if we find the number unreasonable or whatever, we can change to that
<zyga> if those are identical will apparmor optimize those?
<jdstrand> no
<zyga> mm, ok
<zyga> we could look at that then, just not in 1st branch
<jdstrand> so there is compile time and kernel memory. at somepoint we'll have the ability to work with templates better, and sttitch things together
<jdstrand> so you could load the template rules, and then say 'ad these' for foo and 'add these' for bar
<jdstrand> then the size is template + foo + bar instead of template_ foo + template+ bar
<jdstrand> size and compile time
<zyga> yeah but for the simple case where profiles "foo" and "bar" are *identical* and not associated with a path
<jdstrand> but we don't have that. it is planned
<zyga> that will be the same blob to load
<zyga> is that also not optimized?
<jdstrand> no
<zyga> ok
<zyga> btw, what's the right header ?
<jdstrand> they aren't actually identical-- the profile name is different :)
<jdstrand> the contents are identical though
<zyga> ahh, right
<zyga> good point
<jdstrand> e can achieve what you want there by doing what I said-- only using a child or otherwise named profile and transitioning to that. means added code complexity
<jdstrand> as opposed to apparmor just doing it
<jdstrand> it probably wouldn't be terrible to do that. think about it
<zyga> k
<zyga> @LIBEXECDIR@/snap-confine (attach_disconnected) {
<zyga> so in the new profiles will that look like
<zyga> snap-update-ns.hello (attach_disconnected) { ... }
<jdstrand> so the profile change itself is the simple aa_change_onexec
<jdstrand> zyga: yes
<zyga> cool
<zyga> I'll get it done first thing tomorrow
<zyga> if rc3 comes along it _may_ be in 2.31
<zyga> 2.32 is in a month
<jdstrand> zyga: instead of the Cx rules, you'll add to snap-confine's profile: change_profile -> snap-update-ns.*,
<zyga> thank you, that's a good point
<jdstrand> zyga: ok, I won't be able to review this until monday, but if it is there monday morning, I can do it first
<zyga> that's okay
<zyga> I will review the bulk of it with mvo and gustavo
<zyga> and we'll see what to do about it
<zyga> thank you, I think it's closer than ever now :)
<mup> PR snapcraft#1880 closed: Provide stub for when /etc/os-release doesn't exist <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1880>
#snappy 2018-02-02
<mup> PR snapcraft#1907 closed: tests: setup the correct environment for adt <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1907>
<kyrofa> cprov, any chance you're around?
<cprov> kyrofa: hey, how can I help ?
<kyrofa> Something interesting has come up and I'd like your advice. You're familiar with the format of the snapcraft credentials file?
<kyrofa> Turns out there are two ways to utilize export-login, one anticipated, and one not
<cprov> kyrofa: not by heart, go on
<kyrofa> One way is to encrypt the credentials file, save the decryption key in CI, and use it to decrypt the file, then use the file to log in
<kyrofa> (it's an ini file basically)
<kyrofa> That ^ is the anticipated usage
<cprov> Right
<kyrofa> However, some folks here are building tooling that actually saves the individual macaroons out of the credentials file, putting THOSE into the CI environment, and then reconstructing the file itself in order to login
<kyrofa> This works of course, but is quite fragile. What if we change the login URL, or any part of that file format
<kyrofa> So I'm trying to think of a way to make it more... token-ish
<mup> PR snapcraft#1908 opened: tests: update tests to work in adt <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1908>
<kyrofa> But it's weird because we have a root macaroon and a discharge
<kyrofa> (or however that works)
<kyrofa> I dunno, I guess I just wanted your thoughts
<kyrofa> It would be cool if people could just paste the entire creds into an environment variable instead of needing to encrypt a file
<cprov> kyrofa: we can serialize/discharge it  and have the authorization token
<kyrofa> So is the discharged one the only one we need?
<cprov> But i am not sure it is that easier to use
<kyrofa> cprov, here's another use-case for something like that: https://pastebin.ubuntu.com/26503341/
<elopio> snappy-m-o autopkgtest 1908 xenial:armhf xenial:arm64
<kyrofa> I'm writing a Travis deployer
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmpb03l5uir/retry_autopkgtest.sh', '1908', 'xenial:armhf', 'xenial:arm64']' returned non-zero exit status 1
<kyrofa> cprov, that's an example of AWS, note how they handle the access keys
<cprov> kyrofa: i guess we snacraft can consume the a env var with the final secret
<kyrofa> cprov, what would that final secret be, though? The unbound_discharge that we have in the config file now?
<kyrofa> cprov, sorry, still pretty dense on macaroons :D
<cprov> kyrofa: no, we have to bind it
<elopio> snappy-m-o autopkgtest 1908 xenial:armhf
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmp1bapez85/retry_autopkgtest.sh', '1908', 'xenial:armhf']' returned non-zero exit status 1
<cprov> It is called serialize_for_request(), iirc
<kyrofa> deserialize_macaroon, maybe?
<cprov> Let me find it, one sec
<kyrofa> Ah, no: root_macaroon.prepare_for_request
<cprov> kyrofa: yup, https://github.com/cprov/surl/blob/master/surl.py#L130
<kyrofa> Okay so if I save that `bound` value then, that's all I need?
<kyrofa> Does that have the same expiration time as the macaroon?
<cprov> kyrofa: not only the bound discharge, you also need the root to build an 'Authorization' header the store can validate
<cprov> kyrofa: 'Macaroon root={}, discharge={}', then we can probably hex encode the text and pass it in as a ready to use secret
<kyrofa> cprov, ah, okay gotcha
<kyrofa> cprov, I think that's a good idea. And `login --with -` will read from stdin
<kyrofa> cprov, thank you for letting me borrow your brain :)
<cprov> kyrofa: good idea about allowing stdin for pipe-ing evn vars
<cprov> env, even
<kyrofa> Yeah that already works
<cprov> kyrofa: the b64 encoded auth is about 4k, a bit too long to be a secret. That's the only problem I can see.
<mup> PR snapcraft#1909 opened: Add dotnet command to path and enable developer scenario for  snap  <Created by rakeshsinghranchi> <https://github.com/snapcore/snapcraft/pull/1909>
<mup> PR snapcraft#1910 opened: tests: expect in-snap unsquashfs when using docker <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1910>
<mup> PR snapd#4591 opened: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4591>
<mup> PR snapd#4592 opened: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() for 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4592>
<mup> PR snapcraft#1911 opened: Add support enable configurable runtime version for .NET Core applications <Created by rakeshsinghranchi> <https://github.com/snapcore/snapcraft/pull/1911>
<zyga> o/
 * zyga preps breakfast for kids
<mborzecki> morning
<zyga> hey
<mborzecki> zyga: o/
<mborzecki> zyga: on the same note as this https://forum.snapcraft.io/t/spotify-cannot-create-tmpfs-target/3805/7 do we create /var/lib/snapd/lib/gl automatically?
<zyga> mborzecki: no, we need to do that
<zyga> I think we create one of those
<zyga> but not all perhaps
<zyga> and this needs to be rc3 IMO
<zyga> I'm going to take a shower, let's discuss soon
<zyga> look at snap-confine's tree that handles that
<mborzecki> ok
<zyga> let's add the mkdir's there
<mborzecki> zyga: we should cover lib/gl, lib/gl32 and lib/vulkan then
<zyga> all of the variants enumerated from the regular expressions in the apparmor profile
<zyga> well
<zyga> I assume there are variables for that
<zyga> and that on any given system there's a fixed amount
<mborzecki> right
<mborzecki> zyga: will you be looking into this?
<zyga> mborzecki: mmm, maybe, depends on timing
<zyga> I need to discuss with mvo first
<zyga> mvo: good morning
<zyga> mvo: I have great news and bad news
<zyga> mvo: pick :)
<mvo> hey zyga
<mvo> zyga: bad first
<zyga> mvo: we need to add some code that creates new directories in /var/lib/snapd/lib/{gl,vulkan,...}
<zyga> mvo: people are running into this if they use rc2 and have nvidia and reexec
<mvo> zyga: *nod*
<zyga> mvo: it's small but a little annoying that we found out this late
<zyga> mvo: ikey can help I'm sure, with his array of hardware
<zyga> mvo: the good news is that if we wait for monday (jdstrand is off today) we can get fully functional layouts tooo
<zyga> though that is more complex than we initially discussed because of confinement
<zyga> in any case, it will be ready today and it's an option
<zyga> (maybe "layouts beta"
<zyga> anyway, that's the news, how are you feeling today?
<mvo> zyga: hm, we want to be in candidate by monday
<mvo> so thats a tough one
<zyga> so let's fix the bad news and play safe
<zyga> we can be in edge with layouts
<mvo> yeah
<zyga> I'd love 2.31 but I agree that this is an added risk
<zyga> mvo: perhaps we should disable layouts for 2.31
<mvo> he will also not be able to review before .eu evening, right?
<zyga> (entirely with some early return)
<zyga> I think he will, he is just traveling today
<zyga> he was super exited about what we did last night
<zyga> maybe over weekend, we'll see
<zyga> we just realized we need per-snap snap-update-ns profiles
<zyga> because otherwise snap-confine becomes unconfined
<zyga> we discussed the details already and implementation is straightforward
<zyga> my plan today is to get layous ready in master, do the per-snap snap-update-ns profiles done, write spread tests and merge that
<zyga> if you want I can help with missing directories
<mvo> zyga: help> would be great, just catching up with mails and stuff
<zyga> same here :)
<zyga> hey spineau
<spineau> morning zyga
<kalikiana> good morning everyone
<pstolowski> mornings!
<zyga> hey pstolowski
<zyga> sorry I didn't finish that review yesterday, I wasn't feeling good and ended up being unproductive for first half of the day
<zyga> pstolowski: I read the code and it was OK so far, I wanted to see if there's anything missing by checking the non-diff parts and stopped there
<pstolowski> zyga, 4551?
<zyga> yes
<pstolowski> zyga, ok, thanks for looking at it. Gustavo had objections against not reusing "conns" in the state for that, but perhaps I explained my reasoning purely in the standup (and he didn't look at the code yet afaict)
<pstolowski> zyga, feeling better today?
<zyga> yes
<zyga> my back is okay, not sure why it hurt so much yesterday
<zyga> it's not like broken bones that hurt when weather changes
<zyga> thank you :)
<pstolowski> glad to hear!
<ikey> grats on skype
<mup> PR snapd#4593 opened: advisor: ensure commands.db has mode 0644 and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4593>
<zyga> hey ikey
<zyga> :)
<zyga> snaps are starting to get popular :)
<zyga> ikey: any issues on solus, I cannot wait to get skype off from classic confinement
<ikey> zyga, not tried the one in the store yet
<ikey> got back home late yesterday
<mup> PR snapd#4594 opened: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4594>
<mborzecki> ^^ more thinking than coding :/
<mborzecki> zyga: about those lib/gl[32], lib/vulkan directories, shall i look into it?
 * ikey perks up ears at mention of the one domain he looks at
<mborzecki> mvo: pstolowski: ikey: morning guys
<ikey> morning
<pstolowski> o/
<ikey> mborzecki, might i query whats changing in gl/vulkan land?
<mborzecki> ikey: https://forum.snapcraft.io/t/spotify-cannot-create-tmpfs-target/3805
<mvo> hey mborzecki
<ikey> is there some missing stuff on the hostside?
<ikey> i.e missing host dir
<mborzecki> ikey: yup
<ikey> so packaging fixes, gotcha
<ikey> thought the dirs were changing :D
<mvo> mborzecki: thanks for the PR
<ikey> technically the vulkan stuff would be my fault, sorry guys
<mborzecki> mvo: i'll try to check it with that guy's snaps, but i'm missing some of the stuff he added in his snapd fork (btw. it'd be great if he opened an PR :P)
<zyga> mborzecki: mmm, yeah go for it please, I'm working on new profile generation
<zyga> thank you for taking care of that
<mup> PR snapd#4595 opened: snap: improve validation of snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4595>
<zyga> mvo: this one is for 2.31, it will ensure 2.32 won't reject snaps accepted by 2.31 (layouts)
<Chipaca> moin
<mvo> hey Chipaca ! good morning
<mborzecki> Chipaca: morning
<pstolowski> Chipaca, o/
<zyga> hey Chipaca
<mborzecki> hm no luck with syncloud's platform snap either https://paste.ubuntu.com/26504652/
<zyga> mborzecki: you could try with layouts soon :)
<zyga> *today*
<zyga> you can remap /opt/disk to $SNAP_DATA/opt/disk
<zyga> (or to snap common)
<zyga> mborzecki: try with my branch from last night
<mborzecki> fyi https://www.reddit.com/r/linux/comments/7ukrbq/microsoft_releases_skype_as_a_snap_for_linux/
<kalikiana> yay for skype snap ^_^
<mborzecki> btw there was a post on slashdot too
<mborzecki> don't know if anyone visits the site still, but here it is https://linux.slashdot.org/story/18/02/01/1644250/microsoft-releases-skype-as-a-snap-for-linux
<mborzecki> the year of linux desktop is upon us :P
<pstolowski> :)
 * zyga reads slashdot
<zyga> mborzecki: haha, yes
<mborzecki> now that we've had at 's' with releases we'll probably never get to see photoshop as snap, and i can't really think of any interesting application that starts with 't'
<zyga> mborzecki: total commander ;-)
<zyga> mborzecki: we'll wrap around and 'a' will come with adobe busyware
<mborzecki> total commander - the 'ever' shareware
<Chipaca> mborzecki: thunderbird :-p
<mborzecki> zyga: i'd swap adobe for autodesk, see their A* suite running on linux
<zyga> mborzecki: yeah, I remember using *commander style programs since forever essentially
<zyga> when I was 9 and we got a 386 at home
<mborzecki> haha, remember 'dos navigator'?
 * zyga googles
<zyga> maybe not by name
<zyga> I didn't speak english back then
<zyga> so things were "magic"
<zyga> so the name doesn't ring any bells but 1st screenshot I see is "yep, used that"
<pstolowski> mborzecki, mvo thanks for you comments to 4584, i've implemented your suggestions (and the aspects we discussed yesterday during standup)
<mvo> pstolowski: nice, thank you
<mborzecki> hmm so a friend of mine tried installing skype on 17.10: https://paste.ubuntu.com/26504804/
<mvo> mborzecki: server side overload? we see a lot of failures in spread as well
<mborzecki> he got: 2018/02/02 10:39:47.590935 backend.go:152: cannot create host snap-confine apparmor configuration: cannot replace snap-confine apparmor profile: AppArmor parser error for /etc/apparmor.d/snap.core.3887.usr.lib.snapd.snap-confine in /etc/apparmor.d/snap.core.3887.usr.lib.snapd.snap-confine at line 11: Could not open '/var/lib/snapd/apparmor/snap-confine
<zyga> is /var/lib/snapd/apparmor/snap-confine a directory?
<zyga> it should be
<mvo> ogra_: quick question about the gadget defaults for core> you say this worked for 2.30? are you sure? then I will check the diff between the 2.30->2.31, so far I have not found a smoking gun (but adding a test case right now :)
<ogra_> mvo, not 100% ... i have definitely checked it a week or two ago and there it was behaving
<ogra_> i'm not 100% sure about the exact version though
<mvo> ogra_: how much work is it for you to run this again with stable (2.30)? if trivial it would be nice to double check
<ogra_> i currently have the system completely messed up (trying out grub-uboot atm) ... it would take a bit
<zyga> hmm, tests are sad today
<pedronis> Chipaca: snapshots it's big,  usually indeed we would split overlord, daemon/client and cmd/snap bits in different PRs
<Chipaca> pedronis: yep, thus the commits
<Chipaca> pedronis: having 4-5 RFC PRs didn't seem to me to be something that'd progress
<Chipaca> I'm not expecting a deep nitpicky review of this, just a "yeah that's what it should look like" / "WTF are you on can i have some" thing
<zyga> Chipaca: can I have some
<zyga> it must be good :)
<Chipaca> zyga: diclofenac + pridinol (but not too often)
<mvo> ogra_: re 1746714> there seems to be  typo there, in your gadget it should read "rsyslog:\n  disable: true" - your gadget has disable*d*
<ogra_> oh man
 * Chipaca ~> physio
<zyga> ogra_: no validation?
<ogra_> zyga, obviously not
<mvo> zyga: config schemas is on the roadmap for some time
<mvo> for core we could (nowdays) probably "emulate" them
 * mvo thinks a bit
<ogra_> well
 * zyga feels like having a hangover, needs more water
<ogra_> even an error when it is attempted to be set would already help here
<zyga> (weather is terrible lately)
<kalikiana> zyga: you realize you just said you want to have a hangover? ;-)
<mborzecki> zyga: should't the vulkan code be outside of nvidia specific pieces?
<zyga> kalikiana: oh yes
<zyga> it came out wront
<zyga> wrong
<zyga> see!
<zyga> I feel like I have a hangover, not like I would like to have one
<kalikiana> :-D
<zyga> mborzecki: not sure, good question
 * kalikiana coffee break, back in a bit
<zyga> mborzecki: I think not
<zyga> mborzecki: it's not about nvidia but about external drivers
<pstolowski> oh the tests are very unhappy today, indeed
<mvo> ogra_: I wrote a testcase and I think once the typo is fixed this will work
<pedronis> mvo: I don't know if we can error, but we could at least  log a warning if we see core configs that we don't know about
<mvo> niemeyer: quick question - we just had this issue that an invalid core config option was used, for core itself we could validate if its a supported option, do you think that is worth persuing? probably not hard, we just need to expose something like config.Transaction.ChangesKeys() or something
<mvo> pedronis: yeah, that was what I was thinking
<mvo> pedronis: also it kind of buged me a bit that we do not test setting core options right now in spread, unfortunately because core has no snap-id its not easy to test (I hacked a bit and with https://paste.ubuntu.com/26505078/ it works)
<pedronis> because of nesting is not super obvious what it means though
<pedronis> mvo: IÂ wonder if we should have a special key for   that could be used there  and would work also for non store core
<pedronis> mvo:  like $core or something
<mvo> pedronis: oh, nice
<mvo> pedronis: I like that idea
<pedronis> it also would solve the issue that core doesn't have the same id in prod and staging (not super important but it's an issue for testing)
<pedronis> anyway just an idea
<mvo> pedronis: I can prepare the pastebin as a proper PR with $core
<pedronis> the other option would be to invent a general syntax to use name instead of id, it's a bit a pity if we go there because then it would have been saner to have a special syntax for ids instead
<pedronis> we will have the same issues with the connect functionality
<pedronis> btw
<pedronis> mvo: anyway $core is also interesting because is a bit unclear what should happen when we split core  vs base or have core-16 etc
<mvo> pedronis: excellent point
<mvo> pedronis: could we use heuristics? i.e. is the snap-id longer than the allowed snap names?
<pedronis> I don't remember what are the rules
<pedronis> ids are fixed lentgh
<pedronis> IÂ think
<pedronis> we don't have a size limit in snapd for names
<mvo> pedronis: yeah, that is what I remember too, might be worth looking at. anyway, I make this $core thing and will ask about validation in the standup, nested values will be a bit nasty but iirc we don't use those for the core config
<pedronis> but I think there is one in the store
<mvo> pedronis: yeah, thats what I remember, I had to shorten some test snaps
<mvo> because the store was unhappy :)
<pedronis> I can check that
<pedronis> (in a bit)
<mvo> pedronis: no rush. it looks like snap-id is 32char, I think snap names can be larger so a heuristic may not be easily possible
 * mvo is slightly sad about this
<pedronis> anyway using ids was quite intentional I think, just a bit annoying
<pedronis> but core is a bit special because reasons
<pedronis> anyway something to discuss with Gustavo
 * mvo nods
<pedronis> mvo: snap name max length is 40
<pedronis> (in the store)
<mvo> pedronis: ta
<zyga> mvo: does this fail on your machine?
<zyga> ----------------------------------------------------------------------
<zyga> FAIL: cmd_userd_test.go:62: userdSuite.TestUserd
<zyga> cmd_userd_test.go:84:
<zyga>     c.Assert(err, IsNil)
<zyga> ... value *errors.errorString = &errors.errorString{s:"cannot obtain bus name 'io.snapcraft.Launcher'"} ("cannot obtain bus name 'io.snapcraft.Launcher'")
<mup> PR snapd#4596 opened: osutil: allow using many globs in EnsureDirState <Created by zyga> <https://github.com/snapcore/snapd/pull/4596>
<zyga> Chipaca: ^ perhaps for you, it's pretty short and I need it badly
 * Chipaca looks
<ikey> so, question
<ikey> are the /etc/apparmor.d files meant to include /var/lib/snapd/apparmor/profiles ?
<ikey> because it seems those guys will only be loaded when i start snapd
<ikey> but if i snap run something, those profiles don't exist yet
<ikey> i.e. AVC apparmor="DENIED" operation="change_onexec" info="label not found"
<zyga> ikey: I think that the thing that loads profiles on boot looks at /var/lib/snapd/apparmor/profiles
<ikey> yeah thats kinda the thing here
<zyga> ikey: we reload them in snapd if needed but it should happen during boot to let services start without starting snapd
<ikey> "the thing" is slow as ass
<ikey> and massively regresses boot time
<zyga> ikey: that's orthogonal, I'm explaining how it functions, not why it is slow
<ikey> and the only "solution" is private to the debuntu packaging world
<zyga> oh?
<zyga> what solution is that?
<ikey> your package hooks for apparmor
<zyga> maybe I'm missing the point somewhere
<ikey> and the boot load service
<ikey> the /var/lib/apparmor/profiles path isnt referenced in the /etc/apparmor.d/* files
<ikey> so they won't be compiled in with a boot time service
<ikey> until snapd is started and does the reload you mentioned
<ikey> but with socket activation, snapd.service itself wont be started
<zyga> it should be referenced by the arcane /etc/init.d/apparmor script
<ikey> and a snap run of some snap will fail
<ikey> i use systemd. :)
<zyga> /etc/apparmor.d is more like a /usr/lib/apparmor.d
<zyga> yes, we too
<ikey> /etc/init.d is a banned path in solus
<ikey> so i know we dont have it
<zyga> it's a shell script and runs with sysv compat generator AFAIK
<ikey> so are nasty shell scripts during boot
<ikey> lol
<zyga> and that's what makes it slow for you perhaps
<zyga> so
<ikey> im adding a workaround
<zyga> I think you want to write a small tool (that would go upstream)
<zyga> that 1) loads and 2) caches profiles
<ikey> by including the private apparmor profiles directory into our aot portion
<ikey> ya ive done that
<zyga> loading cached profile is very fast
<ikey> way ahead of ya
<zyga> cool,
<zyga> but please share that with jdstrand and upstream,
<ikey> https://github.com/solus-project/aa-lsm-hook
<zyga> that script has some reason for not being a systemd job sadly
<zyga> and it's probably some messy complexity
<zyga> maybe it's just legacy complexity that can die
<zyga> but maybe there's some genuine thing to care about and you'd just run into it all over again
<ikey> working out the kinks with this in solus atm
<zyga> jdstrand is off today (traveling) but next week we can sync on that
<ikey> so we have a -compile and a -load binary
<ikey> -compile is called during package operations
<ikey> and -load at boot
<ikey> which if it fails to load, will recompile
<ikey> to handle kernel abi changes and such
<ikey> which takes my whopping 1.3s regression to to 32ms
<ikey> in my VM over half the boot time /was/ spent in apparmor.service ^^
<ikey> but now im doing the AoT/cache approach and making sure it doesn't bust snapd :P
<zyga> yeah, it also doesn't help that that is a shell script and it wasn't a one liner
<zyga> look at how it gets invalidated
<zyga> one of the things that the old code cared for was apparmor base things gettingchanged
<zyga> so all the #include files
<zyga> this sucks IMO
<ikey> right
<zyga> and it could be nice to even ship _precompiled_ profiles and build-depend on the include files
<ikey> so this is why our AoT is called by usysconf during package changes
<zyga> but that's not how it's done in ubuntu
<ikey> only if /etc/apparmor.d changes
<zyga> yes
<ikey> and then the boot uses the cache
<zyga> and really /etc/apparmod.d is a messy zoo that should live in /usr/lib
<ikey> yeah
<zyga> and not in /etc for the vast majority of content
<zyga> it's just in dire need of a gardener
<ikey> /usr being shipped, /etc being local vendor/etc
<zyga> yeah, exactly
 * zyga wrote https://disqus.com/home/discussion/omgubuntu/it_just_got_a_lot_easier_to_install_skype_on_ubuntu/#comment-3738650041
<ikey> people still raging about getting the stuff they want? ..
<zyga> yeah, but I think that unless we put accurate comments and explanations people will run off with the wildest conspiracy theory they can come up with
<ikey> yeah true
<zyga> snaps are from SATAN or whatever
<ikey>              8ms aa-lsm-hook.service
<ikey> thats more like it
<zyga> wooot
<zyga> thank you
<zyga> I actually think that's something we could adopt in base18
<zyga> mvo: ^^
<zyga> we want empty /ec
<ikey> https://hastebin.com/mukeneheha.coffeescript
<zyga> _empty_ /etc
<ikey> all loaded properly
<zyga> oh
<zyga> minecraft!!!
<ikey> so for now we load /from/ etc path, *but*
 * zyga snap installs it
<ikey> we support optional paths
<zyga> man snaps are really a double-edged sword
<ikey> i mean my eventual thinking is we'd merge the hook into apparmor userspace after discussion
<ikey> zyga, productivity
<zyga> how do you stay focused when you can install cool software and use it :)
<ikey> xD
<zyga> yes, that sounds good to me
<zyga> soooooo... I have a new computer now
<ikey> we have some path magic here: https://github.com/solus-project/aa-lsm-hook/blob/master/src/lib/hook.c#L24
<ikey> oh?
<zyga> feeling very tempted to open it ^_^
<ikey> it was popeys snap not sure how far he got with it
<zyga> oh neat, proper compiled language
 * zyga hugs ikey for being this cool dude that writes in C
<ikey> :D
<ikey> we had to for the boot time regressions
<ikey> we just did the same with solus-hardware-config
<zyga> and in other news, I now have per-snap apparmor profiles for snap-update-ns if a given snap uses layouts
<ikey> oh very nice
<zyga> so ... layouts not only work but are safe and won't weaken snap-conifne
<zyga> man, I'm so exited about that one :)
<zyga> I'll break for some more tea and convert my hand-made layout snap to a spread test
<ikey> :D
<zyga> btw will layouts benefit solus in any immediate way?
<ikey> idk but i mean we can probably invent some use cases
<ikey> totally up for that
<zyga> layous, let you put, for instance $SNAP_DATA/stuff in /var/lib/whatever
<ikey> yeah
<zyga> or $SNAP/usr/share/foo in /usr/shre/foo
<ikey> seems good in terms of bolt-ons
<ikey> or hell even themes
<ikey> if they were content layouts
<zyga> mmm,
<zyga> so themes are a separate topic but they already benefit from this
<ikey> oh ok
<zyga> because as a prereuquisite we can now *spool* content interface
<zyga> so you can create $SNAP/plugin and connect any number of things there
<zyga> and they will show up as $SNAP/plugin/{foo,bar,froz}
<zyga> (even deconflict on name clash to foo, foo_2
<zyga> and the same idea is that we can now stick a theme snap up
<zyga> and connect it via a theme interface (or just one of the desktop interfaces)
<zyga> and use the right content tags to ship various variants and connect the right one
<zyga> (so you get all themes but the right ABIs)
<zyga> and one fat theme snap can cover common themes
<zyga> and other theme snaps can complement that freely
<zyga> all of that is possible, just not used yet
<zyga> and the ubuntu desktop team is looking at adopting it now
<zyga> the single fat theme snap is just a 1st step before snapd knows which theme you use and which ABI it needs for a particular snap and pulls that from the store automatically
<zyga> I'm so so so looking forward to that
<zyga> as it will unbreak theming in a major way
<ikey> true
<ikey> i think folks will be a lot happier when they land
<zyga> but first
<zyga> coffee
<zyga> I can slow down and plan what's needed for layouts to land on monday
<ikey> yeah i gotta run to town and get a new shirt for myself
<zyga> oh? wedding?
<mborzecki> zyga: what kind of rig do you have now?
<zyga> mborzecki: I have this x250 laptop
<ikey> zyga, nah just heading out to a mates place for pizza + beer
<pstolowski> mvo, 4579 looks great to me; and what's the plan re seccomp features?
<zyga> and I'm selling my hand-built PC wit amd x4 845 cpu
<zyga> with two r9's 280x
<zyga> ikey: man, I miss pizza
 * zyga had breakfast
<ikey> :D
<mborzecki>  13:17 	<zyga>	soooooo... I have a new computer now   <--- i mean this :)
<zyga> hahaha
<zyga> that's still in a box :) maybe it's a bag of bricks
 * Chipaca -> lunch
<Chipaca> zyga: maybe it's a mini pdp8
<jdstrand> zyga: I have 30 seconds before leaving for a plane, but I woke up thinking *maybe* it isn't so bad if snap-update-ns has wide write access. the idea is, snapd writes the fstab entries, snap-confine can't write them or modify/load apparmor policy, snap-confine calls snap-update-ns, snap-update-ns can't write fstab files or modify/load apparmor policy (ie, use explicit deny rules)
<zyga> jdstrand: hey
<jdstrand> zyga: but I would need to study the existing profile to convince myself this is ok
<zyga> jdstrand: I wrote the per-snap policy now
<jdstrand> heh
<zyga> jdstrand: it will be ready for review over weekend
<zyga> jdstrand: :)
<zyga> jdstrand: it's super sweet, I did the optimization we talked about
<jdstrand> you're too fast. I mean, I didn't even sleep that long!
<zyga> jdstrand: so that we have fewer profiles and it's less of an impact for non-layout snaps
<zyga> jdstrand: haha :)
<zyga> jdstrand: I'm super keen to see this fly :)
<jdstrand> ok
<jdstrand> well, I gotta run
<jdstrand> have a nice day!
 * jdstrand -> travel
<zyga> safe travels!
<jdstrand> thanks :)
<mup> PR snapd#4597 opened: snapstate: allow core config via $core <Created by mvo5> <https://github.com/snapcore/snapd/pull/4597>
<mup> PR snapd#4598 opened: packaging: create /var/lib/snapd/lib/{gl,gl32,vulkan} as part of packaging <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4598>
<mvo> mborzecki: \o/
 * kalikiana heading out for lunch, back in a bit
<pstolowski> niemeyer, can you take a look at #4584?
<mup> PR #4584: hooks/osutil: limit the number of data read from the hooks to avoid oom <Created by stolowski> <https://github.com/snapcore/snapd/pull/4584>
<niemeyer> pstolowski: Reading
<mup> PR snapd#4594 closed: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4594>
<mup> PR snapd#4591 closed: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4591>
<mup> PR snapd#4580 closed: tests: ensure disabled services are masked <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4580>
<zyga> mvo: https://github.com/snapcore/snapd/pull/4595 needs review for 2.31
<mup> PR #4595: snap: improve validation of snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4595>
<mup> PR snapd#4599 opened: many: send  new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4599>
<mvo> zyga: looking
 * pstolowski lunch
<zyga> small break to handle kids
<kalikiana> re
<zyga> thank you
<mup> PR snapd#4595 closed: snap: improve validation of snap layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4595>
<zyga> we'll probably do some tweaks but this should be very much like what we want to have in edge week
<niemeyer> pstolowski: ALright,
<niemeyer> pstolowski: I sent a review.. which actually suggests a slightly different route that does not involve killing the process
<niemeyer> pstolowski: I'm sorry for the late suggestion, but it seems worth it.. have a look at the rationale there and let me know what you think please
<zyga> wow
<zyga> http://lkml.iu.edu/hypermail/linux/kernel/1802.0/00454.html
<zyga> search for "snap"
<cachio__> mvo, hey
<cachio__> mvo, I see a bug in arm64 for the test prepare-image-uboot
<cachio__> mvo, after snap prepare-image ....
<cachio__> it downloads all the snapd
<cachio__> snaps
<cachio__> but kernel.img is not in $IMAGE/boot/uboot/pi2-kernel_*.snap
<cachio__> initrd.img it is there
<cachio__> not sure if there is any log where I could get more info
<cachio__> nothing in journalctl and dmesg
<pstolowski> niemeyer, thank you. yes I agree killing completely innocent hooks that happen to produce too much output is valid concern. I'll redo this
 * zyga breaks for some time to unpack
<mup> PR snapd#4600 opened: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<mvo> 4593 needs a second review
<mvo> (should be pretty trivial)
<mup> PR snapd#4592 closed: interfaces/desktop-legacy,unity7: support gtk2/gvfs gtk_show_uri() for 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4592>
<ogra_> cjwatson, do you happen to have any clue about grub-uboot ? (i have it working fine, chainloaded from a vendor u-boot and am at the grub prompt, but i cant find out how to actually access a disk (hd0/hd1 apparently do not work)
<cachio__> mvo, review done on 4593
<cjwatson> ogra_: I know that it exists but not a whole lot more.  You might be able to tab-complete disks if you start with a (
<cjwatson> ogra_: sounds like you either have a wrong prefix or haven't built in the necessary modules to get at /boot/grub
<ogra_> yeah, i cant see mmc or sdhc modules in the grub-core/ dir of my build
<ogra_> i'd expect something like that to be there
<ogra_> (the fun part is that i just loaded core.img from the MMC with u-boot ... so it is initialized and all)
 * cachio__ launch
 * cachio__ lunch
<ogra_> launching lunch :)
<cachio__> ogra_, :)
<mup> PR snapcraft#1912 opened: lxd: unset SNAP to work-around LXD deb thinking it's a snap <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1912>
<kalikiana> kyrofa: have a look at this one, please. This is a work-around for the broken container builds with LXD v2.21
<mborzecki> EOW for me, enjoy the weekend guys
<mborzecki> there's FOSDEM this weekend, be sure to watch the live streams
<niemeyer> pstolowski: Thank you, and again sorry for figuring this a bit too late..
<mup> PR snapd#4593 closed: advisor: ensure commands.db has mode 0644 and add test <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4593>
<pstolowski> niemeyer, no worries. i've visited a few dark corners by doing this, was a nice learning excercise anyway
<cjwatson> ogra_: it *looks* like grub-core/disk/uboot/ubootdisk.c is supposed to be built into the GRUB kernel and deal with disks enumerated by u-boot init
<cjwatson> ogra_: did tab-completion after ( say anything?
<ogra_> cjwatson, yeah, but it seems to need a devicetree, i suspect thats what i'm doing wrong here
<ogra_> nope
<cjwatson> ah, at this point I know nothing
<mvo> cachio__: what is the revno of the pi2-kernel snap that is downloaded? I wonder why this test is only failing on arm64
<mvo> cachio__: thanks for the review, I have a look
<cachio__> mvo, rev 49
<cachio__> mvo, I did unsquash and everything seems to be good
<cachio__> mvo, }kernel.img is there
<cachio__> -rw-------  1 sergio sergio 5722584 ene  7 10:07 kernel.img
<mvo> cachio__: so if you manually download and unsquash it is good but it fails on the arm64 test? or am I misunderstanding?
<Chipaca> pstolowski: I have this round robin thing here if you're interested btw
<pstolowski> Chipaca, ?
<cachio__> mvo, in a debug session I did > su -c "SNAPPY_USE_STAGING_STORE=$SNAPPY_USE_STAGING_STORE snap prepare-image --channel edge --extra-snaps snapweb $ROOT/model.assertion $ROOT" test
 * kalikiana going to wrap up shortly
<Chipaca> pstolowski: suddenly remembered you were working on making the limit writer a round robin thing?
<cachio__> and then I unsquash the downloaded kernel snap
<Chipaca> pstolowski: and that i had one
<Chipaca> pstolowski: https://gist.github.com/chipaca/d292f8f29110d5ab72bc675ca1c5d0e6 fwiw
<mvo> cachio__: so in the debug session you could not reproduce the failure, is that what you say?
<cachio__> mvo, yes
<mvo> cachio__: :(
<mvo> cachio__: thats mysterious
<cachio__> mvo, https://paste.ubuntu.com/26506616/
<cachio__> mvo, that's what I see after run the snap prepare-image command
<mvo> cachio__: hm, kernel.img is a symlink - I wonder if that is the problem
<mvo> cachio__: still - why only on arm64 :(
<mvo> cachio__: btw, do you have more test fixes that we should merge into 2.31?
<pstolowski> Chipaca, ah, that! thaank you. i haven't yet go deep into the details of what Gustavo suggested in the review comment (currently adressing some other PR's comments), but thanks, it be good for inspiration
<cachio__> mvo, no, just this is remaining
<mvo> cachio__: great to hear
<cachio__> the othe fixes were in the test tools that I have for the boards
<pstolowski> / grr my wireless keyboard is eating characters
<Chipaca> pstolowski: np! there are a couple of tweaks I'd do if it was something or production use, fwiw, but otherwise it worked
<Chipaca> s/or/for/
<cachio__> mvo, this is the snap content https://paste.ubuntu.com/26506641/
<pstolowski> Chipaca, ack
 * kalikiana going off into the weekend
<mvo> cachio__: of what rev number? I see kernel.img as a symlink in r49
<cachio__> mvo, the kernel snap is rev 49
<cachio__> mvo, pi2-kernel_49.snap
<pstolowski> eow o/
<smoser> hi.
<smoser> i walk through https://developer.ubuntu.com/core/get-started/kvm
<smoser> and i get http://paste.ubuntu.com/26506699/
<smoser> is that known? i basically can't get through the consoleconf
<mvo> cachio__: strange, when I unsquash -ls I see kernel.img as a symlink and in your output it is a real file
<smoser> so i think the issue above occurs if i attach a 'nocloud' config disk.
<smoser> probably because cloud-init enables itself and writes network config, that throws fits for console-conf.
<Chipaca> smoser: in what part of that walk does it say "attach a 'nocloud' config disk"?
<smoser> Chipaca: you're right, it does not.
<Chipaca> phew
<Chipaca> mvo: I'm EOWing, which means you should've EOWed already
<Chipaca> mvo: have a great weekend (starting now)
<Chipaca> :-)
 * Chipaca waves
<cachio__> mvo, could we add a new pr for rc3?
<cachio__> mvo: #4601
<mup> PR #4601: tests: update kill-timeout focused on making tests pass on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4601>
<mvo> cachio__: sure
<cachio__> mvo, it is really small
<mup> PR snapd#4601 opened: tests: update kill-timeout focused on making tests pass on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4601>
<mvo> cachio__: ta
<cachio__> mvo, just the prepate-image-uboot test missing
<cachio__> mvo, still chasing the problem
<mvo> cachio__: yeah, a mystery, sorry that I am not useful right now in solving this puzzle :(
<mvo> cachio__: I gtg, but I will read scrollback!
<cachio__> mvo, np, I0ll try to see which is the problem
<cachio__> enjoy your weekend
 * zyga-ubuntu moved his files onto the new machine
<kyrofa> zyga-ubuntu, hey, you got a sec?
<zyga-ubuntu> yes
<zyga-ubuntu> what's up?
<kyrofa> zyga-ubuntu, take a look at this: https://pastebin.ubuntu.com/26508980/
<kyrofa> zyga-ubuntu, note that the hook is present, and is executable
<zyga-ubuntu> cannot find
<zyga-ubuntu> hmm
<zyga-ubuntu> can you nsenter into the namespace
<zyga-ubuntu> and see if it's really there?
<kyrofa> zyga-ubuntu, it's not my machine I'm afraid, but I'll pass that on. Note that this snap actually works fine on my machine, same version of core/snapd
<zyga-ubuntu> is that iside a container?
<kyrofa> zyga-ubuntu, Tyriar is the one having this issue, would you mind repeating what you said above?
<zyga-ubuntu> kyrofa: I don't know what that may be caused by, if it says it cannot find it then it's probably not mounted
<zyga-ubuntu> the hook runs inside the namespace
<zyga-ubuntu> so it's probably just not there (probably the mount event didn't propagate inside)
<kyrofa> zyga-ubuntu, indeed, this is actually parallels
<kyrofa> Right Tyriar?
<Tyriar> Yeah parallels
<zyga-ubuntu> Tyriar: interesting
<Tyriar> there are other issues with parallels I've noticed (cannot launch the snap from inside the snap)
<zyga-ubuntu> Tyriar: what does "snap version" say?
<zyga-ubuntu> Tyriar: thats normal, it's not allowed
<zyga-ubuntu> parallels as in that virtualization software, right?
<Tyriar> It works normally though?
<zyga-ubuntu> no, it shouldn't
<zyga-ubuntu> though
<zyga-ubuntu> I wonder what parallels does
<Tyriar> By running inside the snap, I mean a pty is launched from the snap which launches another window
<Tyriar> Parallels is mac only VM software yeah
<Tyriar> snap version: snap    2.30 snapd   2.30 series  16 ubuntu  16.04 kernel  4.4.0-104-generic
<zyga-ubuntu> Tyriar: can you give me the output of "cat /proc/self/mountinfo" (tip: use pastebinit)
<zyga-ubuntu> Tyriar: in any case, can you please drop a topic on the forum, give some information about how to reproduce the problem
<zyga-ubuntu> I can try (no promises though)
<Tyriar> https://pastebin.com/iFEKBUyq
<zyga-ubuntu> this looks normal
<zyga-ubuntu> which snap failed?
<zyga-ubuntu> ah, my-snap
<zyga-ubuntu> actually
<zyga-ubuntu> maybe it's a bug :)
<zyga-ubuntu> Tyriar: can you please switch core to the beta channel
<zyga-ubuntu> there's a new release of snapd there
<zyga-ubuntu> can you see if that also has the same issue
<Tyriar> what do I run to switch the channel again?
<kyrofa> zyga-ubuntu, I used my-snap in the pastebin, but it's actually the one at the very bottom of Tyriar's paste
<zyga-ubuntu> code-insiders?
<kyrofa> Indeed
<zyga-ubuntu> so it's correctly shared:96OC
<kyrofa> zyga-ubuntu, note also that the one that failed probably won't be there as it's the post-refresh hooks that's dying, thus rolling it back
<zyga-ubuntu> it should be mounted inside the snap mount namespace
<zyga-ubuntu> kyrofa: ah, noted
<kyrofa> The ones you see there have no hooks
<zyga-ubuntu> Tyriar: so when it failed, you were refreshing a snap?
<zyga-ubuntu> were you refreshing from a store revision to a local revision?
<kyrofa> zyga-ubuntu, just installing --dangerous over the top.
<Tyriar> I was installing a local snap with --dangerous, over a store revision yes
<kyrofa> Ah, wonder if that has something to do with it
<kyrofa> I didn't try that
<Tyriar> kyrofa, it's a private snap on the store which I think you have access to
<zyga-ubuntu> kyrofa, Tyriar: this is something for pstolowski on monday
<zyga-ubuntu> it may be a bug where we think a hook exists
<zyga-ubuntu> but it doesn't in the right revision
<zyga-ubuntu> but that's just a theory, no idea what's wrong for real
<kyrofa> zyga-ubuntu, that sounds accurate given the symptoms
<Tyriar> the store revision definitely doesn't have a post-refresh hook, if that matters
<kyrofa> zyga-ubuntu, I'll try to install from the store and see if I can reproduce
<zyga-ubuntu> yeah, looks like a bug there
 * zyga-ubuntu looks at ubuntu in high-dpi and is amazed
<noise][> FYI, having some API slowness + elevated error rates on snap store
<noise][> investigating
<kyrofa> noise][, I was just about to ping you, thank you :)
<noise][> updated the status page but there seems to be a rendering delay there or something
<mup> PR snapcraft#1913 opened: Use pyelftools to parse ELF files rather than using readelf <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1913>
<marosg> hi, is something wong with snapcraft.io? snap info takes 40 seconds and snap refresh times out
<marosg> s/wong/wrong/
<Odd_Bloke> marosg: There is an issue with the snap store ATM; the team are working to address it.
<kyrofa> noise][, I can't refresh anything either, but status.snapcraft.io shows green for everything except search
<noise][> site24x7 status page won't reflect my outage notif :(
<noise][> anyway, working the problem
<mup> PR snapd#4602 opened: tests: use root path to /home/test/tmp to avoid lack of space issue <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4602>
<cachio__> mvo, please could you add the PR #4602 to the rc3 too? tx
<mup> PR #4602: tests: use root path to /home/test/tmp to avoid lack of space issue <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4602>
<zyga> are you guys still working on the release?
<cachio__> zyga, I just left the comment for mvo
<cachio__> I am almost done today
<cachio__> zyga, you should be too :)
<zyga> yeah, though I'm not working anymore, just exploring my book collection
<kyrofa> jdstrand, you around by any chance?
#snappy 2018-02-03
<mup> PR snapcraft#1914 opened: docker: add Dockerfiles for all risk levels <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1914>
<mup> PR snapcraft#1915 opened: snap: patch ctypes for the snap <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1915>
<bashfulrobot> Heads up guys, looked like the forums are down again with a 502 nginx error.
<mup> Bug #1747200 opened: console conf crashes on dragonboard <Snappy:New> <https://launchpad.net/bugs/1747200>
#snappy 2018-02-04
<SchuggerLeo> Hi, does anybody know how to install "spotify" in the latest lubuntu with snap ? snap seem to work, but it finds no package called spotify
<milp_wurst> hi, ive got a nano pi neo v2 running ubuntu core and it is missing the usbserial module - is there a way to install this? is there a way to "upgrade" an ubuntu core installation to a full ubuntu server?
<ogra_> milp_wurst, the module is definitely there on my ubuntu core install, what image did you use (did you roll it yourself ? )
 * ogra_ points to http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<milp_wurst> i see images there, does one contain usb serial support?
<milp_wurst> oh sorry didnt see your first message
<milp_wurst> hold on ill look
<milp_wurst> i went with "nanopi-neo_ubuntu-oled_4.x.y_YYYYMMDD.img.zip" since i have that oled display
<milp_wurst> i guess ill ahve to recompile the kernel
<milp_wurst> i dont get the reason for ubuntucore instead of something like raspian or a full ubuntu
<milp_wurst> is there a way to make a "proper ubuntu" out of it?
<milp_wurst> ogra_: which image are you using?
<milp_wurst> are those images bzImages i can just drop into the boot folder?
<milp_wurst> i wonder how long compiling the kernel is gonna take with the usb_serial options on and support for ftdi
<ogra_> no, these images are pure ubuntu-core images
<ogra_> (full disk ones ... install them like any other core image )
<ogra_> "nanopi-neo_ubuntu-oled_4.x.y_YYYYMMDD.img.zip" is definitely not an ubuntu-core image
<ogra_> istall instructions are at https://developer.ubuntu.com/core/get-started/installation-medias
<ogra_> (for initial setup you can follow the install instructions section at https://developer.ubuntu.com/core/get-started/orange-pi-zero )
<milp_wurst> it is based on ubuntu core and im afraid ill lose support for the oled display if i just use a stock ubuntu core image
<ogra_> milp_wurst, it is not based on ubuntu-core ... ubuntu core is a readonly IoT product that is only built around snap packages (no dpkg/apt support at all)
<ogra_> milp_wurst, you should ask friendlyarm why they claim this, whatever home-hacked images they provide there do not have any relation to ubuntucore
<ogra_> (or to ubuntu in general)
<ogra_> if their kernel they ship in these images does not support usbserial, you should try to get in touch with them that they fix this, proper ubuntu-core kernels have this module enabled by default (at Ã¶east for all supported images)
<milp_wurst> http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO#Get_Image_Files
<milp_wurst> thats where they claim it is
<milp_wurst> i checked their most recent version of that image and it seems to contain usb serial driver modules in /lib/modules - so ill install that now
<milp_wurst> im building a rs232-ethernet modem device out of this, ubuntu core wouldnt be the right thing for that purpose i guess
<ogra_> milp_wurst, well, ubuntu-core would be perfectly fine for this but you'd have t learn to package your apps as snap packages for that ...
<ogra_> secure and properly upgradeable IoT and enbedded are exactly the focus of ubuntu-core
<memphisto> hi. I'm using kubuntu 16.04 with no backports.Looking for workaround for snaps showing in kde, dolphin
<memphisto>  i know that in newer kde version there is a fix, but i'm sticking to LTS.
#snappy 2019-01-28
<mborzecki> morning
<mborzecki> 54 PRs, not bad at all
<zyga> Good morning
<mborzecki> zyga: hey
<zyga> https://www.irccloud.com/pastebin/MMF5SCYo/
<mborzecki> zyga: no snapd-lib?
<mborzecki> or some path component
<mborzecki> zyga: looks like glob wasn't expanded by the shell
<zyga> mborzecki: looks like teardown went south
<zyga> anyway, that's just random noise today
<mvo> hey zyga  and mborzecki
<zyga> mvo: hey :)
<mborzecki> mvo: hey
<zyga> mvo: ready to face the music?
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/6431
<mup> PR #6431: snapcraft.yaml: fix snap building in launchpad <Simple ð> <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6431>
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/6426 with a tiny comment tweak, I think it is ready now
<mup> PR snapd#6431 closed: snapcraft.yaml: fix snap building in launchpad <Simple ð> <â  Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6431>
<mup> PR #6426: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <https://github.com/snapcore/snapd/pull/6426>
<zyga> mvo: also good news, https://tracker.debian.org/pkg/snapd will migrate tomorrow
<mvo> zyga: thank you
<mup> PR snapd#6437 opened: snap/channel: improve channel parsing <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6437>
<zyga> mborzecki: school winter holidays started today
<zyga> mborzecki: two weeks with all the kids at home :)
<mborzecki> zyga: nice, it starts on 11.02 here, right before the sprint, i'll probably take the week before sprint off
<zyga> bring them to malta :)
<zyga> mvo: is the plan still to review PRs more than open new ones?
<mvo> zyga: yeah, I think thats wise
<mup> PR snapd#6428 closed: interfaces: add display-control interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6428>
<mup> PR snapd#6435 closed: interfaces: add display-control interface - 2.37 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6435>
<pstolowski> mornings
<zyga> hello pawel, welcome back
<mborzecki> pstolowski: hey
<mvo> hey pstolowski! welcome back
<mborzecki> hm not that many reviews that aren't waiting for the author to address the feedback they got
<mborzecki> i'll be looking into what's wrong with #6252 spread tests
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<mvo> mborzecki: this one is a good one to look at, thank you
<mvo> mborzecki: I think the issue is that we need to either do more mocking or use less mocking :) I mean, we might look into using some real xdg helpers (less mocking)
<mvo> looks like tests are unhappy right now in debian-9 (/me looks)
<mvo> hm, so stretch no longer has golang-1.10 (just 1.11)
 * mvo scratches head
<zyga> mvo: with integration of debian packaging we cannot assume to build for older releases
<zyga> mvo: realistically we should target testing and sid
<zyga> or really just sid perhaps
<zyga> as soon as we fix lintian warnings we may start using standards version that is from the future from the perspective of debian-9
<pedronis> pstolowski: hi, I did another pass on #6322 last week
<zyga> hey pedronis
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<zyga> mvo: shall we sync with pedronis?
<mvo> zyga: yeah, when he has time this morning we should have a quick HO
<mup> PR snapd#6438 opened: data/systemd: helper service to hold refreshes when waking up from suspend <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6438>
<pedronis> mborzecki: did you see my small comment on #6016 ?
<mup> PR #6016: snap/naming: move various name validation helpers to separate package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<pedronis> *comments
<mborzecki> pedronis: yes, pushing those soon
<mborzecki> pedronis: i've pushed a PR to improve channel validation
<mborzecki> pedronis: ah, i see you've already looked at it, thanks!
<pstolowski> pedronis: hi! yes i saw that, thanks. btw, not sure if i was super clear when we talked last week, but 6106 is ready imo
<mborzecki> mvo: zyga: is there a way to depend on golang-any 1.7+ and then use `go env` to discover things?
<zyga> presumably, yes
<zyga> mvo: is the problem to add the correct go things to path?
<pedronis> mborzecki: yes, reviewed that, but it's red
<mborzecki> pedronis: yeah, debian doesn't build atm, Dependency is not satisfiable: golang-any|golang-1.10
<pedronis> pstolowski: yes, you were clear,  just didn't get to it yet
<pstolowski> pedronis: ah, sure, ok
<mvo> mborzecki: I need to look, not sure there is anything that references golang-1.11 in stretch
<mvo> mborzecki: let me log into a debug system
<mborzecki> mvo: log from a job on master branch: https://api.travis-ci.org/v3/job/485270403/log.txt
<mvo> mborzecki: thanks! golang-any seems to be a confusing name, it seems to refer to gccgo ./
<mborzecki> w8, rly?
<mborzecki> mvo: isn't that a golang-go or gccgo-go dependning on platform support?
<mvo> mborzecki: aha, no
<mvo> mborzecki: sorry, its just confusing on debian-9 because golang-1.11 comes via backports
<mvo> mborzecki: so golang-any has no idea about its existance
<pedronis> zyga: mvo: I'm available to chat if needed
<mvo> mborzecki, zyga I'm looking into this right now
<zyga>   thank you
<mborzecki> mvo: need help?
<zyga> mborzecki: reading the suspend refresh postponing PR
<zyga> mborzecki: is there any way snapd could learn from systemd or from the system itself that the system was just resumed
<zyga> to do this internally?
 * zyga goes to make tea
<mborzecki> zyga: yes, afaik dbus is the only way: https://www.freedesktop.org/wiki/Software/systemd/inhibit/
<mvo> mborzecki: should be fine, up for review now
<mborzecki> zyga: a topic that we haven't looked into yet, is also inhibiting sleep during refresh
<mvo> mborzecki: might be overkill (the fix) though, alternatively we could simple do "apt install -y golang-1.11" and fix it again in ~1-2y when go changes
<mup> PR snapd#6439 opened: tests: workaround missing go dependencies in debian-9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6439>
<mborzecki> mvo: wow :P so cool you know about python apt bindings
<mvo> mborzecki: *cough* I do
<mborzecki> mvo: failed on shellcheck
<mvo> mborzecki: meh, silly me - let me check
<pedronis> mborzecki: zyga: I'm -1  on using a service to set refresh.hold from outside
<mup> PR snapd#6438 closed: data/systemd: helper service to hold refreshes when waking up from suspend <Created by bboozzoo> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6438>
<mborzecki> pedronis: should have added RFC there, i think we can discuss it during the sprint
<pedronis> mborzecki: it's ok, I appreciate having prototyped this, but we also don't need more open forever rfc PRs
<Chipaca> mvo: do you know if there's a reason private-files can't be used yet?
<mvo> Chipaca: that should work if 2.37 is installed
<Chipaca> mvo: store says no
<mvo> Chipaca: its very strict though, deny auto connect and connect
<mvo> Chipaca: manual review?
<mvo> Chipaca: or no in more ways?
<Chipaca> mvo: ah, maybe
<pedronis> Chipaca: you need a snap declaration, otherwise it will not even install (unless --dangerous)
<Chipaca> right, but I need it in the store to ask for that
<Chipaca> but you're right, it's up
<Chipaca> the error from snapcraft sounded too much like an outright rejection :-)
<Chipaca> pstolowski: welcome back!
<pstolowski> hey Chipaca!
<Chipaca> pstolowski: thank you for the review
<pstolowski> np
<mup> PR snapd#6414 closed: daemon: try to tidy up the icon stuff a little <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6414>
<pedronis> Chipaca: hi, should we have a HO about epochs last PR ?
<Chipaca> pedronis: I'm about to have a meet about coh*
<pedronis> Chipaca: ah, do you need me?
<Chipaca> pedronis: not necessarily, but you're welcome if you're curious
<zyga> Chipaca: coh?
<pedronis> zyga: cohorts and coherence
<Chipaca> pedronis: it's more for me to sync with sparkiegeek and us to get a shared idea of timelines than anything else
<zyga> ahh
<Chipaca> zyga: carbon-oxygen-hydrogen compounds
<mvo> Chipaca: hm, we talked recently about snap info foo.snap not returning the arch of the snap. what was the conclusion/workaround, do you remember?
<Chipaca> mvo: will be added once info is nicer
<mvo> Chipaca: ok, no worries, I need this too for something but its easy to workaround
<mborzecki> there's some snap instance name validation weirdness, it's happening super late for installing from store now, so you can actually attempt to install hello-world_123__a and it fails as late as setting up mounts
<mup> PR snapd#6440 opened: Fix typo in cmd_wait.go <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/6440>
<zyga> brb, need to pick up something
<Chipaca> pedronis, mvo: wrt personal-files, https://forum.snapcraft.io/t/request-for-automatic-alias-and-connection-for-icdiff/9703 (weekend was fun)
<Chipaca> don't tell sergio but that'll be my first snap to use snapcraft
<sergiusens> Chipaca: good for you to have joined the parade ð
<Chipaca> sergiusens: btw is there a way to build using 3.0 without bases?
<Chipaca> mvo: pedronis: OTOH, is it on purpose that core can't be used as an explicit base?
<sergiusens> no, and the latter about core, I requested that 6 months ago ð
<sergiusens> but `base: core` is illegal for snapd
<pedronis> Chipaca: yes, core is not a base
<Chipaca> sergiusens: pedronis: I guess #6418 makes it moot
<mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<sergiusens> Chipaca: not entirely, as now I need to go into snapcraft and workaround the fact that when someone says `base: core16`, to say that `core` satisfies that requirement.
<Chipaca> sergiusens: BTWÂ², snapcraft doesn't understand license yet?
<Chipaca> I thought that was Done
<sergiusens> it should
<mup> PR snapd#6441 opened: overlord/snapstate: validate instance names early <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6441>
<Chipaca> using 3.0.1, using a base, had to put it in passthrough
<sergiusens> there's even integration tests enabled for that
<sergiusens> hmm
<mborzecki> pedronis: you might be interested in 6441
<popey> niemeyer: Would you consider adding a robots.txt to snapdocs.labix.org? It's coming up in google search results, and I don't think that's useful.
<popey> currently looking for robots.txt on the site redirects to the home page.
<niemeyer> popey: I'm thinking of killing it actually
<niemeyer> popey: The new docs site is already out
<popey> Awesome, even better :D
 * Chipaca afk for a while
 * Chipaca bok
<Chipaca> bak?
<pstolowski> mvo: a question on 6404
<mvo> pstolowski: thanks, I check in a sec
<mborzecki> mvo: looks like we need to manipulate PATH in run-checks too
<mborzecki> mvo: that's regarding #6439
<mup> PR #6439: tests: workaround missing go dependencies in debian-9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6439>
<zyga> mborzecki:  can you try fixing that?
<mborzecki> zyga: yeah, in a couple of minutes, got some changes in snap connections i need to wrap up
<pedronis> Chipaca: yes, 6389 looked like my suggestion, it needs a 2nd review
<Chipaca> pedronis: ack tks
<ackk> hi, I was trying snap parallel installs on snaps and noticed some issues with hook not being found. is that something that's known?
<mborzecki> ackk: we've addressed an issue regarding hooks and parallel installs last week or so, let me see
<mborzecki> ackk: what is the problem that you see?
<ackk> mborzecki, snapd says it can't find the hook
<ackk> mborzecki, snap install --edge h2static_test
<ackk> mborzecki, ok that's just weird because it now worked
<ackk> tried it different times and didn't seem to
<pedronis> Chipaca: can you look again at #6333 to consider the last changes
<mup> PR #6333: daemon: introduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<Chipaca> pedronis: in a bit
<mborzecki> mvo: i'll look into #6439 if you don't mind
<mup> PR #6439: tests: workaround missing go dependencies in debian-9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6439>
<mup> PR snapcraft#2452 closed: Fix typo in comments <Created by Lin-Buo-Ren> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2452>
<mup> PR snapcraft#2450 closed: pluginhandler: handle removal of inconsistent files <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2450>
<mvo> mborzecki: sure
<mvo> mborzecki: its actually probably just a sed / on debina/control
<mvo> mborzecki: like "sed -i s/golang-1.10/$best_golang/ debian/control"
<mborzecki> mvo: yeah, and also need a correct symlink to /usr/bin/go
<mvo> mborzecki: indeed
<mvo> mborzecki: hopefully just ln -s /usr/lib/$best_golang/bni/go /usr/bin/go - should be all pretty uniform
<mborzecki> mvo: actually it's /usr/lib/go-<ver>/bin/go :P
<mborzecki> s/lang//
<mvo> mborzecki: meh, ok
<mvo> mborzecki: thanks for looking into it
<pedronis> Chipaca: there's a couple of nitpicks by mvo for 6411 that seems worth considering
<Son_Goku> mborzecki, so I've proposed this change to fedora-release: https://src.fedoraproject.org/rpms/fedora-release/pull-request/67
<Chipaca> yeah
<mborzecki> Son_Goku: looking
<zyga> Son_Goku: thank you, that's nice :)
<Son_Goku> the only thing is that I'm not sure if I should call the variant snappy, similar to Ubuntu Core
<Son_Goku> snap sounds... dumb
<Son_Goku> but snappy isn't that much better
<mborzecki> Son_Goku: nice
<mborzecki> Son_Goku: so the -snap variant would be included in fedora base then?
<Son_Goku> yes
<Son_Goku> this will also give us the key we need to make snapd aware of Fedora Snappy variant too
<zyga> Son_Goku: perhaps ask pedronis for naming opinions
<Son_Goku> because the VARIANT_ID will allow us to identify a bootable Fedora Snappy variant
<Son_Goku> pedronis, should the variant for the base snap os-release be "Snap" or "Snappy?
<zyga> Son_Goku: I think that's not required, snapd doesn't decide if a base snap is bootable based on  this AFAIK
<Son_Goku> *"Snappy"?
<zyga> but having a variant is good IMO
<zyga> Son_Goku: my preference for the VARIANT_ID is lowercase word
<mborzecki> Son_Goku: btw. does bluesilver have VARIANT_ID=flatpak?
<Son_Goku> zyga, there's a couple of os-release detection behaviors for handling normal systems and snappy-based systems
<zyga> VARIANT can be anything nice
<Son_Goku> mborzecki: silverblue is variant silverblue
<zyga> Son_Goku: yes but not for bootable vs non-bootable bases
<mborzecki> Son_Goku: ah ok
<Son_Goku> unless someone here has an interesting marketing name for a snappy variant of Fedora, that's all I got
<Son_Goku> zyga: VARIANT_ID is lowercase
<mborzecki> mvo: if 18.04 gets go-1.11 will we continue building with 1.10?
<Chipaca> Son_Goku: zyga: we distinguish current ubuntu core from the pre-snappy ubuntu core by calling the former "snappy ubuntu core"
<Chipaca> we might need to check about whether the use of the brand is ok?
<Chipaca> is it a brand?
 * Chipaca has no idea
<Son_Goku> I think the brand is Snapcraft?
<Son_Goku> which I've deliberately avoided using
<Chipaca> I'm sure somebody will have Opinions
 * Son_Goku groans
<Chipaca> should I ask?
<Son_Goku> as much as it pains me, we do need to know the answer to this
<Son_Goku> I need a name for the variant
<Chipaca> a'ight
<Son_Goku> I think I'd prefer to use "snappy" rather than "snap", but I dunno
<mborzecki> zyga: standup?
<zyga> joining
<cwayne> How do they not go with fed-core-a
 * cwayne will see myself out
<zyga> jamesh: hell
<zyga> hello :)
<zyga> sorry, typo
<mup> Issue core18#56 closed: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
<mup> Issue core18#86 closed: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
<mup> Issue core18#89 closed: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98, core18#113
<mup> Issue core18#56 opened: Sensible version number <Created by mvo5> <https://github.com/snapcore/core18/issue/56>
<mup> Issue core18#86 opened: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
<mup> Issue core18#89 opened: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98, core18#113
<popey> are layouts still behind an experimental feature flag?
<popey> (yes, it seems, as snap install refuses to install my snap which uses them)
<ogra> did you try with 2.37 ? iirc zyga said it was a 2.37 feature
<zyga> popey: no
<zyga> popey: they are available now
<zyga> but there are weird conditions on snapcraft side
<zyga> you must use bases
<Chipaca> also, maybe you explicitly turned them off?
<Chipaca> what does 'snap get system experimental' say
<Chipaca> popey: ^
<popey> ah, i wasn't using bases
<popey> error: snap "core" has no "experimental" configuration option
<sergiusens> zyga: popey bases should not be required on snapcraft for a snap to work during runtime, passthrough will just allow it into `snap.yaml` and let by gones be by gones
<mvo> sergiusens: hey, the autopkgtest results for 2.37 have some failures in the  integration test for plainbox, I will give you a pastebin soon. do you know anything about those?
<sergiusens> mvo: autopkgtests using the deb I suspect, something happened along the release line for plainbox that broke the test, we have not SRUed since, so should be safe to ignore, except, maybe you want to consult with cwayne just in case.
<mvo> sergiusens: https://paste.ubuntu.com/p/GGm3mqvGgY/ (cc cwayne )
<mvo> cwayne: is the above plainbox/checkbox failure a reason for concern? just ensureing that the 2.37 release we want to push out soon (later tonight or tomorrow morning) can also be pushed to -updates
<cwayne>  kissiel ^
<zyga> FYI: core snap with snapd 2.37 has been promoted to stable just now
<popey> Time to update the wikipedia page then! :D https://en.wikipedia.org/wiki/Snappy_(package_manager)
<zyga> let me do that
<popey> huh
<popey> someone broke the version part and refers to snapcraft only and not snapd
<zyga> hmm
<zyga> 3.0.1?
<sil2100> mvo, zyga, pedronis: hey! Do we have an official model assertion in the store for pi3 arm64? Would be nice to have one if we don't
<zyga> sil2100: I don't know, would love one if we did
<sil2100> The snap is in the store since a while (with a new one in the review queue)
<popey> yeah, they mistakenly changed the snapd to snapcraft versaion
<sil2100> mvo, zyga, pedronis: if we could get the assertion in, I could enable pi3 arm64 core18 as an official image we build and get that out for the .2 point release
<zyga> ah
<zyga> there's a confusion between snapd and snapcraft there :(
<popey> whole page needs a rewrite
<popey> I see someone re-added the critisism from the peek developer back in after it was removed
<pedronis> sil2100: we don't, we need to go through the process the get one signed
<pedronis> sil2100: that's something foundation drives
<pedronis> now
<pedronis> I think
 * mvo afk
<sil2100> I could drive it if someone could point me to how! Didn't do that before, can you link me some docs?
<pedronis> or maybe mvo did it, but I don't think it should be mvo
<sil2100> Since I think none of the current core18 assertions have been done by Foundations
<pedronis> sil2100: they weren't but should I think
<pedronis> like you do fro cloud images
<pedronis> they are connected to the images
<pedronis> sil2100: let me forward you one of the relevant RTs
<sil2100> pedronis: thank you!
<sil2100> :)
<pedronis> sil2100: you also need a name,   ubuntu-core-18-pi3  is the armhf ?
<pedronis> how do you plan to call the arm64 ?
<sil2100> I need to think about it still, not sure who invented the previous naming, I'd have to look at the other standards - first thing that comes into my mind is simply ubuntu-core-18-pi3-arm64, just like we had pc-amd64 and pc-i386 for 16
<sil2100> (now we just have -i386 and -amd64 but yeah)
<pedronis> sil2100: forwarded
<sil2100> pedronis: thanks again o/
<zyga> sil2100: wrt docs, you should be in sync with degville
<xnox> is my lxd busted, or my snapd busted?
<xnox> $ lxc list
<xnox> cannot read mount namespace identifier of pid 1: Permission denied
<popey> xnox: what if you "snap disable lxd && snap enable lxd"?
<ondra> xnox in other words, have you tried to switch it off and back on? :D
<xnox> popey, https://paste.ubuntu.com/p/N5yvH9CDyr/
<xnox> ondra, still bad https://paste.ubuntu.com/p/N5yvH9CDyr/
<xnox> but is it like lxd bad or snapd bad? =) is there anything else i can try to see if /all/ of snaps are broken, or just this one....
<ondra> xnox I was more laughing we are at that stage already when we try to remedy things by restarting them :)
<xnox> $ /snap/bin/gnome-calculator
<xnox> cannot read mount namespace identifier of pid 1: Permission denied
<xnox> ok, i claim snapd is busted for me.
<xnox> of all the things, gnome-calculator should work.
<ondra> sergiusens here is bug we talked last week https://bugs.launchpad.net/snapcraft/+bug/1813634
<mup> Bug #1813634: not reliable way to detect target architecture <Snapcraft:New> <https://launchpad.net/bugs/1813634>
<ondra> sergiusens seems like SNAPCRAFT_ARCH_TRIPLET is also busted when cross compiling using build-on: run-on definition
<xnox> Odd_Bloke, popey - sudo apt install --reinstall snapd => helped!
<sergiusens> ondra: could you create a bug for that last one too?
<ondra> sergiusens and new question I have, is maven supporting core18? I have change base snap in my snapcraft.yaml and my build is now failing
<sergiusens> ondra: yes, look at the 3.0 release notes
<sergiusens> ondra: https://github.com/snapcore/snapcraft/releases/tag/3.0
<ondra> sergiusens I added both (SNAPCRAFT_ARCH_TRIPLET and project.target_arch) to same bug, it seems related
<ondra> sergiusens unless you tell me to split it
<sergiusens> ok
<ondra> sergiusens with snapcraft 3.0.1 I'm getting maven.py", line 263, in _create_symlinks IndexError: list index out of range
<ondra> sergiusens and only thing I changed was base snap
<sergiusens> cross compilation are low priority bugs, btw
<sergiusens> ondra: please log a bug
<sergiusens> or submit to sentry
<ondra> sergiusens I did already uploaded traceback
<sergiusens> ok
<ondra> sergiusens same happens with edge and candidate
<ondra> sergiusens BTW, this line is funny "if self.project.info.base not in ("core18", "core19"):"
<sergiusens> hmm, that is a bug
<ondra> sergiusens I know core18 made it out in 2019, but did not know we actually have core19 now :D
<sergiusens> should be core16... not tests in place as core16 did not really exist then
<ondra> sergiusens same in ant, maven gradle :)
<sergiusens> ondra: I will need your snapcraft.yaml for the maven issue
<ondra> sergiusens https://bugs.launchpad.net/snapcraft/+bug/1813636
<mup> Bug #1813636: ant maven and gradle plugins referene mysterious core19 <Snapcraft:New> <https://launchpad.net/bugs/1813636>
<ondra> sergiusens OK let me share it
<ondra> sergiusens I will add it to bug report
<ondra> sergiusens https://bugs.launchpad.net/snapcraft/+bug/1813637
<mup> Bug #1813637: maven plugin crashes with base core18 <Snapcraft:New> <https://launchpad.net/bugs/1813637>
<ondra> sergiusens I will clean whole snapcraft and push it to git
<Odd_Bloke> xnox: Glad to hear it.
<sergiusens> ondra: try setting `maven-openjdk-version: "11"` for the part
<diddledan> I think the code should be slightly smarter by checking that there's at least one result from glob() before plucking the first element
<diddledan> the error is here: https://www.irccloud.com/pastebin/7vs1guXj/
<mup> PR snapcraft#2453 opened: ant, maven and gradle plugins: use correct defaults for jre <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2453>
<sergiusens> ondra: ^
<sergiusens> diddledan: it is a problem in itself that we failed to find what we wanted in our controlled environment though, that has been addressed ^
<diddledan> aha
<mup> PR snapd#6439 closed: tests: workaround missing go dependencies in debian-9 <â  Critical> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6439>
<mvo> cwayne, kissiel let sync about https://paste.ubuntu.com/p/GGm3mqvGgY/ in my tomorrow, my feeling is it should be fine but I feel better if one of you could double check :)
<kissiel> mvo: ack
<mvo> kissiel: thanks - so I take it you also need to investigate this first, right?
<mvo> kissiel: I gtg, lets sync tomorrow
 * mvo waves
<ondra> sergiusens I will try maven-openjdk-version: "11"
<ondra> sergiusens also openjdk-11 does not have jre subdir when I was checking code originally, if that will have impact on that code
<FrogCast> hey your documentation is not working here: https://tutorials.ubuntu.com/tutorial/basic-snap-usage#2
<FrogCast>  snapd find hello
<FrogCast> zsh: command not found: snapd
<FrogCast> it should be corrected to "snap"
<ondra> sergiusens adding maven-openjdk-version: "11" did not help
<mup> PR snapd#6411 closed: cmd/snap: wrap "summary" better <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6411>
<cjwatson> FrogCast: I don't see "snapd find hello" on that page - only "snap find hello".
<cjwatson> (And that page hasn't been touched in the git repository that hosts it for over a year)
<FrogCast> o_O
<FrogCast> I thought I copied and pasted
<FrogCast> cjwatson: guess my mistake. Sorry for that
<cjwatson> No problem
<cjwatson> I was all set to propose a quick PR to fix it ;-)
#snappy 2019-01-29
<mvo> kissiel: hey, good morning! ready when you are to talk about this autopkgtest failure, probably just a glitch but wanted to double check with you :)
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: ah, i see you're already pushing master merge to each pr
<mvo> mborzecki: well, some :)
<mvo> mborzecki: but yeah, we have some easy fixes
<mvo> mborzecki: I still need to cherry pick this for 2.37
<mborzecki> mvo: well, no we're going to break google again :)
<mvo> mborzecki: haaha - that was a funny error
<mvo> I can see the headlines: "search engine gigant down because snapd runs too many testsâ¦"
<mup> PR snapd#6442 opened:  tests: workaround missing go dependencies in debian-9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6442>
<mup> PR snapd#6400 closed: overlord/snapstate: use an ad-hoc error when no results <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6400>
<mup> PR snapd#6389 closed: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6389>
<morphis> mvo, zyga: any idea about https://forum.snapcraft.io/t/snapd-2-37-breaks-existing-snap-installation/9717 ?
<mvo> morphis: thanks. we are looking at this now
<morphis> mvo: thanks, if you need any live debugging let me know
<Chipaca> morning peeps
<Chipaca> mvo: zyga: pedronis: 6443 is something I'd like in 2.37 if it can sneak in
<mup> PR snapd#6443 opened: daemon, polkit: pid_t is signed <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6443>
<mvo> Chipaca: sure thing, it looks like we need a .1 soon because of a regression that morphis  just reported
<mvo> Chipaca: so lets try to move things quickly
 * Chipaca shakes fist at morphis 
 * Chipaca hugs morphis tho
<morphis> Chipaca: :-)
<mvo> mborzecki: any idea what might have changed in snap-confine that gives the error that morphis reported above?
<mborzecki> mvo: no, looking at it
<mvo> mborzecki: ta, I was just looking at the diff (lots of churn :/ but nothing so far that looks obvious
<morphis> mborzecki: I still have the 2.37 core snap installed, if you want me anything to try let me know
<zyga> Goood morning
<mvo> mborzecki: thanks, please consider this priority as it breaks users, we will push hard for a fix
<morphis> otherwise I am going to revert core
<mvo> zyga: hey, good morning
<mvo> zyga: bad news, morphis found a regression in 2.37
<zyga> I think it is not a regression
<zyga> Let me wake up and get to my keyboard
<mvo> morphis: also, could you please "snap refresh --candidate core" on all your boxes? that would be awesome because it helps us to find these issues slightly earlier (and candidate is as good as stable in 99,9% of the cases)
<mvo> zyga: thank you! keen to learn more :)
<zyga> Usage of home outside of /home always required local configuration changes
<morphis> mvo: our dev boxes use candidate already but not our CI ones
<morphis> zyga: these are classic snaps and things were working well for < 2.37
<mborzecki> zyga: can HOME/HOMEDIRS be set/extended manually?
 * Chipaca â school run
<mvo> zyga: do you know what code change created this denial?
<mborzecki> mvo: afaict it's snap-confine, though it seems to have the right rules to allow creating directories inside @{HOME}
<pstolowski> mornings
<mborzecki> morphis: did you need to tweak /etc/apparmor.d/tunables/home.d for jenkins before?
<mvo> mborzecki: iirc HOME really just means /home :/
<mvo> mborzecki: I wonder what change in s-c caused this, I mean, if this used to work something most have changed
<mborzecki> mvo: morphis mentioned that he's using /var/lib/jenkins as $HOME for jenkins
<mvo> mborzecki: yeah, what I mean is iirc apparmor tools are not very smart about @{HOME} when it is outside of /home but I may be wrong here
<mvo> Chipaca: your PR fails in the unit tests, could you pleae check and force-push (force-push so that we can still easily cherry-pick into 2.37)
<morphis> mborzecki: no, I didn't
<morphis> mborzecki, mvo, zyga: the problem appears with classic snaps (go, snapcraft) so theoretically they should be allowed to write to $HOME regardless where it is
<jamesh> morphis: the error is from snap-confine: it'll have the same policy no matter what snap it is running for
<mvo> morphis: its trivial to reproduce feel free to revert your snap
<mborzecki> mvo: wonder if adding /var/lib/jenkins/ to /etc/apparmor.d/tunables/home would fix it
<mvo> morphis: hm, this is strange - with the previous stable core (2.36.3) I get the same error - what was your previous version
<mvo> mborzecki: I'm pretty sure it would
<mvo> mborzecki: the interessting question is why is it breaking for morphis  now
<mvo> mborzecki: but wasn't before
<mvo> mborzecki: and an we fix it for him somehow :)
<zyga> re
<zyga> mvo: so:
<mvo> (I mean, not just for him for everyone who might be affected)
<zyga> mvo: the change is a result of removing quirks code
<mborzecki> oh
<morphis> mvo: https://pastebin.canonical.com/p/Rs8TmRYGJS/
<mborzecki> zyga: tell us more :P
<zyga> mvo: this is not a regression in my eyes for the following reason
<zyga> mvo: home directories outside of /home require local configuration to work
<zyga> mvo: they may have worked partially before
<zyga> mvo: but we never tested or supported that
<zyga> mvo: it may have been that some subset of snaps operated okey
<zyga> mvo: but it's unclear if all interfaces were supported or if not all, why not
<zyga> mvo: my advice is as follows:
<zyga> mvo: for the people affected the same advice present on the forum stands
<zyga> mvo: edit local apparmor configuration to indicate HOMES contains /var/lib/jenkins
<zyga> mvo: for 2.38 we can look at properly supporting thta
<zyga> mvo: including looking across the stack at assumptions, writing tests, etc
<zyga> mvo: so that's that
<zyga> mvo: in my eyes this is not a regression, it is a change but not all changes are regressions
<pedronis> zyga: we don't have a plan to make that work for 2.38 tough, unclear how much work it is even
<zyga> mvo: it was an unsupported feature  before
<mvo> zyga: right, people can workaround this issue. I would still like to understand if there is anything we can do and how the quirks changed things. even if its not technically a regression if it breaks existing installs thats not good (tm)
<zyga> mvo: the reason is very simple, to allow quirks in /var/lib/lxd snap-confine had wide permissions to /var/lib
<mvo> zyga: aha, that makes sense
 * mvo scratches head
<mborzecki> right, so /var/lib/jenkins would fit in there nicely
<mvo> yeah, now it all makes sense
 * zyga goes to make coffee
<zyga> sorry, stayed up late last night
<mvo> I still feel very uneasy about this
 * mvo scratches head harder
<pedronis> mvo: it's a bit unclear we can fix it easily for 2.38 tough, I wouldn't count on it
<mvo> pedronis: yeah, I'm fine with that, I am not looking for a general fix
<mvo> pedronis: just wondering if we can do anything about this particular case without things being horrible
<zyga> we could restore the permission, write a a few tests, add  test-var user with home in /var/lib/test, run some selection of tests that run as an user there
<pedronis> mvo: well, if we put back the open rule is a general fix but it means living with it forever
<pedronis> do we want that
<pedronis> sounds a jdstrand discussion
<zyga> pedronis: I agree
<zyga> the bad aspect of $HOME is that it can in theory point anywhere
<zyga> I think supporting /var/lib/jenkins explicitly is sane
<zyga> but /var/lib/snapd is not :)
<mvo> pedronis: yeah, that is the question I want to discuss. its fine if we say "no" it just want to make sure we explored options
<zyga> so there's that balance
<mvo> zyga: indeed
 * mvo scratches head more 
<zyga> sorry for beinig late, I hope the explanation makes some sense
<mvo> zyga: yeah, the key was the apparmor /var/lib quirks thing, that was the missing piece for me
<morphis> zyga: so what is the workaround you mentioned for this?
<zyga> morphis: let me pull up the forum post
<zyga> morphis: add one line to the proper config fle
<zyga> file
<mborzecki> zyga: i've edited apparmor tunables locall, but creating /var/lib/jenkins/snap/hello-world/27 fails, isn't /var/lib/ ro in the mount ns?
<zyga> ahhh
<zyga> interestng
<zyga> interesting
<zyga> so
<zyga> this is deeper than thata
 * zyga needs to wake up first
<mvo> morphis: thanks for the pastebin above, what does "snap list --all core" say?
<mborzecki> zyga: yeah, /var/lib is still from the core snap, we mount over /var/lib/snapd and quirks did a bind mount over /var/lib from what i can see
<mvo> oh, interessting
<zyga> the quirks code added /var/lib/lxd
<zyga> but at the same time made /var/lib writable
<morphis> mvo: https://pastebin.canonical.com/p/6b2J4rMFdD/
<mborzecki> zyga: could we have snapd set up the snap mount profile accordingly when we find well-known home dirs in /var/lib?
<mvo> Chipaca: nevermind, I pushed the (trivial) update
<zyga> yes but it would not work for /var/lbi
<mvo> morphis: thank you
<zyga> the quirks code was special
<zyga> it knew how to move /var/lib/snapd aside
<zyga> and move it back
<zyga> it also ran in a context where that is possible
<zyga> regular mount namespace updates cannot do that
<zyga> first of all, they have no logic for evading "shadowing" using mount --move
<zyga> and second of all, they have no scratch space outside of the filesystem
<zyga> the old quirk code ran before we did the pivot
<zyga> I have two quick ideas:
<zyga> 1) explicit support for jenkins
<zyga> add /var/lib/jenkinks to the core snaap
<zyga> make appropriate changes to snapd / snap-confine to match
<zyga> 2) add home rewriting
<zyga> for home outside of /home we synthesize a home directory and bind mount the original location to /var/lib/snapd/homes/$LOGNAME
<zyga> the 2nd idea seems better
<zyga> it would mean we can essentially have any home directory on the outside
<mborzecki> zyga: another thing, the case reported by morphis was for classic snaps, so we don't need to do anything about mount there (yet)
<zyga> mborzecki: apparently snap-confine still insisted on making a directory for the classic snap
<mborzecki> zyga: yeah, very much so
 * zyga drinks coffee 
<morphis> zyga, mborzecki, mvo: if there is nothing else I can do right now, I will revert back to the old core snap to get our CI back working
<mborzecki> Chipaca: do you want to take a look at the changes in #6333, some patches were pushed since you approved it
<mup> PR #6333: daemon: introduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<pstolowski> mborzecki: hey, would you take a look at another hotplug PR? https://github.com/snapcore/snapd/pull/6106
<mup> PR #6106: overlord/ifacestate: handler for hotplug-update-slot tasks <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6106>
<mborzecki> pstolowski: sure
<pstolowski> ty
<mvo> zyga: hm, how hard would home rewriting be?
<Chipaca> mborzecki: will do
<Chipaca> mvo: thanks
<pedronis> mborzecki: does 6016 need a master merge ?
<mborzecki> Chipaca: thanks
<zyga> mvo: snap-confine would bind mount home from wherver it was to a new location such as /var/lib/snapd/homes
<mborzecki> pedronis: heh, yes, pushed it to some other prs but not that one
<zyga> mvo: snapd would cooperate, telling snap-confine the home for each username
<zyga> mvo: there are some complications there though
<mvo> zyga: that sounds not too complicated
<mvo> zyga: oh?
<zyga> for instance, it cannot be done by snap-update-ns
<zyga> so snap-confine would need to do it
<zyga> so it would have to have the permission to do it
<zyga> this is complicated because again, it is open ended
<zyga> but we could begin with a simple constraint
<zyga> $HOME is either /home/* or /var/lib/jenkins
<zyga> that would solve it for "now"
<jamesh> zyga: it looks like it is sc_nonfatal_mkpath needing read access to all parent directories of the home dir as it does its mkdirat/openat chain
<zyga> indeed
<zyga> mvo: in the end the $HOME variable (alongside things that use it, like $SNAP_USER_DATA) would use the rewritten location
<zyga> mvo: for lesses impact we could only do this if $HOME is not somewhere in /home/
<mvo> zyga: the later sounds more compelling
<jamesh> if there was a version that assumed the home directory existed as a starting point, the AppArmor @{HOME} tweakable would be enough
<pedronis> it's just me, or the forum is flaky today
<zyga> jamesh: here the problem is that home for jenkins is not representable in the mount namespace at all
<jamesh> zyga: once that's solved, presumably it's still going to hit the denial for opening /var though
<zyga> jamesh: at that time we would make a fixed change to the apparamor profile to allow writes to /var/lib/snapd/homes
<Chipaca> mborzecki: what was the conclusion about  --disconnected?
<mborzecki> Chipaca: i don't think there was any
<Chipaca> pedronis: yo
<pedronis> Chipaca: yes
<Chipaca> pedronis: snap connections --disconnected?
<pedronis> yes?
<Chipaca> pedronis: me and one other person thought it might be a good idea, wdyt?
<pedronis> Chipaca: used where?
<pedronis> with a snap, without a snap?
<pedronis> anyway I cannot reach the forum today, it gives me network errors half the time
<Chipaca> pedronis: seems to work here
<popey> fine here too. take your foot off the cable
<mborzecki> pedronis: https://paste.ubuntu.com/p/f3HGxwDcwk/ the forum message, i have it working with and without a snap
<pedronis> mborzecki: the original suggestion was to show everything if a snap is given
<pedronis> Chipaca: I'm not super happy with the need to of headers or footers to explain what has been left out
<mborzecki> pedronis: ok, so you'd opt for the original suggestion, show both conencted & disconnected when a snap is given, show only connected when no snap is given?
<pedronis> yes
<pedronis> we still have all for the 2nd case, no?
<pedronis> or is that yet something else
<mborzecki> pedronis: you mean --all?
<pedronis> yes
<mborzecki> pedronis: i'm assuming it's in (seems uncontroversial anyway)
<mup> PR snapd#6333 closed: daemon: introduce /v2/connections snapd API endpoint <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<zyga> mvo: one more observation, while morphis may revert now, once 2.37.1 is out, he will be back in hot water
<pedronis> zyga: yes, reverting doesn't solve anything long term for him
<pedronis> mborzecki: the next bit is 6387? does it need a merge and tweaks ?
<mborzecki> pedronis: yup, pushing it now
<mborzecki> spread tests should be green now
<Chipaca> zyga: can i have a second review of 6443? it's green an' all
<zyga> Chipaca: certainly sir, looking
<Chipaca> Son_Goku: ping
<zyga> Chipaca: ah, user ids are tricky
<zyga> Chipaca: thank you for the patch!
<Chipaca> ikr
<morphis> zyga: is there already a date for 2.37.1?
<mvo> 6443 needs a second review
<Chipaca> mvo: zyga is on it
<mvo> ta
<zyga> morphis: there are some interface patches from jamie lined up
<morphis> zyga: and btw. I didn't picked /var/lib/jenkins as HOME for jenkins, it does that by default
<Chipaca> mvo: merged
<zyga> morphis: right, I know
<mup> PR snapd#6443 closed: daemon, polkit: pid_t is signed <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6443>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6442#pullrequestreview-197449157
<mup> PR #6442:  tests: workaround missing go dependencies in debian-9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6442>
<zyga> mvo: let's land it :)
<pedronis> can somebody merge master into 6440 ?
<mvo> zyga: will land in a wee bit
<zyga> mmm
<mvo> zyga: debina-9 is also merged now
<mup> PR snapd#6442 closed:  tests: workaround missing go dependencies in debian-9 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6442>
<mvo> having 6413 would be good, but this needs a second review
<mvo> but I guess its fine, we can use salsa
<pedronis> mvo: zyga: see #webops internally
<mvo> zyga: looks like more people are affected, can we revert the quirks code?
<zyga> I see no other way
<mvo> zyga: iirc that was 6123
<zyga> but please let me spend a moment
<zyga> I will write a quick test
<zyga> perhaps we don't need all of quirks
<zyga> I wonder why nobody tested candidate :/
<zyga> morphis: did you file a bug for this?
<mvo> zyga: you write a test and I prepare the revert
<zyga> mvo: no wait
<zyga> mvo: I don't think we want the full blown revert
<zyga> mvo: it's more complex because of other changes there
<zyga> mvo: please give me two hours
<morphis> zyga: no, just a forum topic
<zyga> morphis: can you file a quick one, just so that we have a bug number
<mvo> morphis: that should be fine
<zyga> mvo: or rather, give me 15 minutes for quick assesment
<mvo> morphis, zyga I can write it if we need it
<mvo> zyga: ok
<mup> PR snapd#6437 closed: snap/channel: improve channel parsing <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6437>
<mvo> zyga: I think its fine to revert and least risky but if you justneed 15min thats fine :)
<zyga> mvo: revert won't apply cleanly anymore
<zyga> that's what I mean by more work
<mvo> zyga: aha, ok
<mvo> zyga: conflicts are trivial
<mup> PR snapd#6444 opened: Revert "cmd/snap-confine,snap-update-ns: discard quirks" <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6444>
<mvo> zyga: ocd or something but I let you investigate and we can talk in a wee bit
<zyga> k
<zyga> thanks
<zyga> we can look at tests
<mvo> zyga: yeah, given the urgency I want this as a plan B, feel free to poke and look for better solutions
<zyga> k
<zyga> make sense
<mvo> zyga:  having a proper regression test would be good too
<mup> PR snapd#6445 opened: [RFC] snap-confine: revert "cmd/snap-confine,snap-update-ns: discard quirks" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6445>
<kissiel> mvo: hey! I finally managed to reproduce that crash; working on a fix
<zyga> mvo: so
<zyga> https://www.irccloud.com/pastebin/tx6qPpbI/
<zyga> mvo: this coupled with mkdir on /var/lib/jenkins in core / core18 fixes the issue without bringing back quirks
<zyga> mvo: can we have a call about this?
<pedronis> zyga: a call about what?
<zyga> about the approach to take
<zyga> I would really prefer not to bring back all of quirks
<pedronis> zyga: a mkdir in core / core18 ?  you mean we need to add that dir to the snaps?
<zyga> yes
<pedronis> mmh
<mvo> kissiel: no worries, is it something on our side?
<kissiel> mvo: leaning towards that, yes
<mvo> kissiel: do you have more details? if it is something on our side we would like to fix it :)
<kissiel> mvo: damn, sorry, misunderstood, more on our side :)
<kissiel> i mean cert's
<mvo> kissiel: haha, no worries
<kissiel> so stay tuned
<mvo> kissiel: thank you
<mvo> zyga, pedronis the small size of this is compelling - the fact that we need to add the dir not so much :/
<zyga> mvo: adding the directory is cheap, adding that code restores cost for each snap startup
<mvo> zyga: yeah, I can see that
<mvo> zyga, pedronis we could add the dir until we have better !/home support?
<pedronis> what is that dir visible to?
<zyga> we need to roll out new core anyway, this would mean the change is smaller
<zyga> pedronis: in 2.36 quirks made the full real host /var/lib visible
<zyga> pedronis: in 2.37 only the /var/lib from base snap is visible
<zyga> pedronis: apparmor prevents access as usual though this is fixed by local configuration of HOMEDIRS
<pedronis> zyga: do we do something special about extrausers?
<zyga> no
<mborzecki> zyga: imo HOMEDIRS is not enough, we open each intermediate path and need r there
<zyga> this is only affecting classic
<zyga> and the patch I pasted only configures this for classic
<zyga> mborzecki: I know, that was not what I meant
<pedronis> zyga: we have a couple of interfaces that gives access to var/lib stuff, are you saying they are broken in 2.37 now?
<mborzecki> ah ok
<zyga> mborzecki: look at my patch above
<pedronis> they owuld have worked in 2.36 if all var/lib was mounted
<zyga> pedronis: no
<zyga> pedronis: which interfaces are those?
<ackk> hi, is using snap install --dangerous ./mysnap.snap --name mysnap_2 the right way to do a parallel install from a local snap?
<popey> I didn't know you could parallel install local snaps
<pedronis> zyga: account-control, classic-support, network-control
<mborzecki> ackk: yes
<zyga> pedronis: what I'm describing so far only affects core systems
<zyga> er
<mborzecki> popey: you can
<zyga> classic systems
<popey> nice
<zyga> on core systems there are other things in /var/lib
<pedronis> zyga: they all give access to bits of var/lib
<pedronis> are they broken now? or not?
<pedronis> I imagine they needs the bits from host
<ackk> mborzecki, but if you're installing directly from the store you should just use mysnap_2 right?
<pedronis> are they using mount support properly?
<mborzecki> ackk: yes
<zyga> pedronis: looking at master
<zyga> pedronis: excluding /var/lib/snapd/*
<pedronis> yes
<zyga> pedronis: and excluding /var/lib/extrausers
<pedronis> because?
<zyga> I see the following
<pedronis> anyway, I get this:  https://pastebin.ubuntu.com/p/fY9gcjw2bJ/
<zyga> (because those have bind mounts)
<zyga> https://www.irccloud.com/pastebin/lH6YnuB2/
<zyga> I would have to check each one to see if they are for core or classic, hold on
<mborzecki> ackk: that's because the snap file has metadata that states the snap name is 'mysnap' so you need to pass the name you want separately, for the store install we know everything just having mysnap_2
<zyga> pedronis: alsa is affected
<pedronis> zyga: see
<pedronis> mvo: so we have a bit of a bigger problem
<zyga> I think there's more though
<zyga> the quirks code only ran if you had /var/lib/lxd AFAIR
<zyga> so no lxd, no quirks
<zyga> let me double check
<zyga> pedronis: we could bring the code for each of those (alsa, dhcp) to the appropriate interface
<zyga> if they really affect classic
<Son_Goku> Chipaca: pong
<pedronis> yes, just saying that 2.37 might be broken more than just related to jenkins
<zyga> pedronis: quirk code ran unconditionally on core (but not core18) and only on classic systems
<Chipaca> Son_Goku: ok to use snappy in that context
<Son_Goku> cool
<Son_Goku> I'm going to change it then
<pedronis> zyga: still, some snaps might be broken now
<pedronis> apparently
<mvo> pedronis, zyga if thats the case the quirks revert seems to be the best option, yes?
<zyga> mvo: I disagree, I think bringing back quirks is the wrong move
<pedronis> mvo: would not say best, it's the quickest
<zyga> looking at the list we need /var/lib/alsa/ for alsa, /var/lib/usbutils for hardware-observe, /var/lib/systemd/catalog/database for  log-observe and /var/lib/dhcp/ for network-control
<zyga> apparently none of those are tested
<pedronis> of course
<zyga> I'd like to remind us that quirks were done in response to a bug in a similar situation (release broke lxd)
<pedronis> we don't have complete tests for all permissions for any interface afaik
<zyga> we didn't anticipate it would open more things than it did
<zyga> bringing that back would not only fix those, but allow us to make the same mistake, silently, again
<pedronis> zyga: I understand, but breaking things is not good
<zyga> pedronis: I agree on that
<pedronis> zyga: how long would it take to do the correct fix for all relevant things?
<pedronis> that's a bit the question
<zyga> it's just planning what to do to fix the issue
<zyga> adding each of those to the approrpiate interface is easy, just one line in each of the interfaces mount profiles
<pedronis> in away that don't risk perturbing something else
<pedronis> zyga: do we need to add them to core* as well?
<pedronis> no, because this are normal mounts?
<pedronis> I mean they would go through the full mount mechanism?
<zyga> pedronis: alsa and usbutils, yes, dhcp and systemd, no
<pedronis> anyway we would need tests for all of them
<pedronis> given we are at this conjuncture
<zyga> tests for functionality would be complex but a test that a snap can see host's files is easy to add (we have some of those)
<zyga> (see or write to, as appropriate)
<zyga> the code in snap-update-ns that can poke writable holes has one property
<zyga> it works great on top of read-only tree
<zyga> it should not be used on top of /var/lib where some things are writable
<zyga> IMO it's safer to just make the directories required by those interfaces explicitly
<zyga> it is safer because the writable-mimic system takes a snapshot of the directory
<zyga> this way we avoid that entirely
<zyga> in addition, quirks are not represented
<zyga> in the mount profiles
<zyga> they don't participate in the diff calculation
<zyga> mainly in fact because of lack of ability to represent the operations performed (move of /var/lib/snapd)
<zyga> so
<zyga> what shall we do?
<zyga> I worry if 2.37 broke any core devices
<zyga> with network-manager
<zyga> but we got no reports of this during testing cycle
<pedronis> zyga: have a HO
<mvo> +1 for HO
<zyga> I'm there
<zyga> hold on :)
<zyga> actually, we're not in that much of hot water
<zyga> quriks never brought random directories from the host, they made /var/lib writable
<zyga> and brought /var/lib/lxd
<zyga> so all the other interfaces accessing stuff
<zyga> that was never there
<zyga> so that's much easier to reason about :)
<Chipaca> jamesh: you're not around by chance are you?
<xnox> so my lxd is back to bad
<xnox> yesterday "apt install --reinstall snapd" fixed things, but i guess I simply got rolled back to older snapd.
<xnox> / core snap.
<xnox> today i have this:
<xnox> https://paste.ubuntu.com/p/hwBMf2Rwwp/
<mvo> zyga: I did a codesearch for adduser /var/lib - there are a bunch of things that also add a system user there - so if any of those is using (classic) snaps we are in trouble, right? the puppet user is one that might affect us
<zyga> mvo: interesting
<zyga> mvo: if it's a small list we can handle them the same way
<zyga> mvo: if it's not a small ist
<mvo> zyga: there are tons more but I'm not sure how relevant they are
<zyga> right :/
<mvo> zyga: I mean, mariadb, spamd, sendmail, rabbitmq
<zyga> I would say we should fix jenkins and perhaps some high-profile ones only
<pedronis> mvo: zyga: so my forum troubles seems related to the vpn, it works if I'm out of the vpn, doesn't if I'm on the vpn. didn't change vpn config recently tough
<mvo> bacula
<zyga> mvo: it is unlikely rabbit would need snap apps
<mvo> pacemaker etc
<zyga> mvo: the key question is: is this user going to run snap apps
<mvo> zyga: yeah, thats what I mean, I don't know if any of these are relevant
<mvo> zyga: but potentially its quite a few
<mvo> tomcat
<zyga> mmm
<mvo> nagios
<mvo> icinga
<mvo> sbuild :P
<sergiusens> ondra: for the time being you might have luck with setting the version to 8
<ondra> sergiusens I'm building for core16, so that would do for me for now
<zyga> mvo: https://github.com/snapcore/snapd/pull/6446
<zyga> mvo: I'll work on a regression test now
<mup> PR #6446: cmd/snap-confine: add special case for Jenkins <Created by zyga> <https://github.com/snapcore/snapd/pull/6446>
<mup> PR snapd#6446 opened: cmd/snap-confine: add special case for Jenkins <Created by zyga> <https://github.com/snapcore/snapd/pull/6446>
<sergiusens> zyga: you say"it is not a supported feature", do you have a compiled list of what ARE supported features?
<zyga> sergiusens: yes, only /home/* is supported officially
<zyga> anything else is not
<sergiusens> I asked if you have a compiled list
<zyga> sergiusens: the list is: /home/*
<sergiusens> what are the limitations of classic confinement?
<sergiusens> where is this documented?
<zyga> I don't understand the question sorry,
<zyga> limitations of classic confinement?
<zyga> sergiusens: classic confinment is subject to the same limitations that snapd has for users as for non-classic snaps
<zyga> I don't believe we have a page listing limitations in snapd
<zyga> perhaps we should have one
<sergiusens> zyga: when you say something is supported or not, it would be ideal to know what is and what isn't without needing to be on IRC at the right time
<zyga> I don't disagree
<zyga> it's just hard to have a comprehensive list that is correct
<zyga> we learn the hard way about some of those
<zyga> https://forum.snapcraft.io/t/limitations-in-snapd/9718
<zyga> it's a wiki, please feel free to expand this
<zyga> degville: https://forum.snapcraft.io/t/limitations-in-snapd/9718 FYI
<degville> thanks zyga!
<zyga> I'm sure it is not a complete list
<zyga> mvo: how does this look like?
<zyga> https://www.irccloud.com/pastebin/wSR2jWvJ/
<zyga> just a quick smoke test
<zyga> I've hand-tested this on my patched system (I have not tried the real apt install yet)
<mvo> zyga: looks good
<zyga> cool, I'll propose this separately
<mvo> zyga: we have a test-snapd-sh
<zyga> oh, indeed
<zyga> sorry, just local testing memory :)
<mvo> zyga: that you can probably use, use "install_local" for it
<mvo> zyga: no worries
<zyga> will do
<mup> PR core#100 opened: hooks: add /var/lib/jenkins for compat <Created by mvo5> <https://github.com/snapcore/core/pull/100>
<zyga> I mistyped "jenkins" as "jenkinks" way too many times today
<mup> PR core18#115 opened: hooks: add /var/lib/jenkins for compat <Created by mvo5> <https://github.com/snapcore/core18/pull/115>
<mup> PR snapd#6447 opened: polkit: cast pid to uint32 to keep polkit happy for now <Created by chipaca> <https://github.com/snapcore/snapd/pull/6447>
<mvo> zyga: one more complication - core18 will need a stable release (which we have not scheduled) by foundations for the jenkins fix to work
<zyga> mvo: pushed a test
<zyga> mvo: no :)
<zyga> mvo: core 18 never had quirks
<mup> PR snapd#6440 closed: cmd/snap: fix typo in cmd_wait.go <Simple ð> <Created by sparkiegeek> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6440>
<zyga> mvo: one less thing to worry about :)
<zyga> we can just make core18 work on separate timeline (not a regression!)
<sparkiegeek> yay
<zyga> mvo: right?
<mvo> zyga: aha, I like that
<zyga> mvo: I took your suggestion
<zyga> we could add more users this way
<mvo> zyga: so we can remove the core18 PR?
<zyga> and especially once we can drop the magic patch
<zyga> I would keep it
<zyga> but not release on this schedule
<zyga> right?
<mvo> zyga: its YAGNI to me but I don't care enough to argue hard
<zyga> it means people can use core18 based snaps
<zyga> where before they could not
<mvo> zyga: aha, nice
<mvo> zyga: ok, sorry, I misunderstood, I will update the core18 description
<zyga> it's not YAGNI in the sense that we can get this bug back as soon as one of the snaps migrate to core18 for whatever reason
<zyga> (layouts carrot)
<pstolowski> mborzecki: can you take another look at https://github.com/snapcore/snapd/pull/6394? i think Sergio addressed your comment and we could land it
<mup> PR #6394: tests: iterate getting journal logs to support delay on boards on daemon-notify test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6394>
<mvo> zyga: no, sorry, core18#115 is fine and no YAGNI. I thought we were talking about my suggestion in the task.yaml in the jenkins PR
<mup> PR core18#115: hooks: add /var/lib/jenkins for compat <Created by mvo5> <https://github.com/snapcore/core18/pull/115>
<zyga> ah, I see
<zyga> nb, your suggestion was good too :)
<pstolowski> mborzecki: great, thanks!
<mvo> zyga: I updated the core18 description - good to know that we can push that at a different pace
<zyga> yes, one less craze today
<mvo> sil2100: could you please have a look at https://github.com/snapcore/core/pull/100
<mup> PR snapd#6394 closed: tests: iterate getting journal logs to support delay on boards on daemon-notify test <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6394>
<mup> PR core#100: hooks: add /var/lib/jenkins for compat <Created by mvo5> <https://github.com/snapcore/core/pull/100>
<sil2100> mvo: sure o/
<sil2100> mvo: ok, both approved, sadly I don't have write access to the core repo
<sil2100> As I guess that's still under the snappy team, right?
<mborzecki> zyga: E: Package 'jenkins' has no installation candidate ?
<sil2100> (we have core18 and core16, right?)
<mup> PR core18#115 closed: hooks: add /var/lib/jenkins for compat <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/115>
<zyga> mborzecki: drat :)
<mborzecki> zyga: tried it on 18.04, so maybe it actually works on 16.04
<zyga> https://packages.ubuntu.com/search?keywords=jenkins&searchon=names&suite=cosmic&section=all
<zyga> where's wally?
<mup> PR snapd#6448 opened: snapcraft.yaml: fix XBuildDeb PATH for go-1.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6448>
<sparkiegeek> http://pkg.jenkins-ci.org/debian/
<mup> PR core#100 closed: hooks: add /var/lib/jenkins for compat <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/100>
<zyga> sparkiegeek: is that *the* way to install jenkins?
<zyga> I mean, is that what we do internally?
<zyga> mvo: now to trigger core build
<mvo> zyga: yeah, its running
<zyga> mvo: can you please look at https://github.com/snapcore/snapd/pull/6446 again
<mup> PR #6446: cmd/snap-confine: add special case for Jenkins <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6446>
<zyga> sorry, the jenkins package is not in the archive :/
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6441#pullrequestreview-197518397
<mup> PR #6441: overlord/snapstate: validate instance names early <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6441>
<mborzecki> zyga: i suppose it's ok to add the external repo given that tis is the only source
<zyga> yeah
<sparkiegeek> zyga: hmm, can't speak for every team, but that's what some teams use, yes
<zyga> sparkiegeek: thank you, that just makes our tests more relevant
<zyga> I can now take a break and have breakfast, I guess
<mvo> zyga: sounds like an excellent plan
<mvo> zyga: thank you
 * ogra is surprised people dont seem to use a jenkins snap 
<ogra> (there is one maintained by snapcrafters ... even seems reasonably up to date)
<pedronis> mborzecki: 6016 can land now, right?
<mborzecki> pedronis: yup, let me merge it
<mup> PR snapd#6016 closed: snap/naming: move various name validation helpers to separate package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<popey> ogra: it's not classic, so it's a bit inert, I have requested classic for it
<zyga> re
<ogra> popey, +1
<popey> Is there some way to query the store to find out which snaps require core18?
<zyga> https://github.com/snapcore/snapd/pull/6413 needs a 2nd review
<mup> PR #6413: packaging: import debian salsa packaging work, add sbuild test and use in spead <Created by mvo5> <https://github.com/snapcore/snapd/pull/6413>
<zyga> popey: not that I know of
<popey> Ok, I'll ask store people :)
<zyga> https://github.com/snapcore/snapd/pull/6426 needs a 2nd review
<mup> PR #6426: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <https://github.com/snapcore/snapd/pull/6426>
<zyga> mvo: do we need 2.37 PRs for 2.37.1 material or do you plan to do a master-based release?
<mup> PR snapd#6447 closed: polkit: cast pid to uint32 to keep polkit happy for now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6447>
<mborzecki> mvo: the spread test in #6252 needs tweaking, because we're actually using snapFromSender() now, it's looking wehther the calling pid is part of snap. cgroup
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<Chipaca> pedronis: did you see my note on the #6280 ?
<mup> PR #6280: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6280>
<zyga> mvo: FIY https://tracker.debian.org/pkg/snapd - 2.37 has now migrated to testing
<mborzecki> off to pick up the kids
<diddledan> popey https://www.irccloud.com/pastebin/O8qqJ1D3/
<pedronis> Chipaca: mmh, so the output there is yaml parsable but is also localized?
<pedronis> strange combination
<Chipaca> pedronis: â¦ yeah i guess it is
<Chipaca> it doesn't have to be, i was just rotating the original list
 * diddledan pokenprod the pope! popey...
<pedronis> Chipaca: do we do that anywhere else?
<diddledan> has he gone?
<pedronis> I mean that = this combo
<Chipaca> pedronis: info is the only other yaml-ish, and that's not i18n'ed
<diddledan> I think that's a flawed query actually. it only returns 2000 results
<pedronis> Chipaca: bit of a mess
<pedronis> Chipaca: seems we need --localized  and not just --unicode
<Chipaca> ?
<Chipaca> localisation already has a standard way of turning it off across the board
<pedronis> Chipaca: it makes sense to localize it, but not if it goes to a tty and program wants to parse it
<pedronis> not-tty
<Chipaca> zyga: question about 6446 (which might already have been discussed here but i missed it)
<Chipaca> zyga: why not add /var/lib/jenkins to homes?
<zyga> homes?
<zyga> to HOMEDIRS?
<Chipaca> HOMEDRIS
<Chipaca> yes
<Chipaca> or no?
<Chipaca> /etc/apparmor.d/tunables/home:@{HOME}=@{HOMEDIRS}/*/ /root/
<Chipaca> or HOMEDIRS
<Chipaca> either, probably
<zyga> I don't know if we can do that from our package sanely
<Chipaca> I dunno enough to know :-)
<zyga> I think this is a question to jdstrand
<Chipaca> zyga: yes we can
<Chipaca> zyga: look at /etc/apparmor.d/tunables/home.d/
<zyga> yes but that has more implications (beyond snpd)
<zyga> snapd
<zyga> I think we could but I didn't think about doing this
<Chipaca> zyga: if we did it, would it work?
<zyga> it would still require the remaining patches
<zyga> but I don't see why not
<Chipaca> right, I'm not liking the duplication we're adding for this
<Chipaca> whereas if it's adding it to homes or homedirs, it's less duplication imho
<Chipaca> if it worked, and if jdstrand is ok with it
<zyga> where would you add that?
<zyga> in /etc/apparmor.d/
<zyga> adding files to /etc/ is problematic
<Chipaca> zyga: why?
<zyga> it cannot be easily changed
<Chipaca> AIUI it'd be in /etc/apparmor.d/tunables/home.d/
<zyga> we cannot handle the reexec case then
<zyga> it becomes a conffile that lives beyond the lifetime of the package
<zyga> all smell in my opinion
<zyga> we have bugs that keep us holding onto specific names in /etc because of apt bugs
<pedronis> also why would we do this
<pedronis> and not jenkins
<zyga> yeah
<zyga> good point
<zyga> jenkins is free to do this (not that they are aware it is useful)
<pedronis> Chipaca: seems the most simple thing would be not to localize those strings in 6280, not great tough
<mvo> zyga: I will cherry pick all the easy ones into 2.37
<mvo> zyga: only if there are conflicts I won't
<mvo> zyga: slightly sad that 6446 is not finished (spread)
<mvo> zyga: jenkins postinst fails in the spread test
<mvo> zyga: ERROR: no java executeable found or something
<pedronis> heh
<jdstrand> zyga and Chipaca: I just commented on something similar in https://github.com/snapcore/snapd/pull/6446
<mup> PR #6446: cmd/snap-confine: add special case for Jenkins <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6446>
<jdstrand> zyga and Chipaca: the thing is, zyga is right, HOMEDIRS only makes sense when it is something that really is home directories for actual users. eg, nfs users, etc. if we added that for every snap in the manner Chipaca described, sure it would work for snap-confine, but it would also affect non-snap policy as well as snap policy that uses @{HOME}
<Chipaca> jdstrand: to be clear this was just for jenkins, which isn't a "regular" user but it isn't a snap either
<jdstrand> zyga and Chipaca: but we have the beginnings of a similar system with /var/lib/snapd/apparmor/snap-confine
<mvo> zyga: if you don't mind I will split 6446 into the first commit and the test and push the test as a second PR, this way we can get the fix into master and 2.37 while iterating on the test. sounds sensible?
<jdstrand> Chipaca: I know. I read all backscroll and the PR
<Chipaca> jdstrand: you're a better person than I am
<zyga> AFK
<jdstrand> Chipaca: but I wouldn't want HOMEDIRS updated on my system to allow /var/lib/jenkins since that is a surprising side affect on the other policy on my system. snap-confine should have that, not global policy
<jdstrand> Chipaca: hehe :) I'm not sure how you came to that conclusion! ;)
<Chipaca> jdstrand: by gathering too few facts and jumping to conclusions, like I always do
<Chipaca> which â¦ is kinda the point
<jdstrand> heh, I knew what you meant but was disagreeing with the conclusion :)
<mup> PR snapd#6449 opened: cmd/snap-confine: add special case for Jenkins <Created by mvo5> <https://github.com/snapcore/snapd/pull/6449>
<mup> PR snapd#6106 closed: overlord/ifacestate: handler for hotplug-update-slot tasks <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6106>
<mup> PR snapd#6441 closed: overlord/snapstate: validate instance names early <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6441>
<mup> PR snapd#6445 closed: [RFC] snap-confine: revert "cmd/snap-confine,snap-update-ns: discard quirks" <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6445>
<mup> PR snapd#6444 closed: [RFC] snap-confine: revert "cmd/snap-confine,snap-update-ns: discard quirks" (2.37) <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6444>
<zyga> hey jdstrand
<zyga> (standup)
<zyga> mvo: thank you, I will fix the java thing shortly
<mvo> zyga: thank you
<mvo> zyga: and welcome back :)
<zyga> jdstrand: about home directories, I have some ideas myself, I would like to detach ideas from the current fire (unless the idea is feasible as a solution right now)
<zyga> Chipaca: unsigned is a sign of sign issue
<zyga> jdstrand: as one item I wanted to avoid depending on the environment
<zyga> jdstrand: we have too many things conveyed this way
<diddledan> popey: https://www.irccloud.com/pastebin/fcCcNH8d/
<morphis> mvo: there seems to be another thing which "broke" with 2.37: https://bugs.launchpad.net/charm-etcd/+bug/1813678
<mup> Bug #1813678: Snap install error: snap "etcd" is not compatible with --classic <field-critical> <Etcd Charm:New> <https://launchpad.net/bugs/1813678>
<mup> PR snapd#6280 closed: cmd/snap: make 'snap warnings' output yamlish <â Blocked> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6280>
<diddledan> popey: if you want to replicate my test, I've put the source online at https://github.com/diddlesnaps/snap-bases (many thanks to the uappexplorer folks who I stole the majority of the api code from)
<morphis> mvo: the k8s folks are updating the charm but it actually broke existing setups, not sure if you heard about this one yet
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6446 updated with the comment you asked for
<mup> PR #6446: cmd/snap-confine: add special case for Jenkins <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6446>
<zyga> morphis, mvo: looking at etcd thing
<zyga> ah
<zyga> I think this is another of the "feature not a bug" case :/
<niemeyer> https://twitter.com/gniemeyer/status/1090260317416841217
<niemeyer> Snap thread
<morphis> zyga: yeah, it's not critical and gets fixed from the charm but revealed that the etcd snap was still installed with --classic after it got strict confined a year ago
<zyga> mmm
<zyga> yeah
<morphis> zyga: just wanted that you guys are aware of this as I am not sure if it will cause issues elsewhere too
<zyga> thank you
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/6252/commits/c7d97e0cacc2b40a8d51cd46f5668ff05f403c31 do you recall if there was some trouble with cla checker at the time?
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<Chipaca> mborzecki: what do you mean?
<Chipaca> mborzecki: you trying to remember why that's set there?
<mborzecki> Chipaca: yeah
<Chipaca> mborzecki: yeah i expect it broke at some point
<Chipaca> it needs the whole history to work properly
<Chipaca> was this PR's  kenvandine's?
<mborzecki> Chipaca: yes
<Chipaca> 's?
<Chipaca> yeah
<Chipaca> he'd signed it with a weird account, that just happened to be in the tree already
<Chipaca> you can see it in the output, probably
<Chipaca> yeah
<mborzecki> Chipaca: briefly thought about reverting it, zyga asked for it, but if the cla checker is going to stop me then i'd leave it :P
<Chipaca> one of those is not like the other
<Chipaca> yep
<Chipaca> it _should_ work, dunno why it didn't
<Chipaca> we can try :-)
<Chipaca> mborzecki: zyga:  https://travis-ci.org/snapcore/snapd/jobs/461903781
<Chipaca> it's because kenvandine hasn't signed the cla, wouldn't you know
<zyga> eh
<zyga> can we special case in the code :-) ?
<mborzecki> haha
<Chipaca> and launchpad doesn't let me ask "does this account have any other emails @canonical.com"
<Chipaca> at least AFAIK
<mborzecki> hm, kenvandine could reset author if the 'offending' commit
<Chipaca> yes, yes he could
<Chipaca> but having the whole history  is the right thing to do
<Chipaca> so, eh
<kenvandine> I'm afk until Thursday
<kenvandine> :-)
<kenvandine> What was wrong with the author line?
<diddledan> if Ken signed the CLA and his employer is Canonical, does that mean that Canonical are assigning their copyright to Canonical? that sounds like a deep rabbit hole ;-p
<mborzecki> kenvandine: hehe nothing about you without you :)
<Chipaca> kenvandine: TINC! HAND.
<kenvandine> Time for airplane mode!
<mborzecki> Chipaca: kenvandine: i'll push the changes to the spread test so that it'll be green and then i'll request changes to get it sorted out
<ackk> hi, if you have multiple services in a snap, can you start/stop/enable/disable them individually via snapctl inside a hook?
<zyga> ackk: I think you can now
<ackk> zyga, is it via "${SNAP_INSTANCE_NAME}.$service" ?
<ogra> jdstrand, seeing you adding all these interface docs ... i think it might be helful having a filed "causes manual review on upload" or some such, so people are aware before using an interface in their snapcraft.yaml
<zyga> ackk: I don't recall, sorry, let me check if this is documented
<zyga> hmm
<zyga> perhaps this is not allowed
<zyga> pstolowski, mborzecki: looking at https://github.com/snapcore/snapd/pull/5777 - do you know if this got resurrected?
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<jdstrand> zyga: well, that's why I said for the future. however, I think it is useful to have a vague understanding of the future so we don't do something now that would conflict with it
<jdstrand> zyga: but we've done that
<zyga> jdstrand: I have some ideas if you'd like to know
<zyga> I can share those quickly
<mborzecki> zyga: 5777 went in as #5979
<mup> PR #5979: install: don't start disabled services <Squash-merge> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5979>
<zyga> mborzecki: thank you, super
<jdstrand> ogra: as for updating the interfaces with needs manual connection, that is more of a degville thing. I'm just following established prcedure. it might be nice though
<jdstrand> zyga: maybe for another time? we should chat about it though
<ogra> jdstrand, well, you already have "Auto-Connect: true/false" ... the above was more about ... perhaps i shouldnt bother, since using this interface will get me into manual review anyway ...
<ogra> i.e. more about the store than about the later installation of the snap
<degville> ogra / jdstrand: I can add a note about triggering a manual review to the interface overview.
<ogra> that would be a great addition i think
<ogra> saving some support questions in the forum
<degville> cool, I'll do that now.
<mborzecki> ackk: yes snapctl <start|stop|restart> $SNAP_INSTANCE_NAME.$service
<ackk> mborzecki, I see. kinda related, we currently run "snapctl start --enable $SNAP_INSTANCE_NAME" + "snapctl restart --reload $SNAP_INSTANCE_NAME" in the config hook to ensure the service is enabled and restarted if already enable (after config change). is there a way to do this in a single shot? afaict that takes a long time as it restarts the service twice
<mborzecki> ackk: no, i don't think so, you're looking for plain `systemctl enable` if i understand correctly?
<ackk> mborzecki, no I want to enable it but if it's already enabled and running I want to restart
<ackk> (as the config might have been changed)
<mborzecki> ackk: ok, so systemct is-enabled ...  && systemctl restart then?
<ackk> mborzecki, yeah something like that, but I guess you can't do it with just snapctl, right?
<jdstrand> degville: there are only a few that trigger a manual review, and we do have text for those (cc ogra) in the actual interface page
<mborzeck1> ackk: heh, connection problems, idk if you got my last message, imo you'd need to parse snapctl services output
<jdstrand> eg, https://forum.snapcraft.io/t/the-block-devices-interface/9721 has "Consumers of this interface require a snap declaration for distribution via the Snap Store."
<ogra> yeah, its only 3 or 4 ... but i still think it would be helpful having that in the doc directly
<jdstrand> but https://forum.snapcraft.io/t/the-u2f-devices-interface/9722 does not since it is manually connected (which is expressed in the large table)
<ogra> now thats very ... uhm ... whats a snap declaration ... means i need to read up about that first
<jdstrand> ogra: that snap declaration is a link
<jdstrand> to https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455/
<ogra> feels like a text adventure :)
<jdstrand> well, people shouldn't be using these typically ;)
<zyga> jdstrand: ack, another time is fine
<zyga> I feel so tired today, I'll take a nap
<degville> jdstrand / ogra: thanks. I'll tread lightly so that no one'e eaten by a grue, but add a note to look out for these specific cases.
<ackk> mborzeck1, ah I see yeah that might work, thanks
<pedronis> pstolowski: question in 6322, sorry I didn't ask it before
<pstolowski> looking
<rharper> does snapd exec udevadm trigger  ? if so when?  does it ever use 'udevadm settle' ?
<pedronis> mborzecki: some comments in 6387
<zyga> rharper: yes it does
<pedronis> Chipaca: #6415 needs a re-review
<mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<pstolowski> pedronis: replied
<Chipaca> rharper: https://github.com/snapcore/snapd/blob/master/interfaces/udev/udev.go#L104
<pedronis> pstolowski: re-replied :)
<rharper> Chipaca: ok;  are you aware of any snaps using subsystem=block  ?
<Chipaca> rharper: how would a snap do that?
<Chipaca> maybe it's a question for pstolowski :-)
<rharper> I'm not sure, there is this call, https://github.com/snapcore/snapd/blob/master/interfaces/udev/udev.go#L79
<pstolowski> pedronis: sure, will do, fair point, ty!
<rharper> I'm not familiar enough with the code base or interface in snap to know if only certain subsystem triggers are allowed
<Chipaca> rharper: grepping, that's called with nil, []string{"input"}, []string{"input/joystick"}, and []string{"input", "tty"}
<Chipaca> rharper: at least currently
<Chipaca> rharper: why?
<rharper> I'm looking at logs on a system where after the core snap and the livepatch snap are installed, I can see block device rules get triggered; trying to see if that's related or not
<Chipaca> zyga: ^ ?
<Chipaca> rharper: I don't see anything that says to do that with subsusytem=block
<Chipaca> rharper: but, I'm not familiar with this part of the codebase; zyga or pstolowski would know for sure
<rharper> Chipaca: ok, thanks
<pstolowski> rharper, Chipaca: interfaces/udev/backend_test.go tells more about cases where we retrigger udev rules; test case names give context
<pstolowski> rharper: actually, we do "trigger --subsystem-nomatch=input", per comment in the code:"// By default, trigger for all events except the input subsystem "
<rharper> yes, was just looking at that
<pstolowski> rharper: that would explain the block devices case?
<rharper> yes
<rharper> yes it does
<pstolowski> rharper: does it cause issues?
<zyga> Iâm sorry for the lag. Iâm not feeling very well. Thank you for handling this pstolowski
<pstolowski> np
<rharper> pstolowski: it is, but I'm not sure exactly why;  replaying of rules is sometime resulting in missing symlinks;
<pstolowski> uhm.. not good
<zyga> mvo: the jenkins core is now in edge
<mvo> zyga: great
<mvo> zyga: now we just need a green pr
<zyga> it failed on github network :/
<zyga> with a bit of luck it will go green now
<zyga> did you merge a 2.37 backport of just the fix (sans the test?)
<zyga> ah, I see it is also pending
<mup> PR snapd#6449 closed: cmd/snap-confine: add special case for Jenkins <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6449>
<zyga> jdstrand: nothing for .1 but if you have a moment, I'd love an actionable review comment on https://github.com/snapcore/snapd/pull/6347
<mup> PR #6347: many: allow snap-update-ns to write user mount profile <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6347>
<zyga> morphis: hey
<zyga> morphis: did you ended up filing that bug?
<morphis> zyga: no
<jdstrand> zyga: it's on my list but not for today
<zyga> thanks, just checking
<zyga> not urgent
<sergiusens> zyga: hey, as the resident OS snapd ecosystem rep, do we have guides to make snapd work on systems where systemd is not pid 1?
<zyga> hey
<zyga> I think we have no written document about this
<zyga> we have the older systemd that was patched to run alongside another init system
<zyga> from snapd's point of view not that many things differ
<zyga> but I don't think we have any document about this
<sergiusens> zyga: the reason I ask is because there's an MX Linux developer wanting to enable snapd there
<zyga> MX linux?
<zyga> do invite him over to join us here
<zyga> I think it takes thinking and cooperation but it can definitely be done
<sergiusens> zyga: should I tell him to just ping you?
<zyga> please
<zyga> thanks for raising this!
<zyga> mvo: 2.37.1 ready
<zyga> shall I dput?
<mvo> zyga: sounds good to me
<zyga> okay
<zyga> here goes nothing
<zyga> done
<mup> PR snapd#6448 closed: snapcraft.yaml: fix XBuildDeb PATH for go-1.10 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6448>
<zyga> Pharaoh_Atem: hey, we released 2.37.1 with an important fix for using snaps in jenkins
<zyga> (we broke usability badly)
<zyga> Pharaoh_Atem: if you have a moment to release the .1 package it would be great
<mup> PR snapd#6446 closed: cmd/snap-confine: add special case for Jenkins <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6446>
<mup> PR snapd#6450 opened: release: 2.37.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6450>
<Pharaoh_Atem> zyga: considering I haven't released 2.37 at all yet, yeah I'll look at 2.37.1
<Pharaoh_Atem> zyga: insofar as the MX Linux guy wanting to enable snapd, it should be relatively easy to repackage the deputy systemd to run on non-systemd distros
<mwhudson> zyga: oh hey did you update snapd on salsa?
<zyga> I sent a PR
<roadmr> yum
<zyga> can I push to salsa debian/snapd directly?
<mwhudson> zyga: ah maybe not
<mwhudson> i can fix that though
<mwhudson> zyga: ok you should have access now
<zyga> thank you, I have access now
<mwhudson> i merged your PR though so you can't test it by pushing that oh well
<zyga> mwhudson: that's fine, I'm sure 2.37.2 or 2.38 is soon to follow :)
<mwhudson> zyga: what's the status of getting the debian packaging into snapcore/snapd?
<zyga> mwhudson: it was proposed by mvo
<zyga> mwhudson: we have a card for it and will get it merged
<mwhudson> zyga: ok
<zyga> it includes a spread test that really uses it properly (with sbuild and dual build)
<zyga> I will update it with 2.37.1 release tomorrow
<mwhudson> will we replaced the snapd branch with something that's basically master with a single extra non-merge commit that changes the 'debian' symlink then?
<mwhudson> er
<zyga> yes :)
<mwhudson> snapd debian branch on salsa i mean
<mwhudson> awesome
<mwhudson> zyga: huh i see prs from mvo here https://salsa.debian.org/debian/snapd/merge_requests
<zyga> yeah
<mwhudson> but i guess those will get subsumed by the other work?
<zyga> I noticed too, I'll ask him tomorrow
<zyga> I think so as well
<mwhudson> something is a bit odd about them, maybe they are based on revisions i force-pushed over or something
<mwhudson> ah yes they are
<mwhudson> how the heck to i sign up to get an email when someone proposed a PR
<mwhudson> ah 'watch' i guess
<zyga> yeah
<zyga> watch
<mwhudson> anyway lunchtime
#snappy 2019-01-30
<mborzecki> morning
<mup> PR snapd#6450 closed: release: 2.37.1 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6450>
<mborzecki> arch packages update
<mborzecki> d
<ackk> hi, is it expected that $SNAP_DATA and $SNAP_COMMON on parallel installs point at the same dirs on all installs?
<zyga> Hello
<zyga> ackk: yes, check out the data though
<zyga> It is all good :-)
<zyga> mborzecki: thank you
<mborzecki> ackk: yes, inside the mount namespace those appear as the same paths, but outside each instance has its own dir
<mborzecki> zyga: hey
<ackk> oh, I see
<mborzecki> ackk: however, this is not the case for $SNAP_USER_DATA, $SNAP_USER_COMMON and $XDG_RUNTIME_DIR
<mborzecki> ackk: https://forum.snapcraft.io/t/parallel-installs/7679 has some info about the paths and lists some limitations of the current implementation
<ackk> mborzecki, but why are SNAP_DATA and SNAP_COMMON paths not instance-based as for the USER ones?
<zyga> ackk: just technical limitation
<zyga> We should be able to handle that eventually
<zyga> 2.39
<zyga> Perhaps
<mborzecki> ackk: they are, each instance has a separate directory, but insdie a snap we bind mount the instance specific dir on top of the non instance one to make it easier to use
<mborzecki> ackk: for instance, snap foo_123 has /var/snap/foo_123/common and /var/snap/foo_123/current, inside the filesystem view of the snap, /var/snap/foo_123/common is also avaialble as /var/snap/foo/comon, but that's stil the same directory
<mborzecki> ackk: not sure i explained that well enough :)
<ackk> mborzecki, yeah thanks I understand
<ackk> mborzecki, ok, the issue I was trying to track down seems to be this: if you have a "foo" snap with a config hook and you snap install foo_2, the hook is not found
<mborzecki> ackk: ok, let me look into this, maybe there's a bug after all
<ackk> mborzecki, thanks
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> mborzecki: thanks for the arch update
<mvo> zyga: fwiw, the failure in the last from last night was a fluke
<mvo> zyga: I re-run the entire suite
<mvo> zyga: and no errors, so yay
<zyga> Good morning pawel, michael
<zyga> Good news
<mvo> zyga: and good morning
<zyga> I will be around soon. Feeling a little under the weather today
<zyga> at my keyboard
<mup> PR snapd#6451 opened: tests: update smoke/sandbox test for armhf <Created by mvo5> <https://github.com/snapcore/snapd/pull/6451>
<mborzecki> ackk: i tried my demo snap and it seems the hooks are called as expected
<mborzecki> ackk: in your case, do you need foo to be installed before foo_2 is installed?
<ackk> mborzecki, that's the case that doesn't work, when you just snap install foo_2 and don't have foo installed
<mvo> pstolowski: hey, good morning! if you have some cycles and a dragonboard or a pi3 running some of the beta validation would be great, then we can parallelize  as much as possible
<mvo> zyga: or do you happen do have a dragonboard?
<zyga> mvo: I do :)
<mborzecki> ackk: can you use this demo snap https://github.com/bboozzoo/parallel-installs-demo ? snap pack and install --dangerous .. --name parallel-installs-demo_foo
<mborzecki> ackk: the configure hooks drops a log in $SNAP_COMMON, so there should be /var/snap/parallel-installs-demo_foo/common/run.log file once it's installed
<pstolowski> mvo: sure, happy to help, i've pi3, shall i run specific tests on it?
<ackk> mborzecki, yeah that works but IDK why my snap doesn't then
<ackk> mborzecki, "snap install --edge h2static_2"
<ackk> mborzecki, then set listen=:8080
<ackk> (or any port)
<mborzecki> ackk: ok, trying
<zyga> pstolowski, mvo: for the benefit of everyone let's discuss the testing process here
<zyga> my memory of how it goes is rusty
<pstolowski> zyga: yeah, i've never done this before, not familiar with the process at all
<mvo> zyga: its all in the mail from sergio
<zyga> https://github.com/snapcore/snapd/blob/master/tests/external-backend.md
<mvo> zyga: his examples are really good
<zyga> oh, let me look
<mvo> zyga, pstolowski https://github.com/sergiocazzolato/snappy-qa-jobs
<zyga> https://github.com/sergiocazzolato/snappy-qa-jobs
<zyga> right :)
<mvo> zyga: heh
<zyga> mvo: I think we really want to help sergio merge the code to master
<mvo> pstolowski: yeah, sorry for this. special circumstances because sergio is on vac and we need to deal with this regrssion :/
<zyga> or at least link to it from master
<mvo> zyga: yeah, I think we need to look into brining this into our tree
<pstolowski> mvo: don't mention it, happy to help, we really need to spread knowledge and workloads more
<mvo> pstolowski: yeah, it also makes me appreciate sergios work more (I always did of course) but its nice to see how much this is automated
<mvo> pstolowski, zyga I added you to the card and there is a list of things to do, if you take one, just add *name* in the checlist and once its done a pastebin link (those are generated automatically)
<mborzecki> ackk: can you add https://github.com/bboozzoo/parallel-installs-demo/blob/master/meta/snap.yaml#L10-L11 to your snap.yaml?
<mborzecki> pstolowski: do you know if configure hooks are automatically discovered?
<ackk> mborzecki, oh wait, I thought I had that, lemme try
<pstolowski> mborzecki: yes they are
<ackk> mborzecki, ah, that works
<ackk> mborzecki, thanks
<sparkiegeek> ackk: did you figure out your 'hooks aren't running on parallel installs' issue?
<ackk> sparkiegeek, yeah, see above. I was missing the hook: section in the snapcraft.yaml
<sparkiegeek> ackk: ah, so PEBKAC
<ackk> sparkiegeek, well, afaiu it's only mandatory if you need to set plugs. the hook is called on the "normal" install
<pedronis> pstolowski: mborzecki: hook should be outdiscovered,  does autodiscovery gets confused if there's a instance name?
<mborzecki> sparkiegeek: might be a bug too looking into it, for now declaring it explicitly works
<Chipaca> mo'in
<pedronis> Chipaca: hello
<sparkiegeek> Chipaca: moin moin
<mborzecki> pedronis: trying to find that out
<Chipaca> pedronis: question about lanes: why do tasks have a list of lanes? when would a task be on more than 1?
<pstolowski> mvo: clarification needed - if i'm going to test fresh core18 install on pi3, after flashing the image i do the initial consoleconf setup manually right? the test scripts doesn't automate this?
<mvo> pstolowski: correct
<pstolowski> mvo: good, thanks
<mvo> pstolowski: if you notice anything where the docs should be clearer feel free to make notes and pass to sergio
<pedronis> Chipaca: afaik we haven't used that feature so far (putting a task in more than one lane)
<pstolowski> mborzecki: fwtw we rely on auto-discovered configure in many of our test snaps in spread
<Chipaca> popey: Wimpress: where was that "how to make your snap more shiny" tutorial with stats and such?
<Chipaca> pedronis: what would it do if we did? :-)
<pedronis> Chipaca: something complicate if you abort
<pedronis> we have logic for it (complicated)
<pedronis> Chipaca: tbh, at this point I would be ok for us to error if we try to do that (add a task to more than one lane)
<Chipaca> ok, I'll not worry about it for now then
<popey> Chipaca: https://snapcraft.io/blog/make-your-snap-store-page-pop
<Chipaca> pedronis: can we talk in malta about using a database for state?
<Chipaca> popey: thanks!
<mborzecki> pstolowski: pedronis: looks like there is a bug
<pedronis> Chipaca: we can talk about it
<mup> PR core18#116 opened: Support arm64 with efi bootloader <Created by woodrow-shen> <https://github.com/snapcore/core18/pull/116>
<pedronis> Chipaca: do we have an obvious candidate for it tough?
<mborzecki> pstolowski: pedronis: https://github.com/snapcore/snapd/blob/master/snap/info.go#L1011-L1019
<pedronis> mborzecki: I suppose the bug is inside those functions
<pedronis> ah we set instance key
<pedronis> late
<pedronis> funny us
<mborzecki> yeah
<pedronis> mborzecki: anyway need a test
<mborzecki> mhm
<pedronis> mborzecki: ?
<mborzecki> pedronis: just confirming that's the bug, and we do need a test
<pstolowski> grr github acting up on me, can't see that diff
<pstolowski> mborzecki: do we have any tests for hooks and instances?
<mborzecki> pstolowski: no, i don't think there's a spread test specifically targeting hooks with parallel instances
<mborzecki> so declaring the hooks explicit works, but autodiscovery does not
<zyga> mborzecki, pedronis: patch for 2.37.2 :) ?
<mborzecki> zyga: likely
<mborzecki> are we doing .2 already? :P
<Chipaca> the tests run so much faster with 1.10
<zyga> mborzecki: inevitably
<mborzecki> Chipaca: especially the ones are cache and don't run
<mup> PR snapd#6452 opened: overlord/snapstate: format the refresh time for the log <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6452>
<Chipaca> mborzecki: travis's "short" unit run went from ~9m to ~5m
<Chipaca> locally it seems to be even faster
<mborzecki> Chipaca: oh, those aren't cached for sure
<Chipaca> ^^^ a very very trivial PR (honest)
<mborzecki> ehh merge conflict in #6415
<mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<Chipaca> mborzecki: yeah
<ogra> pedronis, mvo, is there any coordination between the cloud-init people and the core team going on ... the cloud-init documentation regarding core seems to be quite a mess (see: https://forum.snapcraft.io/t/ubuntu-core-18-rpi-3-not-seeded/9728/9 )
<pedronis> ogra: not really so far
<ogra> yeahm thats what i thought
<sparkiegeek> blackboxsw: ^
<Chipaca> pedronis: wrt re-refresh, it's to be done on all snaps that were requested in the original update, not on all snaps that were updated, right?
<Chipaca> ie if the user said "snap refresh a b c d", re-refresh checks those 4 even if just c had an update?
<pedronis> Chipaca: should we write it down somehwere
<Chipaca> pedronis: I'll add a comment :-)
<pedronis> we are reshaing the same thing again and again
<Chipaca> pedronis: last time it was just-those-that-had-epoch-bump vs "all"
<Chipaca> now i'm clarifying what "all" meant
<pedronis> Chipaca: we need to ask about snaps that have had a successful refresh, of these we should refresh the ones that have a new epoch change lined up
<pedronis> *ask the store
<Chipaca> pedronis: yes, and for that I check the lanes
<Chipaca> pedronis: but in the task description, I wanted to say what the re-refresh was _for_
<Chipaca> I guess just the ones that get updated is the better superset
<pedronis> Chipaca: yes, but that's also the set we put in the original summary, no?
<pedronis> I don't think the summary has a b c d
<pedronis> if only c got an update
<pedronis> (but maybe I'm misremembering)
<Chipaca> pedronis: the change summary yes, we set that in daemon
<Chipaca> the task summary no
<Chipaca> (there's no other task that's whole-update like rerefresh is)
<Chipaca> (afaik)
<pedronis> but we have the info
<zyga> mvo: should we upload 2.37.1-1 to disco?
<pedronis> Chipaca: we are problably discussing a detail that doesn't merit discussing here, it should be clear enough in the code, np?
<Chipaca> pedronis: i think so
<pstolowski> mvo: my validation tests seem to be stuck on failover:emptysystemd
<mvo> pstolowski: hm, ok might be worthwhile to investigate
<mvo> pstolowski: I saw some fluke failures in different tests, especially in core18 I think we need to look at those too, looks like the suite is not quite as robust on core18 yet
<pstolowski> nooo... /usr/bin/pastebinit
<pstolowski> Uploding execution log to paste.ubuntu.com
<pstolowski> Failed to contact the server: [Errno socket error] The write operation timed out
<pstolowski> mvo: is it ok to re-run the tests over same image, or should i reflash?
<mvo> pstolowski: worth a try to re-run but my experience is that it might be broken from some invalid restore etc
<mvo> pstolowski: via the docs in tests/external-devices.md you can also re-run individual tests
<pstolowski> mvo: ack, thanks
<Chipaca> hmm
<Chipaca> 2019/01/30 10:40:32.282838 taskrunner.go:420: DEBUG: Running task 293320 on Do: Make snap "core" (6259) available to the system
<Chipaca> 2019/01/30 10:40:32.321291 link.go:75: cannot update fontconfig cache: cannot get fc-cache-v6 from core: open /snap/core/current/bin/fc-cache-v6: no such file or directory
<Chipaca> suspect something there is not waiting for the mount
<pedronis> Chipaca: we had a fix for that I tought
<Chipaca> ah, maybe we do (i'm switching channels a lot)
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/6317
<mup> PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6317>
<pstolowski> pedronis: i've cleaned up https://github.com/snapcore/snapd/pull/5962 and unblocked it. diff is ~1100 lines, but 700 lines are new tests.
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<pstolowski> mvo: pastebin step of the validation tests always fails for me :/
<mvo> pstolowski: even if you have pastebinit installed? strange it works pretty reliable for me (18.04 and 18.10)
<mvo> the Pi test just takes forever :/
<pedronis> pstolowski: ok, thanks, will try to get to it this week still
<pedronis> pstolowski: does it include the bits about avoiding to recreate slots already in the gadget, or is that separate?
<pstolowski> pedronis: yes it does
<pstolowski> mvo: yes, i can use pastebinit manually just fine
<pedronis> pstolowski: did you find out if we have problem with the implicit slots logic as it relates to hotplug?
<pedronis> or it will just work
<pstolowski> pedronis: should just work; it remains a bit messy and brittle though
<pedronis> ok, thanks
 * Chipaca takes a break
<mborzecki> heh, hookstate tests are missing some cleanup, added new test there and the previous ones get stuck :/
<mup> PR snapd#6453 opened: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6453>
<mborzecki> pedronis: pstolowski: fix for autodiscovery of hooks ^^
<pstolowski> ty
<zyga> mvo: hey
<zyga> sorry for the slow update
<zyga> I'm having issues setting up the dragon board
<zyga> it gets the ip address but console-conf is unhappy
<jdstrand> mvo: hey, fyi, test-snapd-dbus-consumer and test-snapd-dbus-provider have a bunch of 'Store upload failed for...' messages that for some reason the security team is getting emails for, but I don't see where we own those. did the macaroon expire?
<pedronis> jdstrand: yes, macaroon expiry is the likely cause
<mvo> jdstrand: oh, stange - sould you forward me one of those?
<mvo> jdstrand: why the security team of all people :)
<zyga> mvo: I think the dragonboard image doesn't work
<mvo> zyga: uh
<zyga> mvo: it boots, I can associate with ap's
<zyga> mvo: but I cannot leave console conf
<zyga> mvo: some kernel error flies on the screen briefly during setup
<mvo> zyga: uc16 or uc18 or both?
<zyga> mvo: and then the message from console-conf is "Network configuration timed out; please verify your settings"
<zyga> uc16
<zyga> I've been trying to use different AP's move the device around etc
<zyga> mvo: note that it does connect, it gets an IP address
<zyga> but that's that
<zyga> the error that flashes is "] wcn36xx: ERROR hal_remove_b6"
<mvo> zyga: hm, hm, bad. I can't comment, I don't know enough about the DB, I think sergio mentioned we can run some tests via testflinger, I have a look at this now
<zyga> mvo: I can make a uc18 image next
<zyga> I may also have a usb-ethernet adapter at home somewhere
<zyga> but I think that's not sufficient to say "this is good"
<zyga> I doubt it's our fault (3.37 -> 3.37.1)
<zyga> so I would not block on that
<mvo> zyga: yeah, lets see if testflinger is more happy
<cwayne> plars: ^ fyi
<zyga> booting uc18 now
<zyga> random thing from logs: FAT: Misaligned buffer address (00000000bd0f48f0)
<zyga> ubuntu-image issue?
<zyga> mvo: uc18 feels less happy
<zyga> ah
<zyga> no, just veeeery slow :)
<zyga> mvo: uc18 works
<jdstrand_> mvo: ok, I bounced them to you
<mvo> zyga: probably slow because of entropy
<mvo> jdstrand_: ta
<mvo> zyga: running testflinger now, fingers crossed
<cwayne> mvo: is this with a fresh image created with the core in beta?
<mvo> cwayne: I hope so, this is done via a script from sergio, I have not looked at the inner workings yet
<mvo> cwayne: it says "2019-01-30 13:52:47,210 dragonboard_002 INFO: DEVICE AGENT: Flashing Test Image
<mvo> "
<cwayne> ok, just checking as we've done the core beta snap tests and dragonboard was a-ok
<mvo> cwayne: aha, so my test is redundant?
<cwayne> mvo: not if its a new image
<cwayne> we just snap refresh
<mvo> cwayne: its the beta 2.37.1
<mvo> cwayne: aha, I see
<mvo> cwayne: I will check, I am not sure which method is used
<cwayne> IIRC this test is creating an image with ubuntu-image, which i guess is technically different
<mvo> cwayne: indeed, I double check
<zyga> mvo: question about sergio's scripts, <BRACH> is the snapd branch?release/2.37?
<mvo> zyga: he has examples
<zyga> I'm jumping through the maze of includes
<mvo> zyga: but its more like a TAG
<mvo> zyga: yeah, the layout is a bit unconventional :)
<zyga> k
<zyga> thanks
<mvo> zyga: I had very good results just following the examples
<zyga> it's running now ... let's see
<zyga> core doesn't like motd: /etc/update-motd.d/50-motd-news: 59: /etc/update-motd.d/50-motd-news: cannot create /var/cache/motd-news: Read-only file system
<mvo> zyga: hm, we killed motd on core I thought
<zyga> not that hard apparently
<zyga> where should the bugs go?
<zyga> we still have /etc/update-motd.d/50-motd-news
<zyga> we actually have more
<zyga> -rwxr-xr-x 1 root root 1220 Apr  9  2018 00-header
<zyga> -rwxr-xr-x 1 root root 4264 Aug 19 23:44 50-motd-news
<zyga> -rwxr-xr-x 1 root root  348 Jan 30 05:01 60-unminimize
<mvo> zyga: meh, I think we need to kill that
<zyga> it's in /etc, I hope that's not another writable-dirs hell
<zyga> 2019-01-30 15:19:34 WARNING: external:ubuntu-core-16-arm-64 (external:ubuntu-core-16-arm-64:tests/main/failover:rclocalcrash) running late. Current output: ... <- feels this guy got stuck
<mvo> zyga: uh, apparently that happend to pstolowski as well - sounds like we need to look into this why its fragile
<zyga> mvo: another random error observation, pam complains about Jan 30 14:08:45 localhost login[2870]: pam_env(login:session): Unable to open env file: /etc/default/locale: No such file or directory
<zyga> mvo: tests failed
<zyga> http://paste.ubuntu.com/p/D699fhS5BK/
<zyga> it looks like
<zyga>  real issue /home/gopath/src/github.com/snapcore/snapd/tests/lib/boot.sh: line 33: fw_setenv: command not found
<pstolowski> zyga: i saw that a lot
<zyga> https://www.irccloud.com/pastebin/uSQ850Vs/
<mvo> zyga: woah
<mvo> zyga: is thre /etc/default/locale?
<zyga> no
<zyga> mvo: where should I report those
<zyga> irc doesn't work well
<zyga> core18 github?
<pedronis> pstolowski: btw what did we conclude about spread tests for hotplug?
<pstolowski> pedronis: i've something based on groundwork set by Sergio (nested vm tests), a simple scenario with virtual serial port worked, but it will require some effort still
<pedronis> pstolowski: ok
<pstolowski> mvo: doh, you won't believe what prevented ssh-agent from working for me
<mvo> pstolowski: I'm curious now :)
<mvo> zyga: yeah, core18 github
<zyga> mvo: thank you, on it
<pstolowski> mvo: i had two rsa keys, one very old and unused (i don't even remember what it was); it was also very weak; turns out just having it around caused an issue; got rid of it and ssh agent is now happy about the other key and doesn't prompt for password anymore
<mup> Issue core18#117 opened: update-motd is installed but cannot operate on read-only / <bug> <Created by zyga> <https://github.com/snapcore/core18/issue/117>
 * zyga -> tea and lunch
<mborzecki> #6252 is green now, yay
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<pedronis> mvo #6453 needs a 2nd review
<mup> PR #6453: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs â> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6453>
<pedronis> Chipaca: 6452 is green
<mvo> pedronis: in a wee bit
<pedronis> mvo: np, pointing to it because it would go in 2.37.2
<Chipaca> pedronis: whee
<mup> PR snapd#6452 closed: overlord/snapstate: format the refresh time for the log <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6452>
<mvo> pedronis: sounds good
<zyga> re
<Chipaca> brb, walking the dog for a bit
<zyga> mvo: it's not a regression but core18 has a real bug
<mvo> zyga: which bug? the motd?
<zyga> no, the fw_printenv, hold on
<zyga> https://github.com/snapcore/core18/issues/118
<mup> Issue core18#118 opened: fw_printenv is not present in core18 <bug> <Created by zyga> <https://github.com/snapcore/core18/issue/118>
<mvo> zyga: aha, right
<mvo> zyga: yeah, I wonder why we did nto notice - oh well. we need to fix it so that we can run the tests. we could even bring it in as a snap or provide an internal command (we have support to write uboot)
<zyga> it feels like a core18 or a gadget binary
<zyga> it's not great that we didn't notice before release
<mvo> zyga: well, I think its only needed for tests
<zyga> I'm not familiar with how we use that binary to say where it belongs
<mvo> zyga: I'm 99% sure
<zyga> mvo: if it is just for tests that's not bad then
<mvo> zyga: yeah, we would be in trouble otherwise
<zyga> but also means nobody noticed?
<zyga> that is, we released ignoring or not testing that
<mvo> zyga: yeah, thats the part that is concerning
<mvo> zyga: correct
<zyga> I will file more bugs
<zyga> took a break, got some cold/flu meds
<zyga> feeling better now
<mvo> zyga: well, what test was this?
<mvo> zyga: I am running tests here right now on a dragonboard
<mvo> zyga: and they are passing so I wonder *why*
<zyga> as core18 or core16?
<mvo> zyga: maybe we exclude some tests somewhere for the wrong reasons (systems: [-...])
<mvo> zyga: aha, sorry - this one runs on core16
<zyga> right
<mvo> zyga: I will restart on core18 once this is done
<zyga> it's not broken on core18
<mvo> zyga: sorry !
<zyga> we should generate a diff between file list of core and core18
<zyga> mvo: it is likely pawel saw the same issue on pi
<zyga> pstolowski: which raspberry pi model did you use and which snapcraft model did you use?
<zyga> I amended the bug report with more details
<pstolowski> zyga: pi3 model b v1.2, 2015
<zyga> mvo: there's no snapcore/dragonboard-kernel
<zyga> where should those bug reports go?
<pstolowski> zyga: what do you mean by snapcraft model? i just built beta images following the guide, with a script
<zyga> pstolowski: snap known model
<zyga> what does that say on your device?
<pstolowski> ah, let me check
<zyga> mvo: we only use fw_setenv for testing, that's okay then
<mvo> zyga: yeah, we still need to make sure how to get that in the tests and figure out why we didn't notice this before
<cwayne> This sounds like a reason for us to do this full beta image testing in our lab as well
<mvo> cwayne: indeed
<mvo> cwayne: having nightly runs against edge for pi3/db for core and core18 would be awesome
<oSoMoN> hey jdstrand, https://forum.snapcraft.io/t/the-u2f-devices-interface/9722 mentions 2.37+, yet the interface is not in 2.37.1, is that an oversight?
<pstolowski> zyga: my pi3 system is borked, snapd daemon doesn't respond to client anymore :(
<zyga> that's ok
<zyga> which image did you flash?
<pstolowski> zyga: pi3-18-beta
<zyga> pstolowski: thank yo
<zyga> you*
<zyga> so that's that, the same bug is present across core18 devices
<zyga> mvo: this is double worrying now, it means core18 was not really tested?
<zyga> it would not have passed anywhere
<mvo> zyga: indeed it is, looking now
<zyga> mvo: I will restart core16 testing now
<mvo> zyga: core is the critical one
<mvo> zyga: but core18 (snapd) also needs to be promoted of course (but it has less users at this point)
<mvo> zyga: anyway, I am building a core18 beta now to see if what we can do
<zyga> flashing in progress
<mvo> I run fresh-install-pi3-core18 now
<zyga> mvo: dragonboard doesn't power off, it reboots
<zyga> where should I report that?
<zyga> booting core16
<mvo> zyga: hm, foundations or kernel I would say
<zyga> mvo: URL? :-)
<zyga> I wish we had one for each part of ubuntu core
<mvo> zyga: if kernel ppisati might know why a dragonboard would reboot instead of powerdown
<zyga> github.com/snapcraft/dragonboard-kernel
<mvo> zyga: +1
<pedronis> mvo: we really need to review what we run with core18
<mvo> pedronis: indeed - this is still puzzling, I'm running pi3 core18 now here to see what I get
<mvo> but of course arm is not run as part of the normal spread
<zyga> mvo: I feel weird because I have a feeling _we_ ran the validation tests for core18
<mvo> so its plausible that the full suite was not run yet on arm for core18 - if so we really need to make sure to fix that
<mvo> zyga: we do - the question is if we ever did that for arm
<mvo> zyga: anyway, hopefully I hvae some data points and an image to poke around soon
<zyga> mvo: I mean, that you and me were running core18 tests
<zyga> mvo: and that we did include pi
<zyga> Press enter to configure.
<zyga> /usr/share/subiquity/console-conf-wrapper: line 62: read: read error: 0: Resource temporarily unavailable
<mvo> zyga: that is something that mwhudson might be interessted in
<zyga> mvo: this time I managed to connect, I'll start tests now
<mup> PR snapd#6453 closed: snap: fix hook autodiscovery for parallel installed snaps <Parallel installs â> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6453>
<diddledan> https://snapstats.org/
<diddledan> ^^^ I made a thing!
<zyga> diddledan: https://snapstats.org/bases seems inaccurate
<zyga> diddledan: look at hello-fedora
<diddledan> that's purposely stripped because it's a hello-world snap
<zyga> something that should be mentioned
<zyga> is the logo use official?
<diddledan> no it isn't
<diddledan> I am just putting a disclaimer about that
<popey> https://www.irccloud.com/pastebin/SOj5dhP7/
<popey> ^ zyga
<zyga> fedora29 was not pushed to stable
<zyga> that's why,
<popey> so maybe unpublish hello-fedora from stable?
<zyga> I'll publish the base snap
<jdstrand> oSoMoN: oh, I thought it made it. I suspect it will be in 2.37.2 then. mvo, fyi u2f-devices is not in 2.37.1
<pedronis> mvo: 6453 needs a backport, right?
<oSoMoN> jdstrand, ack
<pedronis> jdstrand: correct
<pedronis> backport is still up for merging together with other bug fixes
<mvo> pedronis: correct, I added a card for 6453
<mvo> jdstrand: sorry for that, iirc there is a question/issue in the PR
<mvo> jdstrand: yes, will be in .2
<jdstrand> mvo: I thought all questions were resolved which was why it made it to master. let me know if I should do anything else
<mvo> jdstrand: its just that it looks like this PR squashed all the commits in to a single one but it landed in master as 5 individual commits iirc
<mvo> jdstrand: so if we merge it this way into 2.37 next time there will be unneeded conflicts when merging 2.37 -> master again
<mvo> jdstrand: https://github.com/snapcore/snapd/pull/6434#pullrequestreview-196909893 - but please do let me know if I misremember/misread
<mup> PR #6434: interfaces: add u2f-devices interface (2.37) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6434>
<jdstrand> mvo: oh! I did that together for a nicer git log for 2.37. is it better if I cherry-pick?
<zyga> Error executing external:ubuntu-core-16-arm-64:tests/main/interfaces-daemon-notify https://www.irccloud.com/pastebin/M7vCiVNk/
<mvo> jdstrand: yeah, with the cherry picks git should be able to work out that this patch was already applied before - squashing it will result in conflicts if its merged back. I can double check, maybe git got smarter over the years though
<mvo> zyga: yeah, I think sergio has a PR for this, once sec, let me try to find it
<mvo> zyga: I think we need to cherry pick https://github.com/snapcore/snapd/pull/6394
<mup> PR #6394: tests: iterate getting journal logs to support delay on boards on daemon-notify test <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6394>
<zyga> mvo: ah, nice
<mvo> zyga: the good news is its a test-only thing, no real issue
<zyga> yes
<jdstrand> mvo: let me just make your life easier and create a new PR
<zyga> mvo: daughter interrupt (not that daugther)
<zyga> mvo: I will promote after this test finishes and it feels like an hour away
<mup> PR snapcraft#2454 opened: baseplugin: add a proper exception for cross-compilation support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2454>
<mvo> zyga: thank you
<mvo> zyga: my 2019-01-30 20:18:32 Executing external:ubuntu-core-18-arm-32:tests/core18/snapd-refresh (232/232)...
<mvo> zyga: is almost done but that is only relevant for the snapd snap candidate promotion
<mup> PR snapcraft#2453 closed: ant, maven and gradle plugins: use correct defaults for jre <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2453>
<mvo> zyga: strange things - I ran the ubuntu-core-18-arm-32 suite from a fresh image and did not see the fw_setenv error - in what test did you had this error? fwiw, my full log is at http://paste.ubuntu.com/p/vdmNJDPzBf/
<mvo>  
<zyga> I added that to the log
<zyga> Can you see fw_setenv on PATH?
<zyga> (I meant I added that detail to the bug report)
<mvo> zyga: I have not logged into the machine, just observed tehat the test did not fail, looking now
<mvo> zyga: hm, no fw_printenv on uc18
<mvo> zyga: ok, so this is curious - when I grep the tree for "fw_printenv" I see it used in the "bootenv" shell function - this is only used in main/core-snap-refresh-on-core/task.yaml  main/core-snap-refresh/task.yaml  main/failover/task.yaml  main/kernel-snap-refresh-on-core/task.yaml  main/ubuntu-core-upgrade/task.yaml and those are all only running on ubuntu-core-16-*
<mvo> zyga: maybe accidently the uc16 tests were run on a uc18 system?
<pstolowski> mvo: it's possible in my case, i accidently run tests earlier with dev_snapd_pi argument instead of dev_snapd_pi_18
<mvo> pstolowski: sounds plausible
<mvo> pstolowski: no worries
<pstolowski> mvo: nb, i reflashed and have been running the tests for last 2hrs (225/232 atm) and for the first time it looks it's going somewhere. not sure what changed
<mvo> pstolowski: \o/
<mvo> pstolowski: sounds encouraging - which test case is that?
<pstolowski> mvo: core18/snapd-refresh
<mvo> pstolowski: nice
<pstolowski> fingers crossed for pastebin at the end..
<mvo> yeah
<zyga> Iâm still with my daughter
<zyga> I ran the script from the tree, using âdbâ name
<pstolowski> mvo__ my tests just finished - 4 failures - http://paste.ubuntu.com/p/JjP9dcMfQt/
<pstolowski> mvo__: but i see you run fresh install for pi3 as well
<zyga> I will be back in 45 minutes :/
<mup> PR snapcraft#2455 opened: cli: retrieve error data from provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2455>
<zyga> Letâs see ...
<zyga> dragonboard core16 tests are good
 * zyga EOds
<diddledan> zyga: I swapped out the snapcraft logo for one of my own creation on snapstats.org
<roadmr> diddledan: then your footer doesn't need to say "The Snapcraft logo is copyright Canonical Limited." anymore, does it? :)
<diddledan> true
<Chipaca> sergiusens: o/
<sergiusens> Chipaca: hey!
<Chipaca> sergiusens: is that test failing on master as well, or only on that pr?
<sergiusens> Chipaca: only on that PR, the thing diddledan did was just convert our schema.yaml to json
<Chipaca> sergiusens: right
<Chipaca> sergiusens: those error messages are only different in whitespace (one of them is wrapped)
<Chipaca> sergiusens: on master, that test uses Equals
<Chipaca> sergiusens: and I don't see anything in that PR that changes it to use a different checker
<Chipaca> so it's using Equals
<Chipaca> and... they aren't equal :-)
<sergiusens> Chipaca: I see this now, in the yaml, it is a continous string and in the json diddledan added \n in the message, we should remove the \n from there
<Chipaca> yeah, that's the wrong place to \n
<Chipaca> :-)
<mup> PR snapd#6454 opened: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6454>
<mup> PR snapd#6455 opened: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6455>
<mup> PR snapcraft#1905 closed: Remove dangling symlink from JDK plugin (LP Bug #1617296) <Created by ARostovsky> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1905>
<mup> PR snapcraft#2446 closed: Update schema/snapcraft.yaml <Created by diddledan> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2446>
<mup> PR snapcraft#2389 closed: repo: run `apt update` before `apt install` <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2389>
<mup> PR snapd#6456 opened: interfaces: add network-manager-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6456>
<mup> PR snapd#6457 opened: interfaces: add network-manager-observe interface (2.37) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6457>
#snappy 2019-01-31
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> 47 PRs
<mvo> mborzecki: indeed, looking good
<mup> PR snapd#6434 closed: interfaces: add u2f-devices interface (2.37) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6434>
<mup> PR snapd#6458 opened: snapd,state: improve error message on state reading failure <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>
<mborzecki> mvo: about #6458, did that happen often in your tests?
<mvo> mborzecki: just once
<mup> PR #6458: snapd,state: improve error message on state reading failure <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>
<mborzecki> mvo: error message will certainly be useful, i recall we had a case in the forums where state.json was corrupted and the contents were actually part of some other file :/
<mvo> mborzecki: yeah, its not super helpful but at least it gives people a clue
<mvo> mborzecki: error: EOF is really saying nothing :/
<mborzecki> mvo: we could have done worse, eg 'error: failed' :)
<mvo> heh: "error: computer says no"
<mvo> mborzecki: we should probably have noticed that the error is not great when writing the unit test with the error - oh well
<mup> Issue core18#118 closed: fw_printenv is not present in core18 <bug> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/core18/issue/118>
<mborzecki> mvo: #6417 can be landed now?
<mup> PR #6417: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6417>
<mvo> mborzecki: yes, good catch
<mup> PR snapd#6417 closed: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6417>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> good morning pstolowski
<mwhudson> when did /v2/find?name=foo start including information on whether the publisher was verified?
<mwhudson> must be a while ago
<pstolowski> mvo: will do beta validation core18 - upgrade pi3
<mvo> pstolowski: thank you
<pedronis> mwhudson: quite a while ago, yes
<pedronis> mwhudson: https://forum.snapcraft.io/t/how-to-display-account-names-and-usernames/4007/4
<pedronis> mvo: comment on 6458
<mup> PR snapd#6459 opened: tests: iterate getting journal logs to support delay on boards on daemon-notify test (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6459>
<mvo> pedronis: thanks, checking
<mup> PR snapd#6460 opened: snap: fix hook autodiscovery for parallel installed snaps (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6460>
<mvo> pedronis: ta
<mup> PR snapd#6454 closed: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6454>
<mup> PR snapd#6455 closed: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile (2.37) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6455>
<mvo> mborzecki: thanks for your reviews btw :) really appreciated
<mborzecki> mvo: had some suggestions in #6456, actually made me revisit gio again
<mup> PR #6456: interfaces: add network-manager-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6456>
<pedronis> do we know why is targeted at 2.37
<mvo> mborzecki: yeah, I saw that, its great feedback
<pedronis> it's a full new interface
<mvo> pedronis: probably just because jamie wants it there and its low regression risk
<mvo> pedronis: not sure if there is more to it, it seems he is doing that for most of his interface PRs
<pedronis> not completely a fan tough
<pedronis> when is this interface supported
<pedronis> 2.37.2
<pedronis> not a nice answer
<mvo> yeah, trouble is if we push it into .38 and there is a .2 then .38 will be delayed by ~2w or so and I guess jamie does not like that
<pedronis> mvo: what if it's broken in some ways
<pedronis> do we do a 2.37.3 ?
<pedronis> I marked it blocked for now
<pedronis> I would like to understand
<pedronis> the urgence
<mvo> pedronis: thats fine
<pedronis> mvo: notice that there is no real spread test for this thing afaict
<pedronis> mvo: we already added in u2f-devices in .1 right?
<mborzecki> anyone updated go to 1.11.5 ?
<pedronis> or is it for .2?
<pedronis> mvo: as I said I find a bit problematic that these things don't come with real tests
<mvo> pedronis: right - we should discuss this with jdstrand then - maybe we can offer help with this when sergio is back. we had no hard rule about it so far :/
<pedronis> mvo: I don't have a strong opinion, but merging them late and not tests doesn't seem a good combo
<mvo> pedronis: *nod*
 * zyga crawled to his laptop
<zyga> I will be off today
<mvo> zyga: get well!
<pedronis> zyga: get well!
<pedronis> mvo: but yes, a chat with jdstrand seems good
<pedronis> mvo: can we create a 2_38 tag in the forum
<pedronis> mvo: for example for this: https://forum.snapcraft.io/t/risk-only-channel-requests-vs-pinned-default-tracks/9332
<mvo> pedronis: sure
<mvo> pedronis: done
<pedronis> mvo: thank you
<mup> PR snapd#6459 closed: tests: iterate getting journal logs to support delay on boards on daemon-notify test (2.37) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6459>
<mup> PR snapd#6458 closed: snapd,state: improve error message on state reading failure <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6458>
<kissiel> mvo: hey! got a minute? I'd like to close that thread about checkbox crash you had couple of days ago. First of all, I think I fixed it - python wheel present on PyPI had some no longer supported syntax in its metadata. I removed it, and released a newer version that snaps fine. I modified the part accordingly in that test snap definition
<kissiel> (https://github.com/kissiel/snapcraft/commit/8d5b91a3dd398d224a9d957344613401a2266570)
<kissiel> mvo: but from what I can tell, that test was disabled since Oct '18. So that patch also re-enables it.
<kissiel> mvo: makes sens? shall I propose that PR?
 * Chipaca takes a break
<pstolowski> mvo: hey, thanks for refactoring of canInstallSnapdSnap, it's intention is now much cleaner! i'm still slightly confused though about what we want vs what's in the description of the PR (I'm probably missing something) - it seems we will transition automatically if base/model exists, regardless of the experimental flag, and the flag will only be used with other models. is that intended?
<mvo> pstolowski: its a good point you raise. all current models that use a base snap also have the snapd snap - however it is confusing so I will look if this can be expressed better. maybe the canInstallSnapdSnap is already too much - it mixes two things which is probably shouldn't (can-it-be-installed and should-it-be-installed is mixed)
<mvo> pstolowski: I pasted your comment into the PR
<pstolowski> mvo: right, thanks!
<pedronis> mvo: I do plan to start looking at your big PRs today and tomorrw btw, I added myself to them
<mvo> pedronis: thank you
<pstolowski> mvo: 1-1?
<mup> PR snapd#6460 closed: snap: fix hook autodiscovery for parallel installed snaps (2.37) <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6460>
<pstolowski> mvo: ah, false alarm, it's tomorrow ;)
<pstolowski> sorry
<mvo> pstolowski: :)
<mvo> pstolowski: no worries
<pedronis> Chipaca: hi, could you review when you have a moment the last commint in #6415
<mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<mup> PR snapd#6461 opened: snap-confine: provide proper error message on sc_sanity_timeout <Created by mvo5> <https://github.com/snapcore/snapd/pull/6461>
<mup> PR snapd#6462 opened: snap-confine: fix incorrect "sanity timeout 3s" message <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6462>
<Chipaca> pedronis: did you see my comment in that one?
<pedronis> Chipaca: it didn't sound a blocker, tough? it's orthogonal no?
<Chipaca> pedronis: ye
<pedronis> Chipaca: does it still have your +1 ?
<Chipaca> as i said i would, i added a card :-)
<pedronis> that's my question
<Chipaca> pedronis: it's even got an extra +1 for good measure
<mup> PR snapd#6463 opened: [RFC] snap-confine: increase locking timeout to 30s  <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6463>
<zyga> mvo: fyi, indent is unstable across systems
<pedronis> Chipaca: thx
<Chipaca> mvo: which indent?
<pedronis> Chipaca: the C(++) formatter
<pedronis> I think
<mborzecki> zyga: mvo: we have a make target to call clang-format
<zyga> we have one
<zyga> read the makefile.am, there are two sets of files
<zyga> one formatted with indent
<zyga> other with clang-format
<zyga> both are unstable though
<zyga> so it's just what you prefer, I guess
<zyga> note: clang-format is 10x better
<pedronis> Chipaca: me is confused, isn't the order of channels in that message wrong
<zyga> so over time we will switch
<pedronis> ah, no
<mborzecki> pedronis: which message?
<pedronis> mborzecki: nvm
<leinardi> Hi, I'm still trying to distribute GWE with Snap but I'm stuck with this error: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/11
<leinardi> any idea of what is the issue?
<pstolowski> mvo: finished upgrade tests on rpi3, 2 failures http://paste.ubuntu.com/p/BmsVGpgTMF/ , both we had seen yesterday already
<zyga> leinardi: replied
<pedronis> pstolowski: btw, now that we switched to newer gos, we need to try to go back addressing the EnsureBefore issues
<pstolowski> pedronis: right, great
<pstolowski> will re-visit it
<pedronis> pstolowski: thx
<mborzecki> off to pick up the kids
<jdstrand> oSoMoN: ok, u2f-devices will be in 2.37.2 (pr committed thanks to mvo)
<jdstrand> pedronis (cc mvo): added PR 6457 for 2.37 in case you could accept it. it is fine if you don't. Adding new interfaces is low risk imho because nothing can regress cause nothing uses it. added that one cause it is of interest to kde and thought it would be nice for them instead of waiting N weeks
<mup> PR #6457: interfaces: add network-manager-observe interface (2.37) <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6457>
<jdstrand> mborzecki: thanks for the feedback btw. I'll adjust
 * jdstrand added a bunch of interfaces for 2.37 last week
<jdstrand> so just did this the same. if you don't want it, nak it. that's fine
<pedronis> jdstrand: my problem is if they have bugs, and they typically don't come with deep tests, to they create a need for more .x , pushing the next release further
<pedronis> jdstrand: it's a balance basically
<jdstrand> pedronis: imho it would only have a profiling bug. we would not do a 2.37.3 just for it. profile fixes for 2.38
<jdstrand> which is part of why I did it this way-- get it out sooner for feedback. I mean, if it works perfect great, if not, iterate in the next release
<pedronis> jdstrand: .x don't stay around a lot in testing
<jdstrand> but again, I'm not pushing for 2.37. it is there as a discussion point. if you don't want it, fine
<pedronis> jdstrand: they can test things using edge
<pedronis> btw
<pedronis> so it's not so clear why they would need stable
<pedronis> mvo: you said you have further changes planned for #6404 because of feedback, right?
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<jdstrand> pedronis: don't feel pressure to say yes. I was only expressing my reasoning :) tbh, I didn't release dot releases got less verification
<jdstrand> realize*
<pedronis> jdstrand: well, the assumption is that they have targeted content to fix bugs
<pedronis> adding features defeats that
<pedronis> also at some point just the mechanics of landing things delays them a bit
<pedronis> jdstrand: also the main PR for master got questions/comments
 * jdstrand nods and is addressing that now
<pedronis> jdstrand: I closed the 2.37 one
<mup> PR snapd#6457 closed: interfaces: add network-manager-observe interface (2.37) <â Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6457>
 * jdstrand nods
<oSoMoN> jdstrand, mvo: re- u2f-devices in 2.37.2, many thanks!
<mvo> pstolowski: thanks for the test-run
<mvo> pedronis: 6404> yeah, iirc I wanted to add some more tests, need to look at the pr again though
<Chipaca> pedronis: I'm seeing a lane having tasks with status that's a mix of Done, Undone, and Error
<Chipaca> in tests, to be clear
<Chipaca> pedronis: looks like I'm either missing to do something in the test, or the lane checker needs to be smarter
<mup> PR snapd#6461 closed: snap-confine: provide proper error message on sc_sanity_timeout <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6461>
<Chipaca> not sure if I should make the tests more involved though
<pedronis> Chipaca: me confused
<pedronis> Chipaca: I misread your code?
<pedronis> Chipaca: just a lane did not succeed
<pedronis> s/just/such/
<pedronis> but is ready
<Chipaca> pedronis: right, but then I was expecting all tasks on a non-successful lane to be non-Ready
<Chipaca> ie either Undone or Hold
<Chipaca> er, not non-REady, i meant non-Done
<pedronis> Chipaca: you can really only check the reverse
<pedronis> everything DOne
<pedronis> == success
<pedronis> anything else
<pedronis> not
<Chipaca> sigh
<Chipaca> ok
<pedronis> sorry, I tought that was what the code was doing
<pedronis> I misread, read too quickly
<pedronis> I suppose
<pedronis> anyway
<Chipaca> whoops, standup, omw
<pedronis> jdstrand: hi, did you see my question about the serial-port logic in https://forum.snapcraft.io/t/allowing-interfaces-to-disable-device-cgroup-udev/9630/11 ?
<pedronis> jdstrand: seems hidraw is also like that
<jdstrand> pedronis: I did and I responded (note, you typically do not need to ping me unless it is urgent since I read all forum mail; it's possible I might miss something, so if I don't after a little while, feel free to ping)
<mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
<mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
<sergiusens> plars: hey, about snapcraft 3.1 hitting candidate, did anything get triggered incorrectly on your side?
<sergiusens> plars: this is what I am talking about btw https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-1/9712
<plars> sergiusens: I can take a look... usually no news is good news on those tests, but it never hurts to check
<sergiusens> plars: yeah, never hurts, if you don't mind adding a comment on that post when verified, that would be grand
<plars> sergiusens: apparently we are still stuck on an earlier version because we still depend on remote parts
<sergiusens> ah, ok
<cwayne> Which we're looking into fixing
 * zyga waves 
<zyga> I feel a bit better, slept for most of the day
<zyga> mvo: I hope to be operational tomorrow
<mvo> zyga: cool, yeah, rest and lets sync tomorrow then
<cwayne> ah, feel better soon zyga
<zyga> thanks guys!
<mwhudson> hm
<mwhudson> how does version: git in snapcraft.yaml know which of the two git repos my snap is built out of to use?
<mwhudson> and can i make it use both of them somehow
<Chipaca> mwhudson: adopt-info: <some part> tells it to use the version from that part
<Chipaca> mwhudson: do you have two git repos in the same part?
<mwhudson> Chipaca: no, separate parts
<Chipaca> mwhudson: and you have an adopt-info: <blah> somewhere?
<mwhudson> no
<mwhudson> i had never heard about adopt-info: until now :)
<Chipaca> mwhudson: snapcraft uses it: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml
<Chipaca> mwhudson: but I'm not sure this is what you want
<Chipaca> sergiusens: what would you suggest?
<Chipaca> sergiusens: (to have the version of a snap built from combining the versions from two git sources in two parts)
<mwhudson> i guess i can do a version-script or whatever it is called
<mwhudson> relatedly
<mwhudson> is there an easy way to rebuild the snap when either git branch changes?
<mwhudson> that's more a launchpad question i guess and i bet the answer is "no"
<sergiusens> mwhudson: if you use build.snapcraft.io and host on github, change detection should just work
<sergiusens> mwhudson: about `adopt-info`, that's documented here https://docs.snapcraft.io/extracting-information-from-sources-in-snapcraft-parts/4642
<mwhudson> sergiusens: can't use bsi because of that thing about collaborators iirc
<sergiusens> mwhudson: collaborators? As in you do not have ownership as it belongs to Canonical? I would talk to Saviq as multipass uses build.snapcraft.io and it is under Canonical
<mwhudson> ah maybe that is fixed now
#snappy 2019-02-01
<mup> PR snapcraft#2456 opened: plugins: add colcon plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2456>
<mborzecki> morning
<mup> PR snapd#6462 closed: snap-confine: fix incorrect "sanity timeout 3s" message <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6462>
<mup> PR snapd#6463 closed: snap-confine: increase locking timeout to 30s  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6463>
<Saviq> sergiusens, mwhudson: I believe we got the multipass build going on bsi before we moved it under Canonical, and yeah last I checked it wasn't possible to set up a build if you were only a collaborator
<zyga> Hi
<Saviq> moaning
<mvo> hey zyga ! good morning
<mvo> hey Saviq
<zyga> Good morning
<mborzecki> zyga: mvo: Saviq: hey guys
<mborzecki> zyga: feeling better today?
<zyga> mvo: so-so, I was just thinking if I should be off and back in bed to be on the safe side
<mvo> mborzecki: good morning
<mvo> zyga: sure, do it
<zyga> mvo: I was thinking about the timing issue yesterday
<zyga> mvo: I will investigate one aspect and then probably just quit (I'll file paperwork for both days)
<zyga> mvo: there's a reliable way to trigger the issue
<mvo> zyga: sure
<mvo> zyga: oh?
<zyga> mvo: I want to see what happens now with 2.37.x as far as systemd is concerned
<zyga> mvo: sure, just put a long sleep in the main process after forking the helper
<zyga> mvo: if there's a difference to 2.36 I will look at patching that
<mvo> zyga: aha, I see
<Saviq> zyga: "put a long sleep... after forking..." that's re: your day off, is it? ;)
<zyga> haha
<zyga> fork & exec and then I will be off ;)
<zyga> (for a few days at least)
<pstolowski> morning
<mborzecki> pstolowski: hey
<pedronis> pstolowski: hi, couldn't the doHotplugAddSlot bit be separated out in a PR before being used?
<pstolowski> pedronis: hi, yes it could, i wasn't sure if we want to separate further. shall i do this?
<pedronis> pstolowski: yes, but I left a comment there as well, one sec
<pedronis> pstolowski: ok, added one comment
<pedronis> (for now)
<pstolowski> pedronis: km thanks
<mup> PR snapd#6456 closed: interfaces: add network-manager-observe interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6456>
<ogra> sil2100, hey ho ... do you currently use ubuntu-image to create the classic pi images (and a gadget for classic) ?
<sil2100> ogra: yeah, pi3 for now, and using currently a slightly modified gadget tree for classic
<sil2100> ogra: (we want to merge it into one gadget repo in the next iteration)
<sil2100> I hope waveform will help with that ;)
<ogra> sil2100, do you have the gadget code public ... ?
<sil2100> ogra: sure, it's used in our daily builds so yes
<sil2100> https://github.com/CanonicalLtd/pi3-gadget/tree/classic
<ogra> thanks !
<sil2100> ogra: it has some messy bits right now (some hacks to workaround various missing pieces here and there) and well, the custom classic bootscript is very simple as we didn't have time to create one that would do our things for both classic and core
<sil2100> I blame it on time constraints of course
<ogra> sil2100, uh, why did you re-inroduce boot.scr ? took us years to get that fixed upstream to allow uEnv.txt files
<sil2100> ogra: yeah, so that was not the best decision I made, we'll be going back to using uenv soon, I used boot.scr because: a) that's what ryan's pi3 classic images used and b) that's what flash-kernel upstream was using for the pi3
<ogra> wow, that code is miles apart from the core gadgets
<sil2100> But yeah, it's something we'll change back in the nearest weeks
<sil2100> Which part of the code? ;)
<ogra> Makefiles instead of letting snapcraft do everyrthing (i.e. only a snapcraft.yaml) ... boot.scr ... copying blobs around instead of building from source
<sil2100> ogra: yes, the Makefile and copying blobs is all that will go 'upstream'
<sil2100> ogra: we can't use snapcraft to do all the things because snapcraft is in universe, and we need to build the gadget trees in our livefs builders (livecd-rootfs)
<sil2100> ogra: and we need to pull all the blobs from the archive as everything we build officially for classic should use existing binaries from the archive, not building them 'in place'
<ogra> oh, and you cant use the snapcraft snap during build either ?
<sil2100> No, since livecd-rootfs needs to only use debs, we're not relying on snaps in any point of our image build process
<ogra> oh my ... yeah, then that setup is probably best
<sil2100> So I had to switch to a Makefile, which made things eh, very complicated
<ogra> yep, i know what you mean
<sil2100> The boot.scr is a mistake, I know ;p
<ogra> my "getting in touch with snaps" was exactly the other way around ... everything was a Makefile ... nowadays everything is just snapcraft.yaml
<sil2100> I was going back and forth with that one sadly
<ogra> yeah, its not easy
<ogra> in core its a bit better since we need to pre-build the whole environment as an image
<sil2100> First I used uenv like core, but then saw flash-kernel and our unofficial images and well, switched, but that's actually not what we want - and it was already a bit too late then
<ogra> so no need for a boot.scr, all customization happens when the env is created
<ogra> core only used uEnv.txt in 15.04
<ogra> we quickly moved to a full environment build
<sil2100> Yeah, and we need to have a common scenario for both core and classic, so I'll switch back to u-boot.env
<ogra> makes everything easier to maintain :)
<ogra> sil2100, BTW, why do you build separate images, you could have a single universal Pi image that runs on all Pi's we support (at least for armhf ... arm64 only for all Pi3 models)
<Chipaca> mvo: o/
<Chipaca> mvo: two things for you (ish?)
<Chipaca> mvo: one, https://forum.snapcraft.io/t/the-road-to-core18/5547/24
<Chipaca> mvo: two, https://forum.snapcraft.io/t/cant-set-permission-set-hardware-observer/8695/6
<ogra> sil2100, (note i dont want to mimic adam smith :P ... just an interest question)
<sil2100> ogra: that's the plan as well! Right now they're called pi3 images, but we're pretty confident that the pi3 armhf images we have will just work on the pi2
<sil2100> ogra: but we don't brand them that way yet as we didn't commit to making sure that's really the case
<waveform> ah, more reading (have not come across uEnv.txt yet!)
<sil2100> ogra: for now we're only concentrating on making the pi3 arm64 one working
<ogra> sil2100, https://www.raspberrypi.org/documentation/configuration/config-txt/conditional.md should be interesting ... you can use conditionals in config.txt to switch to the right u-boot/kernel.img based on the HW the first stage bootloader detected
<sil2100> waveform: hah! Well, we'll be just using u-boot.env in our case, just like the core snap
<waveform> I shall be testing on "all the Pis" when I get a spare moment!
<waveform> ogra, yup - includes may be useful too (to avoid trampling users changes to config.txt)
<ogra> sil2100, thats what i use in my core universal Pi gadget ... https://github.com/ogra1/pi-kiosk-gadget
<sil2100> ogra: yeah, didn't use it but saw that in the config.txt of core18 gadgets, seemed nice and useful
<sil2100> ogra: we have that in the universal pi gadget for core18 as well, although a bit messy ;p
<ogra> waveform, ah, you are the Pi-guy ? welcome to the madhouse ;)
<mvo> Chipaca: thank you
<waveform> ogra, yup - surrounded by the things (and the madness :)
<sil2100> ogra: yes, waveform will make our Pi experience amazing ;)
<ogra> sil2100, because i initially wrote it :) i'm known for "messy but working, ... needs work" stuff ... you know me ;)
<sil2100> I guess we all have projects like that ;)
<ogra> yeah
<mup> PR snapd#6415 closed: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
<mup> PR snapd#6464 opened: [RFC] many: add simple performance measure tool mostly for firstboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/6464>
<mvo> waveform: nice - welcome!
<mvo> mborzecki: firstboot measure, the above is my RFC/idea how to get started, very simple but should give us something to start from (if pedronis  is happy with the initial shape :)
<mborzecki> mvo: ok, will look in a bit
<mborzecki> mvo: snap analyze-blame :P
<ogra> now that would be a thing
<ogra> !
<mvo> mborzecki: haha - I like that
<pedronis> mvo: I'm a bit worried you did that at all :)
<mborzecki> mvo: iirc zyga has a branch to collect some timing measures too, we closed it didn't we?
<zyga> yes
<zyga> I have it on github
<mvo> pedronis: its just a quick outline, promised I will not touch it more
<mvo> mborzecki: yeah, I reference to zyga PR
<zyga> specifically the ring buffer code is IMO good to merge
<mvo> mborzecki: zyga approached it from the other side, I think we need to agree on the shape first (with pedronis) then we can take those bits, YAGNI and all that
<mborzecki> yup, agreed
<mvo> zyga: yeah, there is a FIXME in there that point to the ringbuffer
<zyga> I started with the assumption that snapd should know timing data about any part of the stack
 * mvo really likes snap analyize
<zyga> k
<zyga> I didn't read any of the PRs
<pedronis> yes, don't carried away too much before I look at things
<mvo> zyga: its fine, no worries, I think we will need most of your stuff its just approaching it from the other direction
 * dot-tobias waves hello
 * Chipaca waves back
<Chipaca> pedronis: both my PRs are ready for re-reviews, if you're wondering what to do :-p
<mup> PR snapd#6465 opened: overlord/ifacestate: hotplug-add-slot handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/6465>
<pstolowski> pedronis: ^ it grew some extra tests not present in the main branch
<Chipaca> pedronis: unrelatedly, if I have a ClientSnapFromInfoSnap(*info.Snap) (*client.Snap, error), should I put it in cmd/ (next to the similar ClientAppInfosFromSnapAppInfos(apps []*snap.AppInfo) ([]client.AppInfo, error) ) ?
<Chipaca> it'd be used by daemon and cmd/snap
<pedronis> Chipaca: yes, seems those two need to be together
<pedronis> pstolowski: thanks, in my queue
<pedronis> pstolowski: are you blocked or are you looking again at EnsureBefore ?
<pstolowski> pedronis: yes, i'm looking at ensurebefore, not blocked
<pedronis> pstolowski: thx
<mborzecki> should we land #6422 and see if that makes the occasional mount issue on ubuntu-core-18 go away?
<mup> PR #6422: tests/prepare: prevent console-conf from running <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6422>
<pedronis> Chipaca: thanks, yes your PRs are likely the next things I look at
<mup> PR snapcraft#2438 closed: rust plugin: new link for rustup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2438>
<mup> PR snapcraft#2454 closed: baseplugin: add a proper exception for cross-compilation support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2454>
<dot-tobias> Struggling with cross-compilation in multipass VMs / snapcraft 3.x, super grateful for any âyou're holding it wrongâ hints: https://forum.snapcraft.io/t/snapcraft-3-x-cross-compilation-amd64-armhf-in-multipass-vm/9758
<mup> PR snapd#6426 closed: cmd/snap-confine: refactor and cleanup of seccomp loading <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6426>
<Chipaca> mvo: ping
<Chipaca> popey: ping?
<Chipaca> oh, fosdem
<Chipaca> fossdem?
<Chipaca> Wimpress: also fosdem?
<Wimpress> Chipaca: Hi
<Wimpress> Sorry, was head down. I'm available. Not a FOSDEM.
<Wimpress> I don't have anything to discuss, but if you've got something we can jump on a call?
<Chipaca> Wimpress: ah, er, I went off to prepare lunch (it's cooking rn), mvo did similarly i think
<leinardi> Hi, when I try to run my app from the snap I'm getting an error related to gnome-3-26-1604, even if I specified gnome-3-30-1804 and core18. Can someone give me some hints on how to fix this? More details here: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/17
<zyga> kenvandine: ^
<zyga> leinardi: you might need to wait for people from US time-zones to be up though
<kenvandine> Hey
<Chipaca> leinardi: are the connections ok?
<zyga> hey kenvandine :-)
<Chipaca> maybe we got the content interface plugged wrong or sth
<kenvandine> That message just means the content snap isn't mounted
<zyga> kenvandine: does 3-30-1804 exist?
<zyga> mvo: iterating on the regression test, it's trickier than it should perhaps :/
<kenvandine> zyga: it's only in edge and untested
<kenvandine> leinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-1804
<zyga> kenvandine: is there a plan to make it stable, 18.04 was shipped a while ago and core18 is a thing for a few weeks now
<kenvandine> we're shipping a bunch of snaps with gnome-3-28-1804 already
<kenvandine> if $SNAP/gnome-platform doesn't exist or is empty it prints out that error to connect it
<zyga> ah
<zyga> I missed 28 vs 30
<kenvandine> right now the scripts are hard coded to gnome-3-26-1604 for that print statement
<zyga> mborzecki: ^ it would be great if we had a way to get slot attributes via snapctl
<zyga> e.g. snapctl slot-info --print-attr=content "gnome-platform"
<zyga> so that a message like that doesn't have to be hard-coded
<mborzecki> zyga: hm iirc there's snapctl get --slot/--plug
<zyga> oh, I didn't know
<zyga> does it show stuff like attributes easily?
<zyga> I'm mainly after usability from shell
<mborzecki> idk
<Chipaca> zyga: you can just run it :-)
<Chipaca> error: error running snapctl: interface attributes can only be read during the execution of interface hooks
<Chipaca> I lied
<mborzecki> heh
<zyga> ~/go/src/github.com/snapcore/snapd/tests/regression/lp-1813963 $ snapctl get --plug :opengl
<zyga> error: error running snapctl: interface attributes can only be read during the execution of interface hooks
<zyga> not useful
<Chipaca> quoth the raven, Y THO
<mborzecki> poe rolling in his grave
<kenvandine> zyga: speed is very important there
<kenvandine> we don't want to slow down desktop-launch
<zyga> sure
<zyga> it should be zippy
<zyga> fast
<zyga> snappy even
<kenvandine> it needs to be as fast as checking for the contents of the directory :)
<zyga> sure but now it is fast but misleading
<Chipaca> right, the fast path yes, but if it fails you can be slower reporting the error
<kenvandine> but... it would be a big improvement
<zyga> it needs to be useful and fast
<kenvandine> ah
<kenvandine> good point
<kenvandine> we'll look at doing that in the gnome extension of snapcraft
<Chipaca> error handlers have all the time in the worldÂ¹
<zyga> good point
 * zyga recalls a special parser that has a fast path for correct code and a super-generic error path for any errors that is then causing re-parsing with a parser crafted for careful errors at the expense of longer parsing time
<Chipaca> in other news, cabbage does not shrink while cooking. I'm eating out of a bucket today.
<zyga> mvo: whee
<zyga> it passed
<zyga> man that was tricky
<leinardi> > <kenvandine> leinardi: Use gnome-3-28-1084 it probably has a newer gtk than gnome-3-30-1804
<leinardi> kenvandine, wait, so gnome-3.28.1804 actually has Gnome 3.30? I need 3.30, can't use 3.28
<kenvandine> they are both built from 18.04, gnome-3-30-1804 isn't a real thing yet
<kenvandine> it's not in stable because it's not complete yet
<kenvandine> and it will ultimately be built from the build snap, not the archive
<leinardi> so, there is no current way to get gnome 3.30 to work with snap? should I just wait to release my app with it?
<Wimpress> I've just installed `multipass` on a clean install of 18.10.
<Wimpress> Every multipass command I issue results in: `dropping privs did not work` which is an error being thrown by snapd-confine.
<Wimpress> Just want to know if this is a known issue before I got digging.
<Chipaca> zyga: ^
<zyga> Wimpress: no
<zyga> hmm hmm hmm
<zyga> Wimpress: I will check in a moment but can you please open a bug
<zyga> Wimpress: and attach
<zyga> SNAPD_DEBUG=1 multipass
<zyga> I will handle the rest
<Wimpress> Sure thing.
<pedronis> Chipaca: I did a review of #6356
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<Chipaca> pedronis: ta
<Wimpress> zyga: You can stand down. We have a case of use error.
<zyga> :D
<zyga> what did you do?
<Wimpress> I've just notice the terminal I was use is logged in as root.
<Chipaca> pedronis: the call to SetStatus needs to happen before the call to EnsureBefore, right?
<pedronis> Chipaca: no, doesn't matter, given you holding the lock
<Chipaca> k
<pedronis> Chipaca: we tend to do it last, lots of examples
<pedronis> in ifacestate
<Chipaca> pedronis: isn't the status set to done as soon as the handler returns with no error?
<pedronis> Chipaca: yes, but we release the lock in the middle of that
<pedronis> so not guarentee
<pedronis> that we get there
<abeato> jdstrand, hey, was wondering if you had seen my comment about NM controlling netplan: https://github.com/snapcore/snapd/pull/5915#issuecomment-454695004
<mup> PR #5915: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5915>
<sergiusens> Wimpress: hmm, multipass works fine on the current devel I am typing from
<kenvandine> leinardi: i can take another look at your snap in a bit, i'm in a meeting for the next couple hours
<Wimpress> sergiusens: It was user error on my part.
<jdstrand> abeato: I had and need to circle back to it (it is on my todo). thanks for the reminder
<abeato> jdstrand, great, thank you
<pedronis> abeato: which snaps need this? just our own NM?
<pedronis> jdstrand: fwiw I'm also thinking about this problem
<abeato> pedronis, just that one, yes
 * jdstrand nods
<Chipaca> pedronis: wrt putting fromChange 'last', that'd be last before flags, right? or actually last?
<pedronis> Chipaca: actually last
<Chipaca> pedronis: ack
<Chipaca> pedronis: and the filter also after the flags?
<jdstrand> is there a problem with lp snap builds? I tried to request a build from something and all it says is 'Failed to build' with no buildlog
<cjwatson> jdstrand: #is-outage
<ogra> jdstrand, theer seem to be other timeouts too
<cjwatson> swift takes out librarian which takes out a bunch of random stuff
<ogra> ah, cjwatson beats me
<jdstrand> cjwatson: thanks
<pedronis> Chipaca: that's fine, not as a strong opinion on that
<leinardi> kenvandine, sure thanks! I'll go offline soon, if you can please reply on the forum post: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/27
<zyga> mvo: given is-outage I wonder if we can release today
<mvo> zyga: we released
<zyga> I mean about .2
<zyga> can we even go to beta?
<zyga> mvo: interesting observation from just now
<zyga> I fixed one more typo
<zyga> the service fails correctly now
<zyga> but :)
<zyga> it is "working" during the startup phase
<zyga> I wonder if snap-confine or snap-run perhaps should be able to tell systemd "hold on, not really there yet"
<zyga> systemctl start snap.foo.bar.service # <- while snap-confine is running the service appears to be operational
<zyga> I realise this is a daemon=simple service
<zyga> just was not expecting it, I guess
<cjwatson> zyga: note that the swift that the LP librarian uses isn't the same as the one that the snap store uses
<zyga> cjwatson: ah, uff, that's good news
<cjwatson> at most it could cause a problem for builds; if you have something built it won't matter though
<cjwatson> (also it looks like it might be fixed)
<zyga> mvo: the test is passing now, I will experiment with the two extra variants that pedronis suggested
<mvo> zyga: thank you - I will take a break and get back to it then
<zyga> k
<cjwatson> jdstrand: try again now?
<zyga> mvo: going through smoke testing main/regression with my patch
<zyga> mvo: in parallel iterating on the variants pedronis suggested
<zyga> mvo: so far all good
<zyga> jdstrand: hey
<zyga> jdstrand: do you have a moment to discuss a regression I introduced to snap-confine?
<zyga> jdstrand: a quick look at a patch fixing that, I can give you context about the earlier discussion I had with pedronis and mvo
<zyga> jdstrand: if you cannot do it now that's fine, we can try next week
<jdstrand> zyga: if it isn't urgent, next week would be better
<jdstrand> zyga: and hello :)
<zyga> jdstrand: hey :)
<zyga> jdstrand: it's urgent-ish but I think it can wait (CC: mvo)
<zyga> jdstrand: I will open the PR and let anyone comment in case someone wants to over weekend
<jdstrand> zyga: if you do it that way, ping me with the PR and perhaps I can get to it later today
<zyga> thank you!
<zyga> I have a patch now but I'm trying to reduce it in scope so that it can do less side-effects and damage
<diddledan> Lukewh: did the build.snapcraft.io get fixed for https://github.com/canonical-websites/build.snapcraft.io/issues/1181?
<pstolowski> pedronis: hey, i'm fighting with ensurebefore.. as soon as i enhance the "naive" fix with "if !o.ensureTimer.Stop() { <-o.ensureTimer.C }" it hangs around it
<diddledan> I'm seeing the snaps again that had disappeared, but I'm not sure if it's because of a fix or just my dumb luck that I received a different set of data from the API when I refreshed (my bug was https://github.com/canonical-websites/build.snapcraft.io/issues/1175) but it seems identical to popeys
<diddledan> popey's
<mvo> zyga: thanks
<mvo> zyga: yeah, what I heard from abeato was that monday is ok but if not I can jump on it now
<zyga> mvo: I have the patch now
<zyga> reduced
<mvo> zyga: is there a PR yet? abeato was also keen to look at the details
<zyga> yes
<mvo> zyga: aha, nice - with pedronis suggestions?
<Chipaca> I'm going to take a break for a while. Will bbl, in a couple of hours. If you go before I'm back, have a great weekend!
<zyga> yes
<zyga> sorry, messed up my branch names (wip vs fix) opened properly now
<mup> PR snapd#6466 opened: cmd/snap-confine: handle death of helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<zyga> jdstrand: ^
<zyga> pedronis: ^ FYI
<zyga> at least for _this_ test it works correctly
<zyga> and feels like a safe thing to releae
<zyga> *release
<zyga> there are more children but this is the only pipe handling
<zyga> (so yay)
<mvo> zyga: sweet, shorter
<zyga> yes, the test, now devoid of critical typos, is most of the code
<zyga> I was thinking about a negative test
<zyga> edit-out the sleep and see things work
<zyga> but I will let everyone comment first
<zyga> I ran main suite successfully with this change
<zyga> and, surprisingly, it even works on 14.04
<pedronis> zyga: thanks for checking out simplifying the change at least for now, have a bit of head ache so I will let other look at it today, calling it a week
<zyga> pedronis: that's a good plan :)
<pedronis> have a great weekend!
<zyga> pedronis: likewise!
<zyga> jdstrand: note, this fixes a private consumer bug, I can subscribe you for context
<zyga> jdstrand: done now, you should be able to see the bug
 * zyga EOWs
<Lukewh> diddledan: We haven't released build.snapcraft.io recently, so I assume magic has made it work for you again. I'm going to leave your bug open as it still needs further investigation. Please update the bug if it happens again!
<diddledan> willdo
<diddledan> thanks
<mup> PR snapcraft#2457 opened: lifecyle: avoid installation of snaps in docker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2457>
<mup> PR snapcraft#2458 opened: clean: error out on invalid or missing yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2458>
<mup> PR snapcraft#2459 opened: catkin plugin: describe how to build all packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2459>
#snappy 2019-02-02
<mup> PR snapcraft#2458 closed: clean: error out on invalid or missing yaml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2458>
<leinardi> Hi, is there a way to access the sockets in /tmp/.X11-unix? Currently I'm getting "No such file or directory" when I try from snap
<zyga> leinardi: hey
<zyga> leinardi: no, at present you must use the abstract socket
<leinardi> zyga, ok thanks, I'll try
<zyga> leinardi: /tmp is private (and empty) for each snap
<zyga> so any sockets located there are inaccessible
<leinardi> what is the plug x11 providing than? Do I still need it if I want to use the X protocol?
<zyga> leinardi: it provides several things
<zyga> leinardi: but we don't have a mechanism to restore items that are placed n /tmp
<zyga> leinardi: you can use the abstract unix socket to talk to x
<zyga> leinardi: if you want to know what each interface provides, technically, just look at:
<zyga> https://github.com/snapcore/snapd/tree/master/interfaces/builtin
<zyga> leinardi: for example the x11 interface is implemented in https://github.com/snapcore/snapd/blob/master/interfaces/builtin/x11.go
<zyga> leinardi: most typically the interestesting part is the set of permissions provided to connected plugs
<zyga> leinardi: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/x11.go#L105
<zyga> leinardi: the rules are sometimes hard to read as they use include statements that reference local files (/etc/apparmor.d/abstractions/X for example)
<zyga> leinardi: but this is a good starting point to understand every interface
<leinardi> zyga, thanks, I'm checking now if the python library that I'm using for the X protocol implementation handles the abstract socket. I really hope it will, because otherwise I guess it will be complicated...
<zyga> it's just a path :0
<zyga> well, a path-like thting
<zyga> *thing
<zyga> it should be OK
<zyga> good luck
<zyga> I'll be around
 * zyga is fighting https://github.com/snapcore/snapd/pull/6466
<mup> PR #6466: cmd/snap-confine: handle death of helper process <Created by zyga> <https://github.com/snapcore/snapd/pull/6466>
<zyga> pstolowski: FYI https://www.irccloud.com/pastebin/XAW55EMc/
<leinardi> Hi, does anyone know if is possible to run commands on the host and get the output? Details here: https://forum.snapcraft.io/t/running-commands-on-host-and-get-the-output/9781/1
<mup> PR snapd#6467 opened: image,cmd/snap,tests:  introduce prepare-image --classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/6467>
#snappy 2019-02-03
<mup> PR snapd#6468 opened: image: bootstrapToRootDir => setupSeed <Created by pedronis> <https://github.com/snapcore/snapd/pull/6468>
<mup> PR snapd#6469 opened: image,cmd/snap,tests: introduce support for modern prepare-image --snap <snap>[=<channel>] <Created by pedronis> <https://github.com/snapcore/snapd/pull/6469>
<mup> PR snapcraft#2451 closed: static: address black warnings <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2451>
<r3-{s0urce> Hi, is it possible to run vmware workstation on ubuntu-core?
#snappy 2020-01-27
<zyga> Good morning
<zyga> a bit empty today...
<zyga> wonder if netsplit
<zyga> or flu
<mvo> zyga: vacation, swap days, ...
<zyga> hey :)
<zyga> mvo: indeed
<zyga> mvo: welcome back!
<mvo> zyga: I will probably also swap at least half a day but wanted to double check how things are
<zyga> mvo: we had some humps
<mvo> zyga: yeah, was reading what you did on friday
<zyga> mvo: lxd candidate started handing out i386 containers
<mvo> zyga: thanks for digging into all this!
<zyga> mvo: one test needs investigation as it breaks on core20
<mvo> zyga: yeah, read that too, that was hillarious
<zyga> mvo: I'm just looking at results
<mvo> zyga: yeah, I suspect we stopped using shadow for the user tools
<zyga> mvo: and I found a few leaks
<zyga> mvo: no progress on reviews from security team yet
<mvo> zyga: I remember there was a switch planned to something else that also provides userdel but a) I may misremember b) I can't remember what the other source package was :/
<zyga> hmm
<zyga> I see
<zyga> I tried to make all of my branches green though I didn't manage to for the few oldest
<mvo> zyga: nice
<mvo> zyga: I investigate this userdel issue
<mvo> zyga: what is confusing is that this test fails on core20 but not on ubuntu-20.04-64
<zyga> oh, indeed
<zyga> ppa skew?
<mvo> zyga: could be, I will just try to reproduce, also strange that it just started recently to fail - oh well
<zyga> yeah, it failed on Friday
<zyga> mvo: skipping 1:1 today?
<mvo> zyga: see /msg
<mup> PR snapd#8050 opened: tests: add marker tag for core 20 test failure <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8050>
<zyga> mvo: given that you are here still - can I merge https://github.com/snapcore/snapd/pull/8047
<mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
<mup> PR snapd#8034 closed: overlord/snapstate: fix for lp:1860324 for 2.43 <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8034>
<zyga> mvo: any news about 2.43 revert for /writable?
<zyga> mvo: should we revert?
<mvo> zyga: no update yet so I think we should
<mvo> zyga: or I missed a mail which is quite possible
<mvo> zyga: I think I will do 2.43.2 tomorrow morning
<zyga> the branch is sitting green, let's wait until we get some news today
<zyga> and pick the decision tomorrow
<zyga> I'll check the bug report
<mvo> zyga: thank you!
<zyga> mvo: the customer is okay with the workaround but the timing is that they would rather have a revert now
<mvo> zyga: sure thing
<zyga> mvo: I'll grab a coffee and do some reviews and merges
<mvo> zyga: sounds great, I will leave irc for a bit, availalbe on tg for emergencies
<sdhd-sascha> hey, zyga - "markstos" seems to be very interrested in termite on classic. And also likes sway and i3. Maybe we can bring the gnome-extension into classic-mode, so the termite's snapcraft.yaml didn't need to much environments and scripts...
<sdhd-sascha> (just for your information. )
<Chipaca> ð
<zyga> re
<zyga> sdhd-sascha: it's probably silly but I don't follow - gnome-extension classic mode?
<zyga> Chipaca: hello
<zyga> how are you? are you off today or working>.
<sdhd-sascha> zyga: i know. What i want to say is, that there are some one more, which could help. And i know you are good in social connections. So i just want inform you. Nothing more ;-)
<Chipaca> zyga: working today
 * zyga nods
<Chipaca> not sure when I'm going to get a break tbh :)
<mup> PR snapd#8022 closed: cmd/snap-confine: Revert #7421 (unmount /writable from snap view) <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8022>
<zyga> Chipaca: anytime you feel like it
<zyga> it's a bit of tumbleweed territory here today
<zyga> maciek and pawel are off
<Chipaca> s/break/swap/
<zyga> mvo and samuele are off too
<zyga> cachio is off
<zyga> ian will come around in a few hours
<Chipaca> zyga: I've come back from za with a rather hard deadline for some things i need to get done :)
<zyga> I see
<Chipaca> zyga: thank you for the note on #7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> Chipaca: I sent small tweaks to https://github.com/snapcore/snapd/pull/8045
<zyga> Chipaca: and removed my review since I changed it now
<mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
<zyga> Chipaca: do you want to do a second review?
<zyga> I tried to document my patches as best as I could
<Chipaca> zyga: will do in a bit
<zyga> thank you, it's not urgent though
<Chipaca> "a bit" â a while (knee-deep in users right now, and then have a manpages meeting, and then standup...)
<Chipaca> zyga: speaking of which, do you want to come to the manpages meeting?
<zyga> yeah
<zyga> I was about to ask
<Chipaca> is that something that interests you?
<Chipaca> ok :)
<zyga> yeah, greatly
<zyga> over the past few weekends I've been hand-writing manual pages :)
<zyga> (seriously)
<mup> PR snapd#8050 closed: tests: add marker tag for core 20 test failure <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8050>
<Chipaca> zyga: FWIW manpages is black, so unless I can do it this week it's not getting done, but I'd rather somebody else in the snapd team knew about what needed to be done
<sdhd-sascha> Is it a goal, that classic and strict snaps should work the same in future ?
<zyga> sdhd-sascha: in which sense
<zyga> sdhd-sascha: there's a fundamental difference between them
<sdhd-sascha> For the user, who creates a snap.
<zyga> no, they will always be different then
<sdhd-sascha> Oh :-( Then it would be nice, if a git-branch can be used as a track on snapstore, at least.
<zyga> git branch?
<mup> PR snapd#8051 opened: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
<sdhd-sascha> zyga: i mean - the store people. Could implement a feature, that per "github" branch, a automated build and publish pipeline to a "track" exist. So, in git there is a "classic", "devmode" and "strict" branch.
 * sdhd-sascha afk
<Chipaca> sdhd-sascha: the ability to be classic is a per-snap attribute
<Chipaca> sdhd-sascha: so tracks for classic are not typically approved
<Chipaca> sdhd-sascha: recommendation is to use a different name for classic vs non-
 * Chipaca takes a break
<sdhd-sascha> Chipaca: i know. That's why i started to upload snaps on github... Would it make sense to have a community store, with lesser restrictions ?
<zyga> sdhd-sascha: no, because that would be an enormous effort and why?
<zyga> community store becomes curl | sudo sh
<zyga> that's not useful
<zyga> and not responsible
<sdhd-sascha> hmm, maybe a case for a cmdline option for `snap install <url>`
<zyga> classic?
<zyga> wget && snap install --dangerous
<zyga> but that's not better either
<sdhd-sascha> zyga: like it is now. `--dangerous` makes sense
<zyga> this is not a technical limitation, it's a design that prioritizes safety
<sdhd-sascha> yes
<Chipaca> zyga: added you to the manpages meet, but it has not meet url atm
<zyga> Chipaca: is there a video ?
<zyga> aj
<zyga> ah
<zyga> ok
<Chipaca> zyga: cjwatson can add that, i can't
<Chipaca> :-)
<Chipaca> cjwatson: thanks
<cjwatson> I just did
<mup> PR snapcraft#2895 opened: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2895>
<zyga> that was fun :)
<Chipaca> zyga: actually i said wednesday but pedronis is back tomorrow afaik so i'll chat then
<Chipaca> calendar allowing
<Chipaca> zyga: you want in on that meeting as well?
<zyga> yeah
 * Chipaca adds
<cjwatson> Chipaca,zyga: https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
<zyga> Chipaca: check out the standup doc please
<zyga> Chipaca: I added one bit that we didn't discuss
<zyga> highlighted now
 * Chipaca looks
<zyga> Chipaca: if we go and model manual pages, I wonder if this is a one-off
<zyga> or is this "snap ships content to unconfined world"
<Chipaca> zyga: meta/man would also be backwards compatible :)
<zyga> Chipaca: yes
<zyga> Chipaca: but not $SNAP/man (that was my only point)
<Chipaca> zyga: updated the meeting description with this as well
<Chipaca> cjwatson: <3
<Chipaca> ok, i need to go get veggies to go with my lunch
 * Chipaca vegs out
<zyga> o/
<cmatsuoka> Chipaca: interesting test error in the users refactoring PR
<cjwatson> Chipaca,zyga: Hm, I forgot to check, does the name mediation bit require any store changes?
<cjwatson> I never found out how that worked before I mostly stopped working on the store
<zyga> cjwatson: I suspect it would - which is also easier if it's explicit rather than fished from the filesystem structure
<cjwatson> Somebody who has a clue what's involved should loop in Bret ASAP then
<zyga> cjwatson: I think we should do that after the call tomorrow
<cjwatson> But if that doesn't happen then <snap-name> and <snap-name>.* will still work, right?
<zyga> it's probably not the store as much as review tools
<cjwatson> Er right, maybe Jamie then
<cjwatson> I won't release man-db for a week or so, just in case
<zyga> Chipaca: daemon/api_users_test.go:220:42: "potatos" is a misspelling of "potatoes"
<zyga> 862
<Chipaca> cjwatson: re name mediation, if it goes beyond what aliases does, yes -- i'll add that to the meeting with samuele tomorrow
<cjwatson> Ta
<Chipaca> I expect it'd look like another assertion type, with snapd needing to do some work but not the store
<zyga> I think so too
<Chipaca> but I might be over-optimistic wrt the store side of assertions
<zyga> I'm off for a walk with Bit
<cmatsuoka> Chipaca: could you have a look at https://bugs.launchpad.net/snapd/+bug/1860773? It seems that we have a problem in default track error messages
<mup> Bug #1860773: Default track not in error message when branch requested <snapd:New> <Snap Store:New> <https://launchpad.net/bugs/1860773>
<Chipaca> cmatsuoka: that was filed at my behest
<cmatsuoka> Chipaca: ah good, thanks
<Chipaca> cmatsuoka: IOW, yes yes we do -- I knew we did, although I didn't predict this exact flavour
<cmatsuoka> Chipaca: should I assign it to you, or leave it unassigned?
<Chipaca> cmatsuoka: there's a store-side component to that because the error from the store doesn't let us tell the user the right thing
<cmatsuoka> hmm
<Chipaca> cmatsuoka: leave it unsigned -- i doubt i'll have time to get to it
<cmatsuoka> ok
<Chipaca> cmatsuoka: the quick fix would be to make snapd not tell the user the channel it was looking for
<Chipaca> cmatsuoka: the better fix would be to make the channel mapper default-track-aware, and pass in the default track from the error response (that's the bit that's missing)
<Chipaca> </braindump>
<Chipaca> cjwatson: about https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
<Chipaca> cjwatson: note in redhat etc that'd be /var/lib/snapd/snap/man
<Chipaca> "redhat etc" is release.DistroLike("fedora", "arch", "archlinux", "manjaro", "antergos")
<cjwatson> Chipaca: I'll try to remind those packagers that they need to patch that
<Chipaca> cjwatson: ð
<cjwatson> I think it's reasonable for upstream man-db to refer to upstream snapd's path, though
<Chipaca> cjwatson: fair
<Chipaca> cjwatson: also while those distros don't like /snap/, most of their users will have it anyway because without it they don't get classic snaps
 * Chipaca looks athttps://github.com/rydal/tuxconfig-frontend and is terrified
<zyga> re
<zyga> Chipaca: standup?
<Chipaca> zyga: omw
<ijohnson> hmm one of the case fans on my desktop has stopped spinning :-/
 * ijohnson reboots
<ackk> hi, does anyone have an opinion on https://bugs.launchpad.net/snapcraft/+bug/1860884 ?
<mup> Bug #1860884: Python plugin: paths for from the snapcraft snap in sys.pat break dependencies <Snapcraft:New> <https://launchpad.net/bugs/1860884>
<zyga> Chipaca: quick review on https://github.com/snapcore/snapd/pull/8051#pullrequestreview-348743013
<mup> PR #8051: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
<mup> PR snapcraft#2896 opened: Fix the package 'python3-distutils' not found on Ubuntu Xenial <Created by khiemdoan> <https://github.com/snapcore/snapcraft/pull/2896>
<mup> PR snapd#8045 closed: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8045>
<ijohnson> cmatsuoka: mind giving a quick re-review to #8044 ? I merged master so the diff should is pretty small now
<mup> PR #8044: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
 * zyga looks as well
<cmatsuoka> ijohnson: sure, checking it now
<ijohnson> thanks!
<cmatsuoka> ijohnson: done
<Chipaca> zyga: thank you for the review
<zyga> :)
<mup> PR snapd#8052 opened: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
<ijohnson> thanks cmatsuoka, I just opened ^ which is the followup you requested
<zyga> the leftovers would be the temporary files, right
<zyga> ?
<Chipaca> zyga: pushed changes you suggested to the 8051
<zyga> mmm
<ijohnson> zyga: yes that's what I meant by leftovers
 * ijohnson is bad at puns
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8052#pullrequestreview-348804159
<mup> PR #8052: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
<ijohnson> zyga: thanks, I think I'll leave it as is (but also I responded in the PR)
<zyga> that's fine
<mup> PR snapd#8044 closed: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
<mup> PR snapd#8052 closed: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8052>
 * zyga goes to install focal on bare metal
<zyga> with nvidia
<zyga> this will be fun
<zyga> bah, contention
<zyga> popey: is the new shiny theme hitting the daily anytime soon?
<zyga> jdstrand_: hey, how is the review queue looking this week?
<jdstrand_> zyga: same as last week since I haven't started the push yet
<zyga> jdstrand_: but you still plan to this week?
<jdstrand> zyga: that is still my plan, yes
<zyga> good, that's all I wanted to check
 * zyga has focal usb but goes for supper first
<mup> PR snapd#8051 closed: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8051>
<cmatsuoka> ijohnson: are we still packing .go files inside the snapd snap? if so, there's an easy way to fix that
<ijohnson> cmatsuoka: you mean in the snapd snap in the store?
<ijohnson> cmatsuoka: I hope we aren't
<cmatsuoka> ijohnson: I think we were, many months ago, let me check that...
<ijohnson> cmatsuoka: I don't see any .go files in the snapd snap
<cmatsuoka> ijohnson: we're still doing it. look what's inside the snap directory in the snapd snap
<ijohnson> cmatsuoka: that dir is empty for me
<ijohnson> cmatsuoka: actually you know what I'm looking at a snapd snap I built myself, not one from the store
<cmatsuoka> hmm, I just ran snap download snapd and unsquashed the snap
<cmatsuoka> ijohnson: could you try it and check the snap subdir for a bunch of .go files?
<ijohnson> cmatsuoka: yeah I see it with what's built from the store
<ijohnson> FWIW, I have been building local snapd snaps with my branch: https://github.com/snapcore/snapd/pull/7904 which doesn't suffer this problem
<mup> PR #7904: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
<cmatsuoka> ijohnson: ah ok, then it was fixed in snapcraft and the fix was used when you added base: core
<ijohnson> cmatsuoka: yes IIUC the current snapd snap is still built with legacy snapcraft
<cmatsuoka> ijohnson: it used to happen because snap/ is special and one way to fix that was to use build-aux/snap but if it's not necessary it's even better
<ijohnson> cmatsuoka: my branch also uses build-aux/snap so perhaps that's why
<cmatsuoka> ah right ok, you already have the fix then :D
<mup> PR snapd#8053 opened: osutil: implement deluser <Created by chipaca> <https://github.com/snapcore/snapd/pull/8053>
#snappy 2020-01-28
<mup> PR snapcraft#2897 opened: meta: include environment in hook wrappers <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2897>
<mup> PR snapcraft#2893 closed: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2893>
<mup> PR snapcraft#2898 opened: meta: remove dead code from snap packaging <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2898>
<mborzecki> morning
<mvo> hey mborzecki ! good morning
<mborzecki> mvo: hey!
<mup> PR snapd#8049 closed: tests: fix revisions leaking from snapd-refresh test <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8049>
<mup> PR snapd#8032 closed: boot, cmd/snap, cmd/snap-bootstrap: move run mode and system label detection to boot <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8032>
<mup> PR snapd#8040 closed: gadget: skip update when raw structure content is unchanged <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8040>
<mup> PR snapd#7993 closed: devicestate: enable encryption based on model grade <UC20> <Created by cmatsuoka> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7993>
<zyga> Hey guys
<zyga> Iâm going to check my wrist
<zyga> I have a visit at 9:30
<zyga> Iâll be back later
<mvo> zyga: good luck
<mborzecki> zyga: hey
<mborzecki> btw. played a little with gnome-builder yesterday, it'd be nice to have some snap integration there, looks like it supports building flatpaks ootb
<jamesh> mborzecki: I did some work on that ages ago.  I set it aside, as I couldn't get things to work the way upstream wanted without changes to Snapcraft, and couldn't get buy-in to get those Snapcraft features done.
<mborzecki> jamesh: interesting, thanks for the insight!
<jamesh> mborzecki: my patch essentially introduced "Snapcraft" as a new build system.  What they wanted was to keep the underlying build system visible (i.e. automake, meson, etc), and allow Builder to invoke it
<jamesh> The idea is that build system plugins could support operations like "add newfile.c to library X", and they would update the appropriate makefile or equivalent
<jamesh> you also want to be able to determine compile flags for each source file in order to properly parse them for completion
<jamesh> so if Snapcraft was build system, it would need to reimplement all of this for each of its supported build systems
<mborzecki> jamesh: yeah, makes sense when you're working on your piece of software and snapcraft is really just a packaging method
<mborzecki> jamesh: btw. have you worked with builtstream too?
<jamesh> mborzecki: IIRC, the Flatpak plugin adds an early build step to download dependencies, and provides the appropriate environment to run the underlying build system.  There's also an extra step at the end to package up the result
<jamesh> There is the risk that this could produce different results to a standard build, but it means you have incremental builds and all the IDE features
<jamesh> I haven't looked at Buildstream
<mup> PR snapd#8054 opened: snap: add `snap pack --compression=<comp>` options <Performance ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8054>
<Chipaca> mo'in, all
<mvo> hey Chipaca and pedronis ! good morning
<pedronis> hi
<Chipaca> mvo: had an adequate amount of rest? :-)
<Chipaca> pedronis: I set up a short meeting to go over some things about manpages, either to clear the path for me to push a PR with it this week, or to spread the knowledge around of what needs doing later
<pedronis> Chipaca: yes, saw it
<Chipaca> mvo: pedronis: it just struck me that postUserCreateData's ForceManaged flag might be deprecated as well, I'm not clear what the use case was for it (ie should I leave it behind in the to-be-deprecated endpoint or carry it forwards as is currently done)
<pedronis> Chipaca: it's a bit of an orthogonal concern, I think we do want to carry it forward
<pedronis> even it's hopefully low usage
<Chipaca> k
<mvo> Chipaca: people seems to use the flag to create additional users on devices which seems to be a valid use-case. the name is a bit confusing though :/
<mvo> Chipaca: thanks for setting up that meeting
<Chipaca> mvo: should I add you to it? so far it's me, zyga, pedronis
<Chipaca> mvo: working on the assumption that you don't love meetings _that_ much :-p
<mvo> Chipaca: I'm fine not being part of it
<zyga> Iâll be back soon
<zyga> Hey pedronis, welcome back :-)
<mborzecki> Chipaca: pedronis: hey
<zyga> Hey mborzecki :-)
<pedronis> mvo: zyga: shouldn't the disabling in 5512861442cbf containt TODO:UC20 ?
<zyga> If that is the patch I think it is there was a follow up that adds the todo core 20 marker
<zyga> (Iâm still afk for a short while)
<pedronis> mborzecki: in the doc comment for ModeAndRecoverySystemFromKernelCommandLine "returns the current run mode", I think we need to s/run/operating/
<mvo> pedronis: I had the same comment about the todo:uc20 and it was added in pr 8050
<mup> PR #8050: tests: add marker tag for core 20 test failure <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8050>
<pedronis> ah ok
<pedronis> good
<mborzecki> pedronis: ack
<mup> PR snapd#8055 opened: boot: tweak kernel cmdline helper docstring <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8055>
<mborzecki> hm, it'd be cool if we could indicate that full spread run is unnecessary for PRs like that
<pedronis> mborzecki: maybe there's a way to read via the api if a given label is applied to the PR
<mborzecki> pedronis: that or just scrape the page, like we did with the PR title, as the API had limitations and required api key
<mup> PR snapd#8056 opened: client: move user-related things to their own files <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/8056>
<Chipaca> mborzecki: pedronis: FWIW, https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b4 looks at labels on PRs
<Chipaca> they're reasonably straightforward to get
<Chipaca> (but yes without an api key we'd hit rate limits very fast)
<pedronis> mvo: did you see this: https://forum.snapcraft.io/t/auto-import-assert-fails/15181
<mvo> pedronis: have not seen it, will followup
<zyga> brb
<mup> PR snapd#8057 opened: overlord/auth: add RemoveUserByName <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/8057>
<zyga> Chipaca: reviewed
<popey> Hm, anyone built an image with series:: "18"? ubuntu-image doesn't seem to like it
<popey> https://tutorials.ubuntu.com/tutorial/create-your-own-core-image
<zyga> popey: series 18 is not a thing
<zyga> series is always 16
<popey> oh
<zyga> popey: and hi :)
<popey> thats odd :)
<Chipaca> popey: series is the restart-the-world generation switch
<Chipaca> popey: if we change the series it's because we're starting over
<zyga> we should have called it multiverse
<Chipaca> popey: as in, nothing from series X works on series Y
<Chipaca> popey: granted in retrospect we should've made it more internal-only, but we hadn't learned how to make things co-habitate back then
<Chipaca> we thought we'd have to bump the series every lts
<Chipaca> or something like that
<popey> Is it possible to seed something to stop me having to do the U1 SSO dance on first boot of a core device?
<mup> PR snapd#8058 opened: run-checks, travis: allow skippng spread jobs by adding a label <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8058>
<mborzecki> anyone remember when cachio is coming back?
<zyga> next week
<mborzecki> ah, ok
<zyga> focal with zfs
<zyga> oh mhy
<mup> PR snapd#8053 closed: osutil: implement deluser <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8053>
<mborzecki> zyga: is the oracle police already banging at your door trying to extort a fee? :)
<mup> PR snapd#8055 closed: boot: tweak kernel cmdline helper docstring <Simple ð> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8055>
<zyga> popey: you might know - nvidia experimental drivers for ubuntu?
<zyga> popey: how do I get some
<mup> PR snapd#8056 closed: client: move user-related things to their own files <Simple ð> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8056>
<popey> Possibly https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa  zyga
<zyga> popey: thank you! :)
<Chipaca> hmm, shouldn't ubuntu-20.04 no longer be unstable?
<mup> PR snapd#8057 closed: overlord/auth: add RemoveUserByName <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8057>
<mup> PR snapd#8059 opened: daemon: implement user removal <Created by chipaca> <https://github.com/snapcore/snapd/pull/8059>
 * Chipaca goes out for a while
<zyga> brb
<zyga> need to make tea for Iza
<mup> PR snapd#8060 opened: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8060>
<mborzecki> off to pick up the kids from school
<mborzecki> re
<zyga> o/
<zyga> ijohnson: without the window reflection https://twitter.com/zygoon/status/1177917609783808001/photo/1
<ijohnson> zyga: very nice, it's so cleanly organized
<ijohnson> my desktop has cables running everywhere and looks very messy generally
<Chipaca> zyga: https://i.redd.it/4c9udy915qyy.jpg
<mborzecki> ijohnson: had to address a similar problem, otherwise my vega 56 would run really hot (still runs quite warm under load, but UV keeps the temps in check)
<Chipaca> zyga: (via https://www.reddit.com/r/cablefail/comments/6ccwaq/looked_tidy_until_the_side_fell_off_in_the_wind/ )
<zyga> Chipaca: just add fire :D
<ijohnson> Chipaca: how did you get a picture of the inside of my desktop ?!?! :-)
<zyga> ijohnson: the other PC is also pretty tidy but not to that level
<Chipaca> ijohnson: i had to resverse the polarity on your webcam, and the rest was easy
<Chipaca> reverse*
<Chipaca> tachion flux*
<ijohnson> Chipaca: ah I knew I shouldn't have installed that 1.21 gigawatts power generator on my webcam
<zyga> https://twitter.com/zygoon/status/1222166974802878464 :)
<zyga> ugly cables going everywhere
<ijohnson> https://usercontent.irccloud-cdn.com/file/MVvajfu5/IMG_20200128_083935.jpg
<ijohnson> zyga: do you have a noctua cpu cooler on that? looks very similar to mine
<zyga> with that carpet you could get great results buy just having feet and a dust filter
<zyga> yeah
<zyga> it's a 10+ year old PC
<zyga> with a new case
<zyga> 1st gen core i7
<zyga> for the xmas refresh I will get a mobo/ram/gpu and go with something newer
<zyga> but keep the outside the same
<ijohnson> yeah mine could do better, but it works well enough, just need to blow out the dust every once and a while
<ijohnson> there's a big fan on the top and on the side panel that aren't in the picture that keep the whole system quite cool
<zyga> yeah, cooling in PCs is really hard to get wrong :)
<zyga> lots of space
<ijohnson> I wanted to do a water cooled system but I was a bit lazy
<ijohnson> pedronis: do you have a minute to chat about snap-bootstrap re-execing into the snapd snap on first-boot? I agree that it is complicated but I think it would be very good to have
<ijohnson> pedronis: I tried to make it work quickly, the most difficult thing I ran into was picking which snapd snap to mount snap-bootstrap from
<zyga> degville: you didn't tell me you are making the corsair link snap!
<degville> zyga: aha, yeah. I use it personally. I think there may be a permission issue I've not sorted out with the one I've pushed though, so it's not made it to stable (I've not looked at it in a while).
<degville> zyga: I use it set my own fan profile for silent operation :)
<zyga> degville: what are you controlling with it?
<zyga> degville: the PSU?
<degville> zyga: HX750i PSU and H100i GT v2 CPU water cooler.
<zyga> mmm
<zyga> I have the fan controller only
<zyga> actually, no fan and RGB controller
<zyga> and fan controller has more rgb and temp
<degville> zyga: it does use a poorly documented syntax. I don't set the RGB (my box is under the table), but the syntax for my cooling profile is --device 1 --fan channel=1,mode=6,temps=0:35:45:50:55:60,speeds=0:0:55:60:75:100.
<pedronis> ijohnson: that's why it's hard, we would need to put a snapd copy into ubuntu-boot
<pedronis> with all that entails in terms of state and checks
<ijohnson> pedronis: oh also I just realized that in the fde case ubuntu-data is encrypted too
<pedronis> ijohnson: yes, ubuntu-data is encrypted
<ijohnson> pedronis: okay I see why you would want snapd in ubuntu-boot too
<ijohnson> pedronis: maybe this is too much, but maybe for the snapd snap specifically we could have a "extract snapd assets" function which would copy things like snap-bootstrap to ubuntu-boot when a snapd snap is installed?
<pedronis> ijohnson: how do we check that that binary is good
<pedronis> we don't sign single binaries that way
<pedronis> ijohnson: I understand the appeal, I don't see a way to keep the complexity cost vs benefit under control
<ijohnson> pedronis: hmm I suppose currently snap-bootstrap is part of the initramfs which is part of the kernel.efi and so thus is measured, but if it was just ran directly then it wouldn't be measured
<ijohnson> yeah I guess I don't see a way to easily do it then without possibly waiting to re-exec until after ubuntu-data is decrypted perhaps, but that kind of defeats the purpose
<pedronis> ijohnson: it needs to get stable and stay relatively simple
<ijohnson> pedronis: yes another thing I just thought about is perhaps for our tests, we could re-build the initramfs for spread tests that way we can test changes in the PR without needing to wait for a new kernel snap?
<pedronis> ijohnson: that should be possible in some way
<pedronis> mvo: ^  thoughts on on that?
<pedronis> patching initramfs in tests
<zyga> pedronis: initramfs may need to be signed - is that a problem?
 * zyga needs a coffee
<pedronis> zyga: well , we'll special certs that we use in tests
<ijohnson> zyga: not a problem for tests
<pedronis> so that's should be the main problem for tests
<pedronis> shouldn't be
<zyga> in that case it feels okay
<zyga> just like rebuilding core/snapd snaps
<ijohnson> well it would be a problem if we do try to test FDE via spread
<ijohnson> but I think we have other, related problems with testing that anyways
<pedronis> ijohnson: we actually discussed some to have some kind unpack/repack mechanism for it
<pedronis> not sure there was progress on that
<ijohnson> yes I remember mvo mentioning that in SU a few weeks/months ago
 * zyga goes upstairs for a while
<ijohnson> well I think it's a reasonable suggestion so I'm gonna prototype out building a kernel snap for uc20 in the spread test with the right initramfs
<Chipaca> raaahhh
 * Chipaca rages a little
<Chipaca> why do we have an endpoint that returns things or lists of things depending on the phase of the moon
 * Chipaca spends a PR to fix it
<pedronis> Chipaca: which one?
<Chipaca> pedronis: /v2/create-user
<pedronis> I wasn't aware of that
<Chipaca> yeah
<Chipaca> pedronis: it's got two modes, create a user, or create all known users
<pedronis> ah
<Chipaca> pedronis: so i'm changing users to return a list always, and hacking create-users to preserve behaviour
<pedronis> Chipaca: +1
<Chipaca> i'll also change remove from returning true to returning nil as the result, for the same reason
<Chipaca> pedronis: at some later point you might want to consider login also being an action on users
<mvo> ijohnson, pedronis rebuilding the initramfs sounds appealing to me. if it's not too much hassle I would love to have this. we have snakeoil signing keys so we can even make this work in the tpm case (sorry for the slow reply, was in a ad-hoc meeting)
<ijohnson> mvo: ack I'll work on this then, not entirely sure how to use the snake oil keys for tpm, but I can just do the non-fde case right now easily enough
<mvo> ijohnson: yeah, one step at a time :)
<ijohnson> :-)
<mup> PR snapd#8061 opened: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<Chipaca> much nicer now :)
<mvo> zyga: the release/2.43 is a bit of a nightmare because of all the conflicts in "mount-ns" PER-SNAP-* files. any hints for me, it looks like this changed quite a bit between 2.43 and master and the revert of the /writable view that needs to be undone in the merge again makes this all a bit messy
<mvo> zyga: nevermind, I will just revert manually
<zyga> mvo: hmm
<zyga> mvo: re
<zyga> mvo: I'm confused - I merged the 2.43 revert
<zyga> mvo: in master it's good and we should not bring that patch to master
<mvo> zyga: yes, that's my point :) but we merge the release/* branches into master so that was a bit of pain
<mvo> zyga: it's all fine again
<zyga> resolve with --theirs or --ours or whatever was the option
<zyga> (don't take changes to that directory)
<mup> PR snapd#8062 opened: release: 2.43.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8062>
<zyga> or just cp it back from master :)
<zyga> mvo: thank you for doing this; I'm sorry for the annoying merge
<mvo> zyga: no worries
<zyga> and that I didn't respond faster, I was having dinner
<mvo> zyga: also no worries :)
<zyga> there's a changelog conflict
<mvo> zyga: oh, silly me
<zyga> resolved
<mvo> zyga: thank you!
<Chipaca> current status of user work is https://github.com/snapcore/snapd/compare/master...chipaca:client-deluser â¦ one more commit to go (in cmd/snap!) and it's Done(tm)
<Chipaca> (if it all comes together without needing to go back and tweak things I'll be giving myself a putty medal)
<Chipaca> now going to take a break
<mvo> Chipaca: nice!
<Chipaca> mvo: each of those commits becomes a PR, but I don't want to push them stacked (although i did do that for the last one)
<Chipaca> actually, i lie, the first two commits are a PR, the others are a pr each
<Chipaca> anyway, break time
<Chipaca> travis is all kinds of sad
<Chipaca> lots of 503s from the store
<noise][> yeah, we are troubleshooting CDN issues
 * Chipaca hugs noise][ 
<Chipaca> hmm, hmm, hm
 * Chipaca broke things
 * Chipaca fixes things
<mup> PR snapd#8062 closed: release: 2.43.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8062>
<mup> PR snapcraft#2893 opened: [legacy] meta: include environment in hook wrappers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2893>
<mup> PR snapcraft#2899 opened: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2899>
<Chipaca> chipaca@jan282010-194967:~$ sudo snap remove-user chipaca
<Chipaca> error: cannot delete user "chipaca": userdel: user chipaca is currently used by process 4865
 * Chipaca counts that as winning
<zyga> Chipaca: woot
 * zyga installs a round of mac updates
<mup> PR snapd#8063 opened: Remove users [DRAFT] <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
#snappy 2020-01-29
<mborzecki> morning
<mborzecki> driving the kids to school, back in 30
<mvo> mborzecki: good morning
<zyga> good morning
<mvo> hey zyga
<zyga> hey
<zyga> somewhat early start for me
<zyga> kids were incredibly efficient today
<mvo> nice
<zyga> mvo: I forgot to metion this
<zyga> *mention
<zyga> mvo: I think there's something seriously broken with lxd
<zyga> install lxd, start a container and shut the host down
<zyga> it doesn't shut down cleanly
<zyga> it takes 10 minutes for LXD to stop (on system timeout where it just ignores it)
<zyga> it's been like that for three weeks at least (I reboot infrequently)
<mvo> zyga: oh? did you mention this to stgraber or cbrauner?
<zyga> no, I only remember this when I reboot :/
<zyga> (and I reboot now to shut down everything to upgrade macos)
 * mvo nods
 * zyga notices it's 15C in the office and switches on heating...
<mborzecki> re
<mborzecki> zyga: mvo: hey
<mborzecki> it's snowing today, as in properly snowing
<mborzecki> otoh, the forecast for tomorrow is +4 and +10 over the weekend xD
<mvo> mborzecki: woah, nice! we have +5Â°C here
<zyga> mborzecki: yeah, it will snow here as well soon
<zyga> mborzecki: but it's too warm for the snow
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/7614 something you can review today?
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga> I would really like to move on with that topic
<mborzecki> zyga: sure, let me grab some coffee
<zyga> thanks
<zyga> I think it's close
<zyga> I have a follow up that I wrote months ago
<zyga> that adds most of the support for cgroup v2
<zyga> and one that fixes v1 flip flop issue
<zyga> (where the cgroup must change from open to closed and back)
<mborzecki> flip flip issue?
<zyga> cgroup having open access + default rules
<zyga> vs closed access + explicit rules
<zyga> as in
<mborzecki> ah, ok
<zyga> nothing tagged - defaults without constraints
<zyga> something tagged - some implicitly allowed, some explicitly allowed, rest denied
<zyga> this is what triggered this whole branch originally
 * zyga reboots for updates
<zyga> mborzecki: another thing that you could review, that is smaller, is https://github.com/snapcore/snapd/pull/7980
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> mborzecki: the setgid code changes
<mvo> mborzecki: I was looking at the remodel code again (and added some comments to your undo PR). when playing with it I noticed that it seems like "snap remodel" is now hanging instead of exiting when we have a pending reboot, did you notice this as well? this means one of the pending  spread tests is no longer quite working
<mborzecki> mvo: no i did not, i'll be running those tests again with the changes so i'll probably stumble upon that
<mvo> mborzecki: it's probably something silly, I poke at it a little bit
<zyga> mvo: hey, just a note from my backlog, solus maintainer expressed desire for changelogs for full releases
<zyga> mvo: like what you do for point releases
<zyga> mvo: it helps them write their own release notes
<zyga> mvo: and to do some testing
<zyga> mvo: I promised to relay this
<mvo> zyga: uh, ok. the changelogs will be huge but I can do this
<zyga> yeah but we can edit them (I offer my help) to highlight interesting things
<mvo> zyga: sounds good
<zyga> hmm
<zyga> unit test failure of 2.43.2 in opensuse
<zyga> https://www.irccloud.com/pastebin/j6YvQeQb/
<mvo> zyga: oh, what version of go is there?
<zyga> 1.12
<mvo> zyga: strange, we have 1.12 on eoan as well
<zyga> I think it's something else
 * zyga digs
<zyga> it writes a file to HOME
<zyga> but HOME doesn't exist during package build
<mvo> zyga: uh, that's unfortunate
<zyga> same as in debian
<zyga> remember /inexisting?
<mvo> yeah
<zyga> oh well
<zyga> I hope it's not a .3
<mvo> but we run this stuff in sbuild, I wonder why this wasn't caught
<zyga> our sbuild config is not the same as buildd
<zyga> (ran into this countless times with other packages)
<zyga> there's always something different
<zyga> let me tweak the test and see if that passes
<zyga> and if so, I'll sent the patch back
<zyga> setting HOME=/inexisting doesn't break the test
 * zyga wonders what's going on
<zyga> ahh
<mvo> zyga: there was a PR about rebooting from spread too early, do you remember that? or am I misremembering?
<zyga> mvo: so
<zyga> mvo: ... HOME is set by go-test or perhaps go-check
<zyga> mvo: rebooting from spread too early?
<zyga> mvo: not sure if that's what you mean
<zyga> mvo: but while working on some leaks last week
<zyga> mvo: I changed a test so that it would just wait for the system to reboot by itself
<zyga> mvo: rather than issuing a REBOOT
<zyga> mvo: and that didn't work because spread didn't expect this
<zyga> mvo: I'm not sure if that is related
<zyga> mvo: but I was thinking it would be good if spread had an ANTICIPATE_REBOOT thing
<zyga> mvo: that would allow regular reboot to just work
<mvo> zyga: yeah, that was kind of my question
<mvo> zyga: was just curious about this
<zyga> mvo: perhaps there's a trick but it would be hard with spread design now
<zyga> mvo: because there's no side channel
<zyga> mvo: REBOOT relies on special exit code
<mvo> zyga: yeah
<zyga> brb
<zyga> mvo: so, I added printf to the test
<zyga> and now it passes :?
<mborzecki> Chipaca: hi, can you split this to a separate topic? https://forum.snapcraft.io/t/snapped-application-wont-start-for-nvidia-graphic-card/13342/6
<mborzecki> zyga: ^^ some trouble with nvidia, wonder what driver version this guy has
<zyga> indeed, replied now
<mborzecki> zyga: thanks!
<mvo> zyga: a race?
<mup> PR snapd#8064 opened: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
<Chipaca> mborzecki: topic title and category plz
<mborzecki> Chipaca: category snapd, title: 'nvidia libraries not accessible inside snaps' ? cc zyga
<zyga> re
<zyga> +1
<zyga> SNOW
<mborzecki> jon?
<zyga> Chipaca: you should move your edit rights to someone, maybe mackiek?
<mborzecki> :P
<zyga> *maciek
<mborzecki> duh, still snowing :/
<Chipaca> mborzecki: https://forum.snapcraft.io/t/nvidia-libraries-not-accessible-inside-snaps/15227
<mborzecki> Chipaca: thanks!
<Chipaca> mborzecki: zyga: I a mod, not an admin, so i can't make people mods (nor admins)
<Chipaca> mborzecki: zyga: you want to ask gustavo, or the pope
<Chipaca> the small one from hampshire, not the regular one from buenos aires
<mborzecki> hahah
<zyga> hmmmmm
<mborzecki> wow, huuge snowflakes
<zyga> yeah
<zyga> I took some photos
<zyga> same here
<zyga> too bad it's not -10
<mborzecki> mvo: which remodel test was hanging for you?
<mvo> mborzecki: in a meeting right now, get back to you in a wee bit
<Chipaca> zyga: I could've also moved your comment instead of you deleting and recreating it fwiw :-)
<zyga> that's fine, thanks :)
<zyga> mvo: did you invite me to a meeting that was just finished?
<mvo> zyga: for next week
<zyga> ah, cool
<mvo> zyga: did it in a rush, all good
<mborzecki> quick errand, back in 30 or so
<pedronis> mvo: what's the relation between 8064 and Ian stuff ?
<pedronis> mvo: are you trying to split out bits from it?
<mvo> pedronis: I was wondering if that's possible
<mvo> pedronis: it's a bit long
<mvo> pedronis: this one is a straight cherry pick
<mvo> pedronis: but I was wondering if e.g. just the extraction of the kernel plus symlinking could land
<mvo> pedronis: and then the more delicate bits, mostly wondering at this point, no super strong opinion
<pedronis> mvo: I don't know, we turned on a lot of spread tests, will the ypass?
<mvo> pedronis: I think this one will, it just adds the kernel to the /boot/grub/pc-kernel_123.snap/kernel.efi
<mvo> pedronis: if we have the symlink too we would have something that could in theory boot an encrypted ubuntu-data
<pedronis> maybe
<pedronis> my impression was that Ian was fighting the fact that a lot of things dont' work
<mvo> pedronis: yeah, it's fine if you think it's a waste of effort, I will try to review in one go then
<pedronis> unless everything works
<pedronis> mvo: I'm not against
<pedronis> but consider that spread test might fail
<mvo> pedronis: yeah, I will keep this in mind
<mvo> pedronis: I poke it a bit more, but it might be this is the only thing that can easily extracted
<mvo> (assuming spread works)
 * Chipaca â orthopedist 
<kbroulik> Hi. I'm the maintainer of KDE Plasma's notification service. Recently we introduced a quick reply feature by adding a new signal on the FDO notification interface. This one isn't standard (yet) but I patched Telegram to use it. I now realized the AppArmor policy in snapd prevents it from connecting to this signal.
<kbroulik> Is a change to the builtin/desktop.go recipe to add NotificationReplied something you'd accept?
<kbroulik> ftr this signal: https://cgit.kde.org/plasma-workspace.git/tree/libnotificationmanager/dbus/org.freedesktop.Notifications.xml#n12
<sitter> zyga, Chipaca ^
<zyga> kbroulik: hey
<zyga> kbroulik: let me look
<zyga> I think it could go to desktop and desktop-legacy
<zyga> and perhaps unity7 as well, for completeness
<zyga> kbroulik: would you mind opening a forum thread, I'll patch things
<zyga> kbroulik: can you check that editing the dbus rules is enough for this?
<kbroulik> mostly asking because it's "not standard", otherwise I would have just submitted a pull request :)
<zyga> kbroulik: I can guide you how, if required
<zyga> kbroulik: yeah but practicality
<zyga> plus
<zyga> standard/
<zyga> what is standard in linux
<kbroulik> and from what I reckon getting things into freedesktop is also easier if you have "prior art" ;)
<kbroulik> so we can tell "yo, it's already used by Telegram and others, so please accept, thanks"
<zyga> s/standard/freedesktop
<kbroulik> zyga: is editing my local apparmor policy thing enough?
<zyga> so +1 from me
<zyga> yeah
<kbroulik> what forum thread do you want me to open?
<zyga> kbroulik: just look at /var/lib/snapd/apparmor/profiles/snap.telegram.*
<zyga> there's a line that says
<zyga> member={GetCapabilities,GetServerInformation,Notify,CloseNotification}
<zyga> kbroulik: just a forum thread about this change, so that it can be referenced in the patch
<zyga> kbroulik: where you say who you are and that you are adding this to kde and telegram
<zyga> kbroulik: that should be enough
<kbroulik> I'm such a noob - how do I have it reload the apparmor policies?
<zyga> you need to run sudo apparmor_parser /var/lib/snapd/apparmor/profiles/fname
<zyga> (replace the fname)
<zyga> er
<zyga> apparmor_parser -r
<zyga> sorry ;)
<zyga> :)
<kbroulik> ok, let's see if it works now
<kbroulik> yup, works, lovely
<kbroulik> so basically
<kbroulik> -member={ActionInvoked,NotificationClosed}
<kbroulik> +member={ActionInvoked,NotificationClosed,NotificationReplied}
<zyga> there may be some tests that need changing
<zyga> "go test" should tell you
<kbroulik> I dont see anything in git grep using notifications at least other than the rules file
<kbroulik> can't load package: package .: no Go files
<kbroulik> (I havent built it yet)
<zyga> you can run tests with go test ./...
<zyga> just go to the project tree
<zyga> ideally just run go test ./interfaces/builtin
<kbroulik> apparently the go in bionic (both repo and snap) is too old
<zyga> no worries, I can make the patch
<kbroulik> ok, well, 13 is > 6, so I'll give the snap a go then
<zyga> just start a forum thread please
<kbroulik> https://forum.snapcraft.io/ this forum I guess?
<zyga> correct
<kbroulik> righty-o
<kbroulik> https://forum.snapcraft.io/t/kde-plasma-quick-reply-support/15229 is this alright?
<zyga> yes
<zyga> that's great
<kbroulik> thanks
<zyga> do you want to send the patch or shall I?
<kbroulik> I can do it
<kbroulik> should I then just put also a link to that forum thread in the commit message?
<zyga> yeah, add Forum: ...
<zyga> at the bottom
<kbroulik> desktop_legacy doesnt have org.freedesktop.notifications mention, only desktop and unity7
<zyga> ah right
<zyga> I misread grep output
<kbroulik> I'll add it to the latter two
<zyga> thanks!
<kbroulik> oof, CLA, I think it's better if you do the patch then
<kbroulik> (I'm sure I had a launchpad/ubuntu one thing at some point)
<zyga> kbroulik: just try it, the check is automatic
<kbroulik> ok
<mup> PR snapd#8065 opened: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications <Created by kbroulik> <https://github.com/snapcore/snapd/pull/8065>
<zyga> mborzecki: I will have two small patches for you soon
<zyga> mvo: snapd doesn't work at all on focal :D
<zyga> mvo: patch soon
<zyga> mvo: trivial
<kbroulik> zyga: for the CLA it wants a phone number (which I'm not keen on giving them) and a canonical project contact..
<zyga> mvo: ^ can you please help
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8066
<mup> PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066>
<zyga> mvo: in case we do .3 please include this ^
<mvo> kbroulik: I'm your contact and feel free to not give a phone number -  Ithink that's new, I don't remember this as a requirement. sorry for that
<mvo> kbroulik: I can also pass this on to the relevant people
<mvo> zyga: it does not work on focal? I'm on focal, curious
<mup> PR snapd#8066 opened: cmd/snap-confine: allow snap-confine to link to libpcre2 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066>
<zyga> mvo: old builds are ok but new builds link to liprce2
<zyga> build on focal and you're sol
<mvo> zyga: ta!
<kbroulik> zyga: alright, can you re-run the ci check
<zyga> sure
<zyga> mvo: is it approved?
<ackk> mborzecki, hi, to confirm https://bugs.launchpad.net/snapd/+bug/1831473 is not yet released, right?
<mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:Fix Committed by jdstrand> <https://launchpad.net/bugs/1831473>
 * zyga goes for tea
<zyga> https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/12
<zyga> :D
<mvo> zyga: good that you are fixing this, yes :) ?
<mborzecki> re
<zyga> re
<zyga> mvo: yeah, I need to tweak the fix after doing it for real
<zyga> mvo: but it works
<zyga> mvo: man
<zyga> version strings like 123.435.02 SUCK
<zyga> mborzecki: snapd is out of date in aur
<mborzecki> zyga: mhm, got an email ;)
<zyga> yeah
<zyga> I find them funny
<mborzecki> zyga: weird version string `123.435.02 SUCK`
<zyga> OMFGOUTOFDATEEEEEEE
<zyga> mborzecki: :D
<mborzecki> kbroulik: LP hasn't been updated yet, but no worries, i'll try restarting the travis job periodically
<mborzecki> mvo: replying to your review of #7972 and realized that poking current is actually unreliable
<mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<popey> With ubuntu-image and the json "required-snaps" - is it possible to specify that the snap needs to come from a particular channel?
<pedronis> mvo: comment on #8064
<mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
<popey> I tried snapname/latest/edge but it didn't like that
<pedronis> popey: no, you can specify that with --snap to ubuntu-image but not in the model itself, that will be possible with Core 20 models, but the syntax is quite different there
<popey> ok
<popey> thanks
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8066
<mup> PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066>
<zyga> mvo: we don't have 20.04 systems, do we?
<zyga> mvo: we have some in unstable
<zyga> which is not flagging anything
<mborzecki> zyga: btw. do you know which library pulls in pcre?
<zyga> mborzecki: checking
<zyga> mborzecki: no idea?
<zyga> maybe dlopen somewhere, it's not in NEEDED
<zyga> sty 29 11:33:59 fx kernel: audit: type=1400 audit(1580294039.867:53): apparmor="DENIED" operation="file_mmap" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0" pid=74460 comm="snap-confine" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
<mborzecki> zyga: that's on focal right?
<zyga> yes
<mborzecki> zyga: can you try with LD_DEBUG=all ?
<mup> PR snapd#7942 closed: snap-confine: support nvidia driver microversion string <Created by zhuker> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7942>
<mup> PR snapd#8067 opened: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067>
<zyga> mborzecki: looking but I cannot find it
<zyga> it's so weird?
<mvo> zyga: aha, still in unstable, ok !
<zyga> it's not there
<mvo> mborzecki: thanks, looking
<mvo> pedronis: also looking :)
<mborzecki> mvo: quick HO?
 * mborzecki wonders if it's a larger problem
<pedronis> mborzecki: what problem?
<mvo> mborzecki: give me 2min to make a cup of tea, but then yes
<mborzecki> pedronis: looking at generateWrappers for snapd snap
 * zyga can join as well
<zyga> standup?
<pedronis> mborzecki: I should probably join as well
<mborzecki> pedronis: ack
<kbroulik> mborzecki: okay, cool
<kbroulik> what's the update policy for snapd on older ubuntu? Bionic seems to have the same 2.42.1, so it's safe to assume it is still being updated?
<zyga> kbroulik: snap version
<zyga> kbroulik: it's not 2.42.1 in practice
<zyga> kbroulik: it will use snapd from a snap (either core or snapd)
<kbroulik> ok, cool
<zyga> kbroulik: we regularly do updates of the classic package
<kbroulik> I have 2.42.5, so my patch will end up reaching bionic users, too, I guess :)
<zyga> kbroulik: but on some systems we also have this mechanism where you can get most of the new release without that
<zyga> kbroulik: yes, even 14.04
<kbroulik> cool
 * Chipaca looks around for things to set on fire
<zyga> Chipaca: bugs, burn them all
<cmatsuoka> Chipaca: RGB fans!
 * Chipaca sets all RGB fans on fire
<Chipaca> we could package an RGB fan controller as a snap
<Chipaca> and then one day update it without the --avoid-being-on-fire flag
<Chipaca> build flag*
<zyga> Chipaca: I'm so into RGB fans
<zyga> I plan to buy a few
<zyga> to compare them
<zyga> there are those magnetic levitation fans
 * Chipaca sets zyga on fire as a preventive measure
<zyga> that are supposedly quiet
<zyga> Chipaca: can it be RGB fire? :D
<zyga> I would only wish if the vendors did more work in the open
<zyga> to put the protocol of their things out
<zyga> so that people can write nice foss integration
<zyga> gnome-rgb-fan-omg-panel anyone?
<Chipaca> zyga: as long as the RGB aspect can be bought separately, and the market isn't inundated with cheap rgb fans such that the only way to get a no-nonsense one is to pay for a fancy one (or worse, a fancy one that actually allows you to turn it off), I don't really mind
<Chipaca> s/fans/fires/ also
<zyga> Chipaca: all RGB fans can be turned off, you know
<zyga> it's not like RGB is powered by the same cable
<zyga> (or if it is, I haven't seen those)
<Chipaca> hmmm
<zyga> though
<zyga> to be fair
<zyga> I would rather see another development
<zyga> steal a design idea from the mac pro
<zyga> and design towards cable-free systems
<zyga> mac pro has zero cables inside the case
<zyga> nothing is connected by a cable
<zyga> that's a lot of work
<zyga> but it's super clean and nice if you can have that
<zyga> even fans are powered by a contact connector
<zyga> *connector
<zyga> PCI graphics - bus powered using new high-current connectors
<zyga> power switch - pogo pins
<zyga> it's a lot of tweaking but I would love to see corsair or other vendors go that way
<zyga> e.g. case with contact connectors that can be used for front / rear fans
<zyga> with one cable that goes to the mobo
<zyga> instead of a zoo
<zyga> aaanyway
<zyga> not snapd :)
<zyga> imagine a PSU without any cables on it, just a card that slots into the board
<zyga> and the kernel now has time namespaces
<zyga> yay
 * zyga goes for a snow walk
<kbroulik> cool, ci passed \o/
<mup> PR snapd#8065 closed: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications <Created by kbroulik> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8065>
<zyga> kbroulik: thank you for the contribution!
 * zyga is back
<zyga> it's dark now
<kbroulik> alright, thanks zyga, mborzecki, and mvo. that went a lot more smoothly than I would have thought! :)
<zyga> :D
<zyga> kbroulik: it's even better
<zyga> kbroulik: because of the distribution system you can enjoy it from edge in a few hours :)
<zyga> take that classic packaging!
<kbroulik> heh
<mvo> kbroulik: nice, great to hear!
<zyga> mvo: https://forum.snapcraft.io/t/winter-2020/15231
<mvo> zyga: nice one!
<pedronis> mvo: mborzecki: I did a pass on #8001
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
 * zyga is cold
<zyga> tea
<mvo> pedronis: thank you so much!
<mborzecki> pedronis: cool, thanks, looks like i can address most of it in the morning
<mup> PR snapd#8066 closed: cmd/snap-confine: allow snap-confine to link to libpcre2 <â  Critical> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8066>
<pedronis> Chipaca: there isn't a GET on /users right ?
<Chipaca> pedronis: yes there is
<Chipaca> pedronis: returns a []userResponseData of all users
<Chipaca> pedronis: from state, that is
<mborzecki> damn, i'm late to a meetup
<pedronis> Chipaca: it's RootOnly though, ok
<Chipaca> pedronis: yep
<Chipaca> pedronis: all of these are
<Chipaca> pedronis: and in fact that's probably the strongest argument for _not_ making login/logout also go via /v2/users
<sil2100> Hey! Just wanted to touch base and make sure that the current snapd snap in stable is good for our ubuntu-core 18 18.04.4 images next week
<sil2100> mvo, pedronis, zyga: ^ can I use the current snapd safely for new images?
<sil2100> (uc18)
<zyga> ymmmm
<zyga> stable is always good
<zyga> or we change what it points at
<zyga> I think the answer is "always yes"
<Chipaca> sil2100: maybe coordinate with mvo as we're just wrapping up a release?
<zyga> Chipaca: yeah but that's coming in like ... two weeks :/
<zyga> (to stable)
<Chipaca> aw
<Chipaca> i thought it was also next week
<Chipaca> (it was two weeks two weeks ago :-P)
<zyga> I think it's after sergio is back plus then some
<zyga> for validation
<Chipaca> right
<zyga> but yeah
<zyga> sil2100: do wait for mvo's response
<pedronis> Chipaca: in #8059 Maciek's comment looks reasonable, I made some comments in #8061
<mup> PR #8059: daemon: implement user removal <Created by chipaca> <https://github.com/snapcore/snapd/pull/8059>
<mup> PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<Chipaca> pedronis: the more i think about the latter, the more i favour a boolean flag
<Chipaca> pedronis: digging into Response is nassty
<zyga> https://github.com/snapcore/snapd/pull/8067 is green :)
<mup> PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067>
<Chipaca> pedronis: wrt the former, i'll push those changes at the bottom of the pile if that's ok
<pedronis> Chipaca: I don't have a strong feeling, but the current code is maximally opaque
<pedronis> because it depends too much on knowing exactly what the other function does
<Chipaca> pedronis: not maximally! it no longer has resp.(*resp).Result.([]userResponseData) !
<pedronis> heh
<Chipaca> pedronis: thank you for your reviews
<Chipaca> pedronis: I will address this shortly
<Chipaca> i think i'll go to the gym first
<pedronis> Chipaca: the stuff in #8063 itself looks alright
<mup> PR #8063: many: remove users [DRAFT] <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<pedronis> nothing too surprising afaict
<Chipaca> pedronis: pushing that into individual PRs is still the right approach tho, right?
<pedronis> Chipaca: any particular reasons to do that?
<pedronis> it's not very big
<Chipaca> pedronis: keeping things easily reviewable
<pedronis> Chipaca: you can split client vs cmd/snap if you prefer
<pedronis> I don't have a strong feeling either way
<Chipaca> yeah that was the split i meant
<Chipaca> client, and then cmd/snap + spread
<pedronis> Chipaca: thank you
<Chipaca> ok
<Chipaca> but first, ex er ci ses
 * Chipaca goes
<sil2100> zyga, Chipaca: thanks guys ;)
<sil2100> Yeah, we'll probably be building image candidates Friday or Monday already
<zyga> mvo: the unit test that does go fmt checks needs to go :/
<zyga> it just doesn't pass anymore
<pedronis> zyga: where?
<zyga> pedronis: tests/unit/go on 20.04
<zyga> it fails and shows a diff about gofmt differences
<pedronis> I think we had the idea to use a specific go version with it
<pedronis> there's a go snap with quite a few tracks
<zyga> pedronis: yeah, but it's not used here, I think we should only fmtcheck on 16.04 or something
<zyga> the rest can just run unit tests
<pedronis> I'm probably misunderstanding what you said then
<mup> PR snapd#8059 closed: daemon: implement user removal <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8059>
<Chipaca> pedronis: I think I've made #8061 saner
<mup> PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<Chipaca> zyga: pedronis: I think the right thing is to skip it of running on non-<whatever gofmt we decided on>
<zyga> Chipaca: that's exactly what I did
<Chipaca> zyga: ah ok
<zyga> Chipaca: branch is coming up soon, all of 20.04 passes
<zyga> just one more run before I open
<Chipaca> zyga: weeâââ
<pedronis> Chipaca: thanks, comment on #8061
<mup> PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/8068 :)
<mup> PR #8068: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/8068>
<mup> PR snapd#8068 opened: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/8068>
<Chipaca> pedronis: fixed
<zyga> brb
<zyga> I need a coffee
<zyga> or maybe
<zyga> a coffee and a short break
<zyga> I'll be back to that OMG cool thing I'm doing :)
<zyga> o/
<pedronis> Chipaca: do I understand correctly that we let you remove users we didn't create?
<mup> PR snapd#8069 opened: tests: build the initramfs + kernel snap for UC20 spread tests <Precious Logs> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8069>
<sdhd-sascha> hmm
<sdhd-sascha> hmm
#snappy 2020-01-30
<mup> PR snapd#8068 closed: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8068>
<mvo> hey mborzecki
<mborzecki> mvo: hey
<zyga> Hey mvo
<mborzecki> mvo: pushed the change with link structure to #7972
<mborzecki> zyga: hey
<mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<zyga> I was woeking till 2am
<zyga> Somewhat sleepy still
<zyga> Kids woke me up
<zyga> Sick and staying at home
<mborzecki> zyga: i know you were playing c&c red alert :P
<zyga> I wish :-)
<zyga> I went for a walk at 2am
<zyga> With my sleeping dog in my hand :]
<zyga> He dislikes water so much I had to carry him for a while to convince him to walk
<zyga> I wrote first spread tests for apparmor prompting
<zyga> Iâll start later today
<zyga> Need to wake up first
<pedronis> mborzecki: mvo: hi, is one of you going to work on #8064 this morning?
<mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
<mborzecki> pedronis:  i was thinking about #8001 but i can look into 8064 first
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<pedronis> mborzecki: I made comment there and I didn't make on 8001
<pedronis> mvo extracted it
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
<mvo> mborzecki: thank you, I check 7972
<mup> PR snapd#8070 opened: dirs: fixlet for XdgRuntimeDirGlob <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8070>
 * Chipaca returns from the doctor's and has breakfast
<mup> PR snapd#8071 opened: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
<pedronis> Chipaca: ^
<Chipaca> pedronis: you ok with the toctou race there?
<pedronis> Chipaca: for now yes
<pedronis> the current behavior is kind of worse
<Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the system user, remove the home and spool
<Chipaca> your question last night left me thinking and that's what i thought we'd do
<Chipaca> er
<Chipaca> insert 'release the lock' after 'remove system user'
<pedronis> Chipaca: well, if you think is doable simply enough you can do it on top of my PR
<pedronis> otherwise leave possible todo
<Chipaca> gah i made a mess
<Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the auth user, release the lock, remove the home and spool
<Chipaca> ^ there better
<Chipaca> the split of the current remove-user-and-home being so as not to hold the lock for ages
<pedronis> yes, I understand that
<pedronis> Chipaca: I also think that snap remove-user email should do something, given create-user email
<pedronis> but that we can deal with it
<Chipaca> pedronis: given we're looking it up anyway, sure :-)
<pedronis> (it's a bit of a mess of its own)
<pedronis> because there might many users with the email and some might not have a username
<zyga> o/
<zyga> how are you guys
<Chipaca> zyga: we're latest/edgy
<pedronis> could be better
<zyga> tired?
<zyga> I'm energized, despite not sleeping much
<mborzecki> mvo: pedronis: i've updated #8064
<mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
<mvo> mborzecki: thank you!
<Chipaca> did the change to warn about invalid seeds get done?
<Chipaca> kenvandine: where should bugs for desktop-launcher go, on launchpad?
<pedronis> mborzecki: thanks, small remark
<Chipaca> mvo: maybe you know ^^
<mvo> Chipaca: do you know the package name? I guess not :) or a binary name in /usr or something?
<mborzecki> pedronis: ack
<Chipaca> mvo: i mean the snapcraft desktop laucnher helper thing
<Chipaca> desktop-helper? worker-dancer? warrior-priest?
<mvo> Chipaca: haha - sorry, now I get what you mean
<mvo> Chipaca: my guess is snapcraft itself but I'm not super confident, kenvandine will know but it's very early for him I guess
<Chipaca> you mean kenvandine isn't a robot?
<Chipaca> mvo: I think I'm leaving #1861177 as New so either you or Ian take a look at it when it's your triage day
<mup> Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:New> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177>
<mvo> Chipaca: nice! let me check that
<mvo> Chipaca: that looks pretty neat
<Chipaca> mvo: i'm assuming the <patch> bit :-)
<Chipaca> not the actual 'iz slow' bit
<mvo> Chipaca: yeah, the patch bit
<mvo> mborzecki: feedback in 7972, looks very nice now
<Chipaca> pedronis: I hope https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1860769/comments/3 isn't too much of a lie :-)
<mup> Bug #1860769: should record changes after snap transactions <etckeeper (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1860769>
<ogra> Chipaca, https://github.com/ubuntu/snapcraft-desktop-helpers/issues
<Chipaca> ogra: what part of 'on launchpad' is that
<Chipaca> also why is that still pointing people to rocketchat
<Chipaca> is rocketchat/snapcraft still a thing?
<ogra> o idea, but that tree is the source people typically include in their snapcraft.yaml to get the launchers
<ogra> s/o/no/
<mborzecki> mvo: can you take a look at #8064 ?
<mup> PR #8064: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
<pedronis> mvo: #8064 needs some kind of 2nd review
<mborzecki> if it's ok, i'll land it an update 8001 accordingly
<mvo> pedronis, mborzecki sure, on it
<pedronis> #8071 also needs a 2nd review
<mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
<mvo> pedronis: was looking at this one as we speak :)
<pedronis> mborzecki: 8064 should be ok to land once gree and then we can pick up 8001
<pedronis> green
<mup> PR snapd#8071 closed: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
<zyga> pedronis: (post merge) https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
<mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
<mborzecki> pedronis: ok
<pedronis> Chipaca: #8071 is in, you might want to update your PRs also consider zyga suggestion but I thought of it myself and not sure whether it makes the message too clunky
<mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
<Chipaca> pedronis: which suggestion would that be?
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
<Chipaca> grah, it now conflicts
<Chipaca> not fair
<pedronis> Chipaca: not suprising though, no
 * Chipaca takes a break
<mup> PR snapd#8064 closed: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8064>
<juliank> Hey folks, I ended up with 6 loop devices with deleted snap squashfs: https://paste.ubuntu.com/p/ry5ZKGqxCS/
<zyga> hey
<juliank> This machine has an uptime of 9 days
<juliank> It's running focal
<zyga> this is a known issue, it feels like a systemd / libmount bug
<zyga> we never manage loop devices ourselves
<zyga> it is reported on launchpad
<juliank> hmm
<juliank> The problem is that, as mentioned on #ubuntu-devel, these now show up in nautilus, confusing users (in this case, me)
<juliank> Not sure how to solve that
<juliank> Probably udisks should look if backing file is in /var/lib/snapd/snaps, and then set HintIgnore to true
<zyga> there's logic like that
<zyga> it's a different problem
<zyga> it shows up as deleted, unmounted loop device you can mount (??) by clicking on it
<zyga> but it isn't possible because it is deleted
<zyga> I really don't know what to do about it, apart from chasing kernel/libmount/systemd internals
<zyga> I think we used to have a reproducer script
<zyga> but perhaps I'm confusing this with another issue
<juliank> zyga: Oh you can absolutely mount them, the loop device still has an open file descriptor, so the inode is never actually freed
<zyga> the loop devices, yes
<zyga> the backing file they used is not linked to the filesystem anymore (but still takes space)
<juliank> yes
<juliank> Couldn't snapd like look once each hour / after it updates a snap for loop devices that point to deleted snap files and delete them?
<juliank> Hah no
<juliank> If I losetup -d the loop device it remains active
<ogra> well, effectively systemd should do this
<juliank> ogra: But I can't even do it manually, so something is off there
<juliank> Ah
<juliank> So closing my telegram window removed the loop device
<juliank> Which I guess means the loop device is used in a different mount namespace?
<ogra> hmm, doesnt for me .... but then ... unity7 here ...
<juliank> OK, I also ran losetup -d multiple times before, it might have marked it for dettachment
<ogra> yeah, that might be
<juliank> Confirmed
<juliank> The lxd snap still has deleted loop devices mounted
<juliank> /proc/1425517/mounts:/dev/loop53 /bin/kmod squashfs ro,nodev,relatime 0 0
<juliank> and various other processes
<juliank> I don't understand why the mount point is listed as /bin/kmod, though
<juliank> Running unmount /bin/kmod inside the namespace a few times made all except one lxd snap loop device go away
<ogra> lxd modprobing something inside the container ?
<ogra> probably squashfuse related ?
<zyga> juliank: if you come up with a reliable way to reproduce
<zyga> we can start chasing this more aggresively
<zyga> aggressively
<juliank> hmm I'm not sure I have time to come up with a reproducer
<juliank> Given the number of lxd in there, I'd sort of expect that just switching around lxd versions should trigger this, but not tried it
<mup> PR snapd#8070 closed: dirs: fixlet for XdgRuntimeDirGlob <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8070>
<pedronis> mvo: is #7999 ready for re-review?
<mup> PR #7999: devicestate: allow encryption regardless of grade <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
<mvo> pedronis: yes, I think so
<pedronis> mvo: it's failing though? it's a new initramfs to land?
<pedronis> *it needs
<mvo> pedronis: yeah, I pinged dimitri earlier
<mvo> pedronis: but yeah, this will only work once the initrd can open it
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8067#discussion_r372947893 please
<zyga> is that sensible?
<zyga> if so I'll make that happen and we can merge this
<zyga> maybe for .3?
<mup> PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067>
<zyga> mvo: we will have .3 - correct?
<mvo> zyga: well, maybe
<mvo> zyga: there is a (small) chance that we can get away witout
<mvo> without
<zyga> brb
<zyga> see you at the standup
<ijohnson> morning folks
<mborzecki> ijohnson: hey
<ijohnson> hey mborzecki
<mborzecki> ijohnson: 8064 landed, i've pushed some updates to #8001 and doing a little cleanup now, i'll push it after the standup hopefully
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<ijohnson> mborzecki: ack thanks for doing that
<mborzecki> ijohnson: or maybe i should push it to my fork, in case it's too dramatic :)
<ijohnson> mborzecki: how dramatic of a change is it ?
<mborzecki> ijohnson: splitting the boot state update 20 commit() into separate successful/candidate kernel code paths
<ijohnson> mborzecki: you meant a separate commit for setNext and markSuccessful ?
<ijohnson> err commit() method I mean
<mborzecki> ijohnson: yeah, actually doing that via 2 separate types, each implementing bootStateUpdate
<ijohnson> mborzecki: smells a lot like my rewrite I have locally for the next step with base snaps
<mborzecki> hahah ;)
<ijohnson> mborzecki: but sure feel free to push it, I can always re-work mine on top of yours
<sdhd-sascha> Hi, should i ask here, or on #maas, about:
<sdhd-sascha> # snap install maas
<sdhd-sascha> 2020-01-30T14:25:28Z INFO Waiting for restart...
<sdhd-sascha> error: cannot perform the following tasks:
<sdhd-sascha> - Run configure hook of "maas" snap if present (run hook "configure": chown: changing ownership of '/var/snap/maas/common/log/proxy': Operation not permitted)
<ijohnson> mborzecki: let me know when you've pushed that up
<mborzecki> ijohnson: sure
<zyga> sdhd-sascha: chown is usually not allowed, the exception is chown to a special snapd daemon user
<zyga> sdhd-sascha: I'm not sure if that's what maas is doing
<sdhd-sascha> zyga: i just installed the `apt` version. I tried the snap inside of lxd ...
<sdhd-sascha> maybe, i look later deeper into the script.
<zyga> sdhd-sascha: I don't know how that's related
<pedronis> mvo: Chipaca: I'm having a break, ping me later when you want to chat about download
<zyga> I'll grab lunch/dinner now
<zyga> and finish my cold soup :)
<mvo> pedronis: are you ok with picking 8067 for 2.43? if we have to do a release it seems like a nice and simple fix
<ijohnson> pedronis: mvo: mborzecki: sorry I forgot to inquire during SU, but shall I go with mvo's suggestion and extract the initramfs-mounts bits from #8001 into a separate pre-req PR, or are we looking okay to merge with that in there?
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<zyga> mmm
<zyga> yummy food today :)
<zyga> polish salad and veggie soup :)
<zyga> mvo: you should try the polish salad one day
<zyga> mborzecki: ^ do you know how it's called in English?
<zyga> random falures
<zyga> just love'm
<Eighth_Doctor> mmm failure :D
<zyga> just slower, travis stopped
<zyga> eh
<mborzecki> ijohnson: meh, i don't think i'll push it anytime today, got more complicated that i hoped
<pedronis> ijohnson: well, I reviewed that code and what it needs is really to be some kind of helper, I don't think splitting helps at this point
<pedronis> but maybe other reviewers have other preferences
<mborzecki> zyga: polish salad?
<zyga> mborzecki: yeah... geez how to explain that
<mborzecki> zyga: photo?
<zyga> https://www.google.com/search?q=sa%C5%82atka+jarzynowa
<zyga> something like this?
<mborzecki> zyga: ah, well, no clue whether there's an generally accepted english name for it, veggie salad? boiled veggie sald?
<zyga> but it's nothing like I've seen in other countries
<zyga> anywy
<zyga> we need a sprint in poland
<zyga> lodz would be great
<zyga> :)
<Chipaca> mvo: pedronis: shared a doc with you about download. GOing to step out for ~40 minutes, let's talk when i get back?
<pedronis> Chipaca: ok
<mup> PR snapcraft#2894 closed: Fix issue with multipass mount on win32 <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2894>
<mup> PR snapcraft#2895 closed: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2895>
<mup> PR snapcraft#2897 closed: meta: include environment in hook wrappers <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2897>
<mup> PR snapcraft#2898 closed: meta: remove dead code from snap packaging <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2898>
<ijohnson> pedronis: ok I asked mvo about splitting it and I think it's best to leave it in for now, and I can refactor the bootloader kernel bits in initramfs-mounts into a helper later
<ijohnson> mborzecki: sure, I will go through the rest of the comments in 8001 and address them then, perhaps you can cleanup anything else you need tomorrow AM
<sdhd-sascha> how can i debug or step this process:
<sdhd-sascha> ```
<sdhd-sascha> $ sudo snap refresh lxd
<sdhd-sascha> error: snap "lxd" has "auto-refresh" change in progress
<sdhd-sascha> ```
<sdhd-sascha> stop
<pedronis> Chipaca: back?
<Chipaca> pedronis: back
<Chipaca> sdhd-sascha: snap watch --last auto-refresh
<sdhd-sascha> Chipaca: thank you. It's seems to hang
<Chipaca> sdhd-sascha: snap tasks --last auto-refresh would be the next thing to look at
<pedronis> Chipaca: should we have the chat?
<sdhd-sascha> Is it normal, that three times `snap-confine` runs, like this:
<sdhd-sascha> ```
<sdhd-sascha> $ ps -Af | grep lxd
<sdhd-sascha> root        3504       1  0 Jan29 ?        00:00:49 lxcfs /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
<sdhd-sascha> root      264698    2355  0 05:10 ?        00:00:02 systemctl start snap.lxd.activate.service
<sdhd-sascha> root      264699       1  0 05:10 ?        00:00:00 /bin/sh /snap/lxd/13073/commands/daemon.activate
<sdhd-sascha> root      264758  264699  0 05:10 ?        00:00:00 lxd activateifneeded
<sdhd-sascha> root     2561183       1  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
<sdhd-sascha> root     2561205 2561183  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
<sdhd-sascha> root     2561206 2561183 98 17:53 ?        00:00:21 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
<sdhd-sascha> root     2561767 2554559  0 17:53 pts/7    00:00:00 sudo systemctl restart snap.lxd.daemon.service
<sdhd-sascha> root     2561768 2561767  0 17:53 pts/7    00:00:00 systemctl restart snap.lxd.daemon.service
<Chipaca> pedronis: I'll ping mvo and get a cuppa and yes
<pedronis> Chipaca: I'm in the standup
<mvo> Chipaca: here
 * sdhd-sascha I killed all the process. Now it seems to work
 * Chipaca resumes all the downloads
<mup> PR snapd#8067 closed: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8067>
<mup> PR snapcraft#2900 opened: Travis pr snapstore <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2900>
<pedronis> Chipaca: I added to your doc
<Chipaca> pedronis: thanks
<Chipaca> pedronis: I don't think I can wrangle that in tomorrow tho
<Chipaca> pedronis: that == the hmac option
<pedronis> Chipaca: that's fine, it's not hard to add once we have the basics
<pedronis> of the rest
<pedronis> HEAD support and resume params
<Chipaca> that one i probably can get up tomorrow :)
<pedronis> ijohnson: as far as I can tell this are the not yet applied/answered things in #8001: https://github.com/snapcore/snapd/pull/8001#discussion_r368975082 , https://github.com/snapcore/snapd/pull/8001#discussion_r372449659 , https://github.com/snapcore/snapd/pull/8001#discussion_r372451326
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<ijohnson> pedronis: this is what I have that I'm doing now https://pastebin.ubuntu.com/p/YsN6rDWqq4/
<pedronis> sounds right
<ijohnson> so I think your 3 things are contained in that
<ijohnson> good that we found the same things just about
<mup> PR snapcraft#2899 closed: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2899>
#snappy 2020-01-31
<mborzecki> morning
<zyga> Hey hey
<pedronis> #8061 needs a 2nd review (it's small)
<mup> PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<mborzecki> pedronis: zyga: mvo: hey
<pedronis> mborzecki: hi, should I re-review 8001 or will you push more to it?
<mborzecki> pedronis: pushed a little comment tweak, but it should be ok for re-review
<pedronis> thx
 * zyga-laptop has some stuff going on at home with friend dropping a dog for weekend
<pedronis> mvo: I never noticed that snap-bootstrap has a bootstrap subpackage just about creating partitions, it's a bit weird tbh
<mvo> pedronis: yeah, it's a bit of a leftover of the early days, I guess we need to clean this up
<pedronis> mborzecki: +1 on #8001 but there are still some things that need a cleanup
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<pedronis> mborzecki: let me know if you want me to address some of that or you can
<pedronis> the last comment is mostly a remark btw, it might get clearer when we split up commit in variants
<mborzecki> pedronis: i'll look into that
<pedronis> mborzecki: I'm fixing my first comment
<mborzecki> pedronis: ok
<pedronis> mborzecki: I did this: https://github.com/snapcore/snapd/pull/8001/commits/9906cdbbfcbf292e2e1e91c004dbba810e8bb0d8
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
 * pedronis has some quick errands to take care of
<mborzecki> pedronis: ok, on to 8001, have you pushed the comment fix?
<mborzecki> ah errands, i take that as a no then :)
<pedronis> mborzecki: I pushed a fix for my comment, not a a comment fix
<mborzecki> pedronis: ah, ok
<pedronis> mborzecki: what's left is comment in tests that seems not correct, they mention extraction in tests that test other things etc
<mborzecki> pedronis: updated now, tweaked the test a little bit too
<mborzecki> anyone can take a look at https://github.com/snapcore/snapd/pull/8060 ?
<mup> PR #8060: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8060>
<zyga-laptop> mborzecki ay
<mborzecki> zyga-laptop: hm? what broke?
<zyga-laptop> ?
<zyga-laptop> nothing
<zyga-laptop> I'm just saying I'll look
<zyga-laptop> :)
<zyga-laptop> but first, let me grab tea
<pedronis> mborzecki: thx
<pedronis> mvo: mborzecki: #8001 needs some kind of 2nd review
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<pedronis> #8036 needs a 2nd review
<mup> PR #8036: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <https://github.com/snapcore/snapd/pull/8036>
<ijohnson> pedronis, mborzecki should I remove the check in commit() for `if u20.env["kernel_status"] != "" {` ?
<pedronis> ijohnson: it was mostly a remark
<pedronis> ijohnson: we can think about it when we refactor
<pedronis> ijohnson: I'm more interested in this things landing atm
<pedronis> but it needs a review from somebody that is not me
<ijohnson> pedronis ack I'll wait for a review then
<mborzecki> yeah, not me either :P, mvo maybe?
<ijohnson> pedronis my refactor with the base snap is much simpler as commit () is 3 different functions for different scenarios
<mup> PR snapd#8072 opened: daemon, store: better expose single action errors <Created by chipaca> <https://github.com/snapcore/snapd/pull/8072>
<Chipaca> can I get a second review on #8061 ?
<mup> PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<zyga-laptop> mborzecki https://github.com/snapcore/snapd/pull/8060#pullrequestreview-351447565 +1
<mup> PR #8060: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8060>
<mborzecki> Chipaca: do we get to kill /v2/create-user?
<Chipaca> mborzecki: thank you for the review
<Chipaca> mborzecki: not at this point in time
<Chipaca> mborzecki: killing it would mean adding a deprecation notice, and removing it in N releases
<Chipaca> that has not been done
<Chipaca> mborzecki: instead we stop talking to it and hope it gets bored and goes away, i guess? :-)
<mborzecki> hahah
<mborzecki> or return an error telling to use the new api
<Chipaca> mborzecki: but, i think we're stuck with it for a good while anyway; people are using it for its intended purpose on devices in the wild
<Chipaca> 'people' here includes some big companies, but also some small companies like us via mwhudson iirc
<Chipaca> zyga-laptop: how was your famous phrase? "nothing can break with this" but much more nicely said
<zyga-laptop> the one where everything breaks? :D
<zyga-laptop> <zyga> There is no breaking or risky change induced by this branch.
<zyga-laptop> Chipaca ^
<ogra> was ther a T-Shirt ?
<ogra> *there
<zyga-laptop> haha
<zyga-laptop> I wish
<Chipaca> zyga-laptop: thanks
<Chipaca> zyga-laptop: used it in my latest
<mup> PR snapd#8073 opened: daemon: drop support for the DELETE method <Created by chipaca> <https://github.com/snapcore/snapd/pull/8073>
<Chipaca> ^
<zyga-laptop> if it fails it's the official label for <complex> tag
<zyga-laptop> Chipaca final commit of the week? :)
<Chipaca> zyga-laptop: ~4 more to come
<mup> PR snapd#8061 closed: daemon: make users result more consistent <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8061>
<pedronis> mmh, 8001 will likely conflict with 7705, another reason to try to get it in today
<mup> PR snapcraft#2901 opened: python plugin: do not leak snapcraft's site-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2901>
<mup> PR snapd#8074 opened: client: move to /v2/users; implement RemoveUser <Created by chipaca> <https://github.com/snapcore/snapd/pull/8074>
<mvo> mborzecki: re "yeah, not me either :P, mvo maybe?" - which review was that?
<Chipaca> hmm
<Chipaca> in a purported 16.04.5 install:
<Chipaca>     snapd is already the newest version (2.0.2).
<Chipaca> hmmÂ²
<pedronis> mvo: 8001
<mup> PR snapd#7812 closed: asserts: parse plug-names/slot-names constraints  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7812>
<mup> PR snapcraft#2902 opened: static: fix some valid flake8 issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2902>
<cmatsuoka> Chipaca: https://github.com/askervin/python-il/
<Chipaca> cmatsuoka: micropython's had that for ages :-D
<mup> PR snapcraft#2903 opened: tests: fix status test for staging store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2903>
<Chipaca> cmatsuoka: you should check micropython out sometime, if you haven't
 * cmatsuoka checks
<Chipaca> hah, 6 years down the road I'm still contributor #6 :-)
<Chipaca> i guess some things move slowly after a point
<Chipaca> ah no, #8 now
<mup> PR #8: launchpad.net/snappy -> github.com/ubuntu-core/snappy <Created by chipaca> <Merged by elopio> <https://github.com/snapcore/snapd/pull/8>
<Chipaca> good
<Chipaca> mup: shaddup you
<cmatsuoka> haha
<mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<Chipaca> mup: from where i'm sitting it looks like you respond to unknown commands as well, tbh
<mup> Chipaca: In-com-pre-hen-si-ble-ness.
<pedronis> Chipaca: you are #4 by additions
<Chipaca> hehe
<Chipaca> it's not the size of the pull requests, it's how you use them
<Chipaca> or something
<pedronis> Chipaca: all those stats are questionable
<Chipaca> mhmm
<mup> PR snapcraft#2904 opened: meta: move Snap's from_dict() system-username parsing into new method <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2904>
<mup> PR snapcraft#2905 opened: requirements-devel: uprev pyinstaller to 3.6 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2905>
<ijohnson> good morning for real this time folks
<mborzecki> ijohnson: hey!
<ijohnson> hey mborzecki
<mborzecki> off to school
 * zyga afk for lunch and stuff
<mup> PR snapcraft#2906 opened: [ignore me] travis test <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2906>
<Chipaca> pedronis: d'oh, was in such a hurry i didn't add tests :-|
<roadmr> ð±
<pedronis> Chipaca: well, we might pick it up unless missing that blocks the follow ups
<mborzecki> re
<Chipaca> roadmr: hush, you
<Chipaca> pedronis: nah i'll get to it in a bit
<roadmr> ð¯
<roadmr> ð¤«
<pedronis> Chipaca: on another PR I find funny that you added single error wrapping, while you removed in another
<pedronis> I wouldn't add it given it wasn't there and I don't think it relates to what that PR is trying to achieve
<Chipaca> pedronis: ah, probably true, i think that's a mis-change
<Chipaca> pedronis: also i think that bit isn't tested (otherwise there'd be a change in the test and i don't see it)
<pedronis> yes, as well to that
<Chipaca> as in, it wasn't tested before my refactor i mean
<pedronis> anyway another reason not to touch that bit in particular
<Chipaca> mhmm
<Chipaca> mborzecki: pedronis: I've addressed your feedback on #8074
<mup> PR #8074: client: move to /v2/users; implement RemoveUser <Created by chipaca> <https://github.com/snapcore/snapd/pull/8074>
<cjp256> Any thoughts on what would cause a `Cannot retreive credentials in unknown state` when running `snap set system experimental.snapd-snap=true`?
<cjp256> nvm, that's coming from multipass exec
<mborzecki> Chipaca: thx!
<ijohnson> afk for a little bit
<pedronis> Chipaca: yes, all the error paths are not tested in users, something for us at some point
<pedronis> I mean in client/users.go
<Chipaca> pedronis: un P || Q && R, R is only evaluated if !P and Q
<Chipaca> pedronis: right?
<pedronis> yes, just me being confused for a second
<Chipaca> ah ok
<pedronis> otoh some parenthesis wouldn't hurt
<Chipaca> i mean, i always think of it as wrong-associative, but :)
<Chipaca> pedronis: yep
<Chipaca> pedronis: pushing that in a sec
<Chipaca> going to take a break now, will bbl to continue punishing travis
 * Chipaca not gone yet
<mvo> ijohnson: 8001 is good from my POV, just one concern about the panic() in there but that can be a followup, let's get the next one up :)
<ijohnson> Thanks mvo looking now
<ijohnson> ah just missed him oh well
<mup> PR snapd#7813 closed: interfaces/policy: enforce plug-names/slot-names constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7813>
<pedronis> ijohnson: yes, looks like he was looking at some code, because I commented on that in https://github.com/snapcore/snapd/pull/8001#discussion_r372451985 and mborzecki fixed it already
<mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<pedronis> *some old code
<ijohnson> yes probably some github ui issue
<ijohnson> pedronis: should I merge now then?
<pedronis> ijohnson: I would say yes, anyway commit itself will be refactored again
<pedronis> afaiu
<ijohnson> pedronis: ack, yes I have refactored it
<mup> PR snapd#8001 closed: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<mborzecki> yay!
<ijohnson> yay indeed!
<pedronis> ijohnson: there was indeed a conflict with pawel PR but I pushed a fix hopefully already
<pedronis> #8036 needs a 2nd review
<mup> PR #8036: snapstate: refactor things to add the re-refresh task last <Created by pedronis> <https://github.com/snapcore/snapd/pull/8036>
<ijohnson> pedronis: which of pawel's PRs?
<pedronis> ijohnson: #7705
<mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
<ijohnson> pedronis: ah right, I have that on my list to review, I'll try to get to that today or Monday
<mup> PR snapcraft#2902 closed: static: fix some valid flake8 issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2902>
<mup> PR snapcraft#2905 closed: requirements-devel: uprev pyinstaller to 3.6 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2905>
 * Chipaca kicks travis a bit more
<mup> PR snapcraft#2903 closed: tests: fix status test for staging store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2903>
<ijohnson> ugh travis why do you have to be broke right after I merged my PR :-(
<Chipaca> ijohnson: it had a troubled childhood and has difficulty expressing its love for you
<ijohnson> Chipaca: all that kicking probably didn't help
 * Chipaca punts it back into orbit
<Chipaca> ijohnson: what kicking
<ijohnson> tbh I probably wouldn't work too well either if somebody kept kicking me every time I did something wrong
<Chipaca> ijohnson: travis is the whipping boy
<ijohnson> I'd just like to take this opportunity to thank travis for not being able to kick us back
 * Chipaca actually LOLs
<zyga> Chipaca: are you lol'ing as eod-ing? :)
<sdhd-sascha> hey "folks" ;-)
<sdhd-sascha> is to say, the word "folks" okay ? for woman, man, and ... ?
<sdhd-sascha> is it ?
<sdhd-sascha> (sorry, sometimes i make failures. )
<ijohnson> sdhd-sascha: yes folks is okay for a generic group of people
<sdhd-sascha> ijohnson: thank you :-) *great* ... i'm really poor in language's .. (but i grow) ;-) thank you
<ijohnson> np
<sdhd-sascha> :-)
<sdhd-sascha> ijohnson: still, and again - thankyou
<mup> PR snapcraft#2908 opened: Tt <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2908>
<mup> PR snapcraft#2906 closed: [ignore me] travis test <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2906>
<mup> PR snapcraft#2908 closed: Tt <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2908>
<mup> PR snapd#8074 closed: client: move to /v2/users; implement RemoveUser <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8074>
<Chipaca> #8063 is now open for business
<mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
<mup> PR snapd#8075 opened: boot: don't use "kernel" from the modeenv anymore <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8075>
 * sdhd-sascha Chipaca sorry for me ;-)
<Chipaca> sdhd-sascha: ?
<sdhd-sascha> Chipaca: i'm not so easy - sometimes ;-) i love your hints ;-)
 * sdhd-sascha sometimes i have too much beer ...
<Chipaca> sdhd-sascha: glad you enjoy them, but i'm at a loss as to which ones in particular you mean this time :-D
<sdhd-sascha> Chipaca: as i said - you give me hints, which are very cool, and i understand . not in time. but shorten ... you have a nice way to write ;-)
<sdhd-sascha> Chipaca: i love your sarcasm ;-)
<Chipaca> :-)
<sdhd-sascha> ;-)
 * sdhd-sascha afk - look for my wife... 
 * sdhd-sascha back (for a moment) .. is it bad, that i can better talk to you folks... ? i cant say it to ....
<Chipaca> sdhd-sascha: Â¯\_(ã)_/Â¯ it happens :-)
 * Chipaca takes the dog for a wander
 * sdhd-sascha i wonder, Chipaca how you type this ;-) thank you - make me smile ;-)
<sdhd-sascha> hey, ;-) look forward
<mup> PR snapd#8076 opened: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8076>
 * ijohnson EOWs
<mup> PR snapd#8077 opened: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
 * sdhd-sascha how much is too much talk ... can i be litte crazy
#snappy 2020-02-01
<mup> PR snapd#8078 opened: daemon, store: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
<mup> PR snapcraft#2900 closed: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2900>
<wxl> hey folks. when should we expect a proper 2.43 upload for focal? the ~pre1+20.04 version is a little stale
#snappy 2020-02-02
<mup> PR snapd#8079 opened: overlord/snapstate, wrappers: manpages! <Created by chipaca> <https://github.com/snapcore/snapd/pull/8079>
