#snappy 2015-04-13
<fishcooker> apk ini apkah di surabaya kah?
<fishcooker> *sorry typo
<jchodyniecki> installed snappy on ESXi, virtualbox, and vagrant and the ubuntu/ubuntu user/pass doesn't work on any of them
<jchodyniecki> any help?
<JamesTait> Good morning all; happy Monday and happy Scrabble Day! :-D
<dholbach> mvo, https://code.launchpad.net/~dholbach/click-reviewers-tools/run-pyflakes3/+merge/255821
<fionnan> Anyone getting `ERROR: Could not generate AppArmor profile for docker_docker_1.5.0.002.json...` when installing docker on a fresh snappy instance?  Traceback is here: http://pastebin.com/ChQmLUmq
<mterry> snappy-go no longer allows you to build a snap with an unknown framework?
<pendigging> Recently update snappy app docker 1.5.0.002 fails to install on ubuntu core dev 15.04.
<pendigging> ubuntu@localhost:/var/log$ sudo snappy install docker docker      8 MB     [====================================================================================================================================================]    OK     ERROR: Could not generate AppArmor profile for 'docker_docker_1.5.0.002.json'. Skipping Traceback (most recent call last):   File "/usr/lib/snappy-systemd/systemd-snappyhook", line 198, in <module>  
<pendigging> Any workaround?
<ogra_> asac, ^^^^
<ogra_> two people already
<fionnan> yup
<jdstrand> pendigging: are you using the latest promoted image or the latest devel-proposed?
<jdstrand> pendigging: actually, can you paste: system-image-cli -i
<pendigging> ubuntu@localhost:~$ system-image-cli -i current build number: 145 device name: generic_amd64 channel: ubuntu-core/devel last update: 2015-02-24 19:19:17 version version: 145 version ubuntu: 20150223.2 version raw-device: 20150223.2 ubuntu@localhost:~$
<jdstrand> let me try
<jdstrand> pendigging: ah, that is the old promoted image
<jdstrand> fionnan: hey, can you give the output of: system-image-cli -i
<jdstrand> pendigging: you need to update your system with snappy update and reboot
<pendigging> jdstrand:   Tx much!   I will give it a whirl!
<fionnan> jdstrand: yup, here you go
<fionnan> http://pastebin.com/NLt2exvx
<pendigging> jdstrand:  That worked for me.  Again, tx :-)
<jdstrand> fionnan: right, the same thing I told pendigging applies to you. you need to update your system with snappy update
<jdstrand> pendigging: nice!
<jdstrand> asac: re ogra's ping, I handled it
<dholbach> links:
<dholbach> http://developer.ubuntu.com/snappy
<dholbach> https://developer.ubuntu.com/snappy/porting/
<lool> thnka dholbach
<dholbach> https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/docs/
<dholbach> anytime
<lool> repeating for the couple of recent joiners
<lool> http://developer.ubuntu.com/snappy
<lool> https://developer.ubuntu.com/snappy/porting/
<lool> https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/docs/
<elopio> http://www.wefearchange.org/2015/04/creating-python-snaps.html
<elopio> I'm playing with ^
<lool> slide deck with links: https://docs.google.com/a/canonical.com/presentation/d/1DCeQ1lSsZQaGAyUeJGOdCbTVstG1DYViw9wc2GUpK7w/edit#slide=id.g606de2313_017
<lool> sergiusens: the porting guide says snappy-dev/beta for the PPA with latest device-flash; I'm using snappy-dev/tools though; which one is the right one?
<lool> NB: there are trusty users here
 * ogra_ always uses phablet-team/tools 
<ogra_> :P
<fionnan> jdstrand: Cheers!
<sergiusens> lool: I'm on trusty
<sergiusens> lool: and using the tools ppa, that said I need to copy it to beta
<lool> sergiusens: I told everyone to use the tools PPA now
<lool> sergiusens: do you have the power adapter for the ninja SDK? if not, what's the voltage?
<vila__> mvo: https://bugs.launchpad.net/ubuntu/+source/snappy/+bug/1443557 feel free to re-assign
<mvo> vila__: thanks, I put it on our trello board
<elopio> jodh: ping. We are at the snappy sprint and they told us you have been running tests.
<elopio> jodh: could you join #ubuntu-quality and tell us which kind of tests have you been running, and the kind of errors you have found?
<tgm4883> Having difficulty getting the snappy image booting on the beaglebone black. following the instructions on http://www.ubuntu.com/things#try-beaglebone I've got the image on the micro SD card, but when the card is inserted I don't seem to get anything happening on the beaglebone. Just the one power light
<tgm4883> puting other things on the card (debian, ubuntu) boots up fine
<lool> hwang4: https://docs.google.com/a/canonical.com/presentation/d/1DCeQ1lSsZQaGAyUeJGOdCbTVstG1DYViw9wc2GUpK7w/edit
<hamo> mvo: ping
<mvo> hamo: pong
<hamo> mvo: Hi...https://bugs.launchpad.net/ubuntu/+source/snappy/+bug/1443599
<hamo> mvo: I found some issue during usage
<hamo> mvo: and I have proposed a patch, could you help to review it?
<mvo> hamo: YES, sounds great, let me have a look
<hamo> mvo: thanks :-)
<hamo> mvo: I saw you approve it... Thanks very much for your reivew
<hamo> mvo: what should I do next?
<mvo> hamo: hm, let me think about this for a minute or two
<lool> Nikolay: http://people.canonical.com/~ogra/ninja/README
<lool> ogra_: ^ was that the latest ninja sdk bits you had?
<lool> ogra_: we're running a hands on workshop and I've proposed Nikolay to create an OEM snap for ths board
<sergiusens> hamo: if you want to contribute, maybe adding support for snappy info to list the oem snaps if they exist
<sergiusens> hamo: or the other one would be to have snappy list follow the spacing spec
<tbo_> can I chroot into snappy from ubuntu?
<sergiusens> mvo: Chipaca https://code.launchpad.net/~sergiusens/snappy/installFactorX/+merge/256042
<Chipaca> sergiusens: when you feel like taking a break, https://code.launchpad.net/~chipaca/snappy/touch/+merge/255650
#snappy 2015-04-14
<jchodyniecki> anyone available for a silly question?
<jchodyniecki> maybe mahmoh or kirkland? or anyone
<jchodyniecki> guess I'm 0 for 91 here
<JamesTait> Good morning all; happy Equal Pay Day! :-D
<zbenjamin> does anyone know where mvo is these days?
<ogra_> zbenjamin, at a sprint i think ...
<ogra_> US timezone
<zbenjamin> ogra_: aaa ok, makes sense
<zbenjamin> ogra_: right there is a sprint in austin afaik
<zbenjamin> ogra_: what would be the right way to hack around on snappy in a VM?
<zbenjamin> ogra_: do we have any images
<ogra_> i never used it in a VM :)
<zbenjamin> ogra_: heh, how do you use it ? :)
<ogra_> but i think there are instructions for runnin it in KVM on the website somewhere
<ogra_> on arm boards
<ogra_> once you have it running you should be able to ssh into it or open the webdm UI in a browser ...
<ogra_> http://www.ubuntu.com/cloud/tools/snappy
<ogra_> that has a KVM section
<zbenjamin> ogra_: aa nice thank you
<sergiusens> cprov: http://people.canonical.com/~ogra/snappy/odroidc/
<ogra_> sergiusens, that *might* need a re-spin for the latest release ... havent done one since the last milestone ...
<sergiusens> no worries
<cprov> sergiusens: thanks
<ezobn> Hi All, Can the "repository"/store for the snappy packages be installed localy  ?
<ogra_> no
<ezobn> ogra_: Is it available in commercial terms ? Or some other ideas here ?
<ogra_> ezobn, ah, i dont know ... beuno might though
<beuno> ezobn, hi
<beuno> what do you mean?  as in, run your own version of the store?
<ezobn> beuno, yes. To have scenario like vCPE for the telcom and application delivery using localised store.
<beuno> ezobn, you can't run it locally, we do offer a sub-store for products
<beuno> still hosted by us, but you have control over what goes into it
<beuno> in some cases, we will offer a local proxy, so clients don't need to talk outside of the network to get updates
<mvo> jdstrand: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image
<jdstrand> thanks
<ezobn> beuno, good to know, the idea for the local proxy is to deliver updates to not get it all from outside network, decrease amount of possible traffic or so ?
<beuno> ezobn, yeah, different people want to lock down networks for different reasons
<beuno> for some it's security, some bandwidth
<ezobn> beuno, thanks, got the point.
<sergiusens> zbenjamin: ah yes you are
<sergiusens> mvo: raise your ears just in case :-) (or eyes)
<sergiusens> zbenjamin: I'd rather have mvo be the main stakeholder here ;-)
<sergiusens> zbenjamin: we don't have a concept of hand holding builds with snappy
<sergiusens> like click chroots didd
<zbenjamin> sergiusens: hm yeah i just had the idea that it would be nice and more lightweight to create a buildenv with the snappy tools
<zbenjamin> sergiusens: since we already have package versioning and so on
<sergiusens> zbenjamin: right, we have no versioning in snappy either
<zbenjamin> sergiusens: you can do rollbacks no?
<sergiusens> zbenjamin: yes
<sergiusens> zbenjamin: but there is no dependency chain that ties you to the versioning
<zbenjamin> sergiusens: thats what i meant, so lets say you want to build a specific snap, you need a rootfs with the dependencies. The rootfs builder could read your dependencies and install them into a core rootfs
<sergiusens> zbenjamin: as in, in the click world you could depend on ubuntu-sdk-13.10
<zbenjamin> sergiusens: yes, but i can depend on frameworks in the snappy world
<zbenjamin> or did i get that wrong
<sergiusens> zbenjamin: yes, you can
<sergiusens> zbenjamin: for native builds you might want to look at what lool did
<zbenjamin> sergiusens: if it uses schroot then thats exactly what we would like to prevent...
<sergiusens> zbenjamin: just take into account, snappy rootfs don't have apt (and won't have dpkg)
<zbenjamin> sergiusens: schroot has proven to be slow and unstable in the SDK.
<zbenjamin> bzoltan: ^^^ jus t case you want to read as well
<zbenjamin> sergiusens: so for example schroot leaks mounts. For any reason a click chroot .. run is killed or terminated it will leave mounts behind. Those mounts are restored on boot.... We had people with 16k mounts
<zbenjamin> sergiusens: also the mount/umount on every command is horribly slow
<sergiusens> zbenjamin: https://lists.ubuntu.com/archives/snappy-devel/2015-March/000415.html
<zbenjamin> sergiusens: ah teh devpacks yeah
<zbenjamin> sergiusens: ok i thought the devpacks would be installed by snappy as well
<zbenjamin> sergiusens: the idea was that i can construct the rootfs from outside. and then use it as chroot/sysroot/whatever
<zbenjamin> sergiusens: but reverting it to a clean state is the problem here
<elopio> ping ogra_, if I install your chatroom snap in kvm, what is the url?
<sergiusens> zbenjamin: that's snapcraft; but I suggest to reply with that in the rfc email which needs some interaction love
<sergiusens> elopio: don't forget to -redir if using kvm
<sergiusens> elopio: and you can check by looking at the ports entry in package yaml maybe
<ogra_> elopio, $ip:6565/
<ogra_> elopio, for kvm you need to forward that port somehow
<ogra_> then i think localhost:6565 might work
<elopio> sergiusens: where should I use -redir ?
<ogra_> you likely use it already in your kvm commandline
<ogra_> just add another redirect for the 6565 port
<elopio> got it.
<ogra_> elopio, and thanks for the blog comment !!
<elopio> ogra_: this is really cool actually. Thanks to you for the magic tool.
<ogra_> :D
<zbenjamin> sergiusens: sadly i can not answer to that mail. I just registered for the snappy-devel ML
<elopio> where do I report a bug for snappy-remote?
<lool> ogra_: would you know where the pins for the serial console are on the ninja sphere develoepr kit?
<lool> ogra_: nevermind, found it
<fishcooker> is anyone here with "Screen version 4.00.03 + CentOS release 6.6 " that support vsplit release?
<fishcooker> err sorry wrong channel
#snappy 2015-04-15
<JamesTait> Good morning all; happy Microvolunteering Day! :-D
<sergiusens> jodh: hey, your udf branch looks good
<sergiusens> jodh: I just have a minor thing to discuss
<jodh> sergiusens: sure
<sergiusens> the location of where we flag this becomes a problem once we support factory reset
<sergiusens> jodh: what do you think about storing it somewhere in /boot?
<sergiusens> I just thought /boot as it's a common location contrary to system-a/b
<jodh> sergiusens: unless the reset detected the sideload and replaced that file after a format. But yeah, I guess the simplest+safest option is to use /boot.
<tbr> so, I'm trying out snappy. Downloaded the alpha2 vm as told in the tutorial. got the examples. built. tried to deploy. It fails.
<tbr> a) if I update the image it fails completely - missing signature
<tbr> b) with the image as is it asks repeatedly, mumbles about an override and installs it
<tbr> my question is: how do I a) sign a package b) add the key as trusted to the core image
<tbr> querying the web search engine of my least distrust yields no usable results.
<tbr> https://bugs.launchpad.net/snappy-ubuntu/+bug/1443676 is also not really helpful, but at least indicates that I'm not the only one having a problem
<tbr> oh, and downgrading the "ubuntu-core-alpha-02_amd64-virt.img" image once it's upgraded fails "Unable to determine bootloader"
<tbr> pointers to be able to RTFM appreciated
<Nikolay> lool: lcf@lcf-ThinkPad-W510 ~/austin/rpi2 $ sudo ubuntu-device-flash core --platform bcm2836-rpi-2-b --size 4 --oem ./pi2.lool_0.10_all.snap --developer-mode --device-part=device-pi2-0.9.tar.xz -o rpi2.img Determining oem configuration 2015-04-15 14:40:14 ERROR snappy logger.go:199 Signature verification failed with exit status 14 Signature verification failed with exit status 14
<lool> sergiusens: that was it
<ogra_> tbr, i think there was a newer release inbetween ... the version on TFM might be outdated (not following snappy much recently so take that with a grain of salt)
<tbr> ogra_: so the tutorial bits are all there is?
<ogra_> not sure, there might be blogs etc about vm images ... i always only used snappy on real hardware (real = ARM :) )
<tbr> well, a BBW is on my desk waiting
<tbr> but for that I'd like to know how I integrate with a custom kernel as I'd like to be able to use the 6loWPAN stack in Linux 4.0
 * tbr didn't want to get ahead of himself and opted for a "quick boot of vm image as recommended by tut"
<mterry> kirkland, hey btw, I snappified tmux with my scripts and it works fine if you build it with an unconfined profile (needed some /dev access) -- or probably if you used snappy hw-assign to let it access the right /dev.  Anyway, try building like so:  ./make-snap -d 15.04/beta-2 --aa-template unconfined tmux
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/polishit/+merge/256358
<Chipaca> sergiusens: interesting name :)
<sergiusens> :-P
<ogra_> sausages !
<jdstrand> pitti: lxc-usernsexec -m b:0:1000:1 /bin/bash
<pitti> jdstrand: cheers
<jdstrand> obviously I didn't unshare, etc there, but that is the format of -m
<sergiusens> beuno: https://bugs.launchpad.net/software-center-agent/+bug/1443537
<mvo> pitti: what does your subuid file looks like again ?
<pitti> mvo: martin:100000:65536
<pitti> mvo: but I don't think we actually need that
<pitti> mvo: you can e. g. call lxc-usernsexec -m b:0:`id -u`:1 -- unshare -m
<pitti> mvo: that's what I'm doing in my prototype now
<mvo> pitti: cool
<pitti> mvo, jdstrand: \o/ working
<mvo> pitti: does still also work if you remove martin from /etc/subuid
<mvo> ?
<pitti> mvo: it did for jdstrand
<mvo> pitti: nice!
<jdstrand> mvo: I had to create the mapping on the fly
<pitti> mvo: yes, works fine here
<jdstrand> mvo: with the -m option
<pitti> I commnted out everything
<pitti> so /etc/sub[ug]id mostly seems to be a default for -m
<mvo> pitti, jdstrand: I'm still having trouble to get from  uid 0 back to 1000 inside the shell I unshared. but I will come over to you soon
<pitti> mvo: yeah, that's so much easier to do in C
<mvo> pitti: hm, I can setuid(0) but can't setuid(1000) anymore, I guess I need to setup a new mapping
<dholbach_> slangasek, do we have something like the table on https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/ for snappy?
<mvo> sergiusens: lp:~mvo/snappy/snappy-fix-hooks-rootdir-wrong-symlink
<sergiusens> mvo: works fine
#snappy 2015-04-16
<tbr> so is the process of getting those snap packages on a current image a nation state secret?
 * tbr still hasn't found a way to sign or do disable the signature check
<JamesTait> Good morning all; happy High Five Day! :-D
<ogra_> tbr, --allow-unauthenticated ... (as snappy install option)
<tbr> ogra_: $ snappy-remote --url=ssh://192.168.122.121 --allow-unauthenticated install ./hello-world.canonical_1.0.5_all.snap
<tbr> ogra_: unknown flag `allow-unauthenticated'
<ogra_> oh, remote ... that i dont know ...
<tbr> remote is what TFM tells me to use
 * ogra_ just uses an ssh shell usually
<ogra_> scp ... snappy install ...
<tbr> ok, that I can try
<tbr> the whole "forget everything you learned about package management and apt" thing makes me approach this from TFM side, instead of trying random things
<ogra_> yeah, but everyone is busy ... the manuals are often a bit behind and updated last once a feature works
<ogra_> and alongside, everyone is at a sprint in US TZ
<ogra_> which doesnt make IRC actually a good place this week
<ogra_> (for support)
 * tbr mumbles something about potemkin villages and goe sto figure this out the hard way
<tbr> ubuntu@localhost:~$ snappy --allow-unauthenticated install /tmp/hello-world.canonical_1.0.5_all.snap
<tbr> unknown flag `allow-unauthenticated'
<tbr> this is from inside the image
<tbr> Name        Date       Version Developer
<tbr> ubuntu-core 2015-04-10 146
<ogra_> i think install needs to come first
<tbr> ok, now it asks for root, progress
<tbr> yay. it installed.
<ogra_> \o/
<tbr> so I guess the only way to get something workable is to toss out snappy-remote and reinvent the wheel with a wrapper script around scp and "ssh ubuntu@foo sudo snappy install --allow-unauthenticated $bar"?
<ogra_> yeah, i think there is a bug open for that somewhere
<tbr> yes, I found it and it was not helpful
<ogra_> bug 1443676
<ogra_> bah, no bot ?
<tbr> https://bugs.launchpad.net/snappy-ubuntu/+bug/1443676
<ogra_> https://bugs.launchpad.net/bugs/1443676
<ogra_> heh
<ogra_> *snap*
<ogra_> :P
<tbr> :>
 * dholbach hugs davidcalle
<davidcalle> :-)
<davmor2> davidcalle: if dholbach said and maybe jump off a cliff....... ;)
<davmor2> davidcalle: on a more serious note \o/
<davidcalle> davmor2, I would... I would not... that's a hard question, I trust him! :p
<davmor2> davidcalle: hahaha :)
<davidcalle> dholbach, are there install instructions for the raspi2 we could include in /install? (I know it's an image ready to burn, but we should probably have a small something)
<dholbach> davidcalle, not yet - I'll find out more though
<dholbach> davidcalle, https://lists.ubuntu.com/archives/snappy-devel/2015-April/000463.html
<dholbach> I'll talk to lool- once I see him around here
<dholbach> and see if the instructions are going to get any more official
<dholbach> the great thing is that all devices which have oem snaps in the store can just use ubuntu-device-flash to have their image created on the fly
<dholbach> so we can at some stage just have a big table with instructions for lots of different devices :)
<lool-> dholbach: had to step out for a call sorry
<dholbach> lool-, no worries
<davidcalle> dholbach, thanks
<davidcalle> lool, hey :)
<dholbach> davidcalle, I'll note down to add a table to install/devices (or shall we call it start/devices)?
<dholbach> sorry start/things
<lool> davidcalle: heya
<lool> davidcalle: how goes?
<davidcalle> dholbach, start/devices sounds great to me
<davidcalle> lool, all is well, you?
<dholbach> davidcalle, I think dpm wanted to call it things (just like ubuntu.com/things)
<dholbach> but yeah, I'll rename the 'install' section to 'start'
<dholbach> that'll also set the direction for the /start
<dholbach> we could add content like "hey, install the ppa" first because it's going to be relevant for everything else
<lool> davidcalle: well well
<davidcalle> dholbach, +1
<dholbach> cool, I'll start work on this in half an hour or something
<mterry> jdstrand, did that framework bug get fixed?
<mterry> asac, can I be in ~snappy-dev?
<jdstrand> mterry: it is supposed to be in 0.3.7. I got a report that it may not be, however the 'snaps don't specify release framework' work that landed means there is another bug now
<jdstrand> I'm looking at it now
<mterry> jdstrand, OK.  So I should continue not to specify a framework  :)
<jdstrand> for now-- don't update your image just yet either :)
<jdstrand> mterry: I suggest not upgrading and not specifying the framework for now. hopefully be eod you can do both
<mterry> jdstrand, gotcha.  Can you ping me when I can?  I'd like to publish instructions for using the scripts today, and that would be a nice bug to not have to mention
<jdstrand> sure
<mterry> thx!
<slangasek> dholbach: https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/ - I don't think so; particularly as our "channel" nomenclature is meant to be changing
<dholbach> slangasek, right... it'd be still good if we could come up with something like that... even if we have to change it
<slangasek> asac: ^^ you said sabdfl had some guidance about the use of edge (devel-proposed) vs. alpha (devel)?  What is our messaging around channels for 15.04?
<slangasek> dholbach: btw, how do I submit changes to https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/ since most of the channels listed there also need to be deprecated? ;-)
<dholbach> slangasek, if you want, I can give you access to the site, or a bug on developer-ubuntu-com will do as well
<slangasek> dholbach: thanks, filing that in my brain for later - the channel schema needs to really be changed on the server first before we make the changes to the website
<ogra_> and in peoples brains :)
<ogra_> which is the harder part i guess ...
<dholbach> thanks slangasek
<volkrass> Can somebody point me to correct version of ubuntu-device-flash what support the oem flag
<volkrass> I tried out this: https://lists.ubuntu.com/archives/snappy-devel/2015-April/000463.html
<volkrass> But I got message: unknown flag `oem' when I try reproduce what Loic did.
<volkrass> Any hints for me?
<jdstrand> Chipaca: http://people.canonical.com/~jamie/snappy/test-snap-foo-framework_1.3_all.snap
<Chipaca> jdstrand: http://pastebin.ubuntu.com/10835145/
<sergiusens> jdstrand: kickinz1 https://gist.github.com/sergiusens/8d4d2b99b2e5d87c7a50
<kickinz1> sergiusens, Thanks!
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/catchupToInstall/+merge/256602
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/tarmac/+merge/256604
#snappy 2015-04-17
<siderati> hello everyone, looking for some help booting up snappy on OVM
<siderati> anyone here who might be able to gimme a hand?
<geoaxis> hello people, any one running snappy on rasberry pi here?
<JamesTait> Good morning all; happy Friday, and happy Bat Appreciation Day! :-D
<plorenz> hi, i'm trying to build my own snappy image for the raspberry pi 2 and found a tutorial where the tool ubuntu-device-flash is used with the parameter "--oem". I can't find a version of that program which has this parameter implemented, does anybody know where to find such a version? (the tutorial is: http://people.canonical.com/~lool/pi2-device-and-oem/ )
<lool> plorenz: yup; you want ppa:snappy-dev/tools
<lool> plorenz: also, might only work with Ubuntu 14.04 and 14.10 (trusty and vivid)
<plorenz> i've got trusty installed :) thanks, let me try that...
<plorenz> thank you, it's working :)
<dholbach_> mvo, sergiusens, jdstrand, cprov, asac and others: http://snappy.asac.ws:9001/p/SnappyDeveloperExperienceNotes
<dholbach> please help out by adding notes :)
<dholbach> beuno, Chipaca: too^ :-P
<beuno> I feel less special
<elopio> newbie question, fighting with the sd card that I can't always flash...
<elopio> any idea why I get this?
<elopio> $ sudo dd if=/tmp/snappy.img of=/dev/sdb bs=32M
<elopio> dd: failed to open â/dev/sdbâ: No medium found
<beuno> sudo fdisk -l shows /dev/sdb?
<elopio> beuno: it does not.
<beuno> elopio, so it's likely not properly inserted, maybe?
<beuno> or the sdcard ready isn't working?
<elopio> beuno: I have just umounted it. I can read the contents without problems.
<beuno> elopio, unmount or eject?
<elopio> eject.
<beuno> try the former
<elopio> ack
<dholbach> elopio, /dev/mmcblk0 or someting maybe?
<elopio> beuno: dholbach: umounting the four partitions seems to have worked.
<dholbach> ok cool
<elopio> thanks
<elopio> another q, what am I doing wrong here?
<elopio> http://paste.ubuntu.com/10839140/
<elopio> I get "snappy package not found"
<jdstrand> dholbach: updated http://snappy.asac.ws:9001/p/SnappyDeveloperExperienceNotes with some notes I took
<dholbach> thanks a lot jdstrand
<jdstrand> np
<dholbach> I'll review them and write something up we can discuss at UOS ... or some other time
 * Chipaca rages against functions not having unit tests
#snappy 2015-04-18
<Nothing_Much> Is it possible that the deb2snappy thing can become deb2click or something??
<Nothing_Much> Is it possible that the deb2snappy thing can become deb2click or something??
#snappy 2016-04-18
<Gunther_> How do I install a sideloaded x.snap with "snap" instead of "snappy"?
<dholbach> sudo snap install <local-file.snap>
<Gunther_> dholbach: I tried this with little success:ubuntu@localhost:~$ sudo snap install trionet-kernel_4.4.0_amd64.snap  error: trionet-kernel_4.4.0_amd64.snap failed to install: snappy package not found
<dholbach> hohum....
<dholbach> which version of snapd is this?
<Gunther_> I am running mvo's allsnap amd64 image
<dholbach> do you know if everything is up to date on the system?
<Gunther_> I did run "snappy update"
<Gunther_> Currently looking how to ask snapd for its version ...
<dholbach> if nobody has an answer for you, you could just try mailing the snappy-devel mailing list
<dholbach> if it's a bug you're facing, this should be looked at
<Gunther_> dholbach: I will do that. First I need to find out the version of the install tools
<dholbach> ok :)
<netpheak> hi, guys!
<zyga> good morning all
<netpheak> morning
<shuduo> mvo ogra_ hi, may i know if kernel snap for dragonboard canonical-dragon-linux is exist in edge channel?
<Gunther_> On mvo's allsnap image: How do I find out the installed version of snap, snapd?
<mvo> Gunther_: /usr/share/snappy/dpkg.list contains a list of deb packages
<Gunther_> mvo: thanks
<mvo> Gunther_: I need to do new images, they are a bit outdated right now
<Gunther_> ok then I will wait before reporting the bugs I seem the have to see if they still exist
<Gunther_> with the new images
<_morphis> zyga, jdstrand: got NetworkManager now mostly working
<zyga> _morphis: woot, great
<zyga> _morphis: any issues (apart from 1571497)
<_morphis> zyga: I suspect auto-connect isn't implemented yet, right?
<zyga> _morphis: it is implemented
<zyga> _morphis: but connection only happens on snap install time
<zyga> _morphis: and the interface has to advertise it
<_morphis> zyga: hm, I set https://github.com/morphis/snappy/blob/networkmanager-interface/interfaces/builtin/networkmanager.go#L390
<zyga> _morphis: *and* the interface slot has to be on the OS snap
<_morphis> ah
<zyga> _morphis: look at snap/implicit.go please
<_morphis> zyga: https://git.launchpad.net/~morphis/+git/nm-snap/tree/snapcraft.yaml#n17
<zyga> _morphis: until those slots are in the real core snaps this is what we need to do
<_morphis> so if I am doing something like this I don't have any chance to both apps connected
<zyga> _morphis: no, that will not work
<zyga> _morphis: (I guess we need to discuss how this will work)
<_morphis> so even if I add networkmanager to snap/implicit.go I wont connect?
<zyga> _morphis: hint, no need for the top-level plugs/slots
<_morphis> s/I wont/it wont/
<zyga> _morphis: correct
<zyga> _morphis: (this is the first time we handle something like this)
<_morphis> zyga: you mean var networkManagerPermantedSlotDBus .. ?
<_morphis> ah I see
<_morphis> you mean https://git.launchpad.net/~morphis/+git/nm-snap/tree/snapcraft.yaml#n11
<zyga> _morphis: try this http://pastebin.ubuntu.com/15909347/
<zyga> _morphis: (and I'd suggest calling the interface network-manager)
<_morphis> zyga: that works but then I get a plug network-manager:networkmanager and a slot network-manager:networkmanager
<zyga> _morphis: we *might* do something special if the interface name matches the snap name
<zyga> _morphis: seems like a nice case to auto-connect everything within the snap
<_morphis> if I now add more than one other app I have two identical plugs
<zyga> _morphis: ahh, right
<zyga> _morphis: and gustavo also said we cannot have plug and slot sharing the same name in one snap
<zyga> _morphis: sorry, forget my advice please
<_morphis> :-)
<_morphis> zyga: but maybe we can improve the automated naming here
<zyga> _morphis: still, feels like something we should auto-connect, just looking for a pattern
<zyga> _morphis: yes though this needs to be discussed firstr
<_morphis> sure
<zyga> _morphis: any other gotchas with interfaces?
<_morphis> just one thing which jdstrand noted on the bluez interface: https://github.com/ubuntu-core/snappy/pull/802#discussion_r59771686
<_morphis> I just dropped peer=(label=..) checks in my policy for now
<zyga> ah, I plan to retrun to bluez soon and make it actually understand the connections made
<zyga> just not sure if I do that before I go and hide away from computers for a while
<_morphis> :-)
<_morphis> zyga: ssweeny is currently working on getting the bluez snap back working with what he implemented for the interface
<_morphis> zyga: there are still some bits wrong in that interface: https://github.com/morphis/snappy/commit/bf2abcec0453ad8edd9bdcdeb6f16cd4f8c38b57
<zyga> _morphis: sure
<zyga> _morphis: are you guys blocked by anything today? I know images are in a so-so state
<_morphis> so-so state?
<zyga> _morphis: not working much
<_morphis> ah
<zyga> _morphis: we need a moment to restore images to bootable state
<_morphis> zyga: I can develop by using your dev-tools so we're for the moment fine
<zyga> :)
<_morphis> publishing is a bit ahead
<zyga> cool, that's great
<_morphis> zyga: nice work on those dev-tools :-)
<zyga> question: how will the interface work on the desktop
<_morphis> zyga: for bluez and networkmanager?
<zyga> can I make a snap that talks to n-m and have it magically work because the OS snap on the desktop will fake the interface
<zyga> _morphis: yes, I'm trying to think about interoperability
<_morphis> sth like that should work
<_morphis> as long as there are no API breaks
<_morphis> zyga: just wondering a bit what the release plan looks like
<zyga> _morphis: fors snappy "for devices"?
<zyga> _morphis: I guess that's going to be decided at the sprint
<_morphis> lets say we land the networkmanager interface tomorrow, how soon can that be in an image?
<zyga> _morphis: in daily image, the next day, in ubuntu 16.04 -- not sure
<zyga> _morphis: we plan to SRU things all the time but we didn't go through the process to see how it works yet
<_morphis> ok
<zyga> _morphis: images are somewhat broken now as mvo mentioned above so I suspect this week we'll see some work on making them bootable again
<_morphis> ok, sounds good
<ogra_> shuduo, it is called linux-snapdragon since the switch to a 4.4 base
<ogra_> err
<ogra_> sorry ... canonical-snapdragon-linux
<shuduo> ogra_: is there a way to know when it be changed? i used to encounter error like "mount: mount point /tmp/diskimage833309661/system/snap does not exist".  is it a problem happen at server side or my side?
<ogra_> sounds more like you are using a to old ubuntu-device-flash
<ogra_> make sure to have the latest one from mvo's all-snaps dir
<mvo> shuduo: and use "edge" for the channel
<mvo> shuduo: there is still a bit of breakage right now, I'm working on the fix
<mvo> shuduo: note that the images are still alpha, the 16.04 snap desktop/server release is not yet stable for devices and the imags are still in flux
<shuduo> mvo: after specify edge, i got "failed to install "linux-snapdragon" from "edge": linux-snapdragon failed to install: snap not found
<shuduo> mvo: yes, i understand it's not stable. i need to make some demo or help customer to demo so unstable is acceptable. but it used to fail at generating.. :(
<ogra_> shuduo, note that i corrected myself above
<ogra_> <ogra_> sorry ... canonical-snapdragon-linux
<shuduo> mvo: btw, i have used the script of https://launchpad.net/~mvo/snappy/mksnap-os-kernel for kernel snap generating. but snappy-tools package seems not available in xenial, so the command "snappy build" will be replaced by "snapcraft snap", right?
<mvo> shuduo: yes, snapcraft snap .
<mvo> shuduo: snapcraft snap targetdir
<shuduo> ogra_: sorry i missed it.  canonical-snapdragon-linux is downloading. back to my question, how I know which kernel name is correct if  it be changed? can i find it from somewhere by myself? just in case i meet problem but you are not on irc or timezone problem. thanks.
<ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-snapdragon-linux --gadget canonical-dragon -o test.img
<ogra_> all official kernels are canonical-$arch-linux nowadays ... where $arch is one of pc, snapdragon, raspi2
<ogra_> non official ones can indeed be named as the like
<zyga> shuduo: you can use my ubuntu-image script, while images are kind of broken today I keep it up-to-date with ongoing changes needed to build an image
<ogra_> zyga, whyx do you say this all the time ... images arent broken :)
<zyga> ogra_: with snappy 2.0?
<ogra_> the dropped config bit makes it a bit harder to set thjem up ... and none of the snaps from the store work
<ogra_> well, they worked on friday
<zyga> ogra_: I suspect they are broken now, we're discussing how to fix that (firstboot et all)
<ogra_> the images themselves are fine though
<zyga> ogra_: shades of gray
<ogra_> heh
<zyga> ogra_: but thanks for telling me :)
<ogra_> if they are broiken now, it must be the punishment for mvo not spending his weekend with the family :P
<zyga> ogra_: and the solution is to not spend time with the family again to fix them :-(
<shuduo> zyga: pls let me know where i can download your ubuntu-image script. thanks.
<mvo> ogra_: snap list is empty right now too, the images boot though
<zyga> shuduo: github.com/zyga/devtools
<ogra_> zyga, yeah, its a doom loop
<zyga> ogra_: part of the solution is to snap doom so that we can get some R&R
<ogra_> +1 !!
<shuduo> zyga, cool! :)
<shuduo> ogra_: that means all snapdragon family SoC be supported by a single kernel, right?
<shuduo> ogra_: i'm working on a board with APQ8074 but the kernel is 3.10. So if current kernel already support this chip, only adjustment could  be partition layout in gadget snap (if need). that will be awesome!
<popey> is SNAP_APP_DATA_PATH still correct or has its name changed recently?
<popey> (specifically - what's the environment variable which points to the writable area?
<ogra_`> SNAP_DATA
<ogra_`> iirc
<popey> aha!
<popey> yes, thanks.
<Gunther_> Is it possible that a daemon in a snap container is able to access /bin/systemctl to restart itself? (I am getting apparmor denied)
<kyrofa> Good morning
<zyga> Gunther_: no
<_morphis> zyga: one other thing I see is that installing a snap some times doesn't work after I had it already installed: https://paste.ubuntu.com/15911281/
<zyga> Gunther_: but you should be albe to send a signal to the daemon from using an app from the same snap
<zyga> _morphis: looking
<popey> $ sudo snap remove mame
<popey> error: can't remove "mame": snap "mame" has changes in progress
<popey> what does that mean?
<Gunther_> zyga: thanks
<Gunther_> zyga: I assumed I have to
<ogra_`> popey, someone broke into your system and is secretly playing pacman ?
 * ogra_` has no clue :)
<daker> ogra_`: i have snappy ubuntu core running on rpi2, how can i apt snapcraft 1.x ?
<ogra_`> dayou can only use snapcraft 1.x in pre-xenial systems
<ogra_`> but the 15.04 snappy did not have the classic shell ... so you would need a chroot
<popey> i can't add or remove anything
<ogra_`> (or lxc container or so)
<zyga> popey: it means that there are changes operating on that snap now, can you please pastebin "$ snap changes"
<popey> http://paste.ubuntu.com/15911444/
<popey> zyga: ^
<zyga> popey: thanks, can you report a bug with this information
<popey> sure, where?
<zyga> popey: is that on 2.0?
<zyga> popey: launchpad.net/snappy please
<daker> ogra_: i didn't manage to run an armhf lxc container
<popey> up to date 16.04
<popey> ok
<ogra_`> daker, then grab a tarball from http://cdimage.ubuntu.com/ubuntu-core/releases/15.04/release/ ... scp it to your snappy ... unpack it in a dir, copy resov.conf in place and you can chroot into it
<ogra_`> (or use the 15.10 tarball ... probably easier to get a newer snapcraft with that)
<zyga> popey: can you try snap abort "snap abort" the changes related to those snaps?
<popey> zyga: https://bugs.launchpad.net/snappy/+bug/1571614
<ubottu> Launchpad bug 1571614 in Snappy "Can't add or remove snaps 'snap "mame" has changes in progress'" [Undecided,New]
<popey> zyga: what change ID do I use?
<Gunther_> What is the essential apparmor config needed for a custom kernel? I am getting ailed to load AppArmor policy for trionet-srv: exit status 1 :Cache read/write disabled: interface file missing. (Kernel needs AppArmor 2.4 compatibility patch.)
<ogra_`> well, recent mainline should have all you need
<ogra_`> for older kernels the security team has backported patches ... but only for a certain set
<ogra_`> https://wiki.ubuntu.com/SecurityTeam/AppArmorForPhabletKernels might help
<Gunther_> ogra_`: thanks
<ogra_`> (note that snappy needs at least 3.10 though ... forget about the 3.4 patches :) )
<Gunther_> I am using the kernel sources from 	url = git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git 	fetch = +refs/tags/Ubuntu-4.4.0-14.30:refs/tags/Ubuntu-4.4.0-14.30
<ogra_`> that should have all patches
<Gunther_> ok
<ogra_`> (read, your issue is most likely a config thing)
<Gunther_> I just looking for the correct "essential" configuration :)
<zyga> popey: thanks
<daker> ogra_`: if i want to use my actual snappy installation(without touching anything), i just need to use snapcraft 2.x ?
<zyga> popey: those of the changes related to the snap you were trying to install/remove
<ogra_`> daker, on a 16.04 snappy image you call "sudo snap enable-classic", then you can "snap shell classic" to get into an apt ebaled environment
<popey> zyga: error: cannot abort change 3 with nothing pending
<popey> zyga: there's a bunch on Hold.
<daker> ogra_`: when the 16.04 image is going to be available :) ?
<ogra_`> the first alpha should be available soon
<ogra_`> until then you need to use the inofficial ones
<daker> ogra_`: where can i find one ?
<ogra_`> http://people.canonical.com/~mvo/all-snaps/
<daker> of course you have one :D
<ogra_`> and for pi3 http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<daker> rpi2-all-snap.img.xz is the one i am looking for ?
<ogra_`> yes
<daker> ok thanks! i'll test that
<zyga> ogra_`: oh, can I patch ubuntu-image for pi3?
<ogra_`> zyga, well, the pi2 image should work as is atm .... if you build from the store
<zyga> ogra_`: ok
<zyga> ogra_`: I'll patch the script today
<ogra_`> (i'll have to change that though, unless ppisati has found a fix for the uboot serial issue on the pi2 with that uboot binary)
<ogra_`> i'll most likely introduce a canonical-pi3 gadget
<zyga> ogra_`: yep, that would be good
<zyga> ogra_`: even if the only different thing is a name
<ogra_`> well, then we cant easily do a 64bit image
<ogra_`> i would really like to have a generic pi image that works on both for 32bit
<netpheak> Ogra: When is an official RPI3 release expected?
<ogra_`> netpheak, with the offical snappy 16.04 release
<netpheak> ok, thx ;)
<ogra_`> in a month or two or so
<popey> zyga: is it easier to nuke everything and start again? If so, how do I nuke all of snap?
<zyga> popey: yes; sudo servicectl stop snapd; sudo  umount /snap/*/*; sudo rm -rf /var/lib/snapd
<zyga> popey: give that a try
 * zyga will add nuke-state to devtools
<mvo> zyga, ogra_`: fwiw, I pushed a new u-d-f
<ogra_`> so the archive ?
<ogra_`> *to
<mvo> which brings back mounted snaps on boot
<mvo> to my people page for now
<popey> zyga: ok
<ogra_`> ok
<mvo> and I have a branch up for discussion to sync state on firstboot so snap list actually has something
<mvo> *if* that branch is accepted we may have images tomorrow that are in much better shape than todays
 * mvo crosses fingers
<zyga> mvo: thanks
<daker> ogra_`: error: Unknown command `enable-classic'.
<ogra_`> thats on a 16.04 image ?
<daker> yes Xenial
<ogra_`> on your rpi ?
<ogra_`> weird
<daker> yes
<daker> rpi2
<ogra_`> the images are old though ... try if the snappy command still exists thetre
<oparoz> daker no dash
<oparoz> daker, never mind
<Gunther_> FYI allsnaps (amd64): snappy install custom_kernel.snap works (boots!) (Yeah)
<ogra_`> congrats !
<Gunther_> but snappy remove custom_kernel.snap leaves grub in a state trying to boot the custom kernel
<Gunther_> it does not recover ...
<netpheak> ogra: where can i find the latest RPI3 image?
<zyga> _morphis: FYI https://github.com/ubuntu-core/snappy/pull/1034
<zyga> _morphis: could you give that a practical spin?
<zyga> _morphis: just git checkout that in your tree and use devtools as usual
<ogra_`> netpheak, just build a pi2 image from the latest store snaps using u-d-f
<ogra_`> the ony in my rpi3 dir is very outdated
<_morphis> zyga: sure, thanks!
<ogra_`> mvo, hmm, that new udf is very noisy
<ogra_`> http://paste.ubuntu.com/15912226/
<Gunther_> another one: I tried to add an udef rule to my kernel.snap (it is in the snap, I see the directory/file /etc/udev/rules.d/some.rule). But its not visible on the system the kernel.snap is installed then.
<Gunther_> but rules.d seems to be a mount point
<ogra_`> it would need to be defined in snappy
<ogra_`> iirc it only mounts stuff to /lib/firmware|modules atm
<Gunther_> ogra_`: ok. Currently I have just daemons (root) accessing the device. But I would like to give normal apps the access too
<Gunther_> ogra_`:  I will put this on the wishlist
<ogra_`> Gunther_, kernel and gadget snaps are effectively being re-designed from scratch the next weeks
<zyga> Gunther_: you'd have to make an interface for that
<zyga> Gunther_: I can guide you but I'm AFK for the next 30 min
<Gunther_> zyga: thanks.
<ogra_`> zyga, seriously ? for a kernel snap ?
 * Gunther_ has to get information about interfaces
<primobasilio> Hi guys. I'm using: $ snapcraft --version
<primobasilio> 2.8.1
 * ogra_` thinks that a bunch of dirs should simply be supported by default ... 
<primobasilio> I can't use configFlags in the new version, right?
<ogra_`> like udev/rules.d or the GL search path
<primobasilio> Issue while loading plugin: [...] Additional properties are not allowed ('configFlags' was unexpected)
<primobasilio> So, please, how should I pass parameters to ./configure
<ogra_`> (and /etc/modprobe.d ...)
<_morphis> zyga: any idea about the reinstall problem already?
<popey> Can someone help me with an app I have snapped? lp:snappy-playpen -> mame/mamedeb . Once snapped and installed, if I try and run it, it just fails with a "not found" message, but I can run the exact same command (outside of apparmor/snap) fine. No apparmor denials. It's doing my head in.
<popey> this is the output when it's run via "mame.run":-
<popey>  /snap/mame/100001/bin/launcher: 16: exec: /snap/mame/100001/usr/games/mame -v -inipath /snap/mame/100001 : not found
<mariogrip> why cannot i run snappy apps on 16.04? i get "can not find a snappy os. errmsg: No such file or directory"
<popey> mariogrip: sudo snap install ubuntu-core
<mvo> ogra_`: thanks, will fix in a sec
<mvo> or two
<mariogrip> popey: I tried, but i get "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress"
<popey> ah, i had the same
<ogra_`> mbvbeyond that snap list and snap find seem to work fine on the dragonboard here
<popey> mariogrip: bug 1571614
<ubottu> bug 1571614 in Snappy "Can't add or remove snaps 'snap "mame" has changes in progress'" [Undecided,New] https://launchpad.net/bugs/1571614
<popey> I had to nuke the entire world
<ogra_`> mvo, what hap0pened to "enable-classic" though ?
<popey> so I'd say you've reproduced that bug, could you please mark it so. zyga ^
<zyga> _morphis: no, not yet
<ogra_`> mvo, was the option dropped ? that will make itr very hard to get the arm64 bug fixed before 16.04 release
<_morphis> zyga: ok
<mariogrip> popey: is there a workaround?
<popey> mariogrip: nuke from orbit.
<popey> mariogrip: http://paste.ubuntu.com/15911812/
<zyga> popey: reproduce this bug?
<mariogrip> is there some logs that will help debug that I can collect before nuking?
<popey> zyga: mariogrip has the same issue I had.. snap "ubuntu-core" has changes in progress
<zyga> ah, ok
<zyga> marcoceppi: can you add the same info to the bug please
<zyga> marcoceppi: snap changes (pastebin that)
<mariogrip> zyga: was that for me?
<zyga> mariogrip: ys, sorry
 * zyga hates tab-complete in polair
<zyga> marcoceppi: (sorry)
<ogra_`> xchat has fixes for that ;)
<ogra_`> (moves the person you last talked to to the top of the tab completion list)
<mariogrip> zyga: done :)
<davmor2> ogra_`: s/xchat/hexchat :P
<zyga> mariogrip: thank you
<zyga> mariogrip: I'll check it out after our standup
<ogra_`> davmor2, depends what you use ... xenial isnt released yet ;)
<zyga> popey: did you reslve your problem with mame?
<popey> zyga: no
<zyga> popey: what's the current state?
<zyga> popey: (as in where are you, what works, what doens't)
<popey> see 57 mins past
<popey> above
<mariogrip> popey: I how do i remove /snap? it's read only
<popey> mariogrip: sudo ? :)
<zyga> mariogrip: on a device you don't have to
<mariogrip> popey: tried
<zyga> mariogrip: just umount all the stuff inside and rm -rf all the dirs
<mariogrip> zyga: how do i unmount a sideloaded snap?
<zyga> mariogrip: just unmount the squasfs
<zyga> mariogrip: sudo umount /snap/*/*
<popey> yeah, mount | grep snap
<popey> and unmount all those things
<zyga> mariogrip: try this http://paste.ubuntu.com/15911812/
<zyga> I'll improve that and add it to devtools
<mariogrip> zyga: it worked thanks
<dpm> so the recent change from /snaps to /snap on the desktop seems to have broken previously installed apps. I reinstalled ubuntu-core and ubuntu-clock-app, but now on launching it, I get:
<dpm> $ ubuntu-clock-app.clock
<dpm> appname ubuntu-clock-app.clock not allowed
<mariogrip> zyga: btw, umount /var/lib/snapd/snaps/* || true does not works for sideloaded snaps
<dpm> any ideas how to fix it? I think somehow the launcher is still seeing the old clock app in /snaps
<zyga> mariogrip: ah, thanks
<zyga> mariogrip: where are they located?
<dpm> which incidentally I don't know how to uninstall
<popey> dpm: maybe look in /snap/bin ?
<mariogrip> zyga: I have no idea
<zyga> dpm: nuke your state
<zyga> dpm: and reinstall
<popey> yeah, seems the message of today is "Nuke from orbit"
<zyga> with the orbital ion canoon
<zyga> canon*
<dpm> zyga, what can I nuke the state?
<dpm> argh, can't type
<zyga> dpm: give me a moment, I'm writing a script for that
<dpm> *how, I meant
<dpm> ok, thanks zyga
<dholbach> dpm,
<dholbach> sudo umount /var/lib/snappy/snaps/*
<dholbach> sudo rm /etc/systemd/system/snaps-*.mount
<dholbach> rm -r ~/snaps
<dholbach> but there might be more involved than that
<dholbach> it's what I noted down at some stage
<mariogrip> zyga popey damn, still "error: can't install "ubuntu-core": snap "ubuntu-core" has changes in progress
<mariogrip> " after the nuke
<zyga> mariogrip: systemctl stop snapd;
<zyga> mariogrip: rm -rf /var/lib/snapd/state.json
<zyga> that will erase all state
<dpm> thanks dholbach. I guess the snaps PATH should be updated too?
<ogra_`> ppisati, hmm, did you test the latest raspi2 kernel with the pi3 ? seems i cant get mine to boot anymore
<zyga> dpm: they are on the desktop
<dholbach> dpm, where?
<dholbach> dpm, you might have to rebuild/reinstall the snap, and after installing the new snapd/u-core-launcher/etc probably reboot
<dpm> ok
<mariogrip> zyga: thanks, it works now
 * zyga is lost with various support requests
<zyga> it would be great if each person having an issue mentioned if they are on the desktop or a pure-snap image
<zyga> _morphis: can you report the bug you had with sideloading please?
<_morphis> zyga: sure
<zyga> _morphis: I'm afraid most people will just crash quickly today and take some time off
<zyga> _morphis: but I don't want to lose track of this
<_morphis> zyga: sure
<mhall119> how can I edit my snap app's files in place? they're all readonly even for sudo
<mariogrip> mhall119: remount -o rw,remount /snap/*/* test if that works
<zyga> mhall119: you cannot
<zyga> mhall119: those are on a squashfs
<mariogrip> not remount use mount
<_morphis> zyga: btw. on other thing I noticed with your dev-tools is that copying snap to $HOME breaks snapd or any snap from creating $HOME/snap as directory which is now where $SNAP_USER_DATA is
<_morphis> zyga: can propose a PR to fix that but wasn't sure where to put the new snap binary then
<zyga> _morphis: ahh, yes
<zyga> _morphis: I'll fix that, I saw it too
<zyga> _morphis: I just forgot about it
<zyga> _morphis: maybe devtools.$1
<_morphis> zyga: named it snap-1 for me
<zyga> _morphis: e.g. devtools.snap devtools.snapd
<_morphis> sounds good!
<zyga> would be a clear indication of someone uses that when hacking and reports problems
<zyga> _morphis: I'll patch devtools for better desktop support
<zyga> _morphis: thanks for looking into this
<_morphis> zyga: np
<mhall119> mariogrip: didn't work
<mhall119> zyga: if I can't make them rw, what's the easiest way to debug a failing python app launch?
<zyga> jdstrand: we should plan some work for the support tool for snap developers that adds advice ofr particular interfaces
<zyga> mhall119: you cannot because squashfs is inherently read only
<zyga> mhall119: what do you see?
<zyga> mhall119: I'd suggest adding a shell app
<zyga> mhall119: (like in hello-world)
<zyga> mhall119: that will let you inspct the state and play around more easily
<mhall119> zyga: there are multiple wrapping shell scripts already
<zyga> jdstrand: (I'm sorry I forgot the name)
<zyga> mhall119: I mean an interactive one
<zyga> jdstrand: and add REST API that gives snippets and lists interfaces
<mhall119> yeah, I'll inject a pdb call
<zyga> mhall119: that's useful too :)
<zyga> mhall119: one more thing
<zyga> mhall119: snap install --devmode
<zyga> mhall119: you can use that to install your snap with non-enforcing confinement
<mhall119> it's still using unconfined in snapcraft.yaml
<zyga> mhall119: that's useless
<zyga> mhall119: it doesn't do anything
<zyga> mhall119: can you pastebin your snapcraft.yaml
<oparoz> zyga, unknown flag `devmode' Is that on edge only?
 * zyga feels he should blog about interfaces
<zyga> oparoz: that's in 2.0
<zyga> oparoz: (images are somewhat broken today)
<zyga> oparoz: we're fixing that to make building new images possible
<oparoz> Thanks zyga
<mhall119> zyga: well it builds a snap I can sideload, my problem right now is that setuptools and pkg_resources can't find the script to launch my app
<mhall119> zyga: but http://paste.ubuntu.com/15913016/ if you want to look at it
<zyga> mhall119: can you please pastebin some output?
<zyga> ah
<zyga> :D
<zyga> sorry
<zyga> mhall119: drop the no-security plug
<zyga> mhall119: add unity7 plug
<zyga> mhall119: debug snapcraft issues with sergio
<zyga> mhall119: I can help with runtime
<daker> ogra_: the snappy command is still in the image
<zyga> mhall119: you can use setup/ to create a desktop file and icon
<zyga> (later)
<ogra_> daker, then there might also still be the "enable-classic" option to it
<zyga> daker: images are somewhat broken, not based on snappy 2.0
<daker> ogra_: yes snappy enable-classic it working now
 * zyga stops saying that over
<ogra_> good ... better dont upgrade then :)
<ogra_> zyga, he is not using a 2.0 image
<zyga> right
<daker> zyga: no problem, i just want to produce an armhf snap for snapcraft 1.x
<ogra_> good enough to get a classic shell
<zyga> yep
<_morphis> zyga, jdstrand: https://github.com/ubuntu-core/snappy/pull/1036
<mhall119> zyga: I don't think these are snapcraft issues specifically
<zyga> mhall119: can you be more specific please? can you pastebin the error you're seeing?
<sergiusens> hey, just finally reconfigured my `shout` snap
<mhall119> I think it's a python2/setuptools issue
<zyga> ah
<sergiusens> what errors are you mhall119 and zyga talking about?
<zyga> mhall119: I can help with that as well
<sergiusens> oh
<sergiusens> carry on
<zyga> _morphis: nice!
<sergiusens> -)
<zyga> sergiusens: no no, you can take over
<zyga> I should do this "sleep" thing that people say is good for your health
<mhall119> zyga: http://paste.ubuntu.com/15913119/
<mhall119> sergiusens: ^^
<sergiusens> zyga no, I'm preparing a final snapcraft release
<sergiusens> no can do
<zyga> ok
<_morphis> zyga, jdstrand: policy wise there is still room for improvements and I am not sure if I did everything the right way
<zyga> mhall119: can you share the setup.py file?
<zyga> _morphis: I'll check it out, thanks, nice work :)
<_morphis> zyga: thanks :-)
<_morphis> zyga: and I must say, it didn't took me as long as I suspected
<mhall119> zyga: http://paste.ubuntu.com/15913162/
<mhall119> zyga: I just pushed my local bzr changes to lp:~mhall119/hello-unity/snap
<zyga> mhall119: can you psatebin the content of the squashfs file
<zyga> k
<ogra_> beuno, or mvo, can one of you approve https://myapps.developer.ubuntu.com/dev/click-apps/4870/rev/1/ ?
<mhall119> zyga: the what now?
<mhall119> my .snap is 101MB
<zyga> mhall119: just wait one sec, branching
<mhall119> zyga: my snapcraft project files are all in lp:snappy-playpen too
<daker> ogra_: http://pastebin.ubuntu.com/15913217/
<ogra_> daker, snappy shell classic
<daker> ah
<daker> ogra_: sudo: no tty present and no askpass program specified
<daker> when running sudo apt-get install snapcraft
<ogra_> bug 1564369
<ubottu> bug 1564369 in Snappy "sudo broken in latest classic" [Critical,Confirmed] https://launchpad.net/bugs/1564369
<ogra_> (has a workaround)
<beuno> ogra_,
<beuno> checksums do not match. Please ensure the snap is created with either 'snapcraft snap <DIR>' or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs' security-snap-v2_squashfs_repack_checksum
<daker> ok
<beuno> ogra_, I'd double check that one
<ogra_> beuno, oh, come on
<beuno> ogra_, I don't make the rules!
<ogra_> ()it is the same script i use for all gadgets )
 * ogra_ re-works 
<ogra_> beuno, i dont need to bump the version anymore, right ?
<beuno> ogra_, correct
<ogra_> beuno, https://myapps.developer.ubuntu.com/dev/click-apps/4870/rev/2/ now ...
<beuno> ogra_, approved
<ogra_> thx
<popey> zyga: when you're free, if you have any ideas about my mame issue I'd appreciate a look, thanks.
<zyga> popey: still checking the problem for mhall119
<popey> okay
<popey> damn you mhall119 for jumping the queue!
<ogra_> popey, calm down ... he's not british
<mhall119> USA! USA! USA!
<popey> Oh I'm calm. tutting under my breath as I drink tea
<mhall119> that's british rage right there
<ogra_> because the words "tutting" and "tea" are in the same sentence ?
<popey> http://3.bp.blogspot.com/-w_4ts9QQ7Bc/TmgikmOhonI/AAAAAAAAAOk/kzDF0596rf4/s1600/anarchy-in-the-uk.jpg
<mhall119> it's basically what cursing and whiskey is in the USA
<mhall119> popey: lol
<ogra_> hah
<jdstrand> zyga (fyi, mvo): bug #1571675
<ubottu> bug 1571675 in snapd (Ubuntu) "network-bind not autoconnecting the security policy" [Undecided,New] https://launchpad.net/bugs/1571675
<zyga> mmm
<jdstrand> mvo: is 'snap list' supposed to not show the os and gadget snaps any more?
<jdstrand> mvo: is it no longer possible to see if there is a newer snap available? to run the equivalent of 'snappy update'?
<zyga> jdstrand: replied
 * zyga is hammering his cpu with mksquashfs
<zyga> jdstrand: it shows all snaps
<zyga> jdstrand: snap refresh (except store bugs)
<mvo> jdstrand: devices are all broken currently
<jdstrand> zyga: snap list does not show the os snap
<zyga> jdstrand: then it is not installed
<mvo> jdstrand: and snap refresh is not working the same way it was before
<jdstrand> zyga: it has to be
<zyga> jdstrand: images are broken
<mvo> jdstrand: sorry, those will be fixed soon
<jdstrand> I used udf and booted it :)
<mvo> jdstrand: images also have branches up
<jdstrand> ok
<mvo> jdstrand: yeah, it boots that is about it ;)
<jdstrand> I see
<jdstrand> is there a bug for that?
<zyga> jdstrand: not sure
<mvo> jdstrand: hopefully (once my branch gets reviewed) it will be good again
<jdstrand> I'd like to follow it so I don't bother you guys
<mvo> jdstrand: https://github.com/ubuntu-core/snappy/pull/1033 this is the best bet right nw
<jdstrand> mvo: curious, is the equivalent of 'snappy service' coming back or is it dead?
<mvo> jdstrand: I am not sure, I personally really want it back as its so much nicer than systemctl, but it was not discussed in a wider group yet
<ogra_> sprint topic ;)
<jdstrand> mvo: I was thinking exactly the same thing
<jdstrand> systemctl is quite low level
<zyga> mhall119: that's a snapcraft bug
<zyga> mhall119, sergiusens: http://pastebin.ubuntu.com/15913598/
<zyga> that's the content of the script in the snap
<zyga> note the shebangline #!/tmp/foo/parts/hello-unity/install/usr/bin/python2
<zyga> mhall119: I'll stop working on this now
<zyga> mhall119: please report this to sergiusens
<zyga> I can share the small modifications I made to make this easier to work with
<daker> ogra_: from time to time it seems to me that i lost the ssh session
<ogra_> hmm
<daker> the console doesn't seems to responds or it takes seconds for the characters to appear
<daker> maybe a network lag ?
<ogra_> sunds like a network issue
<daker> ok, just want to confirm it's not an issue with in ubuntu core
<ogra_> i dont see it here
<zyga> popey: re
<mhall119> zyga: I don't think the hashbang line is being used
<mhall119> zyga: /snap/hello-unity/current/bin/hello-unity calls `usr/bin/python $SNAP/usr/bin/hello-unity` so it's using the the python executable from /snap/hello-unity/current/usr/bin/python
<mhall119> the shebang is still wrong, but it's not the cause of my problems
<zyga> mhall119: ah, I didn't use the wrapper script, just the tree and the snapcraft file you've pasted
<mhall119> the cause is somewhere in pkg_resources, the right version of that is being called, but it's not finding the script
<sergiusens> mhall119 zyga setup_tools replaces it; we make it proper in the wrapper script but it has to be declared in `apps`
<sergiusens> with a `command`
<mhall119> sergiusens: are you talking about the shebang?
<sergiusens> yes
<mhall119> I still don't think that's my problem, unless that will cause pkg_resources.call_script to ignore it
<sergiusens> zyga that shebang modification is hard coded into python core libs
<zyga> sergiusens: I see
<zyga> sergiusens: does that happen with entry points as well?
<sergiusens> zyga entry points if not part of `apps/<app>/commands` will not work
<zyga> sergiusens: right, I always assume there's an app entry
<sergiusens> zyga blame crappy python's lack of easy distribution
<ysionneau> sergiusens: hi! sorry to insist about this topic but do you have any idea about my image generation issue (the mailing list thread)? Do you need more information from me?
<sergiusens> ysionneau which one was it?
<sergiusens> ysionneau it might be many things, as many thing changed this past week; mvo iirc put up a new u-d-f even
<ysionneau> I'll try with the new one then!
<ysionneau> sergiusens: it was this thread https://lists.ubuntu.com/archives/snappy-devel/2016-March/001668.html
<mvo> ysionneau: https://github.com/ubuntu-core/snappy/pull/1033 needs to land before images work again
<ysionneau> ok I guess this is "another" issue, since I already had issues even before the 2.0 was out
<ysionneau> right?
<ogra_> there are plenty of issues
<sborovkov> Hi. I built snappy for RPI with latest kernel/os snap. It does not load - on RPI 3 it shows gradient on whole screen and nothing else happens. On Rpi 2 it prints some progress until message with `Starting kernel...` - and stops at that. Any ideas what could be wrong?
<ogra_> sborovkov, hmm, i just built an image, works fine
<sergiusens> ysionneau well I never saw that reply :-)
<ogra_> sborovkov, using:  sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o test.img
<sergiusens> ysionneau but as ogra_ pointed out; there is some cleanup that needs to happen
<ogra_> or sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o pi3-test.img
<ogra_> sborovkov, both with the latest ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/
<sborovkov> ogra_: hmm, may be I have something outdated in my files. I will try that, thanks.
<primobasilio> Anyone can point me out a good source of documentation on how should I use --target-arch for autotools. At least, I would like to use i386 and AMD64.
<ogra_> sborovkov, note that the pi2 has some issues with the serial console currently ... (working on that this week)
<ogra_> you might not get a login prompt on serial, even though the device boots fine
<sborovkov> ogra_: is gadget snap for rpi3 not compatible with rpi2? I remember loading with gadget snap for rpi2 on rpi3 like a week ago
<ogra_> sborovkov, until end of this week it will be ... i'm just changing that because we cant make the serial consiole work on the pi2 with the uboot that would support both
<sborovkov> Got it, thanks
<daker> ogra_: \o/ : Snapped micropython_1.7.1_armhf.snap
<ogra_> yay !
<daker> i still need to figure out ssh session freeze
<daker> i suspect the sdcard becomes slow
<mariogrip> I have added the mount_observe interface, but apparmor still denied r to /proc/9955/mount
<daker> ogra_: got some wired stuff here http://pastebin.ubuntu.com/15915224/ :D
<ogra_> daker, you probably want to ship your own libc and libm then
<ogra_> seems it tries to use the system libm there
<mhall119> sergiusens: so either pkg_resources is looking in the wrong place, or setuptools is installing things into the wrong place
<mhall119> sergiusens: pkg_resourcs is looking for /snap/hello-unity/100001/usr/lib/python2.7/dist-packages/hello_unity-0.4.egg-info/scripts/hello-unity
<mhall119> but setuptools puts it in /snap/hello-unity/100001/usr/lib/python2.7/dist-packages/hello_unity-0.4-py2.7.egg/EGG-INFO/scripts/hello-unity
<daker> ogra_: :/
<mariogrip> I see why, pid 9955 is python2 but the apps pid id 9954. then how do i set mount_observe for python2?
<mhall119> sergiusens: even after fixing that, it doesn't look like the python GObject Introspection stuff is there
 * mhall119 tries adding python-gi to snapcraft.yaml
<ysionneau> ok thanks ogra_ and sergiusens
<ysionneau> another question, is it possible when writing a snap containing a service : to provide the systemd unit file
<ysionneau> to provide the activation socket for instance
 * kyrofa snags ogra_'s hug from the backscroll
<kyrofa> ogra_, I take it the bug was fixed?
<ogra_> s390x builds fine at least :)
<kyrofa> ogra_, good to hear! :)
<mhall119> `snap install <local.snap>` spit out:
<mhall119> error: change finished in status "Hold" with no error message
<ysionneau> ah I see there is a "socket" keyword
<mhall119> and `snap remove <package>` now gives me:
<mhall119> error: can't remove "hello-unity": snap "hello-unity" has changes in progress
<jdstrand> mariogrip: you don't have to worry about the particular pid. mount_observe is not 'autoconnected' so you'll need to manually connect after install
<jdstrand> zyga would be the person to ask about manual connecting. It wasn't working as of friday (for me), but several updates came in over the weekend
<jdstrand> that said, all connecting may be broken due to bug #1571675
<ubottu> bug 1571675 in snapd (Ubuntu) "not autoconnecting the security policy" [Undecided,New] https://launchpad.net/bugs/1571675
<jdstrand> (and that is being worked on AIUI)
<mariogrip> jdstrand: yeah, but I have a python2 app, but apparmor denies python to access /proc/*/mounts
<mariogrip> jdstrand: python2 has a different pid then my main app,
<jdstrand> mariogrip: I understand. the mount_observe has something like this: '/proc/*/mounts r,' so the actual pid doesn't matter. the problem is that the rule I just mentioned isn't added to your policy
<jdstrand> so you have to manually connect it
<mariogrip> jdstrand: in https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/mount_observe.go it says  @{PROC}/@{pid}/mounts r
<jdstrand> yes
<jdstrand> @{pid} turns into '{[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}'
<nothal> jdstrand: No such command!
<jdstrand> which is similar to a glob
<jdstrand> point is, you don't have to worry about the pid number
<mariogrip> ah, ok
<roadmr> jdstrand, beuno : click-reviewers-tools r630 is now live on myapps
<roadmr> beuno: I also fixed that "Is a valid click package" thing, that's also up now
 * beuno hugs roadmr 
<jdstrand> thanks!
<wililupy_> Question: I updated my xenail build machine today, and it removed ubuntu-snappy so I don't have the snappy command anymore, is this in a different package now? apt-cache says snappy is in the snappy package, but that is not the correct snappy for building snaps :)
<ogra_> wililupy, the command was renamed to snap ... the package is snapd iirc
<ogra_> (but that is for executing snaps ... for bulding snaps you use snapcraft ;) )
<ogra_> s/executing/managing/
<kyrofa> wililupy, were you using `snappy build`?
<jcastro> error: can't remove "shout": snap "shout" has changes in progress
<jcastro> how do I resolve these kind of errors?
<jcastro> I think my snappy is in some kind of weird state
<wililupy> yes
<wililupy> ogra_ yes
<wililupy> ogra_ My script for building a snap was fakeroot snappy build --squashfs unpack-kernel so that I could install custom modules for my kernel snap.
<ogra_> snappy buuld is deprecated
<ogra_> use snapcraft snap
<kyrofa> wililupy, indeed, what ogra_ said. You can use snapcraft to build the entire thing, or you can just use `snapcraft snap <directory>` the way you're using `snappy build` now
<wililupy> kyrofa: I'll try that. I have my kernel dirctory all open and I have my modules put in place, I'll try to snapcraft snap 4.4.0-18-im and see what happens :)
<kyrofa> wililupy, should work as long as your meta/ directory is good
<kyrofa> wililupy, I do suggest you investigate building your kernel with snapcraft when you're able
<kyrofa> wililupy, might simplify your workflow
<netpheak> Tried installing the http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ubuntu-snappy-armhf+rpi2.img.xz image on my RPI3, but all i get is a a block of rainbow colors on the screen.
<wililupy> kyrofa, ogra_: http://pastebin.ubuntu.com/15918217/
<kyrofa> wililupy, ah, this is ollld
<kyrofa> wililupy, 15.04 must be your target?
<wililupy> no, 16.04
<genii> The pi3 has an A53
<kyrofa> wililupy, then yeah, you're a bit out of date. This has since moved to snap.yaml, and the syntax has changed
<kyrofa> wililupy, I do strongly suggest you begin using snapcraft then
<kyrofa> wililupy, something like this: https://github.com/ubuntu-core/snapcraft/blob/master/examples/96boards-kernel/snapcraft.yaml
<genii> netpheak: Have you tried http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ubuntu-snappy-amd64.img.xz instead?
<genii> Sorry, wrong one
<genii> The arm64
<wililupy> kyroga, I have tried that one, but it doesn't run depmod on my custom modules so when the system starts up, I have to insmod them everytime...
<netpheak> Hmm.. didn't know the PI3 already had 64 bit support?
<netpheak> I think the 64bit one is for the dragonboard
<kyrofa> wililupy, ah, okay. Might be a bug in the kernel plugin?
<kyrofa> wililupy, you can get around it by making a custom kernel plugin for your local snap, or do what you're doing now, and learning the new snappy 16 syntax
<wililupy> kyrofa, not sure. I tried to build the modules from source using snapcraft and then using the kernel plugin to build and install the new kernel, but it would build against the kernel headers on my system and not the ones I wanted to use in Snappy. So I decided to precombile them and use the copy plugin to put them in the lib/modules/* directories I needed, but it doesn't run depmod so I have to insmod after a reboot.
<wililupy> kyrofa, what I could do is create a script that will run when I start my application snap to run insmod to make sure that the modules are loaded before starting. Can be a work around until I can figure out how to build and install the customer modules using snapcraft.
<kyrofa> wililupy, you'll probably run into confinement issues with that, though I suspect you're running unconfined?
<wililupy> kyrofa, yes.
<kyrofa> wililupy, so I imagine your ideal workflow would be to have a kernel part, and a modules part that runs after the kernel part using that kernel's headers, and then it would be smart enough to call depmod. Would you agree with that (I know it doesn't work that way right now)?
<wililupy> kyrofa: yes. Or, just be able to make a kernel snap from .deb :)
<wililupy> kyrofa: I can compile and build everything fine, and then create a deb with all of this done already. If I could just create a kernel snap from my deb package, that would be much easier. I have a "feature request" bug in lp for this :)
<ogra_> netpheak, grab ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/
<ogra_> netpheak,  sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o pi3-test.img
<wililupy> lp: 1565058
<ubottu> Launchpad bug 1565058 in snapcraft (Ubuntu) "add .deb kernel's to the kernel plugin" [Undecided,New] https://launchpad.net/bugs/1565058
<ogra_> (and make sure to have a network cable attached when booting, there seems to be some bug with the NIC when not)
<netpheak> ogra_: where do the kernel, gadget etc come from?
<ogra_> the store
<wililupy> kyrofa: http://pastebin.ubuntu.com/15918492
<kyrofa> wililupy, your kernel source is '.'. I remember talking about the possibility of placing your modules within the kernel source itself-- did you ever try that?
<wililupy> kyrofa, I did, and it failed to build. I tried puting them in staging and modifying the Kconfig, but becuase some modules have the same name, it failed to build.
<wililupy> kyrofa, I tried two different ways. I like tha idea of a kernel snap, and then a module snap. I wonder how hard it would be to create a modifed kernel plugin. I am looking at /usr/lib/python3/dist-packages/snapcraft/plugins/kernel.py and kbuild.py right now.
<netpheak> Is there any way to setup an image, to enable drive encryption?
<netpheak> ogra_: how do i enable classic mode?
<netpheak> snappy enable-classic does not work
<kgunn> sergiusens: hey what was the snap tool arg was it "--devmode"?
<kgunn> e.g. snap install --devmode *.snap?
<kgunn> to ignore interfaces for a moment
<kgunn> jdstrand: ^ ?
<jdstrand> --dev-mode is what was typed into the chat
<jdstrand> I haven't tried it yet
<jdstrand> hmm
<jdstrand> snap install --help
<jdstrand> it says '--devmode'
<kgunn> jdstrand: also, is the ubuntu-core  different than if i stitch an image with u-d-f?
<kgunn> snap install --help doesn't say anything there...
<kgunn> SDoC is ahead of devices?
<jdstrand> kgunn: udf will pull from the store by default. If you grabs snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ they will be newer most of the time
<jdstrand> grab*
<jdstrand> I don't know if there are up-to-date downloadable images available yet
<jdstrand> I think they are being worked on? ogra_ would know best I think
<kgunn> jdstrand: but i'm just talking about the snap cli
<kgunn> i just built an ubuntu-core-image from moments ago
<kgunn> would think it's basically what's in archive
<kgunn> but maybe not...i suppose the snaps there take a bit to update
<kgunn> i see...
<kgunn> what you mena
<jdstrand> fyi, I'm stepping into a meeting and may be unresponsive for a bit
<almejo> hi! I have a question about snappy for desktop. I now I can create snap packages in 16.04. But how can i test them. Should i upload to the store? or can i install it with the command line
<primobasilio> almejo: you can install them using the command line. Even inside a clean Ubuntu Core kvm image.
<ogra_> kgunn, jdstrand, to get the very latest you wuld have to use the cdimage snaps ... they are not auto-submitted to the store yet
<ogra_> so there is delay until someone manually uploads them
<daker> ogra_: so, if i want to snap package libc & libm, how can i automagically do that ?
<ogra_> i'd use the copy plugin
<ogra_> put them into stage-packages and copy them into your snap dir
<daker> ogra_: any example to do that ?
<daker> or i just need to check the snapcraft examples
<daker> ?
<ogra_> no up to date one in my packages atm
<ogra_> so yeah, the examples are probably best
<daker> ok i'll check them
<daker> ogra_: if i understand correctly, i need to the .so from /lib/arm-linux-gnueabihf/ to the snap dir
<daker> to copy*
<daker> but how can i tell the snap to take account of the new libm/libc and not the system ones
 * daker is confused
<jdstrand> ogasawara: right-- how often are they generated?
<jdstrand> err
<jdstrand> ogasawara: nm
<jdstrand> ogra_: ^
<ogasawara> :)
<jdstrand> :)
<skypce> hell
<skypce> hello
<skypce> ca i install snappy package in ubuntu 16.04 beta 1?
<skypce> how can i do  it?*
<skypce> i want test it
<skypce> :)
<ogra_> jdstrand, daily
<ogra_> like isos :)
<jdstrand> right, that is what I though. thanks! :)
<roadmr> Are https://people.canonical.com/~mvo/all-snaps/ going to be updated? If not, where to get a suitably up-to-date image?
<ogra_> best is to build your own using the ubuntu-device-flash from there
<roadmr> thanks ogra_! will do
<ogra_> udo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc -o my-shiny-snappy.img
<ogra_> something like that
<roadmr> awesome :) (sudo)
<daker> ogra_: almost there :D
<wililupy> Ok, so I downloaded 4.4.0-18-generic source using apt-get source linux-image-4.4.0-18-generic, it installed in the linux-4.4.0 directory in my home directory. I build the snap with snapcraft snap, it builds, but for some reason, it builds /lib/modules/4.4.6? Am I missing something from my snapcraft.yaml or should I modify the source image name?
<wililupy> Also, uname -r in snappy says 4.4.6
<MichaelTunnell> will Snappy work with GNOME Software in 16.04?
<MichaelTunnell> I know that it could in the future because of the plugin structure of the app but just curious if that will be included
<sergiusens> ok, I am now finally on irc after a `snap install shout` on Digital Ocean :-)
<sergiusens> oh and with letsencrypt
<MichaelTunnell> whats shout
<sergiusens> MichaelTunnell http://shout-irc.com/
<MichaelTunnell> dang, no dark mode puts me out instantly
<MichaelTunnell> I could make one sure but meh
<sergiusens> MichaelTunnell there are dark themes fwiw
<sergiusens> jdstrand can you help me out with http://paste.ubuntu.com/15922408/
<sergiusens> please ? :-)
#snappy 2016-04-19
<jdstrand> sergiusens: yikes
<jdstrand> $ scmp_sys_resolver 317
<jdstrand> seccomp
<jdstrand> yeah, mmm, for now the best thing to do would be to disable the seccomp sandbox in firefox
<jdstrand> that is going to require some investigating to do safely (if at all). it might require seccomp arg filtering to land too
 * jdstrand adds a card
<sergiusens> jdstrand that can get complicated
<sergiusens> jdstrand  as in, do you mean I have to install with --devmode?
<sergiusens> ubottu hey
<MoPac> just started trying to use the snap / snapd support in ubuntu 16.04, and I'm confused about (among other things) removing snap packages. I installed mir-server, but can't remove it.
<sergiusens> MoPac as in `snap remove mir-server` did not work?
<MoPac> I.e.: "sudo snap install mir-server ....  error: can't install "mir-server": snap "mir-server" already installed  "
<MoPac> But then...
<MoPac> sudo snap remove mir-server error: can't remove "mir-server": cannot find mounted snap "mir-server" at revision 4
<sergiusens> MoPac did you have an old install of snappy or experimenting with it?
<MoPac> sergiusens: Not that I know of
<sergiusens> MoPac I logged a bug for something similar to that I think
<sergiusens> MoPac just log a new one and also add the output of `snap changes`
<sergiusens> MoPac I'll forward it to the developers
<MoPac> when I do locate mir-server, I do find a folder  in /var/li/snapd       and files in /etc/systemd/  (snapd.mir-server... and multi-user.target.wants/snap.mir-server...)
<MoPac> Is it possible those are part of some other installation?
<MoPac> There's also /var/snap/mir-server
<MoPac> But just this week when I installed it, it did a full download and everything through the snap command line command, so I just assumed all that other stuff was how this one system works
<sergiusens> MoPac those files look fine
<MoPac> Alas, and I'd hoped that snap packages would help tame the problem of an installed package's stuff being fragmented all over the filesystem..
<qengho> Man, either something is broken or I don't understand these new changes.
<qengho> On my classic machine, I had snappy and a few packages installed. Now, 1) "snap list" lists nothing. 2) I don't understand how to configure things.
<sergiusens> qengho the new changes landed were incompatible with what once was
<sergiusens> qengho I had to wipe and start from scratch
<sergiusens> they introduced a state machine
<qengho> Huh. I do like me some state machines.
<sergiusens> MoPac it does; those files are controlled by snappy itself; snaps cannot generate those
<qengho> Okay, so I'll remove debs with snap in the name, then look for filesystem artifacts, then install and start anew.
<sergiusens> qengho afaik you need to stop snapd, umount everything in /snap and wipe /var/snap
<sergiusens> check everything before wiping just in case :-)
<sergiusens> qengho do you have any gtk xp btw?
<qengho> sergiusens: some. Enough to hate ListStores
<MichaelTunnell> anyone know if will Snappy work with GNOME Software in 16.04?
<qengho> MichaelTunnell: 16.04 will ship with almost everything in the traditional deb format, including up-to-date Gnome. It also ships with the ability to package new stuff in the new snap format.
<sergiusens> qengho well this is more of a plumbing question :-) I saw there's an envvar that tells this /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache to go somewhere else ($SNAP_USER_DATA/ is my target of choice) but what about the contents of loaders.cache; is there a way to make that installtion path independent or in defect, to make gdk-pixbuf-query-loaders to look for them somewhere else?
<qengho> sergiusens: Ah, I don't know that detail.
<MichaelTunnell> qengho: I meant the integration with GNOME Software will snaps be installable with GNOME Software or only in terminal?
<qengho> MichaelTunnell: I'm sure snaps will be in the "store" program. That's almost like 1/4th the reason for inventing them.
<qengho> sergiusens: also, plenty in /var/lib/  :\
<qengho> Bed time. Back in 14 hours.
<qengho> Oh man. only 12. :(
<Alfredo> someone could help me  I want to mount a disk when system boot but fstab file overwrite on reboot
<Alfredo> in ubuntu snappy
<jdstrand> sergiusens: in devmode initially or compile without the seccomp sandbox. ChrisCoulson may be able to advise you on that
<jdstrand> sergiusens: you could try to add 'seccomp' to /var/lib/snapd/seccomp/profiles while testing to see if you need more or less, but I don't know if that is safe yet for the general case
<jdstrand> sergiusens: (consider the fact that if you can alter the seccomp sandbox, then, well, you can alter your sandbox)
<jdstrand> sergiusens: in theory, it should be ok, but it will take time to verify
<sergiusens> jdstrand now I follow! Thanks. I also have a bunch of gtk things to solve as well; so it is not my only blocker
<sergiusens> I wasn't aware gtk turned into this huge beast
<jdstrand> I can imagine
<jdstrand> yeah-- I tried with gcalculator
<jdstrand> it was pretty hideous
<jdstrand> I set like a thousand variables
<jdstrand> and then it still didn't work :\
<jdstrand> I talked to desrt about it and had more to try but had to focus on other snappy things and hadn't gotten back to it yet
<sergiusens> I might pick on didier's brain tomorrow or maybe seb's
<jdstrand> sergiusens: I don't know if this will help or not with firefox cause we were talking about gnome apps, but most of this is gtk stuff: http://paste.ubuntu.com/15923754/
<jdstrand> hopefully it isn't too hard to follow...
<jdstrand> I haven't worked through it so best to ask a desktop guy if you have questions
<jdstrand> fyi, my online-ness is going to potentially be a little odd the next couple of days, but I read backscroll
<jdstrand> I'm technically off tomorrow, but I may need to swap some things around
<sergiusens> jdstrand thanks
<netpheak> morning, guys!
<mvo> ogra_: fyi, I uploaded a new ubuntu-device-flash with less debug output and a new alpha image for amd64 with snap 2.0
<Gunther_> hi! Is it still mandatory to do snapcraft login for kernel builds (os.snap)? This can be a problem in our jenkins build environment ...
<zyga> good morning
<Gunther_> good morning
<_morphis> zyga: https://github.com/zyga/devtools/pull/5
<davmor2> ogra_: davmor2@davmor2-XPS-13-9343:~â« ubuntu-clock-app.clock /n can not find a snappy os I guess that is a bad thing right :)
<Gunther_> mvo: the new amd64-all-snap.img does not boot :(. I tested it using VirtualBox: unable to resolve 'LABEL=writeable'
<mvo> Gunther_: thanks, I will take it down again, its very confusing, it boots fine in qemu/kvm :/
<mvo> Gunther_: I assume you also converted it first? what commands did you run, just trying to reproduce this now
<Gunther_> VBoxManage convertfromraw amd64-all-snap.img all_snap.vdi --format VDI --variant Fixed
<mvo> ta
<Gunther_> ok it works if the vdi is attached to IDE but fails if the image is attached to SATA
<mvo> Gunther_: wuut? thats strange
<mvo> Gunther_: I suspect a kernel issue, let me try to reproduce and then play around with the kernel. thanks a bunch for this hint
<Gunther_> No SATA support in the kernel?
<mvo> Gunther_: could be, or missing chipset or buggy or soemthing
<Gunther_> Just reproduced this on real hw: If the SATA port is set to legacy IDE in BIOS, it boots. But not if it is set to SATA. This is not only a VirtualBox issue
<dholbach> bzoltan_, what kind of ldd does the copy plugin do?
<bzoltan_> dholbach:  it ldd's the content of my directory and fails on many of the
<stevebiscuit> Gunther_: I've had the same problem running under VirtualBox, attaching the image to the IDE controller seems to resolve it
<dholbach> sergiusens, kyrofa: ^ do you know which problem bzoltan_  might be having?
<dholbach> bzoltan_, you got cut off
<mvo> Gunther_: thanks a bunch
<bzoltan_> dholbach:  thanks
<mvo> Gunther_: I can reproduce it , digging into it now
<Gunther_> mvo: the naming of the net interfaces is also back to the classic "eth0" ...
<Gunther_> is that intenionally
<mvo> Gunther_: a good question, I need to investigate this too
<Gunther_> mvo: ok :)
<dpm> hi all. I'm trying to clean up a desktop system after the move from /snaps to /snap. It looks like /var/lib/snappy/snaps contains a bunch of apps I installed a while ago. Is it safe to just 'rm -rf /var/lib/snappy/snaps'?
<Gunther_> mvo: we seem to got a kernel upgrade after the first boot. The net interface names are enp0sX again,
<popey> dpm: that's what I did, nuke the directory after stopping snapd
<dpm> thanks popey. Done that and reinstalling everything now
<dpm> popey, dholbach, does the calculator app work for you? http://pastebin.ubuntu.com/15927521
<dpm> trying clock now
<zyga> _morphis: thank you, merged!
<popey> dpm: i get same
<popey> dpm: clock fails in the same way
<zyga> popey, dpm: are those snaps using unity7 plug?
<dpm> popey, zyga, actually, they're still unconfined in the store. Let me see if I can update their yaml files and re-upload
<dpm> zyga, mvo, do you happen to know in which folder the .desktop file and icon should be dropped in for snapcraft?
<dpm> last time I talked to sergiusens it was: setup/gui/DESKTOP_FILE
<dpm> setup/gui/icon.png
<dpm> but I don't know if that's changed since
<Gunther_> I seem to be unable to remove a sideloaded kernel.snap. Also to try to reinstall it fails: error: cannot perform the following tasks: - Mount snap "trionet-kernel" (cannot find mounted snap "trionet-kernel" at revision 100001)
<Gunther_> sudo snap remove trionet-kernel_4.4.0_amd64.snap  error: can't remove "trionet-kernel_4.4.0_amd64.snap": cannot find snap "trionet-kernel_4.4.0_amd64.snap"
<Gunther_> I am missing snappy ...
<mvo> dpm: meta/gui is the folder
<mvo> Gunther_: uh, oh :/ I assume all of this worked before? that are regressions that we need to tackle
<dpm> mvo, thanks. And then do I need to remove the 'icon' field or do anything different with the in snapcraft.yaml?
<mvo> I'm curious if a 4.4.0-18-generic kernel boos in virtualbox on sata
<mvo> dpm: I think you can just remove it, if that does not work I will dg into the code
<popey> ogra_: i see a canonical-pi3 in the store, does that mean we have a pi3 image somewhere?
<dpm> thanks mvo!
<Gunther_> mvo: I had issues before, I could remove a kernel.snap, but grub failed on reboot. See my posting on the mailing list.
<ogra_> popey, you can just build one :)
<popey> ogra_: but I will end up with sideloaded things I can't update?
<ogra_> popey, sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi3 -o test.img
<popey> e.g. my current image has a sideloaded canonical-pi3, which refuses to be replaced
<ogra_> get the latest udf from mvo though
<dpm> mvo, last question: https://github.com/ubuntu-core/snapcraft/blob/master/docs/metadata.md#snap-icon seems to indicate there should be a setup/gui directory - is that different from the meta/gui one or are the docs simply not up-to-date?
<ogra_> popey, right, because i built it from local files back then
<popey> ogra_: will building it as above make it so i can store update the snaps?
<ogra_> yes
<popey> sweet
<popey> where's this funky udf?
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<popey> tata
<dpm> dholbach, popey, ok, I got a local build of clock working. I just need to figure out this stuff with the desktop file, see if I can get the x86 build as well, and then I'll upload to the store
<Gunther_> mvo: regarding you question about4.4.0-18-generic: I am running a standard Ubuntu xenial on VirtualBox + SATA
<Gunther_> mvo: uname -a Linux glaure-1604 4.4.0-18-generic #34-Ubuntu SMP Wed Apr 6 14:01:02 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<mvo> Gunther_: thanks! what is your lsmod output on this system?
<mvo> ogra_: I think we can push updated images today (yay), however still investigating a virtualbox issue that looks like kernel or kernel modules issue
<ogra_> k
<Gunther_> mvo: http://paste.ubuntu.com/15927730/
<mvo> ogra_: its very strange, it fails to boot in virtualbox on sata, its fine on ata
<mvo> thanks Gunther_
<ogra_> uuh
<mvo> ogra_: I wonder if modules are missing from the kernel
<ogra_> with our kernel ?
<Gunther_> mvo: not limited to virtualbox - it does not boot on SATA
<ogra_> Gunther_, did you try the default kernel snap too ?
<Gunther_> ogra_: no but it is easy to test for me. Which one should I use?
<mvo> ogra_: its our kernel, I can reproduce it here too
<ogra_> ah
<mvo> ogra_: I'm poking around in my busybox shell and it looks its very few .ko files only
<ogra_> mvo, yeah, i switched to MODULES=list ...
<ogra_> (saves up to 20MB (compressed !))
<ogra_> i guess we'll need to add sata to the list then
<mvo> ogra_: something funny going on, the unpacked kernel snap has a lot more than what I see in my initramfs shell. do we do double initramfs loading or anything fancy
<Gunther_> another issue is the naming of the network interfaces. At the first boot they are "ethX" on all following they are "enp0sX". This generates wrong entries at /etc/network/interfaces.d resulting in no valid net configuration after the first boot
<ogra_> mvo, huh ? you mean the initrd in the kernel snap ?
<mvo> ogra_: oh, sorry, no, my mistake
<mvo> ogra_: the initird I need to poke at next, phonecall rightnow
<ogra_> mvo, all initrds should only have squashfs nowadays
<ogra_> mvo, we either list all controller modules or i switch back to MODULES=most
<mvo> ogra_: I think we miss controller modules, it seems they are =m
<ogra_> mvo, yes
<ogra_> i can add them all
<daker> kyrofa: what's the equilvant to "environment" in snapcraft 2.x ?
<sergiusens> bzoltan dholbach log a bug please or give a pastebin at least. In the end we ldd and copy everything not in Ubuntu core and if it fails due to missing libs it will probably fail on install as well
<ogra_> mvo, seems it is just "ahci.ko", i'll add that to the list ... if thats not enough we can switch back to MODULES=most
<mvo> ogra_: thanks
<ogra_> Gunther_, wiould you mind trying that ? (adding ahci to your initrd modules in the kernel snapcraft.yaml so you end up with it installed )
<sergiusens> dpm those paths are correct
<mvo> ogra_: will you regenerate the image once you did that?
<ogra_> mvo, indeed
<Gunther_> ogra_: sure I can try that
<mvo> ogra_: \o/
<dpm> hi sergiusens - which ones are correct? meta/gui? setup/gui? Or both?
<ogra_> to sad that the modules code is non arch specific in initramfs-tools ... we'll never need ahci on other arches i guess
<ogra_> (arm and friends i mean)
<dholbach> dpm, excellent
<sergiusens> setup/gui
<sergiusens> Unless you are doing raw packaging which you aren't
<zyga> dpm: try setup/foo.desktop
<zyga> dpm: the icon should be in the main part of the snap, you can refer to it with $SNAP/some/path/icon.png
<zyga> dpm: the desktop file is correctly parsed and sanitized, copied to the right spot
<kalikiana> So... as of today's upgrade on my Xenial, "snappy" is gone, "snap" installs and runs snaps to /snap/ - but the snaps stop working after reboot and disappear from "snap list" - is this the right place to ask how to solve it?
<zyga> dpm: the icon is not copied there so it has to live with the main body of the snap
<zyga> kalikiana: yes,
<zyga> kalikiana: which snaps did you install?
<kalikiana> zyga: I had hello-world for example. I was able to run the commands from it. Now it's gone and I can't exec it anymore: execv failed: No such file or directory
<kalikiana> It seems like there are no mounts anymore
<zyga> kalikiana: do you hvae the snappy PPA or is that all from xenial proper?
<zyga> kalikiana: oh, interesting
<kalikiana> zyga: no snappy PPA, just Xenial
<zyga> mvo: I recall you mentioned this in the telegram channel, is that a bug in xanial that we don't mount snaps on reboot?
<kalikiana> zyga: I do have two mounts from the previous "snappy" command which is now gone, hello-world and docker
<kalikiana> Maybe that conflicts somehow?
<kalikiana> But I have no way of removing those now
<zyga> kalikiana: I'm not sure but I would recommend a resetting your state, snap remove everything (if you can), remove snapd, remove everything in /var/lib/snapd and in a few other places
 * zyga should publish that reset-snappy script
<zyga> kalikiana: can you wait 20 minutes? I'll do this properly and then help you out
<kalikiana> remove doesn't work: error: can't remove "hello-world": cannot find mounted snap "hello-world" at revision 23
<kalikiana> zyga: Sure, no hurry
<Gunther_> ogra_: adding ahci seems to be non trivial for me. Please have a look at http://paste.ubuntu.com/15928133/
<bzoltan_> Would somebody show me the simplest example of the copy plugin use?
<Gunther_> ogra_: I am getting the error: modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci [Errno 2] No such file or directory: 'ahci' -> '/home/jenkins/Mercuria l/SW_APP/snap/driver/trion/parts/kernel/build/initrd- staging/../../../ahci'
<ogra_> Gunther_, might be you also need libahci
<ogra_> Gunther_, is ahci enabled in your initrd ?
<ogra_> err
<ogra_> in your kernel config ... sorry
<ogra_> oh, i see it
 * ogra_ wonders if the two optiojns are actually enough
<ogra_> aha, you need CONFIG_ATA too
<Gunther_> ok
<ogra_> sergiusens, ^^^ how does the kernel plugin check config dependencies in snapcraft ?
<ogra_> seems if i enable a high level config the low level deps are not getting enabled is the plugin just mangling .config or does it use some kernel config script ?
<Gunther_> afaik the kernel plugins does nothing else than to run make "defconfig" and adding the given configuration from snapcraft.yaml
<Gunther_> if no config file is given
<ogra_> yeah, that wouldnt select the dependencies
<dpm> zyga, sorry, I was on the phone, reading the backlog now, thanks
<sergiusens> ogra_ we don't, you are in charge
<ogra_> sergiusens, ouch
<sergiusens> mvo zyga please don't talk to people about internal layouts
<zyga> sergiusens: do you mean setup?
<sergiusens> zyga I mean `meta/gui`
<zyga> ah, sorry
<zyga> I will focus on the setup/ side
<sergiusens> zyga if you do that, then you have to go into details of how the process works and I get questions from dpm of the type "which one is it?"
<mvo> sergiusens: well, I was asked about it, but yeah, I missed the context, of course dpm should just use the snapcraft primitives for this
<dpm> sergiusens, zyga I'm totally confused.
<dpm> could someone just tell me:
<dpm> - where should the desktop file go?
<sergiusens> also making him think he has to put something manually in snap/meta
<dpm> - where should the icon file go?
<sergiusens> that is impossible and not feasable
<sergiusens> mvo anyone asking about packaging setup here would ask about it from the snapcraft side here ;-)
<sergiusens> mvo zyga which is why I wanted you guys to start using it ;-)
<sergiusens> dpm so TOPDIR/snapcraft.yaml; TOPDIR/setup/gui/icon.png
<zyga> hmmm
<dpm> sergiusens, ok, that makes sense, thanks. And which location for the desktop file?
<sergiusens> the docs were pretty clear in that respect, unless of course someone took you down the rabbit hole of looking in snap/meta ;-)
<zyga> sergiusens: please also explain how the desktop file should correctly relate to the icon file because that's non-obvious
<sergiusens> dpm same TOPDIR/setup/gui/<desktop>.desktop
<dpm> perfect
<dpm> sergiusens, hm, but are there docs about it already? I couldn't find any mentions to the .desktop file in docs
<sergiusens> zyga from your point of view; anything that is by convention goes into `setup`; the by convention for desktop files is going to suck a bit, but it is what we ended up with
<dpm> anyway, that's the answer I was looking for, I'll add that to the clock app, thanks!
<sergiusens> dpm no, desktop file is probably not mentioned. Let me check
<dpm> sergiusens, I was looking at https://github.com/ubuntu-core/snapcraft/blob/master/docs/metadata.md#snap-icon
<zyga> sergiusens: I'm not disputing that, just the Icon=... line is tricky and requires voodoo to decuce by onself; we should just say how it should look like for things to wokr
<zyga> sergiusens: (AFAIR it should say Icon=$SNAP/meta/gui/icon.png)
<zyga> sergiusens: i.e. using $SNAP is mandatory for the icon to work in practice
<sergiusens> zyga I thought you'd fix that on snap install
<zyga> sergiusens: but I may be wrong, plesae correct me
<zyga> sergiusens: I don't know :)
<sergiusens> zyga I have no idea; but if someone who has no idea has to do Icon=$SNAP/meta/gui that is indeed crappy
<kyrofa> Good morning
<zyga> sergiusens: later on I'll try and get back to you
<sergiusens> kyrofa morning
<kyrofa> Hey sergiusens :)
<zyga> hey kyrofa
 * sergiusens is still chatting from his ubuntu phone hooked up to a bt keyboard using shout as a snap on digital ocean
<sergiusens> I'm all in
<dpm> mvo, do you have the sources for cap-test.xbomb somewhere? I'd like to see how Icon= is specified in the .desktop file ^^
<kyrofa> sergiusens, nice
<zyga> dpm: AFAIR just unsquasfs it, there is no source
<dpm> ok, thanks
<dpm> zyga, sergiusens, can I use the copy plugin to copy the generated .desktop file and icon to setup/gui to avoid duplicating files in the clock app sources?
 * zyga doesn't know
<dpm> or does the desktop/icon file voodoo happen before the plugin is run?
<sergiusens> dpm no, and this is the sucky part about files with convention
<mvo> dpm: no sources unfortunately only the unpacked squashfs, you can look at /snap/cap-test/current/meta/gui/xbomb.desktop to see the "source" of the desktop file
<dpm> ok, thanks all
<sergiusens> dpm so, I'll prepare a fix so you can use relative paths from the desktop file to find the icon
<dpm> ok
<dpm> so cap-test specifies:
<dpm> Icon=${SNAP}/xbomb.png
<dpm> on the .desktop file, so I'll go for that for now
<sergiusens> dpm I guess the desktop icon can point to anywhere, but the package icon has to be in the location I mentioned
<sergiusens> if you want a nice icon in the store or whatever UI
<dpm> sergiusens, ack
<dpm> mvo, on the cap-test desktop file I also see a "StartupNotify=true" key. Do I need to add that to the clock app's desktop file as well?
<mvo> dpm: I'm not sure, it won't hurt but if upstream does not have it, you can probably ignore it
<zyga> dpm: that used to make icons bounce but I don't know if unity even implements that nowadays
<ogra_> mvo, bah, on x86 it isnt possible to easily inject your own initrd into an image, right ?
<Gunther_> sergiusens, ogra_ : I think I have found a kernel build issue in snapcraft. If a add more modules as kernel-initrd-modules like here: http://paste.ubuntu.com/15928133/   this information is used in the kernel plugin like this:  modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci
<dpm> ack, thanks zyga
<Gunther_> but only squashfs will generate valid output: modprobe -n --show-depends -d /home/jenkins/Mercurial/SW_APP/snap/driver/trion/parts/kernel/install -S 4.4.5-trion+ squashfs ahci
<dpm> sergiusens, mvo, does this look ok in terms of adding the .desktop file + icon to the clock app? -> http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/revision/468
<mvo> dpm: looks good
<dpm> awesome, thanks!
<ogra_> Gunther_, yeah, that bneeds to be a per-module loop
<ogra_> modprobe cant take a list in this case
<Gunther_> ogra_: I will patch the kernel.py plugin and try that
<ogra_> ogra@styx:~/all-snaps/amd64$ modprobe -n --show-depends  squashfs ahci
<ogra_> insmod /lib/modules/4.4.0-18-generic/kernel/fs/squashfs/squashfs.ko ahci
<Gunther_> exactly
<ogra_> it thinks the second module name is a parameter
<Gunther_> Should I report this as a bug?
<ogra_> yes
 * dpm starts building clock app with desktop file support
<dpm> mvo, sergiusens, am I supposed to see the icon in the dash and launcher for sideloaded apps? I built clock adding the desktop and icon files, sideloaded it, and I can only see a blank icon in the dash and launcher
<zyga> dpm: look at the dekstop file
<zyga> dpm: and see what it referes to
<dpm> zyga, http://pastebin.ubuntu.com/15928862/
<zyga> dpm: thanks, let me check
<dpm> zyga, so it seems I still need to manually put the icon file in $TOPDIR in addition to setup/gui?
<zyga> dpm: wait, I think something is wrong
<zyga> dpm: ${SNAP} should have been expanded
<zyga> dpm: looks like a bug somewhere
<dpm> zyga, weird, for cap-test I can see the icon, though, and the ${SNAP} in the desktop file is not expanded either
<dpm> zyga, but the difference there is that cap-test does ship an icon in the top directory
<zyga> ahh
<zyga> I'm dumb
<zyga> dpm: of course -- that content is read only
<zyga> dpm: look at /var/lib/snapd/desktop/
<zyga> dpm: that will be what you want
<zyga> dpm: how does your desktop file look like there?
 * dpm looks
<dpm> zyga, http://pastebin.ubuntu.com/15928960/
<zyga> dpm: then rebuild the snap with Icon=${SNAP}/meta/gui/icon.png
<zyga> and put the icon in setup/gui/icon.png
<dpm> zyga, yeah, the icon is already there, I'll just need to update Icon=
<dpm> let me give it a go
<zyga> \o/
<Gunther_> ogra_: https://bugs.launchpad.net/snapcraft/+bug/1572118
<ubottu> Launchpad bug 1572118 in Snapcraft "kernel plugin _make_initrd fails to add given modules" [Undecided,New]
<zyga> sergiusens: can you patch snapcraft to generate: exec ... "$@"
<zyga> sergiusens: $* is a bug
<dpm> zyga, it worked! :-)
<dpm> zyga, but I guess that's still a bug in the sense developers should not know about meta/gui, right?
<ogra_> Gunther_, thanks
<zyga> dpm: perhaps
<xorrr> hi, in the snappy 15.04 img for raspberrypi2 there was apt-get in /usr/bin, i have use this to install wget to download scripts, in the 16.04 img apt-get seems to not be present anymore, what would be my alternative to have access to non-snap tools?
<jibel> seb128, I had cap-test, clock and calculator installed from software center and after a reboot they are all gone.
<zyga> xorrr: use classic dimension
<zyga> jibel: there's a bug where we don't mount snaps on reboot apparently
<jibel> nice
<seb128> jibel, ubuntu software you mean? ;-)
<seb128> jibel, is snap list listing those?
<jibel> seb128, yeah .*sofware.*
<sergiusens> zyga yes we can; we already have a PR even
<jibel> seb128, nope
<seb128> k
<zyga> sergiusens: fantastic, thank you :)
<jibel> zyga, you have a bug #?
<seb128> so what zyga said I guess
<zyga> jibel: no sorry
 * ogra_ curses ... 
<sergiusens> ogra_ use a gui or ncurses instead
<ogra_> mvo, what was the exact line for the task override ? was that "XB-Task: ubuntu-core" ?
<ogra_> sergiusens, i prefera a good dialog :P
<mvo> ogra_: yeah
<ogra_> damn thing ... always gets in my way
 * ogra_ ponders if waiting for 30min for the archive publisher or if uploading another package to the PPA ... 
<ogra_> i guess the time it takes will be the same now
<mvo> ogra_: yeah, the task header is anoying
<jibel> zyga, I filed bug 1572125
<ubottu> bug 1572125 in ubuntu-snappy (Ubuntu) "install snaps are gone after a reboot" [Undecided,New] https://launchpad.net/bugs/1572125
<zyga> jibel: thank you
<xorrr> zyga, can't follow, classic dimension? is this a tool?
<ogra_> who reboots anyway ... this is linux, not windows
 * ogra_ grins evil 
<zyga> xorrr: it's a way to use classic ubuntu on snappy
 * zyga reboots to test that bug
<mvo> jibel: what does /etc/systemd/system/multi-user-target.wants/snap-*.mount looks like?
<jibel> mvo, snap-*.mount or snaps-*.mount ?
<mvo> jibel: all of them, should be snap-* but if you have snaps instead that might be a clue too
<jibel> mvo, http://paste.ubuntu.com/15929159/
<jibel> mvo, there is no snap-*.mount
<mvo> ta
<zyga> jibel: reproduced and confirmed
 * ogra_ taps foot
<ysionneau> zyga: I think the hash of ubuntu-device-flash (from mvo) changed again
<ysionneau> I get integrity issues when using ubuntu-image
<zyga> ysionneau: would you mind sending a pull request, I'm in a call
<ysionneau> ok
<Gunther_> ogra_: the initrd now contains ahci.ko, still no success -> i will add libahci.ko too
<ysionneau> zyga: done: https://github.com/zyga/devtools/pull/6
<ogra_> Gunther_, yeah
<dpm> dholbach, popey, I just uploaded a working ubuntu-clock-app, would you mind reviewing it and approving if it works for you?
<kalikiana> zyga: Can you elaborate on how to "reset" snap/snappy? I'm happy to just remove all local data and try again to see if that resolves things.
<dholbach> dpm, sure
<zyga> kalikiana: working on it
<zyga> kalikiana: in a call, give me a moment
<sergiusens> kyrofa and zyga https://github.com/ubuntu-core/snapcraft/pull/473
<kalikiana> Okay
<dpm> dholbach, thanks! it seems the store still doesn't yet have the opengl interface?
<sergiusens> kyrofa and zyga https://github.com/ubuntu-core/snapcraft/pull/473
<zyga> sergiusens: thanks :)
<dholbach> dpm, click-reviewers-tools don't have it
<dholbach> I have the same problem locally
<dholbach> let me see if it's updated in the branch
<dholbach> no, it doesn't seem to be in there either
<dholbach> filing a bug
<dholbach> https://bugs.launchpad.net/click-reviewers-tools/+bug/1572140
<ubottu> Launchpad bug 1572140 in Canonical Click Reviewers tools "click-reviewers-tools don't know opengl interface" [Undecided,New]
<dholbach> known issues doc updated as well
<dpm> thanks dholbach
<dholbach> dpm, hohum...
<dholbach> error: cannot perform the following tasks:
<dholbach> - Mount snap "ubuntu-clock-app" (cannot find mounted snap "ubuntu-clock-app" at revision 100001)
<dpm> dholbach, what's that the output of?
<dholbach> sudo snap install <snap>
<dpm> dholbach, is that perhaps the result of rebooting and the issue with sideloaded apps?
<dholbach> maybe
<dholbach> this morning I had an issue like this when the state.json file was in an inconsistent state
<popey> uh
<popey> you need to sudo snap install ./snap
<popey> not sudo snap install snap
<dholbach> that was fixed
<popey> or it tries to get it from the store
<popey> oh
<qengho> "./"
<popey> things move fast here :)
<dholbach> https://github.com/ubuntu-core/snappy/pull/908
<dpm> I generally give it the full *.snap filename when I sideload
<qengho> Is it a test for a slash?
<_morphis> zyga: ping
<zyga> hey
<ogra_> mvo, fixed kernel snap works fine (with ahci added to the initrd)
<qengho> Okay, it's a new world. Where did "snappy config" and "snappy activate" functionality go?
<ogra_> once all arches are done i'll push to the store
<zyga> _morphis: I assume you are asking about bluez/nm interfaces
<Gunther_> ogra_: Are you sure? Can look intp the kerne config?
<ogra_> Gunther_, it is the linux-generic default config ... i just made sure ahci and libahci end up inside the initrd
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503/+files/livecd.ubuntu-core.kernel.snap has the changed initrd
<_morphis> zyga: yes, jdstrand said he gave you a patch to get the plug names into the policy
<popey> dpm: clock app launches here
<zyga> _morphis: yes, for bluez, I didn't do it yet but I have a TODO for today to do it
<zyga> _morphis: we're doing another relase now
<Gunther_> ogra_: ok. I have both in but still no success.
<popey> dpm: some apparmor issues, but launches http://paste.ubuntu.com/15929760/
<ogra_> Gunther_, well, works just fine here
<_morphis> zyga: we should get ssweeny bluez interface fix in for that
<zyga> _morphis: we've been fighting bugs and I was also really taking a slow day today
<_morphis> zyga: :-)
<ogra_> i'm looking at a booted vbox
<_morphis> zyga: you have that patch available? can take a look at it too
<zyga> _morphis: I've +1d it; it may get merged today, if not we're also planning 0-day SRU
<Gunther_> ogra_: I must have done something different/wrong. I ll investigate
<zyga> _morphis: the priority today is to not break the 16.04 release and fix critical bugs
<dpm> popey, indeed, these are known issues that might need a fix in the toolkit
<_morphis> zyga: aye
<zyga> _morphis: I'll ping you when I'll get back to bluez
<dpm> popey, dholbach, ok to approve clock, then? Calculator is building and I'll upload it next
<popey> it must have been approved if I got it from the store :)
<_morphis> zyga: thanks
<dholbach> dpm, it's approved
<sergiusens> dpm dholbach have you guys tried any gtk apps? Those seem to be more complicated than anticipated :-)
<mvo> ogra_: \o/
<mvo> ogra_: thanks for fixing this
<sergiusens> well, I know less about gtk than Qt at least
<dpm> sergiusens, we have IIRC, it seems getting the theming to not look like 1990  is one of the biggest issues
<ogra_> oh, whee !!!
<ogra_> http://i.imgur.com/gSPT5uj.png
<ogra_> sergiusens, ^^^
<zyga> ogra_: is that m10?
<dpm> ogra_, hangouts working? :-)
<ogra_> yep
<ogra_> and yep :D
<dpm> \o/
<zyga> woooow
<Gunther_> ogra_: Which config do I have to add to the kernel config to get /proc/config.gz  ?
<Gunther_> ogra_: I think my problem is related with EXT4 filesystem upport
<ogra_> CONFIG_IKCONFIG_PROC
<ogra_> you want ext4 compiled in
<Gunther_> ogra_: thanks and thanks
<sergiusens> ogra_ you even have video on! wow
<ogra_> sergiusens, yeah, fully working
<sergiusens> ogra_ not surprised that it works, only surprised that you have video on :-P
<sergiusens> ogra_ this means it should eventually work on my phone; I want oSoMon to SRU the change into xenial; I'm using the webbrowser on desktop too; so much more light weight :-)
<popey> 14:51 < ogra_> http://i.imgur.com/gSPT5uj.png
<popey> that is the _first_ time I have ever seen ogra in a hangout :)
<ogra_> LOL
<ogra_> sergiusens, it is just three lines in the UA override file, worst case you can hack that in yourself
<_morphis> jdstrand: pushed a reworked version of the networkmanager interface
<qengho> Okay, so looks like "config" and "activate" are being reimplemented. Foo.
<dholbach> Did anyone ever seen an issue like this?
<dholbach> daniel@daydream:/tmp/2048.qml$ sudo snap install 2048-qml_1_amd64.snap
<dholbach> error: change finished in status "Hold" with no error message
<dholbach> or is this related to the current state issues which are being investigated?
<dholbach> zyga, ^?
<zyga> one sec
<Gunther_> where should I report a bug concering "snap"? https://bugs.launchpad.net/snappy ?
<zyga> dholbach: we saw it but it's still unclear what's going on
<zyga> Gunther_: yes
<dholbach> zyga, shall I file a separate bug for it?
<zyga> dholbach: yes, I think so
<zyga> dholbach: that one looks a bit different
<dholbach> ok, will do
<zyga> thank you
<dholbach> zyga, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175
<ubottu> Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New]
<zyga> dholbach: could you try this script https://github.com/zyga/devtools/pull/7/files
<zyga> dholbach: use it to reset your state
<zyga> dholbach: reboot
<zyga> dholbach: and see if you can reproduce the issue
<dholbach> zyga, I reset it this morningg already
<dholbach> but can try
<dholbach> but can try again
<zyga> dholbach: don't reboot again (that will trigger another bug)
<zyga> dholbach: if you can reproduce on top of that "clean slate" I will check it out locally
<pedronis> dholbach: zyga: that one is weird it means all tasks for a change are in hold
<pedronis> more interesting would
<pedronis> what snap changes gives
<pedronis> before resetting everything
<zyga> dholbach: ^^^
<zyga> pedronis: (good point)
<ppisati> ogra_: i'm testing some custom kernel with snappy, but i'm having an hard time debugging why it fails in initrd
<dholbach> I'm not sure I understand
<dholbach> what am I supposed to do?
<zyga> dholbach: pastebin snap changes
<pedronis> dholbach: sorry there's  command called "snap changes"
<ogra_> ppisati, why is that ?
<dholbach> ah ok, thanks
<Gunther_> ppisati: welcome to my world :)
<dholbach> zyga, pedronis: http://paste.ubuntu.com/15930423/
<ppisati> ogra_: basically, it fails while mounting root in /tmp_writable/system-data/var/lib/snappy/... /root
<ppisati> ogra_: and i noticed that .../snappy/... is not there
<ogra_> ppisati, old initrd then
<ppisati> ogra_: before that i don't see any error
<ogra_> the path changed a while ago
<zyga> ppisati: it's now /var/lib/snapd
<ppisati> ogra_: ok, so, what am i doing wrong?
<ogra_> use a recent initrd
<ppisati> ogra_: i'm building thekernel using snapcraft kernel pluging on a 4.4 kernel
<ppisati> ogra_: on a xenial chroot
<ppisati> *in
<ogra_> latest snapcraft on xenial ?
<ppisati> ogra_: from github
<ogra_> with all your snapcraft login data present ?
<ppisati> ogra_: yes
<ogra_> weird
<ogra_> sergiusens, you should realÃ¶ly pull from cdimage :P
<ppisati> ogra_: how do i check if i'm using an old initrd?
<popey> jdstrand: sorry, realised i asked that in the wrong channel - 15:36 < popey> jdstrand: did we get an answer about what we do with apps which need w access to /var/cache/fontconfig/ ?
<ppisati> just to be sure
<ogra_> well the initrd has a version attached to the file inside the os snap ... not sure the plugin prints that somewhere
<ogra_> *attached to the filename
<pedronis> dholbach: what does "snap changes 8"  "snap changes 9" and "snap changes 10"Â and "snap changes 11" give ?
<dholbach> pedronis, http://paste.ubuntu.com/15930491/
<dholbach> sorry, forgot 11
<dholbach> http://paste.ubuntu.com/15930498/
<ogra_> ppisati, i think Gunther_ added a patch that allows you to use a local os snap for this ...
<ogra_> not sure if that landed already
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the most recent one
 * ppisati checks
<pedronis> dholbach: 11 is empty super weird
<zyga> kalikiana: hey, sorry ofr the delay
<zyga> kalikiana: can you please try this: https://github.com/zyga/devtools/blob/master/reset-state
<pedronis> dholbach: what do you have in ls /snap/ubuntu-clock-app/  and /snap/ubuntu-clock-app/100001 ?
<zyga> kalikiana: this will give you a clean slate for experiments and reporting bugs
<dholbach> pedronis, http://paste.ubuntu.com/15930578/
<pedronis> dholbach: you 100001 is empty
<pedronis> that seems the reboot bug
<dholbach> yep, it looks like it
<pedronis> IÂ mean the mount/reboot bug
<pedronis> dholbach: so all you errors are accounted for
<pedronis> dholbach: the empty 11 on Hold is super strange though
<dholbach> ok, cool - thanks a lot
<pedronis> seems like a crash or something
<pedronis> dholbach: anything interesting in the snapd logs ?
<popey> dpm: dholbach have you packaged any non-qml graphical apps?
<dholbach> can you remind me how I check again? something with journalctl?
<zyga> dholbach: journalctl -u snapd
<dholbach> thanks
<zyga> pedronis: perhaps we should add some instructions for people reporting bugs on lauchpad, to pastebin $ snap changes, journalctl, etc
<sergiusens> ogra_ I could and I wanted to but I couldn't find the snaps
<ogra_> sergiusens, oh ?
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<dholbach> pedronis, http://paste.ubuntu.com/15930649/
<ogra_> sergiusens, you want the *.os.snap files ...
<sergiusens> ogra_ I need it tied to xenial though
<ogra_> ah
<ogra_> that might only happen post release
<sergiusens> If not, once Y opens we will start picking from there and will have to SRU
<ogra_> (unless you want to first check the default path and then fall back to a xenial one)
<ogra_> well, fo Y the files will have the Y name as prefix
<dholbach> popey, no, sorry
<dholbach> I tried, but failed
<popey> hm, same
<popey> ok
<popey> ta
<sergiusens> I would rather leave it complicated as it is now so people get the fact that most of the kernel snaps they build are bound to break
<ogra_> well, you are heavily relying on the assumption the dual initrd approach will actually work :)
<ogra_> something nobody tested yet :)
<ogra_> geez, uploading one set ofr snaps for all arches takes 1h of my day ... so annoying
<ppisati> FWIW, using the xenial src tree and the exact xenial config, i was able to build a working kernel
<ppisati> but when i started to reduce the config (start from x86_64_defconfig and add the systemd/ubuntu core options etc)
<ppisati> i always end up in the initrd shell
<ogra_> that sounds liek you disable something you shouldnt disable :)
<ppisati> cause iit can't mound the root snap in /tmp_writable etcetct
<ppisati> ogra_: yep
<ogra_> moving ext4 to a module ?
<ogra_> or some such
<ppisati> ogra_: nope
<ogra_> do you have squashfs defined in your initrd mopdules ?
<zyga> dholbach: could you please link/attach all the pastebins to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175
<ubottu> Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New]
<dholbach> zyga, sure
<zyga> dholbach: thanks!
<ppisati> ogra_: yes, it's there and it's loaded
<dpm> popey, I haven't myself, no
<ppisati> ogra_: the question is: i'm missing a part of
<dpm> popey, while dholbach are on a call, would you mind doing the calculator review on the store?
<ppisati> ogra_: /tmp_writable/system-data/var/lib/snappy/...
<ppisati> ogra_: where does it reside?
<dholbach> dpm, already done
<pedronis> dholbach: those in Hold (no Error)Â you should have got a message from snap the command, they are just left over of us creating the change before all the pre checks are done
<ogra_> ppisati, inside the initrd ubuntu-core script
<dpm> awesome, thanks dholbach
<pedronis> nothing too serious we will fix
 * dpm updates spreadsheet
<ogra_> ppisati, you definitely have an old initrd
<ppisati> ogra_: but then why it works with the full config?
<ppisati> ogra_: do you mind if i pass a kernel to test and you can confirm me it's an old initrd problem?
<ppisati> ogra_: amd64 for kvm
<ogra_> sure
<ppisati> ok, one sec
<dholbach> zyga, pedronis: so you suggest I run the reset-state script now and try again? or reboot?
<dholbach> sorry if I'm a bit unconcentrated - I was in calls while we were looking at the problem
<ogra_> mvo, (or beuno) ... please approve the set of http://paste.ubuntu.com/15930802/ (thats the full set of snaps with the fixed initrd)
<pedronis> dholbach: the reset will not help IÂ think
<dholbach> ok
<pedronis> dholbach: what you need is the fix for the mount issues
<dholbach> that's 2.0.2 which went to the archive earlier?
<pedronis> dholbach: mvo can tell you more about how to work with that
<pedronis> dholbach: I think so, but not sure, mvo can tell
<dholbach> ok cool
 * zyga checks to offload mvo
<pedronis> dholbach: you may need to cleanup snaps manually or fix some systemd units
<ppisati> ogra_: http://people.canonical.com/~ppisati/xenialsnappyfuffa2defconfig_4.4.0_amd64.snap
<ppisati> yeah, the name is stupid, i know...
<dholbach> so just installing 2.0.2 didn't fix it
<zyga> dholbach: use my reset script after installing 2.0.2
 * zyga doesn't have 2.0.2 yet
<dholbach> ah ok
<dholbach> will do
<zyga> dholbach: then reinstall snaps you had
<pedronis> dholbach: because the old units need fixing
<dholbach> zyga, https://launchpad.net/ubuntu/+source/snapd/2.0.2/+build/9597800
<zyga> pedronis: the script removes those units too
<pedronis> ah ok
<zyga> ah, it's in proposed
<zyga> dholbach: how does that promote to non-proposed?
<dholbach> I think it's in binary NEW
 * Gunther_ is trying fuffa2defconfig :)
<dholbach> so there's the first gate
<dholbach> so there's the first gate: the review queue of uploaded source packages
<dholbach> then there's built binary packages in a queue
<dpm> jibel, kgunn, ok, the new calculator and clock are now both installable from the store. They should be launchable from command line, the dash and the launcher
<dholbach> both of them are now in place since we're in final freeze and stuff
<beuno> ogra_, can you make sure you requested a manual review for all of them?
<ogra_> phew ... in a few
<dholbach> zyga, pedronis: http://paste.ubuntu.com/15930918/
<sergiusens> ogra_ it has been tested. And in any case, snappy can do the mashing on install if not
<dholbach> zyga, pedronis: (after installing 2.0.2 and running reset-state)
<Gunther_> ppisati: the same as with my kernel
<ogra_> sergiusens, really ? show me the uboot changes then
<dholbach> zyga, pedronis: maybe reboot?
<pedronis> the 2nd thing seems a store isse not sure
<zyga> hmmm
<zyga> store issue
<pedronis> it's not finding ubuntu-core
<ogra_> (and no, chainloading grub is not an option until someone showed me how the DTs get handed over from bootloader to bootloader)
<dholbach> ok
<zyga> dholbach: with 2.0.2 your release will be looking for 16
<zyga> dholbach: I'm not sure if the store was changed yet
<zyga> beuno: ^^
<dholbach> ok...
<dholbach> I guess I'll hang in there then
 * zyga goes to make some snaps for testing
<ogra_> yeah, make some schnaps !
<kgunn> dpm: yep, worked for me no prob
<sergiusens> ogra_ then my if not part of the sentence applies
<ogra_> heh, k
<mvo> dholbach: store needs to be update to use the new "16" series
<dholbach> ok... so I guess I roll back to 2.0.1 then
<ogra_> ppisati, i get the same error here ... werid
<dpm> kgunn, great
<ogra_> i wish i could see all messages ... i guess the error is scrolled off screen
<zyga> dholbach: 2.0.1 has the mount bug, you want 2.0.2 and you want beuno to tweak the store
<dholbach> ok
<beuno> we're updating to 16 today
<ppisati> Gunther_: are you having the same issue?
<Gunther_> ppisati: yes it looks like that
 * zyga hugs sergiusens for "snapcraft help <plugin>"
<ppisati> http://pastebin.ubuntu.com/15931130/
<ppisati> Gunther_: ogra_ ^
<ppisati> this a snapcraft.yaml
<ppisati> for an exact copy of the amd64 that we use in xenial
<ppisati> and it works fine
<ppisati> if you want to try it out
<Gunther_> looks very similar to mine. but ogra_ and I add ahci.ko and libahci.ko to initrd
<ogra_> right, but thats a different issue
<ogra_> i doubt ppisati uses VBox
<ppisati> nope
<Gunther_> you re right
<ppisati> qemu-kvm
<ogra_> the the disk is found too
<ogra_> sigh, how do i get kvm to actually output everything to serial
<ogra_> booting with -nographic doesnt seem to get me the initrd errors
<dholbach> dpm, I'm working on 2048 right now, but unfortunately my snapd state is broken right now (https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175) and the new snapd (2.0.2 from the archive admin queue, which fixes a bunch other issues) depends on a change which is going into the store, so I'm a bit stuck (just a quick summary)
<ubottu> Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New]
<dpm> dholbach, argh, np, thanks for the update
<dholbach> dpm, if your snapd still works, maybe you can try http://paste.ubuntu.com/15931236/?
<dpm> dholbach, cool, thanks
<dholbach> dpm, shall I add it to the snappy-desktop-examples branch already?
<dpm> dholbach, yes please. It will also need the wrapper to set the environment variables, I think.
<dpm> unless it already worked for you without the wrapper?
<dholbach> dpm, ok... I didn't get that far - "qmlscene 2048.qml" locally works
 * dpm tries
<Gunther_> ogra_, ppisati : I try to use the https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/58503/+files/livecd.ubuntu-core.os.snap now and not the os.snap coming from the store
<dholbach> dpm, added to the branch
<dpm> dholbach, argh: http://pastebin.ubuntu.com/15931341/
<dholbach> dpm, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175
<ubottu> Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New]
<dpm> that's a bit of a big blocker :/
<Gunther_> ogra_: it worked!
<ogra_> awesome
<mvo> dholbach, dpm: the store is moving to the new 16 series and we need to reupload our snaps for this, this means for the next couple of hours the 2.0.2 release is a bit bumpy
<zyga> mvo: reupload or republish?
<dpm> mvo, thanks. Do you happen to know if there is a workaround for that "Hold with no error message" bug?
<Gunther_> ppisati: its os.snap. the one downloaded by the snapcraft kernel.plugin is not "current" enough
<ogra_> yeah
<mvo> zyga: I thnk its reupload, beuno will know for sure
<dholbach> dpm, I think 2.0.2 from https://launchpad.net/ubuntu/+source/snapd/2.0.2 helps, but as mvo said that won't work as we're waiting for a store fix to land
<ogra_> let me switch them to manual approval and get beuno to approve them, that should fix you
<mvo> dpm: not right now afaik
 * ogra_ goes on a clicking spree 
<mvo> dholbach: I'm publishing some snaps now (go-example-webserver) may already be available
<ogra_> oh, seems someone approved the ubuntu-core ones without requesting
<ogra_> beuno, http://paste.ubuntu.com/15931482/ ... all in manual queue now
<beuno> ogra_, I did!
<beuno> they were indeed requested, somehow  :)
<ogra_> ah, awesome :)
<beuno> approving the rest
<ogra_> ppisati, so try again ...
<beuno> package contains external symlinks: lib/modules/4.4.0-1004-raspi2/build lint-snap-v2_external_symlinks
<beuno> ogra_, I assume that's expected, yes?
<ogra_> indeed
<ogra_> thats our kernel package
<ppisati> ogra_: a new os.snap has landed?
<ogra_> they all have that danglinmg symlink
<ogra_> ppisati, yes
<ppisati> k, /me tries
<beuno> ogra_, right, so the reason the other ones made it to the queue is because they only triggered the OS flag, which sends it to manual review automatically
<beuno> ogra_, these ones trigger an error due to these symlinks
<ogra_> ah
<ogra_> ubuntu@localhost:~$ sudo snap refresh ubuntu-core
<ogra_> error: can't update "ubuntu-core": cannot find snap "ubuntu-core"
<ogra_> bah !
<beuno> ogra_, you can work with jdstrand maybe to improve the reviewer tools
<beuno> so that doesn't happen
<ogra_> beuno, yeah, kernel snaps should be handled special :)
<ogra_> so how do i get my updated rootfs now
<beuno> we're all special in some way
<ogra_> snap find shows the new one
<ogra_> but snap refresh doesnt
<pedronis> ogra_: in which channel is the new one?
<pedronis> mvo: ^
<ogra_> pedronis, shoudl all be edge
<pedronis> you need to do snap refresh --channel=edge ubuntu-core
<ogra_> the image is built from edge (sideloaded gadget though)
<pedronis> maybe
<pedronis> (default is stable)
<ogra_> ubuntu@localhost:~$ sudo snap refresh --channel=edge ubuntu-core
<ogra_> error: can't update "ubuntu-core": cannot find snap "ubuntu-core"
<ogra_> nope
<pedronis> then don't know
<ogra_> ubuntu@localhost:~$ snap find|grep ^ubuntu-core
<ogra_> ubuntu-core          16.04+20160419.13-38             The ubuntu-core OS snap
<pedronis> mvo: ^ is that a new store issue?  or things aren't published yet in the right places?
<ogra_> ubuntu@localhost:~$ snap list|grep ^ubuntu-core
<ogra_> ubuntu-core         16.04+20160415.05-15             canonical
<ogra_> so list and find know about it
<ogra_> same issue with the kernel snap btw
<ogra_> ubuntu@localhost:~$ snap list|grep ^canonical-pi2-linux
<ogra_> canonical-pi2-linux 4.4.0-1004-raspi2+20160410.15-31 canonical
<ogra_> ubuntu@localhost:~$ snap find|grep ^canonical-pi2-linux
<ogra_> canonical-pi2-linux  4.4.0-1004-raspi2+20160419.13-51 The ubuntu-core kernel snap
<mvo> ogra_: I don't see a 16.04+20160415 in the store yet, let me double check
<ogra_> mvo, i want to upgrade to 16.04+20160419.13-38
<ogra_> 16.04+20160415 is the local version
<ogra_> (this is armhf btw, so the timestamp varies a bit)
<plars> elopio: fgimenez: Hi, any thoughts on the errors I sent you? Are you still hitting those as well?
<ppisati> it's stuck there trying to download ubuntu-core
<mvo> ogra_: so this is store and side load?
<ogra_> mvo, store os and kernel, sideloaded gadget ... from yesterady
 * ogra_ tries the dragonboard instaed ... i think there i dont have any sideloading 
<elopio> ;5~;5~
<ogra_> elopio, !
<ogra_> elopio, "internet by bucket" ?
<ogra_> mvo, same behaviour on dragfonboard without any sideloaded snaps
<ogra_> (so it isnt the sideloading)
<pedronis> ogra_: do you have content in you /snap/ubuntu-core ?
<elopio> ogra_: what's that internet thing you are talking about? In this little town we just share the latest news sundays in the church.
<pedronis> your
<pedronis> IÂ mean the one you are trying to update
<ogra_> ubuntu@localhost:~$ ls /snap/ubuntu-core/
<ogra_> 92  current
<mvo> ogra_: so you have an os snap and you call snap refresh ubuntu-core and it claims it can not find it? is that what you see?
<elopio> plars: sorry, I have crappy connection. Will try to reproduce your problems in the afternoon.
<ogra_> ubuntu@localhost:~$ ls /snap/ubuntu-core/current/
<ogra_> apps  bin  boot  dev  etc  home  lib  media  meta  mnt  opt  proc  root  run  sbin  snap  snaps  srv  sys  tmp  usr  var  writable
<plars> elopio: no problem, I'm not in a rush. Just curious
<ogra_> mvo, right, the same goes for the kernel snap
<ogra_> mvo, but find and list work fine ... seems to be refresh only
<mvo> ogra_: what version of snapd do you see in /usr/share/snappy/dpkg.list?
<ogra_> ubuntu@localhost:~$ grep snapd /usr/share/snappy/dpkg.list
<ogra_> ii  snapd                         1.9.3~ppa65-1                arm64        Tool to interact with Ubuntu Core Snappy.
<ogra_> ii  ubuntu-core-snapd-units       1.9.3~ppa65-1                arm64        Scripts for snapd that should only run on ubuntu core systems.
<ogra_> the image was built yesterday afternoon
<pedronis> ah this is pre 2.0
<ogra_> lates core from the store
<pedronis> so doesn't work with the store anymore
<ogra_> fun
<ogra_> we really need auto-uploads to work :/
<pedronis> it's complicated story
<mvo> ogra_: in rolling?
<mvo> ogra_: eh, edge?
<mvo> ogra_: sorry, stable is super outdated right now
<pedronis> it's the store that stopped working for it to be precise
<mvo> ogra_: I will fix this soon but I had hoped to release stable with a 16 channel
<ogra_> manually uploading all snaps for and image refresh is a job for someone who killed mother and father with an axe
<ogra_> (takes easily 1-2h)
<ogra_> mvo, thats all edge
<mvo> ogra_: tell me about it!
<pedronis> edge but old edge
<pedronis> no edge
<ogra_> i havent used stable in 6 months or so
<mvo> ogra_: uh, then its matter of reuploading to edge, *sigh* amd64 is up-to-date
<mvo> ogra_: I thought I did update today all ubuntu-core snaps in edge
<ogra_> mvo, you mean beaond what i uploaded qh ago ?
<ogra_> *1h
<mvo> ogra_: maybe I was dreaming :/ or your image is build this monring before I did that
<pedronis> mvo: yes, but they cannot be updated
<pedronis> because remember the store changed and they can't find things there
<mvo> pedronis: yes
<mvo> ogra_: oh, you did not do a reflash?
<pedronis> well he has 1.9 for snapd
<mvo> pedronis: sorry, misunderstood, I assumed he did a reflash not just an update
<pedronis> that doesn't sound reflashed
<mvo> ogra_: sorry, please reflash
<ogra_> mvo, no, i did an image re-build and uploaded all snaps to the store about 1h ago ... about 30min ago beuno released all of them
<ogra_> the image is from yesterday
<mvo> ogra_: and you got version 1.9.x, let me check the build logs
<pedronis> ppa vs archive?
<pedronis> we didn't udpate the ppa in a while?
<mvo> ogra_: right, the image needs to be rebuild
<ogra_> task header ?
<mvo> pedronis: I did update the ppa today
<mvo> ogra_: hmmm
<ogra_> the rootfs build alwaqys prerfers the archive if you dont have the task header
<mvo> ogra_: build log for armhf shows 2.0.2+ppa70-1
<mvo> same on arm64
<ogra_> mvo, yes, for todays build ...
<ogra_> my image is yesterdays
<mvo> ogra_: thats too old, sorry
<mvo> ogra_: you need to rebuild the image with todays snaps for this to work
<ogra_> well, fine then ... but we need some auto-upload going ...
<mvo> ogra_: updates from yesterday to today won't work, its complicated (like pedronis said) and has to do with store interaction
 * ogra_ ponders to simply route it through a local PC for now 
<dpm> popey, for ffmpeg in snappy-playpen, are all the files around snapcraft.yaml needed for the build? If I understand it correctly, we need the *.launcher files, but the clean_build and rebuild files are just convenience scripts to run manually to make packaging easier, right?
<popey> dpm: convenience
<popey> probably don't need any of the launchers, as it looks like snapcraft makes a binary for the app name automatically
<popey> dpm: I'd just grab the 'part' for ffmpeg
<ogra_> jdstrand, tyhicks, FYI i unseeded tpm-tools today (since the MIR is unlikely to get through due to opencryptoki) http://people.canonical.com/~ogra/core-image-stats/20160419.4.changes
<ogra_> ricmm, ^^^
<elopio> kyrofa: sergiusens: how do we deal with projects that are in sourceforge?
<dpm> zyga, still around?
<ogra_> mvo, where does that stuff come from ? http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/
<mvo> ogra_: I don't know, I would assume its a snapshot of my all-snaps page
<ogra_> hwo can that happen if not you or me put it there ?
<ogra_> having random images show up at a semi-official place without you or me knowing isnt actually great
<dpm> popey, btw, adding the ffmpeg part to the youtube-dl snap worked great to overcome the initial bug :). Now I'm looking at another part that's not quite working yet.
<ogra_> slangasek, i assume you dont know either how the images at http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ got there ?
<popey> dpm: yay!
<dpm> :)
<jamiebennett> ogra_, mvo, would be nice to sort this out
<slangasek> ogra_: I put them there
<slangasek> ogra_: by taking a snapshot of the people.c.c stuff that we were pointed to, yes
<slangasek> more permanent solution still in progress
<ogra_> slangasek, well, they are not actually usable :)
<slangasek> ogra_, mvo: one snag I became aware of in talking with infinity, seems that the udf needed for these builds is not in the archive? why not?
<ogra_> nor upgradeable
<slangasek> ogra_: well, they are what I was pointed at when we discussed one-off publishing of snappy images and no one had rescinded that order.  I can certainly take them down again if that's the right answer
<slangasek> or does someone have one I can replace them with that is upgradeable?
<ogra_> slangasek, seems that someone wants to completely re-define gadget and kernel before we release images ... so that udf would be broken again in the archive
<ogra_> slangasek, i usually ask people to build their own image nowadays ... and i think mvo also wiped them from the people.c.c page because they were always behind
<ogra_> now with the last snapd and store changes they wont be upgradeable at all
<ogra_> and these changes are still not final
<dpm> niemeyer, I'm not sure I'm interpreting the output of 'snap interfaces' correctly. Does this mean that L19 is not connected? -> http://pastebin.ubuntu.com/15934268/
<slangasek> ogra_: ok; so you understand that we've been asked to publish pre-built images to cdimage.u.c ASAP?
<ogra_> slangasek, we shoudl simply not release images yet ... they arent ready and might still change in incompatible ways ... especially if kernel and gadget get changed massively again
<slangasek> and are not being given the tools to do so
<ogra_> slangasek, well, not my decision ...
 * ogra_ was in fact asking for u-d-f in the archive for the last few months ... but the prob is really that the format changes all the time .... 
<ogra_> *especially* with the nearly-rewrite that snappy has seen in the last weeks for desktop inclusion
<slangasek> ogra_: well, I would appreciate some consistency here; either we're "not ready" to publish images and Foundations should deprioritize this, or it's important to publish them and so the tools should be in place to support this
<ogra_> slangasek, afaik snappy release date is some time in july ...
<ogra_> and i'd say we're not ready currently ... with luck we can have an alpha state image by end of the week
<slangasek> and so we'll have a working udf in the archive by...?
<ogra_> probably mvo or niemeyer want to chime in here
<kyrofa> elopio, sorry I was grabbing lunch
<ogra_> since all relevant discussions happen in telegram where i'm not part of
<ogra_> slangasek, by SRU (i guess) :)
<kyrofa> elopio, however, I don't quite understand the question. How do we deal with them? Are they special in some way?
<slangasek> ogra_: I meant "by" as in "by what date"
<ogra_> yes, i know ... cant tell you
<ogra_> mvo ^^
<niemeyer> dpm: Yes, that means it was disconnected at that time
<niemeyer> slangasek: We believe we'll have working images by tomorrow
<slangasek> niemeyer: what does that mean exactly?  you'll be building the images locally and we should do a one-off copy again to cdimage.u.c?
<dpm> niemeyer, thanks. So that seems to confirm that the home interface is not autoconnected, if I understand it correctly. After manually running 'sudo snap connect youtube-dl:home ubuntu-core:home' it all seems to work
<ogra_> slangasek, btw, we have a release process that images need to go through, documented in a trello board ... that includes the minimal amount of QA
<niemeyer> slangasek: Sorry, I actually meant we'll have Snappy code capable of being run in an image built by udf tomorrow
<ogra_> https://trello.com/c/PUpWXouz/89-stable-release-checkpoints
<niemeyer> dpm: Sweet!
<slangasek> niemeyer: ok; AIUI that still doesn't give me a udf in xenial that I can use for official image mastering
<ogra_> niemeyer, the question was if we can get the u-d-f that produces usable images in the archive
<ogra_> since the server that builds them will most likely use the archive to obtain all build tools
<ogra_> slangasek, the prob with udf is that it also needs to be tied to http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ and to the store itself
<ogra_> the build setu we need is pretty complex
<ogra_> (cdimage produces the snaps ... the snaps need to go to the edge channel in the store, need to get approved and only then u-d-f can kick in and create images)
<slangasek> niemeyer: and I guess ogra_ is raising concerns about the images currently published to http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ , which we've published there by request of olli/dholbach because not having images in an official location was blocking updating of the documentation for 16.04; so it's not clear to me if we need to be removing the images currently there or if we should just
<slangasek> leave them alone and replace them with tomorrow's images once available / QAed
<ogra_> there are multiple infrastructure parties involved
<ogra_> slangasek, well, did any docs get updated to point to them ?
<slangasek> ogra_: I am aware of the overall architecture, I am only asking for udf in xenial
<ogra_> if not we can leave them there ...
<slangasek> ogra_: and if the docs *did* get updated you would instead pull them and leave dangling doc links?
<ogra_> if there are actually docs pointing to them they should warn that the majority of stuff doesnt work and that they are not upgradeable
<ogra_> or we should wipe them for now
<ogra_> neither is a good way ...
<niemeyer> slangasek: are these snappy 2.0 images, 16.04, or something in between?
<ogra_> niemeyer, 1.9
<niemeyer> If it's something in between, I think we should remove them
<ogra_> 16.04
<ogra_> from beginning of the month
<niemeyer> Yeah, that sounds like more pain than gain
<ogra_> they wont be upgradeable and only have half of the interfaces implementation
<niemeyer> I'd remove and ship new ones with 2.0 tomorrow
<ogra_> if they pass QA :)
<niemeyer> Yep
 * ogra_ was aiming for friday ... then the worst release stuff is over and people have a brain agaiin 
<ogra_> for alpha quality images that is
<ogra_> and i think mvo was on the same page
<dpm> davidcalle, youtube-dl example working
<mvo> yeah, image with snapd 2.0 this week, my goal was actually today and we almost made it
<mvo> then came the store change to 16
<ogra_> and vritualbox explosions :)
<mvo> beuno: no pressure but in order for snap 2.0.2 with the series=16 change we need a working autopkg test which means we need a working 16 series because the autopkgtest tries to install stuff from 16 :/
<ogra_> mvo, slangasek's main point is u-d-f though
<ogra_> mvo, whatever will build future images will have to pull u-d-f from the archive
<mvo> ogra_: we have that only in a ppa currently :/
<ogra_> which means we need some working version landed before release
<mvo> beuno: I think we will need ubuntu-core and hello-world in there
<mvo> ogra_: in the archive?
<slangasek> mvo: what blocks uploading it to the archive?
<ogra_> mvo, why are we holding back (apart from expected changes) it snt like udf for core is in any way usable in the archive right now
<ogra_> 15.04 will soon be deprecated and for 16.04 the archive u-d-f would actually try to use system-image
<ogra_> just upload the PPA one so we at least have a semi working snapshot ...
 * ogra_ can do that if you fear TIL :)
<ogra_> slangasek, another thing ... due to bug hunting i didnt manage to write my MIRs, is there still time ( i dropped tpm-tools from the image but still need libnss-extrausers, watchdog and ubuntu-core-libs in main) ?
<slangasek> ogra_: whether there's time or not, please work on these so we can have sane archive state for release
 * ogra_ will write them today before EOD 
<ogra_> yeah, understood
<beuno> nessita, ^^^^^
<beuno> (otp)
<ogra_> i guess worst case we can also drop watchdog ... extrausers is kind of essential though
<nessita> beuno, ogra_, a little lost from the backlog, how can I help?
<ogra_> nessita, mvo> beuno: no pressure but in order for snap 2.0.2 with the series=16 change we need a working autopkg test which means we need a working 16 series because the autopkgtest tries to install stuff from 16 :/
<ogra_> nessita, <mvo> beuno: I think we will need ubuntu-core and hello-world in there
<nessita> ogra_, beuno, mvo I know, I'm on this since this morning, but still not available, working actively in this
<mvo> nessita: yeah, sorry for rushing this all
<mvo> slangasek: we expect changes to the kernel and gadget snap definitions so a u-d-f that is uploaded today is probably not the final result. I don't know the details or scope of the changes, just that its unlikely that the archive u-d-f would be able to create images for snappy core 16 devices.
<mvo> ogra_: see above, we have a u-d-f branch that can create images today, however the format of the kernel/gadget is not finalized
<ogra_> mvo, i know that :)
<ogra_> but the diff we need to SRU will at least be smaller and whoever works on the image generation in foundations can move on
<ogra_> (i didnt even know someone in foundations does :P )
<sergiusens> kyrofa hey your autopackage tests failed
<kyrofa> sergiusens, hrmm
<kyrofa> sergiusens, OSError: [Errno 5] Input/output error
<kyrofa> sergiusens, running them again
<sergiusens> mvo niemeyer ogra_ slangasek I am not super happy about publishing images AT all fwiw; the work that is going to happen later with gadget and kernel will probably break these same images. I publish them only once the final sutff is done and dust has settled
<ogra_> slangasek, fully with you here :)
<sergiusens> unless we can guarantee an upgrade path, I would really deprioritize
<ogra_> (that is why i brought it up in the first place)
<niemeyer_> sergiusens: Why will it break these images?
<ogra_> sergiusens, yeah, how would we guarantee that if we dont even know how the changes will look like
<ogra_> niemeyer_, the point is that we dont know if we will have any upgrade path from todays kernel/gadget at all yet
<slangasek> sergiusens: this is essentially an argument for not documenting 16.04 at all until later because you don't want people to use it.  That's not my call, just want to be clear about the implications
<ogra_> its isnt that we know it will break ... bt it is very likely
<niemeyer_> ogra_, sergiusens: We can name the snaps as legacy-kernel and legacy-gadget
<niemeyer_> We don't need to break the images, strictly speaking
<ogra_> niemeyer_, how does that help me to upgrade an image i install today (to use in production asap)
<ogra_> (i mean how does the renaming help)
<niemeyer_> ogra_: It helps because we can keep the old using the old
<ogra_> niemeyer_, and maintain two snaps per gadget/kernel ?
<ogra_> note that releasing a single image is over 1h of work with manual uploads and manual approval in the store today
<niemeyer_> ogra_: No.. and to be honest the goal wasn't to provide long term support for these initial images
<ogra_> right
<niemeyer_> ogra_: But rather to allow people to start playing
<pedronis> also these wouldn't be meant for production either way, they are more to start getting used to the other aspects of snappy that won't change as much
<ogra_> so we shouldnt have them at all
<niemeyer_> So what is best?
<ogra_> until we can provide an upgrade path
<ogra_> if people want images they should use u-d-f and roll their own for playing
<niemeyer_> That seems a bit harsh..
<niemeyer_> We can simply label the images as preview, and implement a mechanism that tells them when they cannot update
<ogra_> better than giving them broken stuff they can not upgrade
<ogra_> "implement a mechanism"
<niemeyer_> ogra_: Better for whom?
<ogra_> do we have time for that ?
<niemeyer_> ogra_: LOL
<ogra_> :)
<niemeyer_> ogra_: Have you seen the last two weeks?
<ogra_> yes
<ogra_> i suffered too :)
<ogra_> if i build an image using u-d-f i'll likely talk to someone before ... who tzhen tells me it will be an interim image that i can not upgrade ...
<niemeyer_> ogra_: That's not the point.. pedronis or mvo could likely implement something like that while they're having an icecream on the other hand
<niemeyer_> We just need to understand what we want
<ogra_> if i download some image from cdimage that some G+ post pointed to i wont know that
<ogra_> niemeyer_, videos or it didnt happen :P
<niemeyer_> ogra_: The fact it's labeled as "preview" tells you
<ogra_> niemeyer_, http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/
<niemeyer_> ogra_: Seriously.. I just got errors on my 16.04 upgade. Let's not pretend everything needs to be perfect or we don't ship
<ogra_> currently nothing tells me
<ogra_> but indeed we could add rthat there
<ogra_> niemeyer_, you got errors ... i only get "snap not found" for any snap i try to upgrade on an image i freshly built yesterday
<niemeyer_> The goal here is to unblock people to experiment, even if they're explicitly told the image may need reflashing once it's final
<ogra_> and i was told it wont work anyway, i need to re-do the image and re-flash
<ogra_> had i actually done any work on these images i would perhaps been pissed off now (as an enduser)
<niemeyer_> ogra_: Yep, that's part of the fun of being involved on a fast moving project
<ogra_> if we release anything this week it clearly needs to be marked alpha or pre-alpha
<ogra_> niemeyer_, sure, and i personally dont mind ... but users will
<mvo> labeling it alpha is fine and I think we need to have something for people to play with
<niemeyer_> ogra_: That's one of the reasons why we don't have an image out yet.. the image you built and got snap not found was built locally, with your own udf, right?
<niemeyer_> ogra_: We want to build an image that sort of works for people to experiment with, even if we need to cook a mechanism that will blacklist it against updates when we choose to
<ogra_> niemeyer_, with the most official u-d-f ... the point is that the store changed and that the snaps in the sotre werev weeks outdated because it is a pain to release an image (as i said, took me over 1h to even upload all bits manually today)
<niemeyer_> ogra_: Oliver, you should see when they broke the API last week, just while the integration test servers stopped responding..
<ogra_> niemeyer_, so lest do an alpha image by end of the week (have something ready tomorrow to give it to QA)
<ogra_> and very very clearly promote it as alpha everywhere
<niemeyer_> ogra_: We have the same goal.. working and stable software. Take a deep breath and please give us a hand getting there.
<niemeyer_> ogra_: Not releasing anything is not helpful towards that.
<ogra_> do i get across liek i need a deep breath ?
<ogra_> :)
<niemeyer_> ogra_: I heard you.. tomorrow will meet with mvo so we figure which caveats we want in place.
 * ogra_ is totally calm :) 
<ogra_> i just want to get this sorted ... and in a way that fits us all ...
<niemeyer_> ogra_: Yep, we'll get it sorted, and will have images for people to play with. They will be experimental, and that's okay.
<ogra_> niemeyer_, one point is that whatever will finally do the image build in the infrastructure willl need to pull the build tool from the archive
<ogra_> niemeyer_, so we need to get u-d-f in ... even if it isnt finished that will at least create a smaller SRU diff
<niemeyer_> ogra_: Tomorrow, with more time and out of mvo's evening, I will meet with him and discuss how to get experimental images in place.
<ogra_> niemeyer_, and we also need to check the communication breakdown we had with http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ ... but thats something for the monday meeting
<ogra_> niemeyer_, sure
 * ogra_ has been discussion with mvo all wee on that topic :) all this just got triggered by images showing up on cdimage out of the blue and nobody knowing why :) 
<ogra_> *discussing
<niemeyer_> ogra_: Yep, I know, and your input is appreciated.
<ogra_> :)
<niemeyer_> and sergiusens's
<niemeyer_> ogra_: We'll be more careful as a side effect.
<niemeyer_> ogra_, sergiusens: For the record, we already have a mechanism in place, today, that enables us to ship snaps that will refuse to work on an old revision of ubuntu-core.
<niemeyer_> Forcing ubuntu-core itself to be updated first
<ogra_> niemeyer_, well, but thats indeed requires ubuntu-core to be upgradeable :)
<ogra_> which is todays issue
<niemeyer_> ogra_: and it isn't!?
<ogra_> (or was ... tomorrows images will now work)
<ogra_> niemeyer_, not when buuilding from yesterdays snaps in the store
<ogra_> i pushed a complete set of snaps today ... so now that should work
<niemeyer_> ogra_: Because we decided to change the series while coordinating the store team, the 16.04 release team, and the snappy core team..?
<niemeyer_> ogra_: This wasn't made out of the blue..?
<ogra_> right ... so snap list and snap find show you upgardeable snaps but snap refresh ends up with "no snaps foound"
<niemeyer_> ogra_: So if you say "snap refresh ubuntu-core" on the snapd that is being shipped with 16.04, what happens?
<ogra_> niemeyer_, well, nothing of that seemed to be known by anyone when i first asked about the "no snaps found" issue here
<ogra_> niemeyer_, you mean on a desktop ?
<ogra_> lets see ... i havent upgraded my desktop in a few days now ...
<ogra_> ogra@styx:~/all-snaps$ sudo snap refresh ubuntu-core
<ogra_> [sudo] Passwort fÃ¼r ogra:
<ogra_> error: can't refresh "ubuntu-core": snap "ubuntu-core" has changes in progress
<ogra_> ogra@styx:~/all-snaps$
<niemeyer_> ogra_: I mean on the 16.04 image that is being released tomorrow.. or the equivalent snapd 2.0.2 that is being shipped with it
<ogra_> thats what i get on my system that i upgraded to 16.04 on sat.
<niemeyer_> ogra_: That won't work.. you need to start with 2.0.2
<niemeyer_> ogra_: Or clean your old state
<ogra_> niemeyer_, i have to fill some MIRs first, but i can test an image later ... seemingly there are more store changes needed according to the backlog
<ogra_> (which will also require a complete re-upload of all snaps we use )
<niemeyer_> ogra_: Possibly, but the point is that there's no reason why refreshing ubuntu-core would not work work
<ogra_> well, i need to build a complete image ... that takes time i dont have atm ... the one i run from yeterday isnt upgardeable
<ogra_> (simply because ubuntu-core in the store had 1.9.x in it til today)
<sergiusens> niemeyer ogra_ I'm ok with an image released as long as there is some upgrade path or some way to get the latest kernel and gadget snaps in the future. Also marking it as not production ready somewhere so people trying it are crystal clear on what they are getting into
 * sergiusens dropped a bombed 30 minutes ago and left for lunch
<sergiusens> I won't do that next time :-)
<ogra_> heh
<ogra_> do what you need ... thats the baeuty of IRC ... it is asycnronous :)
<niemeyer_> sergiusens: There may not be an upgrade path.. we can look into that, but we won't stop releasing an experimental image for people to try it out just because we may have to ask them to reflash.
<ogra_> *beauty
<niemeyer_> Yeah, and the other beauty is that you may just loggout so you can claim you didn't read the log
<ogra_> i dont think the point is releasing experimental ones ... but releasing experimental ones under an official release url
<ogra_> which we did
<niemeyer_> Sure, too bad.. let's take it down as they shouldn't be there.. no sweat
<ogra_> exactly
<niemeyer_> Let's then cook something we're happy with, label it as experimental, and do put it there because we want people to try it out
<sergiusens> niemeyer_ oh, I don't mind reflashing; I just want people using it to know before hand :-)
<niemeyer_> Of course
<ogra_> +1
<niemeyer_> "preview"
<sergiusens> niemeyer_ ogra_ wrt logs and irc; I can also claim a network error and since you get no ack can't prove I read it or not :-P
 * sergiusens knows how to play dumb ;-)
<ogra_> niemeyer_, the prob is now that the released images were put into place because someone (dholbach) updated or wanted to update the docs to point to them
<niemeyer_> All good.. we'll get that fixed..
<ogra_> i dont know if any docs were changed ... so i dont feel comfortable to just wipe the dir on cdimage
<niemeyer_> ogra_: Just wipe it.. it's better than having people using something bad
<ogra_> ok
<niemeyer_> ogra_: We can then catch up with Daniel to fix doc, and politely respond to any reports
<ogra_> yeah, and we need to talk to olli to actually coordinate such stuff instead of pinging slangasek directly :)
<ogra_> but as i said, thats something for monday
<niemeyer_> ogra_: .. and finally re-release the image we do want and understand the caveats, and release docs with it mentioning those caveats
<niemeyer_> Yep
<ogra_> yup
<niemeyer_> Anyway, need to step out..
<niemeyer_> talk soon
<ogra_> slangasek, FYI i wiped the subdirs under http://cdimage.ubuntu.com/ubuntu-snappy/daily/ now
<zyga> dpm: re
<ogra_> til we have some usanble image
<ogra_> *usable
<dpm> zyga, all sorted now, thanks :) I just wanted to confirm that a) the 'home' interface is not autoconnected (it's not) and b) how to manually connect it (done it now)
<zyga> :D
<dpm> :)
<zyga> dpm: cool, both confirmed :)
<zyga> dpm: what did you make that requires home?
<dpm> zyga, http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/youtube-dl/
<dpm> oh, I haven't pushed yet, just a sec
<dpm> zyga, ok, the branch should now be up-to-date
<dpm> davidcalle, ^^
<zyga> nice!
<zyga> I hope that over time we can create more fine-tuned interfaces
<zyga> specifically those that give a slice of home
<zyga> e.g. home with some attributes that specify, e.g. the XDG music directory for media player
<popey> sergiusens: do you know how my desktop app snapped can use/see /var/cache/fontconfig and udev stuff (for access to enumerate input devices)?
<zyga> popey: which udev stuff?
<zyga> popey: the answer is *interfaces*
<popey> zyga: http://paste.ubuntu.com/15936638/
<zyga> popey: use unity7 to get /var/cache/fontconfig
<popey> i have specified unity7
<zyga> #include <abstractions/fonts>
<zyga> /var/cache/fontconfig/   r,
<zyga> /var/cache/fontconfig/** mr,
<popey> http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/view/head:/mame/mamedeb/snapcraft.yaml
<zyga> that's unity7, you can confirm you have that by looking at /var/lib/snapd/apparmor/profiles/snap.mame.run
<zyga> popey: FYI I'd suggest naming the main app in a snap after the snap
<zyga> popey: then the executable on path is a nice short "mame", not "mame.run"
<sergiusens> zyga popey you have to maybe get the difference between Ubuntu and Ubuntu Core
<zyga> popey: why does mame want to chmod [180438.835798] audit: type=1400 audit(1461075883.106:144): apparmor="DENIED" operation="chmod" profile="snap.mame.run" name="/var/cache/fontconfig/" pid=2174 comm="mame" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
<sergiusens> is /var/cache/fontconfig/ Ubuntu's or Ubuntu Core's?
<zyga> sergiusens: there is no difference
<ogra_> zyga, doesnt that then come out as mame.mame (it used to in the past)
<sergiusens> zyga really?
<zyga> ogra_: no, now that will be just "mame"
<ogra_> yay
<popey> ok, will simplify that
<zyga> sergiusens: interfaces work the same way everywhere
<ogra_> since when is that ?
<popey> one thing at a time :)
<zyga> ogra_: we talked about it half a year ago, it happened like 6 weeks ago
<ogra_> cool
<zyga> popey: you know about --devmode, right?
<zyga> ogra_: yes, it gives apps a nice CLI UX
 * ogra_ is still waiting for snap config to re-appear ... sadly my snaps are useless without it 
<ogra_> so i didnt touch snaps in recent times
<popey> zyga: no
<zyga> popey: remove your snap and install with --devmode
<sergiusens> zyga try and snap a gtk app then come back ;-)
<zyga> ogra_: config is coming back soon, muuuch better
<ogra_> as long as i can port my stuff :)
 * ogra_ liked the old implementation actually :) 
<zyga> sergiusens: what do you mean?
<zyga> sergiusens: I miss pulseaudio interface, I'll add one locally for games
<zyga> ogra_: it will be easier on snaps to handle
<ogra_> well, i handle it through shell scripts ... as long as i can go on doing that i'm fine
<zyga> ogra_: it will be _far_ easier to handle, especially in shell scripts
<ogra_> (read: please keep it flexible on the programmers side)
<qengho> ogra_: "activate" too!
<popey> zyga: what does devmode do?
<ogra_> it calls a developer ...
<ogra_> :)
<qengho> Makes apparmor warn instead of block. Probably something with seccomp too.
<ogra_> (listen for your doorbell)
<popey> hm, still barfs
<popey> FATALERROR: Unable to load opengl library: <default>
<popey> http://paste.ubuntu.com/15936814/ http://paste.ubuntu.com/15936827/
<qengho> Are there any interface docs? I don't understand them yet.
<ogra_> qengho, we need to attach a printer to zyga's brain
<zyga> popey: installs the snap with non-enforcing confinement for figuring out missing interfaces
<zyga> qengho: I'm wrinting one now
<zyga> qengho: the first will go live todayt
<zyga> popey: did you use the opengl interface?
<popey> zyga:     plugs: [network, network-bind, unity7, opengl]
<popey> like that?
<zyga> popey: yep
<popey> yes then :)
<zyga> popey: does mame need network?
<popey> no
<zyga> popey: does it work in devmode? (I assume it doesn't)
<zyga> popey: with devmode you have no security blockers
<popey> no
<zyga> popey: if it doesn't work it's broken in some other way
<popey> yeah, the opengl thing looks to be the main issue now
<zyga> popey: before you report it, which gpu do you have?
<popey> intel
<nessita> ogra_, release 16 is ready in the store
<sergiusens> elopio this is what you want https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/internal/meta.py#L215
<elopio> kyrofa: pexepect.expect takes a pattern
<elopio> sergiusens: thank you
<kyrofa> elopio, yeah and it seems strings get turned into regex as well-- works great, thanks :)
<zyga> popey: does mame work on your desktop normally?
<zyga> popey: as a last hint, add a 2nd app (mame.sh) that runs /bin/sh and see how the libs you get in the snap differ from what you get on the outside
<kyrofa> sergiusens, elopio you guys should give the colors a run on an example to make sure you like them-- several to choose from
<elopio> dpm: can you give me a link to your qt calculator snap?
<dpm> elopio, https://launchpad.net/~dpm/+snap/ubuntu-calculator-app
<elopio> dpm: ty
<popey> zyga: yes, mame works normally
<popey> zyga: in fact if I manually run the executable exactly from the snap, but not via the snap ubuntu app launcher, it works
<popey> it's only when launched via the snap ubuntu app launcher it fails
<qengho> popey: I get that too.
<zyga> popey: does it really fail because of the app launcher? there's also the extra environment
<zyga> popey: (which changes path resolution and libraies)
<niemeyer_> popey: Do we have a mame snap working confined already?
<niemeyer_> popey: (sorry, didn't track the conversation)
<popey> niemeyer_: that's what I'm working on
<niemeyer_> popey: Sweet
<popey> zyga: well, without the snap environment it works
<zyga> popey: right, I'm sorry, I'm trying to figure out what makes it not work
<qengho> Has anyone hit a limit on number of loop devices yet?
<popey> heheh, I wondered when someone would ask that qengho :)
<zyga> qengho: hmm, no?
<zyga> qengho: when doing what?
<qengho> zyga: Adding packages. Last I recall, the default limit is something like 2**8. If I have 50 packages, I think a few months of version churn should hit that limit.
<zyga> qengho: snap recycles
<zyga> qengho: when you sideload that doesn't perhaps happen but store installs/refreshes will recycle
<zyga> qengho: so you shound't hit the limt
 * popey makes a note of this day
<qengho> Oh good.
<qengho> I think the limit is pretty arbitrary so the snapd package could change it.
<popey> zyga: https://www.youtube.com/watch?v=xqIu4gJa1jA showing where I am
<popey> sorry the bit that shows what happens is at ~1m10s in
<zyga> popey: interesting
<zyga> popey: I don't understand that apparmor denial at the end
<zyga> popey: is that with or without --devmode?
<popey> with
<zyga> hmm
<zyga> something for us to investigate
<zyga> right now I have no idea
<popey> seems to be the opengl thing
<zyga> popey: yes but the denial should not be there in the first place
<zyga> popey: how big is your snap?
<popey> -rw-r--r-- 1 alan alan  47M Apr 19 20:35 mame_0.160_amd64.snap
<zyga> popey: I'll check that out tomorrow
<zyga> popey: I'll finish writin an article and EOD
<popey> kk thanks for the help zyga
<kyrofa> Alright sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/474 is green
<kyrofa> Have you guys played with it at all?
<sergiusens> kyrofa I have
<sergiusens> kyrofa in some future a --no-colors or --no-colours option would be good
<sergiusens> kyrofa elopio also https://github.com/ubuntu-core/snapcraft/pull/475
<kyrofa> sergiusens, easy to add
<sergiusens> kyrofa the debate is on how to write colour ;-)
<kyrofa> sergiusens, or support both :P
<qengho> sergiusens:  ... |cat
<mvo> ogra_: new u-d-f uploaded, new 16 series is there, I push a new amd64 image now and will continue with the other arches tomorrow but it looks very promising (fingers crossed and all that)
<mvo> ogra_: http://people.canonical.com/~mvo/all-snaps/ has new amd64 image and new u-d-f if anyone wants to give it a go
<mvo> latest snappy, using the new 16 series in the store
<zyga> qengho: hey
<zyga> qengho: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<sergiusens> elopio kyrofa from what I read somewhere else matiasb seems to be hinting we will need macaroon support to upload/register using snapcraft; we should take a minute or two to analyze vila's PR tonight if possible
<sergiusens> nessita hey, a little bird told me you can migrate packages to 16; would you mind migrating `shout`?
<sergiusens> ubottu hey
#snappy 2016-04-20
<nessita> sergiusens, hi! I can not migrate, but you can just register the name for the series 16 do a new upload (you can use an existing binary)
<netpheak> morning, guys!
<mvo> ogra_: I updated everything for new images, but my rip2 image does not boot, I wonder if there is some kernel issue maybe? not output after Starting kernel ...
<mvo> ogra_: image created with the latest u-d-f from people.c.c:~/mvo/all-snaps
<davidcalle> Morning o/
<davidcalle> I'm getting "error: can't remove "foo": snap "foo" has changes in progress" for any refresh/remove action. What's going on under the hood? Is there a way to check the status of these "changes"?
<nhaines> davidcalle: morning!
<mvo> davidcalle: try "snap changes"
<mvo> davidcalle: and good morning to you as well!
<davidcalle> mvo: hah, thanks, I missed this one in the help :)
<jibel> morning
<jibel> mvo, snapd 2.0.2 should have fixed the "snaps vanish on reboot" on desktop?
<mvo> jibel: yes, only for new installs though, snaps installed with pre 2.0.2 are still affected, it does not "repair" those
<mvo> ogra_: I also pushed http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz now would be nice if you could verify it (my dragonboard appears to be broken :/
<mvo> (or anyone else with a dragonboard)
<jibel> mvo, all right. I'll reinstall and try again. thanks
<kalikiana> How come this snap https://uappexplorer.com/app/nethack-amd64.ogra cannot be found via "snap find nethack" on Xenial and "sudo snap install nethack-amd64.ogra_0.1.0_amd64.snap" says "error: change finished in status "Hold" with no error message"? The error doesn't tell me what's wrong.
<mvo> jibel: thanks
<davidcalle> mvo: another quick question, can't install webdm, can't remove it: http://paste.ubuntu.com/15942446/ (bonus question: when installed, how do you start it? I used to do snappy service)
<mvo> davidcalle: that sounds like webdm got installed with snappy <2.0.2 :/
<mvo> davidcalle: sudo systemctl start snap-<tab> hopefully gives you the mount unit
<mvo> davidcalle: once you started the mount unit manually you can remove and reinstall it (make sure you have snapd 2.0.2 installed when you do that)
<mvo> davidcalle: the <tab> should give you a list of completions hopefulyl and one of them should be webdm
<davidcalle> mvo: it worked, thanks. I also see a few snappy-* services, leftover cruft? (autopilot.timer, autopilot.service, webdm.snappyd.service, workaround-apparmor.service)
<dholbach> kalikiana, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572175
<ubottu> Launchpad bug 1572175 in snapd (Ubuntu) "change finished in status "Hold" with no error message" [Undecided,New]
<mvo> davidcalle: it sounds like it, yes
<davidcalle> mvo: alright, thanks
<kalikiana> dholbach: Thanks
<zyga> good morning
<jibel> dholbach, I cannot find the ubuntu-{clock,calculator} in the store. anything changed?
<jibel> they were here yesterday
<dholbach> jibel, that has to do with version 16
<zyga> jibel: yes, the store was moved, there's a new series (16) and snaps need to be uploaded there (remember to register the name first)
<dholbach> series, sorry
<dholbach> I sent dpm a mail about it
<dholbach> jibel, if you want to test locally, maybe build it from lp:snappy-desktop-examples for now (just run snapcraft)
<jibel> zyga, dholbach thanks. I'lll build a snap or 2 and wait until they're uploaded
<pjoe> is there a release schedule for next version of snappy ubuntu core? .. what is the target for 16.04?
<zyga> pjoe: we will do SRUs regularly to fix issues and add new relevant features
<zyga> pjoe: (especially new interfaces :-)
<pjoe> ok, but there will be a 'stable' 16.04 sometime soon?
 * pjoe is still quite new to snappy, so have tons of questions :)
<pjoe> I've been testing with 15.04 .. but found that bridge-utils are missing so I can't properly setup the network configuration with bridges into lxd containers
<pjoe> however on rolling 16.04 the lxd snap is missing :(
<pjoe> also how would I go about to getting a kernel module patch in to my snappy install
<pjoe> could that be done in an oem-gadget?
<jibel> willcooke, when I click on a snap in nautilus should it open gnome-software?
<willcooke> jibel, it should but it doesn't.  Known bug
<jibel> k
<jibel> willcooke, bug # please?
<jibel> willcooke, is there another way to install a local snap with gnome-sfotware?
<willcooke> jibel, nope
<willcooke> jibel, https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1570182
<ubottu> Launchpad bug 1570182 in gnome-software (Ubuntu) "Support sideloading snap packages" [Medium,Triaged]
<jibel> thanks
<willcooke> nw
 * pjoe reading trhough the porting guide
<dpm> morning mvo! Quick question: I noticed you uploaded ubuntu-clock-app-mvo to the store - was that for testing purposes or do I need to change anything in ubuntu-clock-app?
<dholbach> dpm, the former
<dpm> thanks dholbach :)
<dholbach> dpm, see my mail from this morning on how to do a new upload
<dholbach> dpm, it'll be required to get clock/calc working on series 16
<dpm> dholbach, yeah, I saw it. I'm packaging calendar now to see the process from the start and see what needs to be changed in the documentation
<dholbach> cool
<dpm> dholbach, thanks for testing it and the summary!
<dholbach> anytime
 * pjoe scratches head ... ahs partition layout changed? ... the 16.04 i tried only has system-boot and writable .. no system-a/b
<zyga> pjoe: yes
<pjoe> is the new layout documented somewhere?
<zyga> pjoe: everything is different, we now mount snaps directly from squashfs
<zyga> pjoe: maybe :)
<pjoe> :)
 * pjoe still trying to get my head wrapped around all this
<pjoe> any pointers for how I would get a patched kernel module into my install?
<pjoe> we have this hw watchdog that isn't supported out of the box in the kernel driver
<pjoe> only a few lines of change in driver code ... but need to figure out how to get it in
<ogra_> mvo, try the rpi on a monitor ... the serial being broken with the shared uboot is known ...
<pmp> ogra_: oh, are there any news concerning rpi2?
<pmp> ogra_: is the os-image working again?
<ogra_> again ?
<ogra_> did it not work ?
<pmp> ogra_: it boots, but I cannot use any snap I installed
<pmp> ogra_: wait I'll get the link of my mail to the mailing list
<pmp> https://lists.ubuntu.com/archives/snappy-devel/2016-April/001746.html
<ogra_> pmp, ah, that might be fixed with the img mvo mentioned above (or if you simply build your own from todays snap packages in the store)
<zyga> ogra_: thanks for sharing my article!
<ogra_> thanks for writing it !
<pmp> ogra_: thanks, that's the information I was looking for to hear
<mvo> dpm: just testing, ubuntu-clock-app-mvo can go, I will unpublish/remove
<mvo> ogra_: aha, if rpi2 is otherwise ok I will upload it as well
<dpm> thanks mvo, no worries. I was just wondering if you were uploading a hotfix to the existing clock or something
<mvo> ogra_: once you (or someone else) verifies that the dragon works I will send a mail to the mailinglist about the new images
<pjoe> how can I see what is inside a snap file?
<pjoe> do I have to mount with squashfs .. or is there some other way
<mvo> pjoe: unsquashfs -ls (or -ll) snapfile
<mvo> pjoe: or unsquashfs snapfile to unpack it
<pjoe> thanks .. for now manage to mount it
<Marco___> hi guys, I just booted the new amd64-all-snap.img. there's stil an issue with eth interface. "ip addr" lists enp2s0 as interface, but in /etc/network/interfaces.d/ it's still called eth0 .. renaming eth0 to enp2s0 (and all stuff inside file) works meanwhile for me ..
<ogra_> Marco___, file a bug please (we should hanlde it the same as on all other images where we enforce old names)
<pjoe> btw. I'm testing on a pc with 2 NICs .. trying to unplug cable from one and insert into the other seemed to work pretty badly :(
<pjoe> like the address of eth0 was never released and routes would still default to the dhcp IP eth0 had gotten
<Marco___> ok, I'll do so.
<pjoe> so even though eth1 was up no traffic would work .. at is was still trying to route everything through eth0
<pjoe> what is the mechanism for handling dhcp and link states?
<zyga> pjoe: that looks like ifupdown, I don't think it handles that at all, you need network manager
<zyga> pjoe: the good thing is, it will be snapped soon, with a supporting interface
<pjoe> heh ... oh don't get me started on nm
<jamiebennett> mvo, ah, I missed it, do we have new rp2 images?
<zyga> pjoe: well, you're out of options then
<pjoe> but suppose I can live with it
<pjoe> so nm will only be a snappy install away?
 * pjoe has been fighting with various nm bugs in the past .. so know some of the code (all too well)
<mvo> jamiebennett: yes, since this morning
<mvo> jamiebennett: I prepared an annoucement mail but I wait for someone to confirm that the dragonboard image actually works, my dragonboard is unfortunately broken
<pjoe> is there a readme or something for how to build image with the new alyout?
<jamiebennett> mvo, I have one here
<mvo> jamiebennett: nice!
<pjoe> lunchtime .. bbl
<zyga> mvo: I can check
<zyga> mvo: mine is operational
<zyga> mvo: what is the gadget snap for dragonboard?
<zyga> mvo: canonical-dragon is not in the store
<mvo> zyga: the image is on people.c.c
<mvo> zyga: http://people.canonical.com/~mvo/all-snaps/dragon-all-snap.img.xz
<zyga> mvo: I tried building it
<zyga> mvo: (ubuntu-image)
<zyga> mvo: latest udf but it prints this error instead:
<mvo> zyga: it should work, you need to build it from the 16 series now, one sec I paste my cmdline
<zyga> Determining gadget configuration
<zyga> expected a gadget snaps: snap not found
<zyga> ahhh
<zyga> thanks!
<mvo> zyga: http://paste.ubuntu.com/15943880/
<zyga> yes, updated ubuntu-image, thansk
<mvo> zyga: :)
<ogra_> mvo, waiting for dd ... do we have any working smaple package ?
<mvo> ogra_: hello-world, xkcd-webserver, go-example-webserver should all work
<mvo> ogra_: hm, maybe not go-example-webserver
<zyga> ogra_: links :)
<mvo> ogra_: I thnk dholbach uploaded moon buggy too and links from zyga
<mvo> zyga:  :)
<zyga> ogra_: though no armhf build
<zyga> ogra_: I can make one in ~30 minutes if you need one
<ogra_> hello-world is enough :)
<ogra_> so we got a shiny store update but i'm still offered the canonical-pi2 gadget in snap find on arm64 ... tsk
<ogra_> (and -i386 and -pc)
<mvo> ogra_: they are all arch indep
<mvo> ogra_: we really need to filter gaget from default searches
<ogra_> yes, thats what i mean ;)
<ogra_> or have a --filter option for package types :)
<mvo> ogra_: lets put it on the pile 223434 items we want to polish ;)
<ogra_> mvo, thumbs up for the dragon ... serial, monitor and ssh logins work, i can install, find, list and remove snaps
<mvo> ogra_: \o/
<ogra_> why is it not upgradeable btw ?
<ogra_> (you say that in etherpad
<ogra_> )
<mvo> ogra_: it is upgradable, it will just not do it by itself
<mvo> ogra_: the auto update timer job is broken because we have only snap refresh <snap>
<ogra_> oh, right, my bad
<mvo> i.e. no "refresh all"
<ogra_> you wrote auto-update
<mvo> ogra_: feel free to correct in the pad so that its clearer
<ogra_> i thihnk we should mention the dropped config interface ... beyond that i think it is fine
<mvo> ogra_: good idea, let me add this
<mvo> ogra_: I actually think I should get these images on cdimage instead and remove the current (outdated) ones, will clarify with the release team
<ogra_> mvo, oh, see Marco___ above ... no auto config of network interfaces on amd64
<mvo> ogra_: really? that works for me in kvm, I have eth0 with a valid IP
<ogra_> (we need net.ifnames=0 on the commandline)
<ogra_> mvo, not on real HW where the interface wont be called eth0
 * pjoe is on amd64 device .. so at least don't need xcompile :)
<ogra_> its a simple addition to the kernel commandline to enforce the ethX names
<pjoe> is this the place to find newest image: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ ... or is it better to build image myself?
<ogra_> pjoe, if you want to help testing http://people.canonical.com/~mvo/all-snaps/ is the place ;)
<pjoe> ok, will give it a try
<ogra_> we'll release these als 16.04 alpha soon
<pjoe> nice
<mvo> ogra_: meh, I thought we had code that detects the interface name in firstboot. oh well, I release note it, thank you
 * ogra_ wonders if there isnt a way to enforce a werid name in kvm ... would make sense to have that in the tests 
 * pjoe reads more about how to make snaps ... wouldn't mind trying to get lxd up on latest img
<ogra_> wow
<ogra_> so booting kvm with: -net nic,model=e1000,name=foobar0 ... makes it hang on boot
<ogra_> (firstboot and sys-subsystem-net-devices-eth0 give an unlimited systemd counter in the shell)
<ogra_> ah, the eth0 job timed out now ...
<ogra_> doesnt look like firstboot will ...
<ogra_> mvo, "boot will hang" in the etherpad should probably get added "forever" (doesnt seem like it will move on here with the mangled nic setup in kvm)
<mvo> ogra_: added, thanks
<ogra_> bah
<ogra_> and as i saw you writing it it moved on
 * ogra_ deletes again
<ogra_> added a correct time estimage instead :)
<ogra_> mvo, heh, webdm ?
<ogra_> (currently broken )
<ogra_> i'm surprised you installed it
<pjoe> hmm that amd64-all img doesn't boot for me :( sad panda
<ogra_> how do you try to run it ?
<mvo> ogra_: well, *maybe* we will update to something that works later ;)
<ogra_> mvo, yeah, but i see it only on amd64 :)
<pjoe> dd to usb and boot on device .. looks like it kind find or load the snaps
<ogra_> how does the boot hang ?
<pjoe> getting no such file or dir for the ubuntu-core and canonical-pc-linux
<ogra_> damn
<pjoe> could this be the missing squashfs boot param?
<mvo> ogra_: indeed, silly me, fixing my build scripts
<ogra_> mvo, i guess i need to re-enable MODULES=most for the initrd :/
<mvo> ogra_: :/
<ogra_> pjoe, no, most likely a missing module for your disk controller
<mvo> Marco___: re bug #1572466 when the machine boots snappy, does ifconfig show anything at all beside the "lo" interface?
<ubottu> bug 1572466 in Snappy "eth interface naming" [Undecided,New] https://launchpad.net/bugs/1572466
<ogra_> (or USB in your case ... i added usb-storage to the initrd but i fear there are lower level bits missing)
<pjoe> ok ... will try to look for more info ... unfotrunately this device doesn't have serial tty .. so I'm limittede to what hasn't already scrolled off the screen :(
<ogra_> yeah, i know what you mean :)
<pjoe> hmmm wondering if it's because I also have an ssd disk on the device ... with old snappy 15.04 installed
<pjoe> maybe it's trying to mount from there
<ogra_> oh !
<pjoe> time to get the screwdriver out :D
<ogra_> well, you could boot from some other mediaq and just remove thje "writable" label from the partition on the SSD
<ogra_> that is all we look for
<pjoe> will try simple disconnected ssd first ... should be fastest way to test for me
<ogra_> heh, ok
<ogra_> let us know how it goes
<pjoe> will do
<pjoe> fwiw I didn't have that issue with the image from: http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/
<ogra_> the image design changed quite a lot
<ogra_> (single partition, everything is a snap)
<pjoe> okbut that one still has only writable part ... no sys-a/b
<pjoe> and it also said 16.04 when it booted (even though the download is from 15.04) :D
 * pjoe got the device open now
<ogra_> that cant really be ...
<ogra_> ogra@nusakan:~$ ls -l /srv/cdimage.ubuntu.com/www/full/ubuntu-snappy/15.04/edge/*
<ogra_> -rw-r--r-- 1 cdimage cdimage 144411420 Jul  7  2015 /srv/cdimage.ubuntu.com/www/full/ubuntu-snappy/15.04/edge/ubuntu-15.04-snappy-amd64-generic.img.xz
<ogra_> i dont think we had teh single partition layout on Jul 7th
<pjoe> weird ... pretty sure that was where I found it
<pjoe> ok booting now without the ssd ... looks more promising :)
<ogra_> phew
<pjoe> it even got ip addr :D
<pjoe> and ssh works .. so far so good :)
<pjoe> but there is no snappy .. only snap command
<ogra_> ok, then the initrd isnt faulty ... phew
<pjoe> that 15.04 edge I tried before had both ... guess it might have been mid transition :D
<ogra_> heh, yeah, it was mid transition for the last 4 months or so :)
<pjoe> but still no lxd snap :S ... will need to dig into how to get that done for 16.04
<ogra_> yeah, now that the setup is final all the snaps need to be adjusted for it
<pjoe> huh .. but nic interface name is back to eth0 ... before was en1sp0
<pjoe> oh well
<ogra_> ah, thats actually good
 * pjoe testing if the other interface then is eth1
<pjoe> hmmm
<pjoe> maybe needs a reboot
<pjoe> ahhh can see on console other nic is en2sp0 ... always good to mix things up
<popey> dholbach: dpm got qtox working!  ð
 * pjoe really misses vim on snappy ... will have to manage with just vi
<popey> dholbach: dpm we finally have a GUI example http://bazaar.launchpad.net/~snappers/snappy-playpen/trunk/files/head:/qtox/ :)
<dpm> popey, nice, good work!
<pjoe> btw. any tricks for optimizing boot time? .... coming from coreos it seems to boot quite a bit slower
<pjoe> huh .. after reboot no network ifs came up
<pjoe> think I saw in console eth0 had become en1sp0
<popey> yeah, nics have new names in recent kernels
<pjoe> well first time it booted it was eth0 and got an IP
<pjoe> hmm
<Marco___> mvo: bug #1572466: on first boot ifconfig shows up eth0. all following boots it only shows lo. ip addr shows enp2s0 additionally to lo
<ubottu> bug 1572466 in Snappy "eth interface naming" [Undecided,New] https://launchpad.net/bugs/1572466
<pjoe> sounds like what I'm seeing
<pjoe> heh had a typo ens1p0 instead of enp1s0 ... think things are coming up now
<ogra_> pjoe, echo "set nocompatible" >.vimrc
<ogra_> ;)
<ogra_> that gives you normal vim behaviour in vi
<pjoe> ahh so it is the full vim binary ... sweet
<ogra_> its stripped down ... but at least it behaves like normal vim
<ogra_> (you can use cursor keys in insert mode etc)
 * pjoe is still trying to learn vim ... guess that will always be an ongoing process :D
<dpm> sergiusens, hi! If I'm creating a local snapcraft plugin, is there any way to specify the launch command, other than me having to ship a separate app.launch script?
<pjoe> I can see both nics now :D ... as enp1/2s0
 * ogra_ curses ... why is LP timing out for me 
<pjoe> snap find '*' is a pretty short list now though :S
 * pjoe tries if my network bridging setup at least now wroks and persists
 * ogra_ updates info on bug 1572466
<ubottu> bug 1572466 in Snappy "net.ifnames=0 missing on kernel commandline in amd64 images" [Undecided,Confirmed] https://launchpad.net/bugs/1572466
<pjoe> heh doing 'mount' show a pretty long list
<ogra_> yeah, thats the "bind mount farm" ... that gives you some writable files
<pjoe> btw. how does path work? ... does all snaps get inserted in path or do they put things in liek /usr/bin
<pjoe> oh btw. when connecting through mikrotik routers I get weird errors like this: - Download snap "nmap" from channel "stable" (Get https://068ed04f23.site.internapcdn.net/download-snap/McFtwWmHVzBWwYSVtXzCdJ6Rt4STQPtl_17.snap?t=2016-04-21T11:12:20Z&h=0078afbef70454c19e106b106682012950b32e9c: dial tcp: lookup 068ed04f23.site.internapcdn.net on 192.168.88.1:53: cannot unmarshal DNS message)
<pjoe> never seen that kind of thing before
<pjoe> is snap implemented in go? ... it sounds a bit like this: https://github.com/golang/go/issues/11070
<pjoe> I'm guessing the router has some kind of dns proxy doing some funny biz
<ogra_> pjoe, yes
<pjoe> kool
 * pjoe has been very fond of go so far
<ogra_> wow, nmap works really nicely
 * ogra_ guesses he should get nethack ported to the new world ... 
 * pjoe using beego framework for some backend stuff
<ogra_> mvo, no pi3 image btw ?
<ogra_> i also dont see pi3 in snap find :/
<pjoe> doing 'snap install nmap' when using openwrt router works just fine ... again must be the other router doing funny dns proxy stuff
<ogra_> yeah
<ogra_> mvo might be able to tell you if/how you can set up a proxy
 * ogra_ imagines you can use http_proxy like on other ubuntus 
<pjoe> no worries ... stil just trying to understand what works and what doesn't ... and how things work
<pjoe> e.g. how do snaps get their binaries into path ... can see from nmap that it ends up in /snap/bin
<pjoe> but it isn't bind mounted there .. is it just linked?
<zyga> pjoe: those executables are wrappers generated by snappy
<zyga> pjoe: they are not the real executable
<pjoe> ahh, I see
<hdtvee> does anyone know whats going on with ubuntu snappy desktop ? i remember reading about plans to eventually make snappy the default package management system on desktop and was quite excited about it but i havent come across any news on this ever since
<ogra_> hdtvee, where did you read that (not true)
<hdtvee> hold on
<zyga> hdtvee: it has been added to 16.04 as as a default install, you can use the new snaps alongside the good old debs
<zyga> hdtvee: 16.04 is not snap-based though
<ogra_> hdtvee, deb will stay the default, but snaps are supported by default as well
<ogra_> the system is (and will stay) deb based
<oparoz_> Will it be possible in 2.0 to run a config script at install time to set things up? Things like creating folders and files for the various services installed with the snap
<ogra_> by 16.10 there might be snappy based desktop images too ... but they wont replace the existing desktop
<hdtvee> https://www.maketecheasier.com/ubuntu-snappy-what-you-need-to-know/
<ogra_> oparoz_, you can do that today in your snap startup scripts (you wont be able to create dirs in the system, and why would you though)
<zyga> oparoz_: no
<zyga> oparoz_: you can do that when your service starts
<ogra_> hdtvee, thats nonsense ... the existing desktop installs wont go away
<zyga> oparoz_: but you cannot run any scripts at install time
<oparoz_> Thanks zyga. The problem is that scripts are started at random, so each and every daemon needs to include the setup script
<ogra_> hdtvee, as i said, tzhere might be additional snappy based desktop images at some point, but we would be insane to stop providing the existing stuff :)
<zyga> ogra_: that article talks about frameworks :-(
<ogra_> too many people use it and depend on it
<zyga> oparoz_: you should patch your daemon to use the snappy dirs
<oparoz_> zyga, they do already
<zyga> oparoz_: each snap has a snap-wide data and per-user data (which daemons don't really use since they run as the root user)
<ogra_> zyga, yeah, some research might have helped :)
<oparoz_> zyga, but we have to re-create everything on the writable partition in order to organise things
<zyga> ogra_: internet journalism ;)
<ogra_> yep
<zyga> oparoz_: ?
<ogra_> as long as it pays off :P
<oparoz_> zyga, create var/log, var/tmp var/run
<oparoz_> zyga, create folders for apps to put their files in
<oparoz_> zyga, typically something you only do once
<zyga> oparoz_: snaps cannot do that, you cannot write to /var/log or /var/tmp or /var/run, you have to patch the daemon code to use s$SNAP_DATA
<zyga> oparoz_: those directories *are* set up for you by snappy
<oparoz_> zyga, yes, but those folders would be $SNAP_DATA/var/tmp, etc.
<oparoz_> zyga, so we know where all logs files, sockets, etc. are
<zyga> oparoz_: well, you can just organize that space in some way, note that /var/tmp won't be removed on reboot, the socket can be just directly in $SNAP_DATA/foo.socket, etc
<zyga> oparoz_: if you reorganize the code around snappy concepts it should be easier
 * zyga -> lunch
<ogra_> oparoz_, just add a startup wrapper that creates them if they dont exist
<ogra_> underneath your snap dir
<ogra_> and make sure all bits you need are in that snap and know that they should write there
<ogra_> thats the proper way to do it in snappy
<oparoz_> ogra_, that's what I'm doing today. I call a filesytem_setup script, but I thought it would be more efficient to be able to call it once at install time, because that's when changes will happen
<oparoz_> I don't like the idea of polluting $SNAP_DATA with log files, sockets, pids, app folders, etc.
<ogra_> oparoz_, just check for SNAP_VERSION ... and comparie it to a stamp file
<ogra_> then you can call it only on upgrade
<oparoz_> ogra_, good idea :)
<ogra_> though dont forget that people can roll back :)
<ogra_> your check needs to cover that
<oparoz_> true
<oparoz_> ogra_, but with snap version, the script will be run every time a service is started when the snap is first installed
<MichaelTunnell> hdtvee: I am making a video that explains Snappy, that might be of interest to you :)
<oparoz_> overall it's not a big deal, but that means adding something to the documentation of a snap, telling people that every daemon as to include a call to that script
<oparoz_> *has
<ogra_> oparoz_, well, it can be a two liner ... wont really be noticeable
<oparoz_> ogra_, Indeed
<hdtvee> MichaelTunnell, alright link it when it's ready
 * pjoe got persistent network bridge working :)
<pjoe> also looks like it would be possible to have custom kernel modules in a oem-gadget-snap
<pjoe> at least canonical-pc-linux looks to have kernel moduls :)
<ogra_> not really, you want them in a custom kernel snap instead
<pjoe> ahh you can do that
<ogra_> gadget (formerly oem) = bootloader and specifications
<pjoe> things slowly starting to fall into place for me
<ogra_> kernel = all the other HW bits
<ogra_> note that both are in the process being re-defined though
<ogra_> (but i guess the basics above wont change)
<pjoe> so you can have a custom kernel snap .. with patched kernel modules and what not ... and you can update that at your own pace independently of ubuntu-core snap
<ogra_> if you would ship a graphics driver it would be in the kernel snap ... together with the libs it needs
<kyrofa> Good morning
<pjoe> I 'just' need to patch a whatchdog drive module to support specific chipset
<pjoe> driver
<mvo> ogra_: proxy is a tiny bit tricky, needs a systemd environment setup, I can post details if someone needs them
<ogra_> mvo, pjoe might
<mvo> ogra_: pi3 - how do we make those? whats the gadget/kernel? happy to build some
<pjoe> so canonical-pc-linux is the default kernel snap
<ogra_> mvo, same as pi2 but with the canonical-pi3 gadget (note it is identical to pi2 currently, but i'll change that soon
<ogra_> )
<ogra_> pjoe, right
<mvo> ogra_: would be nice to clarify with e.g. jamiebennett if we should host pi3 images under the .canonical namespace or if those should be a different namespace (more community oriented)
<mvo> ogra_: aha, ok
<ogra_> i wanted a generic pi image ... but neither ppisati nor I got serial to worjk on the pi2 with the pi3 uboot
<jamiebennett> mvo, ogra_, I'd like to move out the community builds to their own space, just to improve the clarity
<ogra_> that means we need two separate gadgets ... beyond that the image is identical
<zyga> ogra_: didn't pi3 change serial lines around so that it can talk to bluetooth?
<zyga> ogra_: debug serial moved to then next one
<ogra_> jamiebennett, the querstion is weather pi3 should be a community build :)
<jamiebennett> ogra_, something to discuss at the sprint ;)
<ogra_> zyga, right ... and sadly it does that inside uboot
<zyga> ogra_: ahhh
<ogra_> jamiebennett, we support the pi as default arch ... and i suspect the pi2 deliveries go down over time ... so i'd definitely keep it supported
<ogra_> (and rather drop pi2 after a while)
<jamiebennett> ogra_, agree (although keep pi2) but whether is it officially blessed or part of the community is up for discussion
<jamiebennett> I suspect it is more the former though
<ogra_> especially since the pi3 is better suited for IoT with wlan and BT by default
 * pjoe goes reading about how to build snaps ... to try and figure out how much it would take to get lxd up
<ogra_> you want to read about snapcraft
<ogra_> it also has examples
<pjoe> looking here: https://developer.ubuntu.com/en/snappy/build-apps/get-started/
<ogra_> (note that you need a xenial systeom or at least a xenial chroot with snapcraft 2.x)
<pjoe> heh is planning to update my laptop tomorrow
<pjoe> but guessing maybe docker 16.04 could do for today
<pjoe> or even lxd 16.04 :D
<ogra_> yeah
<popey> dpm: do you have any snaps which use an icon and .desktop file, I'd like to take a look and see how you did it
<dpm> popey, both the clock and calculator apps do. You just need to 1) drop the icon and .desktop file in a setup/gui directory 2) make the icon field in the desktop file be: Icon=${SNAP}/meta/gui/$YOURICON.png
<dpm> popey, http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/
<dpm> it's a bit of duplication, as it's a manually crafted .desktop file as opposed to the already built one, but as far as I could tell, there wasn't a way to use the built one
<popey> magic, thanks dpm
<dpm> np
<sergiusens> dpm we will grow plugin meshing with apps once we have a clear design for this; sorry its not there yet; but we also really want it for other use cases; it is just that they are too disparate as they are
<dpm> sergiusens, it's fine, for now it helps me to know there is no other way.
<dpm> sergiusens, also, I find myself copying and pasting the same wrapper over and over for the core apps. I've now started using a custom plugin based on the old qml plugin. If I get it in shape and submit it to snapcraft, would it make sense to get it back upstream? Or was there any particular issue for which it was dropped, other than being unmaintaned?
<sergiusens> kyrofa elopio hey, today its all hands on deck on vila's PR :-)
<kyrofa> sergiusens, you got it
 * vila runs twice as fast 
<vila> sergiusens: happy to discuss anything really, things are still moving server-side but I catch up quickly
<vila> sergiusens, kyrofa, elopio: mainly because store_tests can be run against staging so I can validate before prod is available
<popey> dpm: where does your package end up putting the .desktop file? I see nothing in /usr/share/applications
<ogra_> yay, my tablet arrived
<sergiusens> dpm yes, I mostly killed the qml plugin because it made to many assumptions that were not JUST about qml
<sergiusens> dpm I would be happy to accept something that works for a common base
<zyga> popey: /var/lib/snapd/desktop
<zyga> popey: snappy rewrites desktop files on install
<sergiusens> vila when you say things are moving, are you saying that the stuff landed in this PR might break us in the future?
<sergiusens> I am not super keen on emergency PRs
<sergiusens> vila also, haven't looked at the PR in detail, but can we check if we own the name before uploading a huge snap?
<vila> sergiusens: I can predict that ;-) What I meant is that I'm still waiting for some bits server side to finish macaroon'ed upload and implement publish
<popey> zyga: my unity7 dash doesn't see the desktop file
<popey> zyga: it's in that location, but i can't start my app from the dash
<dpm> popey, in the final snap, it puts it under meta/gui.
<vila> *I /can't/ predict what will break
<dpm> sergiusens, ok, cool. I'll submit it and we can discuss it in the review
<popey> dpm: but once installed, do you get an icon for clock app in your dash?
<popey> because I don't
<dpm> popey, yes, I do
<popey> hm
<davmor2> popey: I don't
<dpm> tested both clock and calculator yesterday
<popey> you sure you're seeing the real desktop file for your snap?
<vila> sergiusens: well, I'm not keen at all with emergency PRs myself...
<dpm> popey, I'm quite certain I am, as in my tests first it was missing the icon, then I fixed it and I could see the icon in the dash and launcher
<popey> hm
<davmor2> popey: but then I still get davmor2@davmor2-XPS-13-9343:~â« ubuntu-clock-app.clock
<davmor2> can not find a snappy os
<popey> davmor2: snap install ubuntu-core
<vila> sergiusens: I'm trying to provide macaroon support for snapcraft as soon as it's available in the store. I understand snapcraft will need it sonner rather than later but I'm all for validating as much as we can
<dpm> popey, but... I haven't upgraded my system since yesterday.
<dpm> davmor2, hm.... I was told ubuntu-core installs automatically for you the first time you install a snap
<popey> it does now
<popey> it might not have done in the past
<dpm> ok, phew
<dpm> yeah, it's quite recent afaik
<popey> i tested that by nuking my entire snap install and installing clock
<popey> ubuntu-core installed first, so that certainly works
<xtihc> ææ¢è¯´åªéé½æè¯´ä¸­æç
<popey> just confused by this desktop file missing
<popey> !cn
<ubottu> å¦æ¬²ç²å¾ä¸­æçåå©ï¼è«è¼¸å¥ /join #ubuntu-cn æ /join #ubuntu-tw
<davmor2> davmor2@davmor2-XPS-13-9343:~â« ubuntu-clock-app.clock
<davmor2> QXcbConnection: Could not connect to display :0
<davmor2> Aborted (core dumped)
<dpm> davmor2, are your snaps installed under /snap or /snaps?
<xtihc> ..
<popey> davmor2: i think you need to nuke and pave
<davmor2> dpm, popey: they are both under /snap/
<dpm> davmor2, ok, at least that's the right location
<davmor2> popey: how did you nuke just rm -rf /snap/ or run a command?
<dpm> davmor2, you might need to wipe your /snap directory and mounts, we've all gone through this in the last couple of days, welcome to the club :)
<popey> davmor2: one mo, let me pastebin
<davmor2> ta
<popey> http://paste.ubuntu.com/15947367/ that kinda thing
<popey> dpm: what version of snapd you on?
<dpm> popey, 2.0.1, I've not updated yet this morning to 2.0.2
<popey> I'm on 2.0.2
<popey> be interested to know if the .desktop thing broke from 2.0.1 to 2.0.2
<dpm> popey, dholbach might be able to help with testing on 2.0.2
<popey> ok
<popey> :)
<sergiusens> vila kyrofa seems the PR needs some work still; can we implement `register-name` independently or take guidance from dholbach's summary to add a link? ref: https://bugs.launchpad.net/snapcraft/+bug/1572399
<ubottu> Launchpad bug 1572399 in Snapcraft "[upload] Catch name registration issue and explain how" [High,In progress]
<davmor2> popey, dpm: Now I seem to be struck by the fact that ubuntu-clock-app isn't listed at all
<popey> davmor2: snap find | grep clock
<popey> davmor2: maybe snap login ?
<dpm> davmor2, or snap find ubuntu, either should work
<davmor2> http://paste.ubuntu.com/15947484/
<popey> davmor2: i386 or amd64?
<davmor2> popey: amd64
<kyrofa> sergiusens, think it's worth investing the effort if it's all switching to macaroons soon?
<popey> davmor2: version of snapd?
<kyrofa> sergiusens, easy to add the link though
<popey> $ snap find ubuntu-clock-app
<popey> error: no snaps found for "ubuntu-clock-app"
<popey> :(
<popey> the whole "snap find" thing is broken
<davmor2> ii  snapd                                                2.0.2                                               amd64        Tool to interact with Ubuntu Core Snappy.
<popey> hmm, I can't see any of dpm's apps either
<dpm> sudo snap install ubuntu-clock-app should do too
<dpm> tyhicks, jdstrand, is there an interface to grant access to dbus? I'm having an issue with the weather app snap whereby it tries to access the network and it's blocked -> http://pastebin.ubuntu.com/15947469
<sergiusens> kyrofa right, I just don't want to do anything in a hurry that would break snapcraft completely; you can at least upload today if the name is registered
<zyga> dpm: each interface can grant access to dbus
<davmor2> dpm: look at the output in my paste you will see it failed
<popey> davmor2: confirmed, snap find shows same here as you see
<dpm> davmor2, popey, argh, I know why. Since this morning apps need to be registered for the 16 release. I've not done that yet for clock and calc :/
<kyrofa> sergiusens, agreed 100%
<popey> ahhhhh
<vila> sergiusens: "can we check if we own the name before uploading a huge snap" not in the MP, known issue but no solution either in the short term :-/
<zyga> dpm: the upcoming network-manager interface should fix part of that bug
<popey> dpm: tickbox in the store?
<kyrofa> sergiusens, I assume that error is store-side. I wonder if they could add a link there?
<sergiusens> dpm you shouldn't have network-bind there now, should you?
<zyga> popey: you have to upload again
<davmor2> jibel: ^ there is the cause of your disappearing apps
<popey> ah, okay
<popey> thanks zyga
<dpm> popey, no, I need to register the name as well, will do all in a minute
 * zyga stops working and goes outside
<popey> ok
<popey> sorry dpm :)
<sergiusens> nessita is it possible? To add a link to the error message from the store here https://bugs.launchpad.net/snapcraft/+bug/1572399
<ubottu> Launchpad bug 1572399 in Snapcraft "[upload] Catch name registration issue and explain how" [High,In progress]
<dpm> sergiusens, probably not, I was just testing.
<zyga> popey, dpm: I will talk about interfaces more later today, by the end of next week interfaces will have very solid and in-depth documentation
<dpm> sergiusens, zyga, does that mean that until there is the 'network-manager' interface I can't get the weather snap working?
<dpm> popey, np, good catch
<sergiusens> dpm I think the network manager interface ALLOWS you TO BE network manager, not talk to it
<zyga> sergiusens: no
<sergiusens> I THINK so at least
<popey> zyga: i appreciate your help
<zyga> sergiusens: it allows both
<vila> sergiusens: oauth will no longer be valid for snappy I tried to preserve it but this is becoming increasingly hard and slows me down
<nessita> sergiusens, you would like the error returned in the API for upload contains the link?
<zyga> sergiusens: depending on plug vs slot side
<sergiusens> zyga isn't that a bit too broad?
 * zyga really stops working
<sergiusens> zyga a k
<popey> wise
<zyga> sergiusens: no, you think in terms of old caps :)
<josepht> zyga: when you get back inside and have a chance; devtools is still not working for me.  https://pastebin.canonical.com/154809/ I'm at commit 9e6802e2d338d432cc265bc469cbf39e6dec3766
<sergiusens> zyga yes I do ;)
<zyga> sergiusens: interface has two sides and those do different things :)
<zyga> josepht: pull
<zyga> josepht: I fixed that earlier today
<vila> sergiusens: fwiw, integration_tests.test_upload.UploadTestCase.test_upload_with_login started failing last night
<zyga> hmm
<zyga> 9e6802e2d338d432cc265bc469cbf39e6dec3766
<zyga> I build all the images with this revision
<sergiusens> vila hmm, I released 2.8.3 last night; master should still work
 * sergiusens tests
<zyga> s/build/built/
<vila> sergiusens: I did use snapcraft register-name with macaroons to register it for u1test+...@c.c so it should pass again, but other integration tests (on master) should still fail
<zyga> anyway, really off
<vila> sergiusens: yes, it does and should continue to work as long as people register and publish from the web site
<kyrofa> nessita, yeah. Maybe something like "You must register X name for 16 before uploading, please register it and try again (see https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ for more information)." ?
<zyga> josepht: that might be a bug in the snap itself, maybe mvo will know
<vila> nessita: will OAuth uploads keep working for the 16 series ?
<zyga> kyrofa: have snapcraft send X-Did-Register-Name and have the server drop the connection early if that's not the case
<nessita> kyrofa, ok, but then notice that name-registration can happen via API, so from my POV is a bit uneven that upload can be done via API, but you then redirect the user to a browser for name registration
<sergiusens> nessita yes, something like what kyrofa says :-)
<nessita> kyrofa, sergiusens I think snapcraft should offer name registration via API to the developer
<sergiusens> nessita so vila is adding support for `snapcraft register-name` now and we will ultimately switch to that, but I don't think it will make it before release
<kyrofa> nessita, indeed, we agree. But we're all oauth right now
<nessita> kyrofa, sergiusens that upload endpoint does not handle snap-ids, so I'm not sure you should be using it
<nessita> vila, the old upload endpoint was conceived to be used with clicks and old snaps, not new snaps
<vila> nessita: yeah, I'm worried about fallouts indeed
<nessita> if it works is by chance, and from the store side we can not guarantee backwards compatibility for new snaps
<nessita> vila, sergiusens, kyrofa I keep having this feeling that snapcraft should store internally a mapping of names -> snap-ids so we can:
<sergiusens> nessita we inherited the original upload implementation from pindonga; I have no clue about the endpoints
<vila> sergiusens, kyrofa: best guestimate for macaroon uploads in today or tomorrow. I have uncommitted code to test the new endpoint as soon as it's available on staging... That's the best I can do ;)
<nessita> 1- know if a name was registered or not
<nessita> 2- have the snap-id to push to API that requires it
<vila> nessita: renames ?
<nessita> vila, not exactly sure what you are asking
<vila> nessita: we agreed on using name, series from the client, sca doing the translation to snap_id (in https://docs.google.com/document/d/1pOAazzykOjBzkFHc9OyV_ORz8CByvWTeZlKgwEJ9YX4/edit)
<vila> nessita: a local mapping will break on renames
<sergiusens> nessita we can't do any drastic changes today, so we will need to coordinate this post release
<sergiusens> nessita please don't break us after release, you don't endure the pain of an SRU as we do
<nessita> vila, we can talk about this in u1-internal, I see your point
<popey> upgrading to snapd 2.0.2 now means I can't lanuch my app at all...
<vila> nessita: ack
<popey> $ mame
<popey> /bin/sh: 0: Can't open /snap/mame/100003/command-mame.wrapper
<popey> seems launching broke
<nessita> sergiusens, I understand the need of coordination; I also think OAuth should not exist anywhere in snappy or snapcraft
<nessita> sergiusens, anyways, will not break anything today, will raise this issues with the proper people
<sborovkov> Hi. I am on RPI with image yesterday's latest images used. After I installed snappy-debug snap and rebooted it does not mount. I can't removeit as well - error: can't remove "snappy-debug": cannot find mounted snap "snappy-debug" at revision 13. Any ideas what's going on?
<Marco___> apparmor rights for snap package: I am calling "systemctl xx" from inside my application and always get apparmor denied. does anyone know how to give my snap application sufficient rights for that call?
<zyga> popey: uninstall all versions, reinstall, this is bug https://github.com/ubuntu-core/snappy/pull/1049
<zyga> popey: (of mame)
<ogra_> uuuh !
<ogra_> nessita, why do i find snaps on my tablet since today ?
 * ogra_ just got offered his upnp-server snap when searching for the filemanager
<popey> zyga: i just filed bug 1572568 - is that bug fixed with that?
<ubottu> bug 1572568 in Snappy "Cannot launch apps since upgrade to snapd 2.0.2" [Undecided,New] https://launchpad.net/bugs/1572568
<popey> zyga: can't remove... - Remove snap "mame" from the system (remove /snap/mame/100002/bin/launcher: read-only file system)
<zyga> popey: that's a different bug!
<zyga> popey: please report it, I also saw it once but I was unable to reproduce it
<zyga> mvo, pedronis: ^^^
<zyga> popey: I think there are two bugs at play, the one I referneced was just about incorrect security after snap upgrade
<mvo> popey: is that running? mame? I suspect the removal one is https://bugs.launchpad.net/snappy/+bug/1571721
<ubottu> Launchpad bug 1571721 in snapd (Ubuntu Xenial) "Removing when an app is running results in a half removal" [High,Triaged]
<mvo> zyga: https://bugs.launchpad.net/snappy/+bug/1572568 is  dupe,  let me find the other one
<ubottu> Launchpad bug 1572568 in Snappy "Cannot launch apps since upgrade to snapd 2.0.2" [Undecided,Confirmed]
<mvo> popey: ups, --^ for you
<sergiusens> nessita heh, this was the reason I wanted pindonga to originally provide his own package with store bindings; so then you could change this all you want without so much coordination; something to consider again after release
<popey> mvo: no, the app isn't running
<popey> mvo: it happens when i try and remove side loaded things I installed on 2.0.1
<mvo> popey: anything that still is open and keeps an fd on the dir? I suspect it failed to unmount the dir because the mount point is busy
<mvo> popey: don't get me wrong, definitely a bug, just trying to understand it :)
<ChrisTownsend> ogra_: Hey, tedg said you might be able to help me.  I have a squashfs based snap and need to debug an app inside it.  Do you have a trick on how I can modify files inside the snap and still preserve the same environment that is normally used?
<kyrofa> ChrisTownsend, overlayfs?
<ogra_> ChrisTownsend, no, and with the classic shell gone currently i suspect the workaround that jdstrand had wont work either (he had a way to add an overlayfs)
<kyrofa> ogra_, I use that without the classic shell
<popey> mvo: D'oh! I had a shell open in those directories! But now I don't, and they still won't remove :(
<ChrisTownsend> kyrofa: Care to elaborate?
<mvo> popey: same error?
<popey> yes
<mvo> popey: hm, I'm in a meeting right now, but something like lsof |grep /snap/mame would be nice
<ChrisTownsend> ogra_: Hmm, not being able to debug "inline" is not very handy:-(
<kyrofa> ChrisTownsend, https://paste.ubuntu.com/15496227/
<popey> mvo: http://paste.ubuntu.com/15948319/ is sudo lsof | grep mame | pastebinit
<ChrisTownsend> kyrofa: Cool, thanks.  I'll give it a shot.
<ogra_> ChrisTownsend, well, it will all get better within the next months ... (some kind of classic mode will come back etc)
<ChrisTownsend> ogra_: Ok, good to know it's being thought about and worked on.
<kyrofa> jdstrand, you should consider shipping that script in snappy-debug
<kyrofa> (it would have to be unconfined I suppose)
<sborovkov> ogra_: Hello. Any ideas what's going on? sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2 -o test.img -> This gives me error expected a gadget snaps: snap not found
<ogra_> ChrisTownsend, we're pretty much back at zero currently ... basics are done, features not
<ChrisTownsend> ogra_: Wow, ok.
<ogra_> sborovkov, do you use the very latest ubuntu-device-flash from http://people.canonical.com/~mvo/all-snaps/ ?
<zyga> sborovkov: use 16 instead of rolling
<zyga> sborovkov: or use my script github.com/zyga/devtools
<josepht> zyga: I'm getting that with devtools now as well
<ogra_> oh, another change :P
<zyga> josepht: then more broken :)
<zyga> josepht: does your copy say "16" or "rolling"?
<josepht> zyga: 16
<ChrisTownsend> kyrofa: Seems that works on my snap.  One other quick question.  To get it back in the ro state, just unmount the overlayfs, right?
<zyga> josepht: then more broken stuff, I'm sorry
<kyrofa> ChrisTownsend, you got it
<ChrisTownsend> kyrofa: Cool, thanks again!
<kyrofa> ChrisTownsend, obviously that'll undo your changes
<ChrisTownsend> kyrofa: Right
<sborovkov> zyga, ogra_: works with 16 instead of rolling (I am using latest ubuntu-device-flash)
<kyrofa> ChrisTownsend, sure thing :)
<josepht> zyga: no worries
<ogra_> sborovkov, good
<kyrofa> ChrisTownsend, note that you can use more permanent directories if you want the ability to remount an overlay you were working on
<sborovkov> Does new permission system with plugs/interfaces work now? can I use it to give my snap to /dev/vchiq now?
 * zyga wonders if udf has is out-of-date again?
<josepht> zyga: seems to be only for pc, pi2 works for me
<zyga> sborovkov: yes, yes but you need to patch snappy
<ChrisTownsend> kyrofa: Ok, makes sense, but I think I have enough for now.
<zyga> sborovkov: I'm writing articles about snappy interfaces, I will get to that point in a few more days
<zyga> sborovkov: the first one was posted to planet ubuntu last night
<zyga> sborovkov: I'm writing the second one right now
<zyga> sborovkov: my articles will allow anyone to understand interfaces and create a new interface for a particular purpose
<sborovkov> Ok, got it. Thanks.
<dholbach> popey, wow... I overlooked the message earlier - that's awesome, let me try it
<pmp> I'm still learning: what's the difference between snappy 2.0 and Ubuntu Core 16 / 16-series?
<popey> dholbach: don't worry, it broke in the meantime :)
<zyga> pmp: ubuntu core 16 contains snappy 2.0
<dholbach> popey, right... it's been what... 3 hours? :)
<ogra_> you guys are to slow
<popey> heh
<ogra_> dholbach, FYI ... we had to remove the images that slangasek released on cdimage on your request (they were completely broken)
<ogra_> new images will show up there soon though ... (in some "alpha" subdir or so i suppose)
<dholbach> ogra_, it wasn't so much MY request - it was more like we wanted to point people to images which were not hosted in somebody's home directory
<ogra_> yeah
<dholbach> and that was requested by sabdfl and others in the mailing list thread too
<ogra_> sure, but we cant release un-upgradeable images that you cant install anything on
<ppisati> FWIW, i still get the "/tmpmnt_writable/..." error when trying a custom kernel
<ppisati> kernel just rebuilt
<ppisati> while i used latest mvo's amd64 image in people...
<ogra_> does the initrd somehow get cached locally or some such ?
<ppisati> ogra_: cached?
<ogra_> by the snapcraft kernel plugin
<ppisati> ogra_: i can do a
<ppisati> git clean -fdx
<ogra_> or do you not use that for your custom klernel
<ppisati> in the snapcraft dir
<ppisati> and rebuild
<ogra_> yeah, seems like you are stuck on an old initrd to me
<ogra_> or that you need some controller module you are missing
<dpm> davmor2, popey, ubuntu-calculator-app and ubuntu-clock-app are again available. If you installed them before yesterday, you might need to remove and reinstall âat least that's what I did
<popey> ok
<popey> hah, 120MB clock :)
<jibel> attente, in which version of gnome-software is the re-prompt issue fixed?
<popey> this better be a pretty damn amazing clock!
<popey> dpm: that worked
<jibel> attente, i get it again and it prompted me at least 3 times when I was installing a snap
<jibel> attente, do I need to clear everything again?
<ogra_> popey, be careful what you wish for .... it might unfold big ben in your office if you start it ...
<popey> :)
<attente> jibel: it's in the archive version, not the private ppa
<ogra_> oops ...
<attente> jibel: i'm updating the private ppa right now though
 * ogra_ notes he forgot the MIR for initrmafs-tools-ubuntu-core
<ogra_> wishful thinking :P
<attente> jibel: it should be fixed since it takes the fixes we've made to the archive version
<jibel> attente, okay, I'll replace the version by the archive version
<attente> jibel: actually... it hasn't been released yet :(
<jibel> attente, I don't need anything anymore from the ppa right?
<attente> jibel: it's the version 3.20.1+git20160420.1.ca63436.ubuntu-xenial-0ubuntu1
<attente> jibel: the public ppa has that version, the private ppa has the snappy plugin enabled
<attente> jibel: you still need the ppa until that gets into xenial
<attente> jibel: and if you want the snappy plugin, you need the private ppa
<seb128> attente, we have a version with the current fixes from distro + snap plugin enabled?
<seb128> or asked differently is the private ppa keeping up or behind?
<attente> seb128: i just did an update to the private ppa
<attente> seb128: all it is is the version Laney uploaded with the snappy plugin enabled
<seb128> attente, good
<joe_____> hi, i'm trying out snappy on a device i have. i'm using docker for running a few services, and now i want to set up monitoring of the device host. what are good options? is it still the traditional tools like munin, nagios that are the way to go?
<jdstrand> dpm (fyi tyhicks): re interface to access dbus> that question is very open ended. I think you mean, is there an interface to grant the weather app access to network-manager. the answer is 'no', not at this time. however, a network-manager interface is in the works. It won't autoconnect because the network-manager interface is dangerous
<dpm> thanks jdstrand
<jdstrand> niemeyer_: note, this is an interesting thing we'll want to discuss at some point. on Touch we were in a position to say 'sorry, you can never talk to network-manager' but with interfacecs, users may be faced with questions like 'should this app be able to talk to network-manager' at which point, they'll be like "I don't know, I guess"
<jdstrand> niemeyer_: and therefore users are being put in a position to make policy decisions that they should not
<dholbach> davidcalle, dpm, popey: I'm pushing another non-working example to snappy-playpen :)
<popey> heh
<dpm> dholbach, "well done"! :-)
<dholbach> I'll use it to track another interesting bug I'm running in :)
<dpm> dholbach, davmor2, are you able to launch clock from the dash?
<dholbach> let me see
<sergiusens> kyrofa ogra_ https://github.com/ubuntu-core/snapcraft/pull/476
<dholbach> dpm, yep, WFM
<dpm> ah, phew
<dpm> thanks for confirming
<dpm> seems some people are not seeing it from the dash
<ogra_> sergiusens, looks sane
<davmor2> dpm: I am now yes
<dpm> thanks davmor2 for confirming
<popey> wtf, why am I not
<popey> ubuntu-clock-app  3.6+snap3             ubuntucoredev
<dpm> popey, did you remove and reinstall?
<popey> yes
<popey> nuked entire snap setup
<nessita> ogra_, we are investigating, we think we have the issue narrowed down, building a fix
<dpm> popey, oh, so you nuked the whole setup again today?
<popey> just now
<popey> recently
<ogra_> nessita, awesome
<popey> so i have a pretty clean setup
<dpm> popey, maybe snappy is rebelling against being destroyed so often
<popey> s/snappy/skynet/
<zyga> popey: we didn't announce that rename yet!
<popey> hah
<sergiusens> nessita is X-Ubuntu-Release 16 or 16-core?
<sergiusens> 16 i alone it seems :-)
<nessita> sergiusens, 16
<jdstrand> popey: re fontconfig> something (it might be a library the app ships) is broken. it is trying to write to /var/cache/fontconfig. /var/cache/fontconfig is not in the ubuntu-core os snap, not mounted from the classic system and even if either were true, the non-root user would not have write access to it anyway (even if apparmor granted it)
<jdstrand> popey: someone from the desktop team needs to take a look-- perhaps there is a variable that needs to be set
<popey> okay
<jdstrand> popey: note, the apparmor rules you and zyga discussed were about 'r'ead rules, not w'rite rules. the denial was for a 'w'rite rule
<popey> yeah. I have no idea why it wants to write there
<popey> it also needs to read a bunch of udev stuff for input device enumeration
<zyga> jdstrand: hey, welcome back! :-)
<jdstrand> kyrofa: we could ship that script in snappy-debug. note, snappy debug is totally broken right now due to like 10 different changes in the system
 * jdstrand will be working on developer mode soonish
<kyrofa> jdstrand, whoa, only 10? That's pretty good
<jdstrand> zyga: hi! thanks :)
<shuduo> mvo: i heard of new u-d-f appear then downloaded it. now it can't find gadget snap. may i know if gadget naming changed again?
<sergiusens> nessita thanks
<jdstrand> popey: re udev and device stuff, that is very much going to be a new interface. snappy will need to expose the devices and then have a way to grant them to the snap
<jdstrand> kyrofa: hehe :)
<jdstrand> zyga: were you able to locate the patch I sent for bluez?
<jdstrand> zyga: I didn't send it, I put in in irc
<shuduo> zyga's ubuntu-image does not work with latest u-d-f too
<jdstrand> zyga: here it is: http://paste.ubuntu.com/15837884/
<jdstrand> popey, dpm: re clock app and network manager-- same thing the question I answered a few minutes ago. really, these apps should be using connectivity-api from Touch instead of network-manager
<sborovkov> Hello. getting this error when trying to install snappy-debug -> - Download snap "snappy-debug" from channel "stable" (snap not found)
<sborovkov> What can I do to fix this?
<jdstrand> sborovkov: is this on 16.04?
<zyga> jdstrand: still on my TODO list
<zyga> jdstrand: I'm off today
<jdstrand> ie, 16.04 image or 15.04 image?
<jdstrand> zyga: that's fine (enjoy your day off and go away!! :)
<zyga> jdstrand: aaalmost ;)
<jdstrand> zyga: I just wanted to make sure you had the info
<dpm> jdstrand, hm, they do use the connectivity API
<sborovkov> jdstrand: yes
<dpm> as far as I understand it
<joe_____> how would you monitor a device host that's running snappy? is it still traditional tools like munin, nagios etc. that are the way to go?
<sborovkov> jdstrand: rpi.
<dpm> jdstrand, ah wait. So you mean instead of using QNetWorkManagerInterface something else should be used? -> http://pastebin.ubuntu.com/15947469/
<dpm> jdstrand, this, it seems? https://developer.ubuntu.com/api/apps/qml/sdk-15.04.1/Ubuntu.Connectivity.index/ I'm not familiar with it, so I don't know if it can do what the Weather app needs
<dpm> jdstrand, it seems to be used only to check network status, not to get data over the network?
<mvo> shuduo: you need to use the "16" series now instead of "rolling" - could that be the issue?
<jdstrand> sborovkov: snappy-debug isn't in stable yet for 16.04 because it doesn't work yet
<sborovkov> oh, alright. The command snap install snappy-debug worked like day before yesterday, so I was surprised when it did not
<shuduo> mvo: yes, 16 series working now. does that mean rolling be dropped?
<jdstrand> dpm: you'll want to talk to mzanetti I think. the point is, you can't give a subset of the nm api to answer the question 'am I online' cause the nm api isn't written with untrusted apps connecting to it in mind. therefore the phonedations team created the connectivity-api to answer that question for apps and it has a very clean, safe api
<jdstrand> dpm: connectivity api isn't on 16.04 by default though afaik, that might be a seb128 question
<mvo> shuduo: yes
<mvo> shuduo: its dropped for now until we open a new rolling again
<jdstrand> sborovkov: well, if you did install it, it wouldn't work properly anyway. this is something I will be looking at after release
<seb128> jdstrand, dpm, no it's not, nothing on the iso uses it it seems
<_morphis> zyga, jdstrand: you had time to look at our PRs for the bluez and network-manager interfaces?
<mvo> ogra_: what is the status of bug #1563296 ? I see fix released but an open snappy task, anything we need to do in snappy land?
<ubottu> bug 1563296 in cloud-init (Ubuntu) "support cloud-init networking with snappy" [Medium,Confirmed] https://launchpad.net/bugs/1563296
<shuduo> mvo: interesting. good to know. let me update my training slides with this change. thanks.
<ogra_> mvo, it is fix-released in livecd-rootfs already ... can be closed
<jdstrand> _morphis: I responded to nm late monday and I saw zyga did yesterday (I think). I was off yesterday and still catching up. if there are things for me to respond to, I will today
<_morphis> jdstrand: thanks!
<sborovkov> jdstrand: right it did not... after I rebooted it did not even mount itself. And I could not remove it since it was giving me error that it's nto mounted
<mvo> shuduo: cheers
<mvo> ogra_: same question for bug #1562784 - I assume the snappy task can be closed as well here?
<ubottu> bug 1562784 in Snappy "cloud-init 0.7.7~bzr1189-0ubuntu1kills snappy boot " [Critical,Confirmed] https://launchpad.net/bugs/1562784
<ogra_> mvo, yeah
<mvo> ta
<ogra_> mvo, can you take a look at mterry's questions in bug 1572544
<ubottu> bug 1572544 in ubuntu-core-config (Ubuntu) "[MIR] ubuntu-core-config" [Critical,Incomplete] https://launchpad.net/bugs/1572544
<ogra_> i assume we can drop /snaps
<mvo> ogra_: yes we can
<ogra_> obama !
<mterry> :)
<shuduo> mvo: seems canonical-pc gadget snap does not exist in  16 series and edge channel?
<ogra_> mvo, can you make snappy-dev the default bug team for ubuntu-core-config, initramfs-tools-ubuntu-core and ubuntu-core-libs ? (i cant, needs a team admin)
<ogra_> iirc the last one is ubuntu-core-meta though
<jibel> dpm, I cannot install the calculator or the clock it tells me it's already installed
<mvo> shuduo: hm, it should I have a look, there was a store issue some minutes ago that hide some snaps
<jibel> dpm, probably because I had pre-2.0.2 installation
<jibel> dpm, what do I do to install the new snaps?
<shuduo> mvo: dragon snap and pi2 snap can be found. pc snap can't. pls check.
<davmor2> jibel: http://paste.ubuntu.com/15947367/ is apparently how popey got my install working, but then I had to manually install ubuntu-core
<jibel> davmor2, yeah that's what I did yesterday already
<jibel> davmor2, it's pretty annoying and impracticable to do that after each upgrade of snapd
<sborovkov> Hello. Do I understand correctly that old-security is not working anymore? is there some simple way I can use new syntax to get old 'unconfined' behavior?
<zyga> sborovkov: no, just install your snap in development mode (snap install --devmode)
<zyga> sborovkov: and work on a new interface (docs on that will be availalbe in the next few days)
<sborovkov> zyga: alright. but as you said before - to allow snap acess /dev/vchiq snappy needs to be patched - how long till that's not needed?
<zyga> sborovkov: till you patch it?
<zyga> sborovkov: or someone else does
<zyga> sborovkov: wait a few more days, I it will all be clear (er) when I describe how that works
<kyrofa> dholbach, perhaps you know the answer to this: https://askubuntu.com/questions/759557/how-to-run-a-command-in-a-snap-package ?
<zyga> sborovkov: btw, what is /dev/vchiq?
<dholbach> kyrofa, dpm knows - he did it in ubuntu-clock-app
<dholbach> dpm, ^ did you update lp:snappy-desktop-examples with the newest?
<kyrofa> Thanks dholbach :)
<sborovkov> zyga: rpi gpu interface
<zyga> sborovkov: I plan to work on pi2 support in the next few weeks
<zyga> sborovkov: I plan to get various perhiperials supported (gpio, spi, i2c, camera)
<jamiebennett> Anyone had problems removing and reinstalling snaps today?
<zyga> sborovkov: just stay in touch, you can help me out soon
<zyga> kyrofa: I replied to that question
<marco___> zyga: I am also very interessted in getting infos for the new sec. concept :-)
<zyga> kyrofa: many people just upgrade and still have just /snaps/bin (note /snaps, not /snap) in their path
<jamiebennett> http://pastebin.ubuntu.com/15951144/
<zyga> marco___: great, follow my blog posts. I sent the first one yesterday. The next one will be published in around two hours, I'm just collecting feedback from proofreaders
<sborovkov> zyga: Ok
<kyrofa> jamiebennett, I seem to remember seeing a bug about needing to remove twice
<kyrofa> jamiebennett, was the clock running when you tried to remove it, perhaps?
<zyga> jamiebennett, kyrofa: each installs creates a new revision, you need to remove *each* revision
<zyga> so you have to remove it till it's gone
<kyrofa> Ah, or that
 * jamiebennett tries to remove again
<zyga> heh :)
<kyrofa> zyga, thanks for answering that question :)
<jamiebennett> If I try to install twice it wont do it
<jamiebennett> How did I get two copies of the clock app?
<zyga> jamiebennett: side loading creates new revisions
<kyrofa> jamiebennett, perhaps you got an update after you initially installed?
<jamiebennett> zyga, no sideloading
<jibel> jamiebennett, I had the same issue and had to reset everything
<jibel> jamiebennett, http://paste.ubuntu.com/15947367/
<jibel> systemctl stop snapd instead of service
<zyga> wait
<jibel> zyga, no sideloading here either
<zyga> jibel, jamiebennett: use this instead: https://github.com/zyga/devtools/blob/master/reset-state
<zyga> this is correct-er
<jamiebennett> :)
<jamiebennett> Looking back through my console log it looks related to refresh so kyrofa may be correct
<jamiebennett> damn autocomplete
<tedg> sergiusens: Is snapcraft doing an ldd and pulling libraries into the snap?
<tedg> Got a bunch of libraries in ./snap that I can't figure out how they got there.
<kyrofa> tedg, yes
<tedg> Okay, thanks kyrofa!
<tedg> Is modern snapcraft if the vivid-overlay PPA for the phone? Or just xenial?
<tedg> I guess not in, but built against.
<jamiebennett> zyga, this is the sequence of steps: http://pastebin.ubuntu.com/15951538/
<ogra_> tedg, only xenial
<ogra_> no backports
<slangasek> ogra_: thanks for the MIR work today.  I see there's still no MIR for ubuntu-fan, which is also on the seed?
<ogra_> slangasek, i was kind of expecting the owner (kernel team) or the cloud teams to MIR it, given it is default in all cloud images
<ogra_> we are only participants here ...
<tedg> kyrofa: Is there any filtering on that list? I was surprised for instance that libGL.so got added when that should be in the kernel snap.
<kyrofa> tedg, indeed, but the list is pulled from stable right now
<kyrofa> tedg, specifically, anything included in the stable os snap is not automatically copied
<kyrofa> tedg, but I think opengl in the os snap is new
<kyrofa> tedg, probably not in stable
<tedg> kyrofa: Well it's not the OS snap, but the kernel snap. It is an enablement thing really.
<slangasek> ogra_: oh, checking
<slangasek> ogra_: c-m fingered snappy, but I believe that may be wrong
<ogra_> slangasek, if needed i can indeed take over ... but i kind of think fan needs to be solved in a broader scope
<slangasek> ogra_: system-image is the only seed that contains ubuntu-fan
<ogra_> oh ? i thought it was a requirement for all container cloud work
<ogra_> hmpf ... k
<slangasek> ogra_: regardless, the MIR process should be owned by whoever is introducing the dependency
<ogra_> i'll file a MIR bug then ... (its a sabdfl request to have it )
<kyrofa> tedg, ah, interesting. Yeah that may need to be updated
<ogra_> i dont think we have even ever made any use of it
<kyrofa> Things will settle once the desktop work flows back into ubuntu core
<sergiusens> kyrofa tedg mvo told me not to filter out gl; it is safer to include it for now.
<kyrofa> sergiusens, ah, good to know
<kyrofa> And agreed, since not everything has it
<ogra_> slangasek, bug 1572650
<ubottu> bug 1572650 in ubuntu-fan (Ubuntu) "[MIR] ubuntu-fan is supposed to be shipped in snappy and thus needs to move to main" [Undecided,New] https://launchpad.net/bugs/1572650
<tedg> Ah, interesting. Will change as graphics drivers do.
<slangasek> ogra_: ok, so you know that's not a complete MIR bug yet, right :)
<ogra_> kirkland, any idea why snappy seems to be the only consumer of ubuntu-fan (it is in universe atm)... i thought it was supposed to be some kind of default for all container related installs
<qengho> Why do snaps in the store show up sometimes and not sometimes, on new instances, with "snap find"?
<qengho> Are snaps in the store still valid?
<dpm> jibel, sorry, I was on a call. Did you manage to get the apps installed in the meantime, or do you need help?
<dpm> sergiusens, if I want to build a qmake app, which essentially needs 'qmake' to be run, and then 'make' over the generated Makefile, what's the best way to do this with snapcraft? Creating a qmake plugin that inherits the make plugin?
<qengho> dpm: I have done that sort of thing a few times. You might want to just copy the make plugin and change it, too. Your choice.
<dpm> qengho, thanks! I'd rather do something I can reuse, so perhaps creating a qmake plugin might be the way to go. Do you have any examples of how you've done it before?
<jibel> dpm, yes, I reset everything again
<ram_> hi, i'm trying to boot in "try" mode. It is told in the guide that "/lib/systemd/system/ubuntu-core-snappy.service" will undo the action. But I find no such service file within lib/systemd/system directory. any help??
<jibel> until next upgrade :)
<ogra_> stop that upgrade madness ...
<ogra_> just stay with what works :P
<dpm> jibel, ok, glad it worked :)
<qengho> dpm: let me push something up...
<dpm> awesome, thanks!
<dpm> popey, jcastro, do you happen to know how we can get notifications for new Ask Ubuntu questions tagged with 'snapcraft' or 'ubuntu-core' on this channel?
<popey> there was an au bot
<jcastro> there's a bot
<popey> dunno who ran it
<qengho> dpm: http://bazaar.launchpad.net/~cmiller/+junk/kodi-snap/view/head:/parts/plugins/x-fake_autotools.py
<jcastro> I can find out
<ram_> hi oliver, can you help me?
<ram_> i'm trying to boot in "try" mode. It is told in the guide that "/lib/systemd/system/ubuntu-core-snappy.service" will undo the action. But I find no such service file within lib/systemd/system directory. any help??
<qengho> ram_: Which guide?
<ram_> this one https://developer.ubuntu.com/en/snappy/guides/system-updates/
<ram_> then who will remove the file /boot/uboot/snappy-stamp.txt ?
<ogra_> ram_, that hasnt bee used in ages
<ogra_> uboot is completely managed inside the uboot.env file
<ogra_> writing text files to fat turned out to be pretty unreliable and made us end up with corrupt fat every now and then
<ogra_> so everything was moved into the uboot.env file which has a fixed size, is binary and not prone to filesystem corruption
<ram_> thanks ogra_. so how to implement the logic? is there no need for system-stamp.txt file? i have u-boot based board
<jcastro> I am trying to snap a node app: http://paste.ubuntu.com/15953115/
<jcastro> but I get this error when doing a `snapcraft snap`: Issues while validating snapcraft.yaml: The 'command' property does not match the required schema: './bin/google-music-electron' is not of type 'object'
<ogra_> ram_, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files ... have a look at the other gagdet snaps
<qengho> jcastro: Sounds like you have a string and it expects (for some reason) a dictionary.
 * ogra_ tickles mvo again about that bug team subscription for the packages ... 
<ram_> @ogra_ thanks for that; i'll try. can you guys please please update the guide!
<nothal> ram_: No such command!
<qengho> jcastro: pastebin your snapcraft yaml?
<ogra_> ram_, we will once the gadgets format is final ... it will be re-worked the next weeks
<jcastro> qengho: http://paste.ubuntu.com/15953115/
<jcastro> I'm mostly just trying to hello world a node.js electron app
<ram_> @nothal sorry what?
<nothal> ram_: No such command!
<ogra_> ram_, its a bot :)
<ogra_> (unlike all other bots in ubuntu channels iit reacts to @ instead of ! )
<qengho> jcastro: Your "command:" should be a child of "google-music-electron", not a sibling.
<ram_> ha ha
<qengho> jcastro: Indent "command" a bit more.
<ogra_> jcastro, learn the genealogy of a snap package :)
<jcastro> yargh, so simple, thanks.
<ogra_> for complex snaps you need to ship an ancestry tree alongside ... describing gandma and gandpa :P
<qengho> niblings. pets. planetary system....
<ogra_> :)
<dpm> awesome, thanks qengho!
<davmor2> ogra_: thank god it's nothal I could live happy knowing I don't need to kill it
<ogra_> it might still kill you though
<sergiusens> dpm yes, inherit make, look at the cmake plugin for inspiration
<dpm> thanks sergiusens
<sergiusens> jcastro indentation of your yaml is wrong; line 6 and 7
<jcastro> sergiusens: in the docs the node example pulls from npm, is there a way to do a local npm build instead?
<sergiusens> jcastro look at the webchat example
<jamiebennett> dpm, going back to your comments about .desktop files, should the clock and cal show an icon in the app switcher on SDoC?
<sergiusens> jcastro https://github.com/ubuntu-core/snapcraft/tree/master/examples/webchat
<dpm> jamiebennett, yes, they should. We've tracked the fact that some users are not seeing the icons in the dash as they need to log out and log back in after the snapd 2.0.2 installation
<jcastro> sergiusens: perfect, thanks!
<jamiebennett> dpm, OK, will test that
<dpm> jamiebennett, https://askubuntu.com/q/759557
<sergiusens> jcastro you can laugh at that js code; I don't do js, that was my example after 1 hour into it
<ogra_> jcastro, once you are done laughing, snap up something useful ... like the unifi controller ;)
 * ogra_ would be your first user 
<jcastro> sergiusens: I'm just trying to do a google music app thing, I'm almost there, just need to find what to put in the app: section
<jcastro> ogra_: I have a unifi so yeah, that interests me. :)
<ogra_> jcastro, me too, i'm just to lazy to snap it up ... but this is the *perfect* thing for a snap package :)
<jcastro> sergiusens: all the node examples are webapps with services though, I can't really find a desktopy example
<ogra_> i'll probably do it one day though
<qengho> Okay, I have a rpi3 freshly-flashed with m'vo's new image. Why does "snap find tor-middle-relay.chadmiller" not find my package?
<ogra_> are you sure you are chadmiller ?
<ogra_> :P
<qengho> It's been a long release, but I'm like 90% sure.
<ogra_> ( i think you dont need the uploader suffix anymore)
<ogra_> (for searching that is)
<ogra_> ubuntu@localhost:~$ snap find tor-middle-relay
<ogra_> Name             Version   Summary
<ogra_> tor-middle-relay 0.2.7.6-3 Essential infrastructure node for Tor network
<ogra_> works fine here
<qengho> $ snap find tor-middle-relay
<qengho> error: no snaps found for "tor-middle-relay"
<ogra_> oh, i'm two days outdated on that image ... ignore me
<ogra_> did you release it for 16 yet ?
<qengho> ogra_: I don't know what that means, and that might be the problem.
<ogra_> in the store ui you need to release it for the 16 release
<ogra_> i think
<qengho> "Supported releases
<qengho> rolling-core"
<jamiebennett> dpm, have you seen this before? http://paste.ubuntu.com/15954428/
<dpm> jamiebennett, I've seen it happening on another app I was working in, but not in clock
 * dpm tries to launch clock again
<dpm> jamiebennett, hm, still seems to work for me. It might be worth looking at entries related to launching clock on /var/log/kern.log and point the security guys to them
<qengho> ogra_: I think that means re-uploading the same files. Store doesn't seem to have a UI for mutating the release series.
<ogra_> i actually dont know ..
<ogra_> but there was a lot of discussion in the backlog about this topic
<dasjoe> So, let's talk about ZFS. Is anybody working on making Ubuntu Snappy Core ZFS-based? Or is this blocked by ZoL not supporting x86 and just barely supporting ARM for now? :)
<ogra_> or any other non x86 arch :P
<dasjoe> Well, there's not many left, are there?
<ogra_> i assume you would irather see f2fs support than zfs
<ogra_> given the focus is on IoT ... you dont really want a memory greedy thing like zfs
<dasjoe> I remember playing around with Snappy back at version 40 or so, upgrading meant downloading the whole tarball that was some gigantic 40+ MB. I put it on ZFS and did the upgrade by "zfs send"ing the incremental between 40 and 41 into a file, the upgrade file was around 400k uncompressed
<dasjoe> ZFS is not memory greedy, actually. We're working on getting ABD merged asap, so we waste less RAM on linux. The hard-coded lower limit for RAM is 64 MiB
<ogra_> dasjoe, well, now make zfs work on some device thats stuck on a 3.10 kernel and comes with 256MB ram
<ogra_> (which you want to use to control your heating)
<dasjoe> Relevant upstream pull request: https://github.com/zfsonlinux/zfs/pull/3441
<dasjoe> ogra_: hah, I'd love to do that if I had the required knowledge about C and Linux' memory management
<rajen> Hi Friends, I am trying to build latest Snappy img using ubuntu-device-flash tool. Do you happen to know if I will need a special version of ubuntu-device-flash for the latest Snappy  image.
<ogra_> does zfs support labels ?
<dasjoe> ogra_: labels?
<ogra_> rajen, yes, the latest one from http://people.canonical.com/~mvo/all-snaps/
<qengho> dasjoe: ZFS is not likely. We could binary-diff other ways, and most Ubuntu Core machines are going to be (for a while) 32-bit ARM machines.
<ogra_> dasjoe, all filesystem operations depend on the partition label in snappy currently
<ogra_> so whatever FS we use needs to support labels
<jamiebennett> dpm, did you try rebooting between tests?
 * jamiebennett rebooted, was working before
<ogra_> jamiebennett, this isnt windwos :P
<jamiebennett> I now get this http://paste.ubuntu.com/15954540/
<qengho> dasjoe: ... and I love ZFS. I worked to get ZFS support into zfsutils-linux and grub2 in time for 16.04.
<jamiebennett> ogra_, the opposite, I rebooted and it _stopped_ working
<ogra_> heh
<dasjoe> qengho: hey, so did I. Hello :)
<dasjoe> ogra_: I see. I think you can name the partition however you want, ZFS reads its own labels at fixed positions inside
<qengho> dasjoe: high five! I wish we had started support in the installer earlier, but ZFS wasn't on my radar until January.
<ogra_> dasjoe, our initrd needs to find the label ...
<dasjoe> qengho: so, I've heard about installer support for 16.10, is this still the current plan? Do you think Debian could merge the relevant installer patches?
<ogra_> if that works in zfs without adding megabytes of userspace tools to the initrd ...
<dpm> jamiebennett, I only rebooted on Monday when I removed the whole /snaps folder and restarted snapd. I've not done it since then. Let me see if I also get a denial for gsettings schemas, it might be a red herring
<ogra_> ... then we're fine
<dasjoe> ogra_: well, I've seen people booting off ZFS snapshots. Anyway, I am sure we can work something out once ZoL supports x86 and ARM in any meaningful way
<ogra_> and ppc
<qengho> dasjoe: Do not quote me, but I would be astonished if we didn't have an unsupported path even for 16.04 before summer. Try Ubuntu"
<ogra_> and ppc64el ... s390x ... arm64
<qengho> dasjoe: Do not quote me, but I would be astonished if we didn't have an unsupported path even for 16.04 before summer. "Try Ubuntu", open terminal, add PPA, update, start installer.
<dasjoe> ogra_: s390x and arm64 are supported as of now, I believe
<ogra_> ah, cool
<rajen> Tanks, ogra_..Did anything change w.r.t gadget snap. Earlier I used "--gadget canonical-pc.canonical" option. Now it does not work.
<dasjoe> qengho: interesting. I'll query you what my current installation script does
<dpm> jamiebennett, I'm getting another type of denials, but those don't stop the app from starting: http://paste.ubuntu.com/15954571
<ogra_> rajen, drop the .canonical from the end
<dasjoe> qengho: I've been working with rlaager to get his How-To up to date for 16.04
<ogra_> not needed anywhere anymore
<qengho> Nice.
<rajen> ogra_  What about "--os ubuntu-core.canonical"
<jamiebennett> dpm, and you snap looks like this?
<jamiebennett> ubuntu-clock-app  3.6+snap3  ubuntucoredev
<ogra_> rajen, same thing
<dasjoe> ogra_: I just checked, PPC seems to be supported, too
<ogra_> neat
<rajen> ogra_, Doesn't seem to work :(  http://pastebin.ubuntu.com/15954604/
<ogra_> anyway, i doubt we'd win many of the embedded developers with defaulting to zfs
<dasjoe> So we're waiting for 32 bit support to become better, which follows above ABD patches and possibly more work
<ogra_> having it optional once we have an installer is another story though :)
<dasjoe> I'm just starting out as an embedded guy, I've been trying to buy a Qseven dev kit from Seco for the past few days
<ogra_> (but that installer thing is still far out i fear)
<dasjoe> Also, does anybody know of a Pico-ITX (or similar) sized SBC which comes with ECC RAM and 2x SATA ports? 1x SATA + 1x mSATA/mini-PCIe is fine, too
<dasjoe> Oh right, amd64 only for above reasons. http://www.seco.com/prods/eu/sbc-a44-pitx.html seems to be the only one
<ogra_> i use alix apu boards here ... if these are fine, the pico ones should be too
<dasjoe> Very interesting boards, the apu2c4 comes with ECC, too
<rajen> ogra_, Any suggestions http://pastebin.ubuntu.com/15954604/
<ogra_> rajen, hmm, not really
<ogra_> that line should just work
<rajen> doesn't seem to
<dpm> jamiebennett, sorry, was having dinner. Yes, that's the one I've got installed. Actually, you might want to remove it and reinstall it,
 * jamiebennett tries that
<dpm> jamiebennett, so with the 16 release being opened yesterday on the store, all apps had to be reuploaded
<jamiebennett> dpm, yeah, the clock worked fine until I rebooted a couple of hours ago
<ogra_> rajen, might be that you need 16 instead of rolling
<jamiebennett> dpm, before that everything was up-to-date
<rajen> let me check
<netpheak> hi, guys!
<netpheak> is mvo's rpi2-all-snap.img.xz image compatible with rapid?
<jamiebennett> dpm, nope, remove and install didn't work :(
<netpheak> rpi3?
<rajen> ogra_, now it proceeds. With 16.
<ogra_> netpheak, it should (though hasnt been tested on pi3 i think)
<netpheak> i'll give it a spin ;)
<dpm> jamiebennett, argh :( not sure what else to try next
<jamiebennett> dpm, slightly different error this time http://paste.ubuntu.com/15954752/
 * jamiebennett will investigate more
<netpheak> do i need to do anything to prepare the image?
<dpm> jamiebennett, let me try on my laptop (I've not updated it since yesterday), see if I can reproduce the issue
<netpheak> The image appears to work :)
<netpheak> how do i enable classic mode?
<josepht> netpheak: classic mode has been removed from the latest images but will be reworked and reintroduced in the coming months
<netpheak> :/
<netpheak> Hmm.. how to build armhf packages then?
<netpheak> the rpi is my only arm device...
<ogra_> netpheak, http://cdimage.ubuntu.com/ubuntu-core/daily/current/xenial-core-armhf.tar.gz ... download that ... scp it to your pi ... untar it in a subdir under /home/ubuntu ... copy /etc/resolv.conf from the pi inot the unpackaged chroot and use the chroot command to work in it
<netpheak> Is there a way to cross compile?
<ogra_> only for kernels so far
<roadmr> heya, anybody know how to get snappy 2.0 to work inside a xenial lxc container? It errored during "Mount snap "ubuntu-core""
<roadmr> s/lxc/lxd/ really
<slangasek> roadmr: by default a container doesn't allow mount privs inside; you have to make adjustments to the profile for nested containers
<roadmr> slangasek: ok, let me try that
<dpm-mostly-afk> jcastro, how are you getting on with your first snap?
<dpm-mostly-afk> qengho, do you mind if we add your kodi snap to lp:snappy-playpen? We've got a kodi snap built from .debs there, and it'd be good to have the build from sources example too
<jcastro> dpm-mostly-afk: The thing I tried to snap has a build system so I'm not sure how to proceed
<roadmr> is there any way for snap to cache downloads somehow?
<jcastro> so I moved on to charm-tools and give that a shot.
<jcastro> I have enough of that to show some other people on my team
<dpm-mostly-afk> jcastro, yeah, that's the same I had with atom. Unless the build is generic, it might be worth writing a custom snapcraft plugin to do the build
<rajen> Hi, I need some help with latest security profile updates that went in. While we are Snapifying our app, we are running unconfined for now. I need to know what is the equivalent for http://pastebin.ubuntu.com/15955468/
<ogra_> i dont think there is an equivalent ... but you can install your sanp in developer mode
<ogra_> snap install --help
<kyrofa> Does the unity7 interface give me the ability to have a tray icon?
<zyga> kyrofa: maybe, I don't know if anyone tried
<zyga> rajen: old security and unconfined is gone, you will have to work with us on a proper interface
<ogra_> Unity7 wontt though
<rajen> zyga, Who will be the best person to work with. We have a lot of stuff we do in our app that will require permission tweaking.
<ogra_> (trayicon is dead since we have indicators)
<zyga> rajen: perhaps me, perhaps jdstrand, perhaps yourself
<zyga> rajen: the first thing would be to run your snap in devel mode
<zyga> rajen: and collect logs
<kyrofa> ogra_, indicators is what I meant, I suppose
<josepht> roadmr: if you get that working please let me know
<kyrofa> ogra_, "an icon next to the clock thingie"
<rajen> Zyga, Got it. Let me explore more. Do you happen to have a link to documentation on new security profiles.
<roadmr> josepht: what, lxd? asking in #lxcontainers now, since I can't even run a simple nested container :(
<josepht> roadmr: yes, I'm trying to figure that out as well
<ogra_> Yeah, I doubt that would work from a snap... tedg might know
<kyrofa> ogra_, what makes you doubt it? I thought it was just dbus
<ogra_> It communicates through dubs.... You still need the UI
<ogra_> dbus
 * zyga published http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html
<tedg> kyrofa: Basically there are a set of dbus interfaces with a TODO next to them. If it was opened, you could.
<zyga> roadmr: hey
<tedg> kyrofa: Depends on what gets configured in the unity7 interface.
<kyrofa> tedg, alright that's what I thought. zyga how would I figure that out?
<zyga> kyrofa: try it
<zyga> kyrofa: run it with confinement, then try --devmode
<tedg> kyrofa: https://github.com/ubuntu-core/snappy/blob/master/interfaces/builtin/unity7.go#L119
<kyrofa> zyga, I did. It doesn't work. Okay, I didn't know about devmode
<zyga> kyrofa: I'm sure the security team will review all changes if we choose to open more dbus interfaces but it seems reasonable to allow desktop apps to have access to this
<zyga> kyrofa: snap install --devmode
 * zyga will write a mini-post just about that
<roadmr> zyga: hello! how's it going?
<rajen> What is the new equivalent of "snappy service" command?
<zyga> rajen: it is removed for now, it will be reintroduced later with richer APIs
<zyga> roadmr: good, trying to rest after the marathon
<zyga> roadmr: (the 16.04 release)
<zyga> roadmr: trying to stay off work but you see how bad I am at this
<zyga> roadmr: how are you doing?
<rajen> zyga, Any alternative that I can work with meanwhile. systemctl ??
<zyga> rajen: yes but snaps cannot use it directly (or unless they use --devmode)
<rajen> zyga, okay..slowly slowly...
<roadmr> zyga: hehe yea, you suck at that :) but thanks for the hard work :)
<roadmr> zyga: doing fine, lots of fun stuff happening
<jdstrand> kyrofa, tedg: there are still a few todos in the unity7 interface because I couldn't get various apps to work quickly enough and had to move to other things and because people who had those skills couldn't use interfaces because they only recently landed in a form that people could really develop on them
<jdstrand> kyrofa, tedg: in other words, try this stuff and if it doesn't work file a bug, tag it with snapd-interface and we'll look at it
<tedg> Cool, I think the only bummer is some of those interfaces won't work with unity8, but eh. I guess that's why it's called "unity7" :-)
<wililupy> Question: When I run sudo ./ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc -o my-snappy.img I get the following error: Determining gadget configuration expected a gadget snaps: snap not found.
<wililupy> Anyone else running into this issue? It worked for me in the past.
#snappy 2016-04-21
<dougb> I am needing guidance/help with enabling the built-in serial ports, other than ttyO0, on the BeagleBone Black, using Snappy.
<wililupy> So I'm taking the latest build of snappy 16.04 for a spin, and I need to change some things in the /etc directory, particularly the motd since it says to still use the 'snappy' command even though it is snap now. Also, more importantly, I need to change /etc/default/grub.d/50-system-image.cfg so that the right tty is referenced and I get a console screen (Its supposed to be tty0 not tty1 for my device. Any ideas how to make
<wililupy>  these changes?
<sergiusens> elopio hey, mind giving 2.8.4 a spin? Should be in the archives
<ogra_> sigh ... no mvo ?
<davmor2> ogra_: you mean you broke mvo too, man you're evil
<ogra_> no, but the snappy builds are broken with the final kernels that landed tonight
<pedronis> ogra_: he is off today and tomorrow (not sure about Monday)
<ogra_> damned
<dpm> dholbach, davidcalle, popey, I started playing with moving snappy-playpen to github, and the list of apps last night. I created a repo for testing purposes on my personal account, which we can then move to ubuntu-core or any other suitable place
<dpm> dholbach, davidcalle, popey -> https://github.com/dplanella/snappy-playpen - and also, check out 'sudo snap install notes-dpm', freshly added to the playpen and store ;)
<davidcalle> dpm: nice!
<sergiusens> good morning folks
<popey> dpm: ooh
<sergiusens> ogra_ heh mvo likes to sleep in the morning :-P
<davidcalle> dpm: wow, custom plugin, desktop file and works flawlessly!
<sergiusens> dpm github seems to be taking over ;-)
<dpm> yeah, I'm now sold on plugins :)
<ogra_> sergiusens, thats news to me :)
<sergiusens> dpm makes things easy, you might be our guest speaker on the 26 ;-)
<dpm> :)
<dpm> sergiusens, now that I've got you here... on https://github.com/dplanella/snappy-playpen/blob/master/notes/snapcraft.yaml#L33 I had an issue whereby snapcraft's copy plugin wouldn't take a path relative to the YAML file location. Strangely enough, L32 works. Is this a bug in the plugin, or something I did wrong?
<dholbach> dpm, cool
<sergiusens> dpm let me see
<sergiusens> dpm so the `notes` part has no install rule?
<sergiusens> dpm maybe try and remove this line https://github.com/dplanella/snappy-playpen/blob/master/notes/parts/plugins/x-qmake.py#L34 and here call super().build() at the end of method instead
<sergiusens> I don't see you calling `make install`
<sergiusens> dpm if you still want to use the copy plugin like this; the "relative path" is relative to "source" but you didn't specify that key, so it is relative to "TOPDIR" so it would be `parts/notes/build/...`
<ppisati> ...
<ppisati> Starting new HTTPS connection (1): search.apps.ubuntu.com
<ppisati> "GET /api/v1/search?q=package_name%3A%22ubuntu-core%22&fields=download_url%2Canon_download_url%2Cdownload_sha512 HTTP/1.1" 500 None
<ppisati> search results {'oops-id': 'OOPS-084b4881d5044f92c480531034deb772'}
<dpm> sergiusens, yeah, there isn't an install target in the Makefile, I just had to move the binary around
<ppisati> i was able to build a kernel, and then it started to error out this way
<dpm> sergiusens, and re: the copy plugin. That was exactly how I understood it, however specifying `parts/notes/build/...` did not work, that's why I had to add the '../../', but strangely on L32 it does work relative to TOPDIR
 * Gunther_ is courious how to add an interface Slot so hat his app snap is able to access a specific devise in /dev ...
<sergiusens> Gunther_ talk or write to zyga when becomes available
<sergiusens> Gunther_ he said he'd write a blog post sometime this week or Monday with the process
<Gunther_> sergiusens: ok thanks - I am currently completely blocked because of the remove of old-security ....
<sergiusens> dpm heh, as a hack it works then; ideally I'd propose a PR so they get an `install` rule :-)
<dpm> sergiusens, yeah, I was actually thinking of doing that, but they've got very simple qmake cross-platform build, and I didn't want to get into learning about win32 and osx...
<sergiusens> dpm since your custom plugin is not really specific to qmake (since you add the qt5 config file), it might be better to just do it in there.
<dpm> ack
<dpm> sergiusens, so what do you think about adding the qt5 config file, is that the right place and way to do it?
<sergiusens> dpm at the end of build, just do `os.makedirs(os.path.join(self.installdir, 'bin')); os.link(os.path.join(self.builddir, 'bin', 'Notes'), os.path.join(self.installdir, 'bin', 'Notes'))
<dpm> ok, will give it a go
<sergiusens> dpm for qt5config I'd just create a part for it, with the config file in some source tree and put the part on the wiki (then everyone can consume from it)
<dpm> sergiusens, yeah, the issue is that the file would then have hardcoded arch-specific paths
<sergiusens> dpm right, forgot about that; a file and a Makefile then ;-)
<dpm> sergiusens, but it seems a lot more self-contained to do it in the plugin code, doesn't it?
<sergiusens> dpm yeah; the problem is; what if you want qmake but not this? what if you use cmake? what if, for unknown reasons you have a qmake project that uses GTK?
<sergiusens> dpm those are the questions I ask myself which make me just doubt adding this as an official plugin. I would of done it already if I had these questions answered
<sergiusens> I am still hoping to dream of a solution, wake up and implement :-)
<dpm> sergiusens, how would I solve this with a Makefile, though? Could it not be solved with passing configflags to the plugin?
<asac> Gunther_: couldnt you go back to the previous build until the rework has settled in?
<sergiusens> dpm for some reason I cannot login to wiki.ubuntu.com and add this part, so here you go https://github.com/sergiusens/qt5conf
<sergiusens> dpm copy paste the "part" and change source to this github repo
<sergiusens> dpm or tell me how to log into the wiki, or if you have access, please add my part :-)
<dpm> sergiusens, what was your exact issue logging in? Timeout?
<sergiusens> dpm after oauth it never comes back; I didn't wait long enough; but did wait at least 30s to 60s
<dpm> surprisingly, after the experiences in the last few days, I could login after a few seconds. In any case, where in the wiki does the part go?
<dpm> sergiusens, ^
<dpm> ok, found https://wiki.ubuntu.com/Snappy/Parts but I've no idea what the syntax is nor how to use it
<dpm> I'll give it a go adding it
<sergiusens> dpm: easy; let me do it for you in a pastebin
<sergiusens> dpm http://pastebin.ubuntu.com/15962652/
<sergiusens> dpm then in your parts definition, for notes, just add `after: [qt5conf]`
<sergiusens> dpm that's all you need; no need to define the part locally
<dpm> sergiusens, is there a reason why you removed `build-packages: [dpkg-dev]` on the paste to the wiki?
<sergiusens> dpm err, my mistake :-)
<dpm> sergiusens, ok, https://wiki.ubuntu.com/Snappy/Parts
<sergiusens> dpm I am thinking of a feature to come in snapcraft where we can point to origins and it will consume the snapcraft.yaml from there
<sergiusens> dpm I wish there was something more lightweight than dpkg-dev to get the arch triplet (we got rid of the dep in snapcraft and rolled our own, I might make a shell callable for that or export the envvars'
<Gunther_> snap interfaces lists interesting things for me : network-control and network-observe. For example I would like to restart or reconfigure a running daemon (in snap) if a network interface has changed. Are there examples how to use those slots?
<dpm> sergiusens, I just tried the wiki part, but it seems to fail here: http://pastebin.ubuntu.com/15962859
<sergiusens> dpm did you remove your qt5 config logic from the qmake plug?
<sergiusens> I need to run for a bit, will bbiab
<dpm> sergiusens, I did
<dpm> ok, np
<ogra_> ppisati, !!!
<ogra_> Setting up linux-firmware-raspi2 (1.20151118+b70b451-0ubuntu1) ...
<ogra_> cp: cannot create regular file '/boot/firmware/bootcode.bin': No such file or directory
<ogra_> dpkg: error processing package linux-firmware-raspi2 (--configure):
<ogra_>  subprocess installed post-installation script returned error exit status 1
<ogra_> Setting up linux-image-raspi2 (4.4.0.1009.9) ...
<ogra_> Errors were encountered while processing:
<ogra_>  linux-firmware-raspi2
<ogra_> what is that ?
<ogra_> (breaks the image builds)
<svij> hm, I snapcrafted a package, installed it, removed it. But "snap list" still list it? Do I have to do something else next to "snap remove <snap>"?
<svij> oh now it's gone
<svij> weird.
<jcastro> svij: I noticed that yesterday too, there's a bit of a delay from when it gets removed and when it stops being listed on that list
<svij> jcastro: ah okay
<svij> and the docs on https://developer.ubuntu.com/en/desktop/get-started/ are (already?) wrong.
<svij> had to install ubuntu-calculator-app without ".ubuntucoredev"
<svij> also, running ubuntu-calculator-app.calculator only returns a "command not found"?
<davidcalle> svij: hmmm
<dpm> jcastro, on the "a new app a day" spirit, I uploaded a new app for you, check out notes-dpm ;)
<davidcalle> Youare right about ubuntucoredev
<jcastro> dpm: already installing it. :D
<dpm> :)
<jcastro> slow dl though, I hope the snappy store is on the same infra as the rest of our stuff
<popey> http://popey.mooo.com/mirror/clicks/graph_snaps.png it's making a difference to the graph already :)
<dpm> svij, davidcalle, I'll update the get-started page, thanks for the heads up
<popey> jcastro: there's issues, they're firefighting atm
<svij> dpm: thx!
<jcastro> popey: ack
 * svij still doesn't know how to start the calculatorâ¦
<jcastro> it should just show up in your dash
<svij> I'm using kde
<svij> will that also show up there?
<jcastro> I believe so
<jcastro> XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
<davidcalle> svij: should be
<svij> echo $XDG_DATA_DIRS
<jcastro> I think all DEs use that variable. Though, I was logged in so long I never picked up that change when they changed it a few days ago, I had to log out and back in
<svij> /usr/share//usr/share/xsessions/plasma:/usr/local/share/:/usr/share/
<jcastro> try logging out and back in
<svij> ah
<dpm> svij, davidcalle, updated https://developer.ubuntu.com/en/desktop/get-started/?edit_off#setting-it-all-up
<popey> https://blog.mozilla.org/futurereleases/2016/04/21/firefox-default-browser-for-linux-users-ubuntu-new-snap-format-coming-soon/
<popey> hello!
<davidcalle> dpm: another thing to note down somewhere (that I'm very happy about): if a command matches the snap name, you don't need to $ <snap>.<command> to run it, just $ <snap>
<kyrofa> Good morning
<davidcalle> Morning kyrofa
<jcastro> popey: wow so Mozilla itself will publish right into the store?
<davidcalle> popey: fireworks!
<popey> i guess so
<dpm> davidcalle, ah, nice. I should probably change ubuntu-calculator-app.calculator to ubuntu-calculator-app.ubuntu-calculator-app then
<dz0ny_> svij: fresh xenial works as described on https://developer.ubuntu.com/en/desktop/get-started/
<jcastro> dpm: I get QXcbConnection: Could not connect to display :0
<jcastro> Aborted ore dumped)
<jcastro> with the notes app
<dpm> argh
<davidcalle> jcastro: it was all a trap jcastro, now you help debugging :)
<jcastro> heh
<dpm> jcastro, I've seen that happening for some apps, but it tended to go away as snapd changes were landing
<dpm> so I've never figured out what caused it
<dpm> davidcalle, does the notes app work for you?
<davidcalle> dpm: yep
<dpm> phew
<svij> /var/lib/snapd/desktop is now in XDG_DATA_DIRS but I still get a "command not found" on ubuntu-calculator-app.calculator
<svij> dz0ny_: I've just updated vom 15.10
<svij> hm, ok, starting calculator from the kde-menu works. Now I still don't know what misses to start my own snap, which I just snapcraftedâ¦ (cli tool)
<jcastro> svij: cool, good to know the GUI bits work at least
<dz0ny_> http://i.imgur.com/gWBFB13.png
<dpm> svij, strange that the menu works but not the CLI... For your own snap, can you put it on a branch somewhere for other people to look at it and perhaps help you?
<dz0ny_> works without problems on ubuntu gnome flavor
<dpm> dz0ny_, \o/
<dz0ny_> and in fish shell :D
<svij> dpm: I think the snap is fine, I cant run the calculator from the command line either
<dz0ny_> svij: maybe broken bashrc?
<dpm> svij, perhaps something to do with how your terminal client handles PATH?
<dz0ny_> works from bash too
<kalikiana> svij: You'll want to make sure your PATH contains /snap/bin
<svij> kalikiana: aha! It doesn't
<svij> so the question is: Why?
<kalikiana> If you have a custom shell config like me it's obvious :-)
<svij> well, I was using zsh, same for bash.
<ogra_> svij, /etc/profile.d/apps-bin-path.sh sets it
<ogra_> from the snapd package
<svij> ah okay
<svij> it works now
<svij> thanks kalikiana
<kalikiana> svij: I override PATH completely to be in charge of the order of evyerthing I put in there. So regardless of the shell it won't pick anything up from the system.
<ogra_> how evil
<ogra_> :)
<kalikiana> :-D
<ogra_> you dont trust your packagers, eh ?
<svij> ogra_: he's that evil, he doesn't even trust shoes! :)
<dpm> kalikiana, now that I've got you here.... how do we solve the LocalStorage AppArmor denial in http://i.imgur.com/gWBFB13.png ?
<ogra_> svij, thats fine ... keeps you grounded :)
<svij> ogra_: hehe
<kalikiana> ogra_: Not sure though why I started doing this originally. It's been a long time that anything changed PATH in a meaningful way. I might try what breaks (or not) if I only extend it.
<kalikiana> dpm: Lemme check that here. Now that I've got the snaps working
<dpm> kalikiana, awesome, thanks. That's the last bit we need to get the calculator and clock apps fully working. Right now they cannot write to their databases, so they're more for showcasing purposes than everyday use. If we can fix that, it will open the door for the rest of the core apps to be snappyfied and available on the desktop
<dz0ny_> webdm seems broken thou
<dz0ny_> curl http://localhost:4200/api/v2/packages/                                                                        Äet 21 apr 2016 15:24:54 CEST
<dz0ny_> "Error: cannot list snaps: not found"
<dz0ny_> aka snappyd
<dpm> kalikiana, also note I tried this: http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/calculator.wrapper#L42 on the wrapper that's called to set the env variables before starting the calculator, but it didn't seem to work
<kalikiana> dpm: What's snappy-qt5?
<dpm> kalikiana, it's a config file that needs to be shipped for qt-selector to work and use qt5. Otherwise Qt apps don't start
<dpm> kalikiana, `cat /snap/ubuntu-calculator-app/current/etc/xdg/qtchooser/snappy-qt5.conf`- I don't know much about it other than you need it. Mirv is the expert on qt selector
<kalikiana> dpm: Are you mixing up XDG_DATA_DIRS with XDG_DATA_HOME by any chance? LocalStorage uses _DATA_HOME and that matches the error message, which tries to use $SNAP which is not writable
<kalikiana> Ah so the snappy-qt5 just makes it look inside the snap, so it's not yet another platform plugin
<Gunther_> Anyone seeing something like that? /snap/bin/trionet.trionet-srv  /dev/pts/ptmx does not exist. errmsg: No such file or directory
<sborovkov> Hello, is there some documentation on how to set read/write access with new security permissions? (I had it set that with security-override before, but that seems to not work anymore).
<Gunther_> the same snap is working flawlessly in xenial. The error is happening in "allsnaps"
<dpm> kalikiana, I had tried setting _DATA_HOME, but that seems to then break fontconfig (apps show up with no fonts). See http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/calculator.wrapper#L46
<sergiusens> dpm works here, albeit I am trying directly http://pastebin.ubuntu.com/15965473/
<sergiusens> I'll give your project a go
<kalikiana> dpm: Hrm. I don't know much about fontconfig. What about XDG_CACHE_HOME?
<kalikiana> That should be honored by fontconfig according to a quick duck
<jcastro> dpm: notes worked on my other laptop though, weird.
<dougb> How do you enable the available UARTs / serial ports on the BeagleBone Black with Snappy?
<Gunther_> The latest changes in snapcraft/sources.py make git not to use --depth 1 :(
<Gunther_> at least when i try to make a clean kernel build
<qengho> Can I branch the Store automated tests and suggest others?
<dpm> sergiusens, it worked in the end. It turned out I had to do a full `snapcraft clean` instead of just `snapcraft clean -- step build`. I've updated the code, what do you think now of the YAML file and plugin code? https://github.com/dplanella/snappy-playpen/tree/master/notes - I keep thinking there must be a better way of doing the notes.wrapper thing rather than having a huge wrapper file.
<dpm> kalikiana, I don't know anything about fontconfig, either unfortunately
<beuno> qengho, you can, yes: lp:click-reviewers-tools
<beuno> qengho, what do you have in mind?
<dpm> jcastro, hm, strange, not sure what could cause it not to start in your other machine :/
<dpm> beuno, for apps that we don't own, do you think the convention of using $APPNAME-$MYNAME to avoid naming conflicts is a sensible one to recommend? E.g. `notes-dpm`
<beuno> dpm, sure
<dpm> ok, thanks
<jdstrand> beuno: can someone sync the review tools to the store? (added slots tests)
<jdstrand> asac, dholbach: fyi, uploaded review tools 0.42 to have 'snap-review' symlink
<beuno> jdstrand, probably!
<beuno> cc/ roadmr
<jdstrand> roadmr: it isn't an emergency. it could be next week if needed
<sergiusens> dpm in your plugin all that can go in `env` ideally we can patch qmlscene to have an argument to rebase dirs for a snap
<beuno> deployments are a bit thin today, given the release
 * jdstrand nods
<sergiusens> dpm you don't need this `export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH:$LD_LIBRARY_PATH`
<dholbach> jdstrand, nice one!
<dpm> sergiusens, I tried to put it in env as the qmlplugin did, but that seemed to break the build for some reason (qmake could not be found)
<sergiusens> dpm beuno is `.` allowed again?
<jdstrand> sergiusens: do you know what SNAP_LIBRARY_PATH is about? eg: 'SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:'
<beuno> sergiusens, in a package name?  no
<sergiusens> dpm yes, of course :-)
<jdstrand> sergiusens: I'm a bit concerned about the trailing colon
<sergiusens> jdstrand it was what was mentioned on some list; the extra colon was something niemeyer suggested
<jdstrand> niemeyer: hi! I'm concerned about the trailing colon with 'SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:'. Is there a reason why I shouldn't be concerned?
<jdstrand> sergiusens: thanks
<sergiusens> dpm another suggestion is, let me add something
<niemeyer> jdstrand: Yeah, this is a path list, supposed to be used as such
<roadmr> beuno, jdstrand ; will do
<niemeyer> jdstrand: The fact it has a single item there is coincidental
<jdstrand> niemeyer: where and how is it used? a trailing colon often evaluates to the current direct which can be an attack vector
<niemeyer> jdstrand: The column is there precisely so people don't misunderstand it, and thus don't have broken code in a short while
<jdstrand> directory*
<asac> jdstrand: pretty awesome!
<asac> thanks
<jdstrand> np
<asac> jdstrand: will that be SRU i guess?
<asac> or in main pocket?
<jdstrand> I'll get it into 16.04 somehow, yes
<niemeyer> jdstrand: LD_LIBRARY_PATH
<jdstrand> right
<jdstrand> that is the problematic one
<jdstrand> a trailing colon in LD_LIBRARY_PATH means add your cwd to LD_LIBRARY_PATH
<roadmr> jdstrand: you want c-r-t r634, right?
<niemeyer> jdstrand: That's nuts :/
<dpm> sergiusens, sure, feel free to do a pull request directly
<qengho> Any empty string means ".". A trailing, or internal, leading empty path.
<niemeyer> We'll fix that for the SRU, and include a second path there
<jdstrand> I can file a bug
<niemeyer> jdstrand: Thanks!
<qengho> jdstrand: Would you be happy with  something:/dev/null  ?
<jdstrand> roadmr: let's make it r635 since that is what I just uploaded
<roadmr> jdstrand: ok :)
<jdstrand> qengho: I'd prefer simply not ending with a colon
<jdstrand> roadmr: thanks!
<jdstrand> niemeyer: fyi, bug #1573082
<ubottu> bug 1573082 in snapd (Ubuntu) "SNAP_LIBRARY_PATH set to path with trailing ':'" [Undecided,New] https://launchpad.net/bugs/1573082
<jdstrand> niemeyer: note, because apparmor protects us, this is more of a best practice thing and therefore not an emergency
<niemeyer> jdstrand: Thanks, glad to fix nevertheless, and to learn about the wart
<qengho> beuno: I was looking for a place to complain about invalid or deprecated variables in snapcraft "command:" yaml, but that's deep in wrapper shell scripts by the time it gets to the store, and snapcraft doesn't have sanity checks yet.
<sergiusens> dpm https://github.com/dplanella/snappy-playpen/pull/1
<ogra_> beuno, (or jdstrand ), mind approving  https://myapps.developer.ubuntu.com/dev/click-apps/4284/rev/12/ and https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/6/ ?
<ogra_> these are the final 16.04 kernels
 * ogra_ cant belive it took two days to get them into the store
<jdstrand> beuno: I'll take a look
<jdstrand> ogra_: huh. I'm fine to approve but do we expect symlinks outside of the snap with kernels?
<ogra_> (note, the dangling symlink is fine on the dragonboard ... it is needed(
<jdstrand> ogra_: can you request a manual review for https://myapps.developer.ubuntu.com/dev/click-apps/4739/rev/6/?
<ogra_> jdstrand, it is the only way to have a persistent MAC with the android driver that kernel uses
<jdstrand> interesting. ok, I'll update the review tools
<ogra_> requested
<ogra_> the driver requires the macaddr0 file under /lib/firmware/wlan ... sice we dont have that writable this is a link to /run/macaddr0 ... which gets populated on boot from the initrd
<jdstrand> ogra_: it looks like xenial-preinstalled-core-amd64.kernel.snap has lib/modules/4.4.0-21-generic/build
<ogra_> (generating a MAC based on the board serial number)
<jdstrand> ogra_: that will dangle, no?
<ogra_> yeah
<ogra_> thats from the deb ... it would link to the headers if we installed them
<jdstrand> ogra_: I'm inclined to adjust the test to continue to error if lib/modules/ but otherwise not. I could also only error if not lib/firmware
<jdstrand> ogra_: do you have an opinion?
<ogra_> hmm, is there any security risk ?
<jdstrand> no, not unless you already had control of the device, but it is untidy
<ogra_> i'd just let them dangle
<ogra_> we do that on desktop installs too :)
<ogra_> (until you install the headers)
<jdstrand> why not create the symlink when you install the headers? (rhetorical)
<jdstrand> ok, I'll just allow the symlinks
<ogra_> dunno, i didnt package the deb :)
<ogra_> i can wipe the build one during snap creation in livecd-rootfs ...
<ogra_> but thats an extra hack to maintain
<MichaelTunnell> I thought Snappy didn't need root to install packages. It appears as though it does?
<jdstrand> I'll just allow it for now. if someone asks you to remove the build symlink, then ping me and I'll adjust the tools
<ogra_> ok
<dpm> sergiusens, thanks! otp now, but will merge once we're done
<jdstrand> ogra_: fyi, both snaps approved
 * ogra_ hugs jdstrand 
<ogra_> phew ... that was a heavy one
<jdstrand> roadmr: if you haven't already started the pull, can you use r636 instead for the kernel symlink fix discussed above?
 * jdstrand hugs ogra_ 
<roadmr> jdstrand: sure
<jdstrand> ogra_: happy release day :)
<jdstrand> roadmr: thanks! :)
<roadmr> jdstrand: (you're just in time btw, I was just about to push my changes ;)
<jdstrand> heh
<jdstrand> niemeyer: happy release day to you too :)
<jdstrand> I imagine you're feeling like this day would never arrive :)
<niemeyer_> jdstrand: Yeah, time did compress a little bit in the last couple of months :)
<niemeyer_> jdstrand: Thanks!
<niemeyer_> It's been a fun ride
 * ogra_ must admit he had better release days 
<ogra_> (finding in the morning that our images explode after archive changes wasnt really fun )
<jdstrand> yikes
<roadmr>  /o\ ugh!
<ogra_> well, all sorted now ...
<ogra_> but unexopected after i spent weeks with mvo getting everything sorted in advance
<jdstrand> best laid plans...
<ogra_> yep :)
<dpm> sergiusens, thanks! Where does qt5-launch come from? I saw you replaced the notes.wrapper, but I don't quite understand with what
<davidcalle> dpm: qt5-launch and qt5conf -> https://wiki.ubuntu.com/Snappy/Parts
<dpm> davidcalle, aha, thanks! it was a bit hidden
<davidcalle> There should be a snapcraft list parts command
<davidcalle> There should be an IRC bot to turn IRC feature requests into bug reports
<sergiusens> dpm it is in my branch
<sergiusens> dpm made sense since qt5-config sets stuff up relevant to the wrapper itself
<sergiusens> davidcalle we have a plan of something like apt for parts
<dpm> sergiusens, I'll give it all a go in a few minutes, thanks!
<davidcalle> sergiusens: nice :)
<wililupy> Is ubuntu-device-flash broken? I keep getting the error expected gadget snaps: snap not found for --gadget=canonical-pc.
<ali1234> did the snappy tour get updated for 16.04?
<ali1234> also, any news on pi 3 support?
<ogra_> wililupy, get the latest u-d-f from http://people.canonical.com/~mvo/all-snaps/ and use "16" instead of "rolling"
<ogra_> (the series got renamed)
<wililupy> Thanks ogra_
<qengho> (I'm not sure that^ image is good. I get weird errors. I assumed a recent bug.)
<qengho> (ubuntu-core-launcher[1885]: seccomp_load failed with -22  //  ubuntu-core-launcher[1885]: aborting. errmsg: Invalid argument)
<ogra_> qengho, what arch
<qengho> rpi
<ogra_> update your kernel snap
<ogra_> the final kernel only landed 1h ago
<roadmr> hey folks, trying to build an image i get "expected 3 partitions but found 0" - here's the command and full output http://paste.ubuntu.com/15968587/ any ideas?
<ogra_> roadmr, using the latest u-d-f from http://people.canonical.com/~mvo/all-snaps/ ?
<roadmr> ogra_: should be, I used zyga's script to download. Am double-checking now
<ogra_> "gadget configuration" ?
<ogra_> you have trailing trash there
<ogra_> oh
<ogra_> no, u-d-f has a bug :P
 * roadmr pictures himself dragging a bag of trash with a long string :)
<ogra_> heh
<ogra_> anyway, i built quite a few images today with that u-d-f
<ogra_> so technically it should work :)
<roadmr> ogra_: yes, I have the apr-19 u-d-f from all-snaps
<roadmr> ogra_: am I missing some command maybe? I'm running this inside an lxc too, may that affect things?
<ogra_> theer were two ;)
<roadmr> the 21:25 one
<ogra_> k
<ogra_> yeah, perhaps ... i run it natively here
<ogra_> and also on a xenial host
<roadmr> yes, xenial here. I'll try natively!
<dpm> ogra_, sergiusens, kyrofa, would you happen to know the answer to http://askubuntu.com/questions/760057/will-a-sideloaded-snap-get-upgraded-to-a-newer-version-in-the-store ? And if so, would you mind answering there?
<dpm> or actually beuno might know too ^
<kyrofa> dpm sure
<dpm> awesome, thanks!
<dpm> "You've earned the 'Popular Question' badge (question with 1000 views) for 'What is snapcraft?'"
<dpm> nice :)
 * dpm goes for dinner
<roadmr> ogra_: ok, so run natively, u-d-f works. So it doesn't seem to like being run inside a container :( in case someone else asks. Thanks!
<kyrofa> roadmr, indeed, I've run into the same problem. Runs fine inside vbox though
<dougb_> I need some guidance for how to enable the available UARTs / serial ports on the BeagleBone Black
<kyrofa> dougb_, you probably want ogra_
<dougb_> ogra, do you have any advice on enabling serial ports in Snappy?
<dougb_> ogra_, do you have any advice on enabling serial ports in Snappy?
<dpm> kgunn, would you happen to know what could be causing this OpenGL error when launching snaps? -> http://askubuntu.com/q/759647/9781
<kgunn> dpm-afk: lemme read
<kgunn> dpm-afk: so i "answered" as i don't have enough kwan to comment :)
<kgunn> attente: ping
<attente> kgunn: hi
<roadmr> hey folks, which plug does my snap need in order to be able to run ssh-keygen? I just want to generate a keypair in $SNAP_DATA
<qengho> roadmr: You have to include your own openssh.
<roadmr> qengho: that's inconvenient ;) but ok, guess that's snappy life! I'll do it.
<qengho> roadmr: In your snapcraft part, add  stage-packages: [ openssh-client ]
<roadmr> qengho: yay :)
<roadmr> qengho: where'll the binary live? $SNAP/bin/ssh-keygen?
<roadmr> (well I'll find out soon enough, building snap now)
<qengho> $SNAP/usr/bin/ssh-keygen -- Normal path with $SNAP prepended.
<roadmr> oh! qengho thanks! /me tweaks script and rebuilds
<roadmr> qengho: it works \o/ thanks so much for your help!
<qengho> roadmr: Happy Release Day!
<qengho> Okay, install a snap. Refresh it, get a new version. The apparmor profile in /var/lib/snapd/apparmor/profiles should be updated then, right?
<sergiusens> elopio mind looking at https://github.com/ubuntu-core/snapcraft/pull/480/files
<sergiusens> qengho yeah
<sergiusens> qengho I am seeing an issue that if I sideload twice the binary I call would still be pointing to the older snap
<qengho> sergiusens: no need to sideload.
<qengho> https://bugs.launchpad.net/snappy/+bug/1573247
<ubottu> Launchpad bug 1573247 in Snappy ""snap refresh" doesn't update apparmor rule" [Undecided,New]
<qengho> sergiusens: Oh, you mean the wrapper script is the older one?
<sergiusens> qengho yeah
 * jdstrand wonders what this means:
<jdstrand> $ sudo snap install ./2048-qml_1_amd64.snap --devmode
<jdstrand> error: change finished in status "Hold" with no error message
<skypce> hello
<skypce> how can install a snap package?
<skypce> i was installed ubuntu 16.04 in virtualbox
<skypce> i want test the feature
<qengho> skypce: "sudo apt install snapd; sudo snap install tor-middle-relay"
<skypce> great, thank you qengho
<skypce> i believe that it is enabled by default
<qengho> skypce: did it work? "ps ax |grep tor-"
<skypce> qengho, excelent
<skypce> i was testing vlc
<skypce> it is a probability that snapd will be in trusty?
<qengho> No.
<skypce> ahh, will be great
<skypce> thank you qengho
#snappy 2016-04-22
<stevebiscuit> dz0ny_: I'm still in the process of getting WebDM building against the latest snappy
<chriss_> hello
<chriss_> Any one their
<chriss_> hey
<rampa> when will the new porting guide for Snappy get release?
<dpm> morning all
<dpm> asac, do you happen to own the webdm snap? It does not seem to work atm, and if so, would you mind unpublishing it from the store until it's been fixed?
<dpm> Same for whoever owns the xkcd-webserver snap
<dpm> People are installing these on their desktops and get confused about running them
<flexiondotorg> I've been experimenting when making my first snaps.
<flexiondotorg> They are Python utilities and the Python plugins for snappy are ace. I have snaps and all dependencies are met. Great!
<flexiondotorg> However, when I execute tools from these snaps they complain about permission errors or not being able to read dot files etc.
<flexiondotorg> Is there something "special" I should be doing to allow these snaps to access dot files and data in my home directory?
<stevebiscuit> dpm: I don't have access to the store and I think most if not all of the core team have taken the day off today. sergiusens could possibly be of help
<dpm> flexiondotorg, check the notes on the 'home' interface here: https://developer.ubuntu.com/en/desktop/examples/#snap-python
<dpm> stevebiscuit, ok, thanks, I'll check with him when he's up
<flexiondotorg> dpm, Thanks. I already see this solution :-)
<popey> :)
<flexiondotorg> dpm, This is good stuff - https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
<flexiondotorg> If I have an application that want to read dotfiles/dirs in my home directory, does the document about imply that is simply not possible?
<davidcalle> jdstrand: ^
<dpm> flexiondotorg, I think that's what it means, but you might want to ask the security team for the rationale, jdstrand or tyhicks might be able to help you when they're up later on
<flexiondotorg> dpm, Thanks. Guidance appreciated.
<dpm> np :)
<flexiondotorg> One of the apps I'm snapping is Mackup, which is a dotfile backup tool.
<flexiondotorg> The other is a static site generator.
<flexiondotorg> Some the 'home' plug is fine.
<flexiondotorg> Hmm, still not able to access files in my home directory :-(
<asac> dpm: nope ... thats sergiusens and one of beuno's folks now i think...
<asac> dpm: xkcd-webserer is mvo
<asac> the above was for webdm
<asac> i own(ed) hello-world with all its neat features :)
<asac> and go-example-serbserer
<asac> webserver
<asac> but that one i didnt rev for a while
<asac> and hello-world seems good to go
<dpm> asac, those two are actually fine, they work
<asac> i love hello-world.sh on desktop :)
<asac> shows you right away how you feel in the sandbox
<asac> hehe
 * asac just tried
<dholbach> how far are we with the images on cdimage.u.c? are all of them official, golden and working now?
<ogra_> dholbach, far from
<ogra_> the ones that mvo built had partially broken kernels ... i.e. the final arm kernels only landed wednesday evening ...
<ogra_> yesterday i was busy fixing the breakage the renaming of the kernel packages caused ...
<ogra_> the store is in a proper shape now but i havent re-built the images yet ... i'll put some up when i'm done generating and testing them
<dholbach> ok, THANKS
<dholbach> thanks
<dholbach> sorry, caps lock strikes again
<ogra_> heh
<dholbach> "big thanks" :)
<ppisati> $ sudo snap install blabla.snap
<ppisati> error: change finished in status "Hold" with no error message
 * ogra_ runs snap find blabla
<ppisati> how do i debug this?
<ogra_> ppisati, is that on an image or on desktop
<ppisati> ogra_: amd64 image, kvm, while installing a custom kernel
<ogra_> well, thats a zyga or mvo question i fear
<ppisati> if i recompile a 4.4 kernel with snapcraft, everything is fine now - it install fine and i can boot the img
<ogra_> (neither is around)
<ppisati> if i recompile an old kernel (3.14 in this case), i get this
<ogra_> cool !
<ogra_> (good to know the initrd works now)
<ppisati> in the 4.4 case, x86_64_defconfig + snappy options + sqaushfs with xz support: ok, working img
<ppisati> in the 3.14 case, i get that error
<ppisati> ogra_: yep, at least it boot now
<ppisati> the next step is to get a 3.14 minimal kernel to work
<ogra_> one of the biggest requests i had at embedded world was a proper realtime kernel ... i was wondering if we could provide a source tree with the required patches for people ...
<ogra_> (without building or officially supporting it indeed)
<ppisati> ogra_: once we get this stuff sorted out, i think we can talk about that
<ppisati> ogra_: what i would like to find, is a suite of tests to run again a series of kernels (3.14...4.4) to assess that everything is fine
<ogra_> yeah
<ogra_> well, a config checker would be nice ...
<ogra_> hooked into the kernel plugin
<ogra_> ppisati, did you try the --devmode option yet ?
<ogra_> snap install --devmode blabla.snap
<ppisati> ogra_: nope
<ogra_> perhaps that works around that
<ppisati> ogra_: but i didn't need that woth the 4.4
 * ppisati tries
<ppisati> same error
<ogra_> hmm
<ppisati> i'm using mvo's amd64 img, FWIW
<ppisati> http://people.canonical.com/~mvo/all-snaps/
<ppisati> the amd64 img there
<ogra_> yeah
<ogra_> yakkety !
<asac> hmm... what a mystery... bought a wifi dongle, plugged into rpi, shows up as wlan0, seems its a mac80211 driver we have in our kernel, can connect with wpa-psk ... so far so fine
<asac> but ... iw list does not show it
<asac> neither is there a phyX somewhere in sysfs :(\
<asac> on pi2
 * asac lost... on desktop it has a phy in sysfs and also is visible in iw list...
<asac> ppisati: any idea?
<ogra_> asac, did you simply try to create a file in /etc/network/interfaces.d and reboot ?
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/README works just fine on the dragonboard
<ppisati> asac: uhm, nope
<asac> ogra_: I CAN connect to wifi
<asac> its there was wlan0 etc.
<asac> it just has no phy :)
<ogra_> cant have everything :P
<asac> lol
<asac> no radio :)
<asac> magic
<ogra_> pfft, radio ... use spotify ... :P
<asac> pitti: any idea? is there udev magic involved to get ieee80211/phyX entries in sysfs?
 * ogra_ wonders who had the glorious idea to use xz for all images nowadays ... i'm really doubting the extra time it takes to cokmpress them actually pays off that much 
<ogra_> (gzip is only a few MB bigger but 20x as fast)
<pitti> asac: no, /sysfs (and most of /dev) is entirely managed by the kernel
<asac> right
<asac> pitti: so on my pi2 i have it as wlan0
<asac> on desktop where it has phy it is like the new long format
 * asac reboots and hopes for magic
<asac> ogra_: think for our squash it makes some sense... for the download artifacts i feel the same
<asac> ogra_: guess now we have two times xz? first xz the tar, then untar and squash again?
<asac> ppisati: who is our wifi expert? :) seth?
<asac> maybe i should try 4.4 kernel... still on 4.3
<asac> but this cant be such new feature
<ogra_> asac, no, i'm talking about img.xz actually ... the snaps are created directly with no tarballs involved
<asac> cool thats good news at least
<ogra_> (i actually need to turn off tarball creation in cdimage since we dont use them anymore ... they are still built in parallel)
<asac> so yeah, guess for our images with squash xz for core inside etc. it doesnt need xz
<asac> shouldnt be super big gain
<ogra_> well, i'Ãm currently producing them on my laptop (udf and trustys kpartx dont work well, so i cant use my desktop)
<ogra_> compressing one image takes around 12min ... 2-3 with gzip
<asac> ppisati: its the pi2 kernel for sure... tested on db and beagle and both get the /sys/class/ieee80211/phy* entry
<asac> unforuntatley its the 4.3 one still
<ogra_> thats broken
<ogra_> (seccomp bugs)
<asac> ogra_: can i get a 4.4 kernel for the old all snaps?
<asac> right
<asac> but not the 4.3
<asac> still its super weird
<asac> that the wlan0 interface works
<ogra_> i only uploaded to the 16 series
<asac> but no radio hardware is seen
<ogra_> snap refresh shoudl work if you are on one of these images
<asac> guess have to work on the beagle then for the time
<asac> fine
<ogra_> i'll push a new image up once they are built and i have at least boot tested them
<asac> ogra_: but 16 series images have no classic, or?
<ogra_> right
<asac> so yeah let me not go down that path :)
<ogra_> you need to use an ubuntu-core tarball and chroot for the moment
<asac> rather wait for stuff to settle
<ogra_> that might take some time though
<ogra_> and we wont update the rolling images anymore
<asac> sounds like its perfect to use that last image for work :) ... e.g. stable until the other side settles in
<asac> if the wifi only would work well on pi2 :P
 * asac moves classic files to beagle
<dz0ny_> heh http://mjg59.dreamwidth.org/42320.html
<dz0ny_> Circumventing Ubuntu Snap confinement
<ogra_> dz0ny_, yeah, known issue
<ogra_> (there was discussion to show a popup to make the user confirm, but that was considered to intrusive, not sure what the final outcvome was though)
<svij> ogra_: too bad, now it feels like, everyone is just repeating matthew garrets blog post, rather than the other improvements on snappy :/
<ogra_> well
<ogra_> he's not wrong though
<svij> I know
<svij> what happens if someone publishes his package to the store, does the automatic review tool recognise that? I think no?
<ogra_> you got to ask tyhicks or jdstrand
<popey> svij: snaps aren't currently automatically reviewed
<popey> so if he (or someone else) uploaded it, it wouldn't get to customer machines
<popey> (AIUI)  ð
<svij> ah, so someone checks them manually right now?
<sergiusens> dpm what's up?
<sergiusens> good morning!
<dpm> hey sergiusens, morning!
<dpm> sergiusens, so, webdm does not seem to be working, and I was suggesting to unpublish it from the store until it's fixed
<dpm> people are starting to install everything they see with 'snap find'
<dpm> and are getting confused at things not working
<dpm> same with xkcd-server
<dpm> but I think that one is for mvo when he's back
<simosx> A common question regarding snappy is whether more diskspace and memory will be used when you have installed several snaps.
<simosx> Is there a page that talks about this?
<ogra_> you mean because of the bundeling of libs ?
<ogra_> (i dont think there is a page)
<dpm> hi simosx, certainly more disk space, although we're looking at options to reduce this. Not sure why snaps should consume more memory, but I'm not an expert
<simosx> ogra_, yes, having extra copies for the libraries. Also, since the libraries are not shared libraries, there would be a few extra copies loaded in memory for the same library.
<ogra_> usually they are shared
<ogra_> snapcraft uses deb packages by default
<sergiusens> dpm check if it is still there
<sergiusens> took me some time to find it :-)
<ogra_> but they arent shared between snaps
<dpm> sergiusens, it's still there - did you unpublish it? Perhaps there is some delay until it's hidden
<simosx> I assume a stock answer would be "surely, more diskspace and somewhat more RAM is used. But in practice, the RAM issue is not so big"
<ogra_> right
<dpm> ogra_, do you happen to know why all the non-amd64 canonical-* gadgets appear in the output of 'snap find' on the desktop?
<ogra_> there will be ways that you can ship a library snap ... to be consumed by your own snaps ...
<simosx> It would be important to have some answer on this, preferably on a blog post.
<ogra_> dpm, no, but i'm ranting about that since a year :)
<ogra_> dpm, gadgets should simply be hidden ... or only visible via some option to find ... like --type=gadget or so
<dpm> ok, I pinged Martin about it, see if he can shed some light into it. At the very least, I think they should not appear listed in foreign architectures
<ogra_> dpm, there are no foreign arches ... gadgets are arch all ;)
<dpm> oh, that explains it then :)
<ogra_> that is why i think we need to filter by type instead :)
<kyrofa> Good morning
<sergiusens> dpm Status Unpublished
<sergiusens> dpm btw, super close to get a build of vscode working; I just need to pull in electron
<sergiusens> all using just the nodejs plugin (I did however had to export envvarts)
<dpm> sergiusens, ah, awesome. Have you had some thoughts about how to deal with electron apps?
<sergiusens> dpm apparently you just need to gulp it
<sergiusens> was going to ask stevebiscuit or beowulf what the nicest way to do that would be
<dpm> I'm not familiar with gulp, other than having heard the name
<flexiondotorg> Hmm.
<flexiondotorg> I'm confused.
<flexiondotorg> I have made 3 Python snaps.
<flexiondotorg> None are able to read anything in my home directory.
<ogra_> hwo would they
<dpm> flexiondotorg, do they use the 'home' plug, and did you connect it manually?
<flexiondotorg> http://paste.ubuntu.com/15980091/
<ogra_> they are confined
<flexiondotorg> dpm, See one example.
<ogra_> right, you need to connect the plug
<ogra_> after install
<flexiondotorg> Is there anything obviously wrong there?
<flexiondotorg> Connect to the plug?
<flexiondotorg> In the yaml?
<ogra_> no, using the snap command
<dpm> flexiondotorg, did you check out the link I sent you earlier on? https://developer.ubuntu.com/en/desktop/examples/#snap-python
<dpm> it shows you how to do the manual connection
<flexiondotorg> dpm, Ahh.
<dpm> :)
<flexiondotorg> So those plugins are not automatically exposed.
<flexiondotorg> *plugs
<dpm> flexiondotorg, going forward, there have been some talks of doing the prompt more interactive, but for now, you'll need to manually connect
<ogra_> they are exposed, but not automatically interconnected
<flexiondotorg> Right, got it.
<flexiondotorg> Once the plugs are connected to they persist across boots?
<popey> dpm: do you detect arch triplet in any of your snaps, or hard wire it for amd64?
<sergiusens> dpm I might need to run a "re index" not sure; last time I did that I broke the store. I'll jut delegate to matiasb, nessita or beuno
<dpm> popey, I'm glad you ask :) -> askubuntu.com/questions/757668/how-to-build-multi-arch-snaps
<ogra_> popey, do you want to build a 600MB calculator multi snap ?
<popey> haha
<ogra_> (though for all arches that might become 1GB)
<dpm> ogra_, too late for that!
 * popey considers a 1.2GB DocViewer
<ogra_> (since we now also support s390x and ppc64el)
<ogra_> really ... dont do multi snaps
<sergiusens> popey I would create a snap call coreapps with all the apps in there ;-)
<dpm> popey, for clock and calculator, I built separate snaps for each arch.
<ogra_> (multiple snaps with same name for different arch is fully supported)
<sergiusens> popey you would save lots of space by having all of them in
<popey> sergiusens: I'll put kvm and an iso in one containing all the core apps :Ã¾
<dpm> but for some reason the x86 fail to start
<popey> pffft i386 is dead to me
<popey> except for this 10 year old Thinkpad T43 on my desk :)
<popey> thanks for the snippet dpm
<dpm> sergiusens, so https://github.com/sergiusens/qt5conf works well for binary Qt5 apps, but is there a way to specify a different launch command, for QML apps, for example? Up until now, I've exec'd them so in the wrapper file:
<dpm> cd $SNAP
<dpm> exec $SNAP/usr/bin/qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
<dpm> nw popey
<flexiondotorg> Hmmm, I'm unable to connect to the home plug using this snap - http://paste.ubuntu.com/15980091/
<flexiondotorg> I have multiple executables in that snap. I can't find a namespace the the home plug with connect to.
<flexiondotorg> But the network plug appears to be connected to the podpublish namespace.
<dpm> flexiondotorg, what does 'snap' interfaces show you?
<dpm> sorry, `snap interfaces`
<jdstrand> svij: no. the automated review tool cannot discover a malicous app wrt mjg's post
<flexiondotorg> dpm, This http://paste.ubuntu.com/15980231/
<flexiondotorg> Last line looks odd.
<dpm> flexiondotorg, it tells your app's plug you it's not connected to the ubuntu-core:home slot
<dpm> flexiondotorg, and `sudo snap connect podpublish:home ubuntu-core:home` does not work for you?
<flexiondotorg> Right, sec. Will report back...
<flexiondotorg> Just building the snap...
<svij> jdstrand: ah okay
<jdstrand> as of today because applications use X you have to trust the application
<jdstrand> that was always understood to be the case
<flexiondotorg> dpm, OK, progress.
<flexiondotorg> But not quite working.
<dpm> flexiondotorg, something that helps when debugging is looking at /var/log/kern.log to watch for AppArmor denials
<flexiondotorg> http://paste.ubuntu.com/15980333/
<flexiondotorg> dpm, So running the executable works and can parse the configuration file. So can access my home directory.
<dpm> good
<flexiondotorg> But then the path of the files in the configuration are being passed back in a different hierarchy.
<dpm> so did you forget to ship that file, or is there some path that needs to be readjusted?
<flexiondotorg> http://paste.ubuntu.com/15980333/
<flexiondotorg> ERROR! /home/martin/snap/podpublish/100001/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg was not found. Abort.
<flexiondotorg> The file path configured in the .ini file is /home/martin/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg
<flexiondotorg> And it exists.
<dpm> it seems to me that the python app is making that path relative to where it's launched from?
<flexiondotorg> It doesn't.
<flexiondotorg> It does expand the user home directory.
<ogra_> you might need to generate the ini file from a wrapper then
<flexiondotorg> In fact it doesn't do that.
<dpm> right, but it seems that on doing expansion, it adds "snap/podpublish/100001 [...]" as a relative path to construct the final path
<dpm> just guessing, I don't know the code
<flexiondotorg> It just takes the configuration entry.
<flexiondotorg> featured_image=~/Dropbox/UbuntuPodcast/Backdrops/S09E07.jpg
<flexiondotorg> Which is that ^
<dpm> jdstrand, how does HOME get set within a snap? ^
<ogra_> HOME=/home/ubuntu/snap/hello-world/25
<dpm> $ hello-world.env | grep HOME
<dpm> HOME=/home/dpm/snap/hello-world/23
<ogra_> the prob might be that bash overrides that when expanding  ~
<kyrofa> dpm it's in the binary wrapper or service file
<ogra_> try using $HOME in the config
<flexiondotorg> This is in the wrapper
<flexiondotorg> export HOME="$SNAP_USER_DATA
<ogra_> right
<ogra_> but you use ~
<flexiondotorg> Yep.
<ogra_> which could be auto-expanded by the calling shell
<flexiondotorg> Because it is defined in an .ini file.
<flexiondotorg> Which I don't think would be an uncommon expecation?
<ogra_> dunno
 * ogra_ would try using $HOME in the ini first ... 
<ogra_> and if that doesnt work, instead generate the ini on first startup instead
<ogra_> -instead
<flexiondotorg> ConfigObj doesn't expand environment variables.
<flexiondotorg> The ini file is human created.
<ogra_> yes, so make it script created instead ... for the initial file
<ogra_> then you can use the vars
<flexiondotorg> ogra_, I don't follow.
<flexiondotorg> Make what a script?
<ogra_> call a script from the wrapper that checks if there is an init file already .... if there isnt, generate one using the SNAP vars
<ogra_> *ini
<ogra_> ppisati, hmpf ... testing the i386 image here i get eth0 on first boot and ens3 on all subsequent ones ... (which makes me end up with an eth0 config that indeed doesnt work after reboot)
<ogra_> hmm, same with amd64
<ogra_> i dont get why it changes names
<ogra_> pitti, ^^^ any idea ?
<ogra_> (we usually set net.ifnames=0 and should probably do that for x86 arches too ... but still it shouldnt change its name after first boot)
<sergiusens> stevebiscuit you should ask fgimenez for help wrt to tarmac ;-)
<stevebiscuit> sergiusens: I was wondering who to bother! the laptop was nearly being thrown out the window
<kyrofa> stevebiscuit, haha
<stevebiscuit> sergiusens: I'm only acting the part of a front-end developer btw... compiling all the JS assets would be the thing to do and there's no end of ways of doing that. copying the gulfile from webdm would certainly get you going along that path
<fgimenez> hey stevebiscuit :) what's the problem?
<stevebiscuit> fgimenez: hello! the machine building https://code.launchpad.net/~stevenwilkin/webdm/add-remove-snaps-via-api/+merge/288437 seems to have run out of disk space
<ppisati> ogra_: yep, i noticed the name change too
<ppisati> ogra_: but at least it's consistent here
<ppisati> i always get ens3
<ogra_> yeah, i just dont get why it changes
<ogra_> only from the second boot on
<ogra_> on first boot i see eth0
<fgimenez> stevebiscuit, mmm seems to have enough space http://paste.ubuntu.com/15980970/, let me try merging again
<stevebiscuit> fgimenez: cool, hopefully the thing actually builds heh
<Elleo> quick question, can you upload snaps using the reserved permissions (like "x11" or "unity7") to the store? do they require manual approval? was just wondering if that should be mentioned in this sort of discussion: https://www.reddit.com/r/linux/comments/4fwfch/circumventing_ubuntu_snap_confinement/
<sborovkov> Hi. Does this syntax still work? snap isntall snap.name config.yaml
<ogra_> sborovkov, no
<ogra_> sborovkov, the config interface is gone (temporary)
<sborovkov> ogra_: Oh, ok, and here I was wondering why my snap's not working after this properly :-)
<ogra_> yeah, its a bit painful ...
<sborovkov> How temporary is that? Should I consider changing how it's working on my side?
<ogra_> all foxcus was on brining snappy to the desktop for the last weeks ... things like config will come back soon
<ogra_> it is high on the TODO afaik
<flexiondotorg> ogra_, dpm http://paste.ubuntu.com/15981191/
<flexiondotorg> I've create python test case, see above.
<ogra_> yeah, so do what i asid ... generate the ini on first start
<ogra_> then you get proper paths
<ogra_> *said
<flexiondotorg> ogra_, You're missing the point.
<ogra_> am i ?
<ogra_> your app can only see /home/martin/snap/home-tester/100001
<ogra_> so your ini needs to point to that
<flexiondotorg> Python code the tries to reference the home directory either via $HOME or os.path.expanduser() result is being given a directory path that is not the home directory.
<seb128> ideally things would work out of the box without requesting every app to writer wrappers when they can to use the standard userdir
<flexiondotorg> And is in fact, empty.
<ogra_> to get the right value in a multi user system you can only grab it on first start
<ogra_> your app runs inside /home/martin/snap/home-tester/100001 by default
<flexiondotorg> But that is not my home directory.
<ogra_> (if the binary supports it you could also use relative paths)
<ogra_> bno, it is the home dir of the snap when it gets started
<ogra_> this is part of app confinement
<flexiondotorg> So I am not able to actually access my home directory using snaps unles I create the snap completely unconfined?
<ogra_> not sure how the home plug actually works ... but the snap subdir was a constraint we had before that
<ogra_> i'd be surprised if the interface gives you full access to all of home
<ogra_> you have to ask zyga or niemeyer though
<pitti> ogra_: can you check /proc/cmdline if it still actually has net.ifnames? if you set it on first boot, you indeed need to set it on others too, or disable that udev rule
<ogra_> pitti, no, x86 doesnt ... so a weird name is expected ... but i dont expect it to change between two reboots
<ogra_> (i.e. we end up with /etc/network/interfaces.d/eth0 on first boot and an eth0 interface being up ... after reboot there is only ens3)
<niemeyer> flexiondotorg, ogra: The home interface allows access to files in the user's home which are not hidden (.*).
<flexiondotorg> niemeyer, Yes, it does.
<ogra_> niemeyer, but when ui start a snappy app its home points to ~/snap/app-name/100001
<flexiondotorg> I can point my python, which is snapped, at a file in my home directory and the file is read.
<flexiondotorg> Good :-)
<flexiondotorg> However, if my file is a configuration file that then want to reference other files in my home directory.
<ogra_> niemeyer, so apps that use ~/ in a config file get that expanded to  ~/snap/app-name/100001 instead of just ~/
<flexiondotorg> The path expansion is to ~/snap/app/#ref#
<niemeyer> ogra_: This dir is always available, even without the interface, and it's where the app should store its own data and control files
<flexiondotorg> niemeyer, Which is fine.
<niemeyer> The home interface is supposed to be used by apps that actually want interaction with user content
<niemeyer> Downloads, pictures, etc
<flexiondotorg> But using  os.path.expanduser() in a snapp Python application doesn't evaluate to /home/me it evaluates to /home/me/snap/app/#ref#
<niemeyer> We'll definitely make this more fine grained, but for now that's how we bootatrapped
<ogra_> niemeyer, but a commandline app that uses ~/myapp/config.conf ... will not look in /home/user/myapp/ for config.conf
<ogra_> because the ~/ expands to the snap subdir
<niemeyer> flexiondotorg: That's a good thing because it makes things just work for a lot of apps that want to write on the user's home just to store its own data
<asac> ogra_: was the store for rolling killed too?
<flexiondotorg> But also breaks lots of others.
<ogra_> niemeyer, but it means you need to patch all apps that use ~/ somehow
<niemeyer> Well, not really.. Most things don't break because they find $HOME elsewhere
<flexiondotorg> I just happen to have picked 3 applications to snap that simply can't be snapped :-(
<niemeyer> Note that there's really no perfect answer here..
<ogra_> well, they could with a wrapper ... :)
<niemeyer> flexiondotorg: Why?
<flexiondotorg> A podcast encoder and uploader. Since all the assets exist outside the snap directory.
<ogra_> as i said ... generate it on first start of the app and everything will have the right paths
<flexiondotorg> A static site generator.
<niemeyer> And what's the problem with that?
<flexiondotorg> A dotfile/dotdir backup utility.
<niemeyer> Just access the assets wherever they are?
<flexiondotorg> Those applications have established workflow.
<sergiusens> ogra_ `home` interface give access to all unhidden files in $HOME (or should); I'm not sure setting $HOME to $SNAP_USER_DATA is the right thing
<niemeyer> flexiondotorg: dot files are restricted for now..
<ogra_> niemeyer, the app has "my_work_dir=~/foo-bar" ... the snap turns that into /home/me/snap/app/#ref# at runtime and doesnt find its config
<flexiondotorg> niemeyer, Yeah. Get that. Understand why. So no issue.
<niemeyer> ogra_: That's a bit strange.. I don't use any applications that restrict their use to a particular part within $HOME
<ogra_> niemeyer, http://paste.ubuntu.com/15981191/ thats a test app that flexiondotorg did
<sborovkov> Is home app for snap persistent? Or will it get created again when snap's version  is changed?
<ogra_> if you now have a config file that expects ~/app.conf ... it woint look in your home but in the snap subdir
<niemeyer> Yes, and that's exaclty one of the reasons we did it
<niemeyer> Most likely it won't be in ~/foo.conf, but in ~/.foo.conf, which should be inside /snap/1
<niemeyer> sborvkov: you mean the dir?
<sborovkov> niemeyer: yes.
<sborovkov> Does it have persistent data? I mean after I update snap
<sborovkov> to newer version
<niemeyer> Yeah
<ogra_> niemeyer, right, but it means that the majority of apps needs a wrapper to mangle the config at runtime or to have a different config patched in at build time
<sborovkov> ok, got it
<oobartez> hi all, where can i find a list of all desktop apps available as snaps? Sth like the deb repo browsers, ideally online
<niemeyer> sborovkov: It's currently copied over so rollbacks are possible, but we'll likely change how that happens soon.. In either case you can trust it to persist data in there across updates
<ogra_> oobartez, you can call "snap find" on a xenial desktop
<niemeyer> ogra_: Or they need to do what they always did and write in $HOME
<ogra_> oobartez, but there isnt much yet (go on, produce some !!!)
<ogra_> niemeyer, but home isnt home :)
<niemeyer> Some will need to be changed to be optimal, for sure
<ogra_> (home isnt the home upstream expects that is)
<niemeyer> ogra_: Yep, and for reasons.. We'll learn whether that's a great idea or not over time, but if we change we'll be breaking other use cases..
<niemeyer> So no golden answer, as usual in life :)
<ogra_> yeah
<ogra_> well, my personal golden answer is a first start wrapper that simply knows the vars ... but that needs to be written indeed ...
<ogra_> (when you port an app)
<oobartez> ogra_: this is what I was thinking ;) just kinda want to figure out what types of apps are already converted, and which ones it'd be best to focus on
 * ogra_ now wonders what to do with the 16.04 images ... while the amr arches are rather fine, x86 falls apart on second boot :(
<ogra_> *arm
<ogra_> i guess i'll wait til monday and sort that with mvo rather than pushing out broken stuff
<sergiusens> niemeyer ogra_ when using the `home` interface we should probably change where HOME points to (well someone needs to analyze, but as a first thought seems good).
<ogra_> yeah
<ogra_> thats kind of what the interface implies :) access to home ... inetad of home/snaps/
<jdstrand> dpm: sorry, I was responding to some other issues
<dpm> jdstrand, no worries, we've already found that, so 'unping' :-)
<dpm> *figured it out, I meant
<jdstrand> dpm: do you still need the question answered regarding HOME? (it is via the script in /snap/bin/...)
<jdstrand> ok
<dpm> all good, thanks
<fgimenez> stevebiscuit, should be fixed now, btw lots of interesting stuff in there! :) reminds me of old times, phatomjs, karma, lodash sigh..
<dpm> Elleo, I'm not sure if you got your question answered, but I don't think either 'x11' or 'unity7' trigger a manual review. But I think one can double-check that on https://launchpad.net/click-reviewers-tools, which is the same code the store runs
<dpm> jdstrand, sorry for the many pings today, but perhaps you can answer that one with more authority ^
<ogra_> perhaps you should write the list you mailed to the ML as a blogpost :)
<Elleo> dpm: ah, okay; so not really an answer to the x11 criticisms then
<jdstrand> they do not trigger a manual review
<jdstrand> because that wouldn't help anything (the review would be looking at binaries)
<jdstrand> ogra_: pass
<jdstrand> :)
<Elleo> jdstrand: is there any warning given to users installing apps with x11/unity7 permissions, maybe that'd be at least a reasonable compromise?
<jdstrand> people are discussing the messaging
<jdstrand> Elleo: not at this time
<ogra_> hehe
<sergiusens> jdstrand there is no way out of this, right http://pastebin.ubuntu.com/15982675/ ?
<sergiusens> jdstrand in the sense that I'll need to patch the code or anything that wants to use QNetworkManager ?
<jdstrand> the answer to that is connectivity-api
<jdstrand> or let people talk to network-manager and live with the info leak
<sergiusens> jdstrand yeah, I figured; so I need to change the code :-)
<sergiusens> well first figure it out ;-)
<jdstrand> it is hard to take a firm line on the network-manager info leak with GetAll when we are allowing x11
<oobartez> is there some place where I could find fairly up-to-date statistics of most downloaded packages from the official ubuntu repos?
<oobartez> *desktop
<dpm> sergiusens, not sure if you saw the question earlier - so https://github.com/sergiusens/qt5conf works well for binary Qt5 apps, but is there a way to specify a different launch command, for QML apps, for example? Up until now, I've exec'd them so in the wrapper file:
<dpm>  cd $SNAP
<dpm>  exec $SNAP/usr/bin/qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml
<dz0ny_> it's getting better zdnet: "Ubuntu 16.04's new Snap format is a security risk"
<dz0ny_> the gist seems to be that caveat that it is more secure than apt
<dz0ny_> and "news" organizations have picked that...
<sergiusens> dpm so doesn't `command: qt5-launch qmlscene $SNAP/usr/share/ubuntu-clock-app/ubuntu-clock-app.qml` should work
<sergiusens> jdstrand it does ;-)
<dougb_> Can anyone offer me some guidance on how to enable the available serial ports on a BeagleBone Snappy?
<qengho> dougb_: enable how? To make character devices that could work, or to talk through them from inside a Snap package?
<geneios> Does anyone have any resources for using snappy with a python 2.7 project?
<kyrofa> geneios, you mean like this? https://github.com/ubuntu-core/snapcraft/tree/master/examples/py2-project
<geneios> That is helpful, I was looking at that earlier. This page here https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/ mentions embedding a Python runtime. I guess I was looking for a "Your First Snap" page using python.
<kyrofa> geneios, yeah anything that uses the python2 plugin will embed the python2 runtime
<kyrofa> geneios, so you should be able to morph that example into what you need
<dz0ny_> kyrofa: source: https://github.com/markokr/spongeshaker.git#rev supported in snapcraft
<kyrofa> dz0ny_, are you asking me a question? :P
<geneios> kyrofa, thanks so much! I am going to give it a try and see what happens.
<kyrofa> geneios, no problem-- we're here if you need some help :)
<flexiondotorg> ogra_, dpm, niemeyer Just finished work and read the backlog.
<kyrofa> Hey jdstrand, just to clarify: that systray example worked for you with no devmode?
<flexiondotorg> What if the 'home' plug was really /home/user and a 'data' or 'snapdata' plug were added to provide the current behaviour?
<jdstrand> kyrofa: it launched, I saw an icon in the launcher (surely just from the desktop file), I clicked stuff and I say notification bubbles. I don't know if it was supposed to do other stuff
<jdstrand> s/I say/I saw/
<flexiondotorg> Perhaps 'home' with access /home/user should have manual review.
<kyrofa> jdstrand, there wasn't a desktop file included there, but yeah you saw the right stuff... but I only saw it with devmode. Maybe I'm out of date?
<flexiondotorg> Where as really confined 'data' apps do not.
<kyrofa> (checking now)
<jdstrand> kyrofa: I saw a heart in the launcher...
<kyrofa> jdstrand, oh, the launcher-- how about in the indicators?
<jdstrand> I didn't see anything in the indicators
<kyrofa> jdstrand, ah, you're supposed to. Try devmode then?
<jdstrand> but the one dbus denial wasn't a Unity 7 denial
<jdstrand> it was some kde dbus denial
<jdstrand> kyrofa: can you add to the bug more information-- what I'm supposed to see, how I am supposed to see it and any denials?
<kyrofa> jdstrand, huh. I'm no indicator expert either, I just _believe_ it's dbus :P . And since it didn't work without devmode I figured it was a unity7 interface issue
<kyrofa> jdstrand, yeah I'll try to flesh that out a bit more
<kyrofa> jdstrand, also, the indicators-- were they the nice pretty libnotify indicators, or the ugly yellow ones?
<kyrofa> Not indicators sorry-- notifications
<kyrofa> Because those didn't work without devmode either
<jdstrand> kyrofa: the notification bubble was ugly
<kyrofa> jdstrand, alright I'll put some links to screenshots in there
<jdstrand> thanks!
<kyrofa> Anyone else having trouble making their fingers stop after typing "apt" ?
<sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/484 has conflicts for some reason
<niemeyer_> http://blog.labix.org/2016/04/22/snappy-interfaces
<roadmr> so, snap install $something fails inside a xenial lxd container, even with nesting and privileged set to true :/ is it desirable to be able to install snaps inside containers?
<kyrofa> jdstrand, updated description
<dougb_> qengho We have a serial application running on the BBB. We are now using the console port. We want to use one of the other available serial ports, but don't know how to enable them in Snappy Ubuntu.
<dpm> niemeyer -> https://plus.google.com/u/2/b/100887841569748798697/+Ubuntu/posts/hUKMDYE9bR9
<niemeyer_> dpm: Thanks!
<qengho> dougb_: the kernel has to support it. I think you'll get far examining "dmesg" and "lsmod" and comparing to BBB that work for you.
<guest1221> Does anyone know if there was a Snappy 16.04 image for IoT devices released yet?
<ogra_> not yet
<ogra_> the first alpha will likely come out next week
<guest1221> Perfect, thanks!
<ogra_> there are some experimental image sif you feel brave :)
<ogra_> *images if
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<guest1221> I don't think our code is ready for that yet, but that will help us prepare for the coming changes.  Thanks a lot!
<mcphail> stgraber: is it possible to run snappy  within lxc/d yet?
<tsimonq2> my bet is yes
#snappy 2016-04-23
<mcphail> On 16.04 desktop, can snaps only be installed locally (using "snap install blah") rather than from the store (using "snappy install blah")?
 * mcphail wants a neat way to install kyrofa's owncloud snap
<thomas25> Hi
<thomas25> I download a snappy image from here http://people.canonical.com/~mvo/all-snaps/
<thomas25> But i'm a little stuck then.
<thomas25> I would like to clone snapcraft repo
<thomas25> However I need git
<thomas25> Since I can't use apt-get install and "snap find" has a limited number of snaps I'm not sure how I can do anything.
<thomas25> maybe i missed something ?
<oparoz> thomas25, see if you can enable classic mode
<oparoz> that gives you a shell with access to standard tools
<thomas25> So today I can't have a minimum ubuntu core 'working' ?
<thomas25> With read only partition and no use of apt-get.
<ali1234> thomas25: such a thing wouldn't make any sense... how you going to use git when it is sandboxed?
<ali1234> classic mode exists specifically for doing development because you can't do development when each of your tools is in it's own sandbox
<ali1234> i could be wrong but i think classic mode is more or less just a snap that has everything (via apt) inside one sandbox
<thomas25> ali1234: That makes sense ^^. Thank you
<thomas25> How do you enter classic mode ?
<thomas25> I'm not sure my image give me that possibility.
<ali1234> not sure
<oparoz> snappy enable-classic
<ali1234> let me read my logs
<oparoz> if that still works, then you can do snappy shell classic
<thomas25> No binary "snappy" only "snap" on my image, and no such option as described here https://github.com/ubuntu-core/snappy-dev-website/blob/master/src/versioned/guides-and-reference/release/build-apps/setup.md
<oparoz> try with snap then?
<oparoz> It's been renamed
<ali1234> looks like the old classic mode was removed
<ali1234> will be replaced by an actual snap one day?
<thomas25> So for now, no "developer mode" ?
<ali1234> yeah looks like it
<ali1234> seems like classic-mode wasn't actually a snap, it used most of the same tech but could not be updated like one
<oparoz> Well it depends, if it's for a personal project, you can use older images
<ali1234> so i guess they want to turn it into a proper snap
<oparoz> the images in the obsolete folder still have classic
<thomas25> oparoz: Yeah it is just to understand and discover snappy.
<thomas25> oparoz: ok thanks, i'll try it then.
<oparoz> thomas25, use the old images then, but other things have also changed, such as how to set up policies
<ali1234> the older images have different problems though
<thomas25> Do you know if an alpha release or something is planned ?
<ali1234> i dont see anything on the mailing list about it
<oparoz> They're hard at work trying to release something, yes
<oparoz> Best to come during business hours to get some answers I think
<thomas25> yeah probably ^^
<thomas25> I will see next week. Thanks for the replies.
<oparoz> ð
<thomas25> An other question, how the configuration file are handled ?
<thomas25> If it is in the snap it would be read only.
<thomas25> So how to modify it ?
<thomas25> I heard about hard link however I tried the "mosquitto" snap present in the snapcraft repository, but it seems there are no writable file available for "mosquitto.conf".
<ovalseven8> Hello - heard of the new "Snap package". Which packages are available? Is there an official Ubuntu repository?
<thomas25> If you just want to test the snap packages, you should try the ubuntu 16.04 lts but there are not a lot of packages by default however.
<thomas25> But you can build some with snapcraft.
<ovalseven8> thomas25: Yes. My question is - which packages can you install by default? Will there come new packages or how does it work
<ovalseven8> If I create a snap for a software, how can I make it that normal people can install it on 16.04?
<thomas25> Using "snap find" you have 14 snaps available
<thomas25> Like "ubuntu-clock-app"
<ovalseven8> thomas25: Yes, but how can I add new snap software?
<thomas25> There is a store where you can probably find more package (you need authentication)
<thomas25> But not sure , I never tried
<thomas25> But I don't know when more package will be added to the 'default' ones
<thomas25> See https://github.com/ubuntu-core/snapcraft/tree/master/examples
<thomas25> You can build snap using these examples
<thomas25> It is very easy
<thomas25> Just run "snapcraft" in "webchat" for example
<thomas25> Then "snap install" will do the job.
<ovalseven8> thomas25: I am just curious how the distribution of snap software will work
<ovalseven8> Who decides which snap apps will be available by default and so on
<thomas25> If your asking if canonical will check every snap I don't know.
<thomas25> Since it is "contained" I don't think so
<thomas25> But I really don't know.
<ovalseven8> thomas25: I see, thanks anyway!
<thomas25> Come asking again Monday you will probably have more and better answers
<daker> ovalseven8: a snap is checked via automated checks once you upload it to the store
<ovalseven8> daker: Do you have a link to the store?
<daker> some checks needs manuals checking
<daker> https://myapps.developer.ubuntu.com/
<ovalseven8> daker: And everybody with 16.04 installed will have access to the uploaded packages?
<daker> ovalseven8: yes
<daker> approved packages
<thomas25> daker: Do you know what kind of tests are performed ?
<daker> thomas25: https://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/files/head:/clickreviews/
<thomas25> daker: Thanks
<thomas25> daker: Do you know how configuration files are handled ?
<ovalseven8> What about snap security? Is there an automatic check if they are signed or how will be checked that everything that is downloaded (for example github) is ok?
<daker> ovalseven8: i guess snappy takes care of that
<daker> ovalseven8: https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go#L53
<ovalseven8> daker: Mh, I don't really understand
<daker> the store provides the checksum of the snap you uploaded, then snappy performs a checksum of the downloaded snap somewhere in the code to compare if nothing happened
<ovalseven8> daker: But I don't see the point. If I can manipulate the download, I can also manipulate the checksum check, no?
<daker> ovalseven8: maybe try to make a POC for that :)
<ovalseven8> Snap packages seems to be interesting. But I guess I will deal with it when more time is passed and I have more time
<ovalseven8> It will be very time consuming if you deal with it the very first time, I guess
<ovalseven8> Additionally, there will be more documentation in the future, I hope. At the moment, there is not too much info
<ogra_> As long as you use snapcraft, the lerning curve is pretty low imho
<ovalseven8> ogra_: There is only snapcraft?
<ogra_> That is what you should use, yeah
<ogra_> Packaging means to create a single yaml file once... The rest is done fully automatic
<ovalseven8> ogra_: The .snap package contains the binary, right?
<ogra_> A snap package is a readonly squashfs file that contains all binaries of your project, yes
<daker> ogra_: hi, did you have chance to work on the wifi firmware for the rpi ?
<ovalseven8> ogra_: So, everythign will be statically linked, right?
<ogra_> daker, nope, had to do some disaster recovery on release day
<ogra_> ovalsend, no, why would it ?
<daker> ogra_: it doesn't work on the rpi3 too ?
<ogra_> you indeed *can* statically link if you feel like... Up to you... by defaukt snapcraft just pulls deb packages from the archive for the defined dependencies.
<ogra_> (and puts them inside your snap)
<ovalseven8> ogra_: I don't understand the concept completely yet, sorry
<ogra_> daker too ?
<daker> i mean the wifi :)
<ogra_> there is no wifi on the pi2 ;)
<ogra_> the pi3 firmware will be added with an SRU and eventually end up in the kernel snap
<daker> ogra_: i use the wifi dongle but it's didn't managed to get it detected
<daker> a*
<daker> i see you were talking about the pi3 when speaking about the firmware
<ogra_> Well, we install the normal linux-firmware package
<ogra_> and the sub drivers should all be enabled
<ogra_> usb
<daker> the same wifi dongle works with raspibian and other distros
<ogra_> I.e. it should not work any different from any Ubuntu desktop install
<ogra_> if it works on desktop but not on the pi2 thats a snappy bug indeed, else just an Ubuntu one..
<daker> it works on Ubuntu
<ogra_> Well, then file a bug please
<ogra_> (I know that raspbian patches a lot of non free ralink stuff into their kernel, so thats not really a metric)
<ogra_> ... but if it works on desktop thats clearly a bug
<daker> Bus 002 Device 004: ID 148f:2070 Ralink Technology, Corp. RT2070 Wireless Adapter
<ogra_> and you are sure that works on desktop ?
<ogra_> (the ralink statically devices are definitely shaky without the driver from the ralink site)
<ogra_> s/statically/sta/
<ogra_> (silly autocompletion on the tablet)
<daker> ogra_: well it gets the wifi networks
<daker> well it works
<daker> it connects to the wifi but i am seeing timeouts
<daker> ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
<ovalseven8> Hi again. Question: A statically linked .snap package makes sense but I don't see a reason for dynamically linked binaries
<ovalseven8> The advantage of dynamic linking is less disk space. But because snap distributes every single dependency, this is not an advantage anymore
<ogra_> daker, yeah thats what I mean, the in-kernel driver usually isn't stable
<ovalseven8> Can someone explain me, please?
<mcphail> ovalseven8: it is usually easier to create dynamically linked apps, particularly if you're just pulling pre-built dependencies
<ogra_> you can use statically linked libs if you feel like
<ogra_> but as daker said... It is easier to just use existing binaries
<ogra_> err... *as mcphail said... Sorry
<daker> :D
<ovalseven8> Which dependencies have I add to? Even packages that are installed on Ubuntu by default?
<ogra_> Whatever your binary needs
<ovalseven8> And if a dependency will change (security update), will I have to upload the new .snap package?
 * ogra_ would suggest to just install snapcraft and the snapcraft-examples packages and play with the examples
<ogra_> yes
<ovalseven8> Oh my god. So, a program with Qt5 and such dependencies will need an update very often
<ogra_> as often as the packages in the archive get security updates
<ogra_> for qt thats probably rather rare
<ogra_> (and if your app is confined some security issues are actually irrelevant, really depends what issues get fixed
<ogra_> )
<ogra_> (and how your app is run)
<ali1234> ogra_: what's the deal with classic mode on 16.04? is it planned to convert it into a normal snap?
<ogra_> I don't think so
<ali1234> so it's just gone forever?
<ogra_> nah
<ovalseven8> I mean, creating a .snap for a big gui desktop application will be very complicated
<ogra_> only temporary... Like snap config
<ali1234> why can't it be implemented as a normal snap btw?
<ogra_> ovalseven8, well, fir fox will most likely switch completely to snap
<ogra_> *firefox
<ogra_> ali1234, because yo want everything o be rw
<ali1234> okay but snaps must support rw to some extent. like what if i make a ftp server where people can upload things... you want that to be rw too
<ogra_> The point of classic is to have a rw playground for apt... shipping that as ro squashfs makes no sense
<ovalseven8> Unfortunately, the examples for snapcraft on GitHub are just very easy programs :/
<ali1234> it would make more sense on a filesystem that supports snapshots
<ali1234> hmm SNAPshots
<ogra_> snaps have a rw dir... Installing an apt chroot/container would mean to copy the whole ro snap into the rw dir
<ogra_> that would be totally wasteful
<ogra_> what we really only want is to have the container ship the bits we removed...as rw overlay
<ali1234> yes.. overlay filesystem backed by a ro snapshot
<ogra_> not over rlay fs
<ovalseven8> The snapcraft docs are poor at the moment
<ali1234> no, overlayfs sucks
<ali1234> but maybe btrfs
<ogra_> Nah
<ali1234> zfs?
<thomas25> probably
<ogra_> btrfs sucks even most more :p
<ogra_> -most
<ogra_> silly autocomplete
<ogra_> zfs on embedded ?
<ali1234> sure why not
<thomas25> Canonical is targeting "big" embedded device
<ali1234> embedded is meaningless when you talk about running ubuntu on it, it's already many times bigger than a real embedded system
<ogra_> dunno, I wouldn't want to give half my ram to a feature that I can also get cheaper in other ways
<ogra_> snappy is focused on embedded
<ogra_> it is designed for it
<daker> ogra_: Sagem XG-76NA 802.11bg doesn't work on snappy :/
<ogra_> daker but on desktop ?
<ovalseven8> Am I right that I have to add parts step by step in snapcraft? So, compile part1 that is needed for part2 and so on?
<thomas25> About zfs/ubuntu http://news.softpedia.com/news/canonical-is-delighted-to-collaborate-with-nexenta-on-optimizing-zfs-for-ubuntu-502806.shtml
<daker> it works
<ogra_> daker, file bugs :)
<daker> ogra_: against what ?
<ogra_> ovalseven8 NT necessarily
<ogra_> not
<ogra_> daker see topic ;)
<daker> ok
<ogra_> feel free to assign to me, I'll get it in the right hands then
<ogra_> (if you can)
<ogra_> ovalseven8, if you need an order you can define one, but I guests the majority of snaps don't need it
<ogra_> guess
<daker> ogra_: i can't assign it (bug 1574075)
<ubottu> bug 1574075 in Snappy "Snappy does not detect Sagem wifi dongle" [Undecided,New] https://launchpad.net/bugs/1574075
<ogra_> Thanks
<ali1234> so how do i get started with snappy 2.0?
<ogra_> easiest is to have a denial desktop install ;)
<ogra_> xenial
<ali1234> my app only runs on raspberry pi
<ogra_> then you can grab an experimental image from mvos all-snaps dir
<ali1234> is the partition expansion fixed?
<ogra_> since ages :)
<ali1234> okay. does it work on pi 3 yet?
<ogra_> yep, but we don have a dedicated image yet
<ali1234> what does that mean?
<ali1234> why do you need a dedicated image if it works?
<ogra_> that you nedd to build it yourself
<ali1234> i see, so ubuntu-device-flash?
<ogra_> Yes, the latest one from mvo
<ogra_> with the canonical-pi3 gadget
<ogra_> (from the store)
<ali1234> the store?
<ogra_> Yes
<ali1234> what store?
<ogra_> snap store.... Where u-d-f pulls its. Snaps
<ali1234> expected a gadget snaps: snap not found
 * ogra_ needs to rush out
<ogra_> I guess your command is wrong then...
<ali1234> i copied it from the shell script :)
<ogra_> The options changed slightly
<ali1234> make-rpi2-all-snap.sh
<ogra_> series is 16 now instead of rolling
<ogra_> No idea what that is
<ali1234> okay it's doing something
<ali1234> http://people.canonical.com/~mvo/all-snaps/make-rpi2-all-snap.sh
<ogra_> Ah, never seen that
<ogra_> anyway... Out
<dduffey> I have a snappy 16 image I made last week.  Now when I boot with that image (even fresh) I'm not able to do a snappy search
<dduffey> it says "no such command"
<dduffey> sorry "Unknown command"
<dduffey> wililupy, ^^^
<ali1234> it's called snap now
<ali1234> and snappy automatically updates itself
<dduffey> ali1234, thanks, how do I snap install webdm?
<ali1234> no idea
<dduffey> even "snap install" says "Unkown command" install|search
<ali1234> i haven't even managed to make an image that boots yet
<ogra_> ali1234, whats the issue with booting ?
<ogra_> (note that serial output is currently not available on pi2)
<ogra_> will be fixed on monday
<ali1234> i don't know what the issue is
<ali1234> because it doesn't boot
<ali1234> maybe i am trying the wrong ip address
<ogra_> defintely boots here...
<ogra_> on both pi's
<ali1234> okay i am in
<ogra_> good
<ali1234> why is the led blinking constantly?
<ogra_> heartbeat...
<ali1234> they are backwards
<ogra_> shows you the system is alive
<ali1234> disk activity makes the power led blink
<ali1234> heartbeat is on the disk activity led
<ogra_> worth a bug I guess
<ali1234> i actually asked the foundation developers if this was possible once and they said no
<ali1234> https://bugs.launchpad.net/snappy/+bug/1574103
<ubottu> Launchpad bug 1574103 in Snappy "Raspberry Pi 2 image LEDs are swapped." [Undecided,New]
<ali1234> so now what? install snapcraft on my desktop?
<ogra_> To build for arm ?
<ogra_> No
<ali1234> yes
<ogra_> only native
<ali1234> oh.
<ali1234> what if i install ubuntu-mate on my other raspberry pi and then install snapcraft on that?
<ogra_> scp an ubuntu-core (not snappy) tarball to the device and use it as chroot
<ogra_> Yeah, mate works too indeed
<ali1234>  /home = /wrtable/user-data?
<ogra_> Kind of, yeah
<ali1234> okay i chrooted. apt can't find snapcraft
<ogra_> copied resolv.conf ?
<ali1234> yes
<ogra_> universe enabled ?
<ali1234> no
<ogra_> there you go
<ali1234> debconf is unhappy because it cannot show a dialog
<ogra_> It only tells you the frontend isn't installed, doesn't mean it would use it ;)
<ali1234> okay i have a snapcraft.yaml
<ali1234> it's downloading cmake stuff...
<ali1234> it failed to build because no C++ compiler
<ali1234> is it a problem that i am running snapcraft as root?
<ali1234> okay it still didn't work because no pkg-config
<ali1234> why do some snaps put build-packages in the top level, but others put it under parts:
<ali1234> i wish debs would have consistent names
<ali1234> why is it libgstreamer1.0-dev but libgstrtspserver-1.0-dev
<ali1234> wow it actually attempted to compile a source file that time
<ali1234> /root/piroverd/parts/daemon/src/i2cdevice.cpp:38:43: error: âioctlâ was not declared in this scope
<ali1234> seriously?
<ali1234> how do i make snapcraft redownload the git repository after i made changes?
<ali1234> i found the repo and pulled manually
<ali1234> okay now i got /root/piroverd/parts/daemon/src/i2cdevice.cpp:54:58: error: âi2c_smbus_read_byte_dataâ was not declared in this scope
<ali1234> this is that thing where's there's two different versions of linux/i2c-dev.h
<ali1234> finally it built
<ali1234> now i get "make: *** No rule to make target 'install'.  Stop."
<ali1234> this is what i've got so far http://paste.ubuntu.com/16015163/
<ali1234> let's see if it can build gst-rpicamsrc
<ali1234> configure: error: Raspberry Pi files not found in /opt/vc/include
<ali1234> nope
<ali1234> well, i give up
<ali1234> all of my software uses the videocore libraries heavily
<Domi> Hello, where do I get the latest builds for rpi 3?
<ali1234> you have to build the image yourself for rpi3
<ali1234> http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash
<ali1234> then do something like this:
<ali1234> sudo ./ubuntu-device-flash --verbose core 16 -o  rpi2-all-snap.img --channel stable --enable-ssh --gadget canonical-pi3  --kernel canonical-pi3-linux --os ubuntu-core
<ali1234> except that doesn't work... snap not found
<Domi> thank you. Is there any documentation on this?
<ali1234> nope
<ali1234> https://www.mail-archive.com/snappy-devel@lists.ubuntu.com/msg01307.html
<ali1234> that looks out of date
<ali1234> earlier ogra told me to use canonical-pi3 gadget
<Domi> http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/ what is with this images?
<ali1234> i dunno
<ali1234> earlier ogra told me there are no images :)
<ali1234> i wouldn't trust that to actually work
<Domi> ok is there anyone who is able to help me? Or can i ask someone?
<ali1234> ogra :)
<ali1234> but i think he's hiding
<ali1234> i'd help you if i could, but i have abslutely no idea what i am doing
<ali1234> this channel has more activity during european business hours
<Domi> ok thank you for your help I will try it tomorrow.
<oparoz> Is there a deb we can use to include extra dynamic linkers?
<oparoz> I've got an arm binary using the wrong one and symlinking works, but that's not possible in Snappy
#snappy 2016-04-24
<thomi> Anyone know why, after installing a snap 'foo'  I get the following error when trying to run the 'foo' command? "/bin/sh: 0: Can't open /snap/foo/100004/command-foo.wrapper" ?
<thomi> I've verified that the wrapper script file is present, and it seems sensible to me...
<thomi> Can anyone help me find docs that expand on https://developer.ubuntu.com/en/snappy/guides/interfaces/ ? Specifically, what do I need to do to use a 'reserved' interface?
<LinuxGUy2020> Hello I am trying to test out making snaps from deb packages. I got the snap to build but Im wondering how to install it. I tried "sudo snap install packagename.snap" and it looks like it downloads something like 64.64MB and fails.
<LinuxGUy2020> So my question is " How do I install a local snap package?".
<pedronis> thomi: seems an instance of this bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1572463  (which is being worked on and should be fixed with the first SRU)
<ubottu> Launchpad bug 1572463 in snapd (Ubuntu Xenial) "setup-profile configures security based on snap.Info from DisconnectSnap, which still sees older revision" [High,In progress]
<Domi> Hello, were do I get the latest ubuntu core image for rpi 3?
#snappy 2017-04-17
<mup> PR snapcraft#1246 closed: store: plumbing for collaboration support <Created by psivaa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1246>
<niemeyer> Hey hey
<renat> Hi!
<renat> Hi, niemeyer, may I have your help?
<niemeyer> renat: Heya
<niemeyer> renat: I can try :)
<niemeyer> renat: What's up?
<renat> I am using the udisks2 interface and I need to get a list of mount points, but AppArrmor denies my .DBus.Properties.Get request.
<renat> [15832.880321] audit: type=1107 audit(1492434933.757:4918): pid=1064 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/UDisks2/block_devices/mmcblk0p2" interface="org.freedesktop.DBus.Properties" member="Get" name=":1.2971" mask="receive" pid=1476 label="snap.udisks2.udisksd" peer_pid=15502 peer_label="snap.screenly-client.netconfig"
<renat>                 exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?'
<renat>  
<renat> As I can see from the `udisks2.go` - it's not enabled there. If I understand correctly - only PropertiesChanged member allowed, not Get.
<renat> What I am doing wrong, and what is the correct way of doing it?
<renat> And, 2nd question, is it possible to enable Introspect on that object? pydbus - the library we use, does introspection on every object request. Currently, I have to use dbus-python library to skip the introspection.
<niemeyer> renat: Hmm
<niemeyer> renat: Former sounds like a simple bug that should be fixed
<niemeyer> renat: Latter requires some thinking and more details about which pieces of the stock dbus interfaces need to be opened up for that introspection to be accessible
<niemeyer> renat: Can you open two independent topics in the forum about those issues?
<renat> Sure, niemeyer, I will do it.
<renat> Thanks for help.
<niemeyer> renat: Thanks, this will ensure it gets the proper response
<niemeyer> renat: Quite a few people are off today
<mup> PR snapd#2749 closed: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<mup> PR snapd#2969 closed: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<mup> Bug #1683364 opened: Cannot get properties of an Udisks2.Filesystem object <Snappy:New> <https://launchpad.net/bugs/1683364>
<mup> PR snapcraft#1256 closed: ant plugin: honour proxy configuration <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1256>
<mup> Bug #1683368 opened: Enable Introspection for UDisks2 objects <Snappy:New> <https://launchpad.net/bugs/1683368>
<mikeb_> Is it known snapcraft behavior that post-stop-command: doesn't expand '$SNAP' like stop-command?  Instead, the post-stop-command is put verbatim into meta/snap.yaml, then I get a 'invalid' error when I try to install the snap.
<Pharaoh_Atem> morning all
<this_self> Hi guys! I have problem with installing any package from snap. I'm using ubuntu 16.04.2 with snap 2.22.6. Here is error output from console http://pastebin.ubuntu.com/24400952/
<zyga> looks network related
<this_self> network is works as well
<mup> Bug #1683389 opened: Modify shell prompt when inside a snap <Snappy:New> <https://launchpad.net/bugs/1683389>
<zyga> can you try again?
<this_self> I still have the same
<this_self> Is I need to log in with `snap login ...` ?
<zyga> no
<this_self> because I try to use snap without logged in
<zyga> it's not related or required
<zyga> (I never log in)
<zyga> you can ask a question on forum.snapcraft.io
<zyga> as today is still easter you will have better luck than asking on IRC, I suspect
<this_self> I tried the solution at link from mup, but nothing
<this_self> right. Will write there right now
<zyga> this_self: good luck
<this_self> thanks
<this_self> small question about theme of posting my bug
<this_self> snapd or snap?
<this_self> As I see in description `snap` thread in most about snap application. My problem is in snapd functionality, right?
<cachio> niemeyer, hi, I have added the code to get the execution time for the tests in spread, but it include the ssh overhead, I was looking at the code to add the time calculation as part of the test script but I don't see a way to add it due to the script could exit before, do you think that approach is ok, or I should think something different?
<niemeyer> cachio: Heya
<niemeyer> cachio: As a first try, it'd be best to have something that looks nice code-wise, so we can more easily agree on it
<niemeyer> cachio: We can always improve it later
<mup> PR snapcraft#1258 opened: python-plugin: support pip list columns mode <Created by sdeancos> <https://github.com/snapcore/snapcraft/pull/1258>
<cachio> niemeyer, well this implementation is really simple
<niemeyer> cachio: So it's all good
<cachio> niemeyer, it is just to consider that the current implementation is adding about 0.1 seconds to any time if the execution is against an external device
<cachio> niemeyer, then if we compare allways againt the same kind of execution that delay doesn't matter
<niemeyer> cachio: Yeah, sounds fine as a starter.. we can later add an "overhead" number of some kind
<cachio> niemeyer, good
<nacc> hrm, i have a build recipe that is failing to upload to the store on lp with '502 server error: proxy error' right now
<nacc> is that expected?
<mup> PR snapcraft#1259 opened: tests: use launchpad as the source of the compressed test snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1259>
<kyrofa> noise][, nessita I'm having trouble installing any snap... keep getting connection reset by peer
<kyrofa> Trying for the third time now
<noise][> kyrofa: during the download? and what's your host's network setup/path to the CDN like?
<kyrofa> noise][, yeah. Nothing special, lxc container on my laptop -> router -> ISP
<noise][> we're eager to get more evidence on those as there's been little so far in conclusive repros and detailed network data
<noise][> can you mtr it?
<noise][> to the CDN host that is
<kyrofa> noise][, haha, of course, it succeeded this time
<noise][> still would be good to have the trace
<noise][> if you can pastebin and attach to https://bugs.launchpad.net/software-center-agent/+bug/1617765
<mup> Bug #1617765: Connections reset when downloading snaps from CDN <Snapcraft:New> <Software Center Agent:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1617765>
<kyrofa> noise][, sure... what domain exactly?
<noise][> ideally use the IP from the conn reset error
<kyrofa> Oh duh
<noise][> because otherwise you may hit a different PoP
<mup> PR snapcraft#1260 opened: meta: version from git support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1260>
<mup> PR snapcraft#1259 closed: tests: use launchpad as the source of the compressed test snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1259>
<evilt0ne> hi
<kyrofa> Hey there evilt0ne
<evilt0ne> i am havin a litle trouble using snap
<evilt0ne> https://nopaste.me/view/8a6fde6f
<evilt0ne> I am trying to get an lxd openstack setup running
<evilt0ne> i installed conjure-up via snap and it seems that packages do have its own pythonenvironment since all required dependencies that conjure-up is trying to import are importable as user
<evilt0ne> has anyone a solution to that issue?
<evilt0ne> sorry to bother you, but I've heared of snapd a few days ago and thought i'll try asking before spending lots of time researching snapd in depth
<evilt0ne> kyrofa: do you have an idea how snapd is managing python environments?
<kyrofa> evilt0ne, sorry, you were hidden behind a massive full-screen terminal :P
<kyrofa> evilt0ne, snapd doesn't do anything special for python-- the snap needs to set that stuff up. stokachu is your go-to guy for conjure-up
<kyrofa> evilt0ne, what OS are you on?
<evilt0ne> ubuntu
<kyrofa> Which version?
<evilt0ne> 16.4
<evilt0ne> i just wanted to try juju
<kyrofa> evilt0ne, yeah that should be working, stokachu will need to advise
<evilt0ne> big thx kyrofa
<evilt0ne> stokachu: hi :-), could you offer a litle bit of your time?
<kyrofa> evilt0ne, if he happens to not be around, consider making a forum post (forum.snapcraft.io)
<evilt0ne> kyrofa: I'll think of it. but first I will install a irc client and rejoin
<kyrofa> evilt0ne, you can try rocket as well: rocket.ubuntu.com/channel/snapcraft
<kyrofa> (no client needed)
<evilt0ne> I do like irssi ;-)
<evilt0ne> at the moment this I am sitting on a test setup
<stokachu> evilt0ne: whats wrong?
<stokachu> evilt0ne: that pastebin is odd as the snap contains everything it needs including it's own python
<evilt0ne> wow super fast premium support
<stokachu> evilt0ne: do you have any custom virtual environments running?
<stokachu> like with pyenv or anything
<evilt0ne> stokachu: yes but I gett this error concering the include in line 6
<evilt0ne> I am getting
<evilt0ne> stokachu: can i provide you some mor information?
<stokachu> evilt0ne: if you can fill out https://github.com/conjure-up/conjure-up/issues/new providing the information required in the issue template
<stokachu> that would help
<stokachu> im mostly interested in the versions you have installed of the various software
<evilt0ne> what kind of information do you need? i'm new to snapd, is there a command that lists the installed dependencies or did you mean the system packages installed with apt?
<stokachu> evilt0ne: if you go that link i explain it all in the template
<stokachu> tells you everything we need
<evilt0ne> thanks
<evilt0ne> i will open a ticket tomorrw morning.
<stokachu> evilt0ne: perfect thank you
<evilt0ne> I know it is better to work this way. thanks for your time
<stokachu> evilt0ne: im around all day tomorrow
<evilt0ne> well then .. i am from germany... and i am about to go to bed. good night
<stokachu> evilt0ne: ill be up early enough to help you out further
<evilt0ne> stokachu: no stress, it is not urgent. i am just playing around al litle to see which distro is best for what i've palned.
<evilt0ne> I think ai have to read more about snapd
<evilt0ne> it is really the first time I've heared about it.
#snappy 2017-04-18
<mwhudson> hmm has anyone talked about making the netplan config part of the core snap's config recently?
<mwhudson> the point of that being that a gadget could then override the default
<mwhudson> wrong time of day for this conversation i guess
<mup> PR snapd#3195 opened: interfaces/builtin: allow full access to properties iface of the udisks service <Created by morphis> <https://github.com/snapcore/snapd/pull/3195>
<pstolowski> morning
<mup> PR snapd#3185 closed: snap: added tasks subcommand <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3185>
<zyga> good morning
<zyga> sory for being late
<zyga> pstolowski: hey
<pstolowski> hi zyga !
 * zyga is sleepy a little
<zyga> I was sleeping outside in a tent
<zyga> mvo: I fixed a bug in running snap-confine from core
<Son_Goku> morning all
<zyga> mvo: and now https://github.com/snapcore/snapd/pull/3149 is green and can land
<mup> PR snapd#3149: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149>
<zyga> Son_Goku: good morning :-0
<zyga> :-)
<Son_Goku> I woke up at midnight :/
<mup> PR snapd#3193 closed: interfaces/mount: parse mount options to map[string]string <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3193>
<zyga> mvo: please review that branch and we can use it as a base for your earlier work on /snap sharing
<Son_Goku> zyga: PR 3149 isn't going to cause it to stop using snap-confine from the host distro, is it?
<Son_Goku> because that's a problem
<zyga> Son_Goku: using snap-confine from host distro is tied to reexec now
<Son_Goku> okay, so the answer is no in my case
<mup> PR snapd#3196 opened: tests: ensure we mock force dev mode as well to fix FTBFS in sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/3196>
<zyga> Son_Goku: right
<zyga> Son_Goku: it is related to having snapd work in containers and in other places where / is not rshared
<mvo> zyga: sure, looking
<zyga> Son_Goku: so /snap or /var/lib/snapd/snap is also not rshared
<Son_Goku> right
<Son_Goku> I'm aware of that little issue
<zyga> mvo: it's nothing urgent but I just wanted  to let you know the tests are green there and we could progress
<Son_Goku> it's what prevents things like snapd from running in docker or flatpak
<zyga> Son_Goku: it should be fixed soon :)
<zyga> (maybe today)
<zyga> Son_Goku: the fix is easy we just needed to do something to make initialization not racy
<zyga> Son_Goku: hence locking ;)
<Son_Goku> right
<Son_Goku> it also is a nice step towards making snapd work in unprivileged contexts
<mvo> zyga: what bug did you fix in running snap-confine from core? is that in already?
<zyga> mvo: it was a simple one liner, it only affected tests
<zyga> mvo: let me find it
<zyga> https://github.com/snapcore/snapd/pull/3194
<mup> PR snapd#3194: tests: copy snap-confine apparmor profile into testbed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3194>
<mvo> zyga: ta
<zyga> offtopic, github added support for project tags
<zyga> e.g. we could add "packaging" to snapd
<mup> PR snapd#3186 closed: tests: allow installing snapd from -proposed for SRU validation <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3186>
<Chipaca> zygaâ also "awesomeness"
<Chipaca> good morning
<zyga> Chipaca: good morning :)
<zyga> Chipaca: what's up? :)
<Chipaca> not me
 * Chipaca 's back is acting up again
<zyga> Chipaca: :-(
<zyga> I know the pain :(
<mvo> uhhh@chipaca
 * mvo hugs Chipaca
<Chipaca> mvoâ good morning sah!
<mvo> Chipaca: good morning to you as well!
<Son_Goku> davidcalle: https://github.com/CanonicalLtd/snappy-docs/pull/69
<mup> PR CanonicalLtd/snappy-docs#69: Update Arch Linux status <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/69>
<zyga> that's a sad change
<zyga> but well
<zyga> btw, do we duplicate the wiki and the table there?
<zyga> maybe we should just redirect
<Son_Goku> the wiki has more details than the website does
<Son_Goku> and I fully expect _every_ distribution to enforce this change soon
<Son_Goku> I've already spoken to some of my counterparts in other distros about this, which is why I keep telling you it'll happen :P
<pstolowski> i've little emergency here. need to take my daughter to the dentist.. bb in ~1h
<Son_Goku> and I've already updated the wiki accordingly: https://github.com/snapcore/snapd/wiki/Distributions
<mup> PR snapd#3197 opened: store: retry on connection reset too <Created by mvo5> <https://github.com/snapcore/snapd/pull/3197>
<zyga> Son_Goku: I think this is couter-productive
<zyga> Son_Goku: I'd only do it after we have better classic confinement
<zyga> Son_Goku: the FHS is not some nagic sacred unicorn, it's not worth removing features over
<Son_Goku> I just want to avoid the back and forthiness and the complexity of directory migrations
<Son_Goku> it's a pain and we're lucky to have avoided it in Fedora
<Son_Goku> the poor Arch guys don't have fancy transaction scriptlets like we do, so everything is harder
<zyga> Son_Goku: it's not a pain, it's just stubborn people
<zyga> Son_Goku: really, nobody normal cares about this, this is just geeks disageeing on niche stuff
<zyga> Son_Goku: (but reversing decision has negative consequences)
<Son_Goku> nobody normal cares about Linux
<Son_Goku> so that's a really bad argument to use with me :)
<seb128> nobody uses android right
<zyga> Son_Goku: I disagree
<Son_Goku> fine, GNU+Linux
<Son_Goku> seb128: snapd can't run on Android anyway
<zyga> Son_Goku: nobody using android (great point seb128) cares about the FS layout there
<Son_Goku> no SELinux support, and alternate filesystem layout isn't supported either
<zyga> Son_Goku: and it's not the "blessed" and "only correct" FHS
<Son_Goku> I'm not saying it is
<Chipaca> saying "nobody cares about X" to somebody that cares about X is not how you win an argument with them, FWIW
<Son_Goku> but breaking people's expectations isn't good either
<zyga> Son_Goku: so what you are doing is IMO harmful, why go to this effort if we're not ready to switch?
<Son_Goku> I did not change Arch Linux
<zyga> Son_Goku: breaking something that worked is also not good :)
<Son_Goku> someone else already did
<seb128> Son_Goku, it's funny how fedora doesn't care about the FHS when it comes to udisks and mountpoints but now you do when it's snapd...
<Son_Goku> seb128: what are you talking about?
<davidcalle> Son_Goku: notre, thank you, should go live today
<davidcalle> noted*
<Son_Goku> udisks mountpoints are ephemeral, which is why they're in /run in the first places
<Son_Goku> it's weird, yes
<Son_Goku> but whatever
<seb128> Son_Goku, https://bugs.freedesktop.org/show_bug.cgi?id=51709
<seb128> Son_Goku, it's also not FHS compliant
<Son_Goku> seb128: at least you're not breaking people's ability to back up their whole system
 * Son_Goku shrugs
<zyga> I love this comment https://bugs.freedesktop.org/show_bug.cgi?id=51709#c7
<Son_Goku> I didn't particularly like this either
<zyga> it really does capture the essence of FSH
<zyga> it's just old stuff that who that can commit can change at will
<zyga> and any that innovate can just ignore as old
<seb128> Son_Goku, right, but if it's coming from fedora it's fine  but if it's coming from somebody else it's not, great double standards right?
<zyga> ENOSACREDCOWINFHS
<Son_Goku> seb128: no, it's not fine regardless
<seb128> but still fedora did it
<Son_Goku> and like then, I can't convince you to change anything
<seb128> didn't reverse patch upstream
<Son_Goku> well, apparently no one ever complained about it in rhbz
<Son_Goku> I guess if someone complained, then something might happen
<Son_Goku> when I complained about the ovirt guys doing it, their packages got backed out of the distribution
<seb128> k, anyway I was just making a comment about those double standards which are a bit sad, no point going over that for an hour, sorry for the noise
<Son_Goku> seb128: if I really wanted to get into that mess, I would bitch about Debian "multi-arch"
<Son_Goku> I've pretty much let it go
<Son_Goku> I've had my fair share of complaints about FHS
<Son_Goku> them intentionally ignoring /usr/libexec which led to Debian and openSUSE spending literally over a year moving everything into the wrong place
<Chipaca> I think it's time for second breakfast
<Son_Goku> and not specifying sysroot style FHS as being a valid mechanism (that is, /usr/<target>/{bin,lib})...
<Son_Goku> davidcalle: where's the source for the home page: https://snapcraft.io/
<davidcalle> Son_Goku: https://github.com/canonical-websites/snapcraft.io/blob/master/index.html
<Son_Goku> geez
<Son_Goku> why can't everything be in one place :(
<davidcalle> Given the amount of teams involved in the snapcraft ecosystem and also involved in many other projects, it's a trade off between having a similar workflow for everything a team is working on and having everything in one place. In this case, Canonical websites follow a specific org structure, because the people building and maintaining them work in a specific
<davidcalle> way.
<mvo> zyga: hm, master is unhappy right now, looks like its related to 3194
<mvo> zyga: I'm looking at this now
<zyga> mvo: sorry, I'm in a call
<mvo> zyga: np
<Son_Goku> davidcalle: meh... we need something to know where stuff is
<Son_Goku> it's really aggravating because I know they're forkable, I just don't know where they are
<Son_Goku> anyway...
<Son_Goku> davidcalle: https://github.com/canonical-websites/snapcraft.io/pull/305
<mup> PR snapd#3190 closed: Change default options for Arch Linux <Created by Aimilius> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3190>
<Chipaca> do we have a fedora image for spread under qemu?
<Chipaca> Son_Gokuâ ^ maybe you know?
<zyga> re
<zyga> Chipaca: no, I don't think we do
<zyga> mvo: what's the status of 3194
<mvo> zyga: ignore me for now, maybe I was reading the output wrong, I'm running a local test now
<Chipaca> zygaâ isn't that merged?
<zyga> aha
<zyga> Chipaca: yes, I think mvo found a potential issue with it though
<Chipaca> ah
<mvo> zyga: yeah, but maybe I'm wrong and I was just confused by the output. sorry for the noise (maybe)
<Chipaca> fedora's "reboot & install" is weird. Also, takes forever.
<zyga> Chipaca: reboot & install?
<Chipaca> rpm used to beat deb-based on speed; what happened?
<Chipaca> zygaâ "upgrades are available; reboot & install?" <click> <reboot> <stuck at "installing updates" for multiple minutes>
<zyga> Chipaca: aha
<zyga> Chipaca: that's the new systemd way of updating
<zyga> Chipaca: you reboot, it installs everything in a controlled environment,
<zyga> Chipaca: and it reboots back
<Chipaca> in the time since i commented it's gone from 55% to 56%
<zyga> Chipaca: I honestly still just "dnf update"
<Chipaca> I am wearing my newbie hat, here
<Chipaca> hmm, getting selinux alerts about snapd trying to access /home
<Chipaca> also about snapd tyring to access ld-linux-x86-64.so.2
<zyga> Chipaca: yes
<zyga> Chipaca: those are complain moe
<zyga> Chipaca: I started filing bugs about this
<zyga> Chipaca: but we really should sit through one session
<zyga> Chipaca: and write a meaty patch to the policy
<zyga> Chipaca: there are tools that mostly generate the policy for you
<zyga> Chipaca: so it shouln't be hard to fix 80% (hand-wavy estimate) of those quickly
<Chipaca> zygaâ ok
<Chipaca> zygaâ good thing these are complain, otherwise nothing would work
<Chipaca> OTOH i also get the same thing for systemd and systemctl trying to do stuff
<Chipaca> e.g. systemctl creating a .mount
<Chipaca> and systemd reading the current symlink
<pstolowski> mvo, thanks for hacking around retry code!
<mvo> pstolowski: my "pleasure" ;)
<mvo> pstolowski: this one is hard to test
<pstolowski> mvo, yeah, I agree
<zyga> Chipaca: yes, there's plenty of them; I don't know if all the fixes can go into the snapd policy; perhaps some must be made in the upstream policy
<ogra_> mvo, mind giving a second ack on https://github.com/snapcore/core-build/pull/5
<mup> PR core-build#5: Update cloud-init configuration <Created by raharper> <https://github.com/snapcore/core-build/pull/5>
<Trevinho> tvoss: hey, do you know why in my 14.04, every time I reboot the snap `core` and others are marked as broken?
<Trevinho> I need to reinstall int all the time...
<mvo> ogra_: sure, I have a look
<ogra_> zhx
<Chipaca> zygaâ is snapd built differently in fedora, or is libexec autodetected?
<Chipaca> if it's the latter, then everything works wrt snapd#3150
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<Trevinho> And now.... error: cannot install "core": snap type unset
<morphis> Chipaca, zyga: I already started looking into those denials on fedora but one after another :-)
<mup> PR core#35 opened: move xdg-open to proper paths <Created by ogra1> <https://github.com/snapcore/core/pull/35>
<Chipaca> there isn't a way to know libexec from bash, is there?
<mup> PR snapcraft#1257 closed: core: support running from other operating systems <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1257>
<Chipaca> nm ignore me
<Chipaca> :-)
 * Chipaca looking at too many things, got confused for a mo'
<Chipaca> zyga, pedronis, you both kinda-half reviewed #3150; could you finish it?
<zyga> Chipaca: yes
<zyga> Chipaca: I just finished throwing something together
<zyga> Chipaca: let me open a few PRs and I'll get to it
<mup> PR snapd#3198 opened: interfaces/mount: pass mount.Profile to mount.NeededChanges <Created by zyga> <https://github.com/snapcore/snapd/pull/3198>
<mup> PR snapd#3199 opened: interfaces/mount: add stub Change.{Needed,Perform} <Created by zyga> <https://github.com/snapcore/snapd/pull/3199>
<mup> PR snapd#3200 opened: interfaces/mount: add Change.String for readable output <Created by zyga> <https://github.com/snapcore/snapd/pull/3200>
<zyga> there
<zyga> Chipaca, mvo: I'll make a coffee and resume reviewing
<zyga> mvo, pstolowski, Chipaca: I would appreciate if you can land the stub PR (3199) as this will allow me to propose the actual algorthim behind update-ns
<sergiusens> Chipaca: have a couple for a review?
<sergiusens> Chipaca: https://github.com/snapcore/snapcraft/pull/1260
<mup> PR snapcraft#1260: meta: version from git support <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1260>
<Chipaca> sergiusensâ we need to talk about completion from snapcraft
<sergiusens> Chipaca: completion as in being feature complete or something more scoped?
<Chipaca> sergiusensâ yes
<ogra_> sergiusens, you dont forget about my override requirements when doing this, right  :)
<sergiusens> ogra_: that comes next, it is rather easy (version-script to run after everything is in stage)
<ogra_> cool !
<ogra_> thanks
<sergiusens> by which I guess we will do it when everything is primed
<sergiusens> to not be all spread out in the lifecycle
<sergiusens> Chipaca: so, when or where do you want to discuss this?
<Chipaca> sergiusensâ reviewing this thing first
<sergiusens> ok, thanks!
<Chipaca> sergiusensâ but after that? although i should have lunch before the standup which is at 2
<sergiusens> ok, whenever you want or forum post it :-P
<zyga> re
<pstolowski> uh oh CheckChangeConflict in Disconnect() doesn't really do a thing if snap/plug/slot names are omitted
<morphis> niemeyer: ping
<mup> PR snapd#3199 closed: interfaces/mount: add stub Change.{Needed,Perform} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3199>
<mup> PR snapd#3157 closed: store: add more logs around retry in download <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3157>
<zyga> Chipaca: theresa may seeks "snap election"
<zyga> Chipaca: snap find election
<Chipaca> zygaâ IKR
<zyga> IKR?
<Chipaca> totally
<zyga> Chipaca: can you "snap revert brexit"?
<Chipaca> zygaâ you're just being mean, now
<zyga> Chipaca: snap install humor
<zyga> Chipaca: I just saw you laughing in the hangout
<zyga> :-)
<Chipaca> niemeyerâ given the 2009 date of the bug, "soon" could mean 2021
<Chipaca> zygaâ I always laugh when I confirm that everything is terrible
<Chipaca> it's the only way to do it
<niemeyer> Chipaca: Yes! :)
<niemeyer> renatu: Heya
<renatu> niemeyer, hey
<niemeyer> renatu: Missed your topics in the forum.. am I blind or did you manage to get a fix?
 * zyga gets to reviews
<renatu> niemeyer, sorry what topic exactly?
<niemeyer> renatu: Related to the conversation we had here yesterday
<renatu> niemeyer, I do not remember that, probably you talk with another person :D
<niemeyer> renatu: Most probably! 8)
<niemeyer> renatu: Sorry.. :)
<renatu> np
<niemeyer> Yes, "renat" vs. "renatu".. :)
<mup> PR snapd#3196 closed: tests: ensure we mock force dev mode as well to fix FTBFS in sbuild <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3196>
<Facu> sergiusens, anybody, mind to explain me the difference between snapcraft tests: [static|unit|integration|snaps] ? (basically, which should be run in which situations) thanks
 * Facu promises to add this explanation to the HACKING.md doc
<morphis> niemeyer: ping
<niemeyer> morphis: Heya
<morphis> niemeyer: hey!
<morphis> niemeyer: you saw my post in the forum about a linode auth key?
<morphis> niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250/3
<niemeyer> morphis: No, I still need to go through this morning's forum posts
<niemeyer> morphis: Will get you a key for usre
<niemeyer> sure
<morphis> niemeyer: thanks, will wait then :-)
<morphis> niemeyer: just wasn't sure if you're the right one for this
<mup> Bug #1683823 opened: snapcraft list-revisions showing multiple publications in the same channel <Snappy:New> <https://launchpad.net/bugs/1683823>
<sergiusens> Facu: you want to talk to elopio; but the gist of of; static->flake8; unit-> no-builds; integration->shells to snapcraft, builds; snaps-> builds snaps, installs and checks how they run
<Facu> sergiusens, thanks
<mup> PR snapd#3200 closed: interfaces/mount: add Change.String for readable output <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3200>
<mup> PR snapd#2749 opened: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<mup> Bug #1683827 opened: snapcraft list-revisions strip trailing 0's from versions <Snappy:New> <https://launchpad.net/bugs/1683827>
<mup> PR snapd#2969 opened: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<morphis> Pharaoh_Atem: did you check those SELinux denials for snapd already?
<mup> Bug #1683827 changed: snapcraft list-revisions strip trailing 0's from versions <Snap Store:New> <https://launchpad.net/bugs/1683827>
<niemeyer> Lunch, biab
<morphis> niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250/6
<morphis> niemeyer: not sure for how long the machines stay when I've used -reuse
<zyga> mvo: there is something odd in tests
<zyga> mvo: I just saw this failure: https://travis-ci.org/snapcore/snapd/builds/223175451#L860
<zyga> + cp -a /etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/usr.lib.snapd.snap-confine.real squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> cp: target 'squashfs-root/etc/apparmor.d/usr.lib.snapd.snap-confine.real' is not a directory
<zyga> first of all, why there are both .real and old files there and why is something a directory?!
<ogra_> the cp command tries to copy two files ...
<ogra_> ... so the target path needs to be a dir
<zyga> aaaha
<zyga> thanks!
<zyga> so
<zyga> on 14.04 it is the plain file
<zyga> on 16.04 it is the .real file
<zyga> so I used a * to get both
<ogra_> ah
<zyga> but why do we get both at once now?
<zyga> anyway, I think the rule needs tweaking
<zyga> s/rule/command/
<zyga> mvo: https://github.com/snapcore/snapd/pull/3202
<mup> PR snapd#3202: tests: handle case when both .real and plain are present <Created by zyga> <https://github.com/snapcore/snapd/pull/3202>
<zyga> ogra_: https://github.com/snapcore/snapd/pull/3202 :-)
<mup> PR snapd#3202 opened: tests: handle case when both .real and plain are present <Created by zyga> <https://github.com/snapcore/snapd/pull/3202>
<ogra_> zyga, if both files are existing they will both end up in target though ... is that what you want ?
<ogra_> (great solution beyond that)
<zyga> yes, that's fine
<zyga> or
<zyga> ...
<zyga> is it?
<zyga> gah, I think we only look at one of them
<Pharaoh_Atem> morphis: I have not, but I will this evening
<zyga> ogra_: updated
<morphis> Pharaoh_Atem: great!
<morphis> Pharaoh_Atem: was trying to find my way through those but if you will have a look I can ignore this for now
<Pharaoh_Atem> I've been busy with Mageia stuff
<ogra_> zyga, approved
<Pharaoh_Atem> morphis: there are more important issues I need you to address, anyway
<Pharaoh_Atem> getting upstream snapd to build without patches and working with hughsie on gnome-software are both more critical
<Pharaoh_Atem> I've been going back and forth on whether I should submit a variant of the spec to be included in the snapd git repo
<Pharaoh_Atem> but if we get down to zero patches, then I can just slightly tweak the one in dist-git so that it can be pulled during spread
<Pharaoh_Atem> I want to avoid going back and forth with dist-git<->git
<morphis> Pharaoh_Atem: yeah I am on that
<morphis> Pharaoh_Atem: g-s is lined up and willcooke asked robert to spend time on this
<zyga> ogra_: thanks!
<morphis> Pharaoh_Atem: you mean spread doing a comparision alerts when both are out of sync?
<Pharaoh_Atem> morphis: I mean for Fedora dist CI
<Pharaoh_Atem> one aspect of that is making sure things don't go out of sync, yes
<Pharaoh_Atem> but another aspect is to make sure the build doesn't get broken
<morphis> ok, so you're going to run spread insight the fedora CI?
<Pharaoh_Atem> I don't know what I'm going to do
<Chipaca> fgimenezâ sunc -> sync (on https://forum.snapcraft.io/t/core-snap-delivery-process/314)
<Pharaoh_Atem> at this point, I'm sorta thinking aloud ;)
<morphis> ok, however let me give you a patch soon which enables go-tests insight the fedora build
<Pharaoh_Atem> okay
<morphis> s/insight/inside/
<Pharaoh_Atem> send me a patch for the spec and I'll apply it
<morphis> need to rule out a problem with go test and asm compilation and a few more snapd fixes but should be ready this week
<fgimenez> Chipaca: thanks! fixed i've already changed it into wiki, so feel free to edit next time! :)
<Chipaca> :-)
<mvo> zyga: nice, thanks for the fix
 * zyga reads the bash tab completion code 
<zyga> Chipaca: I'm still reading your PR; I'll take a break now but I'll be back after small supper and family time
<zyga> Chipaca: it's all +1 so far but I want to ensure I really grok what's going on
<Chipaca> zygaâ I appreciate it, and you for it
<Chipaca> ok, ttfn, ttyl, etc
<Chipaca> o/
<mup> PR snapcraft#1261 opened: storeapi:  improve the error message for the case the Store answers an upload needs manual review <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1261>
<niemeyer> Going outside for some exercising.. back later
<mvip> quick question - is it possible to use Core on RasPi headless? Don't have a monitor or keyboard at my disposal atm. IIRC SSH is disabled by default.
<EEight> hey! is it possible on my ubuntu 16.04 64bit to build a snap for 32bit?
<EEight> because my users are complaining that they don't sudo snap find myapp = not found (on 32bit)
<kyrofa> EEight, you could look into creating a 32-bit lxc environment or something
<kyrofa> EEight, but I recommend using the launchpad snap builders if you're able
<EEight> kyrofa: lxc +- like virtualbox so I guess the easiest way is to install ubuntu 16.04 32bit using a VM and build the snap using this vm?
<kyrofa> EEight, yeah
<mup> Bug #1683942 opened: Startup logs showed after the "Please Enter to configure" message <Snappy:New> <https://launchpad.net/bugs/1683942>
<mup> PR snapd#3202 closed: tests: handle case when both .real and plain are present <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3202>
#snappy 2017-04-19
<mup> PR snapcraft#1262 opened: replace : with _ in file names <Created by andyli> <https://github.com/snapcore/snapcraft/pull/1262>
<mup> Bug #1576500 changed: Plasma fails to load:  "all shell packages missing" <amd64> <apport-bug> <xenial> <Snappy:Expired> <snapd (Ubuntu):Expired> <https://launchpad.net/bugs/1576500>
<mup> PR snapd#3195 closed: interfaces/builtin: allow full access to properties iface of the udisks service <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3195>
<mup> Bug #1684014 opened: LibreOffice in snap won't print <Snappy:New> <https://launchpad.net/bugs/1684014>
<morphis> mvo: thanks for merging!
<mvo> morphis: my pleasure, thanks for doing the PR in the first place :)
<mup> PR snapd#3048 closed: interfaces: add media-hub interface <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3048>
<mup> PR snapd#3179 closed: packaging: add `built-using` header for 16.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3179>
<zyga> good morning
<zyga> mvo: about https://github.com/snapcore/snapd/pull/3198 -- it is an update of existing function to use the new type that was introduced later; it used to take []Entry but now it takes a struct with that inside
<mup> PR snapd#3198: interfaces/mount: pass mount.Profile to mount.NeededChanges <Created by zyga> <https://github.com/snapcore/snapd/pull/3198>
<zyga> mvo: I should have documented that inside the PR
<mup> PR snapd#3198 closed: interfaces/mount: pass mount.Profile to mount.NeededChanges <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3198>
<mup> PR snapd#3203 opened: interfaces/mount: add ReadMountInfo and LoadMountInfo <Created by zyga> <https://github.com/snapcore/snapd/pull/3203>
<pstolowski> mvo, hey, 3197 has a conflict. it can land once fixed
<mup> PR snapd#3204 opened: interfaces/builtin: don't panic if content plug has nil attrs <Created by zyga> <https://github.com/snapcore/snapd/pull/3204>
<zyga> pstolowski: something for you https://forum.snapcraft.io/t/snapd-service-doesnt-start/319
<mvo> pstolowski: sure, I will push a fix, I also adding a testh
<mvo> test
 * zyga -> break / errands
<mup> Bug #1684041 opened: In core /var/lib/systemd/backlight should be bind mounted to writable <Snappy:New> <https://launchpad.net/bugs/1684041>
<davmor2> Someone needs to fix the snapcraft bot on rocketchat
<mup> PR snapd#3205 opened: tests: add openvswitch interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3205>
<ogra_> urgh
<ogra_> niemeyer, mup is going crazy in the #snapcraft channel on rocket
<ogra_> sending the same bug notification every 2sec
<mup> PR snapd#3204 closed: interfaces/builtin: don't panic if content plug has nil attrs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3204>
<niemeyer> ogra_: Stopped and investigating. Thanks for the note.
<ogra_> niemeyer, wow, now i'm impressed ... wouldnt have expected you awake!
<niemeyer> ogra_: Me neither..
<niemeyer> :)
<ogra_> lol
<niemeyer> ogra_: Looks like RocketChat broke the protocol again
<ogra_> ouch
<niemeyer> I bet it was just updated..
<niemeyer> Yep..
<niemeyer> 1 hours, 13 seconds
<zyga> mvo: are we releasing 2.24 again?
<zyga> we need a 2nd review for https://github.com/snapcore/snapd/pull/3149
<mvo> zyga: just a sru fix
<zyga> aha
<mvo> zyga: the autopkgtests are unhappy currently and the SRU team wants us to do some small tweaks, I'm also preparing a fix for a failure with the stable core snap
<mvo> zyga: but this only affects the debs, we could even do it as a distro patch
<mvip> \quit
<mup> PR snapd#3206 opened: [2.24] Add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3206>
<zyga> mvo: thanks for merging the panic fix
<zyga> mvo: I was thinking, could we call {plug,slot}.Sanitize and register a panic handler so that we fail sanitization if the method misbehaves
<zyga> mvo: that part is naturally exposed to user input
<zyga> mvo: and while it cannot harm snapd as go is a safe language (except for the unsafe package we don't use here)
<zyga> mvo: malicious input can include denial of service attacks, like this one
<mvo> zyga: thanks for fixing the panic so quickly
<mvo> zyga: a good question about the handler, probably best to check with gustavo, I think it would be fine
<mvo> zyga: depends a bit how clean it will be (codewise) I htink
<zyga> mvo: I think that's pretty clean, let me make a quick prototype
<mup> PR snapd#3207 opened: tests: relax network-bind interface regexps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3207>
<Son_Goku> mvo: if this is ubuntu specific, please don't re-release the tarball
<Son_Goku> it's not the end of the world if you need to distro patch temporarily
<mvo> Son_Goku: yeah, I think we should not even do a regular release, its strictly fixes for autopkgtests that are pretty specific
<Son_Goku> indeed
<zyga> hey Son_Goku, how are you doing
<Son_Goku> well, I just woke up, so kinda cottonmouthy
<zyga> mvo: ok, took longer than expected but is pretty short actually
<mup> PR snapd#3208 opened: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
<zyga> mvo: details on the forum https://forum.snapcraft.io/t/snapd-service-doesnt-start/319/5
 * zyga takes a break and goes to eat something
<zyga> ttyl
<zyga> re
<ogra_> zyga, an opinion on bug 1684063 would be appreciated
<mup> Bug #1684063: core snap/amd64: dynamic linker unusable in classic confinement when using Zesty <snapd:New> <https://launchpad.net/bugs/1684063>
<zyga> ogra_: looking
<zyga> ogra_: replied
<zyga> ogra_: look at the reply please
<ogra_> zyga, seeing it ... hmm, but that means i need to mangle the link ... not great :/
<zyga> ogra_: I think there should be no links
<zyga> ogra_: the way snapcraft links snaps should give them the realpath of the linker
<ogra_> zyga, well, thats a default setup coming from libc
<zyga> ogra_: not some symlink
<zyga> ogra_: IMO that is irrelevant
<zyga> ogra_: if the linker is in /snap/core/current/foo-ld.so
<zyga> ogra_: then whatever other symlinks point to it
<zyga> ogra_: that is what snapcraft should use
<ogra_> zyga, well, the problem is that the core snap uses an absolute link to /
<ogra_> or rather libc does
<ogra_> so it links outside of the core snap
<morphis> Son_Goku: you had success fixing a few few SELinux denials yesterday?
<ogra_> the binaires would have to use /snap/core/current/lib/x86_64-linux-gnu/ld-2.23.so ...
<ogra_> instead of /snap/core/current/lib64/ld-linux-x86-64.so.2 ... (which is the default everywhere)
<ogra_> so you would have to re-build each and every binary
<zyga> ogra_: absolute link to / ?
<zyga> ogra_: sorry, I don't understand
<zyga> ogra_: that is correct
<zyga> ogra_: the answer is to rebuild those
<zyga> ogra_: that's how it is designed to work
<zyga> ogra_: (until we come and re-design it)
<ogra_> ugh
<ogra_> but that means you can not use any stage-packages at all in classic snaps
<ogra_> you would have to build all dependencies from source
<zyga> ogra_: yes, until we figure out a better way to have classic confinement working
<Son_Goku> morphis: some of the issues are related to the socket not having its label applied correctly
<zyga> ogra_: it's a complex problem - there's no silver bullet
<Son_Goku> I wonder if systemd can create the socket with the correct label...
<zyga> ogra_: what did you mean about symlink mangling?
<ogra_> zyga, hmm, could you note that on the big as well ? i think thats unexpected
<morphis> Son_Goku: can we fix that somehow?
<zyga> Son_Goku: yes, we can
<zyga> Son_Goku: you mean selinux label?
<Son_Goku> yes
<zyga> Son_Goku: sure we can, it's a feature in systemd for ages
<ogra_> zyga:
<ogra_> ogra@styx:~$ ls -l /snap/core/current/lib64/ld-linux-x86-64.so.2
<ogra_> lrwxrwxrwx 1 root root 32 MÃ¤r 21 21:06 /snap/core/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so
<ogra_> zyga, see where the link points to ?
<ogra_> that is my hosts linker
<ogra_> zyga, if my host has a newer libc ... i.e. 2.24, that link points nowhere
<morphis> zyga: is there a config item for this in the service unit?
<zyga> morphis: SELinuxContext=
<zyga> morphis: AFAIR
<morphis> ah
<zyga> ogra_: aha
<zyga> ogra_: I see
<zyga> ogra_: right,
<morphis> Son_Goku: so SELinuxContext= is what we should try
<Son_Goku> zyga: doesn't look like it for .socket files?
<morphis> Son_Goku: https://www.freedesktop.org/software/systemd/man/systemd.socket.html
<Son_Goku> there's SELinuxContextFromNet=
<morphis> yeah
<morphis> that will use the connection from the daemon to determine the label
<Son_Goku> ah, that might work
<morphis> " When true, systemd will attempt to figure out the SELinux label used for the instantiated service from the information handed by the peer over the network."
<morphis> so we need to touch snapd.service and snapd.socket
<Son_Goku> snapd itself is already properly labeled, I think
<Son_Goku> the issue is that the socket doesn't exist at the point of the policy getting applied
<zyga> ogra_: unless sergiusens disagrees I don't think we support prebuilt binaries yet
<Son_Goku> so I think snapd.socket is the only thing that needs to be changed
<ogra_> zyga, you mean no stage-packages in classic ? thats news to me
<ogra_> (but that would indeed solve the issue)
<kotVaska> hallo, spricht hier jemand deutsch?
<zyga> ogra_: yes that's what I mean
<morphis> Son_Goku: ok, so who labels snapd if not through the .service file?
<zyga> ogra_: how did you expect stage-packages to work/
<morphis> zyga: https://github.com/snapcore/snapd/pull/3156 gets really close :-)
<mup> PR snapd#3156: Support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<zyga> morphis: let me see :)
<Son_Goku> morphis: the policy, when it is applied, labels /usr/libexec/snapd as snappy_exec_t
<ogra_> zyga, dunno, i never built a classic snap ever :P
<Son_Goku> that happens during the package install
 * ogra_ thinks thats an insanity anyway 
<zyga> morphis: I have a fedora system that I plan to use for daily development in the next 2-3 weeks; I need to buy some extra hardware and then I can switch
<Son_Goku> or at least, it should...
<morphis> zyga: two tests are failing which I need to look into but all others should be ok now
<morphis> zyga: nice :-)
<morphis> Son_Goku: ah I see
 * Son_Goku needs to set up a clean box and test something
<Son_Goku> something about these denials is bugging me, because it looks like at least a good chunk of them shouldn't be issues anymore...
<zyga> morphis: commented quickly
<zyga> morphis: I'll comment again after reading it fully
<kotVaska> please help my. i have follow error with "sudo snap install nextcloud"-command -> https://pastebin.com/DsherkXt
<zyga> kotVaska: hey, you may have better luck on forum.snapcraft.io
<zyga> kotVaska: I'll gladly help you there
<zyga> kotVaska: because others can benefit from this
<morphis> zyga: thanks
<zyga> kotVaska: please open a new thread under the "snap" category
<zyga> thanks!
<kotVaska> zyga: I don't want to register there.
 * zyga though we already had various social network login available
<Son_Goku> we still don't
<zyga> kotVaska: can you please run `snap version`
 * ogra_ bets the kernel is a mess ... the "vps" in the hostname kind of indicates that :)
<kotVaska> zyga: 2.22.6
<ogra_> kotVaska, the full output please
<kotVaska> snap    2.22.6
<kotVaska> snapd   2.22.6
<kotVaska> series  16
<kotVaska> ubuntu  16.04
<kotVaska> kernel  2.6.32-042stab120.7
<ogra_> (should be 5 lines)
<ogra_> lol
<Son_Goku> oh god
<ogra_> 2.6.32-042stab120.7
<Son_Goku> stab is right
<ogra_> kotVaska, that cant work
<Son_Goku> it's an OpenVZ system
<kotVaska> yes
<ogra_> kotVaska, talk to your vps provider to use a proper kernel
<Son_Goku> you can't run snaps on OpenVZ
<zyga> kotVaska: snapd won't work on that kernel
<zyga> kotVaska: your kernel is too old, I'm sorry
<Son_Goku> they need to upgrade to Virtuozzo 7
<ogra_> this is like decades outdated
<Son_Goku> if they do that, snaps will work again
<kotVaska> i have a vServer
 * zyga recalls his first job that had a 2.6 kernel ;)
<Son_Goku> kotVaska: your hosting provider needs to upgrade to Virtuozzo 7: https://virtuozzo.com/products/virtuozzo/
<mup> PR snapcraft#1263 opened: Pass through commands into the lxd container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1263>
<kotVaska> my provider have "LXC - Linux vServer", " Qemu-KVM vServer" and " OpenVZ vServer"
<kotVaska> i rent openvz vserver
<morphis> zyga: where did you still see is-forced-devmode on the PR?
<Son_Goku> Qemu-KVM will work, as you'll use the distro's kernel
<morphis> that should be gone
<zyga> morphis: hmm,
<Son_Goku> and LXC may work, if the host is modern
<zyga> morphis: not sure what you mean?
<zyga> morphis: I commented on the blacklisting of tests on Debian
<zyga> morphis: that those had no comments explaining why
<morphis> got a mail with a comment "I suspect this part doesn't respect the rules for command help and long description. Have a look at other commands and what they do."
<zyga> morphis: ah
<zyga> morphis: that's ancient :)
<zyga> morphis: it was for a command you wanted to add
<zyga> morphis: to check if a distro is in forced devmode
<morphis> yeah, I will do that in a second step
<zyga> morphis: we (very long time ago) defined some rules of how help for commands must look like
<zyga> morphis: including specific wording
<zyga> morphis: see all the commands, they have consistent help wording
<morphis> ok, any link to that?
<zyga> morphis: no, it was before we had anything like a forum/public ML
<zyga> morphis: it was in a private email thread
<zyga> morphis: just use your imagination, compare to how other commands have help worded
<ogra_> kotVaska, you sould re-consider that ... this kernel is definitely something very hacked up ... running ubuntu 16.04 on a 2.x kernel was never officially possible .... would be surprising if there were not also other issues that do not surface as easily as this one (not to forget there might be horrid security holes)
<morphis> zyga: worth to bring that to the forum or any other documentation place now :-)
<zyga> morphis: yeah
<zyga> morphis: if you ask the question I'll go through my archive and try to find it
<sergiusens> ogra_: zyga we don't support doing the right thing with runnables from prebuilts when on classic confinement, that is correct
<kotVaska> thanks
<Son_Goku> ogra_: it's not hacked up
<Son_Goku> it's a container
<Son_Goku> don't be misleading
<ogra_> Son_Goku, dude ... to make 16.04 run on top of a 2.x kernel you will have to massively patch it
<Son_Goku> unless the 2.6 kernel itself has been patched and backported
<morphis> zyga: thanks
<Son_Goku> which is exactly how that is even working
<ogra_> no matter if it is a container or raw HW
<ogra_> were there even things like multiple pty's possible in 2.x ? i dont think it was ... there is a ton of corner cases that will affect the behaviour of the userspace here
<Son_Goku> the OpenVZ kernel used supports multiple ptys
<ogra_> this can not legally be called ubuntu
<Son_Goku> then the same goes for all your docker images
<Son_Goku> if I load a docker image into an OpenVZ system, I didn't touch Ubuntu
<ogra_> depends if they are blessed by canonical or not ... but i doubt there are doker installs using 2.x anywhere
<Son_Goku> a docker image doesn't have to be used by docker
<Son_Goku> rkt, nspawn, lxc, openvz, etc. can all consume them
<ogra_> sure,. i can also consume am ubuntu-base tarball o top of a monolithic 1.x kernel and still cant seel it as ubuntu then
<ogra_> *sell
<ogra_> the kernel is a part of the brand
<ogra_> (you cant sell RH CDs with a replaced kernel either and call it RH)
<zyga> another part of update-ns for review: https://github.com/snapcore/snapd/pull/3209
<mup> PR snapd#3209: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <https://github.com/snapcore/snapd/pull/3209>
<mup> PR snapd#3209 opened: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <https://github.com/snapcore/snapd/pull/3209>
<zyga> I'll switch to code reviews now and work on chipaca's tab-completion PR now
<zyga> ogra_, morphis: ^^
<zyga> low level, feedback appreciated
<ogra_> zyga, why do you nered all the options for umount  ? if it is mounted the mountpoint should be enough for unmounting
<ogra_> *need
<zyga> ogra_: interesting point; I guess we don't want to unmount something _else_
<zyga> ogra_: but not sure if that captures it
<ogra_> well, that would only affect things that are double-mounted on the same mountpoint (which you likely dont want top happen in the first place)
<ogra_> *to
<zyga> morphis: did you cancel the call just now?
<zyga> ogra_: yes, I think you are right
<ogra_> beyond that i think it looks fine
<zyga> ogra_: I think the devil is in mountpoint details though (like bind mounts making stuff more complex)
<ogra_> i also wonder if you carry over the mount options for filesystems from the original mount when bind mounting ...
<zyga> ogra_: yes, those are unchanged
<zyga> ogra_: well, there are two sets as you see
<ogra_> good
<zyga> ogra_: superblock and per-mount
<ogra_> right, i'm rather cobncerned about "noatime,nodiratime,data=ordered" etc ... stuff that makes sure we dont wear out SSDs or eMMCs
<ogra_> but i guess that is carried forward anyway ... or rather physically used from the original mount
<zyga> ogra_: I think that right now it doesn't matter
<zyga> ogra_: we only do bind mounts
<zyga> ogra_: and the code as written is only a stab at the generic functionality
<ogra_> yeah
<mup> PR snapd#3210 opened:  tests: relax network-bind interface regexps for 2.24 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3210>
<mup> PR snapcraft#1255 closed: Update rust plugin to set RUSTFLAGS <Created by ChrisMacNaughton> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1255>
<mup> PR snapcraft#1250 closed: Fixed links to doc <Created by andyli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1250>
<mup> PR snapcraft#1251 closed: cli: remove empty lines in the unclean parts message <Created by EduardoVega> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1251>
<NicolinoCuralli> hi all: it seem that there is a misalignement between  https://snapcraft.io/docs/reference/interfaces and the result of snap interfaces on  a snap core 1580; ex network-manager is on wiki page but not in snap interfaces output
<ogra_> NicolinoCuralli, well, depends on the context
<NicolinoCuralli> naturally snap connect don0t work for that interface
<ogra_> NicolinoCuralli, on a classic install where network-manager is pre-installed for your desktoop, the interface is provided by this ...
<NicolinoCuralli> ogra_ : i run in a strict mode
<ogra_> on a core image on some developer board there is no network-manager, thus there is no interface for it until you install the network-manager snap
<ogra_> so the interface is context dependant
<NicolinoCuralli> ogra_ : i understood , thanks
<ogra_> :)
<davidcalle> NicolinoCuralli: although, you can install the network-manager snap https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/installation
<ogra_> indeed
<donofrio> anyone know how to force a refresh that actually loads snappy reposities?  I tried but I just get this https://apaste.info/8eil
<ogra_> donofrio, that is not how snaps work
<ogra_> there are no local ppackage lists you need to refresh like you have in apt
<ogra_> (also ubuntu-core is obsolete ... the snap is only called "core" nowadays)
<donofrio> ogra_, how do I use this good project then....when I try "snap install --classic anbox-installer" from https://github.com/anbox/anbox/blob/master/README.md#installation I just get no snap found ;(
<ogra_> donofrio, thats a normal ubuntu install ?
<donofrio> uh yah
<ogra_> (i dont think classic snaps work anywhere else currently)
<ogra_> whats the output of "snap version" (shoudl return 5 lines)
<ogra_> donofrio, oh, also ... nevver use "sudo su -" it will unset a lot of environment ... use sudo -s or sudo -i and not su
<ogra_> (snapd definitely uses some env that would be dropped by "su -" )
<ogra_> (but thats a general rule not snap specific ... su - is always bad unless you want to be in a new env)
<ogra_> niemeyer, since when does an empty "snap find" actually return one/two packages ? thats new ...
 * ogra_ gets lxd, docker, mongo32 and rocketchat-server as returns here 
<ogra_> i wonder if something regressed in 2.24 in that regard
<niemeyer> ogra_: I think the idea was always to have a stock list of interesting snaps there.. if they're too few, probably something needs fixing
<niemeyer> ogra_: Can you open a topic on forum under "store"?
<kyrofa> ogra_, do you know if ubuntu core 16 has an image in AWS?
<ogra_> kyrofa, i dont actually ... but i dont see why the normal x86 image wouldnt work ...
<kyrofa> Yeah, I just see blog posts from 2014 saying "hey, it's on AWS!" like it was hard, so...
 * kyrofa actually goes to check for himself
<ogra_> niemeyer, https://forum.snapcraft.io/t/empty-snap-find-suddenly-returns-four-snaps-but-not-more/323/1
<ogra_> kyrofa, it was hard back then ... it needed some special packages added ... but that need was dropped
<ogra_> (we used to actually build special AWS images in 15.04 snappy ...)
<kyrofa> ogra_, yeah, the only results I'm seeing are in the community AMIs, and that's only 15.04
<kyrofa> niemeyer, do you know anything about ubuntu core on AWS?
<ogra_> kyrofa, rharper does perhaps ... being in the cloud team
<niemeyer> kyrofa: Not much to be honest
<kyrofa> niemeyer, trying to figure out how to test a CUDA setup without buying an expensive video card :P
<ogra_> all i know was that i was asked to drop the AWS hacks before 16 because it would "just work" now
<kyrofa> ogra_, good deal, thank you
<niemeyer> ogra_: Thanks for the topic
<sergiusens> jdstrand: tyhicks can I get your opinion on https://forum.snapcraft.io/t/asset-recording-for-a-built-snap/317?u=sergiusens
<tyhicks> sergiusens: nice! I'll need a little bit of time to think it over
<sergiusens> tyhicks: no rush
<mup> PR snapcraft#1260 closed: meta: version from git support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1260>
<jdstrand> sergiusens: I saw it and like tyhicks, plan to think about it and comment
<mup> PR snapcraft#1264 opened: tests: do not print coverage check message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1264>
<morphis> zyga: can you have a quick look at https://paste.ubuntu.com/24414168/ ; not an expert yet in reading those expect scripts
<morphis> zyga: look at the bottom
<zyga> morphis: looking
<zyga> morphis: those expect-based tests are very unreliable
<zyga> morphis: just run it a few times, if it fails still it's interesting
<morphis> they reliable fail on debian :-)
<zyga> morphis: in that case run those manually in a debug shell
<zyga> morphis: and see what you get
<zyga> morphis: maybe PS1 discrepancy or something
<morphis> hm, that is a good idea
 * zyga goes for a walk, ttyl
<morphis> zyga: that's it
<zyga> morphis: aha, PS* differences?
<morphis> $ bash --norc -i
<morphis> that gives different prompts on debian vs. ubuntu
 * zyga completed backup
<zyga> ttyl :)
<mup> PR snapcraft#1203 closed: Add some initial checks to intelligently build the initial snapcraft.yaml <Created by mhall119> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1203>
<mup> PR snapd#3211 opened: assertions: add "repair" assertion  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3211>
<Pharaoh_Atem> morphis: please open a review for snapd-xdg-open
<Pharaoh_Atem> at this point, I don't care anymore and I want this in Fedora now
<Pharaoh_Atem> zyga: have you had a chance to respond in the email thread started by mattdm?
<zyga> Pharaoh_Atem: no, you are right, I should do it now
<Facu> sergiusens, anybody, my snapcraft branch in travis failed with:
<Facu> The command "if [ ! -z $CHECK_CLA ] && [ "$TRAVIS_PULL_REQUEST" != "false" ] && [ "$TRAVIS_EVENT_TYPE" != 'cron' ]; then docker exec -i builder ./tools/cla_check_in_travis.sh; fi" exited with 1.
<Facu> do you have any idea about what is it? why a CLA check may have failed? it's not my first branch for snapcraft
<sergiusens> Facu: because you authored the commit with an email that has not signed the CLA or is not @canonical.com
<Facu> sergiusens, mmm, that may be it (I'm not @canonical.com in github), but it would suprise me how the other branch got in
 * Facu checks
<sergiusens> we started enforcing the check recently to avoid these oversights
<sergiusens> Facu: looks like you used gmail in this last one and "Author: Facundo Batista <facundo@taniquetil.com.ar>" in one that passed
<Facu> gmail????
<sergiusens> hmm, I don't know what is going on, which is why I assigned to elopio
<Facu> sergiusens, "git log" in my computer says the Author is facundo@taniquetil.com.ar (expected)
<Facu> sergiusens, where are you finding the gmail mail address?
<sergiusens> I am not... anymore ;-)
<elopio> Facu: hello.
<elopio> Facu: I think that the error will go away after rebase with master. I will hit the update button in your pr.
<Facu> :o
<Facu> elopio, thanks
<Facu> here https://launchpad.net/~facundo it says I signed the contributor agreement on April 3rd
<renat> Hi, guys! It's Renat from Screenly.
<mup> PR snapcraft#1265 opened: shell_utils: code cleanup <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1265>
<zyga> Pharaoh_Atem: replied
<renat> I have a question related to the warning message from the store
<renat> (NEEDS REVIEW) 'daemon' should not be used with 'browser-support' security-snap-v2_daemon_with_browser-support (viewer)
<renat> Is it possible to make the store accept a daemon service with a browser support plug?
<renat> To make it automatically.
<zyga> renat: most likely no, why do you need a daemon to have browser support permissions?
 * ogra_ guesses thats a jdstrand question ... there are surely reasons to not allow browser daemons 
<zyga> renat: browser-support is a special interface that we really only expect to hand out to specific browsers
<zyga> renat: and nobody else
<zyga> renat: as it is exceptionally open to support various things modern browsers do
<ogra_> zyga, well, there might be browsers in kiosk mode ...
<ogra_> which i assume this boils down to
<zyga> ogra_: aha
<zyga> ogra_: daemon mode browser is an interesting case
<ogra_> yep
<zyga> still feel like a hack
<ogra_> but i guess the seutrity team had reasons to not allow this combo yet
<zyga> because runs as root
<zyga> yes, it's super powerful and open
<ogra_> *security
<renat> zyga, ogra_, we use it for digital signage.
<renat> And it's really running in a daemon mode.
<zyga> renat: please open a thread on the forum, I will reply tere
<zyga> there*
<pstolowski> it would be great to have second review on 3159 and land it
<renat> zyga, forum? You mean - write to the mailing list?
<zyga> renat: see forum.snapcraft.io :-)
<zyga> pstolowski: done
<renat> Wow. Okay.
<mup> PR snapd#3159 closed: store: retry once on hashsum mismatches in a Download() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3159>
<pstolowski> zyga, cool, thanks
<zyga> pstolowski: I'd love to land https://github.com/snapcore/snapd/pull/3203
<mup> PR snapd#3203: interfaces/mount: add ReadMountInfo and LoadMountInfo <Created by zyga> <https://github.com/snapcore/snapd/pull/3203>
<zyga> mvo: I added some comments on https://github.com/snapcore/snapd/pull/3211/
<mup> PR snapd#3211: assertions: add "repair" assertion  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3211>
<mup> PR snapd#3212 opened: api, ifacemgr: resolve disconnect early <Created by stolowski> <https://github.com/snapcore/snapd/pull/3212>
<zyga> mvo: quick question, aren't models specific to a brand?
<zyga> mvo: so would we need a list of pairs there or would a single repair be associated with the publisher and somehow implying which brand is affected?
<mup> PR snapcraft#1266 opened: tests: report coverage only in unit tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1266>
<renat> Done: https://forum.snapcraft.io/t/suppress-the-security-snap-v2-daemon-with-browser-support-warning-for-the-snap/325
<zyga> renat: thanks!
 * zyga -> break
<pstolowski> zyga, +1
 * pstolowski eod
<pstolowski> o/
<elopio> Facu: yes, it's green now. So, we had a commit from a private github email and thus we couldn't check CLA there. If you have an outdated PR, travis will add on top all the commits that you are missing from master, and then run the tests.
<elopio> if you sync with master, it will just pull your commits, and not check the CLA on things that were already merged.
<Facu> elopio, thanks
<jdstrand> renatu (cc ogra_ and zyga): I responded to the forum post
<mup> PR snapcraft#1264 closed: tests: do not print coverage check message <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1264>
<mup> PR snapcraft#1265 closed: shell_utils: code cleanup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1265>
<mup> PR snapcraft#1267 opened: meta: override the version with version-script <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1267>
<mup> PR snapcraft#1195 closed: [experimental] run unit tests in osx <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1195>
#snappy 2017-04-20
<mup> Bug #1684343 opened: For candicate release is appearing on dragonboard the message "ERROR hal_remove_bsskey response failed err" <Snappy:New> <https://launchpad.net/bugs/1684343>
<mup> PR snapcraft#1266 closed: tests: report coverage only in unit tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1266>
<zyga> good morning
<koza> hey
<mup> PR snapd#3201 closed: interfaces: re-add reverted ioctl and quotactl (revert 21bc6b9f) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3201>
<zyga> hey mvo, how are you doing today?
<mup> PR snapd#3206 closed: [2.24] Add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3206>
<mup> PR snapd#3210 closed: [2.24] tests: relax network-bind interface regexps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3210>
<mvo> hey zyga! I'm doing fine, how are you?
<zyga> mvo: good, 3rd night in the tent now :) I used a sleeping bag this time, had a full night sleep for the first time (earlier I would wake up as it's not that warm at night yet) :-)
<zyga> mvo: doing reviews, then will jump into a problem I didn't solve last evening
<mvo> zyga: tent> fun!
<zyga> pstolowski: commented on the disconnect PR, have look please
<pstolowski> zyga, sure, thanks
<pstolowski> zyga, and i commented on 3208
<zyga> pstolowski: repliiied
<pstolowski> zyga, very good point about new snapd running old tasks, thanks!
<zyga> pstolowski: my suggestion would be a patch that converts such a task to the new configuration
<zyga> pstolowski: but that's not without issues itself
<zyga> pstolowski: though unlike other patches it would not need to be undone
<zyga> pstolowski: as old snapd can handle that too
<pstolowski> let's create a forum topic maybe
<zyga> OK
<pstolowski> actually existing topic is fine for that
<mvo> pstolowski: looks like 3070 has a open question from gustavo - is that addressed? if so, I think the PR is good to go
<mup> PR snapd#3207 closed: tests: relax network-bind interface regexps <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3207>
<pstolowski> mvo, thanks, if you mean the comment re having a test for revert case, than yes, it's addressed, i've just added a comment
<mvo> pstolowski: great, thank you.
<mvo> pstolowski: it looekd addressed to me but I wanted to double check :)
<mup> PR snapd#3070 closed: overlord: maintain per-revision snapshots of snap configuration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3070>
<Chipaca> good morning!
<zyga> Chipaca: good morning, how are you feeling?
 * Chipaca is back from the dead
<Chipaca> zygaâ no fever today, but something is still up
<Chipaca> as if my vision had lag
<mwhudson> https://forum.snapcraft.io/t/snapcraft-autopkgktest-failure-in-zesty/337 oh god
<Chipaca> can we tell it >= instead of =?
<Chipaca> no, we can't ("E: Unable to locate package hello>")
<pstolowski> do we actually need to specify version number there?
<mwhudson> you could make a dummy package that depended on hello (>= whatever)
<mwhudson> and install that
<mwhudson> sbuild and pbuilder both have helpers for that iirc
<mwhudson> bit of a run around though
<morphis_> mwhudson: hey! if you didn't saw it yet: https://github.com/snapcore/snapd/pull/3156
<mup> PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<mwhudson> morphis_: nice
<morphis_> mwhudson: its close to be ready, just three remaining tests I need to debug
<morphis_> mwhudson: btw. are there any big differences in the debian packaging bits to what we have in the snapd tree?
<mwhudson> morphis_: well the devendoring is the big thing i guess?
<mwhudson> otherwise, no not really i think
 * mwhudson is not here btw
<morphis_> mwhudson: you mean you have individual deb packages in debian for each golang package snapd uses
<morphis_> mwhudson: ah :-)
<mvo> morphis_: 3177 has a unit test failure it seems (just in case you have not seen it already)
<pstolowski> Chipaca, is https://bugs.launchpad.net/snapd/+bug/1660970 going to be covered by your tab-completion work?
<mup> Bug #1660970: snap info could autocomplete against installed snaps <snapd:New> <https://launchpad.net/bugs/1660970>
<morphis_> mvo: yeah, thanks, already looking into that one
<Chipaca> pstolowskiâ umm
<Chipaca> pstolowskiâ so, no
<morphis_> mvo: looks like something broke after my last rebase on master
<Chipaca> but let me read the bug; it's probably invalid, at least as stated in the title
<Chipaca> pstolowskiâ i can fix this easily :-)
<pstolowski> Chipaca, :) cool
<renat> Hi! It's Renat from Screenly=) I have another question to you=)
<zyga> hey renat
<renat> We configured auto-connection for our snap almost successfully, but dbus plugs and slots don't connect automatically to each other=(
<renat> Let me post here our snap config
<zyga> to each other where? in one snap?
<renat> zyga, yes
<renat> https://paste.ubuntu.com/24419051/
<zyga> renat: not sure why yet BUT, if you use core from the edge channel then each auto-connect logs why it doens't do something
<zyga> renat: so you could install your snap and just read the message
<renat> I will try, thanks!
<Chipaca> zygaâ is there any reason why 'snap interfaces' isn't completing? (i mean one level up from "because the code isn't written")
<zyga> Chipaca: no
<Chipaca> zygaâ same question but about disconnect, now :-)
<zyga> Chipaca: also completion for connect is not as smart as I wish it was
<zyga> Chipaca: same answer :)
<Chipaca> zygaâ oh? tell me more
<zyga> I think connect was a proof of concept
<zyga> and that was just merged but I didn't iterate
<Chipaca> ah
<zyga> if you look at connect, it's really dumb
<zyga> what it should really do
<zyga> is complete only those that you can connect in practice
 * zyga is stuck at a harder part of update-ns
<Chipaca> zygaâ how can you know what you can connect?
<zyga> I think I will break for a moment and do something else, explore the easier parts again and write spread tests
<zyga> Chipaca: well, the interfaces must match
<Chipaca> zygaâ oh you mean for the second argument?
<zyga> Chipaca: but also you need to see that something can have more than one connection at a time
<zyga> Chipaca: and when you factor in hooks it's even more interesting
<Chipaca> right now the second arg doesn't complete at all
<zyga> Chipaca: yes
<zyga> Chipaca: anyway, look at it and think, I'm sure you will come up with a more complete picture than my rusty memory
<Chipaca> grmbl
<Chipaca> zygaâ I'll start with the simpler stuff :-)
<icey> any ideas why suddenly I have `Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path`
<icey> well, with apt or source, snap seems to work fine :)
<mup> Bug #1684525 opened: panic: assignment to entry in nil map <Snappy:New> <https://launchpad.net/bugs/1684525>
<Chipaca> zygaâ ^ that backtrace talks about content interface
<zyga> Chipaca: I fixed that yesterday
<Chipaca> :-)
<wligtenberg> I need to log into a webex meeting, I know it can be a pain to set up on ubuntu 16.04 64 bit. Would it be possible to create a snap with firefox and the correct java packages so that everything will just work? It should also connect to webcam and sound. What would the difficulty level be?
<zyga> wligtenberg: after a firefox snap exists, not high
<zyga> wligtenberg: before, I'd wait
<wligtenberg> zyga: does a firefox snap exist? I am not fully aware of all snaps :)
<zyga> wligtenberg: I don't think a stable one exists yet
<wligtenberg> zyga: ok, thanks. Then I will have to resort to the windows VM I guess. It would be a very cool use case I think. No more try all these things and you might get it to work, but just use this snap. :)
<ogra_> iirc there is a chrome one though (but also only in the edge channel)
<zyga> I agree, I think it's coming though
<wligtenberg> Although it would be even better if Cisco would just play nice with Linux...
<ogra_> snap install chrome-test --edge
<wligtenberg> ogra_: As far as I know, chrome is more difficult since it has stopped java support, which is required.
<ogra_> thats the proprietary chrome though ... it might have more than chromium (it takes 5min to try out if you want to check ,... snaps are easily installed/uninstalled without any harm for your system)
<wligtenberg> ogra_: good point, will just see if it works. :)
<ogra_> ;)
<Chipaca> and that's 5 minutes on *ogra_'s* connection :-)
<ogra_> haha, yeah
<Chipaca> he's got a very speedy dialup
<Chipaca> :-)
<zyga> I-S-D-N
<ogra_> of them get you 1.2Mbit!)
<ogra_> bah
<ogra_> (10 of them get you 1.2Mbit!)
<mcphail> wligtenberg: curious to know if you can get this to work. Was hoping to join a webex next week
<awi> hi
<mup> PR snapd#3213 opened: snap: require snap name for 'revert' <Created by stolowski> <https://github.com/snapcore/snapd/pull/3213>
<wligtenberg> ogra_ mcpahil: using the chrome snap does not work. It downloads a java webstart thingy but cannot execute that.
<ogra_> well, was worth a try at least
<wligtenberg> ogra_ I agree, it is the beauty of snaps :)
<mvo> niemeyer: if you could add tags for sergio and elopio to the forum, that would be great! this way we can use @upcoming @sergio to assign things to them :)
<pstolowski> refresh-delta-from-core failed in my branch https://travis-ci.org/snapcore/snapd/builds/223897482
<mvo> pstolowski: when did that fail? about ~3h ago there was a misconfiguration in u1
<mvo> pstolowski: if its a recent failure we need to talk to them again
<pstolowski> mvo, 4 minutes ago if travis is not laying
<mvo> pstolowski: hm, then I think we need to talk to #u1
<pstolowski> mvo, who is our person to talk to?
<pstolowski> mvo, ah, ok, i see you raised that already
<mvo> pstolowski: yes
<pstolowski> thanks!
<zyga> pstolowski: FYI I saw that many times this week
<mup> PR snapcraft#1267 closed: meta: override the version with version-script <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1267>
<ogra_> mvo, hmm ... i think we need to either finally land the systemd changes in xenial or at least update our package https://forum.snapcraft.io/t/cant-install-libudev-dev-in-classic/333/3
<wligtenberg> mcpahil: This docker approach seems to work https://hub.docker.com/r/dnk8n/docker-webex/ , at least I can join the webex test. After tonight I will know more. I will try this, and have my windows VM as backup.
<mup> PR snapd#3214 opened: cmd/snap: iterate interface tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3214>
<wligtenberg> So I was definitely not the first person with the idea :)
<mup> PR core-build#6 opened: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <https://github.com/snapcore/core-build/pull/6>
<mvo> ogra_: yeah, just noticed this too. very annoying, its the result of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1659195
<mup> Bug #1659195: resolver regression on ubuntu-core from #1636912 <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1659195>
<ogra_> yeah
<pstolowski> mvo, nice idea with using iptables for 3197! looks very promising
<mup> PR snapcraft#1268 opened: Added link to forums in the Get in touch section <Created by Ads20000> <https://github.com/snapcore/snapcraft/pull/1268>
<renat``> Hi, again=)
<renat``> zyga, seems, it doesn't connect because of multiple candidates for connection.
<renat``> Apr 20 09:02:10 localhost.localdomain /usr/lib/snapd/snapd[1181]: task.go:303: DEBUG: 2017-04-20T09:02:10Z INFO cannot auto connect udisks2:service (slot auto-connection), candidates found: "screenly-client:udisks2, udisks2:client"
<renat``>  
<renat``> For example.
<renat``> How do I specify slots for auto-connection?
<renat``> In this particular situation - I want both, but there is another message:
<renat``> auto connect screenly-client:command-dbus-client (plug auto-connection), candidates found: "screenly-client:command-dbus-server, screenly-client:ping-dbus-server, screenly-client:playlist-dbus-server"
<renat``>  
<renat``> And I only want to connect to one of them.
<zyga> renat``: I started discussing this topic here https://forum.snapcraft.io/t/what-should-the-auto-connect-logic-be-like/312
<renat``> Thanks! Joining
<morphis_> zyga: joining us?
<zyga> oh
<zyga> sorry sure
<zyga> no notification :/
<morphis_> mvo: 2.24 is going out today or next thursday?
<mvo> morphis_: the tenative plan is today, we will talk about it in todays standup, feel free to join, its in 7min
<mvo> morphis_: tenative because there is a lot of stuff tagged as 2.25 which is not in yet
<morphis_> mvo: ok, I have another meeting in 5min but that is already all I wanted, thanks :-)
<mvo> morphis_: we need to consult JamieBennett on this too, the stable release is currently done by him. if 2.24 goes out today or not is something we also discussed via mail with tony but no final decision yet afaik
<morphis_> ok
<morphis_> mvo: I was more interested of the perspective when we can push the packages for fedora/suse/yocto out
<mvo> morphis_: aha, I see. for those 2.24 is fine to push out (it is already released upstream). if you mean 2.25 (which is the next release which is currently wrapped up), then today is the tentative plan but things might get delayed because of $stuff
<morphis_> mvo: I was thinking more of we should always align to the stable core snap with that release as their may be dependencies
<Chipaca> zygaâ standup
<zyga> ah, sorry
<mup> PR snapcraft#1269 opened: tests: fix package version pinning tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1269>
<Son_Goku> mvo: let me know if we are releasing 2.24 today, so that I can push the button to release it for all Fedora releases
<pedronis> mvo: fwiw systemd-run takes a --slice=  and IÂ see a user-USER.slice but then there's also a session-xx.scope under the slice and IÂ don't see systemd-run taking a scope
 * zyga -> lunch
<niemeyer> mvo: Done
<niemeyer> 527 members on the devices mailing list.. there we go again
<mup> PR snapd#3213 closed: snap: require snap name for 'revert' <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3213>
<ogra_> niemeyer, FYI https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L28 is what we allow today ... when we change the whole thing i think snap-confine should actually look up which mimetypes are supported on the desktop side and put some file on top of that mimeapps.list file relfecting reality on the desktop side ... (would be a quesrtion to zyga how hard that would be to implement)
<Chipaca> ogra_â note there are two sides to the allowing, and i think niemeyer was pointing to the other side
<ogra_> ah
<ogra_> *that* was the misunderstanding then :)
<Chipaca> ogra_â either that, or there are two implementations of the same thing written in completely different languages
<niemeyer> ogra_: Yes, what is inside core or the snap is irrelevant..
<ogra_> niemeyer, not for the snaps
<ogra_> niemeyer, if my snap wants a file:// url this will not work today
<niemeyer> ogra_: In terms of security, the snap can perform that dbus-send call with whatsoever it wants
<ogra_> so the info that the desktop knows how to handle file:// is a valuable info we should forward to the inside of core (which is what my question above is about, regarding snap-confine)
<ogra_> sure but it will be a no-op for anything we dont define in that file
<ogra_> (or even cause an error on the snap dside, havent tested this)
<niemeyer> !?!?
<niemeyer> ogra_: This is completely irrelevant.. dbus won't consult that file to perform the call, nor will the daemon on the other side
 * ogra_ has the feeling ou dont understand me ... 
<Chipaca> ogra_â gustavo is talking about security
<Chipaca> ogra_â you're talking about usability
<Chipaca> both are needed
<ogra_> right
<niemeyer> ogra_: I have the feeling we're talking across purposes indeed.. you raised security concerns in our call today. That's what I'm talking about.
<ogra_> i talk about what the snap sees and what the user ends up with in the current situation
<ogra_> if we re-do the world we need to re-do this bit too ... thats all i'm saying
<ogra_> (and i propose that snap-confine handles it)
<ogra_> niemeyer, that were no security concerns but rather "xdg-open will open anything, not just a browser ... completely unrelated to security
<niemeyer> ogra_: If a snap could open anything with xdg-open, that'd be a major security concern.. that's exactly the topic above.
<niemeyer> ogra_: It can't, and it's not because of those files you referred to
<ogra_> well, thats an xdg-open thing ...
<niemeyer> ogra_: But because the daemon will anything not accepted
<niemeyer> * the daemon will reject
<niemeyer> ogra_: We don't use xdg-open *at all* today.. it's simply an executable with the same name
<ogra_> right, currently the mimeapps.list file makes us reject even before it goes anywhere
<niemeyer> ogra_: Once more (and last, I think), mimeapps is irrelevant.. the dbus call that is inside that xdg-open call can be carried with any URL.. it's the daemon that will prevent arbitrary URLs from being opened
<ogra_> what i'm saying from a UX/snap perspective is that we should have that bit dynamically based on the capabilities the actual desktop exposes
<niemeyer> ogra_: You're flipping back and forth between UX and statements such as "xdg-open can open anything"..
<niemeyer> ogra_: Our xdg-open can't...
<niemeyer> and it shouldn't
<ogra_> it should allow the exact same any other desktop app is capable to when using a MRL/URL
<ogra_> which is defined on the desktop side
<ogra_> but not carried through as info to the core snap
<niemeyer> ogra_: Nope, our xdg-open needs to be security aware...
<niemeyer> ogra_: and btw, mvo is right.. polkit is unrelated.. the daemon would need to integrate with polkit for it to work, and it doesn't today
<ogra_> well, then we shoudl make that work ... but since you want to drop that anyway i wont argue about security anymore ;)
<niemeyer> ogra_: Don't worry about that feature. We'll sort it out.
<morphis> niemeyer, ogra_: I think there are two things we're mixing here, one is carrying what we have right now (http://) forward also to other distributions and the other thing is support for other URI's like tel:// or similar
<niemeyer> ogra_: We're not dropping anything.. we're evaluating a different way of doing it that might help cross-distribution support. It's about being open minded enough to accept exploring ideas and perhaps falling back if it turns out to be a dead end.
<morphis> once we have sorted the first one we can use the same implementation to add more things if needed
<ogra_> morphis, right, that was my point ... the core snap should have the info what the desktop side supports before even offering it to the snap
<niemeyer> morphis: Right
<morphis> ogra_: what do you mean by that? what kind of info should the core snap have?
<ogra_> morphis, mime types
<morphis> right, but that is a different story we can solve later on
<ogra_> morphis, https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L23 defines the supported mime types a snap sees
<morphis> we first need a way to talk with the classic desktop at all
<niemeyer> ogra_: You had several points, actually, and most of your posts on that thread don't contribute to the conversation but rather just create controversy.. and in some cases are just plain wrong, such as the polkit statements. Please try to collaborate towards a solution.
<ogra_> morphis, and since i try to drop any arguing about security, thats another bit i would like to see solved which is why i brought it up here
<niemeyer> ogra_: For contrast, see morphis's last post on the thread. This is what good feedback looks like.
<morphis> ogra_: shouldn't that be just x-scheme-handler/http;x-scheme-handler/https ?
<morphis> ogra_: as that are the only two mime types snapd-xdg-open currently allows
<ogra_> morphis, PRs accepted :) i thought we hand through mailto as well at least
<morphis> ogra_: we do?
<ogra_> (that script isnt mine, i think tvoss wrote it initially)
<morphis> ah right
<morphis> https://github.com/snapcore/snapd-xdg-open/blob/master/src/snapd-xdg-open.c#L67
<morphis> both should be in sync always and I agree there could be a better way to keep both in sync
<ogra_> rigth
<morphis> ala letting snapd ship both xdg-open and xdg-open.desktop so we can control both
<morphis> in the same place
<Saviq> hey all, any idea which plug we'd need to connect to get an Electron app to work confined? http://pastebin.ubuntu.com/24420540/ is the denial I'm getting
<ogra_> Saviq, i thought only browser-support
<morphis> Saviq: there is an attribute for the browser-support interface you may have to set too
<morphis> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L250
<morphis> allow-sandbox: true
<Saviq> morphis, aha, any idea if that can be done with auto connection?
<morphis> Saviq: you need to ask at the store level for a proper snap-declaration assertion for this
<ogra_> Saviq, all my electron snaps did auto-connect over here ...
<ogra_> so that shoudl definitely work fine
<morphis> Saviq: but could be that you can set some switches for electron too to disable sandboxing for chrome
<ogra_> snap install snapcraft-forum ... or rocketchat-desktop ...
<morphis> niemeyer: so how do we take this further? do you want some more time to think about this or should I get a meeting up to discuss this with all involved people?
<Saviq> ogra_, you using electron-builder?
<ogra_> Saviq, i think ryan uses it for the snapcraft-forum one ... not sure about the rocketchat one
<ogra_> (sadly ryan didnt publish his snapcraft.yaml)
<Saviq> might be because it's autogenerated by electron-builder ;)
<niemeyer> morphis: My last hope is being able to properly ask systemd itself to fire the process inside the user session.. mvo is not super optimistic, but said he'd have a quick look into it. If that turns out difficult or awkward, then we'll need to go back to having a daemon inside the user session.
<ogra_> ah
<morphis> niemeyer: the problem with that is that systemd doesn't control the user session on all distros
<ogra_> niemeyer, you dont need any daemon (and we never had one)
<morphis> niemeyer: on 14.04 and 16.04 it doesn, on 16.10 you could use systemd-run --user to do that
<ogra_> niemeyer, there is just a dbus listener service ... that doesnt mean anything is running
<morphis> niemeyer: so it is possible but not really portable
<niemeyer> ogra_: I'm sure morphis understands what I'm talking about
<niemeyer> morphis: I see.. hmmm
<morphis> niemeyer: I can give `systemd-run --user`a try later on on 16.10 if that would solve it but that would be a super long term solution
<niemeyer> morphis: Isn't that a short cut for a more complex set of options that might be used in 14.04.. I note it supports --slice
<morphis> niemeyer: given that we need to support 14.04 / 16.04 till 2020
<morphis> niemeyer: --slice isn't enough as it doesn't affect the process hiearchy
<morphis> I used that in my example I gave on the forum post
<niemeyer> morphis: --user is a way of selecting which service manager it's talking to, right?
<morphis> right
<niemeyer> morphis: Can't we explicitly select that service manager some other way?
<niemeyer> morphis: Manipulating environment or whatever
<morphis> niemeyer: we can hack and get the DBUS_SESSION_ADDR from a process inside the session and then talk to it
<niemeyer> morphis: How does it find out the proper service manager nowadays?
<niemeyer> morphis: Sounds promising
<morphis> however that doesn't solve the problem that we have to support upstart and systemd
<morphis> niemeyer: its defined somewhere within the lightdm configuration if I am not wrong
<niemeyer> morphis: snapd doesn't work with upstart today, I think
<morphis> niemeyer: right
<niemeyer> morphis: Ah, wait, I get what you mean
<niemeyer> Need to step out for a couple of minutes.. brb
<morphis> niemeyer: we basically need to support for initctl --user and systemctl --user and for the upstart variant we need to craft our own .conf file and ship it as part of the snapd deb package
<morphis> niemeyer: I think that really adds only more complexity to the whole situation than we want
<jdstrand> Saviq: briwser-support should be all you need. don't specify 'allow-sandbox: true' since electron apps don't need it
<ogra_> morphis, well, things like openbox dont even use upstart or systemd as session managers (while the DM cares for logind and dbus to always run for any desktop)
<morphis> ogra_: right, that is what I meant with my last comment more or less, we have too many case to consider if we go this route which takes aways the simplicity we want to achive
<jdstrand> Saviq: you might have to set an env var or something to disable the sandbox, but I don't think that is necessary (someone could correct me)
<ogra_> exactly
<Saviq> jdstrand, I didn't, but still getting denials like http://pastebin.ubuntu.com/24420628/ - doesn't work unless --devmode
<morphis> jdstrand: the electron apps don't use chromium sanboxing?
<ogra_> i dont think any webapps can
<Saviq> only thing about sandbox I can find is https://electron.atom.io/docs/api/sandbox-option/ but that doesn't seem to be that
<ogra_> iirc you have to actually invoke the binary with --no-snadbox
<ogra_> yeah
<niemeyer> morphis: Ack, does feel like a can of worms
<ogra_> /snap/snapcraft-forum/4/snapcraft-forum --type=renderer --no-sandbox --primordial-pipe-token=31B373498D
<morphis> niemeyer: yes :-)
<ogra_> Saviq, ^^^
<morphis> ogra_: ah!
<morphis> --no-sandbox is the key here
<ogra_> yeah
<morphis> ogra_: is electron using that by default?
<Saviq> ogra_, ack, thanks!
<ogra_> morphis, i dont know ... i would expect electron-builder to actually default to it
<ogra_> when building a snap :)
<jdstrand> morphis: they can use seccomp but not userns. electron apps don't need it, they are snappy sandboxed
<morphis> jdstrand: right
<jdstrand> allow-sandbox: true allows use of userns but grants a ton of privilege, so it is only used for official browsers
 * jdstrand takes a note to update the review tools to mention --no-sandbox with electron apps
 * jdstrand also updates the wiki
<ogra_> sergiusens, github sends me mondrian artwork about snaopcraft by mail suddenly !
<ogra_> (the color selection is a bit boring though ... only red, green and grey)
<apw> ogra_, hey did we jsut release a new core snap ?
<apw> i seem to have a lost loop device showing up which looks to be the 1337 version of the core snap
<Saviq> ogra_, hrmf, should I see something when running snapcraft-forum? I'm seeing "mmap() failed: Permission denied" and the same DENIAL... nothing else Â¿?
<Saviq> hmm hmm, works with --devmode, /me starts thinking this is something special about his host...
<Saviq> like... zesty
<mup> Bug #1684893 opened: "fonts", "themes" and "icons"  interfaces for desktop apps <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1684893>
<mup> Bug #1684896 opened: sha3-384 mismatch downloading lxd <Snappy:New> <https://launchpad.net/bugs/1684896>
<sergiusens> ogra_: err, what?
<ogra_> apw, not me, either JamieBennett or mvo do the releases nowadays
<sergiusens> Saviq: kernel >=4.10 needs snapd 2.24
<ogra_> Saviq, yeah there was a forum thread about it
 * sergiusens wonders why people still discuss things here :-P
<mup> Bug #1684896 changed: sha3-384 mismatch downloading lxd <snapd:New> <https://launchpad.net/bugs/1684896>
 * Saviq upgrades snapd
<sergiusens> mvo: are you pushing to zesty as the latest distro series possible and are you finding hassle in trying to do that?
<mvo> sergiusens: I'm pushing to zesty via the normal SRUs, I find it the same hassle as the other SRUs. or is that not the question?
<sergiusens> mvo: great, that is what I wanted to hear; was wondering if we were asked to wait for z+1 and anything like that
<cachio> ogra_, hey, I am starting some test automation for console conf, any advice about how to start that?
<ogra_> cachio, you want to read up about system-user assertions ...
<ogra_> not sure if we have anything for the networking side though ...
<cachio> ogra_, ok, nice
<cachio> ogra_, do you know where is the code stored for console conf?
<ogra_> cachio, it is the source package of "subiquity" ... not sure where the actual code lives, i would suspect on launchpad ... mwhudson is your man for details, he maintains it
<mup> PR snapcraft#1269 closed: tests: fix package version pinning tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1269>
<cachio> ogra_, ok I'll look up tx
<ogra_> i guess you can somehow find it under the subiquity project on LP
<kyrofa> ogra_, that's on GH now I think: https://github.com/CanonicalLtd/subiquity
<ogra_> sergiusens, re -> mondrian .... https://codecov.io/gh/snapcore/snapcraft/pull/1263?src=pr&el=continue
<mup> PR snapcraft#1263: Pass through commands into the lxd container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1263>
<ogra_> sergiusens, seems to send these reports to everyone and his grandmas addressbook by mail ...
<ogra_> (i dont mind, but it should really use more colors :P )
<mup> PR snapd#3215 opened: tests: address review comments from #3186 <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3215>
<kyrofa> Oh cachio I guess that github subiquity link was for you
<kyrofa> Man that word is hard to type
<cachio> ky, yes I saw that, thanks
<cachio> kyrofa, yes I saw that, thanks
<mup> PR snapcraft#1270 opened: release changelog for 2.29 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1270>
<morphis> jdstrand: do you have time to look at https://github.com/snapcore/snapd/pull/3177 again today?
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<jdstrand> morphis: yeah
<morphis> jdstrand: thanks!
<jdstrand> let me phrase that another way. I'll look at it today :)
<jdstrand> let's leave having time out of it :P
<mvo> morphis: I fixed a bunch of conflicts and reopened 2592
<mup> PR snapd#2592 opened: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<mvo> morphis: we talked about this the other day, tomorrow I will continue with ensureing the snapd.conf is always available and refinements, then the session dbus bit should be good, we can then talk about system dbus too, hopefully straightforward
<Facu> git related question: I proposed a branch for snapcraft, and a change was requested; should I go back to my branch, do the change... and then what? one commit, then *squash* that commit to have only one in the branch, and then push?
<kyrofa> Facu, no, don't squash, the reviewers will be hard-pressed to see what changed
<kyrofa> Facu, just push up a new commit with the changes requested
<Facu> kyrofa, ah, thanks!
<kyrofa> Facu, any time, thanks for caring enough to ask! That's a good sign ;)
<Facu> :)
<icey> what are the requirements to get an alias accepted as the default way to access an app without renaming a snap?
<kyrofa> icey, just make a forum post in the store category requesting it
<icey> kyrofa: is the forum tied at all into SSO?
<kyrofa> icey, I don't think so yet
<icey> also, possible to get a review on new snap ripgrep, with classic confinement?
<icey> or
<icey> is there an interface for full filesystem access?
<mup> PR snapd#3203 closed: interfaces/mount: add ReadMountInfo and LoadMountInfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3203>
<mup> PR snapd#3216 opened: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216>
<icey> for reference, upstream pull request: https://github.com/BurntSushi/ripgrep/pull/455 :)
<mup> PR BurntSushi/ripgrep#455: Add snapcraft.yaml <Created by ChrisMacNaughton> <https://github.com/BurntSushi/ripgrep/pull/455>
<mup> PR snapcraft#1271 opened: tests: increase the staging registration limit to 100 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1271>
<zyga> gah gah gah
<zyga> my algorithm sucks
<zyga> this is surprisingly a hard problem :/
<zyga> given mountinfo data and a particular mount command answer if the command has ran and can be skipped
<lutostag> can somebody take a quick peek at https://bugs.launchpad.net/snappy/+bug/1679210 to at least triage it?
<mup> Bug #1679210: snap install --revision tracks stable by default <Snappy:New> <https://launchpad.net/bugs/1679210>
<catbus1> Hi, I assume the proprietary software/binaries can be snapped, how do I make it available to my paying customer?
<catbus1> and I assume if I don't want automatic update, I just don't update the channel like 'stable' the customers have access to, right?
<qengho> catbus1: There's a pricing model in the Ubuntu store, if you want to sell it that way, or you can run your own store, or you can put it anyone's store and make it available to everyone to download and test for some kind of license key file at startup.
<qengho> catbus1: as for updates, you can make a kind of sub-channel, I think.  So, you each customer or class of customer gets their own channel and you update by flipping states in the store.
<catbus1> qengho: thanks.
#snappy 2017-04-21
<zyga> good morning
<zyga> mvo: hey, do you prefer to talk here or do a hangout to introduce the problem quickly and then talk here?
<mvo> zyga: here or in the forum so that other may also benefit
<zyga> mvo: ok, let's do a quick conversation here, the rest can be done on the update-ns thread
<zyga> mvo: the first thing to look at is the general algorithm of the tool: https://github.com/snapcore/snapd/pull/3216/files
<mup> PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216>
<zyga> That code is fairly well commented and simple
<zyga> there are two kinds of input apart from the snap name
<zyga> the snapd-created mount profile
<zyga> and the kernel-maintained mount table
<zyga> if you have a look at the code there you can see that we read the desired mount profile (what we want to have in the mount namespace of a given snap) and compare it to what is currently there (what we wrote on prior run of snap-update-ns or snap-confine)
<zyga> from there we compute what to do, this is so far all the old code and there's nothing wrong with it AFAIK
<zyga> now once we know what to do we represent that as a list of mount changes to perform: either mount something or unmount something
<zyga> because we work with the simplistic fstab-like files written by snapd we don't really know what got mounted (e.g. by older version of snap-confine or by the snap itself)
<zyga> so we cross check each change with the mountinfo table
<zyga> and here is where the dragons are
<zyga> the interfaces/mount.Change.Needed function is non trivial
<zyga> before we jump into that, please let me know if this makes sense so far and if you have any questions?
<mvo> zyga: so far so good
<zyga> ok
<zyga> so I looked at the mountinfo table and talked to the kernel guys (initially I wanted to make a patch for the kernel to make this information easier to grok but later abandoned that idea)
<zyga> the mountinfo table has records with several fields, the most obviously important are MountDir which says where something is mountd (relative to the root filesystem) and MountSource (which says what is mounted)
<zyga> super important though not obviously so is the Root field which tells us the "root of the mount within the filesystem" (to quote kernel documentation)
<mup> PR snapcraft#1272 opened: tests: initial setup for the snapcraft snap tests with spread <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1272>
<zyga> as an example, I mounted tmpfs in my home directory "/home/zyga/data"
<zyga> then the Root field of that entry is "/" as the "whole" tmpfs is mounted there
<zyga> then I created a directory "/home/zyga/data/foo" and similarly "bar"
<zyga> and bind mounted foo over bar
<zyga> so now the subtree rooted at "/foo" (relative to the tmpfs itself) is mounted
<zyga> and the mountinfo entry for that speaks about MountDir: "/home/zyga/data/bar", with Root: "/foo"
<zyga> what is problematic now is that it's hard to know what is "/foo" relative to, we only see "tmpfs" filesystem name
<zyga> and arbitrary and irrelevant "none" that I passed as device name (via mount -t tmpfs none /home/zyga/data)
<zyga> so on quick look it's hard to say that "/foo" refers to a directory on the same filesystem that is mounted in /home/zyga/data/
<zyga> there are two more pieces of information
<zyga> each mount entry has two numeric values: MountID and ParentID
<zyga> in the example I was describing so far the root filesystem has MountID of 25
<zyga> the /home/zyga/data tmpfs has MountID of 392 and ParentID of 25
<zyga> the /home/zyga/data/foo -> /home/zyga/data/bar bind-mount has MountID 400 and ParentID of 392
<zyga> so here's my issue now:
<zyga> is this sufficient to create a tree of mounts and figure out the answer of Change.Needed or do we need additional information (e.g. collected by walking and stat'in the filesystem)
<zyga> I was hoping we don't
<zyga> the algorithm for solving the issue that I wrote so far was based on the following idea:
<zyga> when we are asked to perform a mount change
<zyga> to check if that thing is mounted already (for bind mounts)
<zyga> (because only bind mounts are harder)
<zyga> (perhaps I should explain why: because regular mounts describe what is mounted and where it is to be mounted fully
<zyga> while bind mounts describe the source indirectly
<zyga> as we don't know what is the nature of /home/zyga/data/foo from the fstab-like entry
<zyga> we just know we need to mount it on /home/zyga/data/bar
<zyga> so the idea behind that algorithm is as follows:
<zyga> look at the source of the bind mount (/home/zyga/data/foo) and resolve it to something absolute
<zyga> I chose to use the mounted device (e.g. /dev/sda2, but this breaks apart with tmpfs)
<zyga> and a path relative to that device
<zyga> (or to a filesystem on that device)
<zyga> and then compute all the things that are exactly the same
<zyga> so we get a set in return
<zyga> and if the destination of a bind mount is in that set we don't need to perform the change
<zyga> this works well for simple examples but for this tmpfs example I referred to it falls apart
<zyga> and I think I need to start using the MountID and ParentID
<zyga> unfortunately there's no easier way to check as far as I know
<zyga> let me know if this makes sense, I can show you what I have (the implementation of interfaces/mount/AliasesOf)
<zyga> and the array of tests I wrote
<morphis_> mvo: regarding dbus session bus activation, just give me a ping when the PR is ready and I will give it a try and do a review
<zyga> I can also convert this to a forum topic
<mvo> zyga: I think it does make sense
<mvo> zyga: this is all in the PR, right?
<mvo> morphis_: the most important missing piece is creating of /etc/dbus-1/session.d/snapd.conf in the re-exec case, that should be finish in some minutes I hope
<morphis_> mvo: great!
<zyga> mvo: I'll break to eat some breakfast and be back here soon
<mvo> zyga: what should I do next? review the PR ? or poke at the mountinfo stuff to see if there is an easier way to figure out the bind mounts?
<zyga> mvo: maybe look at mountinfo and see what you make of it
<zyga> mvo: specifically look how it looks like for snaps
<zyga> mvo: for tmpfs'es
<zyga> mvo: and regular filesystems
<zyga> mvo: just to build some extra intuition
<zyga> mvo: note that mountinfo is specific to the namespace your are observing it from
<zyga> mvo: so you may want to nsenter to a snap mount namespace as well
<mvo> zyga: ta
 * zyga -> breakfast
<morphis_> mvo, zyga: do you guys have time for another review on https://github.com/snapcore/snapd/pull/3177 today?
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<mvo> morphis_: yes
<morphis_> mvo: thanks
<mvo> pstolowski: hm,hm, I would love to merge 3119 but  I think we need a gustavo review first?
<pstolowski> mvo, indeed
<fgimenez> hi mvo: wrt the sru verification all is good for trusty, xenial and yakkety, we have an error that afaik is not a regression in the tests on zesty http://paste.ubuntu.com/24425481/ "snap create-key" hangs
<fgimenez> mvo: we found this in the branch that enabled expect tests for ubuntu-core systems, not until now on classic
<mvo> fgimenez: and it also hangs outside the tests?
<fgimenez> mvo: yep, i've tried manually on an up to date zesty and it hangs
<mvo> fgimenez: could you do a quick check if previous versions of snapd on zesty were also affected?
<fgimenez> mvo: sure on it
<mvo> fgimenez: thank you! if its a regression we need to do something, otherwise its ok, but obviously this needs attention :)
<mup> PR snapcraft#1273 opened: Check snap name <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1273>
<fgimenez> mvo: with 2.23.6+17.04.1 it hangs too http://paste.ubuntu.com/24425510/
<mvo> fgimenez: ok, "great"
<mvo> fgimenez: at least not a regression but this needs urgent attention, can you please create a forum topic and tag upcoming?
<mvo> fgimenez: strace of the hanging thing would be nice but I can check that in a bit on my zesty machine when I finished my current task
<fgimenez> mvo: sure, i'll update the sru bug too once the test run ends, only a few of them remaining
<mvo> ta
<fgimenez> mvo: https://forum.snapcraft.io/t/snap-create-key-timeouts/359
<wligtenberg> q
<pstolowski> $ snap changes everything
<pstolowski> Yes, yes it does.
<pstolowski> :)
<mvo> fgimenez: hm, confusing, I just tried snap create-key in a 17.04 vm with 2.23.6 /2.24 it works
<mvo> fgimenez: so maybe test related afterall? I ran the commands manually
<fgimenez> mvo: mm i tried manually too, let me check again
<mvo> fgimenez: what kind of machine? maybe I just need a different vm/machine. I can also test on real HW
<mvo> fgimenez: if you can reproduce it, a ps afx would be nice, also an strace
<fgimenez> mvo: yes, it hangs here, is your system up to date? maybe this is related to another package
<mvo> fgimenez: i.e. ps to see if there is gpg running
<martyix> Is there a web catalogue of existing snaps? I can't find it on https://snapcraft.io/
<fgimenez> mvo: sure, this is the strace http://paste.ubuntu.com/24425544/
<mvo> fgimenez: I upgraded it some minutes ago, but I did only install snapd from proposed, I can try everything from proposed now
<fgimenez> mvo: same here, this is a vm created with "adt-buildvm-ubuntu-cloud -a amd64 -r zesty"
<davidcalle> martyix: hi, closest you can find as a website is https://uappexplorer.com/apps?type=snappy&release=16 that lists all stable snaps. You can also simply use "snap find" on the command line
<fgimenez> mvo: this is ps afx http://paste.ubuntu.com/24425624/
<martyix> davidcalle: I know about "snap find". It looks good, thanks
<davidcalle> yw
<mvo> fgimenez: thanks, I will build a new vm just to be sure mine is not contaimiated ;)
<fgimenez> mvo: great thanks, i'll do the same :)
<morphis_> mvo, fgimenez: I see the create-key issue too, on Linode (latest git) and on my desktop (2.23.6)
<fgimenez> morphis_: thanks a lot for confirming! :) i'm seeing it too in my desktop, 2.23.1+16.10
<morphis_> mvo, pedronis: any idea what that can be?
<pedronis> morphis_: it works here with 2.24
<pedronis> morphis_: is the test that hangs, or just the command?
<morphis_> both
<mvo> morphis_: I still cannot reproduce
<morphis_> I see it on https://github.com/snapcore/snapd/pull/3156 for debian too
<mup> PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<morphis_> pedronis: happy to provide more data
<pedronis> mvo: yea, it works here too
<morphis_> pedronis: it doesn't seem to work with SNAP_REEXEC=0 too
<pedronis> morphis_: what is your gpg --version ?
<morphis_> also tried after removing my $HOME/.snap dir
<morphis_> 1.4.20
<morphis_> 1.4.20-1ubuntu3.1
<pedronis> same here
<Chipaca> guys, i'm going to head back to bed and wait for this to boil over
<Chipaca> see you on the other side
<morphis_> mvo: updated https://github.com/snapcore/snapd/pull/3177 with all requested changes
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<morphis_> pedronis, fgimenez: ok, now it worked again
<morphis_> fgimenez: do we purge $HOME/.snap during the spread tests before every test is executed?
<pedronis> morphis_: ?
<morphis_> pedronis: I did: mv $HOME/.snap $HOME/.snap-old and ran create-key again
<fgimenez> morphis_: i don't think so, let me check
<morphis_> it took quite some time but finished now
<morphis_> pedronis: interestingly I have now two default keys
<pedronis> well if you are creating the same key it should fail
<pedronis> in which sense two default keys?
<morphis_> pedronis: https://paste.ubuntu.com/24425759/
<pedronis> that is very weird
<morphis_> it is
<morphis_> trying to reproduce that
<morphis_> pedronis: do we save any state information outside of $HOME/.snap?
<NicolinoCuralli> hi all:  i am tryÃ¬ng to register a kernel, gadget, and assertion for a custom board on public store: how can i make sure that the assertion model is present on the store? i just upload kernel and gadget with the user owning the the signing key for the model assertion
<pedronis> morphis_: no
<pedronis> but we don't do locking either, wondering if gpg itself does locking
<pedronis> anyway that looks like create-key was run twice
<NicolinoCuralli> pedronis: your answwer are to me
<NicolinoCuralli> ?
<pedronis> NicolinoCuralli: no
<mvo> morphis_: \o/ - I have a look
<pedronis> NicolinoCuralli: there is no way to upload a model assertion to the store, it's also not strictly necessary, the thing that need to be in the store is key that signed it
<pedronis> IÂ mean the corresponding account-key
<renat> Hi, guys! =) It's Renat from Screenly.
<pedronis> this might change but atm is not  a requirement nor are there tools to get it there
<renat> I have a question about the timezone-control interface and the following ticket:https://bugs.launchpad.net/snappy/+bug/1650688
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<renat> That part is pretty critical for our system and I wasn't able to make it working.
<renat> What do you think about enabling write access to the /etc/writable/localtime?
<renat> For those who connected to the timezone-control slot, of course.
<NicolinoCuralli> pedronis: a further question:  what is the procedure to publish a kernel on public store? i upload kernel and gadget with a user owning the gpg key with i sign my model assertion: what I also need to make?
<morphis_> pedronis: ok, couldn't reproduce this a second time
<morphis_> pedronis: feels like I had another `snap create-user` process still running in the background
<pedronis> morphis_: yes
<pedronis> NicolinoCuralli: it needs to be approved by a reviewer which is a bit adhoc, notice that only devices with a model signed by the publisher of the kernel can use it
<morphis_> fgimenez: maybe we need to give the test case just a higher timeout
<pedronis> entropy issues?
<NicolinoCuralli> pedronis: ok : for me this restriction is ok; what about the time for a answer about problems with kernel and gaddget i uploaded?
<fgimenez> morphis_: yes, i'm trying to measure how much, in a zesty vm it has been stuck for 13min so far, let's see..
<pedronis> NicolinoCuralli: IÂ don't understand that question?
<morphis_> fgimenez: wow, that is a lot
<NicolinoCuralli> pedronis: how many time the review for kernel and/or gadget takes ?
<pedronis> NicolinoCuralli: ah,  IÂ don't know, I would ping jdstrand when is around here, he might know who to ping
<NicolinoCuralli> pedronis : thanks, i pinged jdstrand
<zyga> mvo: I wrote on the forum about my problem: https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23
<zyga> morphis_: ^^ insight appreciated
<mvo> zyga: yeah, just reading. so the kernel doc says that the mount-id is unique, does that help us?
<zyga> it is unique, yes (otherwise it'd be a poor ID); the issue is that we don't know what is really being shared in bind mounts
<zyga> the MountSource is useless (it's the device, that's fine but for virtual filesystems like tmpfs or others it's not unique)
<zyga> the end of the message contains this information, not sure if you read that far
<zyga> I also worry because gustavo wants to use this for overmount
<zyga> and I want to have a generic solution, not something that only sometimes kind of works
<zyga> I also suspect it's going to get more hairy if we use overlayfs
<zyga> but I didn't try
<mvo> zyga: ok, I clearly have not dived deep enough yet
<zyga> I'm trying from simple towards complex and I already got to a point where I feel stuck
<fgimenez> mvo: if the create-key problem is hard to reproduce we can go ahead with the sru verification and add a link to the bug (which wouldn't be a regression in any case), wdyt?
<morphis_> zyga: looking
<zyga> stgraber: hey, if you have a moment I could really use your insight: with https://forum.snapcraft.io/t/fixing-live-propagation-of-mount-changes/23/14
 * zyga rallies all the people that know more than he does
<fgimenez> pedronis: after adding "-device virtio-rng-pci" to the kvm command line create-key finally ended taking "only" 9min, so seems to be related to the available entropy as you pointed out
<morphis_> fgimenez: so on a linode instance its taking more than 15 min already
<morphis_> fgimenez: do you know if there is something we added to the ubuntu images on linode to improve things?
<morphis_> I guess we have rng-tools installed there
<fgimenez> morphis_: not sure, we should try to find a way, with a regular kvm invokation here it takes more than 30min
<morphis_> fgimenez: ok, activate rng-tools on the debian image with HRNGDEVICE=/dev/urandom and that makes things pretty fast
<fgimenez> morphis_: \o/ we should do the same for the ubuntu images
<morphis_> fgimenez: https://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny
<morphis_> I am hacking that for now into my PR
<fgimenez> morphis_: great thanks!
<morphis_> fgimenez: https://github.com/snapcore/snapd/pull/3156/commits/1ea78835c4aebd911a5702d3d352c3f5e9a0fa7a
<mup> PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<morphis_> lets see how that goes
<zyga> morphis_: ha, interesting
<zyga> morphis_: so debian defaults to /dev/random which uses real randomness
<zyga> morphis_: but we somehow default to /dev/urandom
<morphis_> yes
<zyga> morphis_: so a fresh VM without any entropy has a hard time generating all those keys
 * zyga really thinks VM providers should offer virtualized randomness 
<morphis_> fgimenez: seems to work well :-)
<morphis_> zyga: a bit confusing that we have two test cases: classic-confinement and confinement-classic :-)
<zyga> morphis_: yes, I know; I think we could roll them into one but they do slightly different checks
<tbr> zyga: just use this: http://phoeagon.github.io/dev-random-as-a-service/ ;-Ã¾
<zyga> tbr: I'd rather use a virtio passthru from the VM provider
<zyga> morphis_: there are new bug reports on redhat bugzilla
<zyga> morphis_: are you tracking those?
<ogra_> tbr, oh, cool they also offer /dev/null and /dev/zero as a service!
<tbr> ogra_: full spectrum offering!
<ogra_> yea, now thats a business model one can relate to ...
<zyga> ogra_: /etc/passwd as a service :D
<ogra_> zyga, you should suggest that to them ... shadow as well :)
<morphis_> zyga: I am wondering why I don't get notifications for those
<zyga> morphis_: not sure, just wanted to ask
<morphis_> zyga: but yeah, see them
<zyga> morphis_: great, thanks for checking
<morphis_> zyga: I see four open bugs, https://apps.fedoraproject.org/packages/snapd/bugs
<zyga> yep
<morphis_> good
<morphis_> mvo: do you have the commands at hand you use to generate the vendored releae tarball for snapd?
<zyga> mvo, morphis: any ideas on the mount questions I posted?
<mvo> morphis_: I just use the snapd orig.tar.gz from the ubuntu upload and rename the dir, why?
<mvo> morphis_: I had meant to write a proper script but not happend yet
<morphis_> mvo: as we miss certain assembler files in the tarball
<mvo> morphis_: oh? which ones?
<morphis_> mvo: like the .s files from https://github.com/golang/crypto/tree/master/salsa20/salsa
<mvo> morphis_: the vendor tree is  generated from ./get-deps.sh
 * mvo looks
<morphis_> mvo: do we build with gccgo on Ubuntu?
<mvo> morphis_: no, but we have a test that excercises gccgo
<morphis_> hm
<morphis_> mvo: as https://github.com/golang/crypto/blob/master/salsa20/salsa/salsa20_amd64.go has an explicit !gccgo and refers to the .s file for amd64 builds
<morphis_> zyga: not yet
<mvo> morphis_: I downloaded https://github.com/snapcore/snapd/releases/tag/2.24 the vendor.tar.xz  and I have the salsa2020_amd64.s file here
<morphis_> mvo: hm, why do we miss it then on fedora
<morphis_> mvo: ok, nevermind I will find out why
<mvo> morphis_: keep me updated please
<morphis_> will do
<morphis_> mvo: thanks for approval!
<Son_Goku> morphis_: the vendor.tar.xz is a full tarball
<Son_Goku> it's not just snapd-2.24/vendor/
<Son_Goku> if I were to apply it on top of the regular tarball, it'd be wasteful
<mup> PR snapcraft#1270 closed: release changelog for 2.29 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1270>
<mup> PR snapd#3217 opened: snap: support for snap tasks --last= <Created by stolowski> <https://github.com/snapcore/snapd/pull/3217>
<mvo> ogra_: just fyi - I'm going to build a new core with the stock xenial systemd to help steve with diagnosing the systemd issue we were seeing
<ogra_> mvo, fine with me if that doesnt get in the way of the release
<ogra_> (i actually held back any manual builds til next week to not interfer ... i,.e. for the cound-init stuff)
<mvo> ogra_: hm, good point. I will revert right after I created an image then
<ogra_> mvo, also ... bug 1650688 seems to go in the direction you proposed ... which means we'll need patches in the systemd package again ...
<mup> Bug #1650688: timedatectl set-timezone fails on UC16 <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1650688>
<ogra_> (orthogonal ... but relevant i think)
<mvo> ogra_: aha, thanks, I have not checked. I think I prepared a patch for this (iirc), its pretty small and close to the atomic_rename so hopefully things will not be a (huge) pain to maintain
<ogra_> mvo, right, that patch was what i meant ... i think we should test it soon ... but that means we'll again carry a patched systemd
<mup> PR snapcraft#1274 opened: Simple explanation of what the test groups mean <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1274>
<mvo> ogra_: yeah, its slightly horrible but I see no real alternative currently
<ogra_> yep
<Son_Goku> mvo: is 2.24 going out today?
<mvo> Son_Goku: there is an ongoing discussion with JamieBennett and awe about this right now
<Son_Goku> I'd really like to know if I should be pushing the button now
<Son_Goku> as I was previously told I should hold everything back for Ubuntu...
<JamieBennett> Son_Goku, we have a release that needs to happen with the current stable on Monday, we have been asked to hold off the 2.24 promotion to stable until then
<JamieBennett> I will talk to awe again today about it
<mvo> Son_Goku: my (personal) opinion is that 2.24 is fine to push into fedora or anywhere, it had its source release. its fine IMO if the core snap is not yet on 2.24
<zyga> Son_Goku: I agree with mvo here,
<JamieBennett> mvo, Son_Goku I agree
<mvo> but thats just me :)
<zyga> we should send it out
<Son_Goku> I'd rather push it now then :D
<mvo> aha, apparently not just me!
<zyga> :-)
 * zyga bangs head on the kernel
<zyga> and mount namespaces come out
<mvo> we also pushed it into ubuntu-proposed
<Son_Goku> push for F24 done
<zyga> thank you!
 * zyga updates
<Son_Goku> push for F25 done
<JamieBennett> We will not change the 2.24 release now, just delay it due to another dependency that the core team do not control
<zyga> btw, I will create a new interface
<mvo> zyga: for me its systemd-network that I push my head against
<JamieBennett> thanks Son_Goku
<zyga> simple one but ... cool and something I wanted for a long time
<ogra_> zyga, so for proper namespace support we need to ship your head with the kernel ?
<Son_Goku> push for F26 done
<Son_Goku> Rawhide already has it
<mvo> yeah, exactly. 2.24 is done. there might be an official 2.24.1 or something but that would be a new release
<zyga> mvo: I really like this, I just wish it wasn't going in circles; the mount backend is very important for users
<mvo> zyga: +100
<zyga> I have 6 tests now but with a new approach only one passes
<zyga> I think the kernel interface for this is really terrible
<zyga> I need to look at what the kernel does again :/
<zyga> I'd say that one bit is missing
<jdstrand> NicolinoCuralli (cc pedronis): re kernel reviews> for the irc backlog, it normally doesn't take very long, but sometimes further discussion is required. I'm answering NicolinoCuralli's specific questions in privmsg
<zyga> the mount source disambiguator
<zyga> of some kind
<Son_Goku> JamieBennett, mvo, zyga: snapd 2.24 will sync out to updates to all supported Fedora releases later today
<Son_Goku> hopefully
<Son_Goku> either today or tomorrow, depending on when the update masher runs
<zyga> Thank you!
<Son_Goku> it doesn't look like it's been kicked off yet, so it might even be today
<zyga> mvo: could you please review https://github.com/snapcore/snapd/pull/3209
<mup> PR snapd#3209: interfaces/mount: add partial implementation of Change.Needed <Created by zyga> <https://github.com/snapcore/snapd/pull/3209>
<zyga> and https://github.com/snapcore/snapd/pull/3138 if you don't mind
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<zyga> mvo and https://github.com/snapcore/snapd/pull/3216
<mup> PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216>
<Son_Goku> davidcalle: https://github.com/CanonicalLtd/snappy-docs/pull/71
<mup> PR CanonicalLtd/snappy-docs#71: Update Fedora snapd version to 2.24 <Created by Conan-Kudo> <https://github.com/CanonicalLtd/snappy-docs/pull/71>
<morphis_> Son_Goku: you submitted to stable already?
<Son_Goku> morphis_: yes, now I just have to wait for Bodhi masher to sync them out
<morphis_> despite that 2.24 isn't yet official?
<zyga> morphis_: yes, read above please
<morphis_> zyga: I did, however the rational from my side to hold back until 2.24 (or any other release) is marked official is, that there might be changes which depend on the corresponding core snap
<morphis_> in this case I am sure there are not but that is general thing we need to keep in mind
<mvo> morphis_: we are currently a bit out of sync because of soemthing else going on. normally it would all be in sync
<morphis_> zyga: like if we do the /etc change in snap-confine we have a dependency
<zyga> morphis_: yes, that's true
<morphis_> mvo: yeah
<morphis_> mvo, zyga: wouldn't it make sense to label a release when we announce it more as a candidate?
<morphis_> as that is what we do, we push a new core snap to candidate and start extensive testing before we move to stable
<morphis_> if we can enforce somehow that we put use release-candidate releases instead o stable once that would make it obvious to the public that the release isn't done yet
<mvo> morphis_: (in a meeting so a bit slow) - worth to discuss it. to me 2.24 is the upstream release, the other parts are downstream. just like e.g. libreoffice releases but distros take a bit to push it into their system.
<morphis_> mvo: right but isn't a core snap always aligned with a snapd release?
<morphis_> mvo: but we can discuss later when you have more time
<NicolinoCuralli> hi all: i want to enable i2c by gadget on my board. my board offer /sys/devices/platform/soc/1c2b000.i2c/i2c-0/0-0062/leds/pca963x:red/brightness -  is it correct to set in gadget the following
<NicolinoCuralli> slots:
<NicolinoCuralli>   i2c_leds:
<NicolinoCuralli>     interface: i2c
<NicolinoCuralli>     path: /sys/devices/platform/soc/1c2b000.i2c/i2c-0
<NicolinoCuralli> i infer this from test of snapd
<zyga> NicolinoCuralli: you may (perhaps) even just give the symbolic path, but not sure
<zyga> NicolinoCuralli: I did this a while ago
 * zyga is in a call
<morphis_> Son_Goku: any idea about this: https://paste.ubuntu.com/24426706/
<morphis_> Son_Goku: I see this with mock --with vendorized
<Son_Goku> seems like the tarball has a problem?
<morphis_> Son_Goku: no, but I figured it out
<Son_Goku> what was the issue?
<morphis_> Son_Goku: problem is that we install the go code and run tests afterwards
<morphis_> so snapd source end up /usr/share/..
<morphis_> then tests are running and they take the vendor dir from /usr/share/... which don't have the .s files
<Son_Goku> ah
<Son_Goku> so for vendorized build, the .s files need to be copied too :)
<morphis_> Son_Goku: right
<morphis_> fixing that
<morphis_> Son_Goku: btw. we need to land another package for running tests with a non-vendorized build
<Son_Goku> huh?
<Son_Goku> oh, a new godep?
<morphis_> https://github.com/snapcore/snapd/blob/master/tests/lib/fakestore/store/store.go#L34
<morphis_> at least go test github.com/snapcore/snapd/... wants to build and run the test case for that one too
<Son_Goku> morphis_: make a review request and we'll go from there
<morphis_> Son_Goku: yeah will do
<zyga> pedronis: thanks, I think you nailed it
<zyga> The code is far shorter now and the two failing tests are not related, and looking at one of those (symmetry test) I think I understand how to fix it
<Facu> sergiusens, elopio, this PR is all green and approved, but not merged... is anything missing from me in the procedure? thanks!  https://github.com/snapcore/snapcraft/pull/1261
<mup> PR snapcraft#1261: storeapi:  improve the error message for the case the Store answers an upload needs manual review <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1261>
<lutostag> can somebody weigh in if this is expected? https://bugs.launchpad.net/snappy/+bug/1679210
<mup> Bug #1679210: snap install --revision tracks stable by default <Snappy:New> <https://launchpad.net/bugs/1679210>
<ogra_> lutostag, i think the point there is the "tracking" entry ... if you had done "snap install etcd --revision=48 --edge" it would switch to track edge and only upgrade to a new edge upload (not sure that helps your actual problem though, there is no pinning currently)
<morphis_> zyga, mvo: is it correct that we use CoreLibExecDir here https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L249 ?
<morphis_> zyga, mvo: shouldn't that be DistroLibExecDir ?
<lutostag> ogra_: yeah, I think pinning would work except for that it is still tracking a channel, the only way I can pin is if I specifically download, ack and install from disk, which is quite a silly thing to do
<lutostag> ogra_: thanks for peeking at it though
<morphis_> zyga, mvo: looks to like we should only use CoreLibExecDir if want to reexec and otherwise use the distro one
<mvo> morphis_: when snap-exec runs we are already inside the core snap, snap-confine has done all the setup, except for classic snaps i think
<morphis_> mvo: right but at this point (snap run) we decide which snap-exec we want to execute
<morphis_> but maybe the test case is then wrong instead
<morphis_> as the test case only uses DistroLibExecDir
<morphis_> which clashes when both CoreLibExecDir and DistroLibExecDir are different like on Fedora
<mvo> morphis_: oh, that sounds like the test is wrong then. unless I miss something (classic mode is the exception) there is no way to run the host snap-exec, it always runs from core because the setup has already happend then
<mvo> (the setup == the snap-confine chroot/mount magic)
<morphis_> ok
<morphis_> must be like this as its working well on Fedora just the test isn't :-)
<morphis_> niemeyer: if I am going to change the debian image on Linode again can you snapshot it?
<sergiusens> Facu: we are in SRU release phase so don't land anything unless it is really urgent until we get a green light to land in -updates
<zyga> morphis_: looking
<zyga> morphis_: yes, we perhaps should tie this to reexec case
<mvo> morphis_: 2592 is ready for a look, it still needs some love to move bits into the new "spec" interfaces code, but the basic idea is ready I think
<ogra_> jdstrand, should snaps actually be able to access i2c devices via sysfs (i wouldnt think so, but perhaps we need to improve the interface here) ? ... https://forum.snapcraft.io/t/how-can-i-declare-i2c-slot/364
<Facu> sergiusens, ah, thanks!
<jdstrand> ogra_: responded in the forum
<ogra_> jdstrand, yeap, just "liked" it ;)
<niemeyer> morphis_: Definitely.. I'd prefer to do that on Monday if that's okay, though, as today it's a national holiday here and I'm planning to take some time off the keyboard
<morphis_> niemeyer: sounds good!
<jdstrand> mvo: that is a PR I'm interested in too. I gave a lot of feedback in the past, is it ready for me to look at again or are you just bringing morphis_ into the discussion?
<zyga> Pharaoh_Atem: is `dnf install --enablerepo=updates-testing` enabling that forever or just for one transaction?
<Pharaoh_Atem> just for the one transaction
<zyga> aha
<Pharaoh_Atem> if you want to enable it permanently, use the following:
<zyga> well, I have 2.24 now
<Pharaoh_Atem> `dnf config-manager --set-enabled updates-testing`
<zyga> no that's fine I was just surprised to see 2.24 on my machine :)
<zyga> I'm spinning just one one problem wrt mount stuff
<zyga> shadowing
<zyga> everything else is good
<Pharaoh_Atem> well 2.24 has been around for about a week in updates-testing
<zyga> but I think I know how to fix it as well :-)
<zyga> mvo: drama is (mostly) over I think
<zyga> I'm adding tests now but I will soon open a PR
<zyga> mvo: the advice from pedronis was brilliant and unblocked me
<cachio> niemeyer, is there any way to rever the snap create-user?
<genii> revert, reverse, revere?
<cachio> niemeyer, It would simplify the tests that I am doing for the console conf
<cachio> genii, revert
<cachio> or delete
<sborovkov> Hi. So I am bit confused by documentation of REST API of /v2/changes/id. I want to check 3 scenarios - error (that's covered by code 401). In progress and Done? So status code for both would be 200. Where is the documentation on what it will return for both cases?
<elopio> Facu: we are just in the release process, so we will land new things on monday probably.
<elopio> oh, sorry, I didn't see the reply from Sergio. What he said :)
<mvo> jdstrand: I think its ready for a second look, there are some technicalities that I want to fix, so its fine to wait too, I want to make sure of the new "spec" system for interfaces, that needs some work still but the principle should be there now for sesson services at least
<zyga> sborovkov: this is something chipaca would be best to answer
<zyga> sborovkov: but I think you should ask this on forum.snapcraft.io
<zyga> sborovkov: so that other people can find it and reuse the response
<jdstrand> mvo: ack, at this point it probably won't be today, but I should be able to look at it early next week
<mvo> jdstrand: hpefully I finished the remaining warts by then :)
<jdstrand> :)
<zyga> jdstrand: hey
<zyga> jdstrand: would you have some time to look at https://github.com/snapcore/snapd/pull/3216
<mup> PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216>
<zyga> jdstrand: and perhaps https://github.com/zyga/snapd/commit/fa7fb5206ba87609729c494bf9b6ccaaed93ea9b
<zyga> jdstrand: just RFC
<zyga> that last commit is meaty in low level stuff
<jdstrand> zyga: I've got a couple of things in front of it today, but I'll add it to the list
<zyga> jdstrand: thanks, next week is fine
<zyga> jdstrand: with some luck I'll resolve the TODOs by then :)
<jdstrand> zyga: I say the forum post. yucky that mountinfo is being so annoying
<jdstrand> saw*
<zyga> jdstrand: pedronis gave me the tip that st_dev (aka major:minor numbers) is the key
<zyga> jdstrand: now I'm down to shadowing
<zyga> jdstrand: if you fetch my remote and look at the feature/update-ns/needed-2 branch
<zyga> jdstrand: and "go test" in interfaces/mount
<zyga> jdstrand: you will see the one test that fails because of overmount/shadowed mounts
<zyga> jdstrand: but this is a huge improvement over the state in the morning :)
<jdstrand> cool
<zyga> jdstrand: I must say I wasn't aware what those numbers represent
<zyga> jdstrand: especially since there's the "mount id" that was so confusing
<zyga> jdstrand: st_dev doesn't shout like "unique device identifier"
<jdstrand> heh
<stgraber> zyga: ah good, I was about to point out that you can use the major:minor to see if a path comes from the expected device. Won't do you much good with virtual filesystems, but for anything block based it should help.
<zyga> stgraber: it seems to work for tmpfs too
<zyga> jdstrand: I'm still worried about effect of one mount hiding effect of earlier entries
<zyga> jdstrand: not just simple shadowing but something more generic (e.g. bind mount something over /snap/core/ (which is not a mount point)
<zyga> jdstrand: so I'm looking for a generic solution
<zyga> I commented on the forum to update the state
<zyga>  /me -> break
<mup> PR snapd#3218 opened: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3218>
<Facu> somebody may help me with some snapcraft tests? I have a test case that uses the FakeTerminal fixture; the test currently errors, but the last thing I see is the "E", no other output (my guess is because terminal is being captured)
<mup> PR snapd#3219 opened: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3219>
<mup> PR snapcraft#1275 opened: init: add a newline at the end of the file <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1275>
#snappy 2017-04-22
<mlw> Hi all, any snap makers willing to take requests?
<mlw> If anyone could find the interest to make a snap of the latest version of MonoDevelop (https://github.com/mono/monodevelop/archive/master.zip), I'd greatly appreciate it. I've attempted to do it myself, only to end in miserable failure.
<jrwren> mlw: why not use the mono repo?
<jrwren> mlw: I might try it. I used to build all of mono from source, all the way through monodevelop. that was many years ago.
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<mlw> jrwren: I've used the monorepo, but it doesn't have a 6.x branch of monodevelop which is required for monogame. And using the flatpak install is causing sandboxing issues.
<kotVasja> hallo
<kotVasja> hello, i have a problem, see her -> https://pastebin.com/XN8cCUdG please help me
#snappy 2017-04-23
<bazhang> would this be the channel to ask about anbox
<mup> Bug #1653852 changed: Cannot activate Chinese input method for Qt app even in the devmode <Snappy:Expired> <https://launchpad.net/bugs/1653852>
<mup> Bug #1663091 changed: Mir interface does not auto-connnet <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1663091>
<mcphail> davidcalle: cheers for the scummvm snap!
#snappy 2018-04-16
<mup> PR snapcraft#1943 closed: Release/2.39.2+18.04 (DO NOT MERGE) <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>
<mup> PR snapcraft#2078 opened: Release/2.41+18.04 <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2078>
<pbek> zyga: thanks a lot for your patience. so the most common way for a download tool like https://github.com/pbek/lmdownload is to tell the user that they only can download files to their home folder if they are installing the snap package?
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hello
<zyga> pbek: I'm not sure I understand, is the download tool itsel a snap?
<zyga> hey :)
 * zyga is a bit hurt today :)
<pbek> good morning, zyga
<pbek> yes, the tool downloads pdfs to the current folder and is snapped
<pbek> https://github.com/pbek/lmdownload/blob/develop/snap/snapcraft.yaml
<pbek> but of course downloading just works in the /home folder when the tool is started as snap
<zyga> pbek: you can check if you are in /var/lib/snapd/void, if so, tell the user to do something else
<zyga> pbek: that directory is used if the original working directory cannot be represented in a snap
<zyga> mvo: some good news, the leak is gone
<zyga> mvo: but the case is not fully cloesd, we need to talk to the kernel team
<pbek> zyga: strange, the tool never told me that it was in that directory (I print out the directory where the tool wants to strore the pdf file). the directory was always the one I really was in bash, but I got a write permissions error when I was storing the file. the tool is written in go
<zyga> pbek: it only does so if it is in a directory that cannot be represented
<zyga> pbek: it may be in a directory that is represented but cannot be written to
<pbek> zyga: ok, I can output a more propper error message then,  but I cannot get around the fact that the tool can only write to the home-folder while in snap confinement, right?
<zyga> pbek: that's correct
<zyga> pbek: snaps should wite to $SNAP_USER_DATA or $SNAP_USER_COMMON
<pbek> thank you again for your patience, zyga!
<zyga> pbek: eventually you may use xdg portals to write to more places
<pbek> yes, I found that out already (and am using using it for storing settings)
<mvo> zyga: hey, good morning. yeah, I saw the mail
<mup> PR snapd#5050 opened:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5050>
 * zyga tries to get through his inbox today
<mup> PR snapd#5051 opened: snap,wrappers: address review feedback from #5043 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5051>
<mup> PR snapd#5044 closed: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5044>
<mup> PR snapd#5045 closed: overlord/snapstate:  poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5045>
<pstolowski> morning
<zyga> hey pawel
 * zyga spent all of saturday and sunday outdoors, walking and biking a lot
<zyga> and now endures the pain in all kinds of places :)
<mborzecki> if anyone feels like doing some reading https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001
<zyga> mborzecki: yeah
<mborzecki> btw. i think there's a bug in nm, some signal not emitted at the right time/place
<mborzecki> at least when switching connection to metered from the cli, you don't see the Metered property changed on the main NM object
<mborzecki> had to restart NM and then it got updated
<ackk> hi, is there a fix for the pip error when building a python package with snacraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmp7036_63f', '/home/ack/canonical/src/gitlptools/parts/gitlptools/install/usr/bin/python3', '-m', 'pip']' returned non-zero exit status 1
<zyga> mborzecki: replied
<mborzecki> zyga: good points
<kalikiana> good morning
<zyga> Pharaoh_Atem: snap-confine package contains all kinds of things in fedora
<zyga> Pharaoh_Atem: we should really disband that package and move those files over to snapd
<mborzecki> disband ;) reminds me of civ
<zyga> mborzecki: ha, yeah
<zyga> disband militia in 2050 :)
<Chipaca> moin moin
<mborzeck1> wow, my network is flaky today
<zyga> mvo: I will update the GitHub release page
<zyga> although I plan to skip the .1 and .2 tarballs
<zyga> just go to .4
<zyga> I will use it to make the openSUSE release now
<pedronis> mvo: hi, are you going to create .5 today?
<mvo> pedronis: yes, I will do that hopefully ready around lunch time. do you have anything pending?
<pedronis> no
<pedronis> I saw you merged the doMountSanp/readInfo stuff
<zyga> pedronis: can you update https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954 to include the latest status of that issue please
<mvo> pedronis: yeah, I looked over it and it looked like a good idea to have it
<pedronis> I'll update it in a bit
<mborzecki> #3 is wontfix, #4 has had some error-catching fixes, #5 is almost fixed right?
<mborzecki> any prs needing reviews?
<zyga> Can you look at my trespassing pr
<mborzecki> zyga: #4889 ? already did
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> Ah, then no idea :-)
<mborzecki> zyga: btw. it needs deconflicting
<zyga> Oh thanks. Iâll do that shortly
<mborzecki> #4983 needs a second review
<mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<Chipaca> can't linux mint run classic snaps?
<mborzecki> is there a way to tell what type of confinement is supported by the system, other than running `snap debug confinement` ?
<pedronis> zyga: updated
<zyga> thanks!
<Chipaca> mborzecki: what do you mean?
<Chipaca> mborzecki: http snapd:///v2/system-info | jq .result.confinement
<Chipaca> mborzecki: ?
<mborzecki> Chipaca: when you run `snap debug confinement` you actually see the confinement mode supported on the host (strict|partial), but I don't see a way to get this information using cli and not 'debug' command (which is hidden btw)
<Chipaca> mborzecki: AFAIK there isn't
<Chipaca> mborzecki: i mean, not via 'snap'
<Chipaca> mborzecki: maybe we want it in 'snap version' or sth?
<Chipaca> mborzecki: (what for?)
<mborzecki> Chipaca: when the user runs hello-world.evil they will on unconfined system they will see the message 'If you see this line the confinement is not working correctly, please file a bug', but they may not have confinement in the first place
<Chipaca> mborzecki: 'please file a bug with your distribution' :-p
<mborzecki> i was thinking that we could update the message with eg. 'Try running snap version to check if your system supports confinement blah blah'
<Chipaca> mborzecki: why not make .evil run 'snap debug confinement' or equivalent itself?
<mborzecki> Chipaca: hm doable, but snap debug is hidden (or pretends to be at least), snap version would be nicer, https://paste.ubuntu.com/p/JRn57pP99Q/
<Chipaca> mborzecki: is this on arch btw?
<mborzecki> Chipaca: yes
<Chipaca> mborzecki: is there any info we could put next to 'arch' in the output of 'snap version'?
<Chipaca> i know it's rolling, but maybe, the time of the last update?
<Chipaca> dunno
<Chipaca> mborzecki: we could add confinement to distro info instead of as a new line if the new line is frowned on
<mborzecki> Chipaca: - ?
<mborzecki> Chipaca: https://paste.ubuntu.com/p/CGJZ9XPnSv/
<Chipaca> mborzecki: aw :-) ok
<zyga> IMO putting this on the distribution version is silly
<zyga> let's just do it properly
<zyga> confinement: seccomp(...), cgroup(device, freezer), namespace(mount), apparmor(...)
<Chipaca> zyga: note that that's not exposed via system info yet
<Chipaca> +1 to it or something like it if it were
<mup> PR snapd#5050 closed:  many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode #5043  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5050>
<mborzecki> zyga: seccomp(...) as in actions?
<zyga> yeah, some version details there
<mborzecki> hmm maybe we should have a separate `snap confinement` command or some --verbose switch to snap version, this is getting a bit verbose
<mborzecki> then we could print apparmor features, seccomp actions, available cgroups (those that are mounted), and namespaces (those listed under /proc/$$/ns of snapd daemon)
<zyga> mvo: updated https://github.com/snapcore/snapd/releases/tag/2.32.4
<zyga> mborzecki: I think we have too many commands but I agree we should have some way to s how this
<zyga> mborzecki: I doubt most users will undertstand more than I said initially on a single-line confinement value
<mborzecki> ok, so maybe `confinement: (strict|partial)` in snap version is all that we need
<mvo> zyga: thanks! .5 is rolling forward
<pedronis> mvo: so .5 doesn't include 5051 ?
<mup> PR snapd#5052 opened: cmd/snap: handle distros with no version ID <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
<mborzecki> Chipaca: ^^
<mvo> pedronis: no, I think its fine, its cosmetic but if you feel strongly about it I can include it too
<zyga> mvo: that's odd, we had that patched before
<Chipaca> mborzecki: +1
<zyga> ah
<zyga> I see what the patch does now
<zyga> mvo: ping me when .5 tarball is up
<popeycore> diddledan: you havint trouble with irccloud today?
<popeycore> fails to launch here on core stable, and I just get 3 dots in the screen constantly
<pedronis> mvo: mostly fearing a bit of confusion  about the log,  and if we need to do a .6
 * zyga does /o\
<zyga> why would we need a 6?
<pedronis> exactly, we don't know
<pedronis> that's how that stuff happens
<mvo> zyga: what is odd?
<zyga> mvo: nothing, I misunderstood the output
<zyga> mvo: - vs ""
<mvo> pedronis: ok, I will pull it into release/2.32 just in case we need a .6
<mvo> pedronis: it does make sense
<zyga> mvo: https://github.com/snapcore/snapd/pull/5053
<mup> PR #5053: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
<mvo> zyga: ta, I have a look. .5 is available in the ppa, one sec, I look for a direct link for you
<zyga> mvo: FYI I have tested jj's fix and it's stable over extended periods of time
<zyga> mvo: oh, neat
<zyga> just push the tag, I'll do the rest :)
<mvo> zyga: tag is pushed as well
<mup> PR snapd#5051 closed: snap,wrappers: address review feedback from #5043 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5051>
<mup> PR snapd#5053 opened: release-tools: handle the snapd-x.y.z version <Created by zyga> <https://github.com/snapcore/snapd/pull/5053>
<mvo> zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8990918/+listing-archive-extra has the build
<zyga> Son_Goku: good morning
<popeycore> diddledan: must have been corrupted config, removed and reinstalled the snap and it's fine \o/
<mup> PR snapd#5054 opened: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
<mup> PR snapd#5055 opened: release: 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5055>
<zyga> mvo: https://github.com/snapcore/snapd/releases/tag/2.32.5
<zyga> can you please check if I got the refresh/stop mode bits right
<zyga> mvo: .5 failed to build for ppc
<mvo> zyga: looking, I suspect a stray failure
<zyga> pedronis: https://bugs.launchpad.net/snappy/+bug/1764069
<mup> Bug #1764069: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:New> <https://launchpad.net/bugs/1764069>
 * zyga -> walk
<zyga> popey: notepad++ looks bad on high-dpi system
<zyga> not sure if there's anything we can do to tell wine" hide"
<zyga> "hidpi"
<popey> Indeed
<popey> We don't pass through pixel doubling in some apps
<popey> not just WINE
<Chipaca> popey: do you know what we need to pass through?
<popey> i dont think there is anything we can do for WINE, but for some other apps, Wimpress mentioned looked bad on his hidpi machine, i think he knows
 * Chipaca tries to make a joke about sulphites, and fails
<mup> PR snapd#5052 closed: cmd/snap: handle distros with no version ID <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5052>
<mborzecki> 5052 for 2.32 in case we do a .6 release? ;)
<Chipaca> mborzecki: too much regression potential
<Chipaca> :-p
<pedronis> zyga: afaict that's a DNS problem
<zyga> Ok
<pedronis> mvo: this changelog line looks strange:   daemon: support 'system' as nickname of the core snapchange it is
<pedronis> +      possible to do:
<pedronis> change it is ...  seems spurious
<mborzecki> pedronis: my fault, i tend to include how the command output looks like in the commit messages
<pedronis> I'm not sure, the whitespace is wrong either way
<mvo> pedronis: yeah, the whitespace there is incorrect. good catch
<mvo> pedronis: look like the script that generates them has a bug there, I look into it
<mup> PR snapd#5056 opened: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5056>
 * Chipaca trundles off in search of something to lunch
<zyga> re
 * zyga works on .5 release for opensuse
<Chipaca> zyga: .6 is where it's at
 * Chipaca runs
<zyga> Chipaca: what?!?
<zyga> are we doing a .6 now
<zyga> is this what "eventually released" software is like?
<pedronis> .5.4.3.2.1
<mborzecki> approximating towards 2.33
<zyga> Chipaca: should we use LazyUnmount= in our .mount units?
<pedronis> effectively :)
<pedronis> (that was about approx 2.33)
<cachio> mvo, should I start testing .5 or I should wait for a .6?
<pedronis> cachio: I don't think we plan a .6 atm
<cachio> pedronis, ah, ok
<cachio> thanks, I'll run beta validation for .5 in that case
<cachio> mborzecki, hey, amazon linux image is ready
<cachio> but you just can use it
<cachio> if you use this spread
<zyga> 2.32.4 is building for all opensuse systems now
<cachio> mborzecki, https://github.com/snapcore/spread/pull/57
<mup> PR spread#57: Adding preserve option for systems to keep the default image size <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/57>
<cachio> mborzecki, beasuse the filesystem cannot be resized
<mborzecki> cachio: what's the system name in spread.yaml?
<cachio> mborzecki, basically it is not possible to shrink xfs filesystems
<cachio>             - amazon-linux-2-64:
<cachio>                 workers: 1
<cachio>                 preserve: true
<cachio> mborzecki, you can add that
<cachio> with that branch
<mborzecki> ok
<cachio> mborzecki, I'll going the the kinesiology now, I'll explain better during the standup
<mborzecki> cachio: i'll try to run it, thanks
<cachio> mvo, there is not changelog for 2.32.4 -> 2.32.5
<zyga> cachio: I made "some" changelog
<zyga> cachio: https://github.com/snapcore/snapd/releases/2.32.5
<zyga> Caelum: I updated snapd twice to 2.32.4 and now to 2.32.5
<zyga> Caelum: let me know if you run into any issues
<zyga> Caelum: although this release should be very stable now
<zyga> mvo: maybe I could look at updating the debian package
<zyga> Pharaoh_Atem: I will have a small selinux patch for you to review soon
<zyga> does anyone know what networkd-dispatcher is for?
<zyga> mvo: how is our upload to bionic like?
<zyga> mvo: can we upload .5 now?
<zyga> and similar question about xenial SRU
<mborzecki> off to get the kids
<popey> mborzecki: when you return - did you have any luck with nvidia on 18.04? I got from zyga  that it's somewhat of a lost cause?
<zyga> popey: with classic snaps
<zyga> popey: otherwise it should work
<zyga> popey: with classic snaps it can work but the snap needs to understand the particular layout of the host
<popey> This needs documenting somewhere.
<zyga> popey: yes, no disagreement there
<zyga> mvo: when we have more bases and more core18 things
<zyga> mvo: I was thinking that we should drop the "series 16" line from snap version
<zyga> we could show it on core devices
<zyga> and actually show the name of the bootable base
<zyga> I think right now it's not a very useful/informative thing
<mup> Bug #1764069 changed: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:Invalid> <https://launchpad.net/bugs/1764069>
<zyga> mvo: hey, is issue #5 solved with 2.32.5 now?
<mup> PR snapd#4833 closed: tests: add a detector for kernel bug https://pad.lv/1755563 <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4833>
<zyga> mvo: given that #5043 is for 2.32.x, do you still plan to make additional release (that is, .6)?
<mup> PR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<mvo> zyga: reading backlog now
<mvo> cachio: http://people.canonical.com/~mvo/core-changes/html/beta/2.32.4r4443_2.32.5r4486.html <- that looks ok (modulo missing space)
<pstolowski|lunch> Son_Goku: hey! I've proposed go-udev https://bugzilla.redhat.com/show_bug.cgi?id=1567819 but just got a comment there that go packaging has been revamped? haven't yet looked at the guidelines
<mvo> zyga: 5043 has lnaded in .5, no?
<mvo> zyga: or what am I missing?
 * kalikiana lunch
<zyga> mvo: has it? the branch is open
<zyga> ah
<zyga> sorry
<zyga> I mean 5054
<zyga> mvo: I think my question was about the status of the forum post, if issue #5 is fixed let's mark it as solved
<mvo> zyga: checking
<Son_Goku> pstolowski|lunch, I think he's talking about this new form: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/blob/master/f/golang-gopkg-yaml.spec
<mvo> mup #5054
<mup> PR #5054: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5054>
<zyga> mvo: offtopic, remember those 100s of threads? my bionic shows 11 threads in .5
<mvo> zyga: 5054 is just cosmetic, but given the amount of questions about it I should have included it. its now in release/2.32 so *if* there is anohter one it will be in
<mvo> zyga: I do remember that
<zyga> mvo: understood now, thanks
<pstolowski|lunch> Son_Goku: okay, i'll dig into the new guideline after lunch
<mvo> zyga: thank you! so the 100s threads I don't see on my two bionic machines
<mvo> zyga: so not sure what is going on there
<Chipaca> huh, gnome software has a 'restart and install' button
<mvo> zyga: #5 *should* be fixed in beta but I hope to get confirmation from a real world test case later today
<mvo> Chipaca: for installing updates?
<zyga> Chipaca: yes, for some years now :)
<mvo> cachio: thanks for the sru validation!
<Chipaca> mvo: I'm guessing what it describes as firmware is a bios update
<zyga> Chipaca: it's a very old systemd/fedora/pkgkit feature
<mvo> cachio: also yeah beta validation for .5 sounds great!
<zyga> it's not related to firmware
<zyga> it's related to a mode where all updates are downloaded but not installed, the machine reboots and goes into a special boot mode where systemd installs all updates and reboots back to normal mode
<Son_Goku> pstolowski|lunch, guideline in question is documented here: https://fedoraproject.org/wiki/More_Go_packaging
<Chipaca> zyga: I don't open gnome-software often (i've only recently had enough memory to keep it installed at all)
<mvo> zyga: what is the link to the 18.04 post again? then I can update #5
<zyga> mvo: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
<mvo> zyga: ta!
<mvo> zyga: funny pr 4954 is also a fix for 2.32 as is the above forum topic (ok, maybe not that funny). i update it now
<mup> PR #4954: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4954>
<mvo> zyga: updated, thanks you
<zyga> mvo: we have new pam and netplan
<mvo> zyga: yeah, changelog looks mostly harmless
<zyga> yes
<kalikiana> re
<popey> zyga: to be clear, the snap which I am having trouble with is _not_ a classic snap.
<mborzecki> arch updated to 2.32.5
<popey> I'll speak to snapcraft chaps, as it could be that.
<mborzecki> popey: still mame thing?
<popey> yeah
<mborzecki> i posted the logs from friday in the LP bug report
<popey> you mentioned rpath, but I dont know what *I* am doing wrong here
<popey> yeah, I saw.
<pstolowski> niemeyer: will you have some time to talk about hotplug after your current meeting?
<tyhicks> mvo, zyga: hello! would you all be alright with the apparmor memory leak bug (bug #1750594) being fixed in the first SRU kernel of 18.04 or do you feel it is urgent enough that the 18.04 kernel be respun again before the release?
<mup> Bug #1750594: Eventual OOM with profile reloads <AppArmor:Fix Committed> <https://launchpad.net/bugs/1750594>
<zyga> tyhicks: I think it's not that critical, it only affects systems that run our test suite as far as we are aware
<mup> PR snapcraft#2074 closed: Release changelog for 2.41 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2074>
<zyga> it's annoying but not user-critical from my POV
<zyga> mvo: ^
<zyga> tyhicks: will live kernel patches fix it?
<tyhicks> that's my understanding of the bug, as well
<tyhicks> zyga: no, we don't plan to do a livepatch for it
<tyhicks> we'd really only want to respin if it affected installs or made the out of box experience bad but, AFAIK, this bug doesn't show up in normal use cases
<mvo> tyhicks: hi, in a meeting right now
<mvo> tyhicks: let me reply as quick as I can
<tyhicks> thanks
<niemeyer> pstolowski: I'm just off and have a few minutes before lunch.. can you talk now?
<pstolowski> niemeyer: yes
<niemeyer> pstolowski: Ok, standup then
<mup> PR snapd#5057 opened: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/5057>
<Chipaca> niemeyer: 10MB unaccounted for after creating a bolt db. Will continue digging.
<Chipaca> RSS of a simple thing goes from 4MB to 14MB
<niemeyer> Chipaca: That sounds very promising
<niemeyer> Chipaca: One data point worth gathering is what happens if we open that same file in RO mode
<Chipaca> niemeyer: 8MB rss
<pstolowski> pedronis: hey, will you find some time this week to make another pass on iterface hooks PR? i've addressed your last comments
<niemeyer> Chipaca: Unaccounted or total? That is, 4 to 12, or 4 to 8?
<Chipaca> niemeyer: actually 10MB if the code to create it is still there, just not used
<Chipaca> niemeyer: total
 * Chipaca needs to step away for a bit, will bbl
<Chipaca> niemeyer: time.Sleep -> 4MB, ro bolt: 8MB, ro bolt and rw code unused: 10MB; rw bolt: 14MB
 * Chipaca afk
<cachio> mvo, https://paste.ubuntu.com/p/Z59BDC4VWq/
<cachio> running beta validation for 64 bits
<cachio> mvo, it is like the system was rebooted after line 53
<cachio> but it shouldn't
<mvo> cachio: yeah, this is stange, anything in syslog?
<mborzecki> Chipaca: hacked a small tool that prints package sizes (*.a that end up in the binary, unless go does some lto at the end) https://gist.github.com/bboozzoo/a363e591075cb4d4faae39b4066ac411
<cachio> mvo, this is from syslog
<cachio> mvo, I already saw that doing refresh from stable too
<cachio> similar problem
<mvo> cachio: uh uh
<mvo> cachio: is this on a core device? or 16.04?
<cachio> mvo, from journalctl https://paste.ubuntu.com/p/DsqmKfDGNv/
<cachio> it is core-16-64
<cachio> a vm
<mvo> this is very uncommon
<mvo> Apr 16 14:31:53 localhost.localdomain snapd[993]:  ERROR cannot open snap: open /tmp/snapd-sideload-pkg-105860667: no such file or directory
<mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
<cachio> mvo, yes, first time I see this
<mvo> cachio: confusing
<cachio> mvo, this has more info https://paste.ubuntu.com/p/2ty37JM39W/
<mvo> cachio: yeah, more info but still very confusing. I wonder what change from .4 -> .5 might cause this :(
<niemeyer> Chipaca: Hmm.. are we keeping the file open? If we close the database and discard the structure, does the extra RSS memory go away?
<oSoMoN> the latest build of the chromium snap on launchpad failed automated review in the store ("checksums do not match"), is that a known issue with the store/snapcraft, or could it be just that specific snap?
<mvo> cachio: is it reproducible?
<niemeyer> Chipaca: If it doesn't, that must be a bug
<niemeyer> Chipaca: If it does, then we should probably just do that for the release
<cachio> mvo, I don't know
<cachio> I'll try
<mvo> cachio: thank you!
<niemeyer> Chipaca: Or at least keep it RO, if it impacts runtime of advice too much
<mvo> cachio: it looks very fishy, is this in a VM ? or on real HW?
 * niemeyer lunch
<cachio> mvo, it is a vm
<mvo> cachio: hm, hm, then that is double confusing
<mvo> cachio: I was wondering if there might be some HW issue that triggered the reboot but not in a VM
<mvo> (usually)
<cachio> in parallel I was running i386
<cachio> and it worked fine
<mvo> cachio: it *might* be the oom issue but given that we have not seen that beforre on non !i386 its unlikely
<mvo> cachio: ok, cool. at least that is good to know
<oSoMoN> I just rebuilt the chromium snap again on launchpad, and got the same error (checksums do not match) : https://code.launchpad.net/~chromium-team/+snap/chromium-snap-stable/+build/193033
<oSoMoN> known issue?
<oSoMoN> ah, apparently it is bug #1763641
<mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
<oSoMoN> however the bug says that this shouldn't happen with snapcraft 2.40, but the chromium snap is built on LP and the log says it's using snapcraft 2.40 (deb)
<mup> PR snapcraft#2079 opened: repo: catch error updating the package cache <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2079>
<Caelum> zyga: nice, will look in a bit, and also post to factory list
<zyga> Thanks!
<pedronis> mvo: that's the new checking code in doMountSnap
<mup> PR snapd#5055 closed: release: 2.32.5 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5055>
<mvo> pedronis: oh, so it already caught a case where things did not quite work correctly?
<mup> PR snapd#5058 opened: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5058>
<pedronis> mvo: maybe, or we are misunderstanding something
<mvo> cachio: -^
<cachio> mvo, not yet
<mvo> pedronis: cool, I need to leave in a wee bit to play hockey but I will read backlog, would be great to learn if we introduced a regression
<cachio> working on that
<mvo> cachio: thank you
<sergiusens> zyga, jdstrand any insight on https://paste.ubuntu.com/p/ZP6R7WM4Kz/ ?
<mvo> cachio: just wanted to let you know that pedronis  has an idea where the error comes from but its not clear yet if it is just making an existing error visible or if its something new
<cachio> mvo, ok
<cachio> mvo, perhaps it is not new but it is cannot be reproduced easily
<cachio> mvo, I'll make many executions today to see if I can reproduce it
<cachio> mvo, pedronis  I'll keep you updated in case I find something
<mvo> cachio: thank you!
<mvo> cachio: thanks to pedronis we have much improved error checking around this area of code now, so maybe it surfaces something that existed before. I will read backlog, need to play hockey now
<cachio> mvo, nice, enjoy it
<mvo> cachio: thank you! yeah, I am excited
<pedronis> cachio: it's strange because it seems we are rebooting in the middle of installing a local snap
<pedronis> Chipaca: what happens if we reboot when installing a local snap?  it seems the snap is copied into /tmp, but tmp will be cleared on reboot
<pedronis> cachio: am IÂ misreading that there's a reboot going on at the start of that test?
<pedronis> cachio: do we have a bug about stopping refreshes during some of the core tests?
 * kalikiana eod
<cachio> pedronis, I don't think so, but let me re-check
<Chipaca> pedronis: AFAIK it fails if it happens before the (snap.Container).Install, otherwise it succeeds
<Chipaca> pedronis: (that's the bit that copies the local snap into /var/lib/snapd/snaps iirc)
<pedronis> it seems we are hitting the scenario in a test
<Chipaca> hehe
<pedronis> but I'm not sure why there is rebooting going on though
<pedronis> Chipaca: do you agree that there is some system restarting going on here:  https://paste.ubuntu.com/p/DsqmKfDGNv/ ?
<pedronis> there's too much starting, early, stuff and systemd talking about early boot stuff
<Chipaca> niemeyer: we are not keeping the file open, and we do a commit and close on the db
<pedronis> Chipaca: another theory is that snapd and the test starts before the cleaning of tmp happens
<Chipaca> niemeyer: the only reason snapd uses boltdb is to write that databse, having it ro is like not having it
<niemeyer> That's pretty awkward. Why would the memory stay resident
<Chipaca> pedronis: looking
<pedronis> bu that makes sense only if tmp is not a tmpfs
<Chipaca> niemeyer: ï¼­ï¼¡ï¼§ï¼©ï¼£
<niemeyer> Chipaca: I guess Go's GC
<niemeyer> Chipaca: There is (was?) a method in the runtime package to "encourage" the GC to give memory back to the system
<Chipaca> pedronis: no that doesn't look like early boot stuff
<Chipaca> pedronis: it looks like snapd starts, and systemd says 'ok i'm done'
<Chipaca> niemeyer: runtime.GC()?
<niemeyer> Chipaca: No, that just kicks the GC.. let me check
<pedronis> Chipaca: but we are after a reboot, right?
<pedronis> Chipaca: otherewise there would not be that Reached target stuff
<Chipaca> niemeyer: runtime/debug's FreeOSMemory?
<niemeyer> Yes!
<cachio> pedronis, now error on i386 https://paste.ubuntu.com/p/hkxVgZDZgk/
<pedronis> IÂ don't see an "error" in that log
<Chipaca> niemeyer: it helps a little (14 -> 12 for rw, 10->9 for ro w/unused rw)
<cachio> pedronis, this is for 64 bits https://paste.ubuntu.com/p/5MHzmfjJP8/
<cachio> pedronis, no errors
<cachio> but suddenly rebooted
<pedronis> ah
<pedronis> so we are getting reboots
<cachio> pedronis, yes
<pedronis> IÂ don't see anything about "core"Â in those logs
<pedronis> not sure what would provoke reboots
<pedronis> that is new
<pedronis> I understand why reboot would make other things fail
<pedronis> but not what make us reboot
 * pedronis -> dinner
<Chipaca> blame spectre
<oSoMoN> jdstrand, have you seen my comment on bug #1763641 ? If IÂ read the bug correctly IÂ shouldn't be seeing this error with snapcraft 2.40, but I am
<mup> Bug #1763641: Checksum mismatch error when uploading a snap to the store <Canonical Click Reviewers tools:Fix Committed by jdstrand> <https://launchpad.net/bugs/1763641>
<oSoMoN> I ran reviews-tool from edge on the snap and got no such error
<zyga> sergiusens: did corebird work before?
<zyga> PAM got updated recently but I donât think weâd break abi
<diddledan> I might have told the build to not prime libkrb5
<pedronis> zyga: we are getting random reboots on .5
<pedronis> cachio: we didn't see these reboots with .4 ?
<zyga> Hmmmm
<zyga> What do we know?
<cachio> not for beta scenario at least
<zyga> .5 has new PAM and nplan
<diddledan> danke popey
<popey> I didnt know we had source-checksum!
<popey> TIL
<diddledan> inorite
<cachio> pedronis, I just saw some problems but for factory release to beta
<zyga> Changelog from for .5 is not extensive, mainly new API and a bugfix
<zyga> Is there any chance this is caused by new stop restart mode
 * Chipaca afk
<cachio> pedronis, zyga perhaps something else in the beta image it is causing this
<cachio> new kernel
<zyga> Oh
<zyga> Which one?
<zyga> I will be home soon
<zyga> pedronis: who reported this and how?
<pedronis> cachio
<pedronis> running the validation
<cachio> zyga, at least for dragonboard there was a new one
<cachio> pedronis, there are 2 scenarios, first is to create a beta image  and run  the tests for that image
<cachio> last execution I didn't see any error
<cachio> pedronis, this time I saw this reboot
<cachio> pedronis, but it is not failing 100% of the cases
<cachio> so, perhaps the same error was present in the previous validation and I did not reproduce it
<cachio> but today first exec I saw the errror
<cachio> for core-16-64
<cachio> and core-16-32 worked properly
<cachio> 100% pass
<zyga> cachio: on what hardware?
<cachio> then I rexecuted both and both failed
<cachio> I am running those on vms
<pedronis> probably worth trying  a couple runs with .4 IÂ suppose
<zyga> So amd64/kvm
<pedronis> to see if it's really .5
<zyga> Yes
<zyga> Letâs test .4 in the same host
<cachio> ok
<cachio> I'll do that
<zyga> Thank you
<pedronis> of course if it's new kernel we need to separate that somehow
<zyga> It could also be the oom bug
<pedronis> does it provokes reboots though?
<zyga> It is disabled on 32bit systems but also happens on 64 big systems the same,  just takes longer
<pedronis> or only errors?
<zyga> It eats all ram over time till kernel crashes
<zyga> With swap itâs a slow painful death
<zyga> Without swap it is quick and clear
<zyga> As an option we can do .6 with one of my workarounds
<diddledan> for the coders among us, Brenden Eich on Javascript's evolution: https://www.youtube.com/watch?v=3-9fnjzmXWA
<ogra_> there are coders among us ?
 * popey steps back
<kyrofa> Yes, but I heard the word "javascript" and ran
<diddledan> :-p
 * zyga looks at the reboot issue
<zyga> pedronis, cachio: we have a forum thread for the problem?
<cachio> zyga, no yet
<cachio> zyga, I'll create it
<zyga> thank you
<zyga> the pastebin I read looks very weird, I doubt that's OOM
<zyga> it looks like we really trigger a graceful shutdown shomehow
<zyga> cachio: does it happen in one spot or in some random place during testing
<cachio> the pattern that I saw in the syslog is
<cachio> https://paste.ubuntu.com/p/DVJNqD5yHP/
<cachio> in all the cases I saw something like this before the reboot
<nacc> how can i change the owner of a snap in the store
<cachio> zyga, and then this
<cachio> https://paste.ubuntu.com/p/vTM3bYx2Ph/
<cachio> I am running now 16-2.32.4 to see if I can reproduce it
<cachio> zyga, I thinks  2/3 cases happened installing snapd
<cachio> snaps
 * zyga dinner, I will check soon
<nacc> i specifically need to adjust the ownership of git-ubuntu, git-ubuntu-stable and git-ubuntu-beta away from my user
<sergiusens> nacc: to canonical, snapcrafters or another individual user?
<popey> nacc: post on the forum in the store category
<kyrofa> Hey niemeyer, I can't get the LXD backend of spread to ever work for 17.10 or 18.04, they always end up failing with "2018-04-16 19:01:30 Discarding lxd:ubuntu-17.10 (spread-8-ubuntu-17-10), cannot connect: cannot connect to lxd:ubuntu-17.10 (spread-8-ubuntu-17-10): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"
<kyrofa> Any ideas?
<om26er> popey: up ?
<popey> om26er: yo!
<om26er> oh boy you are always online, cool.
<om26er> popey: sublime is broken and I hope we can land its fix ASAP.
<om26er> we do have it published in edge channel but it won't start
<popey> ok, let me take a look now.
<popey> oh, it's classic. Are you on nvidia?
<om26er> popey: no, Intel
<popey> ok, lemme see
<popey> ok, merged your PR, lets see what that builds
<om26er> great stuff.
<om26er> thanks popey
<popey> np
<zyga> cachio: any news
<cachio> I ran 2.32.4 and I didn't see any error yet
<cachio> zyga, I am re-executing now
<zyga> can you upload the manifest
<cachio> I created images using candidate
<cachio> channel
<cachio> and ran the tests
<cachio> zyga, but no errors yet
<cachio> zyga, the same it is failing 66% of the times on beta
<zyga> cachio: so mvo suggested some ideas
<zyga> can you upload the manifests somewhere
<cachio> zyga, sure
<zyga> mvo said it would be in /usr/share/dpkg/snap* something
<zyga> also how big is the image
<zyga> can you upload the failing image as you got it now
<cachio> zyga, sure
<zyga> thanks!
<cachio> it is also very easy to generate it
<cachio> and faster
<cachio> with my wifi it could take long to upload
<cachio> zyga, clone git@github.com:sergiocazzolato/validator.git
<cachio> and then run
<cachio> ./create.sh beta pc-amd64
<cachio> ./create.sh beta pc-i386
<zyga> trying
<cachio> that will be faster
<zyga> which ubuntu-image are you using?
<zyga> from deb/snap
<zyga> and which version
<cachio> deb
<cachio> ubuntu-image 1.3+16.04ubuntu2
<zyga> I'm on 1.3+18.04ubuntu2
<zyga> but I'll make an image and try this way first
<zyga> if my image works can you upload your image
<zyga> we can compare binary stuff inside
<cachio> zyga, sure
<zyga> maybe overnight
<zyga> so we can analyze tomorrow
<niemeyer> kyrofa: I think there is a patch from Saviq that fixes that, from long ago.. sorry for not having merged it yet.. will try to have a look today still
<kyrofa> niemeyer, ah, excellent, okay thank you
<zyga> cachio: my dpkg.list from /usr/share/snappy/dpkg.list http://paste.ubuntu.com/p/JWPqJFWH7D/
<zyga> cachio: can you check if you have the same one
<zyga> cachio: I'm running kernel 4.4.0-121-generic
<kyrofa> Yep, that looks like it
<cachio> ok
<zyga> cachio: are you running the same thing on your test machine?
<cachio> zyga, checking
<cachio> zyga, the kernel is the same
<cachio> zyga, same
<cachio> the list is the same
<zyga> ok, thanks
<cachio> zyga, I am running again now
<mvo> cachio: I just chatted with zyga and he told me about the reboot issues (and you did so as well earlier). I just checked, might be worth running with the kernel from stable, looks like the kernel in beta got released just today
<cachio> mvo, you mean the kernel snap?
<zyga> yes
<mvo> cachio: yes
<cachio> let me cehck that
<mvo> cachio: I was just looking at the things that changed recently and noticed that this might be something
<mvo> cachio: I will also run the testsuite against a freshly build image to see if I can find any clues
<cachio> mvo, I just created a new image 20 minutes ago
<cachio> and I am running again against this new one
<cachio> so far no errors
<cachio> mvo, but just 31/199 yes
<cachio> yet
<cachio> mvo, I am in i386 and I have  pc-kernel  4.4.0-120.144  111   beta      canonical  kernel
<cachio> there is a new one in beta
<cachio> 4.4.0-121.145
<cachio> I'll regenerate also i386 image to see if the problem persist
<mvo> cachio: thanks. I just build an amd64 image, is that correct?
<mvo> cachio: aha, nice if you have an i386 image with an older kernel its interessting to see if the new kernel changes anything
<cachio> mvo, :(
<cachio> I just delete it
<cachio> overwrite it
<mvo> cachio: no worries
<om26er> popey: https://github.com/snapcrafters/sublime-text/pull/10
<mup> PR snapcrafters/sublime-text#10: Remove architectures stanza as it breaks auto builds <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/10>
<om26er> ...and this https://github.com/snapcrafters/android-studio/pull/20 (though not urgent)
<mup> PR snapcrafters/android-studio#20: remove architectures stanza <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/20>
<popey> om26er: merged both
<popey> thank you!
<om26er> super!
<om26er> we probably need to define some kind of "trust" chain (equivalent of MOTU/Core dev ?), so that we don't always have to bug you to get things landed.
<popey> there are others who have access :)
<om26er> apart from Martin, ev and you ? talking about snapcrafters repos only
<popey> yeah, currently the three of us
<om26er> its generally difficult to get a hold of flexiondotorg
<popey> he's Wimpress  now :)
<om26er> ev, I am not sure if he hangs around here.
<popey> he doesn't
<om26er> aah
<popey> he hates irc
<popey> like, passionately :)
<Wimpress> It is I
<Wimpress> And popey will burn in the embers of the heat death of the universe for being a lying #&$%
<om26er> alright, its the two of you then ;-)
<mvo> cachio: tests with stable kernel still going strong, I had one issue with python3 /nsap/network-bind-consumer/x1/bin/consumer eating all cpu and producing log messages I think we need to ensure in the relevant test that we kill it
<Wimpress> I see the reference to hating IRC was not attributed to me.
<Wimpress> #carryon
<om26er> popey: Wimpress still when snaps take over the world, MOTU/Core dev like access may be necessary.
<cachio> mvo, which is the test?
<popey> om26er: well, ideally these would all be gone from snapcrafters and owned upstream :)
<om26er> not today, but hopefully soon -__-
<popey> :)
<cachio> mvo, I am rnnning refresh scenario too
<cachio> mvo, let's see how it goes
<mvo> cachio: I'm not sure what test triggers this, just noticed
<cachio> mvo, ok, I'll check it
<om26er> popey: sublime text is good now
<om26er> \o/
<om26er> zyga: ^ its in edge
<zyga> thanks!
<zyga> mvo: I have a helper snap for redirecting systemctl
<popey> om26er: alias works too?
<om26er> popey: yep, subl
<popey> wow, that launches fast
<popey> om26er: released. thanks so much for all your work on this!
<popey> Sorry it took so long.
<popey> https://snapcraft.io/sublime-text
<mvo> cachio: and I noticed sometihng interessting too, when I log into the VM while the test is running I see a "system is going gown" message, so there is a planned reboot triggered by a test, for me the planned reboot message starts at 22:38 and the following tests run then http://paste.ubuntu.com/p/d3xsB4KQMP/ so one of these tests triggers a change that includes core/kernel which triggers the reboot
<om26er> popey: no problem, lets see if the upstream wants it now
<cachio> mvo, weird
<popey> maybe wait till we promote it and get more installs :)
<cachio> I didn't see any reboot scheduled
<cachio> well, there is a reboot schedulet but for a really long time
<cachio> which should not be affecting the testst
<om26er> sure
<mvo> cachio: if you ssh into the machine, do you get Broadcasting messages as well?
<cachio> mvo, no
<cachio> I just saw in the logs
<cachio> in the vm I didn't see any broadcastig message
<zyga> mvo, cachio: sudo snap install systemctl-redirector --beta
<cachio> zyga, what's this?
<zyga> then touch /var/log/systemctl.fake.log
<zyga> then sudo /snap/systemctl-redirector/current/bin/install
<zyga> then run all tests
<zyga> in the end collect the log file
<zyga> this logs all invocations of systemctl
<mup> PR snapd#5059 opened: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059>
<zyga> (reboot and all kinds of systemctl commands)
<zyga> mvo: ideas for improvement welcome
<mvo> zyga: thanks, I also pushed the above pR to break when we detect something that triggered a shutdown
<zyga> yeah
<zyga> looks good
<mvo> zyga: lets attack it from multiple angles
<mvo> cachio: iif you cherry pick the change from 5059 into your tree hopefully this also gives you an error when the shutdown is triggered
<mvo> cachio: when running -debug maybe it gives us clues
<zyga> cachio: if you run tests with this snap installed and with the install script invoked we should collect more info about what is going on
<cachio> mvo, zyga, ok
<cachio> I'll run it now
<mvo> ta
<zyga> thanks
<mvo> I will soon need to crahs :/
<mvo> but I start the tests now to see if I also notice anything
<zyga> me too
<mvo> and also login the VM to see any wall messages
<cachio> with the last kernel seems to be working better
<cachio> I didn't see any reboot yet}
<zyga> cachio: I refreshed the systemctl-redirector snap to improve the log messages
<cachio> ok, I'll start a run in 10 minutes
<cachio> zyga, could you reproduce the error?
<cachio> with the new kernel snap?
<zyga> I didn't run full test run yet
<cachio> zyga, I regenerated the image with the new kernel snap and I couldn't reproduce it anymore
<cachio> zyga, wait
<cachio> I did :)
<zyga> did you install and configure my snap on your VM
<cachio> zyga, https://paste.ubuntu.com/p/KMR33JvpyG/
<cachio> not for this run
<cachio> I'll do it for next one
<zyga> Apr 16 20:45:41 localhost kernel: [ 3071.152512] modprobe: page allocation failure: order:7, mode:0x2080024
<mup> PR #16: Feature/git buildpackage <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/16>
<cachio> zyga, because if I install it during execution it is gonna be deleted on reset
<cachio> zyga, yes
<zyga> on reset?
<zyga> ah
<zyga> snaps are removed :/
<zyga> looks like we ran out of ram
<cachio> zyga, I am configuring vms with -m 1500
<cachio> zyga so far it was enough
<zyga> cachio, mvo: the allocation that failed was for 524288 bytes
<zyga> not a lot
<zyga> it looks like we ran out of ram, plain and simple
<mvo> zyga: I also run with a 1500m VM, interessting
<zyga> cachio: which kernel is that?
<mvo> I keep it running
<zyga> 4.4
<cachio> zyga, pc-kernel                         4.4.0-121.145  113   beta
<zyga> right, I see
<zyga> guys, I need to go to sleep
<zyga> cachio: before you EOD write what you know on the forum
<cachio> zyga, sure
<cachio> zyga, go to bed :)
<zyga> Thank you. Good night!
<mvo> zyga, cachio I need to crash as well, I will keep the tests running and check in my morning, I run with beta kernel and the shutdown detection patch from the PR above
 * mvo waves
<kyrofa> nacc, any idea why building git-ubuntu on arm64 would fail unable to find ffi.h? libffi-dev seems to be in stage-packages
<kyrofa> Does it need to be a build-package as well?
<kyrofa> Not sure how this is setup
<nacc> kyrofa: log?
<kyrofa> nacc, https://pastebin.ubuntu.com/p/mGjrtbBdfJ/
<kyrofa> nacc, note that this worked fine on amd64
<nacc> kyrofa: otp, looking now
<kyrofa> No problem
<nacc> kyrofa: i have no idea :/
<nacc> kyrofa: i've never tried to build on arm64
<kyrofa> nacc, ah, that's what I was going to ask
<kyrofa> Okay, that's not unusual
#snappy 2018-04-17
<mup> PR snapcraft#2080 opened: project_loader: support architectures for CI <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2080>
<mup> Issue snapcraft#1680 closed: Documentation overhaul for scriptlets and setters <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1680>
<mwhudson> bah the snapcraft autopkgtests failed in bionic
<mwhudson> snapcraft.internal.errors.StagePackageDownloadError: Failed to fetch stage packages: Error downloading packages for part 'python2': The package 'python-distutils' was not found..
<mwhudson> i guess that patch wasn't quite right
<mborzecki> morning
<zyga> CzeÅÄ
<mborzecki> zyga: hej
<zyga> https://forum.snapcraft.io/t/unexpected-reboot-during-snapd-tests-execution-on-ubuntu-core-16/5009
<mup> PR snapd#5024 closed: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5024>
<zyga> There is a new kernel there
<zyga> And one of the logs looks like OOM
<mborzecki> zyga: this is with the new kernel?
<zyga> But others did not
<zyga> I didnât check cachioâs post in detail but I assume so
<zyga> Just woke up :-)
<mvo> hey zyga and mborzecki
<mborzecki> mvo: hey there
<mup> PR snapd#4989 closed: tests: add arch to CI <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4989>
<mborzecki> mvo: #5059 is something you want to merge or just wanted to run it through the CI?
<mup> PR #5059: tests: add pending shutdown detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/5059>
<mvo> mborzecki: both, its fine to keep it open for now I will also want to backport it to 2.32. it hopefully helps us to get clues about the reboot issue that cachio is reporting
<mborzecki> ok
<mborzecki> mvo: about the changelog, is this some tool that picks up the commit messages? (git-bp?)
<mvo> mborzecki: yeah, its a hand written one that is not very good in lp:~mvo/+junk/snappy-dch
<zyga> good morning
<zyga> mborzecki: now you know about mvo's secret stash of secrets :)
<zyga> is there any script that creates an image, prepares it for testing and runs tests against it
<zyga> I always have to hand-craft things and that feels weak
<zyga> yesterday I installed elementary to test a collection of snaps there
<zyga> and I noticed that elementary ships HWE kernels by default
<mborzecki> zyga: maybe they like running recent-ish kernels?
<zyga> yeah, just more leaky kernels
<zyga> but that's fine, the fix will come out soon enough
<zyga> mvo: do you suspect the error is just OOM again?
<zyga> after the last log from cachio late last night I think that's just it
<mvo> zyga: maybe it is that. I just had one run that was completely good and now I got a kernel oops with a _dma_segment_allow failure
<mvo> zyga: hm, /proc/meminfo looks happy, I don't think its just mem
<mvo> zyga: I wonder if we should add a more generic check for kernel oopses during the test runs
<mvo> zyga: just like the oom test
<zyga> mmm, good idea
<zyga> so do you think the new kernel is just busted?
<mvo> zyga: not sure, I refresh to stable now and re-run the tests
<mvo> zyga: its strange no reboot so far for me
<zyga> how are you running tests?
<zyga> spread + external backend + ...
<mvo> zyga: yeah, tests/external-backends.md
<mvo> zyga: so 1. build image using ubuntu-image (from the deb in my case) 2. create user on image 3. slavishly follow steps in tests/external-backends.md
<zyga> graargh
<zyga> yeah
<zyga> so handheld test
<mvo> zyga: I think sergio has better code for this
<mvo> zyga: I'm just a bit set in my ways (and I almost never do that kind of tests)
<zyga> casual testing on elementary shows everything is ok with 2.32.5
<zyga> om26er: installing sublime-text now, thank you!
<om26er> great to know
<mup> PR snapd#5060 opened: tests: detect kernel oops during tests and abort tests in this case <Created by mvo5> <https://github.com/snapcore/snapd/pull/5060>
<zyga> om26er: is the snap owned by upstream developers?
<zyga> om26er: I would love if they could se the percentage of snap vs native package userss
<om26er> zyga: not yet, there is an ongoing discussion with them, will se where that goes
<om26er> currently its under snapcrafters
<zyga> ok
<zyga> it works just great so thank you :)
<zyga> om26er: is there a chance to put dev builds in edge?
<om26er> @zyga: that should be possible, I think they have public apis with which we can check the latest dev build version
<zyga> the dev build is just in a different archive
<zyga> I don't know how this snap is built but if you can use a different archive for edge vs stable then it should be painless
<om26er> this has to be done externally though as their project is proprietary and we dont have access to its vcs
<om26er> zyga: https://github.com/snapcrafters/sublime-text/blob/master/snap/snapcraft.yaml
<om26er> I am working on a service that notifies us when a new release is available upstream
<zyga> where is SNAPCRAFT_PROJECT_VERSION coming from
<zyga> and that's some unusual variable replacement
<om26er> sublime, android studio and probably others could benefit
<zyga> not shell compatible (cc sergiusens)
<zyga> om26er: ack, thank you
<zyga> ah, I see version is just placed there
<mup> PR snapd#5061 opened: tests: ensure interfaces-network-bind daemon is really stopped <Created by mvo5> <https://github.com/snapcore/snapd/pull/5061>
<zyga> mvo: does this mean we remove snaps incorrectly on cleanup
<zyga> That is, keep processes up and running
<mvo> zyga: maybe - or maybe my analysis was too shallow
<mvo> zyga: it was a drive-by while searching for the real bug
<mvo> zyga: but there is definitely a runaway process that caused the journalctl --sync hangs
<mup> PR snapd#5062 opened: tests: skip interfaces-content test on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/5062>
<mvo> zyga: ^- is the reason for the reboot (or one reason, not sure yet, need to keep this running)
<mvo> zyga: but it all makes sense
<pedronis> mvo: ah :(
<mvo> pedronis: no :( more :) because we found the issue and its just test related and the fix is easy
<zyga> Pho
<zyga> Oho
<zyga> But why is that rebooting the system
<zyga> Is that test special? It just checks content connection
<pedronis> it's removing state.json
<mvo> zyga: it purges the state which triggers a download of core and for core core wants to remove
<mvo> to reboot
<mvo> sorry
<zyga> Aha
<zyga> I didnât remember that test is doing such things
<pedronis> mvo: well, on core it shouldn't download core
<pedronis> but it might trigger a reboot if strange things happen
<pedronis> or maybe nowadays it download core even on core?
<mvo> pedronis: indeed you are right, it is not downloading core, it is seeding again it seems
<pedronis> I'm not sure, given the new prereq code
<pedronis> it might be even trying to do both
<mvo> pedronis: the snap change output here indicates its seeding that is happening
<pedronis> ok
<mvo> pedronis: and in the content snap I don't see it tries to fetch core
<pedronis> mvo: there is a small change that it could try to do both tough
<mvo> pedronis: aha, its interessting. its is not core that triggers the reboot (because we are smart and know that we already have that). it is the kernel seeding
<mvo> pedronis: interessting, there might be a race here?
<pedronis> mvo: we start Loop  and we start accepting api calls,    the first ensure pass will create the tasks for seeding, but is not super clear that an install api couldn't come in before
<pedronis> rarely
 * mvo nods
 * zyga read the test just now
<zyga> (back from the walk)
<pedronis> mvo: don't think is something to worry about now, but we should think about it some more
<zyga> I see this test was re-purposed a ltitle
<zyga> "ensure that prereq installs work even with an empty state"
<mvo> yes
<mborzecki> mvo: runaway process, may this be caused by the changes that affected `systemctl stop` and postrm doing exactly that to stop the services?
<mvo> mborzecki: possible but unlikely unless special syntax is used nothing changes (i.e. you need to set stop-mode in snap.yaml for this to trigger)
<zyga> mvo: we also leak some other things but probably started by individual tests
<mvo> mborzecki: also we had the journalctl --sync hangs before but never figured out what triggered it
<zyga> mvo: most notably dbus-daemon
<mvo> zyga: good point
<zyga> there's enough of them to use up all ram on intense testing loops
<zyga> (I ran into it a few times but I didn't find the responsible test)
<mvo> zyga, mborzecki hrm, hrm, it looks like we already stop so my PR is probably too simplisitc
<mvo> zyga: prepare-restore.sh has a couple of checks now, we could add one more for runaway dbus
<zyga> yes, more whack-a-mole
<zyga> but yes
<mvo> zyga: well, yes whack-a-mole but this time each whack also closes the hole for the moles so hopefully instead of always having to whack N holes with this approach on each step its just N-1 holes :)
<zyga> mvo: we could also check that there are no new processes since test startup
<zyga> mvo: I mainly oppose ad-hoc solutions to system problems
<pstolowski> mornings
<mborzecki> pstolowski: o/
<mvo> zyga: +1
<mvo> hey pstolowski
<zyga> hey pawel, good morning
<mborzecki> maybe we should run the tests through systemd-run
<mborzecki> but this would probably have to go up to spread, and the benefit is only the processes started inside the test would get cleaned up automatically
<mup> PR snapd#5058 closed: packaging: fix incorrectly auto-generated changelog entry for 2.32.5 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5058>
<pedronis> pstolowski: hi, yes, I can look at the interface hooks PR again today
<pstolowski> pedronis: great, thank you!
<Chipaca> moin moin
<pedronis> mvo: does it all means we need a .6 ?
<zyga> hey chipaca
<Chipaca> zyga: how many ways can an X app set its icon
<Chipaca> zyga: :-)
<zyga> Chipaca: ETOOMANY
<mborzecki> hm if we're to do .6, #5024 and #5034 would be nice, this would fix the user autostart logging this
<mup> PR #5024: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5024>
<mup> PR #5034: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
<Chipaca> zyga: sorry, your answer was wrong. The right answer is: -1.
<Chipaca> .6 is happening?
<Chipaca> i was joking about it yesterday
<zyga> Chipaca: I think .7 will be it
<zyga> it's also a lucky number
<mborzecki> as many as we need ;)
<Chipaca> what's broken in .5?
<mvo> Chipaca, zyga what are you guys talking about? .5 is perfect. PERFECT
<zyga> mvo: it's perfect in vacuum in flat space
<Chipaca> mvo: <pedronis> mvo: does it all means we need a .6 ?
<Chipaca> mvo: that's all i know
<mvo> pedronis: I don't think we need .6, its all in tests so far
<mvo> Chipaca: ok :)
<mvo> Chipaca: I though you were pulling my leg
<mvo> pedronis: also tests that affect only core itself which we don't run via autopkgtest
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/5033
<mup> PR #5033: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033>
<mborzecki> zyga: thanks, looking
<Chipaca> niemeyer: good news and bad news: when using bolt directly, both in rw and ro mode, RSS is ~5MB after the call to debug.FreeOSMemory()
<Chipaca> so, we're probably being too clever with caching, interfaces, something else, or all of the above
<Chipaca> I might dig, or I might refactor the whole thing to be less loopy
<zyga> Chipaca: are you saying something just leaks memory or that we keep something deliberately open for extended period
<Chipaca> zyga: yes
<pedronis> Chipaca: are those numbers for the small example? or for snapd?
<Chipaca> pedronis: it's a small example
<Chipaca> pedronis: yesterday this same small example with rw was using 14MB
<Chipaca> pedronis: the difference between that and this is that that one used snapd/store's decodeCatalog, calling advisor's AddSnap, and this one uses bolt directly for that bit
<Chipaca> it still queries using advisor
<Chipaca> 14MB that dropped to (IIRC) 12MB after FreeOSMemory; this one uses 8MB before, 5MB after
<Chipaca> so, we're caching the store, and its http client
<Chipaca> (today's loads a local json file directly)
<Chipaca> and we're probably caching other stuff as well, i'd have to dump or sth to know in full
<Chipaca> and we're using interfaces a lot, which puts pressure on the heap
<mborzecki> and runtime
<Chipaca> yeah, i'm just looking at memory, as this is mostly io-bound
<pedronis> Chipaca: I see, but most of those changes aren't applicable inside snapd itself
<mborzecki> is there a chance we cache some responsese from the store?
<Chipaca> pedronis: well, maybe. I'll be adding things back now to see :-)
<Chipaca> first up, using an http client
<Chipaca> holy crap
<Chipaca> changing the os.Open to do a net/http Get went from 5/8/5 rss to 8/13/11
<pedronis> Chipaca: this is go 1.6 ? or something else
<pedronis> slightly curious if newer go uses less or more memory for this
<Chipaca> checking
<Chipaca> pedronis: go 1.10: 6/11/9
<Chipaca> that's before writing, after writing, after debug.FreeOSMemory
<mup> PR snapd#5063 opened: tests: run interfaces-boradcom-asic-control early <Created by mvo5> <https://github.com/snapcore/snapd/pull/5063>
<pedronis> Chipaca: so 1.10 does a bit better
<Chipaca> ish, yes
<Chipaca> (1.10 uses more memory in the boring case)
<Chipaca> (5/4 vs 6/5)
<Chipaca> but that's the case we don't care about :-)
<Chipaca> remember when there were revision control systems that used inodes for stuff so you couldn't cp things around?
 * Chipaca just copied a git tree and was greatful
<vidal72[m]> mborzecki: this isn't true anymore since 4.14: https://github.com/snapcore/snapd/blob/master/tests/regression/lp-1618683/task.yaml#L3 , linux,linux-lts and linux-hardened have user_ns enabled but restricted to root by default. They use same patch as debian but I don't see debian mentioned there so probably Arch shouldn't be there also: https://wiki.archlinux.org/index.php/Security#Sandboxing_applications
<mborzecki> vidal72[m]: thanks, i'll update the test
<vidal72[m]> mborzecki: also you use vanillia "go" package in test: https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L561 , while "go-pie" is used in package: https://github.com/bboozzoo/aur-snapd/blob/master/PKGBUILD#L15 . Maybe switch to "go-pie" in test as well. Anyway thx for supporting Arch :)
<mborzecki> vidal72[m]: hah, thanks for noticing ;)
<Chipaca> mmm, pie
<mup> PR snapd#5064 opened: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
 * Chipaca -> lunch
<Chipaca> is https://forum.snapcraft.io/t/request-automatic-alias-for-ubuntu-make/4958/5 missing something to be treated like an alias request?
<pedronis> Chipaca: the original request didn't sound like one
<zyga> Chipaca: I updated #4889 based on Gustavo's feedback
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> could you please look at https://github.com/snapcore/snapd/pull/4889/commits/f371bf27d2189c12f9ce5f29b0ed220aaa06101a and give me some quick feedback if that makes sense to you?
<Chipaca> zyga: how quick exactly :)
<Chipaca> zyga: e.g. can i do it after lunch
<zyga> sure, that's fine
 * Chipaca said lunch but then didn't
<Chipaca> k
 * Chipaca afk
<zyga> Ha. I should go too
<zyga> mvo: how are we looking wrt release
<zyga> all green, no smoke on the horizon?
<mborzecki> off to pick up my daughter from school
<Chipaca> popey: ERROR: ld.so: object '/snap/shattered-pixel-dungeon/5/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsedsp.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
<popey> Chipaca: which revision?
<Chipaca> popey: based on the /5/, 5
<popey> lulz
<Chipaca> :-)
<Chipaca> popey: it's /snap/shattered-pixel-dungeon/5/lib/libpulsedsp.so
<popey> wtf, this used to work
<ogra_> works fine here
<Chipaca> ogra_: sound?
<ogra_> (16.04, stable chanel)
<ogra_> yep
<ogra_> i played 1-2h per day since sat.... sound and all works fine
<Chipaca> 16.04, stable channel (even for core! need to fix that), and no sound
<Chipaca> and get that error on startup
<Chipaca> ogra_: unity?
<Chipaca> bah, it says error, but the game works (just without sound)
<ogra_> yes, standard 16.04
<Chipaca> oi hold on
<ogra_> core also stable
<Chipaca> other things also don't have sound
<ogra_> susie, sitting next to me has it running on her laptop as well ... sounds works there too
<pedronis> pstolowski|lunch: lgtm, couple of comments, IÂ think jdstrand might want to look a bit at the policy checks changes
<Chipaca> popey: um
<Chipaca> popey: sound does work
<Chipaca> popey: my bad
<popey> \o/
<popey> wot u do?
<Chipaca> popey: firmware update left me with no sound out of my speakers
<popey> oof
<Chipaca> popey: so that's _probably_ not your snap
<Chipaca> it also no longer detects headphone inserts
<ogra_> sounds pretty low-level then
<Chipaca> double yew tea eff
<zyga> Chipaca: oops :/
<zyga> how did you apply the update?
<ogra_> with a funnel ?
<Chipaca> zyga: machine rebooted, it spent a bunch of time doing 'updating bios' and 'updating the stuff intel uses to hack your machine' and such
<Chipaca> maybe I need to re-dkms or sth
<Chipaca> popey: but, that ERROR thing is still there fwiw (because as stated the file is not there but in lib)
<popey> ok, will take a look after my call
<Chipaca> good ol' java falling back gracefully and making debugging harder
<mvo> zyga: all green so far
<ogra_> popey, Chipaca https://paste.ubuntu.com/p/MXBYZKhr4w/ ... everything works though ... (joystick interface not connected since i have none on my laptop)
<ogra_> looks like it would like "process-control" too
<popey> most games do
<popey> they used to crash, but since 2.32 they carry on even though they dont have it
<mup> PR snapd#5053 closed: release-tools: handle the snapd-x.y.z version <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5053>
<zyga> thanks mvo
<mvo> zyga: thank *you*
<Chipaca> zyga: changes in 4889 sgtm
<zyga> thansk!
<cachio> mvo, hey
<cachio> I ran with -m 2000 and the new kernel and I could not reproduce the reboot error
<zyga> I wonder if we run with -m 512
<cachio> but, it failed in the refresh scenario
<zyga> ogra_: how much does smallest product you are aware of has?
<zyga> *memory*
<zyga> how much memory it has
<cachio> I am now rexecuting the refresh scenario with the systemctl-redirector snap
<Chipaca> zyga: I think ondra had a 256MB one somewhere
<Chipaca> but I'm not sure
<ogra_> zyga, we always said our lowest end is the beaglebone ... so typically the low end products are also in that area, 256M ...
<zyga> thanks guys
<zyga> while running our test suite is not the same as running a single purpose product
<zyga> I wonder how we fare in such world
<mvo> cachio: hey, I think we are good, I added some infrormation to the forum post and did some digging
<mvo> cachio: some open PRs based on that but with those applied I am at run 4 now and still no issues
<cachio> mvo, yes, I saw your comments
<cachio> thanks for adding that info
<cachio> I am rexecuting the refresh scenario now beacuse it failed
<cachio> and I added the systemctl-redirector in case it fails again
<cachio> the regular beta execution is working properly
 * Chipaca goes to grab a cuppa
<ogra_> zyga, well even in the sigle purpose low-level products customers ask for wifi-ap and network-manager to be preinstalled etc ...
<jdstrand> oSoMoN: I just saw it (was off yesterday). I'll look into it
<jdstrand> oSoMoN: where is the snapcraft.yaml for chromium?
<kenvandine> sergiusens, what's the status of snapcraft being able to build on a bionic base?
<oSoMoN> jdstrand, https://git.launchpad.net/~chromium-team/chromium-browser/+git/snappy-packaging/tree/snap/snapcraft.yaml
<jdstrand> ratliff: interesting: https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/8
<jdstrand> oSoMoN: thanks
<ratliff> jdstrand: is that causing all electron apps to fail automated review currently?
<jdstrand> ratliff: I suspect so
<jdstrand> chromium is failing because the store has r1021 and not r1022
<jdstrand> ratliff (cc roadmr): ^
<roadmr> hi :)
<jdstrand> and cc oSoMoN ^
 * roadmr checks
<oSoMoN> jdstrand, what's in r1022 ?
<jdstrand> + don't enforce 'app' snaps that have setuid/setgid overrides since they can't resquash properly without fakeroot or similar
<roadmr> jdstrand: I never added 1022 to the store :( 1021 was added/enabled last Thursday and the next one I have in the queue is r1025
<jdstrand> roadmr: yes, 1022+ is all that is needed
<jdstrand> roadmr: but it seems the electron-builder is unsquashing then running its own mksquashfs with extra arguments that would affect the resquash. Let's turn the resquash off for now. I will investigate
<jdstrand> popey: please see https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/8
<jdstrand> popey: what is signal using, electron-builder?
<kalipso> is there a way to gat old versions of snap packets? the update to lxd 3.0 broke all of our containers, we have to revert to 2.0 but someone in our team deleted snap cache.
<kalipso> s/gat/get
<jdstrand> stgraber: fyi, ^
<jdstrand> oSoMoN: I'm manually approving chromium
<oSoMoN> jdstrand, thanks!
<jdstrand> oSoMoN: (it passes with the review-tools snap, which as r1022)
<jdstrand> has*
<oSoMoN> yeah, I ran that locally and didn't get any errors, which is why I was puzzled by the store rejection
<oSoMoN> glad that you sorted this out already
<jdstrand> the harder one will be what popey is seeing
<popey> jdstrand: i believe it's electron-builder, yes
<jdstrand> popey: I need to *know* since I will be filing a bug against the project
<jdstrand> popey: :)
<popey> (also, one of our ISVs has sent a mail telling me he is using 2.35 so just hit this problem, because he can't use newer than 2.35 because patchelf breaks it)
<roadmr> jdstrand: ok, sorry I missed that (5 minutes only!). Turning off resquashfs enforcement now.
<jdstrand> popey: that ISV needs to work with sergiusens so they aren't stuff forever. they could work around this by unsquashing and calling mksquash with the appropriate args
<popey> they could, but this is yet another issue they've had in the last 2 weeks.
<popey> I have offered them turning off patchelf in 2.40
<jdstrand> popey: but, see what roadmr just said. this is only temporary until electron-builder issue is worked out
<popey> I am loathe to give them a bunch of commands to work around this.
<popey> the ISV isn't using electron-builder (I am though)
<roadmr> they don't need to :) I've turned off enforcement, popey, so their snaps will work as they did last week before Thursday
<jdstrand> popey: that doesn't matter. I asked roadmr to turn off resquash inforcement for everything
<jdstrand> roadmr: but they need to get on 2.40
<jdstrand> err
<roadmr> jdstrand: (I'm quite happy we went the extra centimeter to add the feature flag, super easy to flip this behavior)
<jdstrand> popey: but they need to get on 2.40
<jdstrand> roadmr: yes
<popey> Sure. But we can't _force_ people to upgrade if our tools are broken
<popey> Yes, I will speak to sergio :)
<kalipso> is there a way to build snap packages from source? when yes where do i find them?
<jdstrand> popey: did they turn off patchelf?
<jdstrand> popey: and upgrade? if so, they will be fine when we turn this back on
<popey> I asked them to
<popey> Not replied yet
<jdstrand> popey: can you tell me definitively if signal-desktop is using electron-builder? I see that you referenced the snap-template.sh (great!) but if they are using something else, that also needs to be fixed
<popey> jdstrand: it is using electron builder
<sergiusens> kenvandine: that's on 2.40 already, 2.41 to take into account some breaking changes that got into bionic; there is no container build support though and if doing classic you need to install core18 manually (as it is not on stable)
<sergiusens> a build-snaps entry should solve that ;-)
<pedronis> niemeyer: for reference this is the topic about gadget connections:  https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431
<cachio> mvo, I managed to reproduce the reboot error running the refresh scenario
<cachio> same log than what we saw yesterday
<kenvandine> sergiusens, so it'll build confined snaps  for core18?
<cachio> it is stable image using a core snap from beta
<kenvandine> we want to rebuild our snaps for core18/bionic
<sergiusens> kenvandine: yes, BjornT_ is using it for maas I believe
<sergiusens> kenvandine: you need to specify `base: core18` in snapcraft.yaml, also `snap info core18`
<kenvandine> sergiusens, awesome
<kenvandine> thx
<sergiusens> I don't think the snapd team is committing to its stability yet
<kenvandine> sergiusens, hopefully by release day :)
<sergiusens> kenvandine: heh, I think it is closer to .1; mvo any timelines? Not rushing, just having timelines makes us all align better ;-)
<mvo> cachio: the reboot error means it did reboot out of order?
<cachio> mvo, yes
<cachio> it is using an old kernel
<kenvandine> mvo, our how was to have our default snaps built against core18 for release
<cachio> mvo, I have seem similar issues in the last execution
<kenvandine> but it is late now...
<cachio> mvo, I mean, in the previous
<mvo> sergiusens, kenvandine yeah, .1 is our target for core18
<mvo> cachio: could you run it with PR#5059 cherry picked?
<cachio> mvo, |sure
<mvo> cachio: this should give us a hint when something triggers a shutdown
<mvo> cachio: thank you
<mvo> kenvandine: well, we can make sure to not remove debs at this point
<mvo> kenvandine: from the core18
<kenvandine> mvo, that should be good enough
<kenvandine> any chance of getting core18 into stable?
<cachio> mvo, I already applied that change for current execution
<cachio> mvo, we will see
<mvo> kenvandine: when do you need it there?
<mvo> cachio: cool
<kenvandine> mvo, now'ish :)
<sergiusens> kenvandine: also, I have not tested the DLC aspects of using a different base than core
<mvo> kenvandine: is thursday now'ish enough? I would like to poke at it a little bit before moving it to stable
<kenvandine> mvo, totally!
<sergiusens> and you do not need core18 on the host unless you are going classic
<mup> PR snapd#5041 closed: interfaces/apparmor: don't reload unchanged profiles <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5041>
<mup> PR snapd#5049 closed: interfaces/apparmor: workaround kernel memory leak <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5049>
<kenvandine> mvo, that would be much appreciated
<mvo> kenvandine: ok
<zyga> pedronis: do you think https://github.com/snapcore/snapd/pull/4996 should be merged?
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<mup> PR snapd#5033 closed: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5033>
<pedronis> zyga: I need to look at it again
<pedronis> there's also the question of the name and the comment pawel made
<oSoMoN> jdstrand, thanks for the manual approval of chromium. I requested manual review for the other 3 architectures that were built at the same time, would you mind approving?
<zyga> cachio: I'm seeing this in my PR:
<zyga> E: Unable to locate package linux-image-extra-4.15.0-1001-gcp
<jdstrand> oSoMoN: ok
<zyga> cachio: do we need another bump?
<zyga> full log is in https://api.travis-ci.org/v3/job/367633842/log.txt
<zyga> jdstrand: hey, FYI, I closed the workaround PRs
<cachio> zyga, the systemctl-redirector it is not logging anymore after a reboot
<zyga> cachio: oh? that's odd, is the service enabled?
<zyga> or maybe something kills it for whatever reason
<mborzecki> wow, the go toolchain in arch appears to be broken after all
<niemeyer> cprov: ping
<cachio> bin-systemctl.mount                                                                      loaded failed failed    Replace real systemctl with systemctl.fake
<cachio> zyga, I see that
<zyga> what's the status of the unit?
<cachio> zyga, I don't see it
<cachio> it is not listed
<zyga> cachio: and systemctl status bin-systemctl.mount
<cachio> zyga, https://paste.ubuntu.com/p/9xm6GWNpPJ/
<zyga> can you start it now?
<zyga> maybe it runs at the wrong time
<zyga> sicne it uses "current"
<zyga> and not the real revision
<zyga> so it doesn't get automatic dependency chaining
<zyga> that's proably it
<jdstrand> zyga: I see that. thanks! I haven't read all email yet but see that a fix for the memleak was found (yay!)
<cachio> zyga, I already started it
<cachio> and it is working again
<cachio> Let's see if it give us more info about the current run
<cachio> zyga, thanks for the help
<ondra> Chipaca for small memory devices, ogra is best person to ask
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/qhjrwh9N8n/
<Chipaca> niemeyer: rss grows with number of concurrent bolts
<Chipaca> niemeyer: btw wrt 'acq', that is how much Go's gotten (dynamically) from the operating system
<niemeyer> Chipaca: "write N" means N concurrent bolts?
<Chipaca> niemeyer: open for writing, yes
<niemeyer> Chipaca: Okay, that's pretty reasonable then
<SuperJonotron> is there an equivalent to dmidecode for core to access bios information?
<SuperJonotron> need to use some hardware parameters to determine installation flags for a program
<Chipaca> SuperJonotron: you'd need to ship dmidecode in a snap
<niemeyer> Chipaca: Some level of memory increase is to be expected.. just cannot be close to N x <first one>.
<SuperJonotron> chipaca: i had a feeling that was going to be the answer.  no other alternative for bios access in core?
<Chipaca> SuperJonotron: no, but also mu
<Chipaca> SuperJonotron: as in, I don't understand exactly what you're trying to do but it sure feels like you're doing something unexpected
<Chipaca> SuperJonotron: what is trying to determine installation flags for what program?
<SuperJonotron> Chipaca: software i'm installing utilizes the docker via the docker snap and is designed to run on specific hardware platforms which can be detected by bios settings since each platform will require slightly different runtime flags required by docker
<SuperJonotron> Chipaca: I can get around this by making the user select the correct device, was hoping to simplify that process
<Chipaca> SuperJonotron: so the software you're installing is inside docker, that's inside a snap, and the software on the inside needs to know the hardware the snap is running on?
<SuperJonotron> Chipaca: yes, which it does because dmidecode is a part of that docker container but the installer runs outside of all that which doesn't have dmidecode
<Chipaca> SuperJonotron: why not ship dmidecode yourself?
<Chipaca> i assume this 'installer' is a snap, but i don't know
<SuperJonotron> Chipaca: it is not, it is just some bash scripts that collect all the data necessary to put the docker image in the snap with all appropriate flags for the hardware
<Chipaca> SuperJonotron: actually, i was wrong
<Chipaca> SuperJonotron: we do ship dmidecode in core
 * Chipaca looks
<Chipaca> augh
<Chipaca> SuperJonotron: scratch that again, i was wrong
<Chipaca> SuperJonotron: accidentally looked in the wrong snap
<SuperJonotron> possibly stripped out in the UC16 image for Dell Gateways or is it it's own snap I need to download?
<Chipaca> SuperJonotron: no, i was just wrong
<Chipaca> SuperJonotron: but, if you're creating a snap for the installer, you can drop dmidecode in there and it should work (given the appropriate permissions)
<SuperJonotron> I might go that route in the future but for now i'll just make the installer be a manual hardware selection process
<SuperJonotron> Chipaca: thanks for confirming
<cprov>  niemeyer pong
<zyga> SuperJonotron: you donât need dmidecode, there are sysfs entries for everything
<niemeyer> cprov: Heya, having lunch now.. do you have time for us to go over the chart this afternoon, after your lunch?
<joc> sergiusens: could you take a quick look at this error, I feel like something changed in snapcraft to cause it, any ideas?: https://pastebin.canonical.com/p/7qWNQvNrd6/
<SuperJonotron> zyga: sysfs: command not found
<cprov> niemeyer: yes, absolutely, finishing lunch too.
<zyga> SuperJonotron: one sec :-)
<zyga> SuperJonotron: so
<zyga> it's not a command
<zyga> SuperJonotron: cd /sys/class/dmi/id
<zyga> SuperJonotron: ls -l
<zyga> and look around
<SuperJonotron> zyga: perfect, exactly the type of data i was after, thanks
<cachio> mvo, https://paste.ubuntu.com/p/Q6nJm7nqXs/
<cachio> I see this
<zyga> 2    Doing   2018-04-17T15:30:38Z  -                     Initialize system state
<zyga> is this what I think this is
<zyga> are we re-initializing system state in each test?
<cachio> well, perhaps it was the state when it was saves preparing the project
<zyga> SuperJonotron: there are no interfaces that expoese all of dmi information
<pedronis> zyga: that's seeding, if we start with an empty state we would
<zyga> SuperJonotron: but if you hvae a use-case let us know and we can add one
<pstolowski> Son_Goku: hey Neal! quick question, do you know if %{gofindfilter} macro is a new addition? I'm having failures trying to use it
<cachio> zyga, https://paste.ubuntu.com/p/Yv5MCy8gnm/
<cachio> this is the log from the snap
<zyga> pedronis: yes, the question is if we start with an empty state in each test
<zyga> I hope not
<cachio> shutdown +10 -r reboot
<pedronis> well that test does
<zyga> pstolowski: hey, are you using mock?
<pedronis> it does rm state.json
<pedronis> so that's expected there
<zyga> cachio: I see the systemctl-redirector snap is useful :)
<pedronis> on classic
<cachio> zyga, yes
<cachio> zyga, thanks for this :)
<zyga> I'm surprised how many things it shows at once
<zyga> that systemd relays all of the things through that command
<zyga> I will fix the reboot issue if I can, so that it's always on
<pstolowski> zyga: mock?
<zyga> pstolowski: yes, mock
<zyga> pstolowski: are you familiar with it?
<pstolowski> zyga: no
<zyga> pstolowski: install it, it's your best friend
<zyga> it's very useful
<SuperJonotron> zyga: no use case yet, nothing dmidecode provides was necessary except for some of the things already available in that directory
<zyga> SuperJonotron: sure, just let us know if you get into confinement issues
<zyga> SuperJonotron: normally you will not be able to read those files from a snap
<SuperJonotron> zyga: luckily for this instance, I need to read it from outside of a snap before interracting with one so it works perfectly for my use case
<cachio> zyga, the shutdown is called when the test tests/main/interfaces-content is executed
<pstolowski> zyga: looks useful indeed, thanks (although I don't think it's going to help we my current issue)
<zyga> pstolowski: it may
<zyga> the macro can be easily checked for by running mock against rawhide
<zyga> pstolowski: also mock helps you find missing dependencies
<zyga> pstolowski: let me know if you need help using it, I love mock
<pstolowski> zyga: ah, I see, nice, so it can spin a completely different FC environment
<zyga> yes
<zyga> just build your spec to srpm with mock
<zyga> tell it to use given release (e.g. f28)
<zyga> or f29
<zyga> then use mock again to build what you want
<zyga> mock caches everything so things are pretty fast after once run
<zyga> *one run
<cachio> zyga, mvo in this case the problem seems to be that it is starting the core snap 1441
<cachio> it is the one which comes by default
<cachio> I think the problem is that we are keeping both core snaps in the state and we should remove the old one in the reset
<cachio> zyga, mvo https://paste.ubuntu.com/p/G9mGjg2Ck2/
<cachio> current should be 4486
<cachio> some test is making a mess
<cachio> in this case the error seems to be a testing problem
<cachio> it is not the same we saw yesterday
<pedronis> cachio: this is classic right?
<Chipaca> niemeyer: so, given https://gist.github.com/chipaca/b1861183bbcda2f2d4e14ab3f74e60b2
<cachio> pedronis, ubuntu-core-16-64
<pedronis> cachio: mvo has a branch to disable the test there
<Chipaca> niemeyer: hammering that servier with 100 concurrent requests until 1M requests are served, not one request is lost
<cachio> pedronis, which tests?
<Chipaca> at least so far :-)
<pedronis> cachio: interface-content
<cachio> ahh
<cachio> ok
<pedronis> cachio:  https://github.com/snapcore/snapd/pull/5062
<mup> PR #5062: tests: skip interfaces-content test on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/5062>
<pedronis> I think it said that in the standup and in the topic
<pedronis> s/it/he/
<cachio> pedronis, ahh, ok, I missed that
<Chipaca> niemeyer: that's the good news
<cachio> thanks
<Chipaca> niemeyer: the bad news is that http.Server.Shutdown is 1.8+
<mup> PR snapd#5062 closed: tests: skip interfaces-content test on core devices <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5062>
<pedronis> Chipaca: I have ported Shutdown already to our daemon by hand
<Chipaca> pedronis: :-D
<zyga> can we depend on golang 1.10 somehow
<pedronis> at least something close enough
<Chipaca> pedronis: sssh i was trying to bring us kicking and screaming to 1.10 :-)
<pedronis> Chipaca: anyway please do look at daemon
<zyga> at least we could build with 1.10 in core snap
<Chipaca> pedronis: I was kidding, if we've alreay got it even better
<Chipaca> pedronis: there was a 'graceful' package for 1.6 but i was hoping to avoid it
<Chipaca> pedronis: so this is perfect
<Chipaca> all we need to do is just go away
<Chipaca> and, not restart more than 5 times in any 10 seconds
<Chipaca> :-)
<Chipaca> (or set StartLimitBurst=0 which is easily the most ill-documented bit of service files)
<Chipaca> also love that you can do StartLimitAction=reboot -> if apache is flapping, just reboot the server
<pedronis> Chipaca: sorry,  what IÂ meant,  it would be good to check if my port of Shutdown works well enough
<Chipaca> pedronis: ah
<pedronis> it's writte as small wrapper, so it shouldn't be too hard
 * cachio lunch
<Chipaca> pedronis: so finishShutdown() is Shutdown()?
<pedronis> yes
<sergiusens> joc:  that works with 2.35 and fails with this?
<pedronis> Chipaca: where do you close the listener?
<pedronis> Chipaca: ah, that's diffferent 1.8 closes listeners for you, in my case it's manual
<pedronis> Chipaca: Shutdown =  close listener +  finishShutdown
<pedronis> if I'm making sense
<Chipaca> pedronis: it still seems to work though
<niemeyer> Chipaca: I think we can control the shutdown as we already have some view over the connections going in, IIRC
<Chipaca> niemeyer: pedronis pointed out we can already shutdown as he backported it
<Chipaca> niemeyer: dameon.Daemon uses a daemon.shutdownServer :-)
<niemeyer> Chipaca: Cool.. so the question is whether there's something to tweak on the example
<niemeyer> Chipaca: It'd be worth adding some random sleeps, both inside the handler and outside after shutdown, and increasing the number of requests it's handling
<niemeyer> Chipaca: As it is right now it at least looks like an extremely performant application handling one request and exiting quickly
<Chipaca> niemeyer: it handles anything between 30 and 100 before exiting
<Chipaca> pedronis: and if I don't close the listener, up to about ~300 :-)
<niemeyer> Chipaca: Can we have the sleeps, delaying from 1~3 seconds, and something like ~5 before exiting?
<niemeyer> (after shutdown, before exiting)
<Chipaca> niemeyer: you mean, starting the shutdown after handling ~5?
<niemeyer> Chipaca: I mean sleeping for 5 seconds after Shutdown
<Chipaca> niemeyer: fwiw i also tested with starting the shutdown at ~100, already, with 100ms sleeps
<Chipaca> ok...
<niemeyer> Chipaca: IOW, testing the behavior of those connections coming in as we terminate the previous process
<Chipaca> niemeyer: 1-3 seconds sleep in the request handler, and the 5s after shutdown and before exiting
<niemeyer> Chipaca: To make sure systemd is in fact taking the same old socket and handing these connections that were made to the old process into the new one
<niemeyer> Chipaca: Then we just need to ensure the client testing it is properly reporting unexpected EOFs..
<niemeyer> Chipaca: If all of that work, then let's go out and have a beer :P
<Chipaca> yes, i'd errors on stderr if it EOF'ed
<niemeyer> Chipaca: Worth sending some data as well, perhaps.. to make sure everything is being handled correctly, instead of just taking the connection and closing it.
<Chipaca>      36 /36 26898 1
<Chipaca>      37 /37 27168 3
<mvo> cachio: https://paste.ubuntu.com/p/Q6nJm7nqXs/ <- this one if fixed with 5062
<Chipaca> ^ request #36 handled by pid 26898, request #37 handled by a different pid (5s later) (out of order)
<mup> PR #36: Refactored the test scripts and split the travis runs <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapd/pull/36>
<niemeyer> Chipaca: E.g. send N integers on one end, on exit of both ends ensure no gaps and what the max was.
<Chipaca> niemeyer: client is sending request number, server is echoing it back
<niemeyer> Chipaca: Ah, perfect
<niemeyer> Chipaca: Then I assume it's checking later that no gaps/correct max?
<Chipaca> I'm doing that with shell stuff, yes
<Chipaca> correct max i'm just eyeballing :-)
<Chipaca> 'does it end on 9999'
<niemeyer> +1
<niemeyer> Just plain diff on sorted outputs should do I guess
<niemeyer> Chipaca: Well, that's looking very promising.. in that case maybe we can simply look at the Ensure timer, and if there are no snaps we can shutdown
<niemeyer> Chipaca: Hmm..
<niemeyer> Chipaca: There's something curious here, though.. we did have to make our own client reconnect on errors.. remember that?
<Chipaca> the last test you requested is still running (no failures yet)
<niemeyer> Why was it breaking, assuming all of this was already in place back then
<pedronis> I think the retry code is older than my shutdown backport
<pedronis> fwiw
<pedronis> before my changes there our shutdown was a bit violent
<niemeyer> pedronis: Aha, interesting
<Chipaca> i think the client timeout is also fairly aggressive, but i'm not sure offhand
 * zyga -> grocieries
<niemeyer> Very promising either way
<Chipaca> niemeyer: test finished, success
<niemeyer> Chipaca: \o/
<Chipaca> and, soft eod from me
<niemeyer> Chipaca: Thanks for those tests
<Chipaca> np
<Chipaca> now we need a good way of answering 'can we shutdown' that won't have us racing with ourselves
<Chipaca> e.g. a way to accept a change but not run it, so that we can 202 things that are already in the pipeline after we closed the listener
<Chipaca> (reminder that daemon does EnsureBefore(0) in a bunch of places)
<mup> PR snapcraft#2081 opened: elf: patch everything instead of a subset of elf files <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2081>
<om26er> Is it possible to snap a python utility *without* shipping python with it ? Something that links to python installation in the core snap.
<ogra_> i think (probably that changed) your snap can see the actual python interpreter from core
<ogra_> but snapcraft will try to re-write the hashbang line in your script
<ogra_> (to point to a shipped one)
<zyga> om26er: technically yes
<zyga> om26er: just do it manually :)
<ogra_> so if you dont need any modules and use i.e. the nil plugin in snapcraft, just shipping a self-contained python script should be possible
<om26er> ogra_: zyga its a python package that I want to snap, it has setup.py etc, just instead of shipping a new copy of python want it to use one from core
<om26er> is there an example project that does that ?
 * ogra_ doubts that ... 
<zyga> I don't know sadly, perhaps there is something on the python plugin that can be done
<zyga> I honestly don't know
<ogra_> as soon as you use any of the python plugins in snapcraft it will try to re-write the interpreter line though
<kyrofa> niemeyer, have you had a chance to look at https://github.com/snapcore/spread/pull/39 ?
<mup> PR spread#39: Fix sshd_config sed expression (Issue #38) <Created by Saviq> <https://github.com/snapcore/spread/pull/39>
<Pharaoh_Atem> ?
<niemeyer> kyrofa: Not yet, sorry about that, but hope to integrate it today still
<kyrofa> niemeyer, alright, thank you
<Chipaca> om26er: can we talk about why you're wanting so badly to take over packaging of httpie?
<om26er> @Chipaca: heh, nothing specific but I am trying to pursue upstream to support it officially, so thought the first step would be to get that under snapcrafters.
<om26er> anyways, If there is a positive response from upstream this time, we can definitely get that alias transferred to them.
<Chipaca> om26er: https://github.com/jakubroztocil/httpie/pull/561/files
<mup> PR jakubroztocil/httpie#561: Add the packaging metadata to build the httpie snap <Created by elopio> <https://github.com/jakubroztocil/httpie/pull/561>
<Chipaca> om26er: I also had made them aware of my packaging efforts, which predate snapcraft
<om26er> Chipaca: I was pointed to that a few minutes ago here https://github.com/jakubroztocil/httpie/issues/672
<Chipaca> so, I mean, I snapped httpie ages ago, and have kept it updated
<om26er> Chipaca: alright, lets see if they show interest this time. (will bug you if needed)
<Chipaca> I reached out to upstream then (they showed little to no interest)
<om26er> thanks, its a very useful tool.
<Chipaca> I looked into moving to snapcraft, and it's too much work (if it's possible at all)
<Chipaca> so, do as you will
<Chipaca> om26er: but know that you're coming across as reasonably hostile or aggressive with this
<Chipaca> _un_reasonably
<om26er> Chipaca: no such intentions really, maybe wrong choice of words on my side.
 * om26er revisits the email text.
<Chipaca> om26er: you: "hey we want to be co-maintainers" me: "no because a b c" you: "but x y z"Ã3 also you: "hey upstream take my patch"
<Chipaca> it's not the words, it's the actions
<mup> PR snapcraft#1966 closed: grammar: support `to` statement in source <do-not-merge-yet> <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1966>
<om26er> I searched for 'snap' in their GH issues, nothing came up, so opened a new issue with a paste of very rough snapcraft.yaml that I did to verify if httpie was doing any system calls that would otherwise be deemed security-sensitive, found out that was not the case. Only just found in your email that you also ship unix socket extension of it.
<om26er> Chipaca: applogies if the email felt agressive, though I had no reason to be agressive to start with ;-)
<mup> Issue snapcraft#1685 closed: Implement support for architecture in snapcraft.yaml <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1685>
<mup> PR snapcraft#2080 closed: project_loader: support architectures for CI <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2080>
<popey> om26er: "so thought the first step would be to get that under snapcrafters." (no). First step is a pull request upstream IMO
<popey> if you have a pull request and they say yes, all is good. If they say "no" then -> snapcrafters perhaps
<om26er> popey: ok, in this case Leo has a pull request already.
<popey> awesome
<mwhudson> um um
<mwhudson> snapcraft in bionic needs to depend on python3-distutils...
<popey> kyrofa: ^
<mwhudson> maybe there should be a autopkgtest that actually invokes the binary :)
<mwhudson> kyrofa: https://paste.ubuntu.com/p/wD3gmWVd3P/
<mwhudson> maybe i should just upload the fix myself...
<kyrofa> mwhudson, ah, good catch, thank you
<mup> PR snapcraft#2082 opened: Ignore me, throwing to CI <do-not-merge-yet> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2082>
#snappy 2018-04-18
<mup> PR snapcraft#2081 closed: elf: patch everything instead of a subset of elf files <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2081>
<mup> PR snapcraft#2083 opened: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
<mup> PR snapcraft#1990 closed: tests: build and install snapcraft on osx <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1990>
<mup> PR snapcraft#2084 opened: Osx travis <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2084>
<sergiusens> jdstrand, zyga:  fyi that corebird issue I mentioned, the profile seems to be vanishing from '/var/lib/snapd/apparmor/profiles/' on every other boot
<Son_Goku> [11:39:43 AM]  <pstolowski>	Son_Goku: hey Neal! quick question, do you know if %{gofindfilter} macro is a new addition? I'm having failures trying to use it
<Son_Goku> pstolowski, it probably is
<Son_Goku> I haven't done any go packaging since new guidelines went out
<Son_Goku> but as zyga said, mock is your friend
<Son_Goku> you can also enter the mock environment by doing "mock --shell"
<mup> PR snapcraft#2082 closed: Ignore me, throwing to CI <do-not-merge-yet> <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2082>
<eraserpencil> Hey guys, I do snaps prevent access to source codes?
<mup> PR snapcraft#2085 opened: elf: clear the current runpath before setting the rpath <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2085>
<eraserpencil> I have a project I'd like to deploy and test out but I'm afraid the the source code would be copied. Does making it a snap helps protect the source code?
<mborzecki> morning
<zyga> good morning
<zyga> eraserpencil: hey, just don't put your source code into the snap then
<mborzeck1> zyga: hey
<zyga> eraserpencil: snaps don't have any copy protection
 * zyga is worried by this:
<zyga> <sergiusens> jdstrand, zyga:  fyi that corebird issue I mentioned, the profile seems to be vanishing from '/var/lib/snapd/apparmor/profiles/' on every other boot
<zyga> hmm
<zyga> why is bionic spread broken?
<mvo> zyga: I think there was a kernel update, if it is still broken after a retry we need to investigate
<mvo> zyga: and goooood morning
<zyga> good morning!
<zyga> I merged master a few times, still broken
<zyga> mvo: maybe we need to use a more recent snapshot
<mvo> zyga: aha, yes, that sounds very reasonable
<mup> PR snapd#5065 opened: spread.yaml: move bionic image forward <Created by mvo5> <https://github.com/snapcore/snapd/pull/5065>
<mvo> zyga: lets see if -^ helps
<zyga> oh cool
<zyga> I just made the same :D
<mvo> autsch
<mvo> ok
<zyga> haha, no worries :)
<zyga> hmm, have you guys seen https://zulipchat.com/
<zyga> it's fully FOSS
<zyga> mvo: Sergio<snapcraft> reported that some apparmor profiles disappear randomly on boto
<zyga> *boot
<zyga> but very frequently
<mborzecki> -buildmode=pie does not work in go anymore
<zyga> what? was it removed?
<mborzecki> just doesn't work, left some comments here https://github.com/snapcore/snapd/pull/5064#issuecomment-382098028
<mup> PR #5064: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
<zyga> uh
<zyga> mvo ^
<mvo> zyga: hm, hm, disappear. just apparmor or also seccomp?
<zyga> mvo: I don't know yet, trying to reproduce it
<mvo> zyga: ta
<mborzecki> wonder what fedora does
<mborzecki> hm maybe it just doesn't work, non-cgo and pie
<pstolowski> good morning
 * zyga -> dog
<zyga> mvo: travis hasn't ran your PR yet
<zyga> the one from early morning
<mvo> ok
<zyga> Actually taking the dog out now
<kalikiana> o/
<jamespage> elopio: around? working on vault bits and pieces and wondered if you had time to bring me up to speed on how you are managing the vault snap
<zyga> jamespage: hey, just FYI, elopio left Canonical
<jamespage> zyga: yeah I know ;)
<jamespage> zyga: call my request a retrospective handover...
<zyga> mvo: still nothing, is travis broken today?
<mvo> zyga: not sure, let me check
<mvo> zyga: anything on the vanishing profiles?
<zyga> mvo: I tried to reproduce it but no luck
<zyga> mvo: I used xenial
<zyga> mvo: maybe it is somehow related to the specific kernel sergio is using
<zyga> mvo: I will try to sync with him today
<zyga> (sergio is not using the stock kernel, he's on a surface enablement kernel)
<mvo> zyga: aha, and he is using xenial as well?
<mvo> zyga: travis status page says its up
<mvo> zyga: but I also see nothing building
<zyga> yeah :/
<zyga> mvo: it just started :)
<mborzecki> uhh go build, -extldflags & shell quoting is a mess
<zyga> mborzecki: yeah
<zyga> I failed to make snap-exec static on suse
<zyga> because of rpm macros and the need to quote a space
<zyga> it just failed all the way :/
<zyga> and the ldflags to pass static
<mborzecki> anyways, -buildmode=pie & CGO_ENABLED does not work, fedora uses proper go build -buildmode=pie -ldflags="-extldflags '-static'" and it work, did the same for arch
<mborzecki> zyga: i did go build -buildmode=pie -ldflags=-extldflags=-static ;) appears to work
<mwhudson> at some point i gave up and wrote a wrapper and pointed -ldflags=-extld= at it
<zyga> mborzecki: oh, smart
<zyga> I'll try that
<mborzecki> mwhudson: yeah, it's super confusing
<mborzecki> zyga: afaik it will work if you define a macro in the spec, take a look at fedora spec
<mborzecki> zyga: i mean, you won't have to resort to such ugly tricks
<Chipaca> moin moin
<Chipaca> very spotty network for me today
<Chipaca> anything on fire today?
<mvo> Chipaca: zyga had one alarming message but otherwise it seems to be ok
<Chipaca> mvo: was the alarming message "wake up"?
<zyga> Chipaca: sergio<snapcraft> reported that some apparmor profiles go away on reboot randomly
<zyga> but I could not reproduce this
<zyga> and I don't know more
<joc> anyone else using the vscode snap on bionic and seen it stop working since rev 32?
<zyga> joc: I can try
<joc> (`snap revert` FTW)
<Chipaca> zyga: wait is it sergio<snapcraft>, or is it snapcraft<sergio>
<zyga> Chipaca: aren't teplate specializations commutative ;-)
<Chipaca> zyga: that would be really tidy of them
<zyga> Chipaca: both of them ;-)
 * zyga is in a silly mood
<zyga> pulling vscode in a park at 2.5MB/s
<Chipaca> that's not silly, that's bragging
<zyga> hey
<zyga> just two blocks from my home
<mborzecki> broadband :)
<zyga> vscode snap (r32) broken on ubuntu 18.04 https://www.irccloud.com/pastebin/EiQuCMnT/
<itsfemme[m]> Are you on your home wifi in the park?
<zyga> itsfemme[m]: no, on LTE
<zyga> joc: confirmed
<zyga> popey: ^ FYI, vscode is missing some things and doesn't work on bionic
<joc> zyga: ack, thanks
<zyga> joc: try sublime-text
<zyga> it works :)
<Chipaca> so... I've got two +1's on #5027 and it's green, and master's open, so I'm going to go ahead and merge it
 * Chipaca is full of trepidation
<mup> PR #5027: you won't believe how client gets initial support for snapshots <Created by chipaca> <https://github.com/snapcore/snapd/pull/5027>
<joc> heh, i've reverted and all is good
<zyga> Chipaca: go go go
<zyga> Chipaca: LOL
<zyga> with that commit message
<zyga> mvo: remember to edit the changelog on that :D
<Chipaca> joc: FWIW reverting blacklists the revision, but if they push a new one you'll get it (which is what you want imho)
<joc> Chipaca: yep, happy with that
<popey> zyga: what release?
<zyga> popey: revision 32 of vscode
<zyga> popey: on bionic
<zyga> popey: joc said previous revision worked ok
<popey> works here
<zyga> popey: on bionic?
<popey> yes
<zyga> popey: r32?
<popey> oh, 32?
<zyga> yes :)
<popey> you should update :)
<zyga> it used to work, now broke
<zyga> what? :D
<popey> test 33
<popey> does that work?
<zyga> I literally just installed it now
<popey> sorry, i think it didnt get promoted, 33 works I think
<zyga> checking
<itsfemme[m]> I'm looking at their snapcraft.yaml and it seems they are moving to gtk3 for debs and rpms but did not add it to the snap
<zyga> Chipaca: I found a bug :D
<Chipaca> zyga: impossible
<Chipaca> zyga: where?
<mup> PR snapd#5027 closed: you won't believe how client gets initial support for snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5027>
<zyga> you won't believe what I just found Chipaca https://www.irccloud.com/pastebin/86utZoMt/
<Chipaca> zyga: whaa?
<zyga> Chipaca: ouch, it's a symlink to a brkoen try mode snap
<zyga> I mean
<zyga> I did snap try on something I kept in ~
<zyga> then I moved it to Documents
<zyga> and snap refresh broke
<Chipaca> zyga: ok yes that's a bug, but not a new one -- file it?
<zyga> sure
<zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1764977
<mup> Bug #1764977: Removing backing directory of try mode snap breaks refresh of other snaps <snapd:New> <https://launchpad.net/bugs/1764977>
<zyga> Chipaca: it's worse, I cannot snap list
<zyga> snap remove
<zyga> that's not even broken now
<zyga> is that a follow-up of the change pedronis landed
<zyga> mvo: ^ this may warrant a .6 ://
<zyga> essentially I cannot refresh core now
<mvo> zyga: it breaks refreshing everything? if one snap is in broken state?
<zyga> yes
<pedronis> it shouldn't
<zyga> it does
<zyga> try it
<zyga> (literally)
<popey> "No thank you" :D
<pedronis> we have a bigger bug then
<zyga> mvo: snap list, refresh et all are all failing
<mborzecki> > that escalated quickly
<zyga> popey: so I believe you
<zyga> joc: can you please refresh vscode to edge
<zyga> and see if that fixes it
<pedronis> we didn't change snap list
<pedronis> afaiu
<joc> i can...
<zyga> and communicate with popey wrt promiton of r33 to stable
<zyga> pedronis: well :)
<Chipaca> zyga: I doubt this is a new thing
<zyga> kwi 18 10:59:22 t470 snapd[2069]: 2018/04/18 10:59:22.512843 snapmgr.go:228: cannot read snap info of snap "classic-snap-analyzer" at revision x4: stat /var/lib/snapd/snaps/classic-snap-analyzer_x4.snap: no such file or directory
<pedronis> let's put it this way, we tried very carefully not to change snap list
<pedronis> so I'm a bit confused
<popey> joc: zyga 33 is now in stable
<zyga> pedronis: can you just try it, "snap try" one of the test snaps, move it aside and see
<joc> popey: same error:
<mvo> I wonder if we have an integration test for snaps in broken state
<popey> joc: can you paste the error somewherre?
<joc> ```/snap/vscode/33/usr/share/code/bin/../code: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory```
<zyga> mvo: I bet we don't
<zyga> popey: you probably have that library installed on your host
<popey> gah
<zyga> popey: I wrote an analyzer for classic snaps
<zyga> that shows missing libs
<mup> PR snapd#5066 opened: overlord/snapshotstate/backend: introducing the snapshot backend <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066>
<zyga> _ironically_ it is the snap I moved to another directory
<zyga> that broke everything for me now
<popey> joc: we're on it. thanks
<Chipaca> zyga: if you move it back, does it unbreak
<zyga> trying
<zyga> yes
<itsfemme[m]> That lib is in the snapcraft.yaml though, I just checked
<zyga> it unbreaks everything
<zyga> itsfemme[m]: it's not loaded from there though
<zyga> popey: http://paste.ubuntu.com/p/4sb3wxqNHD/
<zyga> try this and see where it loads the libs from
<Chipaca> zyga: please add that to the bug report just in case it happens to people before we can fix it
<Chipaca> i'd do it myself but my network is already struggling
<zyga> Chipaca: I just updated the bug report
<zyga> I also bumped it to critical
<zyga> it's interesting because people who have broken snaps will stay on 2.32.5
<zyga> until we fix it with classic package
<zyga> which is a bit unfortunatel
<zyga> *unfortunate
<zyga> I'll drop what I was doing and add a spread test onw
<Chipaca> zyga: broken in general, or broken in this particular way
<zyga> snaps that are broken
<zyga> any old try mode snap that is removed qualifies
<zyga> but unfortunately any unmounted snap :/
<pedronis> mmh
<mvo> zyga: I wonder if you could check if going to a tag like 2.32 and running snapd from there shows that its also broken or not
<zyga> mvo: sure
<pedronis> I have the impression is not new to .5
<zyga> I can just snap refresh to older rev
<zyga> it's easier
<zyga> mvo: stable is at 2.32.3 still
<zyga> trying...
 * zyga hums while LTE does its magic
<zyga> 100GB of traffic for my laptop as a free add-on to my low cost phone plan
<zyga> I really missed that in spain
<zyga> spain has LTE and all but man, not at this quantity
<mborzecki> zyga: pushed the fix to https://github.com/snapcore/snapd/pull/5064
<mup> PR #5064: tests: smaller fixes for Arch tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
<mborzecki> what reminds me, we should fix the install path of snapd-generator
<zyga> pedronis, mvo: confirmed, the bug is also present on 2.32.3
<pedronis> ok, that makes more sense
<zyga> can someone confirm https://bugs.launchpad.net/snapd/+bug/1764977
<mup> Bug #1764977: Removing backing directory of try mode snap breaks refresh, listing (at least 2.32.3, till 2.32.5) <snapd:New> <https://launchpad.net/bugs/1764977>
<mvo> zyga: :( so we need a) integration test b) fix
<zyga> mvo: I'm doing (a) now
<mvo> zyga: \o/
<zyga> I can do (b) after
<mvo> cool
<zyga> mvo: is that a .6 then?
<pedronis> we are doing stat of snaps in some place, but not ignoring errors as we should
<mvo> zyga: probably, depends a bit on the diff
<mvo> zyga: but I think it does make sense
<pedronis> yea, confirmed it's in 2.32.3 as well
<pedronis> it's nor related to the new api stuff or the doMountSnap changes
<pedronis> it's something older
<pedronis> ah, IÂ think IÂ know
<pedronis> maybe
<zyga> we have "try-snap-goes-away" test
<zyga> I wonder how it didn't catch this!
<pedronis> mvo: zyga: my suspecte is the InstalledDate code
<zyga> oh
<zyga> neat, that's probably it
<pedronis> it's ignoring the case where the snap is set to Broken
<pedronis> because it's doing an independent Lstat
 * Chipaca whistles innocently
<pedronis> mmg
<pedronis> no
<mup> PR snapd#5063 closed: tests: run interfaces-broadcom-asic-control early <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5063>
<pedronis> it doesn'r eturn error
<mup> PR snapd#5067 opened: tests: add a regression test for https://bugs.launchpad.net/snapd/+buâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<zyga> I added this test, let's see what happens with it
<mvo> zyga: interessting, it looks very similar to the existing test
 * mvo is confused why the existing one does not work, it does not look broken on first glance at least
<zyga> mvo: yes, I don't know why that test didn't catch it
<pedronis> mmh
<pedronis> it's the MountFile
<pedronis> not the MountDir
<pedronis> it's the code to find the size ?
<pedronis> mmh
<pedronis> shouldn't
 * zyga tries to find what it might be
<pedronis> ah
<zyga> found it?
<pedronis> zyga: if you notice the problem is not that the mount goes
<pedronis> away
<pedronis> the mount is there
<pedronis> if you move the dir
<zyga> indeed!
<zyga> it's still mounted
<pedronis> but the symlink because dangling
<zyga> yes
<pedronis> so we don't fail where we think we should
<zyga> that's it
<pedronis> so it's the size computation
<pedronis> it's not really broken
<pedronis> except it is a bit
<pedronis> it was added in 74be4020e
<pedronis> it's a very old bug at least
<pedronis> it's not a regression
<zyga> what is calling .Size()?
<pedronis> ?
<zyga> I mean, what's where's the bug, I see that Size() returns an error if we cannot stat the file
<zyga> but where is that used in practice
<zyga> grepping for '.Size()' shows nothing weird
<pedronis> my  understanding (unproven) is that we fail here:  https://github.com/snapcore/snapd/blob/master/snap/info.go#L801
<pedronis> because of the dangling symlink
<zyga> is it ReadInfoFromSnapFile
<pedronis> no
<pedronis> it's ReadInfo
<zyga> ah
<pedronis> we don't retunr NotFoundError because the mount is there
<zyga> yeah, I see
<zyga> do you want to fix it?
<zyga> or shall I
<pedronis> I actually not sure how to fix it
<pedronis> maybe Chipaca has an opionin, is not super clear that that value make even sense when .snap is a symlink to a dir
<zyga> something like htis
<zyga> http://paste.ubuntu.com/p/C5pHxBYrpM/
<zyga> yeah, the size if bogus in that case
<zyga> I just don't want it to break
<zyga> it should really walk the snap to calculate
<zyga> but that's a separate thing to fix
<mvo> fwiw, I am in a debug shell in try-snap-goes-away and snap list is fine and shows it in "broken" state
<zyga> (I swapped a condition there in the paste but fixed onw)
<zyga> mvo: magic?!
<zyga> why
<pedronis> mvo: it means the mount is gone away
<pedronis> in the bug case it doesn't
<pedronis> well, not the mount
<pedronis> the snap.yaml
<pedronis> mvo: I think there's a difference between rm   the content of the try snap, vs moving it away
<mvo> yeah, that would explain it
<mvo> there must be a difference :)
<pedronis> IÂ mean, I understand there's a difference
<pedronis> mvo:  if the try is moved
<pedronis> the mount is still there
<pedronis> with a snap.yaml
<pedronis> so we fail later in ReadInfo
<pedronis> if you remove the snap.yaml
<pedronis> then you get the broken state
<pedronis> we really need two different tests
<zyga> I pushed a small patch to my PR
<zyga> https://github.com/snapcore/snapd/pull/5067/files check if it makes sense to you please Chipaca
<mup> PR #5067: tests: add a regression test for https://bugs.launchpad.net/snapd/+buâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<zyga> mvo: did you restart https://travis-ci.org/snapcore/snapd/builds/367998252?utm_source=github_status&utm_medium=notification ?
<zyga> did it fail?
<pedronis> anyway I'm not sure it means we need a .6
<pedronis> it's been there since a while
<mvo> zyga: I didn't touch this one
<zyga> pedronis: I agree
<zyga> we can do it later
<pedronis> it's not super typical case
<zyga> unless mvo disagrees
<zyga> but I think it's ok
<zyga> though
<zyga> I'd like to see a deb with this
<mvo> pedronis: aha, this makes sense, yes
<zyga> mvo: maybe it's still worth doing a .6
<zyga> if it is "free" still
<mvo> pedronis, zyga I think we should pull the fix in
<zyga> as in, people get this deb
<mvo> but not necessarily release it
<zyga> not SRU wait
<mvo> just now and in a rush
<zyga> aha
<zyga> ok, I'll defer to your call then
<zyga> man, it's getting too warm over here
 * zyga moves to the shade
<Chipaca> zyga: I doubt it's that path in side info that is causing this
<Chipaca> zyga: as it's able to read the snap.yaml
<pedronis> Chipaca: we found the problem
<pedronis> it's the Size code in ReadInfo
<Chipaca> pedronis: that's what i'm looking at i think
<Chipaca> in https://github.com/snapcore/snapd/pull/5067/files
<mup> PR #5067: tests: add a regression test for https://bugs.launchpad.net/snapd/+buâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<pedronis> been there since 2016
<Chipaca> but the snap.yaml was read ok
<Chipaca> for it to get to the size bit
<pedronis> yes
<pedronis> if you move the try dir
<pedronis> the mount is still fine (until reboot)
<pedronis> so the snap.yaml is there
<pedronis> but the .snap symlink is dangling
<Chipaca> augh
<pedronis> it's different from rm around
<pedronis> fun
<pedronis> anyway, it's not recent code
<Chipaca> can we have a comment
<pedronis> where? who?
<Chipaca> I think I'm lagged to heck
<Chipaca> zyga: with that change, do snaps in this state actually appear as 'broken' in snap list?
<zyga> No
<Chipaca> zyga: should they? :-)
<Chipaca> zyga: either that, or the comment on the task.yaml needs fixing
<Chipaca> zyga: actually the whole test won't work?
<zyga> I didnt try yet
<zyga> I think they should
<zyga> Yes
<zyga> But they wonât just yet
<Chipaca> zyga: I suspect returning NotFoundError instead of ignoring the not found will dwww
<Chipaca> but i haven't tested :-)
<zyga> Yeah, I think so too
<zyga> I force pushed this behavior now
<zyga> let's see what spread says
<mup> PR snapd#5065 closed: spread.yaml: move bionic image forward <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5065>
<zyga> mvo: let's hope master is going to be good now
<zyga> Chipaca: updated: https://github.com/snapcore/snapd/pull/5067
<mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
 * Chipaca  looks
 * Chipaca still lagged
<Chipaca> * Ping reply from Chipaca: 41.707 second(s)
<zyga> woah
<zyga> your packets are going to the moon and back :)
<Chipaca> 3G from the reception of a school in the middle of a field somewhere
<mup> PR snapd#5068 opened: spread: bump delta reference to 2.32.5 <Created by zyga> <https://github.com/snapcore/snapd/pull/5068>
<zyga> how are you testing that?
<Chipaca> zyga: testing what?
<zyga> the ping
<mvo> zyga: thanks for the merge
<Chipaca> zyga: /ping Chipaca
<zyga> can you ping me?
<zyga> my client doesn't report the time
<Chipaca> * Ping reply from zyga: 0.490 second(s)
<zyga> thanks
<Chipaca> zyga: it's very variable today though :-)
<Chipaca> the bar that tells me about ping goes all over the place
<zyga> perhaps you are close to several towers and are constantly doing handover between them
<Chipaca> perhaps the uk 3g network is made entirely of spit and wattle
<Chipaca> and not that much wattle either
<zyga> haha
<zyga> perhaps :)
<zyga> come visit me some day
<mborzecki> 3G? isn't that like umts/hsdpa thing?
<Chipaca> https://opensignal.com/networks?z=15&minLat=51.4545&maxLat=51.4705&minLng=-0.2734&maxLng=-0.2287&s=all&t=2-3 <- i'm at the red splotch in the middle of that
<ogra_> Chipaca, if its so much spit your data should slide through the network fast :)
<Chipaca> zyga: #1764998
<mup> Bug #1764998: profiles making a run for it <amd64> <apport-bug> <bionic> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1764998>
<zyga> Sure, just after lunch
<Chipaca> mborzecki: thanks for the review! i'll work on it in a bit
<mborzecki> Chipaca: np
<jamespage> would someone be able to check who has permissions on the vault charm in the snapstore?
<pstolowski> Son_Goku: hey! I've re-created my spec to follow the new go guidelines, it builds locally but fails on copr on %gometa tag; I've BuildRequires: go-srpm-macros in the spec, do you know what else might be missing?
<zyga> Iâm heading home
<pstolowski> Son_Goku: hey! I've re-created my spec to follow the new go guidelines, it builds locally but fails on copr on %gometa tag; I've BuildRequires: go-srpm-macros in the spec, do you know what else might be missing?
<Son_Goku> %gocratfmeta
<Son_Goku> err
<Son_Goku> %gocraftmeta
<Son_Goku> https://github.com/gofed/go-macros/commit/b8474abd963b4992e8aadd6efbde09833980e985#diff-455385f5d8493917cb83541909b7cfa9
<pstolowski> Son_Goku: ahh, thanks, let me check
<pstolowski> Son_Goku: Unknown tag: %gocraftmeta (copr, rawhide)
<Son_Goku> blech
<Son_Goku> someone has goofed
<Son_Goku> pstolowski, are you in #fedora-devel?
<pstolowski> Son_Goku: i'm now
<Son_Goku> pstolowski, you might want to ask for help there
<Son_Goku> because I'm a bit lost myself :(
 * Son_Goku notes that he's been very wary to change how snapd is packaged because go is already hard
<pstolowski> https://www.irccloud.com/pastebin/vEuTRpRH/
<pstolowski> Son_Goku: it there any BuildRequire that I could be missing? I've this ^ atm
<Son_Goku> let me check
<sergiusens> BjornT_: can I bother you with a review? https://github.com/snapcore/snapcraft/pull/2083
<mup> PR snapcraft#2083: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
<Son_Goku> pstolowski, so here's the macros that are available:
<Son_Goku> * Rawhide: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/master/f/macros.go-srpm
<Son_Goku> * F28: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f28/f/macros.go-srpm
<Son_Goku> * F27: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f27/f/macros.go-srpm
<Son_Goku> * F26: https://src.fedoraproject.org/rpms/go-srpm-macros/blob/f26/f/macros.go-srpm
<Son_Goku> pstolowski, just revert back to the old style and mention in the ticket that you need to support F26 for the moment
<mborzecki> off to pick up the kids
<Son_Goku> the new style seems to be in a weird state right now and it's not supported at all in F26
<pstolowski> Son_Goku: doh, i see.. i hope i still have the old file around ;)
<Son_Goku> if you don't, you can get it from COPR dist git
<BjornT_> sergiusens: sure
<Son_Goku> pstolowski: https://copr-be.cloud.fedoraproject.org/results/pstolowski/go-udev/fedora-27-x86_64/00741447-golang-github-pilebones-go-udev/golang-github-pilebones-go-udev.spec
<Son_Goku> old version is still there ;)
<Son_Goku> just download that and use it again
<zyga> and Iâm back
<pstolowski> Son_Goku: right :)
<pstolowski> Son_Goku: thanks for help!
<Son_Goku> no problem
<zyga> hey, https://github.com/snapcore/snapd/pull/5067 is green :)
<mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<zyga> mvo, pedronis: ^ can you please review it
<zyga> can we land trivial https://github.com/snapcore/snapd/pull/5068
<mup> PR #5068: spread: bump delta reference to 2.32.5 <Created by zyga> <https://github.com/snapcore/snapd/pull/5068>
<zyga> jamesh: hey
<zyga> jamesh: I saw some updates on the user mounts branch
<zyga> I asked a question there
<zyga> also FYI I'm working on somewhat the same idea from another angle (persistence and updates)
<cachio> mvo, hey, we got the +1 to go to stable
<zyga> I will keep de-conflicting your branch as I move along
<zyga> I hope your branch can land soon or at least shrink to 1/10th
<mvo> cachio: great, lets talk in the standup
<jamesh> zyga: that was something I missed when rebasing the branch to clear out what had already been merged.  I dropped the patch with those interfaces/mount/backend.go changes
<zyga> thanks, I'll check the rest soon
<jamesh> zyga: I'm hopeful CI will give me a tick this time around
<zyga> my plan is to land the locking (done), mount namespace setup (in progress) and persistence
<zyga> and then take the privs code from your PR
<zyga> as well as the whole run-snap-update-ns as user
<zyga> I still have to make some update changes but it's not major I hope
<jamesh> zyga: from what I can tell, read only bind mounts are broken in snapd master
<zyga> oh, I will look into that!
<jamesh> zyga: this is due to mount() ignoring all flags but MS_BIND and MS_REC for bind mounts
<zyga> aww, that makes sense
<zyga> man, that's not great then
<jamesh> so MS_BIND|MS_RDONLY is equivalent to MS_BIND
<jamesh> Secure.BindMount gets it right, but required some AppArmor changes to match
<zyga> hmm hmm
<zyga> what's different about the secure bind mount?
<jamesh> that's what the most recent commit in the PR is doing
<jamesh> it follows up with a MS_REMOUNT|MS_BIND|MS_RDONLY mount() call
<zyga> what about MS_REC?
<zyga> what if the initial MS_BIND|MS_REC created multiple bind mounts
<mup> PR snapd#5068 closed: spread: bump delta reference to 2.32.5 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5068>
<jamesh> zyga: at the moment, that errors out.  Alex had some code in flatpak/bubblewrap to parse mountinfo to find out what needed remounting.  So that would be a possibility
<zyga> jamesh: I see, I think I need to look into that
<popeycore> :( 3rd time now I have side loaded a snap and it's completely nuked xorg on 18.04
<zyga> I read that bubblewrap code
<popeycore> lost my entire session immediately after a snap was installed.
<jamesh> zyga: do we have any read only recursive bind mounts?
<zyga> popeycore: xwayland or x
<popeycore> i dont use wayland
<zyga> jamesh: no but AFAIR we made all content recursive, no?
<zyga> and we can use read only content connections
<zyga> still, something to look into
<zyga> popeycore: yeah, that happened to me, though I was not on X at the tiem
<zyga> *time
<zyga> so maybe it's more widespread
<jamesh> there is no obvious examples in the spread tests, and I don't think you can do it with layouts
<zyga> popeycore: did you see my pastebin for checking if classically confined snaps are made correctly?
<popeycore> i wlil try and reproduce it
<popeycore> yes, but it's not my snap, it's Wimpress
<popeycore> and sergio has fixes too
<zyga> jamesh: perhaps it's untested, I will look into that
<jamesh> when AppArmor is used, read only content interface shares are protected
<zyga> ah, that's good
<zyga> at least we're not breaking something that was working (widely) before
<Wimpress> Just returned from lunch. Will rebuild vscode now.
<mup> PR snapd#5054 closed: snap,wrappers: address review feedback from #5043 (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5054>
<zyga> Wimpress: same shout about my pastebin that checks if snap is made correctly
<zyga> I would make it a snap but I need jdstrand to ack an extension of system-observe interface
<mup> PR snapd#5064 closed: tests: smaller fixes for Arch tests <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5064>
<jamesh> zyga: spread tests failed: I introduced a bug in a unit test, and the user-mounts spread test seems to be failing on debian.  I've submitted a fix for the unit test, but not sure why the user-mounts one fails in one place only
<zyga> I'll look after the standup
<zyga> jamesh: again, I'll try to get your branch merged
<zyga> if you want I can take it over entirely
<mup> Issue snapcraft#2071 closed: patchelf to handle RUNPATH <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2071>
<mup> PR snapcraft#2085 closed: elf: clear the current runpath before setting the rpath <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2085>
<jamesh> zyga: it's late here, so I won't check back on it til tomorrow morning.  I think it is fairly clean as is, but there is definitely room for further work
<jamesh> maybe that could go post merge
<zyga> thank you for all the work on this!
<jamesh> (1) recursive read only bind mounts
<jamesh> (2) get Secure.BindMount to handle file bind mounts
<cachio> mvo, zyga, mborzecki could someone take a look to https://github.com/snapcore/spread-images/pull/10
<mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
<jamesh> (2) should be pretty easy with the new secure bind mount strategy
<zyga> yes, the new secure bind mount is awesome :)
<cachio> mvo, zyga mborzecki I have another one with the documentation to push today
<zyga> cachio: sorry, I'm not sure I follow
<mborzecki> cachio: this is for building gce images right?
<zyga> ah
<zyga> I see what you mean now
<cachio> mborzecki, yes
<mborzecki> cachio: like the whole bunch of scripts/tools
<cachio> create images and update images
<mborzecki> ok, got it
<cachio> mborzecki, yes
<cachio> I used those to create update all the images we are already using for gce
<mvo> cachio: thanks, looking
<zyga> cachio: that's quite a diff
<cachio> zyga, yes
<cachio> sorry
<cachio> it started as a small branch to add debian
<cachio> but then I ended up adding all the scripts there
<zyga> cachio: is is spellcheck clean?
<mup> PR snapcraft#2083 closed: python plugin: properly handle distutils on bionic <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2083>
<cachio> zyga, I'll make a spellcheck run again
<popey> Uhm
<popey> I know "snap remove foo", will remove my data from snap/foo/current, but *why* does "snap install foo" do that?
<popey> (I mean I don't agree with either, but install, removing my data, that's a bit mad)
<zyga> popey: can you expand on that please
<zyga> popey: install should not do anything
<popey> i had a snap directory containing data for an application
<popey> i tried running the snap, and noticed thaat i no longer have the snap installed
<popey> so i installed it, tried running it and the config is gone
<popey> i literally have a code editor open and it says the file disappeared
<zyga> hmmmm
<zyga> current is a symlink
<zyga> where was the data exactly?
<popey> sure, but I had a text editor open with snap/foo/current/foo.json open
<popey> i realise current is a symlink, but I guess a symlink to an old version
<popey> but I can't tell now because I have installed the snap so the link has been changed
<popey> i wonder if current was a broken symlink or somehow was a directory?
<zyga> popey: I don't know yet
<popey> my previous full system crash appears to have crashed in the nvidia driver :(
<zyga> interesting
<zyga> maybe mutex thing again ^ mborzecki
<zyga> that TLS mutex library
<mborzecki> hmm
<mborzecki> popey: log?
<mborzecki> or which snap
<popey> i was installing a local snap
<popey> it is always a local snap
<mborzecki> popey: local as in 'snap try'?
<popey> as in i built it and installed with --dangerous
<popey> lemme try installing again to see if i can reproduce
<mborzecki> popey: hm ok, can i say, pull ohmygiraffe, snap pack and snap install --dangerous then?
<popey> you can try :)
<popey> i just tried to reproduce it, and it didn't crash
<popey> https://errors.ubuntu.com/oops/a598af70-4306-11e8-9dfd-fa163e839e11
<popey> ^ thats my crash
<popey> https://errors.ubuntu.com/oops/eb22f554-3c0e-11e8-81fe-fa163e171d9b and https://errors.ubuntu.com/oops/8b8b9504-341d-11e8-8901-fa163ed44aae are also mine
<mborzecki> popey: wow, that's the whole xorg crashing?
<popey> yes, my entire desktop goes bang
<mborzecki> not sure that's something that can be attributed to snaps
<mborzecki> popey: i'll try to reproduce it with ohmygiraffe once we finish the standup
<popey> kk
<zyga> https://bugs.launchpad.net/snapd/+bug/1756317 looks nasty
<mup> Bug #1756317: Can set garbage for core experimental.layouts <snapd:New> <https://launchpad.net/bugs/1756317>
<pedronis> mborzecki: mvo:  we mentioned it yesterday, https://forum.snapcraft.io/t/system-options/87  should document set system
<pedronis> mvo: we didn't discuss goint to stable, I suppose we nedeed cachio for that
<mborzecki> pedronis: let me update that
<pedronis> mborzecki: we need to document both  (and say 2.32.5+ for the 2nd one) for a while I suspect
<mvo> pedronis: yeah, we need him for this, also traditionally we prefer Mon,Tue for this
<mvo> zyga: related to the bug from greyback - pr 4600
<mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<zyga> ack
<zyga> 43 patches :)
<zyga> mvo: it needs a review from niemeyer
<mvo> ok
<mup> PR snapcraft#2086 opened: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
<zyga> given that .5 is in bionic, do we promote .5 to stable?
<niemeyer> mvo, zyga: That's pretty interesting.. will need to dig in a bit to remind myself about the semantics of the changes map
<niemeyer> I think we should eventually expose something along those lines via the API as well
<niemeyer> Details to be figured
<mvo> zyga: .5 is ready for stable promotion we need to decide when we want to do this. traditionally we release to stable Mon,Tue
<mvo> (cc niemeyer -^)
<zyga> doing it now means we can still react to the outcome
<zyga> I think Wed is late in the meaning of "mid week" but it's not too late
<niemeyer> mvo: The delta was just the stop-mode right?
<mvo> niemeyer: stop-mode plus new API
<zyga> niemeyer: https://github.com/snapcore/snapd/releases/
<zyga> I made the release page show some details for the last few releases I worked on
<niemeyer> zyga: Can we please not do that?
<niemeyer> zyga: We have a roadmap page in the forum.. just point it there
<niemeyer> zyga: Otherwise we have two different places, most likely showing different information
<zyga> yes, it doesn't show per release details
<zyga> the point releases we made recently I mean
<niemeyer> zyga: it looks exactly like we want it to look
<niemeyer> zyga: If we want to make it look different, we do
<zyga> sure, I can make that
<zyga> I just thought it is nice to have some information on the GitHub release pages still, I just need to make sure that is in the forum in the end
<niemeyer> zyga: We can point that to the roadmap page.. and we can tune the roadmap page to show more information
<niemeyer> zyga: But we don't want it t be obnoxious
<niemeyer> zyga: What we don't want is multiple people maintaining the same kind of information in different places, with different content
<niemeyer> zyga: Our current roadmap is also much better about providing context about features described.. we need to keep that true.. I'd also prefer to not break down every single patch release in a different section..
<niemeyer> zyga: I suggest having a call today to talk about how we want that organized
<zyga> niemeyer: I'm not sure I agree about not having any information on point releases
<zyga> git log is too ra
<zyga> *raw
<niemeyer> zyga: That's not what I said
<joc> sergiusens: to answer your question from yesterday, yes seems to be a new problem with 2.40
<sergiusens> kalikiana: can you help joc out ^?
<niemeyer> zyga: We should highlight relevant deltas, and demote trivial changes
<niemeyer> zyga: We don't need whole sections for trivial changes
<kalikiana> joc: sergiusens what do you need me to help with?
<sergiusens> not me, joc
<joc> kalikiana: I have a snap that we've been building for a while (months), but since 2.40 is failing to build with some python/pip problems
<kalikiana> joc: Can you paste what's failing?
<mup> PR snapd#5069 opened: configcore: validate experimental.layouts option <Created by mvo5> <https://github.com/snapcore/snapd/pull/5069>
<kyrofa> Chipaca, just realized a script of mine ended up calling `snap install <snap> --channel=` (i.e. no channel at all) which was happily translated to stable instead of yelling at me. Expected?
<kyrofa> Not really a problem, just not what I expected to happen
<kyrofa> And indeed, not what used to happen
<mborzecki> popey: tried both install --dangerous and snap try, no issues
<popey> Yeah, doesn't happen every time, I'm not sure what the critical way to trigger it is
<Chipaca> kyrofa: expected
<kyrofa> Alright
<Chipaca> kyrofa: not sure if it's _right_, but it's expected :-)
<kyrofa> Chipaca, heh, no big deal, just means I need to do my OWN error checking, thanks a lot
<Chipaca> kyrofa: the other option would be to throw an error
<Chipaca> kyrofa: but stable _is_ "" :-)
<kyrofa> Haha
<kyrofa> Yeah no complaint, just a change, wanted to make sure
<Chipaca> kyrofa: it's interesting that you say it's a change
<Chipaca> kyrofa: when did it change?
<kyrofa> My script used to blow up
<kyrofa> I dunno, I'm figuring the core snap updated a while back. My script used to blow up
<kyrofa> (if I forgot to specify a channel)
<kyrofa> Or heck, who knows, maybe it's all in my head
<mup> PR snapd#5070 opened: debian: update LP bug for the 2.32.5 SRU <Created by mvo5> <https://github.com/snapcore/snapd/pull/5070>
<diddledan> kyrofa: did you manage to get anywhere investigating my gimp build?
<jdstrand> zyga: feel free to let me know when 3963 is ready for me to review (I see in backscroll there are failing tests, you may be taking over, etc)
<zyga> thanks, I will
<joc> popey: did vscode get dropped back to rev 29?
<cachio> mvo, are you going to send to proposed the 32.5?
<joc> popey: because that is still not a working revision for me, the last one i have that works is 27
<popey> joc: yup, needs more debugging
<popey> ugh
<popey> Wimpress: ^
<mvo> cachio: yes
<mvo> cachio: I let you know once it gets accepted there
<cachio> mvo, nice
<Wimpress> joc: I've just release rev 27 to stable, beta, candidate
<joc> thanks
<diddledan> Wimpress: joc: revision 29 seems ok here :-/
<diddledan> aah. the font rendering is a problem..
<diddledan> only in the editor window though, the file tree is fine
<joc> diddledan: seems likely to be a host pc specific thing - the error is a missing lib
<pstolowski> zyga: snapcraft doesn't seem to be supporting layouts yet, does it?
<zyga> pstolowski: I don't know
<zyga> perhaps not
<zyga> I usually build snaps by hand
<pstolowski> kyrofa: do you know? ^
<kyrofa> pstolowski, it does not, but in edge you can use the `passthrough` keyword to indicate a set of things you just want passed into the snap.yaml
<pstolowski> zyga: yeah I could do that, but would prefer something I can easily iterate on/rebuild
<pstolowski> kyrofa: sounds great, thanks!
<kyrofa> pstolowski, actually beta and candidate too-- 2.41
<sergiusens> pstolowski, zyga: yeah, please participate https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-41/5022
<pstolowski> sergiusens: yep, i'm just in!
<kyrofa> niemeyer, hey, thanks for merging Saviq's fix, so much better
<niemeyer> kyrofa: np
<niemeyer> kyrofa: Does it work now?
<kyrofa> niemeyer, it does, wonderfully
<kyrofa> Saves me a significant amount of time not needing to manually test on those
<niemeyer> mvo: The release notes say the API was back in .4 .. is that not out yet?
<kyrofa> Now if only squashfuse was in trusty so I could do that too...
<niemeyer> kyrofa: Hmm.. we have snapfuse inside core I think
<kyrofa> niemeyer, I can't install snaps in a trusty lxd instance, should I be able to?
<kyrofa> (core itself can't install)
<niemeyer> kyrofa: I don't know if we have other constraints, but the point of having snapfuse was precisely to make containers work
<zyga> kyrofa: trusty guest on which host?
<kyrofa> zyga, xenial
<zyga> kyrofa: what's the error you see?
<kyrofa> mounting issues, it's been a while since I tried, let me fire one up
<mup> PR snapcraft#2087 opened: Add configuration for AppVeyor <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2087>
<mvo> niemeyer: .4 is not out in stable yet
<mvo> niemeyer: I mean .5 is in bionic so .4 is there by implication. but its not available in a stable core snap or in a stable distro release yet, we can release that today (the stable core with .5 is ready) or Monday, its our call (plus we need to get an ack from the store)
<niemeyer> mvo: ok, got it thanks.. let's have that call shortly and we can also use a bit of time to discuss our options there
<mvo> ok
 * kalikiana heading out for the day
<kyrofa> zyga, huh, nowadays it's "error: cannot communicate with server: Post http://localhost/v2/snaps/core: dial unix /run/snapd.socket: connect: no such file or directory"
<kyrofa> Seems snapd isn't running
<zyga> what's the status of the snapd.service?
<kyrofa> Yikes, systemctl doesn't work either, dbus is busted
<kyrofa> Looks like installing snapd borked things, it pulled in a kernel even though it's a container, wonder if that has something to do with it
<Chipaca> kyrofa: wrt channels (now that i got around to looking), last relevant change seems to be 2016-09
<kyrofa> Chipaca, I shall plead insanity, then!
<Chipaca> kyrofa: you could also shout and posture and claim that I must be wrong
<kyrofa> :P
<mvo> kyrofa: hm, I think we have or had a kernel dependency on trusty
<Chipaca> kyrofa: snapd inside a trusty lxd?
<kyrofa> Chipaca, yep, on xenial host
<Chipaca> kyrofa: I _think_ that isn't meant to work, but I'm not 100%
<Caelum> zyga: I'm posting on the factory list now, that list is actually alive
<kyrofa> mvo, yeah, looks like that's the case
<Chipaca> stgraber: could you remind me if that's expected to work?
<zyga> Caelum: thank you, please keep me posted on the developments :)
<Chipaca> stgraber: 1604 running lxd, a 1404 container in that lxd, running snapd
<stgraber> Chipaca: not supposed to as 14.04 containers don't have apparmor running
<mvo> kyrofa: its a recommends nowdays but still will get pulled in by default. still, that should not kill your dbus :/
<Chipaca> stgraber: thanks
<Chipaca> kyrofa: neener neener
<kyrofa> Chipaca, I'm tired of you telling me no today
 * Chipaca is extremely professional in all his interactions
<kyrofa> :P
<kyrofa> Thanks for clarifying Chipaca, mvo, stgraber
<Chipaca> kyrofa: hey, don't blame me. Blame .... Elves on strike. (Why do they call EMAG Elf Magic)
 * Chipaca puts away the bofh excuse generator for another year
 * zyga takes a break and goes for a walk
<mup> PR snapcraft#2055 closed: python: bring back support for older versions of pip <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2055>
<niemeyer> mvo: Ready when you are
<niemeyer> mvo: Hmm.. nm.. I guess your EOD is now at my 1PM local time..
<Chipaca> oh look at that, it's beer o'clock, and it's lovely outside
<pstolowski> zyga: layouts do not let me bind a subdir under /usr/lib - I get cannot update snap namespace: cannot create writable mimic over "/usr/lib": permission denied; is that by design?
<zyga> No
 * genii checks his Beer O'Clock alarm, but it's it's stilll a seemingly forever 3 hours and 47 minutes away yet
<pstolowski> zyga: ok; so i'm trying to do this: /usr/lib/tcltk/x86_64-linux-gnu/tk8.5:
<pstolowski>       bind: $SNAP/usr/lib/tcltk/x86_64-linux-gnu/tk8.5
<zyga> What is the denial
<zyga> Iâm on a bike now
<pstolowski> zyga: [68891.838823] audit: type=1400 audit(1524071502.757:492): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.scid" name="/tmp/.snap/usr/lib/" pid=15755 comm="3" srcname="/usr/lib/" flags="rw, rbind"
<pstolowski> zyga: ha, enjoy it then, let's talk tomorrow!
<pstolowski> i'm about to eod anyway
<zyga> What is the yaml again
<zyga> The source name looks bad
<zyga> Backwards
<mvo> niemeyer: sorry, real life commitments, but if you have a free slot in 1h I shall be able to attend
<niemeyer> mvo: I certainly do, but don't want to run into your evening.. I didn't realize we had shifted time so much already that my early afternoon is already off-hours for you
<mvo> niemeyer: no worries, a quick syncup is fine
<mvo> niemeyer: I ping you in ~1h, ok?
<niemeyer> mvo: Deal
<mvo> :)
<pstolowski|eod> zyga: https://pastebin.ubuntu.com/p/VgpRx43PVJ/
<mup> PR snapd#5071 opened: tests: replace snap try when possible to speedup tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5071>
<mvo> niemeyer: I'm in the hangout channel now
<niemeyer> mvo: OMW!
<pbek> is there a way to contribute to https://docs.snapcraft.io/build-snaps/syntax? the most valuable parameter "version-script" is missing.
<mup> PR snapcraft#2003 closed: patches: make the ctypes patch more robust and add armhf arch triplet <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2003>
<popey> pbek: https://github.com/canonical-docs/snappy-docs/blob/master/build-snaps/syntax.md
<popey> pbek: that's the repo with those docs in.
<sergiusens> pbek: there's a link at the bottom
<mup> PR snapcraft#2088 opened: grammar: support compound on..to statement <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2088>
<mup> PR snapcraft#2089 opened: many: remove support for remote lxd per project containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2089>
#snappy 2018-04-19
<elopio> jamespage: I was going to tell you that vault is on snapcrafters with some fancy (or hacky) stepped upgrade. But I see you have the latest commit there. Let me know if I can help.
<pbek_> thank you for the link, popey
<pbek_> I didn't make the mental connection from the issue page to the acutal page to edit the documentation sheet ;)
<mup> PR snapcraft#1909 closed: dotnet plugin: add dotnet command to path and enable developer scenario for  snap <enhancement> <Created by rakeshsinghranchi> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1909>
<pbek> popey: I created a pull request at https://github.com/canonical-docs/snappy-docs/pull/390
<mup> PR canonical-docs/snappy-docs#390: added documentation for version-script <Created by pbek> <https://github.com/canonical-docs/snappy-docs/pull/390>
<mborzecki> morning
<zyga> good morning :)
<mborzecki> wanted to try opensuse TW with snapd and nvidia last night, dd'ed gnome live image to usb stick, ran it, zypper dup'ed, installed snapd & NVIDIA (nvidia now maintains a repo with the packages!!) and got a hard lock up, most probably nvidia related :/
<zyga> uh, not fun
<mborzecki> my guess it's gdm trying to do wayland
<mborzecki> it locked up in plymouth screen, just when the tw infinity sign stopped spinning
<zyga> pedronis: updated https://github.com/snapcore/snapd/pull/5067
<mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<jamespage> elopio: hi - popey sorted me out with pertinent access yesterday afternoon - I think I'm all set now aside from some minor confusion around how build.snapcraft.io permissions work
<mborzecki> zyga: left you a comment
<mborzecki> btw. somehow also managed to break polkit & gnome-shell agent
<mborzecki> wow, cannot remove the snap either
<zyga> mborzecki: Ack, looking
<zyga> Fin
<zyga> Fun
<zyga> Looks like another fix on top
<mborzecki>  if anyone wants to give it a try, https://github.com/snapcore/snapd/pull/5034 is simple and easy review
<mup> PR #5034: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
<mvo> zyga: I pushed a core18 PR, it does now show up in mup yet apparently
<mvo> niemeyer: could you please add github.com/snapcore/core18 to the mup announcements?
<zyga> ack, looking
<zyga> mvo: are you sure about the security-policy-stamp?
<mvo> zyga: I can look again
<zyga> I mean, I assume you looked
<mvo> zyga: the description is definitely wrong
<mvo> zyga: we don't have snappy policygen
<mvo> zyga: grep -r securtiy-policy-version over the entire image has no hit
<zyga> yeah, I'm doing the same thing
<zyga> that's a good indication that it is dead
<zyga> yeah, looks like 15.04 leftover
 * mvo ods
<zyga> mvo: about the writable paths
<mvo> zyga: I will poke at it a bit to see if I can remove more but iirc that wasn't working last time
<mvo> zyga: sure
<zyga> how did you pick the things to remove?
<zyga> and are we going to have tests after this PR?
<mvo> zyga: starring at it hard enough
<mvo> zyga: right, tests
<mvo> zyga: man, you ask a lot!
<mvo> ;)
 * mvo hugs zyga 
<zyga> I'm sorry for asking the hard questions :)
<pstolowski> morning
<mvo> zyga: so the short term goal is just to get a base out that is stable enough, i.e. we don't remove packages from it
<mborzecki> pstolowski, mvo: morning guys
<mvo> zyga: so ideally a test would ensure that, i.e. we don't break ABI
<mvo> hey mborzecki and pstolowski ! good morning
<zyga> mvo: sent my full review
<mvo> zyga: thank you
<zyga> sorry for being hard on that one
<mvo> zyga: we could simply remove the entire writable-path in the first go?
<zyga> ah, perhaps
<mvo> zyga: I mean for the purpose of what we need to archive its irrelevant until we boot from core18
<zyga> question: can we mark this as a non-bootable base?
<mvo> zyga: it is right now :) we have no language to mark a base bootable yet
<zyga> mvo: ok, let's just add a comment to snap.yaml
<zyga> describing that given the lack of language we just say it is not bootable yet
<zyga> then +1
<mvo> zyga: cool, will do
<mvo> zyga: I need to tweak it a little bit more it seems, travis failed with some odd error
<zyga> the error look like the binaries have more recent libc requirement than what is in the image
<zyga> mvo: perhaps as a sanity check run tests without your changes
<zyga>  https://toggl.com/blog/startup-zoo-comic/
<zyga> :D
<kalikiana> good morning, snappy
<zyga> hey ho
<mborzecki> travis builds merge the PR branch to master right?
<zyga> ...
<zyga> I don't think so
<mvo> mborzecki: I don't think it does, iirc it just uses whatever is in the PR
<zyga> it tests whatever is pushed
<zyga> there is an option to test the merged branch but we are not using it
<mborzecki> appears we do merge origin/master before running tests, 'tested' empirically
<mvo> interessting, I think this was different in the past
<mborzecki> unit tests in #4844 were failing quite suspiciously
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mborzecki> zyga: BrokenSnapError? (we already show that snaps are 'broken')
<zyga> I called it Corrupted for now but yeah, Broken looks good
<pstolowski> zyga: i found my problem with layouts from yesterday; it was in the fact the i expected it to create extra directory levels before actual mountpoint (maybe it should? are the devs expected to know what existis in the fs?). once it bound /usr/lib/tclk to $SNAP/usr/lib/tclk, it didn't complain anymore
<zyga> Interesting
<zyga> I suspected that while biking
<zyga> I never tested that case
<zyga> thank you for finding it :)
<pstolowski> yw :)
<pstolowski> but i'm nowhere close to get my snap working... tcl/tk is tricky
<pstolowski> zyga: nb, snapcraft will not allow snap with experimental features (passthrough for layout) in the store, it displays explicit warning
<zyga> heh
<zyga> why?
<zyga> that's silly
<zyga> it was not supposed to be that
<pstolowski> The 'passthrough' property is being used to propagate experimental properties to snap.yaml that have not been validated. The snap cannot be released to the store.
<pstolowski> that's what it says
<zyga> yeah but that's not what we discussed
<pstolowski> that's snapcraft from beta channel, so perhaps there is time to change it
<mup> PR snapd#5072 opened: snap,overlord/snapstate: introduce and use BrokenSnapError <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
<zyga> mborzecki: ^ built on top of the earlier one
<mborzecki> ack
<mborzecki> pstolowski: zyga: https://forum.snapcraft.io/t/support-for-passthrough-into-snap-yaml/4698
<zyga> reading the first post reinforces my opinion
<mborzecki> and the message was in the PR that's mentioned in the post
<zyga> yeah but it should not prevent sending that to the store
<zyga> the store should flag
<zyga> but snapcraft should allow it
<pstolowski> indeed, manual review in the store, that's what Jamie said
<zyga> pedronis: 5072 is a follow up to 5067
<pedronis> zyga: I don't think we can use a single error
<pedronis> for exampel the check in doMountSnap is really about presence (mounted, not mounted)
<mvo> zyga: I pushed a poor mans abi test for now
<zyga> I read that
<zyga> I wonder what `which cp` says
<zyga> what's that cp that broke on us?
<mvo> zyga: yeah, something strange in the PATH, when I use /bin/cp its fine
<pstolowski> commented in the passthrough topic
<mvo> zyga: I was wondering earlier if the tar got things messed up, i.e. unpacking to the wrong dir but it was not that
<zyga> pedronis: is #5067 ready from your pop?
<mup> PR #5067: snap,tests : don't fail if we cannot stat MountFile <Created by zyga> <https://github.com/snapcore/snapd/pull/5067>
<zyga> pov?
<pedronis> zyga: I don't think you addressed my comment about Path being optional
<zyga> oh, I didn't notice that
<zyga> done
<pedronis> thx
<pedronis> probably mvo should give it a 2nd quick look
<pedronis> he reviewed an early version
<mvo> pedronis: sure, this is 5067?
<zyga> yes
<pedronis> yes
<mvo> zyga: commented
<zyga> thanks, I'll add notes to both tests
<mvo> ta
<eraserpencil> after successfully running snapcraft and installing the resultant snap with --dangerous --devmode flags, I get this error saying Multiple packages found with the same name "xxx" in snap/parts, snap/prime, and snap/stage
<mvo> zyga: I disabled the core18 writable-path stuff now as well, so we should be good in this area
<eraserpencil> must i delete them to remove that error?
<zyga> kalikiana: ^
<mvo> zyga: if you could have a final look before the merge that would be appreciated, then I can go ahead and build a new core and talk to the desktop team about the details
<Chipaca> eraserpencil: you get those errors after installing your snap?
<eraserpencil> yes
<Chipaca> eraserpencil: but those are snapcraft errors
<zyga> mvo: done on the "snap try" PR
<zyga> looking at core PR now
<eraserpencil> sorry, im not following
<Chipaca> eraserpencil: me neither
<zyga> eraserpencil: can you show the command you ran
<Chipaca> eraserpencil: your snap builds using snapcraft, yes?
<zyga> eraserpencil: and the full error you saw
<eraserpencil> yes
<Chipaca> eraserpencil: was that yes to me or to zyga
<eraserpencil> erm, it's a snap of a ROS package. The command I ran was to initialise ROS.
<eraserpencil> here is the error: https://ghostbin.com/paste/dcdw7
<zyga> mvo: commented
<mborzecki> pedronis: pstolowski: updated #4844
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<eraserpencil> sorry i was disconnected
<zyga> eraserpencil: it looks like the snap is wrong
<zyga> it contains build files from snapcraft
<zyga> only the prime directory should be snapped
<eraserpencil> what does that mean
<zyga> not the whole thing
<Chipaca> zyga: hold on
<Chipaca> eraserpencil: could you run a command and show us its output please:
<Chipaca> eraserpencil: which roscore
<Chipaca> eraserpencil: ^ that's the command
<eraserpencil> here: /opt/ros/kinetic/bin/roscore
<Chipaca> eraserpencil: you're not running the snap
<Chipaca> eraserpencil: could you run this other command: printf "%q\n" "$PYTHONPATH"
<Chipaca> eraserpencil: (and show us its output)
<eraserpencil> Yea, im not. I wanted to run roscore on it's on but snap is tripping it up.
<pstolowski> mborzecki: thanks, looking
<eraserpencil> here: /home/nvidia/mov/catkin_ws/devel/lib/python2.7/dist-packages:/opt/ros/kinetic/lib/python2.7/dist-packages
<Chipaca> eraserpencil: ok, I don't know why ros is picking up libraries from under your current directory
<Chipaca> eraserpencil: but, it's not the snap's fault, I figure
<Chipaca> eraserpencil: run roscore from a different directory
<eraserpencil> same thing
<Chipaca> eraserpencil: show me please
<eraserpencil> erm exact same error
<Chipaca> ok, let me re-read this conversation because I'm getting lost
<Chipaca> eraserpencil: how did you build the snap?
<eraserpencil> https://ghostbin.com/paste/d7ox5
<eraserpencil> the error shows that python tried to find packages but found multiple packages of the same name
<Chipaca> eraserpencil: I saw it that way first, but it's not python, it's ros itself
<Chipaca> eraserpencil: and it's not looking in the snap
<eraserpencil> ahh, the python plugin for ROS has a script that searches recursively for packages.
<Chipaca> eraserpencil: I think the most productive use of our time would be to wait for kyrofa to be online
<eraserpencil> My snap is within the catkin workspace
<eraserpencil> ok
<Chipaca> eraserpencil: he's on -0700 so it'll be a while still
<eraserpencil> which time line is that?
<Chipaca> eraserpencil: PDT I think
<eraserpencil> ok thanks
<eraserpencil> btw im having trouble with both demos of  https://docs.snapcraft.io/build-snaps/python
<Chipaca> eraserpencil: what sort of trouble?
<eraserpencil> https://ghostbin.com/paste/teoza
<eraserpencil> for the youtube-dl demo
<Chipaca> let's see...
<Chipaca> eraserpencil: I'm not sure what you're doing exactly, but I just made a directory, entered it, copied the youtube-dl snapcraft.yaml, and run snapcraft, and it's compiling libavcodec and stuff after successfully getting the source
<Chipaca> eraserpencil: what version of snapcraft do you have?
<eraserpencil> 2.4
<Chipaca> eraserpencil: 2.4, or 2.40?
<eraserpencil> 2.40
<Chipaca> snapcraft just finished building youtube-dl
<Chipaca> so, it works
<Chipaca> eraserpencil: there's something nonstandard about your setup you're not telling us
<eraserpencil> really wish i knew. I've tried it on different computers
<Chipaca> eraserpencil: ok, walk me through what you do, step by step
<Chipaca> eraserpencil: first, what distribution are you on?
<eraserpencil> mkdir ~/snap
<eraserpencil> cd ~/snap
<eraserpencil> git clone git clone https://github.com/snapcraft-docs/youtube-dl
<eraserpencil> cd youtube-dl
<eraserpencil> snapcraft
<eraserpencil> Ubuntu 16.04
<popey> dont do mkdir ~/snap :)
<popey> build your snaps somewhere else.
<popey> it will get all very confusing once you install a snap and the ~/snap directory will then contain a youtube-dl directory which contains the runtime data for the app
<Chipaca> good point (although I doubt that's the cause of the errors)
<Chipaca> eraserpencil: repeating those steps here (also 16.04)
<Chipaca> eraserpencil: I didn't get that error
<Chipaca> eraserpencil: is snapcraft version 2.40, or 2.40.1?
<eraserpencil> 2.40
<Chipaca> eraserpencil: from where did you install it?
<eraserpencil> i cant rem
<eraserpencil> I was installing spotify as a snap
<Chipaca> eraserpencil: dpkg -l snapcraft
<eraserpencil> 2.40
<zyga> pstolowski: can you please amend your forum post on layouts with the denial you saw
<zyga> it will make it easier to fix
<Chipaca> eraserpencil: looks like you're running it from the deb, ok
<Chipaca> eraserpencil: i've just installed it as well
<pstolowski> zyga: sure
<zyga> thank you
<Chipaca> eraserpencil: what does "git version" say?
<popey> Ok, who wants a fun bug for today? snap install isn't pulling in core... http://paste.ubuntu.com/p/KyPhgc5zHs/
<eraserpencil> 2.7.4
<zyga> popey: oh, maybe mvo
<zyga> mvo: ^ looks bad
<eraserpencil> i removed ~/snap and recloned youtube-dl
<eraserpencil> does look good for now
<mvo> zyga: Setting up snapd (2.21-2+b1) ...
<Chipaca> eraserpencil: FWIW I cloned it into ~/snap as well and it worked here
<zyga> mvo: yes, that's debian
<mvo> popey: what does `snap changes` tell you?
<Chipaca> eraserpencil: I'm now trying to downgrade my git to see if it's that
<thresh> hmm, did something change wrt to .config access from the apps?  I seem to get apparmor denials.
<mvo> zyga, popey: ohhh, debian
<popey> mvo: fwiw, installing a snap on its own, not multiple, it installs core
<thresh> like [94066.971259] audit: type=1400 audit(1524129374.572:1024): apparmor="DENIED" operation="link" profile="snap.vlc.vlc" name="/home/thresh/snap/vlc/273/.config/vlc/vlc-qt-interface.conf" pid=9800 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 target="/home/thresh/snap/vlc/273/.config/vlc/#270577332"
<mvo> popey: thats sad
<Chipaca> mvo: that might be 2.21's way though
<mvo> popey: I mean, its good that at least in the one-snap case it is DTRT
<mvo> Chipaca: yeah
<popey> http://paste.ubuntu.com/p/6ZHDG2Hhtq/
<zyga> but ...
<zyga> core       16-2.32.3      4408  stable    canonical     core
<zyga> you have core now
<zyga> so what happened
<popey> yeah, now I installed nextcloud
<popey> the second paste is immediately after the first
<popey> i had no core, installed nextcloud (one snap on its own) and now have core
<popey> if you specify multiple snaps you dont get core
<popey> thats my current way to reproduce it
<mvo> popey: could you please also pasetbin snap change 1 and snap change 2 ?
<mvo> popey: it might be that you get ubuntu-core in the first transaction that re-execs, does the ubuntu-core -> core transition behind your back
<popey> mvo: http://paste.ubuntu.com/p/D6SZypWQPy/
<mvo> popey: ta!
<popey> no, got no core
<mvo> popey: yeah, no core at all
<mvo> popey: :(
<popey> i can file a bug with steps to reproduce
<popey> ?
<mvo> popey: please do
<popey> on it
<mvo> popey: I am not sure what we can do about it though, I think we would have to upload a fixed deb
<mvo> popey: because the re-exec fix will not be pulled down because there will be no core :/
<popey> great! I love the sound of an updated snapd in debian ;)
<Chipaca> mvo: popey: 2.21 had the install core only for single snaps
<mvo> Chipaca: yes, I vaguely remember it was different code-paths
<Chipaca> mvo: it used ensureUbuntuCore in daemon/api.go
<Chipaca> mvo: instead of a flag in snapstate
 * mvo nods
<Chipaca> does debian let us SRU
<zyga> I just reproduced this on debian
<Chipaca> zyga: it's not a bug, it's a missing feature
<zyga> Chipaca: it's not a bug it's a hole in the plane
<Chipaca> eraserpencil: I can't reproduce your issue,  even with the same versions of git and snapcraft and doing it in the same directory on the same ubuntu
<Chipaca> eraserpencil: Â¯\_(ã)_/Â¯
<zyga> mvo: can we get to 2.32.5 in debian ;)
<Chipaca> zyga: I mean: 2.21 did not add core to the list when doing a multi-snap install
<mvo> Chipaca, zyga debian has pretty strict policies, but we can always try if the diff is not too terrible we have a chance. or we put an updated snapd into the debian backports repository
<mvo> zyga: 2.32.5 would be for -backports but I like the sound of it
<zyga> back ports sounds good but they are not enabled by default, right?
<Chipaca> mvo: is backports an enabled-by-default-but-not-used job? ie a flag to apt away from working, or does it need enabling?
<popey> https://bugs.launchpad.net/snapd/+bug/1765355
<mup> Bug #1765355: Installing multiple snaps doesn't install core (debian snapd2.21) <snapd:New> <https://launchpad.net/bugs/1765355>
<Chipaca> popey: which debian is this btw
 * popey looks in the bug report
<popey> https://www.raspberrypi.org/downloads/raspberry-pi-desktop/
<popey> that debian :)
<popey> 9.4
<zyga> Chipaca: it also affects vanilla 9
<mvo> Chipaca: I think its just like our -backports, i.e. "apt install -t foo-backports snapd"
<mvo> Chipaca: but I'm not 100% certain
<Chipaca> popey: can you try that ^
<mvo> if they are not enabled its much less appealing :/
<popey> i see no backports in sources.list
<popey> only stretch and stretch-updates
<zyga> same
<zyga> I think we want backports anyway
<zyga> we can then get more recent snapd cleanly
<zyga> with all the non-reexec fixes
<popey> that would add some additional steps to getting snapd on debian
<pedronis> mvo: zyga: can't we have people opt-in into reexec somehow on debian?Â I understand we cannot make it the default
<zyga> pedronis: sure
<zyga> pedronis: but reexec doesn't fix this issue
<zyga> pedronis: and on that version it is actually the default
<pedronis> what's the issue?
<zyga> snap install foo bar; # not pulling in core
<pedronis> ah
<pedronis> well, too bad
<pedronis> doing a fix for exactly that will be annoying
<pedronis> it might be easier to return an error in that case if there is no core
<pedronis> if we are looking at doing a change only for that
<pedronis> on top of an old snapd
<mup> PR snapd#5067 closed: snap,tests : don't fail if we cannot stat MountFile <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5067>
<eraserpencil> Chipaca: either how, thanks alot
<eraserpencil> lots to ask kyrofa
<zyga> https://github.com/mjl-/duit :D
<zyga> mvo: your missing UI toolkit for the prompts ;-)
<mvo> zyga: oh
<mvo> kalikiana: quick question: is the snapcraft that is used in LP building using snap pack? I asked because it looks like for core18 it breaks permissions, i.e. it maps everything to root. I think we need to ensure that bases are not using "-all-root"
<Chipaca> mvo: snapcraft is not yet building using snap pack afaik
<mvo> Chipaca: ta
<Chipaca> mvo: for that we need to package the standalone snap helper thing
<axino> hi
<axino> are snaps in LXDs still somewhat problematic ? (on xenial)
<popey> installing them or building them?
<zyga> axino: I think so, until 2.32.5 hits xenial (SRU)
<axino> popey: installing
<axino> zyga: OK thanks
<popey> i found just installing squashfuse allowed me to install snaps inside lxd
<mup> PR snapcraft#2090 opened: internal: skip -all-root for base snaps <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2090>
<zyga> popey: that's correct but there are more issues later
<popey> oh ok
<zyga> still, it's all fixed and the SRU will be released shortly (hopefully)
<mvo> popey: what version of snapd do you have in lxd right now?
<popey> hard to say, i have a ton of lxd containers :)
<mborzecki> Chipaca: left a couple more comments in the snapshots pr
<mvo> popey: ok, the sru with the fix should be in -updates at tihs point so if that was something you experienced recently it would be great to know what version the snapd deb had
<popey> ah, these are often long standing lxd containers that i forget to apt upgrade
<mvo> popey: thats fine, if you experience issues in a fresh (and up-to-date) one, please shout so that we can investigate :)
<mvo> zyga: another (trivial) core18 thing
<zyga> ack
<zyga> can we do two things
<zyga> drop debconf + debconf i18n
<zyga> and and and
<zyga> if you can measure the size
<mvo> zyga: I will probably do two more and then it should be fine. all related to uids - remove the apt user and make the two systemd users auto-created instead of hardcoded
<zyga> install locales-all
<zyga> ah, awesome
<mvo> zyga: but probably after lunch
<zyga> reviewed
<mvo> zyga: locales-all? hm, hm, I think it makes sense, let me add it and see what size impact it has
<mvo> zyga: looks like it jumps from 24mb to 36mb with locales-all
<zyga> 8 megs
<zyga> is that with compression
<zyga> or without?
<mvo> zyga: that is the raw snap size, so with compression
<zyga> I wonder if each language contributes the same amount of space
<Chipaca> mborzecki: what are the comments about cleanup about?
<zyga> mvo: are those with i18n or just with non LC_MESSAGE things?
<zyga> if we drop .mo files is it the same?
<mborzecki> Chipaca: just stating the fact that the code looks good and afaict does not leave garbage behind :)
<Chipaca> mborzecki: ah, phew :-)
<Chipaca> waaaait
<Chipaca> mborzecki: why is snapshotmgr in that PR
<Chipaca> oh dammit i pushed the whole thing D:
<mborzecki> Chipaca: hah, no clue ;)
<Chipaca> mborzecki: sorry, will fix
<Chipaca> uh, probably with a --force
<mborzecki> Chipaca: and i was like, nice, new stuff for review ;)
<Chipaca> that was meant to go in the _next_ batch
<Chipaca> this one was already over the 1k
<Chipaca> â¦ i guess i can leave it if you've already reviewed it
<Chipaca> nah, it'd be messy. cleaning it up.
<Chipaca> that should do it
<mborzecki> Chipaca: no worries, i went though cachio's pr in the morning, i think yours was shorter
<Chipaca> heh
<Chipaca> wait, QA is supposed to be about raising the bar, not lowering it :-p
<mvo> zyga: one more for core18 and then I consider that bit finished for today
<zyga> ok
<zyga> mvo: ok
<zyga> mvo: nothing about locale?
<jamesh> zyga: finally got a green tick on https://github.com/snapcore/snapd/pull/3963
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<zyga> I read all the changes you made since
<zyga> now reading the whole diff again
<zyga> jamesh: any reason file bind mounts are not using sec.BindMount?
<zyga> kind == "" || kind == "file" would work IMO
<jamesh> zyga: at the moment, Secure.OpenPath uses the O_DIRECTORY flag, so it would fail.
<zyga> ah, indeed
<jamesh> zyga: it would be pretty easy to get BindMount to work for files, but I thought it would be better to do that as a follow up branch rather than making this one bigger
<zyga> yeah, I agree
<zyga> +1
<zyga> mborzecki: can you do a 2nd review please
<jamesh> the last few spread test failures were down to "su" on Ubuntu and Debian being different to the other distros.  I've got something working everywhere now though
<zyga> jdstrand: I believe the non-persistent per-user mount namespaces are okay now. Can you have look please.
<zyga> yeah, saw that, interesting; I would say it would be easier of spread ran as a user but it's too late for that
<thresh> out of curiousity, am I the only one experiencing way longer build times than previously with snapcraft?  my builds get "stuck" on "Preparing to build $foo", with snapcraft using 100% for minutes, apparently reading every file there is?
<thresh> this is happening since a couple of weeks at least
<thresh> e.g. now it takes an hour to do a build, while at the end of March the builds took around 40 minutes
<thresh> this is reproducible on every machine I have, with snapcraft 2.40 from Xenial
<thresh> https://jenkins.videolan.org/job/vlc-nightly/job/vlc-nightly-snap/buildTimeTrend shows the trend pretty nicely
<Chipaca> jamesh: zyga: how is su different?
<jamesh> Chipaca: we have the version from shadow, and everyone else uses the one from util-linux
<Chipaca> ah
<jamesh> Chipaca: shadow's su allows --login and --preserve-environment together, while util-linux's one ignores -p if used with -l
<Chipaca> we are rather brilliant at that, aren't we
<Chipaca> we should find a distro that's linux with no gnu tools just for extra fun
<Chipaca> anyway, lunch now because meeting later
<jamesh> do you want to port snapd to OpenBSD? :)
 * Chipaca afk
<mup> PR snapd#5034 closed: userd: set up journal logging streams for autostarted apps <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
<Chipaca> jamesh: is there openbsd/linux?
<jamesh> they've got something even better: openbsd/openbsd
<Chipaca> 'starch linux'
<mup> PR snapd#5070 closed: debian: update LP bug for the 2.32.5 SRU <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5070>
<mborzecki> Chipaca: starch linux - sticky when wet
<pstolowski> Son_Goku: hi Neal! can you help push https://bugzilla.redhat.com/show_bug.cgi?id=1567819 through?
<mup> PR snapd#5073 opened: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5073>
<Chipaca> mborzecki: it's dead now i think, but it was a statically-linked arch-based thing
<Son_Goku> pstolowski, yes I can
<Son_Goku> I've taken the review (though note *any* Fedora packager can review another Fedora package)
<Son_Goku> so even zyga and kyrofa could have done it
<zyga> mmm,
<Son_Goku> the only thing *I* can do is sponsor new packagers in
<seb128> thresh, did you report a bug or post on the forum about it?
<thresh> seb128, I found a similar thread on the forums saying it's a feature https://forum.snapcraft.io/t/snapcraft-builds-taking-a-long-time-in-snap-vs-run-from-source/4280/3
<pstolowski> Son_Goku: thanks, I see; but surely some "core" fedora dev need to bless it for landing even if it has reviews of other packages, right? is that your role?
<seb128> thresh, is there any chance you could try if .41 fixes your issue?
<thresh> seb128, is it in xenial already?
<Son_Goku> pstolowski, nope
<thresh> I suppose I could if it's packaged.
<Son_Goku> only because you don't have any packages in fedora am I required to step in at all
<seb128> thresh, in xenial-proposed at the moment
<Son_Goku> pstolowski: that's what FE-NEEDSPONSOR is about
<zyga> pstolowski: fedora is very open for contribution
<seb128> thresh, https://launchpad.net/ubuntu/+source/snapcraft/2.41
<seb128> thresh, you can download the debs on https://launchpad.net/ubuntu/+source/snapcraft/2.41/+build/14770947
<Son_Goku> pstolowski: forget everything you learned about the bureaucracy of Debian and Ubuntu
<Son_Goku> almost none of it applies to Fedora
<pstolowski> Son_Goku: :D
<zyga> the only issues we may encounter is if we wish to influence the default kernel configuration
<zyga> so if we want to enable apparmor in the kernel, that's not going to fly easily and we'd have to discuss this and how it would be supported
<Chipaca> does hangouts not work with the snapped firefox?
<thresh> thanks seb128, trying it now
<seb128> thresh, great, let us know if it works better!
<zyga> Chipaca: it should work with the ESR thing
<zyga> but not with normal ff
<mborzecki> off to pick up the kids, bb for standup
<zyga> because die plugins, die
<mvo> zyga: fwiw, duit looks exceedingly cool
<mvo> zyga: at least from a quick glance
<zyga> it's a "send yaml to C helper" design
<mvo> zyga: the wrapper pointer is interessting but I'm sure people will hate it
<Son_Goku> pstolowski: https://bugzilla.redhat.com/show_bug.cgi?id=1567819#c8
<zyga> I wasn't suggesting we actually use it
<zyga> just that I found it interesting
<zyga> pedronis: updated #5072
<mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
<zyga> let me know if that's what you had on your mind
<zyga> I think it's close to the original idea where we just held an internal error reference
<pstolowski> Son_Goku: great, thanks a lot! will do the reviews
<zyga> but I agree this is cleaner as an interface
<zyga> oh, I misread part of your review
<zyga> I'll make NotFoundError public again and restore that part of the code
<mup> PR snapd#5057 closed: tests: bring back one missing test in snap-service-stop-mode <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5057>
<zyga> pedronis: corrected now
<pedronis> zyga: I'm in a meeting atm
 * kalikiana lunch
<Chipaca> current meeting overrunning
<mup> PR snapd#5074 opened: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
<Chipaca> i'll be a minute
<thresh> seb128, no, it didnt change it at all, still 65 minutes per time(1)
<seb128> :/
<seb128> sergio is not around
<seb128> Chipaca, do you know who knows about snapcraft and could help thresh with a regression that impact vlc builds?
<Chipaca> seb128: kalikiana? kyrofa ?
<seb128> Chipaca, thanks
<seb128> kalikiana, kyrofa, can you help thresh?
<zyga> jdstrand: hey, around?
<kalikiana> thresh: Looking at the backlog... so as of 2.40 builds take a lot longer than before?
<thresh> kalikiana, yep, correct.
<jdstrand> zyga: hey, yes
<zyga> jdstrand: something interesting came up wrt layouts
<zyga> jdstrand: I summarised it in this short comment: https://github.com/snapcore/snapd/pull/5074#issuecomment-382728218
<mup> PR #5074: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
<jdstrand> zyga: did you also say pr 3963 could be reviewed?
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<zyga> yes
<zyga> please do, though that's a bigger cookie :)
<jdstrand> zyga: I commented on 5074. I did not review the pr
<kalikiana> thresh: Considering it's not a classic snap the forum post you linked shouldn't matter...  Do you happen to know what version it was that became so slow?
<thresh> kalikiana, what version of what exactly?
<thresh> kalikiana, snapcraft?  2.40 from ubuntu xenial repos.
<kalikiana> thresh: Lemme re-phrase. You said with 2.40 it became slow. What were you using before?
<thresh> kalikiana, it was 2.39.3+really2.35.
<kalikiana> Okay
<kalikiana> thresh: Is this just building vlc from git?
<kalikiana> Going from the log
<thresh> kalikiana, plus some contribs;  essentially yes.  https://jenkins.videolan.org/job/vlc-nightly/job/vlc-nightly-snap/
<kalikiana> Yeah. Just checking what's needed to repro
<thresh> the slowest part is "Preparing to build vlc" -- the build stays there for 15-20 minutes afaict
<mup> PR snapd#5060 closed: tests: detect kernel oops during tests and abort tests in this case <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5060>
<thresh> we're building in the docker images, containing needed packages since I don't allow jenkins users to be in a sudo group.  The image is registry.videolan.org:5000/vlc-ubuntu-xenial.
<seb128> sergiusens, hey, ^ do you have any idea about that vlc issue?
<sergiusens> seb128 thresh: `Preparing build` is basically unpacking all the stage-packages to their destination
<seb128> sergiusens, is that known to be longer/having an issue since 2.40? thresh said it was working fine with 2.39.3+really2.35
<sergiusens> how many stage-packages are we talking about. I have an item to improve the messaging there
<sergiusens> seb128: we have no known issues on this side
<sergiusens> is it slow just on that docker container or out of it as well?
<thresh> jenkins@0792d2e4c997:~$ find .cache/snapcraft/stage-packages/ -type f -name "*.deb" | wc -l
<thresh> 419
<thresh> I never tried out of a docker container;  could try with an lxd, but not right now and on a very different power-wise machine
<thresh> but that also happens on my laptop with an nvme, I wouldnt imagine that unpacking a few hundred megabytes of .debs should take that much time
<mvo> cachio: 2.32.5 is in *-proposed now, no rush though with the verification
<sergiusens> seb128: the only potential change we have is we went from calling dpkg-deb to using a python implementationdebian.arfile
<sergiusens> thresh: ^
<sergiusens> I will run some numbers against that, but I cannot do that today
<thresh> I do see python proccess doing a lot of read/write under strace, yes
<seb128> thresh, I recommend you open a post on the forum which can be used for debugging/discussion
<seb128> the python thing might be much slower than dpkg-deb?
<sergiusens> seb128: we do track bugs too you know ;-)
<seb128> sergiusens, you mean you prefer  bug report on launchpad? or that rather you don't need me in that discussion? ;)
<thresh> heheh
<seb128> sergiusens, I started responding because nobody picked up his question earlier
<sergiusens> seb128: we do not have a need for that feature anymore given the last PR I am working on, so we could potentially move back to dpkg-deb without much thought
<thresh> and you are most welcome for that, seb128
<seb128> :)
<sergiusens> seb128, thresh: a bug report makes it not fall through the cracks, that's all
<seb128> sergiusens, it does for the snappy team, that's why I asked to use the forum ... but good to know snapcraft is better at that :)
<sergiusens> the forum is nice to have something like this initial conversation we just had on irc :-)
<seb128> right
<zyga> jdstrand: quick feedback, I wrote a helper that constructs the /{,funky/{,paths}}
<zyga> and this is the apparmor profile after the change
<zyga> xmas-tree-ified profile https://www.irccloud.com/pastebin/UWVbEfBd/
<zyga> Looking at line like: ...     "  mount fstype=tmpfs options=(rw) tmpfs -> /{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/,\n" +
<zyga> makes me say, use right-recursion and isProbablyPresent to avoid some of the things
<zyga> as this essentially allows tmpfs over /
<jdstrand> zyga: heh, just make sure you have a test that runs apparmor_parser on the resulting profile :)
<zyga> haha
<zyga> well, layouts tests will do
<zyga> but yeah
<zyga> but I was wondering if / should be off limits somehow
<zyga> so that we allow at most /foo but not /
<zyga> this profile will certainly make apparmor parser more busy ;)
<jdstrand> zyga: so you have /{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/
<jdstrand> zyga: why not /usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}/ ?
<zyga> yes
<zyga> that's my thinking
<zyga> I can easily adjust that
<zyga> and we cannot do things on / directly anyway
<zyga> I added xmasTree function
<jdstrand> right
<zyga> I'll add trunkedXmasTree
<jdstrand> zyga: btw, 3963 is approved
<zyga> woot, thank you
<zyga> I have some things on top I will try to propose but probably not today (or late)
<zyga> I want to use the sun and go biking with my wife
<jdstrand> zyga: well, I'm still working on other things
<jdstrand> with critical priority, so... take your time :)
<zyga> sure, thank you for the feedback! :)
<jdstrand> np :)
<zyga> jdstrand this with variable trunk size https://www.irccloud.com/pastebin/3SkvTtEr/
<zyga> There are some things that can be simplified now
<zyga> ...     "  /snap/tricky/42/{,usr/{,lib/{,tcltk/{,x86_64-linux-gnu}}}}/** rw,\n" +
<zyga> ...     "  /snap/tricky/42/usr/lib/tcltk/x86_64-linux-gnu/ rw,\n" +
<zyga> I think we can essentially stop making the non-xmas versions
<zyga> as they represent the same assumption
<jdstrand> neat
<zyga> I'm happy how it looks like
<zyga> the trunk length depends on what we do
<zyga> so for $SNAP it is 3
<zyga> but for target it is 1
<zyga> so /snap/name/rev is expected to be there
<zyga> but on the other side we just expect /toplevel
<mup> PR snapd#5075 opened: snap/env: fix env duplication logic <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
<mup> PR snapcraft#2090 closed: internal: skip -all-root for base snaps <bug> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2090>
<pedronis> zyga: should IÂ pick up pushing my small comment fixes to #5072 if you are busy with other things?
<mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
<mvo> sergiusens: \o/ for merging the -allroot pr
<zyga> pedronis: re, please! thank you
<pedronis> zyga: ok, will do
<zyga> sorry, I was focusing on apparmor and I didn't notice the ping
<sergiusens> mvo: glad to make you happy
<zyga> pstolowski: I fixed the bug you found locally, I will re-run spread and push the fix :)
<pedronis> mvo:  the failure here looks weird:  https://travis-ci.org/snapcore/snapd/builds/368626305?utm_source=github_status&utm_medium=notification
<pstolowski> zyga: very nice, thank you! i'm honored you considered this case tricky ;)
<pedronis> mvo:  Reading package lists...
<pedronis> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
<pedronis> in the lxd test
<zyga> pedronis: ha
<zyga> we had that once before
<zyga> I wonder how that happens
<zyga> it went away on re-try
<zyga> seems like sed gone wrong
<pedronis> ok, anyway about to repush
<zyga> 's'ecurity
<pedronis> zyga: pushed
<zyga> thanks
<mup> PR snapcraft#2091 opened: meta: soften warning about using passthrough <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2091>
<rogpeppe> quick question: is it possible to give a snap the privilege to be able to open a web page in the user's browser (without using classic confinement) ?
<sergiusens> rogpeppe: if the app uses xdg-open that should already work
<matiasb> sergiusens, o/ fyi, this one https://github.com/snapcore/snapcraft/pull/2086 finally completed and passed its travis run, we are trying to get the store changes rolled out this afternoon
<mup> PR snapcraft#2086: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
<sergiusens> matiasb: ack
<jdstrand> roadmr (cc Wimpress, sergiusens, niemeyer): hey, can you pull r1026 of the review-tools? this has the refresh-mode and stop-mode work
<kyrofa> Is the store down?
<jdstrand> JamieBennett: fyi ^
<roadmr> no
<jdstrand> roadmr: no? :P
<roadmr> jdstrand: yes to you, no to kyrofa  :)
<jdstrand> :)
<kyrofa> Looks like api.snapcraft.io is
<roadmr> kyrofa: correction, looks like it *is* down
<cprov> deadly slow
<cprov> and it's back to normal request timing, investigating what caused the blip
<roadmr> cprov: oh is it?
<jdstrand> roadmr: oh, thanks btw :)
<roadmr> jdstrand: np, I'm submitting the merge proposal now
<jdstrand> \o/
<jdstrand> roadmr: fyi, upstream electron-builder claims to have fixed the resquashfs, so in r1027 I updated the resquash error output to reference the fixed version. r1027 is not urgent, but if it can piggyback on r1026 from earlier, that would be cool
<jdstrand> roadmr: sorry for the quick extra request
<jdstrand> roadmr: we still have a partner issue and I'd like for electron-builder to have a chance to get out there, so don't want to turn on enforcement just yet
<jdstrand> roadmr: but having r1027 in place when we do would be good
<roadmr> jdstrand: no problem! I'll put 1027 in, probably willjust leapfrog 1026 which is already queued
<jdstrand> roadmr: cool, thanks
<cratliff> Hey, I asked this on the forum a while ago and didn't get a response: Some of the different gadget snaps don't have associated licenses, under the license field on launchpad they say "I don't know" Are they available for use?
<sergiusens> kenvandine: today was the day for core18 in stable, do you know if that happened?
<sergiusens> or was it 7 days from now?
<sergiusens> cratliff: which gadget in particular? I suspect that ogra_ could help, but you should be able to use the ones from Canonical just fine, as usual, IANAL ;-)
<cratliff> pc_amd64 in particular, but others don't have licenses as well.  I mean, I thought so, because it's used in demos and tutorials published on your website.  IANAL either, but my understanding is no license should be treated as proprietary.
<nacc> who do I talk to about modifying the publisher entry for a snap?
<mup> PR snapcraft#2092 opened: schema: allow refresh-mode and stop-mode <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2092>
<sergiusens> matiasb: can you confirm that https://github.com/snapcore/snapcraft/pull/2086 works against production?
<mup> PR snapcraft#2086: tests: update metadata store integration test, no previous push required <Created by matiasb> <https://github.com/snapcore/snapcraft/pull/2086>
<sergiusens> nacc: on the forum or maybe noise][ or roadmr can help
<nacc> sergiusens: thanks, will do
<matiasb> sergiusens, it will work as soon as we rollout, which is in the queue; in any case the failing test is really a restriction we lifted store-side, so we are not breaking anything just enabling something that wasn't possible before
<sergiusens> thanks for confirming matiasb
<matiasb> np
#snappy 2018-04-20
<mup> PR snapcraft#2089 closed: many: remove support for remote lxd per project containers <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2089>
<mup> PR snapcraft#2091 closed: meta: soften warning about using passthrough <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2091>
<zyga> good morning
 * zyga notices https://github.com/apple/foundationdb/
<mborzecki> morning
<zyga> hey hey
<mborzecki>  google cloud packages repo for fedora had their gpg keys change
<mborzecki> i'm testing a fix
<zyga> thanks
 * zyga had a rough morning with upset daugher
<zyga> daughter
<mup> PR snapd#5076 opened: spread: auto accept key changes when calling dnf makecache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5076>
<mborzecki> zyga: i've resarted the build in #5074, it failed synchronizing fedora repo
<mup> PR #5074: interfaces/apparmor: add test case for tricky writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
<zyga> mborzecki: ah, it's not ready yet
<zyga> that's all right
<zyga> I will force push a full fix and tests on top
<mborzecki> ok
<pstolowski> mornings
<kalikiana> morning o/
<pedronis> #5072 needs a 2nd review
<mup> PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5072>
 * zyga keeps fighting the bug that pawel found
<Chipaca> zyga: new one?
<zyga> no, still the same one
<zyga> it's just tricky to get the rules right
<zyga> I know what I'm missing
<zyga> but iteration is a bit painful
<pedronis> m-v-o is off today?
<zyga> pedronis: yes
<zyga> he said he'd be off yesterday IIC
<zyga> IIRC
<Chipaca> ye
<Chipaca> s
<Chipaca> yesteray he said he'd be off today and monday
<pedronis> ah, ok
<pedronis> thx
<mup> PR snapd#5072 closed: snap,overlord/snapstate: introduce and use BrokenSnapError <Squash-merge> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5072>
<pedronis> zyga: merged  ^
<zyga> nice, thank you!
<zyga> so one less "snap try" bug
<zyga> I think there are some other places that may need similar changes
<zyga> like there's ReadInfo that takes a container
<zyga> it has the same issues
<pedronis> I'm not sure Broken  and Error should have the same value (we have more context when we use Broken but we can revisit later)
<pedronis> zyga: we use it in much more precise contexts
<pedronis> usually before we are installing something
<pedronis> so we want the errors
<zyga> mmm,
<zyga> it's not clear that one will fail while the other will not
<pedronis> ?
<zyga> I mean, from reading the documentation and function name
<zyga> it's error prone
<pedronis> they both fail
<pedronis> you didn't make not fail
<zyga> yes but one returns different errors than the other
<zyga> sorry, I said that in a confusing way
<zyga> the code is almost the same but the error values are not
<pedronis> one is about the installed snaps
<pedronis> maybe the error name, comment is not quite right
<pedronis> ReadInfo reads the snap information for the *installed* snap ...  that's always been documented like that
<pedronis> but yes, BrokenSnapError doc is a bit insufficient
<pedronis> it seems snap/info.go needs a general doc review,  some comments are out of date
<zyga> yes, I agree
<pedronis> like IÂ see a mention of File that doesn't exist anymore
<mborzecki> i think i'm doing the whole system-nickname-core wrong, i did a change to replace core with system in data returned by /v2/interfaces endpoint, but that feels wrong, if one is using this api endpoint then the data returned would change, but there would no change in api version
<pedronis> yes, not sure we can do that
<pedronis> not sure if a lot of external parties are using interfaces though
<pedronis> on the other hand
<mborzecki> instead should probably only accept system as nickname for core, and do the right thing as if 'core' was passed
<pedronis> we are doing the new connections work
<pedronis> and snap interfaces is going away
<pedronis> so maybe we need to do it only in the new stuff
<pedronis> zyga: IÂ mean a not to look at snap/info.go docs at some point
<pedronis> *a note
<zyga> ack
<pstolowski> pedronis: hey, quick question wrt to what Gustavo asked in the interface hooks review about deny-auto-connection and deny-connection; i see them consistently used in majority of base decls, so I presume they are not denied by default?
<mborzecki> pedronis: so maybe this, on POST to /v2/interfaces dealias system to core, but when you just query the interfaces, at the client side, present core as system by default, unless someone asked for 'core' specifically
<pedronis> pstolowski: the deny-connection bit is a bit strange,  given is a test interface we probably don't want auto-connect though
<pedronis> pstolowski: it's a bit unclear  though given it's a test interface
<mborzecki> so the output of the endpoints does not change, it still accepts the 'nickname', and a new client can act accordingly to user's query
<pedronis> pstolowski: basically IÂ don't think you want the deny-connection bit
<pedronis> pstolowski: it's saying that it cannot be connect on core, but can be connected on classic
<pstolowski> pedronis: right. indeed, it doesn't make sense to deny that
<zyga> I have to go to school, sorry, daughter is trouble today
<Chipaca> must be the weather
<mborzecki> damn, when running daemon unit tests, 3 tests fail, if I run them separately, they all pass, something not cleaned up in teardown
<Chipaca> _unit_ tests
<Chipaca> wat
<Chipaca> (granted the daemon unit tests are the worst)
<mborzecki> Chipaca: daemon/api, exactly what i'm working on right now
<Chipaca> mborzecki: i'm so sorry
<mborzecki> it all started when i started mocking 'core' snap in one of the tests, new it's special but didn't expect this
<mborzecki> s/new/knew/
<zyga> re
<mborzecki> shouldn't https://github.com/snapcore/snapd/blob/master/daemon/api_test.go#L3498 be cleaned up?
<pedronis> there's no way atm, it could
<mborzecki> pedronis: added this https://paste.ubuntu.com/p/9z58cTd53S/ and a corresponding call in api tests, so far it's not failing anymore
 * Chipaca goes afk
 * Chipaca returns
<pstolowski> niemeyer: i've addressed your comments to interface hooks, with one open question; thanks for the review!
<zyga> gah
<zyga> darn
<zyga> I need to think
<zyga> this apparmor rule issue is terrible
<pstolowski> zyga: which one? the xmas tree?
<zyga> yes
<pstolowski> oh
 * pstolowski is going for a walk
<mborzecki> zyga: see what you did :)
<zyga> I would love to go for a walk myself
<zyga> but I have to crack this issue
<mborzecki> poor chap couldn't stand being reminded of that rule
<mup> PR snapd#5076 closed: spread: auto accept key changes when calling dnf makecache <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5076>
 * zyga -> break for pen&paper debugging
<zyga> chop tree test https://www.irccloud.com/pastebin/t1Vah68j/
<zyga> jdstrand: hey
<zyga> Chipaca, mborzecki: can you please review https://github.com/snapcore/snapd/pull/3963
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<zyga> it's got two +1s
<zyga> but is important enough for extra reviews
<Chipaca> zyga: lunch now, meeting after, then standup, then school run, so â¦ after that?
<zyga> sure
<Chipaca> k
<ogra_> zyga, ogra@acheron:~$ snap run snapcraft-forum
<ogra_> cannot change profile for the next exec call: No such file or directory
<ogra_> snap-update-ns failed with code 1: No such file or directory
<ogra_> ogra@acheron:~$ snapcraft-forum
<ogra_> cannot change profile for the next exec call: No such file or directory
<ogra_> snap-update-ns failed with code 1: No such file or directory
<ogra_> ogra@acheron:~$
<zyga> ogra_: hey, what is snap version?
<ogra_> (after a reboot on 16.04 ... whats going on there (other snaps seem to start though)
<zyga> ls /var/lib/snapd/apparmor/profiles
<ogra_> ogra@acheron:~$ snap version
<ogra_> snap    2.32.3
<ogra_> snapd   2.32.3
<ogra_> series  16
<ogra_> ubuntu  16.04
<ogra_> kernel  4.13.0-38-generic
<zyga> sudo cat /sys/kernel/security/apparmor/profiles
<zyga> update to .5 (beta) and see if this is fixing it
<ogra_> https://paste.ubuntu.com/p/fTz2QFW3wZ/
<ogra_> ... refreshing ...
<zyga> ogra_: what is snapcraft-forum
<zyga> and why don't you have profiles for it
<zyga> is it active?
<zyga> is it mounted?
<ogra_> its a sideloaded electron snap for the forum
<ogra_> nothing fancy about it beyond that
<zyga> mmm
<zyga> you don't have any profiles for it
<zyga> is it "snap try"
<ogra_> (same snap runs fine on my desktop that i also rebooted today with latest updates)
<ogra_> no, its just a sideloaded snap .. hasnt changed for 4-5 months, used daily
<zyga> is it in /var/lib/snapd/snaps
<ogra_> zyga, beta fxes it
<zyga> and is it listed in 'snap list'?
<ogra_> indeed it is
<zyga> hmm
<zyga> reboot a few times to see if this happens
<ogra_> and it starts fine now with beta
<zyga> I don't know why we'd _not_ show that snap
<zyga> yeah because beta update regenerated profiles
<zyga> but why was it missing?
<zyga> can you show your snap changes?
<popey> om26er: just fyi, sublime-text grew from zero users to over a thousand pretty much overnight
<ogra_> i really cant reboot a few times now (thats always some effort to bring my scripts back up etc ... and i'm busy implementing fulld-disk-encryption)
<zyga> popey: wow :D
<popey> om26er: dunno if you did any marketing, but we didn't
<zyga> that's pretty neat
<ogra_> ogra@acheron:~$ snap changes
<ogra_> ID   Status  Spawn                 Ready                 Summary
<ogra_> 201  Done    2018-04-19T12:48:57Z  2018-04-19T12:49:01Z  Auto-refresh snap "snapcraft"
<ogra_> 202  Done    2018-04-19T18:13:56Z  2018-04-19T18:14:00Z  Auto-refresh snap "snapcraft"
<ogra_> 203  Done    2018-04-20T09:28:56Z  2018-04-20T09:28:59Z  Auto-refresh snap "snapcraft"
<ogra_> 204  Done    2018-04-20T11:18:23Z  2018-04-20T11:18:55Z  Refresh "core" snap from "beta" channel
<popey> i expect it'll be 2K next week.
<zyga> ogra_: intersting
<ogra_> nothing interesting in snap changes either
<zyga> ogra_: I believe this is something serious
<zyga> ogra_: sergiusens also reported this happening to another snap
<popey> eclipse jumped about the same rate too!
<zyga> on reboot we randomly don't see a given snap
<ogra_> that sounds bad indeed
<zyga> popey: share this with sublime-text upstream
<popey> oh we will :D
<zyga> ogra_: this is artful?
<popey> once it plateaus a little
<zyga> ah xenial
<zyga> same As my test machine
<ogra_> yeah, see snap version above :)
<zyga> I tried to reproduce it but no luck
<zyga> yeah :/
<ogra_> using hwe kernel here
<zyga> popey: did you see my classic analyser?
<ogra_> (non-hwe on my desktop FWIW)
<popey> i did, but didn't use it - i wasn't the one having problems
<zyga> popey: sure but it's not the point
<zyga> you can run sublime-text
<zyga> and run that script on the process
<zyga> to see which things are packaged incorrectly
<zyga> even if it works for $person
<popey> on, interesting
<zyga> it doesn't mean it's correct
<zyga> this let's you see what is wrong
<zyga> try it :)
<zyga> I want to snap that helper
<zyga> but I need to convince jdstrand
<zyga> or make it classically confined
<zyga> but I'd rather just make interfaces powerful enough
<ogra_> zyga, wow ... just looking at syslog ... there are other oddities ... see the hexchat messages https://paste.ubuntu.com/p/qQpCZ8fgRh/
<zyga> Apr 20 13:18:44 acheron snapd[4918]: 2018/04/20 13:18:44.109729 helpers.go:217: cannot connect plug "gsettings"
<zyga>  from snap "hexchat", no such plug
<mup> PR #20: Feature/snapfs cleanup kernel assets <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/20>
<ogra_> yeah
<zyga> hmm, that happened just now
<zyga> so
<zyga> ogra_: "snap interfaces hex chat"
<ogra_> snap interfaces shows them all connected fine
<zyga> (without the space, sorry, spellchecker does this)
<zyga> can you restart snapd and see if something similar happens (to any snap)
<ogra_> oh
<zyga> oh?
<ogra_> :desktop-legacy  hexchat,shattered-pixel-dungeon,telegram-desktop,vlc
<ogra_> :network         gping,hexchat,lxd,packageproxy,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,usbtop,vlc,wine2
<ogra_> :network-bind    hexchat,mjpg-streamer,packageproxy,shattered-pixel-dungeon,telegram-desktop,usbtop,vlc,wine2
<ogra_> :unity7          hexchat,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,vlc,wine2
<ogra_> :x11             hexchat,shattered-pixel-dungeon,snapcraft-forum,vlc,wine2
<ogra_> hexchat:hexchat  -
<ogra_> no home
<zyga> cat the hex chat's snap.yaml please
<ogra_> (or pulse)
<ogra_> its the one from the store ... one sec
<zyga> maybe that's harmless now
<zyga> maybe it just dropped those plugs
<zyga> we have some code in 2.33 that will remove stale connections
<ogra_> http://paste.ubuntu.com/p/VGNzX4hZRJ/
<ogra_> interesting
<ogra_> why does it look for pulse/home/gsettings if they are not defined
<zyga> ogra_: because it remembered those were connected
<zyga> that's fine, that's harmless
<ogra_> ok
<zyga> ok, if you see this issue again (not having apparmor profile) do let me know
<ogra_> (not sure why they would be connected and now not anymre though)
<ogra_> will do
<zyga> well, they were connected at some point in time
<zyga> so we remember that
<zyga> and we never forget until you remove the snap :)
<zyga> (but don't do that, that's silly)
<zyga> as snap refreshes the set of interfaces can change
<ogra_> sure, i get that ... but that snap hasnt changed in a month
<ogra_> ogra@acheron:~$ snap info hexchat|grep refresh
<ogra_> refreshed: 2018-03-19T06:50:55+01:00
<sergiusens> ogra_, zyga, popey:  yes, I logged a bug on snapd for the profiles magically going away
<ogra_> will it try connecting every reboot even though it should know the interfaces are gone after the first attempt ?
<sergiusens> ogra_: https://bugs.launchpad.net/snapd/+bug/1764998
<mup> Bug #1764998: profiles making a run for it <amd64> <apport-bug> <bionic> <snapd:Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1764998>
<ogra_> (i know it is harmless but the probing surely wastes boot time every boot ... )
<sergiusens> zyga and no, I am not going to beta, last time I did that I had to reinstall my entire system
<ogra_> well, but that at least guarantees yu have a clean system every now and then :P
<mup> PR snapd#5077 opened: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5077>
<ogra_> sergiusens, beta solved it for me
<zyga> ogra_: yes but it takes microseconds to check they are missing
<zyga> sergiusens: !
<sergiusens> ogra_: please add it to the bug :-P
<pstolowski> zyga: the code that removes stale connections hasn't landed yet
<zyga> sergiusens: what happened?
<sergiusens> but no, no beta for me
<sergiusens> zyga: there was a bug in core, my snaps stopped working and I had to spend the day reinstalling
<pedronis> atm beta == candidate
<pedronis> and candidate wil becomed stable ~Monday
<zyga> could you not switch back to stable?
<sergiusens> zyga: no, there was a bug where channel switching was broken in beta ;-)
<pedronis> zyga: candidate and beta are the same right now
<zyga> sergiusens: switch, refresh and revert well all broken?
<zyga> pedronis: ack
<sergiusens> zyga: refresh was, and yes, there was no way to move back, I troubleshooted with mvo at that time
<jdstrand> pstolowski (cc pedronis): interfaces/policy/basedeclaration.go describes the thought behind stuff
<jdstrand> pstolowski (cc pedronis): that states that deny-connection should be used with app-provided slots. grepping for deny-connection, I don't see anything that is *only* an implicit core slot that has deny-connection
<pedronis> jdstrand: this the dummy test interface though
<pedronis> it's a bit unclear what rules should applay to it
<pedronis> it doesn't open anything
<jdstrand> pstolowski: the one where it is both core and app, we should have:
<jdstrand> deny-connection:
<jdstrand>   on-classic: false
<jdstrand> pedronis: what is the 'dummy test interface'?
 * jdstrand is lacking context
<pedronis> jdstrand: it's in a big PR  about interface hooks that you should probably read
<pedronis> (tough it's big)
<jdstrand> oh that one
<jdstrand> I've let zyga know-- I am working on a couple of things with critical priority for Berlin so not able to get to that yet
<jdstrand> with luck, next week
<zyga> good luck jdstrand
<pstolowski> jdstrand: yep. that's the interface i introduced strictly for testing purposes as it was the only way to test that interface hooks work end-to-end; it doesn't do anything
<jdstrand> pstolowski: can you describe what the interface does? it sounds like like it literally does nothing. if it does nothing, there is no reason for it to have anything beyond:
<jdstrand> allow-installation:
<jdstrand>   slot-snap-type:
<jdstrand>     -core
<jdstrand> pstolowski: (in terms of security)
<popey> jdstrand: i did as requested with signal-desktop last night, happy to follow up today. https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/13
<pedronis> jdstrand: it attached to some test apps though, not core
<jdstrand> pstolowski: ie, let connect and auto-connect. if you need it to do something else for test purposes, just do what you want
<jdstrand> ok
<jdstrand> -app
<pedronis> but yes, it does notighin
<jdstrand> - core
<pedronis> and probably shouldn't auto-connect, mostly to avoud confusion, unless some tests really need that
<jdstrand> pstolowski: is this supposed to mimic how other interfaces act, or it just needs something in the base decl and you're wondering what?
<pedronis> jdstrand: notice  that the review request, or at least looking at it, was not particularly for this, is that that PR changes a bit how policy is enforced
<jdstrand> pstolowski: (since it does nothing, I would argue that you can put anything you wnat in the base decl)
<pedronis> jdstrand: because it now accounts for dynamic intrface attrs coming from hooks
<pstolowski> jdstrand: it's an interface that has a few attributes both on slot and plug side; some are defined in snap's yaml and some have values dynamically created at runtime by slot/plug hooks. the slot of "dummy" interface is offered by test snap
<jdstrand> popey: that is disappointing
<jdstrand> pstolowski: ok, so it is meant to *only* be provided by the test snap, *not* ever core?
<pstolowski> jdstrand: correct
<jdstrand> pstolowski: I suggest:
<jdstrand> dummy:
<jdstrand>   allow-installation:
<jdstrand>     slot-snap-type:
<jdstrand>     - app
<jdstrand>   deny-connection: true
<jdstrand> then add a snap decl for your test snap
<pedronis> pstolowski: is the snap local or from the store?
<jdstrand> this would mimic what we typically would do. if you don't care about the the snap decl integration, you could drop the deny-connection bit, but add a comment as to why
<jdstrand> pstolowski: also, I'm guessing this is for 2.33 and *not* 2.32.something?
<pedronis> jdstrand: correct, this is 2.33 material
<jdstrand> ok
<cachio> niemeyer, today I'll be 5 minutes late in the standup
<jdstrand> I will have it at the top of my list to review after the two critical things I'm working on
<jdstrand> hopefully that translates to next week, though popey's url means possibly not
<popey> jdstrand: would it help if I gave you the script / setup I'm using to build signal?
<popey> so you don't block on me
<jdstrand> popey: I'm probably going to need to have the full tree to build the thing to see what is happening. I mean, I can resquash, resquash, resquash, ... ad nauseum snaps big snaps and it works fine
<popey> jdstrand: well, I clone, patch, build. But I automated it with a litte script in lxd
<jdstrand> popey: it seems they are maybe doing something weird or there is a disparity in the squashfs-tools inside and outside the container
<zyga> popey: is signal classic?
<popey> no
<jdstrand> popey: yes please. if it is public, can you just put that into the forum topic?
<popey> ok
<popey> lemme dist-upgrade my container, try and build again and see
<pstolowski> pedronis: the snap is local
<jdstrand> popey: oh, yes, please. we did have to patch squashfs-tools for symlinks, but that was *ages* ago
<jdstrand> it would be awesome if that is all it was...
<popey> only had a few updates, including snapcraft 2.41, but not squashfs-tools
<popey> trying anyway
<jdstrand> if you have the 2.41 deb in there, then probably not it
<pstolowski> jdstrand: thanks for the suggestions
<jdstrand> pstolowski: you're welcome. sorry I can't review sonner, but I'll get to it
<jdstrand> popey: thanks for retesting btw
<popey> np
<popey> I want this fixed as much as you :)
<jdstrand> popey: I'm not sure that's possible, but thanks! ;P
<popey> haha
<jdstrand> zyga: you keep referring to snapping a helper and convincing me. is this the environ access?
<pstolowski> jdstrand: np and thanks
<zyga> popey: would it be possible to do one-time upload of dev version of s-t to edge?
<popey> zyga: yeah, I'll take a look.
<zyga> jdstrand: it was ...
<zyga> jdstrand: (more than that)
<jdstrand> both of the things
<jdstrand> let me look, I have that somewhere
<jdstrand> basically, I didn't care for it
<zyga> classic-snap-analyzer https://www.irccloud.com/pastebin/Sk6YiLvk/
<zyga> I wanted to get environment to check if SNAP_NAME is set (to be smart about finding snap processes)
<zyga> I wanted proc/pid/maps to see what is loaded
<jdstrand> /proc/pid/maps and /proc/pid/environ
<zyga> I think there are some misc files I could use but that's bare minimum
<zyga> btw, did you know you can poll on /proc/pid/mounts? :)
<zyga> it's cool, I didn't know
<popey> :( failed again jdstrand
<zyga> jdstrand: also consider /proc/pid/map_files/
<zyga> it's very similar to maps but laid out differnetly
<zyga> *differently
<jdstrand> zyga: system-observe is wrong for both of those
<zyga> jdstrand: maybe process-control? (or process-observe?)
<zyga> (process-observe would be a new interface)
<jdstrand> zyga: process-control is pretty specific about what it can do, and that does not include reading a process memory
<zyga> note that this doesn't leak memory, just information about memory maps
<jdstrand> so, yes, I think it would be a new interfacec, possible process-observe
<zyga> jdstrand: if you agree I can make that happen
<jdstrand> zyga: I know, but it is info that I'm not excited about snaps having about other snaps
<zyga> sure
<jdstrand> so it must be manually connected
<zyga> it's specifically designed for doing that though
<zyga> I mean, on this specific snap I would seek auto-connection
<zyga> as the purpose is to improve the quality of snaps published by other teams
<jdstrand> you could also simply make it a classic snap for the time being
<zyga> yes but that feels like cheating :)
<zyga> I want less classic
<zyga> and better classic if needed
<jdstrand> classic is ultimately about timing
<jdstrand> we can roadmap something, but that doesn't mean it is prioritized to instantly appear
<zyga> that's true
<jdstrand> ie, if you need this to help people *today*, make it classic, then we can see to improve
<mup> PR snapd#5078 opened: interfaces/builtin, daemon: cleanup mocked builtin interfaces in daemon tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5078>
<zyga> yeah, that's a good point
<jdstrand> and take classic away from the snap later
<zyga> yep
<zyga> I'll do that
<zyga> it will help everyone now
<jdstrand> zyga: feel free to do a PR for process-observe. I'm going to want to think about it though, which gets to 'classic today' since, aforementioned critical work
<zyga> sure
<jdstrand> zyga: was there something else from backscroll you needed to talk about? something about apparmor profiles disappearing?
<zyga> jdstrand: no, that's it for today
<jdstrand> \o/
<zyga> we have two reports of that happening but both on 2.32.3
<jdstrand> :)
<zyga> and no way to reproduce now
<zyga> so ... good :)
<jdstrand> not that I don't enjoy talking to you :)
<zyga> the feeling is mutual :)
<zyga> I'm going to publish this snap
<zyga> and get back to apparmor
<popey> jdstrand: added build instructions to the forum
<jdstrand> zyga: the only thing I was going to add was there are a) system-key changes (which should affect all profiles) and b) there is that 'broken' issue
<zyga> ack
<jdstrand> zyga: if it were related to 'a', that sounds like a race condition
<jdstrand> but something with ensure dir state...
<jdstrand> you've surely thought of that though
<jdstrand> ok, moving on
<jdstrand> popey: thanks!
<jdstrand> popey: I'm probably not going to look at that today since electron snaps are not blocked currently (we disabled resquash), but that is one of the two critical priority items
<jdstrand> so, definitely next week
<popey> ok, no worries.
<jdstrand> zyga: oh, and sun profiles
<jdstrand> that's the other one. but again, you are obviously thinking about that
<zyga> in the case ogra had the snap had no profiles present
<zyga> none
<zyga> and it is not easy to reproduce, no ideas yet
 * kalikiana lunch
<jdstrand> zyga: that suggests it maybe misdetected devmode. I wonder what journalctl has to say about that...
<zyga> ogra_: can you look at the log of snapd.service from this boot
<zyga> (all restarts but the whole boot please)
<ogra_> zyga, https://paste.ubuntu.com/p/QVp4vpKg44/
<zyga> is that since boot?
<ogra_> yes
<ogra_> i dont reboot that often (perhaps once a month or so)
<ogra_> no reboots since we started talking ...
<zyga> jdstrand: I sent classic-snap-analyzer to the store
<zyga> jdstrand: https://forum.snapcraft.io/t/request-for-classic-confinement-classic-snap-analyzer/5057
<zyga> https://www.irccloud.com/pastebin/TazWgkcg/
<zyga> Chipaca: hey, standup?
<Chipaca> zyga: meeting
<zyga> ack, thanks
<Chipaca> â¦ and now I'm being called to the school
<jdstrand> zyga: ack, approved. you still need to release to a channel
<zyga> thanks
<pstolowski> kyrofa: hey! can you help answer the question in the comments there https://github.com/wekan/wekan-snap/issues/45#issuecomment-383090374 ?
<zyga> roadmr: is there a way to set "package title" from snap.yaml?
<roadmr> zyga: mmm....
<roadmr> what's even the title? is it the summary?
<zyga> no
<zyga> can you look at the snap "classic-snap-analyzer" in the store
<zyga> It has a title now, "Classic snap analyser"
<zyga> (z)
<roadmr> oh
<zyga> which is separate from summary and description
<zyga> I didn't know that before
<roadmr> zyga: I didn't either! ooh
<zyga> magic :D
<zyga> sergiusens: ^
<zyga> niemeyer: ^ :) (what is a package title?)
<roadmr> zyga: got the URL? I can't seem to find it :(
<roadmr> zyga: oh nm found it
<roadmr> zyga: don't you have an "Edit name" control next to that name?
<zyga> yes, I edited the name already
<roadmr> zyga: it's the "name", not the "package_name" attribute
<zyga> well
<zyga> the title
<roadmr> right internally I see it as "name"
<roadmr> its description is "application name"
<zyga> roadmr: right, I wonder how this maps to snapcraft concepts
<zyga> it is different from snap name
<zyga> which is immutable there
<roadmr> yeah
<zyga> popey: https://forum.snapcraft.io/t/call-for-testing-and-usage-classic-snap-analyzer/5058
<zyga> sergiusens: ^ FYI :)
<popey> zyga: that post needs more words, to explain whats good or bad about the output :)
<zyga> popey: suggestions welcome, can you tell me what you mean?
<popey> at the moment it reads like "here's a thing that tells you something I know about but you don't"
<popey> why should I care? (as a snap maker)
<zyga> aha
<zyga> indeed
<zyga> well :)
<zyga> popey: I updated the description
<zyga> I can make the post into a wiki if you want to wordsmith it more
<om26er> @popey: regarding sublime text install count, I only tweeted about it, thought didnt see any to that. Probably some blog picked that up.
<om26er> *though
<oSoMoN> jdstrand, hey, does this denial look any familiar to you? https://forum.snapcraft.io/t/libreoffice-6-0-3-not-so-stable/5032/16
<kalikiana> re
<jdstrand> oSoMoN: https://forum.snapcraft.io/t/libreoffice-6-0-3-not-so-stable/5032/17
<oSoMoN> jdstrand, thanks!
<oSoMoN> that makes sense, libreoffice wants to create a lock file next to the saved file, and the home interface doesn't allow that in $HOME (but it does in subdirectories)
<jdstrand> oSoMoN: yeah. makes sense, but this sounds like an icky bug for you :\
<jdstrand> I mean, you can patch it of course, but bummer
<oSoMoN> yeah
<oSoMoN> well at least understanding the issue and filing a bug report to track it is a good start
<oSoMoN> and I didn't know of aa-decode, so IÂ learnt something new today, that's a good day :)
<niemeyer> zyga, roadmr: The title is a more unrestricted snap name
<niemeyer> May be non-unique, may have spaces, typically capitalized
<niemeyer> Foo Bar
<roadmr> interesting :)
<niemeyer> "title" is the field in snap.yaml
<niemeyer> It was incorrectly used by gnome-software for some time as if it was a summary, which created some unfortunate data corruption
<jdstrand> oSoMoN: :)
<zyga> hmm
<mup> PR snapd#4509 closed: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<zyga> classic-snap-analyzer has a license specified both in the store and in the yaml
<zyga> and yet it shows up as "unknown" in gnome-software on 17.01
<zyga> and shows no icon on bionic
<zyga> hmm
<zyga> on the other side bionic shows the license correctly
<mborzecki> zyga: isn't that handled by snapd glib wrapper?
<zyga> it is
<zyga> it's okay now, maybe the data was stale for a while?
<zyga> try it :)
<zyga> the screenshot is very blurry
<zyga> not sure what's wrong there
<zyga> but I found a bug :-)
<zyga> going to the channel I can see buttons to switch to candidate, beta or edge
<zyga> but this snap only has stable
<zyga> so ...
<kyrofa> pstolowski, done, thank you for reaching out :)
<zyga> popey: around?
<popey> hello
<zyga> popey: can you refresh classic-snap-analyzer to beta
<zyga> and try the interactive mode
<zyga> just pin it
<zyga> run it then click on a window of any snap
<zyga> it doesn't work on wayland I think
<zyga> but works on X
<popey> like any sane person, I don't use wayland
<zyga> or it may
<zyga> but I need to handle some errors when screen grab fails
<zyga> :-)
<popey> Selected window does not belong to a snap application
<popey> this is a lie
<zyga> oh
<zyga> what did you try it on?
<zyga> I'm getting the pid of the process
<popey> slack
<zyga> then look at the environment
<zyga> checking
<zyga> oh, indeed :D
<zyga> tricky bastard ;)
<zyga> thanks, I will keep looking
<popey> :D
<zyga> but there's progress
<zyga> woah
<zyga> it seems that slack is erasing its environment block
<zyga> it's all zeros
<zyga> that's interesting
<zyga> well, I can test for that
<zyga> this is why I published to beta :)
<pstolowski> kyrofa: thank _you_!
<popey> zyga: might want to think about that wording. indicating "breakage" when someone is using everything as designed isn't a good PR message
<zyga> popey: as designed?
<popey> the developer of the snap is using tools we made to build a snap. to imply breakage when using our tools isn't a good message
<zyga> but it's true
<zyga> our tools are imperfect
<zyga> our users suffer
<popey> Fix them
<popey> Don't tell users *they* did something wrong when *our* tools are broken.
<popey> Its completely wrong.
<zyga> I don't think it can ever be perfect, it's a tough game, I'm not making the tools; I just made _a_ tool that allows anyone to inspect the problem
<zyga> it will always be a catch-up game
<popey> I'm not going to spend the afternoon arguing with you about the wording in an expert tool, but I strongly recommend you think more about the perception you're giving people _we_ speak to on a daily basis.
<zyga> popey: ok, what would you suggest I say instead?
<zyga> is this about the tone or the message in general?
<popey> Firstly, who is the target audience, and what's the goal of the application?
<popey> What message do you want to convey? "Hey, we can help you improve stability / reliability of your application with our cool utility"
<popey> not "hey, our shit is broken, use this tool to find out how"
<zyga> the target audience is an author of a classically confined snap
<zyga> the goal is to allow detecting when the app only works because it uses a host library without anyone noticing because said library is on the developer's machine
<popey> Tested with the code-insiders snap and it worked
<popey> spat out a list of libraries.
<zyga> so again, I'm happy to reword it to make that goal clear
<popey> IMO it needs to clearly describe the problem, or potential problem, and outline how it can be resolved.
<popey> rather than hand-wavy "its broken dude"
<zyga> ack, I will try to rewrite the text around the app
<popey> <3
<mcphail> I'm being offered a snapd update from 2.29.4.2 to 2.32.3.2. Is this one which will fix the issue where I have to add process-control to some of my snaps to get sound working? It'll be cool if I can promote one of my games to stable, as it is waiting on that fix
<zyga> popey: refresh please :)
<zyga> mcphail: try it, I think that's the one
<zyga> mcphail: we switched off SIGKILL on seccomp
<zyga> mcphail: also try candidate which has more bug fixes (2.32.5) and will be in stable next week
<zyga> popey: check if the reworded message is more useful
<popey> mcphail: yes, 2.32* is the good snapd we have all been lusting for :)
<mcphail> Brilliant! Cheers chaps
<popey> zyga: hah, i get a different list of libraries now. much better text too, thank you!
<zyga> yeah, I fixed some issues too
<zyga> plus, it's really variable
<popey> maybe put the forum link and docs before you click on a window?
<popey> Because its a bit odd to be told how the app works after you have used it :)
<zyga> but if you suspect something is super broken  please report that
<zyga> ah
<zyga> sure
<zyga> good point :)
<zyga> popey: refresh :)
<zyga> provide feedback on the forum, I need to break and hop on a bike before the sun sets
<zyga> popey: if you are happy with the output I can promote to stable
<popey> refreshing
<popey> sometimes snap refresh hangs for me for nearly a minute
<popey> doesn't produce any output
<popey> zyga: that's much better, thanks.
<Son_Goku> zyga, can you look into this? https://bugzilla.redhat.com/show_bug.cgi?id=1570076
<popey> i am installing fedora 28 right now to reproduce
<Son_Goku> okay, cool, thanks popey
<Son_Goku> I'm still working, so I can't do anything right now :(
<zyga> I need to break now, I've been here all day
<zyga> but yes, I will definitely look into this
<mcphail> \o/ sound is working! Many thanks
<popey> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1570076 - i left a comment - i can't reproduce it
<zyga> popey: on a bije
<zyga> Bike
<popey> :)
 * cachio afk
<mup> Issue snapcraft#2093 opened: manifest.yaml does not indicate the release the snap was built on <Created by jdstrand> <https://github.com/snapcore/snapcraft/issue/2093>
<jdstrand> ratliff: fyi ^ bug. I can assume xenial and most things will be ok, but we'll need to adjust when that is fixed
<sergiusens> jdstrand: it seems that if you use refresh-mode or stop-mode, it needs to come with a daemon entry for the app
<sergiusens> not sure you are verifying that in the review tools
<jdstrand> sergiusens: yes, and I am
<jdstrand> sergiusens: thanks for mentioning it
<sergiusens> jdstrand: great then!
<seb128> popey, on that fedora/snap bug you might want to ask for the XDG_DATA_DIRS value and if they use xorg/wayland session, also the .desktop are in /var/lib/snapd/desktop so worth asking the content of that dir
<seb128> I would comment but it requires an account and I don't have one
<mup> PR snapcraft#2094 opened: storeapi: better handle network errors and retries <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2094>
<popey> seb128: yeah, i checked the XDG_DATA_DIRS myself
<popey> oh, they need to check, i see :)
<om26er> whats the difference between ubuntu-core/current and /stable ?
<om26er> http://cdimage.ubuntu.com/ubuntu-core/16/current/
<om26er> and /stable
<om26er> also, will there be a UbuntuCore 18, if so how will it be different from a fully update Core16 ?
 * cachio EOW
<mup> PR snapcraft#2092 closed: schema: allow refresh-mode and stop-mode <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2092>
#snappy 2018-04-21
<popey> diddledan: just noticed corebird 1.7.4 (latest) is in edge. it works here. no reason not to push to stable, right?
<diddledan> popey: I think we're good for corebird, yes
<diddledan> RELEASE THE HOUNDS ^H^H^H ALL THE THINGS
<popey> Aweomesauce
<popey> thanks
<popey> done
<popey> diddledan: i also closed beta and candidate channels to force people to stable, and I closed all channels on armhf because I doubt we have tested it there :)
<ogra_> cd -
<ogra_> booo ... focus !
<diddledan> \o/
<nsg> Hello, I have snap with broken fonts (reported on Debian and Solus, works on Ubuntu). I did not realize that the snap required some specific font when I built it, and I'm a Ubuntu user.
<nsg> 1) What is the correct way to avoid this for the future? Test it w/o unity7 plug? Any better way?
<nsg> 2) Is there a way to disable the inclusion of the hosts fonts? The snap is not en editor (it's a game) ... or is this a stupid idea for international users?
<nsg> It's not my application so I'm not even sure what font I need to add, but that's the next step to figure out :)
<nsg> A totally separate question (but the same snap), I did my last release to stable at 26 Mar, works (except the font problem). The build services has since then updated edge several times, and since 3 Apr my application segfaults with a nice memory corruption... not my app so a little hard to debug, has anything relevant changed in snapcraft since then?
<mup> Bug #1765979 opened: snap applications icons missing in launcher wayland <wayland> <Snappy:New> <https://launchpad.net/bugs/1765979>
#snappy 2018-04-22
<mup> Bug #1766079 opened: ripgrep installed via snap fail to work in /lib/systemd/system folder <Snappy:New> <https://launchpad.net/bugs/1766079>
<cjwatson> nsg: I'm far from an expert (I help operate the build service, but snapcraft isn't really my thing), but one thing that's often helpful in general is to grab the build log of the last version known to work and diff it against the first version known not to work
<cjwatson> nsg: Let me know if you need help with tracking down the files
<nsg> Yup, I grabbed the build logs last weekend. I have diffed them, both manually and programmatically but no luck. Only thing I noticed is that the output from snapcraft has changed a little, so I guess a new version was released between these builds.
<nsg> snapcraft_2.39.3+really2.35_all.deb vs. snapcraft_2.40_all.deb
<nsg> But it's also possible that it has nothing to do with snapcraft, it's related to a upstream dep. But the thing is, all the versions from the build logs looks the same.
<nsg> The error I'm getting when I launch the snapped application is "malloc(): memory corruption: 0x00000000026afe30" ... lovely error. Feels like I'm dynamic linked the incorrect libs? Then, I'm not that experienced to debug C/C++ code :)
<nsg> The annoying thing is, I have change 0 lines of code. It broke it self :\
<nsg> I wonder if the "Improved elf mangling" feature does something amazing ... "This functionality is triggered when the build environment is newer than a given base (experimental)" I'm on 17.10 so...."
<nsg> (yes I do lxd based builds)
<nsg> But that would not explain why the build services creates the same broken packages :)
<ogra_> nsg, perhaps related to https://forum.snapcraft.io/t/patchelf-broke-my-binary/4928
<nsg> oh, good find. I will test with "build-attributes: [no-patchelf]"
<nsg> and while I wait for that, I will create a 16.04 VM for a reference build :)
<ogra_> you said above yu already use lxd ... so just use "snapcraft cleanbuild" that should automatically build in an lxd container
<nsg> yes, but, I'm not sure if that's identical with a "real" 16.04 install ... I'm a little out of ideas here to test (the cleanbuld is already running in the background) :)
<nsg> I have also have a lot of problems with "SNAPCRAFT_CONTAINER_BUILDS=1" builds, never works the 2nd time, not sure why, and a cleanbuld takes like a hour. So a VM will be useful for me anyway.
<thresh> Ð° ÐºÑÐ´Ð° wayland-egl Ð´ÐµÐ»ÑÑ Ð¸Ð· Ð¿Ð¾ÑÑÐ¾Ð²?
<matlock> I am trying to build my first snap from a github project, here is the snap file https://github.com/sirredbeard/FeedReader/blob/master/snap/snapcraft.yaml
<matlock> I can't use the cmake plugin in snapcraft because it breaks under nexted cmake files
<matlock> so I tried using a build script to call cmake, make, and make install but none of the built libraries and binaries come over into staging or prime, even though other parts built by autotools plugin do
<matlock> the github project also has meson build features, so I tried using snapcraft's meson plugin for a yaml here
<matlock> https://github.com/sirredbeard/FeedReader/blob/master/snap/snapcraft-meson-version.yaml
<matlock> but it fails with gcc, glibc, and zlib issues
<matlock> can anyone point me in the right direction? thank you!
<matlock> I also have filed a bug with snapcraft here https://bugs.launchpad.net/snapcraft/+bug/1766101
<mup> Bug #1766101: Snapcraft not handling cmake nested builds <Snapcraft:New> <https://launchpad.net/bugs/1766101>
<matlock> I posted it here too I also have filed a bug with snapcraft here https://bugs.launchpad.net/snapcraft/+bug/1766101
<mup> Bug #1766101: Snapcraft not handling cmake nested builds <Snapcraft:New> <https://launchpad.net/bugs/1766101>
<matlock> I mean on the forum here https://forum.snapcraft.io/t/snapcraft-breaking-nested-cmake-not-moving-build-script-files-over-and/5084
<nsg> FYI ogra_, no-patchelf did nothing for me. I tracked it down to desktop-gtk3 and the desktop-launch script. If I launched it w/o it, it started. I did a test build with desktop-gtk2... works.
<nsg> The snap in question is somewhat old, I have learned a few things since then. I will clean it up a little and try to call desktop-launch directly (it's at the moment called by a wrapper of my own).
<nsg> I will then give desktop-gtk3 a 2nd chance, plan B, just ignore desktop-launch or use gtk2 :)
<matlock> I got some initial feedback, snapcraft still doesn't seem to be bundling one part's binaries and libraries into the snap though
<matlock> so it's really three issues (1) snapcraft breaks on nested cmake files (2) snapcraft doesn't bring over binaries/libraries when using build-override and (3) something is broken with the meson plugin for snapcraft leaving snaps asking for glibc7 and zlib; if I could solve any one of these three that would be fantastic
<matlock> if someone could look at my yaml and (1) help get the cmake nested issue sorted out (2) help get the binaries/libraries over into the snap or (3) solve the glibc and zlib dependency when building snap using meson plugin that would be a win for snaps
<matlock> thanks for your help in advance
#snappy 2019-04-15
<mborzecki> morning
<mborzecki> 60 PRs :/
<zyga> good morning
<zyga> mborzecki: thank you for the reviews
<mborzecki> zyga: morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mvo> mborzecki: good morning! what did I miss? anything interessting happend?
<mborzecki> mvo: not really, just a lot of open PRs
<mvo> mborzecki: ok, let me look at those
<mborzecki> zyga: mvo: need to go out for a while, sent a message in the forum
<zyga> ack
<zyga> hey pstolowski
<mvo> hey zyga and pstolowski
<zyga> hey mvo!
<zyga> mvo: I think today is a review day
<zyga> AFK with dog
<mvo> zyga: indeed, looking at the PRs I think you are right
<pedronis> mvo: zyga: hi, I'll also focus on reviews, at least the first part of the day
<pedronis> mvo: #6594 needs a quick look from you after the last round of changes and then can land (hopefully)
<mup> PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<pstolowski> mborzecki: hey, #6711 can land
<mup> PR #6711: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6711>
<mup> PR snapd#6711 closed: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux <SELinux> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6711>
<mup> PR snapd#6696 closed: image: simplify prefer local logic  and fixes <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6696>
<mborzecki> re
<zyga> hey mborzecki
<zyga> how are you feeling?
<zyga> brb, breakfast
<mborzecki> hm 2.38 is in fedora updates repo, i might need to update the rpm upgrade triggers in our packaging
<mborzecki> heh, and looking at how the last the last 2 merges to master failed in spread i need to :P
<pedronis> pstolowski: I did passes on various of your PRs, some can land after small tweaks and then once merged in the follow ups I can look at those
<pstolowski> pedronis: ty, yes, i'm addressing your comments
<pstolowski> pedronis: i've updated https://github.com/snapcore/snapd/pull/6660, you approved it already but please see if the change makes sense
<mup> PR #6660: cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6660>
<pedronis> pstolowski: ok, will look in a little bit
<pstolowski> pedronis: basically, i think Save had a small bug
<mborzecki> #6713 will unbreak master
<mup> PR #6713: tests/upgrade/basic: restore SELinux context of /var/cache/fontconfig <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6713>
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/6692 ? super simple and can land quickly
<mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<zyga> absolutely
<pedronis> pstolowski: looks ok, commented on something else though
<pedronis> pstolowski: sorry, fixed my comment (mistyped a couple of things in it)
<pstolowski> pedronis: ah, ok, will remove that part of the comment thx
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6692/files#r275287380 ?
<mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<mborzecki> zyga: there are some units tests for findSnapdPath, maybe i could drop those
<zyga> +1
<zyga> it just seems odd to reduce a function to a call to another while keeping it when both seem to relate to the same topic
<sil2100> Hey guys! Currently, do we update all the boot-partition contents on gadget snap refreshes?
<mvo> sil2100: we don't, this is part of the work that mborzecki  is doing for the bootloader asset refreshes
<sil2100> Ok, since I remember this being a work-item but didn't know if it actually landed
<sil2100> mvo: thanks!
<mvo> sil2100: do you need it for sometihng specific? is there anything we need to update?
<mvo> sil2100: I found the missing validations, sorry for that! will get this fixed
 * pstolowski lunch
<mup> PR snapd#6713 closed: tests/upgrade/basic, packaging/fedoar: restore SELinux context of /var/cache/fontconfig, patch pre-2.39 mount units <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6713>
<mborzecki> master should be fine now
<sil2100> mvo: no no, just was wondering because of the new grub2 in the pc core18 gadget, Steve mentioned that existing users will be 'safe' because of snap refresh not updating the contents as of yet and I was wondering if that's really the case
<sil2100> mvo: as I remembered discussions about making that happen
<sil2100> mvo: thanks! Just give me a poke once the other buggers are verified
<mvo> sil2100: thanks
 * zyga coffee
<pedronis> sil2100: notice  that even once implemented it will be opt in from the part of the gadget
<sil2100> pedronis: ok, good to knog
<sil2100> *know
 * cachio afk 
<pedronis> pstolowski: hi, when you have a little bit of time, could you double check that we have a spread test for this:  https://forum.snapcraft.io/t/how-to-disconnect-a-snap-from-internet/10901/11
<pstolowski> pedronis: sure, will do
<pedronis> thx
<thresh> so I have a coredump, and my application doesnt run if it detects being running as root (so snap run --gdb is useless), what do?
<thresh> gdb --core=core /snap/vlc/x1/usr/bin/vlc results in a useless trace (all ??)
<zyga> thresh: it's not easy I'm afraid
<zyga> thresh: what is the base your snap is using? core or core18?
<thresh> zyga, it's core18
<zyga> thresh: so you somehow have to set up gdb to look at debug symbols from ubuntu18.04 -- I don't believe this is documented or explained anywhere
<thresh> could having ubuntu 18.04 as a host OS help?
<zyga> yes but it's not required
<zyga> you need the debug symbol packages
<zyga> and you need to have a debug build of the app as well
<zyga> I think it's a big endeavour to  explain and document properly though
<thresh> might be easier to just spin up a VM that trying to do that on my debian
<zyga> you don't need a vm
<thresh> sure, I've got the idea - will try it, thx
<zyga> just debootstrap ubuntu 18.04 or get a tarball from cdimage.ubuntu.com
<mup> PR snapd#6660 closed: cmd/debug: integrate new task timings with "snap debug timings" <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6660>
<zyga> I have *not* done this myself so anything you come up with is worth sharing
<zyga> good luck!
<mborzecki> pedronis: moved selinux cleanup task to the 'done' lane
<pedronis> mborzecki: great!
<pstolowski> zyga: i'm going to review #6717 in a bit
<mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<pedronis> pstolowski: it needs another pass
<zyga> pstolowski: I think it needs a fix again
<pstolowski> thanks for tackling it
<zyga> pstolowski: look at my comment
<zyga> pstolowski: because I think pedronis was spot on, twice :)
<zyga> pstolowski: and the simplistic fix was insufficient
<pedronis> to be fair I wasn't spot on, when we tried to fix this first
<zyga> pstolowski: I will add some tests to it today, to show how it fails, then try to fix it, just working on another existing PR
<zyga> pedronis: as an extra idea, I was thinking about changing how we load yaml
<pstolowski> zyga: ah, i see the new comments, ack
<zyga> pedronis: to allow it to know about the implicit hooks before we read the yaml
<zyga> pedronis: so that we can create them and avoid the late binding complexity
<pedronis> zyga: maybe, that seems a bigger changes though
<zyga> pedronis: yes
<mborzecki> anyone up for a 2nd review of https://github.com/snapcore/snapd/pull/6688 ?
<mup> PR #6688: gadget: add validation of cross structure overlap and offset writes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6688>
<mup> PR snapd#6625 closed: tests: system disable ssh for config defaults in gadget <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6625>
<mup> PR snapcraft#2533 closed: tests: classic confinement spread tests for ant and maven  <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2533>
<zyga> mborzecki: any ideas, is ausearch failing? https://www.irccloud.com/pastebin/ohLqFsHP/
<mborzecki> zyga: can you post the debug part of the log?
<zyga> ah, indeed
<zyga> selinux denials https://www.irccloud.com/pastebin/s5RJWK6u/
<cmatsuoka> kenvandine: hello ken
<cmatsuoka> kenvandine: did you build any kde snap using the frameworks build-snap?
<cmatsuoka> kenvandine: existing material in the internet suggests it should be straightforward, but my tests were not so smooth
<kenvandine> hey cmatsuoka
<kenvandine> cmatsuoka: i haven't
<mborzecki> zyga: which PR is that?
<zyga> I think it was
<zyga> https://github.com/snapcore/snapd/pull/6714
<cmatsuoka> kenvandine: I'll check it directly with sitter or the folks in #kde-devel
<mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
<zyga> mborzecki: no, wait
<zyga> wrong branch
<mborzecki> zyga: can you check which tests ran before? it looks like /home/test/snap has incorrect type, so it either was created by the upgrade test and not cleaned up, or restorecon did not restore the permission, snapd has all the permissions to poke snappy_home_t but not user_home_t
<zyga> https://api.travis-ci.org/v3/job/520237869/log.txt from https://github.com/snapcore/snapd/pull/6673
<zyga> checking
<mup> PR #6673: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <https://github.com/snapcore/snapd/pull/6673>
<zyga> google:fedora-29-64:tests/main/interfaces-broadcom-asic-control google:fedora-29-64:tests/main/snap-connect google:fedora-29-64:tests/main/interfaces-device-buttons google:fedora-29-64:tests/main/debug-sandbox google:fedora-29-64:tests/main/confinement-classic google:fedora-29-64:tests/main/try-with-hooks google:fedora-29-64:tests/main/interfaces-calendar-service google:fedora-29-64:tests/main/refresh:strict_remote
<zyga> google:fedora-29-64:tests/main/install-errors:noreexec google:fedora-29-64:tests/main/snapctl-services google:fedora-29-64:tests/main/nfs-support google:fedora-29-64:tests/main/snap-debug-get-base-declaration google:fedora-29-64:tests/main/snap-service-stop-mode google:fedora-29-64:tests/main/core-snap-not-test-test google:fedora-29-64:tests/main/install-closed-channel google:fedora-29-64:tests/main/snap-disconnect
<zyga> google:fedora-29-64:tests/main/document-portal-activation google:fedora-29-64:tests/main/core18-with-hooks google:fedora-29-64:tests/main/snap-run-symlink-error google:fedora-29-64:tests/main/chattr google:fedora-29-64:tests/main/proxy google:fedora-29-64:tests/main/auto-refresh-private google:fedora-29-64:tests/main/interfaces-netlink-audit google:fedora-29-64:tests/main/auto-aliases
<zyga> google:fedora-29-64:tests/main/command-chain:reexec1 google:fedora-29-64:tests/main/classic-ubuntu-core-transition-two-cores google:fedora-29-64:tests/main/interfaces-content-mkdir-writable:common google:fedora-29-64:tests/main/op-remove google:fedora-29-64:tests/main/snap-service-after-before google:fedora-29-64:tests/main/refresh-delta-from-core google:fedora-29-64:tests/main/interfaces-gpg-public-keys
<zyga> google:fedora-29-64:tests/main/interfaces-hardware-random-observe google:fedora-29-64:tests/main/interfaces-network-control-ip-netns google:fedora-29-64:tests/main/auto-refresh:parallel google:fedora-29-64:tests/main/disable-autoconnect google:fedora-29-64:tests/main/interfaces-ssh-keys google:fedora-29-64:tests/main/snap-userd-desktop-app-autostart google:fedora-29-64:tests/main/install-refresh-private
<zyga> google:fedora-29-64:tests/main/interfaces-network-setup-control google:fedora-29-64:tests/main/install-store-laaaarge google:fedora-29-64:tests/main/econnreset google:fedora-29-64:tests/main/refresh-all google:fedora-29-64:tests/main/interfaces-home google:fedora-29-64:tests/main/umask google:fedora-29-64:tests/main/selinux-lxd + echo '# free space'
<zyga> this ran before
<zyga> mborzecki: ^
<abeato> zyga, hey, is there any PR/plans for https://bugs.launchpad.net/snapd/+bug/1821023 ?
<mup> Bug #1821023: core18 base on core 16 missing firmware <snapd:Triaged by zyga> <https://launchpad.net/bugs/1821023>
 * zyga lunch
<mup> PR snapd#6700 closed: packaging: disable -buildmode=pie on all arches <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6700>
<mvo> 6418 needs a second review
<mup> PR snapd#6594 closed: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<mvo> 6599 also needs a second review, should be easy and small
<zyga> abeato: no PRs yet, just in the TODO list
<abeato> zyga, ok, but still up for 2.39?
<zyga> yes
<abeato> great
<mvo> pedronis: I updated 6603, should be good now
<mvo> 6603 also needs a second review
<pedronis> Chipaca: I suppose you were aware that we potentially import state stuff via auth into snap,  seems the go linker is clever that doesn't happen in practice though
<pstolowski> mvo: +1 to 6599 with a comment
<Chipaca> pedronis: you mean snap â o.auth -> o.state? yeah
<pedronis> Chipaca: yes
<Chipaca> also hexchat is silly and doesn't always do the â -> â thing
<Chipaca> lol
<pedronis> Chipaca: I can probably untangle that now, though as I said the linker seems to do the right thing
<pedronis> Chipaca: do you think untangling that would help overall?
<Chipaca> pedronis: not the first thing i worry about wrt untangling tbh
<pedronis> Chipaca: ok, I'm mentioning it because I'm shuffling things around in that area
<pedronis> anyway
<Chipaca> ah, if you are then maybe yes
<pedronis> but fully untangling that is a bit of extra work
<Chipaca> pedronis: can you nudge it towards it being easier to do, without it being too much extra work?
<mup> PR snapd#6718 opened: spread, tests: do not leave mislabeled files in restorecon test, attempt to catch similar files <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6718>
<mborzecki> zyga: ^^
<pedronis> Chipaca: yes, basically I'm moving AuthContext to a storecontext packages, to fully untangle  some bits of auth would need to move to devicestate
<mborzecki> zyga: hope the safety checks do not catch any thing else
<pedronis> Chipaca: it might be saner anyway
<pedronis> to do the last bit
<Chipaca> pedronis: move what to devicestate?
<pedronis> Chipaca: Device SetDevice User etc
<pedronis> all the functions taking state.State
<Chipaca> hah, and DeviceState
<pedronis> no
<pedronis> that needs to stay in auth
<pedronis> basically almost only the structs
<pedronis> would stay in auth
<pedronis> and be shared with store etc
<pstolowski> Chipaca: are you refactoring any store bits (auth?); asking in the context of autorefresh fix that i'm about to start doing
<Chipaca> pstolowski: pedronis is :-)
<Chipaca> maybe
<pedronis> Chipaca: I am
<pedronis> sorry
<pedronis> pstolowski: I am, but store is actually the package I'm going to touch the least
<Chipaca> pstolowski: I'm not, I'm breaking things in ifacestate and snapstate
<pedronis> pstolowski: so don't worry
<Chipaca> pstolowski: what I heard pedronis say was "race is on"
<pstolowski> Chipaca: :)
<pedronis> if I'm touch store a lot I'm doing it wrong
<pstolowski> pedronis: we still need to find a good name for snapshots.expiration config option (re https://github.com/snapcore/snapd/pull/6669); also your high-level feedback on the "0" semantics would be appreciated (see my self-review comment in the PR)
<mup> PR #6669: overlord/corecfg: make expiration of automatic snapshots configurable (4/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6669>
<mborzecki> Chipaca: almost forgot, https://github.com/snapcore/snapd/pull/6688 volume/structure overlap validation
<mup> PR #6688: gadget: add validation of cross structure overlap and offset writes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6688>
<pedronis> pstolowski: I know, we cand land 6662 to start?
<pstolowski> pedronis: oh yes, doing!
<mup> PR snapd#6662 closed: overlord/snapstate,snapshotstate: create snapshot on snap removal (3/4) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6662>
<mup> PR snapd#6693 closed: cmd: tweak internal tool lookup to accept more possible locations <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6693>
 * cachio lunch
 * zyga resumes work on base snap refreshes
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<zyga> break
<zyga> abck
<mup> PR snapd#6719 opened: many: move auth.AuthContext to store.DeviceAndAuthContext, the implemention to a separate storecontext package <Created by pedronis> <https://github.com/snapcore/snapd/pull/6719>
<pedronis> Chipaca:  ^  it's big but mostly boring
<pedronis> (doesn't do the last bit discussed because it's already big like this, would be a follow up)
<mup> Bug #1824851 opened: snap-update-ns failure on `snap run lxd.activate` <Snappy:New> <https://launchpad.net/bugs/1824851>
<zyga> hmm
<roadmr> hey folks, does ubuntu-image support any kind of caching or proxy? I'm iterating on a build and it's super painful to download pi-kernel every single time :/
<roadmr> I have a squid I can point it to, if supported
<mup> Bug #1824851 changed: snap-update-ns failure on `snap run lxd.activate` <snapd:New for zyga> <https://launchpad.net/bugs/1824851>
<zyga> roadmr: I don't know but I feel the pain as well
<roadmr> zyga: looks like it'll take local snaps preferently, so a poor man's cache seems to be just downloading the required .snaps and putting them in PWD
<roadmr> testing!
 * zyga breaks for an hour
<mup> PR snapcraft#2534 opened: Add SNAPCRAFT_PROJECT_DIR environment variable <Created by tonysimpson> <https://github.com/snapcore/snapcraft/pull/2534>
<pedronis> mvo: cachio: related to good commit messages, we probably shouldn't merge PR levaving [RFC] in their commit
<cachio> sure, pedronis: which is the PR?
<pedronis> cachio: 6594  that mvo merged
<cachio> pedronis: ahhh, ok, your are right
<cachio> pedronis: you suggest to revert/edit/merge ?
<cachio> or it is just for next time?
<pedronis> for next time
<zyga> I could use a coffee
<roadmr> zyga: so - download the snaps that are in your image, name them snap_revision_arch.snap (usual), then point ubuntu-image to them via --extra-snaps=/path/to/foo.snap (use one --extra-snaps per snap). That does a sort of poor man's cache :)
<roadmr> https://blog.ubuntu.com/2017/07/11/ubuntu-core-making-a-factory-image-with-private-snaps has more deets
<zyga> roadmr: does the image get used correctly
<zyga> roadmr: as in, with assertions and such
<roadmr> zyga: hm I didn't test the built image :/
<brlin> https://forum.snapcraft.io/t/anyone-care-to-review-this-article-on-snapd-admin/10937
<mup> PR snapd#6720 opened: many: move Device/SetDevice to devicestate, start of making them pluggable in storecontext <Created by pedronis> <https://github.com/snapcore/snapd/pull/6720>
#snappy 2019-04-16
<mup> PR snapd#6721 opened: tests: new profiler snap used to track cpu and memory for snapd and snap commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6721>
<zyga> Hello
 * zyga was watching the news about Paris last night 
<zyga> a bit sleepy, sorry
<mvo> zyga: it looks like the selinux-clean test is unhappy (in master and in the recent PR spread runs). is anyone on it or shall we disable it for now?
<zyga> mvo: mborzecki is on it
<zyga> we talked about it a lot yesterday
<zyga> essentially it keeps finding bugs
<mvo> ok
<zyga> mvo: there's a fun bug in the kernel and in apparmor breaking disco
<zyga> mvo: but apparently only in lxd
<zyga> mvo: the security team was on it last evening
<pedronis> disco ships on Thu, fun
<zyga> yes
<zyga> everyone is well aware, lsm stacking landed
<zyga> lxd started using shiftfs
<zyga> this confused apparmor parser caching
<zyga> and no profiles got loaded
<pstolowski> mornings
<zyga> hey pawel
<mvo> pstolowski: good morning
<mvo> zyga: woah, sounds like fun indeed
<mup> PR snapd#6722 opened: tests: set selinux-clean test to manual for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6722>
<mvo> woah, now travis fails in the static tests even oh boy
<mup> PR snapd#6673 closed: cmd,tests: forcibly discard mount namespace when bases change <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6673>
<zyga> oh fun
<zyga> mvo: did go change in travis?
<mup> PR snapd#6723 opened: cmd/snap-confine: remove unused sc_open_snap_{update,discard}_ns <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6723>
<zyga> pstolowski, mvo:  ^ trivial
<pstolowski> done
<mvo> zyga: you got it as well
<zyga> thank you
<zyga> aaah
<zyga> I see
<zyga> the go version fun
<mvo> super mysterious as we did not change anything there did we?
 * mvo looks
<mvo> this looks like a travis issue, we request go1.9
<mvo> maybe they dropped it?
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> 56 PRs open, better than yday
<mvo> mborzecki: yeah, its getting better except master is not happy
<mborzecki> mvo: what's the problem with master?
<mvo> mborzecki: but we are working on it :) some things could land once this is unbroken
<mvo> mborzecki: the selinux-clean test is unhappy more often than not
<mvo> mborzecki: also static checks are complaining right now
<mborzecki> mvo: heh
<mup> PR snapd#6724 opened: travis: fix requested go version <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6724>
<mborzecki> mvo: #6718 should help a bit with selinux clean test
<mup> PR #6718: spread, tests: do not leave mislabeled files in restorecon test, attempt to catch similar files <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6718>
<mvo> mborzecki: static checks have a version mismatch and die very early
<mvo> mborzecki: aha, nice, is that green?
<mborzecki> mvo: and yesterday i noticed that snapd started calling runuser
<mborzecki> is that automatic snapshotting?
<pedronis> mborzecki: I think so
<mvo> mborzecki: 6718 ironically fails in selinux-clean
<pedronis> Chipaca probably knows more about that (runuser)
<mborzecki> mvo: yeah, looked at it yday evening and iirc it was because of runuser
<mvo> aha, ok
<mborzecki> flag provided but not defined: -V, hmm
<mup> PR snapd#6724 closed: travis: fix requested go version <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6724>
<mborzecki> conspiracy theories in the forum
<mvo> it looks like version mismatch - go tool asm -V does indeed not exist in 1.9
<mvo> so it looks like go vet is driving it the wrong way (or something is)
 * mvo has a meeting now so won't look at this
<mborzecki> mvo: where do we get vet from?
<mvo> mborzecki: I don't know
<mborzecki> mvo: go tool vet is part of golang distribution package, and afaik vet is just a frontend, presumably both should be from the same distro package
<Chipaca> runuserwha?
<Chipaca> g'morning
<Chipaca> mborzecki: what's up with runuser?
<mborzecki> Chipaca: morning, runuser, we use it to snapshot user's data right?
<Chipaca> mborzecki: yes (and hopefully any user data manipulation someday)
<Chipaca> mborzecki: why?
<mborzecki> Chipaca: cool, we need to extend the selinux policy to allow some actions it does (setgid, writing to audit and so on)
<Chipaca> pedronis: starting on coherence, do you have a link to the server-side to hand?
<mborzecki> fwiw, the changes look trivial, i should have a PR up soon
<pedronis> Chipaca: one sec
<Chipaca> mborzecki: i guess we only saw this now because of automatic snapshots?
<mborzecki> Chipaca: yes, that would be my guess, wonder why it didn't come up in the travis job of the PR that added automatic snapshots
<mborzecki> well, maybe the PR did not include the test back when it was opened
<zyga>  re
<zyga> sorry, had to clean the office a little
<pedronis> Chipaca: sorry, need to have a quick errands, I can give you links after (in ~30 mins)
<Chipaca> pedronis: no probs
<mup> PR snapd#6725 opened: travis: add some debug to run-checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/6725>
<mborzecki> why on earth we use /home/gopath and since it's under /home we treat it like another homedir
<mborzecki> but since it's not a homedir (there's no gopath user), none of the selinux transitions take place
<mvo> I think I found the issue
<mvo> with the status check
<mvo> oh well
<mvo> I wonder why this ever worked
<zyga> mvo: what did you find?
<mvo> zyga: PR up in 60s, then it will be obvious
<zyga>  thank you :)
<mup> PR snapd#6725 closed: travis: add some debug to run-checks <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6725>
<mup> PR snapd#6726 opened: tests: do not hardcode go1.10 in travis <Created by mvo5> <https://github.com/snapcore/snapd/pull/6726>
<mvo> zyga: -^
 * mvo takes a short break
<zyga> looking
<zyga> interesting
<zyga> mvo: there was a simliar bug in suse
<zyga> that is, suse golang stack got updated during startup
<zyga> but the environment variables were pointing to the old stack
<zyga> with similar insane errors
<mborzecki> policy update for runuser is up
<mup> PR snapd#6727 opened: data/selinux: allow snapd to execute runuser under snappy_t <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6727>
<ilyaigpetrov> Hi. I'm new to Ubuntu Core and I want to boot from it from a usb pendrive without using any device other than my notebook (so I have no device to SSH from) -- what is the easiest way to do this? I don't have VTx support on my CPU and wouldn't prefer using a virtual machine, partly because I have an idea of using ubuntu core as my main desktop system (browser and  a terminal is all I need from it).
<mvo> mborzecki: with 6727 can we get rid of 6722?
<zyga> ilyaigpetrov: hey
<zyga> ilyaigpetrov: I think core is not quire suited for that use case yet
<mborzecki> mvo: yes
<zyga> ilyaigpetrov: it is mainly usable as virtual machines in the cloud and single-purpose devices in the field
<ilyaigpetrov> zyga: I want to learn new things this way
<zyga> ilyaigpetrov: support for users and sessions is limited
<zyga> ilyaigpetrov: you won't get a graphics session or a browser easily either
<zyga> ilyaigpetrov: if you want to learn you can try getting the amd64 ubuntu core image and copy it to a USB drive
<zyga> ilyaigpetrov: then instruct your device to boot from it
<mborzecki> mvo: #6726 will probably fail on fedora/centos due to selinux, we should merge it anyway
<mup> PR #6726: tests: do not hardcode go1.10 in travis <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6726>
<zyga> ilyaigpetrov: it will work, it's just not a device that one would use for daily stuff IMO
<zyga> mborzecki: selinux question, when are semicolons required?
<ilyaigpetrov> zyga: yes, I boot from the usb pendrive, enter my ubuntu SSO and it says I need to ssh into it, but I don't have any other notebook to log in via ssh from
<zyga> sorry, that's the only way in
<zyga> once you ssh you can set a password
<ilyaigpetrov> zyga: I think to create a box based on raspberry Pi for kids to learn computers and coding, I want them being able to log in
<ilyaigpetrov> zyga: is there any image customization I can do?
<mborzecki> zyga: allow <foo> rules require it at the end, interfaces have a bunch of allow rules, each should end with ; already
<zyga> ilyaigpetrov: I commend your desire to learn but I don't think core is the best use for that yet, for learing there are much better suited (especially for children) tailored distributions with graphical displays and keyboard / mouse support
<zyga> ilyaigpetrov: what kind of customization?
<mvo> mborzecki: indeed, so how about I combine 6726 and 6722 and then master should be green again. then we combine your selinux fixes and run it ~10 times or so and if all is green there we enable selinux-clean again? sounds reasonable?
<ilyaigpetrov> zyga: replace config launcher on getty (I guess it's called getty)
<zyga> ilyaigpetrov: no, that's not something you can do easily
<zyga> ilyaigpetrov: and it will be undone by the system on the next update
<ilyaigpetrov> *sigh* so sad
<zyga> ilyaigpetrov: note that the user has no password
<zyga> ilyaigpetrov: you must login via ssh first
<zyga> ilyaigpetrov: then you can login interactively on another tty
<zyga> (tty1 is special, rest should be regular)
<zyga> ilyaigpetrov: core is designed for single use devices without users really
<zyga> ilyaigpetrov: you don't expect each streetlight to have an user account, this is what core is aiming at
<ilyaigpetrov> zyga: can I install a basic wayland compositor (or a mir server) and from another snap to install a firefox browser -- will they work together?
<mborzecki> mvo: sounds good, then we can land 6727 and 6718
<ilyaigpetrov> I'm not sure I understand how desktop snap is used by other snaps
<mvo> mborzecki: cool, let me prepare things
 * zyga quick breakfast
<zyga> ilyaigpetrov: there are no snaps that support user sessions on a core system
<ilyaigpetrov> zyga: mm, but I have seen egmde confined snap
<ilyaigpetrov> https://snapcraft.io/egmde-confined-desktop
<zyga> I donât know about that
<mvo> some of my branches need a second review: 6418 (might be interessting for zyga), 6599 and 6603 would be great. also 6627. all remodel related but relatively small and self-contained. *please* :)
<zyga> mvo: gladly!
<zyga> In 15 minutes
<ilyaigpetrov> zyga: thanks for you help, bond appetite
<zyga> ilyaigpetrov: you can try core in qemu
<zyga> On i386 you donât need hardware support
<ilyaigpetrov> zyga: I really like the idea of using core as my main system, even if virtual tty is all I have with a single user
<zyga>  ilyaigpetrov you need a 2nd machine then
<popey> ilyaigpetrov: i have a laptop which is running Ubuntu core. It's a touch limiting for normal use.
<ilyaigpetrov> popey: I used to use gentoo confining myself to using vttys only for learning purposes, and I learn how to run a single window of a browser on naked xorg server, I think it was useful
<popey> It's certainly fun
<zyga> back now
<zyga> mvo: looking
<zyga> mvo: note I will still address the snapd tools directory going stale
<zyga> mvo: separately from this PR
<zyga> mvo: https://github.com/snapcore/snapd/pull/6418#pullrequestreview-227099069
<mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<zyga> mvo: it should be ok to just push the commit suggestion buttons a few times :)
<zyga> mvo: doing another one
<zyga> mvo: about 6599, should AddAll just add edges?
<zyga> mvo: or fail if edges are present?
<cwayne> sil2100: hey, is there anything in the latest core18 that may affect wifi?
<zyga> mvo: https://github.com/snapcore/snapd/pull/6599#pullrequestreview-227102274
<mup> PR #6599: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <https://github.com/snapcore/snapd/pull/6599>
<pstolowski> zyga, mvo: or do extra iteration to check first?
<zyga> hey cwayne, long time no see :)
<cwayne> zyga: heya :) how's it goin?
<zyga> cwayne: great, swamped under bugs and feature work but feeling positive today :)
<cwayne> zyga: I'd rather be swamped than have nothing to do :)
<zyga> cwayne: I think we are not at any risk of having nothing to do :)
<cwayne> lol true!
<sil2100> cwayne: hm, I'd have to dig deeper, but I don't think so
<sil2100> We did release a new systemd yesterday, which is why a new core18 was triggered
<cwayne> sil2100: ok, will poke on this end, seeing some wifi failures on Pi's which we hadnt seen in awhile
<sil2100> Oh, hm
<sil2100> cwayne: for a moment I was worried that someone released the new netplan package, but no, at least not for bionic
<sil2100> And anyway, Matt said that he addressed the previous networking issue in the current netplan SRU anyway
<cwayne> Yeah this isn't the same issue we saw earlier with netplan for sure
<sil2100> Ok
<zyga> mvo: https://github.com/snapcore/snapd/pull/6603#pullrequestreview-227104276
<mup> PR #6603:  snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6603>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6627 has some unanswered questions
<mup> PR #6627: devicestate: deal correctly with the "required" flag on Remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/6627>
<zyga> doing a pass anyway
<mvo> zyga: aha, ok, let me double check, maybe I missed something. thank you
<sil2100> cwayne: the new systemd SRU we released did address some network bugs, so who knows, maybe there's some regression there
<sil2100> cwayne: but the changes didn't seem highly likely to cause wlan-only issues
<cwayne> sil2100: ack, well poke around on our end
<mvo> zyga: sorry, was in a meeting I see you wrote more. will get back to that in a wee bit
<zyga> mvo: no worries, I'm going through the last one you requested
<mborzecki> mvo: https://api.travis-ci.org/v3/job/520673622/log.txt 6722 failed in canonical-livepatch test
<mup> PR snapd#6728 opened: overlord/devicestate: extra measurements related to populateStateFromSeed <Created by stolowski> <https://github.com/snapcore/snapd/pull/6728>
<pstolowski> uhmmm.. unhappy day for travis
<mborzecki> mvo:  copied the log here: https://paste.ubuntu.com/p/QnVW7vCqJ6/ i'll restart the travis job
<zyga> mvo: https://github.com/snapcore/snapd/pull/6627#pullrequestreview-227110498
<mup> PR #6627: devicestate: deal correctly with the "required" flag on Remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/6627>
<zyga> https://github.com/snapcore/snapd/pull/6726 is red
<mup> PR #6726: tests: do not hardcode go1.10 in travis <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6726>
<mborzecki> zyga: yes, it'll land as 6722
<zyga> ack
<zyga> unless anyone has a review they want to pull me into, I will resume working on tests
<mborzecki> hmm canonical-livepatch failed there too :/
<zyga> yeah
<zyga> one of those days, as they say
<mvo> yeah, looking at this now
<mvo> looks like something changed there as well
<pstolowski> pedronis: re your question to https://forum.snapcraft.io/t/how-to-disconnect-a-snap-from-internet/10901/10 from yesterday - yes, we have a spread test for this - it's main/disable-autoconnect
<pedronis> pstolowski: thx
<mup> PR snapd#6729 opened: tests: update canonical-livepatch now that -gcp kernels are supported <Created by mvo5> <https://github.com/snapcore/snapd/pull/6729>
<mup> PR snapd#6730 opened: tests: fix master <Created by mvo5> <https://github.com/snapcore/snapd/pull/6730>
<mborzecki> mvo: looks like we need a one PR to unite all fixes
<mvo> mborzecki: yeah, I added this in 6730
<mvo> mborzecki: or is it missing something?
<mvo> fwiw, I'm also looking at livepatch now, maybe we can make the needle we look for better
<Chipaca> huh, store.RefreshCandidate still exists
 * Chipaca nukes it
<joc> sil2100: so re. the wifi failures you were talking to cwayne about earlier - nothing has changed in core18 but systemd?
<mup> PR snapd#6729 closed: tests: update canonical-livepatch now that -gcp kernels are supported <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6729>
<mup> PR snapd#6730 closed: tests: fix master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6730>
 * zyga hugs everyone who helped to fix master
<mup> PR snapd#6722 closed: tests: set selinux-clean test to manual for now <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6722>
<mup> PR snapd#6726 closed: tests: do not hardcode go1.10 in travis <â  Critical> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6726>
<zyga> mvo: so master is fixed now :)
<rbasak> https://forum.snapcraft.io/c/release seems out of date. Where do relesae announcements go now?
<zyga> rbasak: snapd releases are listed on https://github.com/snapcore/snapd/releases/
<isomari_> greetings, how can I hide my ssid using snap wifi-ap?
<rbasak> zyga: thanks. I was hoping for a summary of changes though. For example, that page doesn't say what happened in 2.38. I thought that's what the forum topic was for/
<rbasak> ?
<zyga> rbasak: it used to say that
<zyga> rbasak: just not all releases are listed with equal verbosity
<zyga> mvo: ^
<pedronis> there is also https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<rbasak> The bugfix releases are all detailed, but I was wanting to know more about the high level stuff happening in feature releases.
<rbasak> pedronis: ah that's useful - thanks!
<Chipaca> isomari_: no idea. Are you sure you're in the right place to ask that?
<mborzecki> anyone brave enough to do a 2nd review of https://github.com/snapcore/snapd/pull/6688 ? :)
<mup> PR #6688: gadget: add validation of cross structure overlap and offset writes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6688>
<mborzecki> involves familiarizing oneself with gadget.yaml and some hair pulling while reading the code :)
<zyga> mborzecki: I can look but only after the standup, trying to wrap up a bigger chunk here
<mborzecki> zyga: thanks!
<cyphermox> cwayne: mvo: so what issue are we seeing now for core18, is it in any way netplan-related?
<isomari_> Chipaca: Was asked to come here from ubuntu.
<isomari_> Chipaca: I found the answer. Thanks
<mup> PR snapd#6731 opened: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <https://github.com/snapcore/snapd/pull/6731>
<pedronis> mborzecki: what's the status of master? needs 6727 ?
<mborzecki> pedronis: master should be green, but selinux-clean test is disabled, 6727 enables the test and carries a fix for the policy
<pedronis> ok, thx
<mup> PR snapd#6704 closed: overlord/devicestate: measurements around ensure and related tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6704>
<mvo> rbasak: sorry, I have not updated for the coming 2.39 features yet. or do you need info about a much older release on the forum? what version are you looking for?
<rbasak> mvo: nothing specific, thanks.
<jdstrand> mvo: hey, sorry to bother you. what is the trick with either creating a debian/fedora qemu autopkgtest image (autopkgtest-build-qemu unstable debian-sid-64.img fails for me) or accessing google (no access to google:debian-sid-64:tests/main/...)
<zyga> hey
<zyga> jdstrand: for debian you can get the qemu cloud image they have
<zyga> AFAIK it works out of the box
<jdstrand> hey zyga :)
<zyga> (they == debian)
<zyga> the fedora one I don't recall
<zyga> if you wait a little I may have some links for you
<jdstrand> hmm, googled for it. /me keeps looking
<mvo> jdstrand: you can ask gustavo for a google spread key
<zyga> jdstrand: in theory there is https://spread.zygoon.pl/images/ but I don't keep it up-to-date
<mvo> jdstrand: I don't know how to create fedora images, I suspect its also "just" downloading their cloud image and adjusting the login creds
<zyga> jdstrand: ^ mvo's advice is really best
<jdstrand> ack. I see in spread.yaml what to change them to. let me see what I can find
<jdstrand> I thought I had a google spread key. where is that stored?
<zyga> jdstrand: it's essentially this: run any cloud image with cloud-init inside to the point where you have shell, set passwords and you _might_ be ready
<zyga> jdstrand: but because google images have customization applied we don't really know
<zyga> jdstrand: it's in ~/.config/gcloud
 * zyga afk for 15 minutes
<jdstrand> I have stuff in that dir
 * jdstrand looks for the images
<jdstrand> thanks!
<sergiusens> ogra: did you happen to look into wireguard on Ubuntu Core?
 * jdstrand notes wireguard upstream still says not to use it in production
 * jdstrand may just use zyga's images and upgrade
<jdstrand> oh those are just ubuntu. I can create those fine
<mup> PR snapd#6732 opened: tests: run livepatch on 18.04 as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/6732>
<ogra> sergiusens, nope
<ogra> sergiusens, there are two snaps in the store touch
<ogra> *though
<zyga> re
<zyga> sorry, I was grabbed into a family lunch
<zyga> jdstrand: let me know if I can help
<zyga> I can regen and upload fresh images
<zyga> I think I can upload some more too, there's a 10GB quota on that directory
<mup> PR snapd#6719 closed: many: move auth.AuthContext to store.DeviceAndAuthContext, the implemention to a separate storecontext package <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6719>
 * dot-tobias says hi
<dot-tobias> is it possible to print output from hook scripts when they're running? I only get output if it fails, and then it's only the last ~5 lines
<mup> PR snapd#6692 closed: interfaces: cleanup internal tool lookup in system-key <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<mborzecki> dot-tobias: redirect the output to some log file under $SNAP_COMMON?
<zyga> or /tmp
<zyga> though tmp is harder to find
 * zyga reviews 6688
<zyga> mborzecki: hey
<zyga> mborzecki: remark about the gadget work
<mborzecki> zyga: hm?
<zyga> I think it would be great if you could add some docs , namely the key types Volume, VolumeStructure etc should be documented
<zyga> they don't have to be long
<zyga> I would put a paragraph or two in the file header, ahead of the docs of other stuff (perhaps package docs) for some quick context
<zyga> then individual types can describe their role in the bigger picture
<mborzecki> zyga: ok, i'll add something
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<pedronis> mvo: Chipaca: pstolowski:  store context refactoring has landed
<pstolowski> pedronis: great, thx
<Chipaca> pedronis: current status: https://pastebin.ubuntu.com/p/2TsZDK3wFZ/
<pedronis> cool
<cachio> zyga, hey, I see this error when fedora 29 is updated https://paste.ubuntu.com/p/rv9Kzh24m7/
<cachio> zyga, any idea what could be causing this?
<zyga> cachio: looking now
<zyga> no idea, what does the unit do?
<zyga> as in, what is systemctl cat man-db-cache-update
<zyga> what does jurnald say about that unit?
<cachio> zyga, I am regenerating the image to reproduce it because the image is dsicarded after that error
<zyga> try to get an interactive shell
<zyga> or expand the debug section to know more
<cachio> zyga, sure, I am creating a new image to get an interactive shell
<mup> PR snapd#6733 opened: state: add possible error return to TaskSet.Edge() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6733>
<cachio> zyga, https://paste.ubuntu.com/p/x9s3GtZJgp/
<zyga> cachio: hey
<zyga> cachio: what does the unit do?
<zyga> can you provide the output of "systemctl cat"?
<zyga> cachio: from the looks of the log systemctl cannot complete its task
<cachio> https://paste.ubuntu.com/p/4swr5qVJKx/
<zyga> perhaps our test suite reloading systemd is affecting other units
<zyga> cachio: what about "man-db-cache-update service" ?
<zyga> could you please cat that one?
<cachio> https://paste.ubuntu.com/p/qTDggnMrtW/
<zyga> pl
<zyga> can you start that service?
<zyga> does it fail?
<cachio> if I start the image works well
<cachio> if I start man-db-cache-update manually works well too
<mup> PR snapcraft#2535 opened: build providers: get rid of attribute warnings from pylxd <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2535>
<jdstrand> mvo, zyga: fyi, https://blog.strandboge.com/2019/04/16/cloud-images-qemu-cloud-init-and-snapd-spread-tests/
<cachio> we are doing something as part of the prepare that is affecting
<zyga> based on previous pastebin I would say that it gets interrupted by systemd restart but that's just my theory
<zyga> jdstrand: looking
 * jdstrand attempts fedora
<zyga> jdstrand: nice
<zyga> jdstrand: I will cron that on spread.zygoon.pl
<zyga> thank you for sharing, this is very useful
<jdstrand> np
<jdstrand> there were a couple dots to connect with 'just get a cloud image' and 'adjust cloud-init' :)
<zyga> jdstrand: indeed, I see you have mastered that
<zyga> I was so lazy for too long :)
<zyga> jdstrand: given your cloud-init data I could use one (shared) procedure for all systems that support cloud-init
<zyga> (with some tweaks for individual systems to allow spread to boot them)
<zyga> jdstrand: I have some local spread patches to enhance compatiblity
<zyga> jdstrand: and to provide saner qemu command line
<jdstrand> zyga: do note it is using whatever the default user is for the distro
<jdstrand> there are lots of things cloud-init can do that I'm sure you know more about than I
<jdstrand> cool, seems no special hoops for fedora
<pedronis> mvo: I added a couple of comments to #6733
<mup> PR #6733: state: add possible error return to TaskSet.Edge() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6733>
<cachio> zyga, this is interesting https://paste.ubuntu.com/p/GBQ4KDcQ6f/
<zyga> cachio: what is dwz?
 * zyga sees
<zyga> cachio: I'm non the wiser, I think it is a real error but it is unclear if we are the cause
<cachio> the part of the journal
<cachio> zyga, agree
<cachio> I'll go deep on this
<cachio> thank
<cachio> s
<zyga> cachio: I'm sorry I'm not of much help, good luck
<zyga> cachio: I'd be curious to see if a vanilla image has this issue
<zyga> cachio: perhaps dwz crashed because it is confused by particular behaviour of the go linker
<cachio> zyga, np, I'll try it after
<mup> PR snapd#6718 closed: spread, tests: do not leave mislabeled files in restorecon test, attempt to catch similar files <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6718>
<mup> PR snapd#6727 closed: data/selinux: allow snapd to execute runuser under snappy_t <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6727>
 * zyga EODs
<jdstrand> mvo, zyga: fyi, made some small updates to my blog post to accommodate fedora
 * cachio afk
<mvo> pedronis: I updated 6603 btw, hope all your comments are addressed
<mup> PR snapcraft#2535 closed: build providers: get rid of attribute warnings from pylxd <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2535>
<mup> PR snapcraft#2534 closed: Add SNAPCRAFT_PROJECT_DIR environment variable <Created by tonysimpson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2534>
<mup> PR snapd#6723 closed: cmd/snap-confine: remove unused sc_open_snap_{update,discard}_ns <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6723>
<mup> PR snapd#6734 opened: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/6734>
#snappy 2019-04-17
<mup> PR snapd#6735 opened: tests: Wait for man db cache is updated before after install snapd on Fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6735>
<zyga> good morning
<zyga> Hey mvo
<mvo> hey zyga
<pedronis> zyga: mvo: hi
<zyga> Hey pedronis
<zyga> I didnât push it yet but I have the next chunk of update ns refactor rebased and adjusted
<zyga> Iâll open the PR in about an hour after I handle kids and other morning routine
<mvo> hey pedronis - good morning
<pedronis> zyga: ok, I likely will not get to it before my vacation though
<pstolowski> morning
<mup> PR snapd#6659 closed: snapcraft: build static fontconfig in the snapd snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6659>
<mvo> https://github.com/snapcore/core/pull/104 <- needs a review (should be simple :)
<mup> PR core#104: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> a day off and i'm looking at spread logs :)
<mvo> mborzecki: I was wondering
<mvo> mborzecki: if I misremembered the day :)
<mborzecki> mvo: got an email from travis that the job is still failing
<mborzecki> looks like google:centos-7-64:tests/main/nfs-support leaves garbage behind
<mvo> mborzecki: uh, ok - I saw this failing earlier indeed
<mup> PR snapd#6418 closed: many: allow core as a fallback for core16  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<mup> PR snapd#6603 closed:  snapstate: add new NoReRefresh flag and use in Remodel() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6603>
<mborzecki> mvo: it's probably best to disable the test for fedora and centos until i figure out a way of this
<mborzecki> mvo: in short, nfsv3 does not export selinux labels, nfs 4.2+ can
<mborzecki> mvo: so with nfs3 incorrect label (nfs_t) will be used, regardless of what we do
<mborzecki> mvo: just checked that nfsv4 with security_label option works correctly
<zyga> quick trivial PR ahead of other stuff https://github.com/snapcore/snapd/pull/6736
<mup> PR #6736: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6736>
<zyga> mborzecki: are you off or not :)
<zyga> mborzecki: sho, go and enjoy the sunlight :-)
<mborzecki> hahah
<mup> PR snapd#6736 opened: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6736>
<mup> PR snapd#6737 opened: tests/main/nfs-support: temporarily disable for Fedora and CentOS <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6737>
<mborzecki> zyga: mvo: ^^
<zyga> approved
<mborzecki> didn't want to leave you with master broken again :P
<mborzecki> ok, now i'm off, cu tomorrow
<zyga> ah
<zyga> hey Chipaca
<Chipaca> hi
<Chipaca> why do i suspect forum-person tried the equivalent of 'snap install snapd'
<Chipaca> because they heard the snap needed snapd
<zyga> Chipaca: perhaps, I was thinking the same thing
<zyga> https://github.com/golang/go/commit/97c4ad432743d74ee59648dee0db1b107c701834
<zyga> CL
<zyga> change list
<zyga> perforce
<zyga> people hacking on go use perforce?
 * pstolowski runs a quick errand, afk for a bit
<Chipaca> zyga: googlespeak leaking
<mup> PR snapd#6599 closed: snapstate,state: add TaskSet.AddAllWithEdges() and use in doUpdate <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6599>
<pedronis> mvo: maybe this was already clear but I added a post-facto comment to https://github.com/snapcore/snapd/pull/6418
<mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<zyga> mvo: https://api.travis-ci.org/v3/job/521150301/log.txt is interesting
<zyga> mvo: no idea, perhaps something left over core16 behind?
<mvo> zyga: yeah, that sounds like it :/
<zyga> mvo: mvo I saved https://paste.ubuntu.com/p/GVwfVfTHVm/
<zyga> mvo: I'll restart the run
<mvo> ok
 * Chipaca goes to get some exercise
<mvo> pedronis: thanks for adding this extra info to the core16-core pr. quick question: checkSnap() needs to get access to the new model to validate things like kernel/gadget for the new model. should I add model to checkSnap or rather "task" and we add the info about the new model to the task. or something else?
<pedronis> mvo: we probably need to chat, I have a plan for that but is involved  (we really need to know a new store and new model at various points)
<mvo> pedronis: is now good? how long will it take? I can also shelve it and work on something else first if you want to do the prereq work
<pedronis> mvo: we can chat quickly now
<mvo> pedronis: ok, I'm in the standup ho
<pstolowski> re
<zyga> gah
<zyga> when master is read on rename, it's not a good day
<zyga> portal test failure https://www.irccloud.com/pastebin/PKt1NTxz/
<zyga> pedronis: https://github.com/snapcore/snapd/compare/master...zyga:feature/user-mount-ns-20.9-split-3-of-n?expand=1
<zyga> pedronis: at +800, -200 I think I will split it into 2-3 more branches
<zyga> but this is now rebased and I think in good shape
<zyga> and on top of that I have working persisted and updated per-user mount namespaces
<zyga> I will need to spend some time to research jdstrand's questions but it's closer now
<pedronis> zyga: cool, as I said but likely might not get to look at it this week
<zyga> yep
<zyga> I'll return to other pending branches
<mup> PR snapd#6737 closed: tests/main/nfs-support: temporarily disable for Fedora and CentOS <SELinux> <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6737>
<zyga> time to fix https://github.com/snapcore/snapd/pull/6717
<mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<pedronis> mvo: btw as I said I'm ok with 6733 with the small tweaks I proposed
<mvo> pedronis: thanks!, will get to it after lunch
<mup> PR snapd#6738 opened: tests: check for /snap/core16/current in core16-provided-by-core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6738>
 * cachio afk
<pedronis> zyga: do I see it correcly that #6681 will/might conflict with our own snap-confine groups related rework?
<mup> PR #6681: many: support system-users for 'daemon' user <Complex> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
<pedronis> s/our own/your own/
<zyga> yes
<zyga> I spoke with jamie about it and promised to work on all conflicts
<pedronis> ok
<zyga> he was happy with either of us doing the conflict resolution though
<zyga> so I don't anticipate problems
<zyga> eh
<zyga> so that go check thing where it eats all memory
<zyga> that is not fixed?
<zyga> when it diffs recursive structures
<Chipaca> zyga: i thought it was a bug in the differ, that had been fixed?
<Chipaca> not sure tho
<zyga> apparently not enough
<Chipaca> maciej knows more
<zyga> I fixed it locally
<zyga> by disabling that
<Chipaca> don't disable the maciej! it's nice having him around
<zyga> pstolowski: can you please look at https://github.com/snapcore/snapd/pull/6717
<zyga> too late! he's gone today
<mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<pstolowski> zyga: will do
<pedronis> jdstrand: hi, I did a first pass, getting familar with #6681
<mup> PR #6681: many: support system-users for 'daemon' user <Complex> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6681>
<pedronis> jdstrand: what's the status of #5644  vs landing it for 2.39 ?
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<jdstrand> pedronis: thanks! I'll take a look. other than that, there is the outstanding question of how to deal with systems that do not have the daemon user
<pedronis> jdstrand: there is a list of those in the forum topic, right?
<jdstrand> pedronis: I've been unable to do any snap decls. I've hoped to get to it since the agreement. I still hop to start this week
<pedronis> jdstrand: ok
<jdstrand> pedronis: the forum topic only lists solus as not having the LSB-required daemon user. that is the only one I am aware of
<jdstrand> pedronis: I have not tested actual behavior yet if it doesn't exist. I know that the lookup for u:daemon and g:daemon will fail in policy generation. how that is exposed to the user I'm not sure
<pedronis> jdstrand: I think we should fail somehow around checkAssumes on this
<jdstrand> pedronis: so, I could try to do something with an implied assumes, an explicit assumes, fail earlier or implement a new backend to create it. maybe you have other ideas
<jdstrand> pedronis: I was leaning towards something like that as well
<pedronis> jdstrand: I think we start by failing with an implied assumes
<pedronis> and see what feedback we get from users there
<jdstrand> pedronis: ok, I'll work on that next
<pedronis> and whether that pushes us, the packaging or the distro to creat the user
<jdstrand> zyga: I had a conflict today. I already resolved it
<jdstrand> pedronis: what is the timeframe for 2.39 btw?
<pedronis> jdstrand: it's in the forum now
<pedronis> jdstrand: https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<jdstrand> pedronis: I marked the daemon user for that since, well, lots of people want it, roadmap, etc. it shouldn't be very risky since most of the code only hits if specifying system-users
<jdstrand> ok, cool. I see the topic (hadn't read email yet today)
<pedronis> jdstrand: that's fine, next week I'm off but I would think if we clarify things,  mvo and zygmunt reviews would be enough
<pedronis> jdstrand: I have a question about the snap-confine change, I'm either confused or the comment is or yet something else
<jdstrand> pedronis: joe said it's my highest priority, so I'll stay on top of it
<jdstrand> pedronis: I saw, I'll swing back to your questions a bit later
<mup> PR snapd#6627 closed: devicestate: deal correctly with the "required" flag on Remodel <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6627>
<jdstrand> pedronis: ok, responded. I'll focus on the implied assumes behavior and keep an eye on the PR for things you or others would like to see changed
<jdstrand> mvo: hey, fyi https://bugs.launchpad.net/snapd/+bug/1825052 in case you didn't see it
<mup> Bug #1825052: seccomp argument filtering not working on Fedora with 2.38 and Debian with 2.37.4 <snapd:New> <https://launchpad.net/bugs/1825052>
<jdstrand> mvo: also, I wasn't planning on looking at that. if you need me to, we'd need to chat with joe (note, I've not really worked on cross distro enablement)
<jdstrand> mvo: I'd also like hello-world to be updated to accept hello-world.sh -c ... (not to mention, be rebuilt so it passes review-tools resquash since it was built before -no-fragments)
<jdstrand> mvo: I can submit something for that (or upload); istr it was part of the shared account but then the shared account went away... please advise :)
<mvo> jdstrand: I can add you to hello world, one sec
<mvo> jdstrand: you should have an email
<pedronis> pstolowski: #6678 can land right?
<mup> PR #6678: cmd/snap, api: use DebugGet for timings <Created by stolowski> <https://github.com/snapcore/snapd/pull/6678>
<pstolowski> looking
<pstolowski> yes
<mup> PR snapd#6678 closed: cmd/snap, api: use DebugGet for timings <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6678>
<jdstrand> mvo: thanks!
<jdstrand> mvo: it's the little things in life :)
<mvo> jdstrand: heh - my pleasure! thanks for updating this snap
<mup> PR snapd#6736 closed: cmd/snap-update-ns: rename variable "up" to "ctx" <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6736>
<mvo> 6716 needs a second review
<mvo> pedronis: 6720 has a conflict now
<mup> PR snapd#6739 opened: cmd/snap, store, image: support for cohorts in "snap download" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6739>
<Chipaca> pedronis: ^ first cohorts bit (starting from an unlikely one, but a nice narrow vertical)
<pedronis> mvo: possibly yes
<Chipaca> next up, create-cohort
<Chipaca> with an alias of 'cohorate', obvs
<pedronis> Chipaca: thx
 * pedronis is doing fun things in/to snapstate atm
<Chipaca> nooo
<Chipaca> :-)
 * cachio lunch
<Chipaca> ooh, oh, i forgot to add a bit to that
 * Chipaca force-pushes quickly before anybody notices
<jdstrand> mvo: fyi, I never got an email
 * Chipaca quickly sends jdstrand his first email
<jdstrand> heh
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mvo> jdstrand: oh, let me try again
<mvo> jdstrand: tried again, can you please check?
<mup> PR snapd#6740 opened: cmd/snap-update-ns: refactor of profile application (3/N) <Created by zyga> <https://github.com/snapcore/snapd/pull/6740>
<mup> PR snapd#6741 opened: [RFC] osutil: make CommandFromCore honor the snapd snap <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6741>
<mvo> pedronis: ^-- this should fix some more of the gaps in snapd vs core
<mvo> pedronis: iirc you wanted to also move osutil.ExecFromCore, please let me know the details and I will expand the PR
<mup> PR snapd#6732 closed: tests: run livepatch on 18.04 as well <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6732>
<jdstrand> mvo: got it
<cachio> Chipaca, hey, when you have a time could you please take a look to #6694
<mup> PR #6694: tests: improve how snaps are cached <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
<zyga> WAT
<zyga> -----
<zyga> + cat
<zyga> EOM
<zyga> + Use release-tools/debian-package-builder to interactively fix build
<zyga> /bin/bash: line 62: Use: command not found
 * zyga fixes
<mup> PR snapd#6742 opened: tests: fix syntax error in here-doc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6742>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6742 if you can please
<mup> PR #6742: tests: fix syntax error in here-doc <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6742>
<Chipaca> ouch
<Chipaca> how did that land?
<Chipaca> ah, debug
<Chipaca> ok
<zyga> Chipaca: fun right
<zyga> thank you
<mup> PR snapd#6742 closed: tests: fix syntax error in here-doc <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6742>
<mup> PR snapd#6738 closed: tests: check for /snap/core16/current in core16-provided-by-core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6738>
<Wimpress> Snapcraft Live is starting in 10 mins - https://twitter.com/snapcraftio/status/1118587454821367808
<zyga> Wimpress: mind if I haunt the comment section? :)
<mup> PR snapd#6743 opened: cmd/snap, client, daemon, store: create-cohort <Created by chipaca> <https://github.com/snapcore/snapd/pull/6743>
<Chipaca> pedronis: ^
<Chipaca> and EOD for me
<Chipaca> tomorrow: snapstate cohortitation /o\
<pedronis> mvo: still around?
<mvo> pedronis: yes
<pedronis> mvo: introducing DeviceContext is going well, but I wonder how much you would dislike this change: https://paste.ubuntu.com/p/hzcxF3rCbS/
<pedronis> mvo: needing Model in the bowels of doInstall is a bit annoying/fragile
<mvo> pedronis: looking
<mvo> pedronis: that looks fine
<pedronis> ok, thx
<pedronis> it simplifies some things and avoid some strange effects
<mvo> pedronis: thanks for this - do you have advice for osutil.CommandFromCore for me? iirc you wanted this to go to cmd.CommandFromSystemSnap or something like this?
<mvo> pedronis: yeah, it sounds nice
<pedronis> yes, something in cmd
 * mvo nods
<pedronis> mvo: close to InternalToolPath basically
<mvo> pedronis: will do
<mvo> pedronis: thank you!
<Wimpress> zyga: Thanks for joining us!
<zyga> pleasure to do so, really enjoy this part ;)
<zyga> :)
<Wimpress> :-D
<zyga> jdstrand: I know you are busy but may I interest you with https://github.com/snapcore/snapd/pull/6714
<mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
<mvo> pedronis: hm, we have an import cycle if I move CommandFromCore to cmd
<pedronis> mvo: hm
<mvo> pedronis: snapinfo.go is the problem
<mvo> pedronis: it imports client which in turn imports snap which imports snapfs
<pedronis> blargh
<mvo> pedronis: maybe I can move snapinfo out?
<mvo> it does not fit there much
<pedronis> yes, the problem is that so far we haven't found where to put it either
<pedronis> also we do plan to break snapfs and snap
<pedronis> but dep but not now
<pedronis> s/but dep/dep/
<mvo> pedronis: I could move CommandFromCore into its own cmd/cmdutil pkg?
<mvo> pedronis: together with InternalToolPath maybe
<pedronis> that sounds ok, if we move both, at least temporarely, we really need to find a home for snapinfo.go
<pedronis> but I haven't had time to think one yet
<mvo> pedronis: ok, I will explore this avenue
<zyga> pedronis: do you think you will have time to look at https://github.com/snapcore/snapd/pull/6717 before your holidays
<mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<zyga> pedronis: alternatively, can you defer to mvo for review?
<pedronis> zyga: it's on my list to try to review tomorrow
<zyga> thank you!
<mvo> pedronis: 6741 is now updated, probably does not need your review I tried to follow your guidance
 * mvo -> sleep
<mup> PR snapd#6744 opened: tests: make test parallel-install-interfaces work for boards with pre-installed snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6744>
<mup> PR snapd#6745 opened: tests: make snap-connections test work on boards with snaps pre-installed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6745>
<mup> Bug #1825254 opened: auto-complete doesn't work on ubuntu core 18 <Snappy:New> <https://launchpad.net/bugs/1825254>
<mup> PR snapd#6746 opened: cmd: typedef struct sc_error <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6746>
#snappy 2019-04-18
<mborzecki> morning
<zyga> Hey :-)
<zyga> I still owe you that review
<mborzecki> zyga: hey :) haha
<mborzecki> zyga: heh love how unpredictable our spread runs are
<mvo> hey mborzecki and zyga
<mborzecki> mvo: hey
<zyga> Hey mvo
<pedronis> seems no mup
<pedronis> hi
<pedronis> mvo: hi, https://github.com/snapcore/snapd/pull/6747
<mborzecki> mup_: ping
<pedronis> mvo: read the description as well, hope it makes sense
<mvo> pedronis: yeah, thank you!
<mvo> pedronis: I'm reading it now (but just started only in 3rd file or so)
<pedronis> mvo: TBH, not surprisingly tests were most of the work
 * mvo nods
<pstolowski> morning
<pedronis> mvo: I answered the comment, could you reply?
<mborzecki> zyga: interesting find, on centos, when snapd runs runuser, it somehow triggers keyctl()
<mvo> pedronis: yes, that makes sense
<mvo> pedronis: its more a warning for the future, that makes sense now
<pedronis> mvo: ok, I'll change it, and rewrap a couple of doc comments
<pedronis> which I noticed are bit too long one liners atm
<pedronis> done
 * mvo nods
<pedronis> 3 of my PRs need a 2nd review,  one probably is best to wait of the prereq to land
 * pedronis is going back to do some reviews too
<zyga> mborzecki: keyctl, that's interesting
<mborzecki> zyga: mhm, found that they adjusted the core policy around rhel 6.5 release, to account for logrotate calling runuser too
<zyga> I will be in the office in 20
<mvo> zyga: quick question - does 6717 also addresses the bug 1819318 ? the htop implicit slots/plugs?
<zyga> mvo: one moment, let me look
<pedronis> mvo: yes, I don't think I need to review closely 6741
<zyga> mvo: no, it is not related
<mvo> zyga: ok, trying to understand the remaining blockers
<mvo> zyga: thanks, I understand now I think
<mvo> zyga: so the fix is to install the snapd snap automatically when the first snap gets installed, thats fine
<zyga> I would say the condition is:
<pedronis> mvo: ah, that bug, yes
<zyga> No core snap, no snapd snap, any app snap: install snapd
<zyga> Remember that systems in the field are broken
<mvo> zyga: yes
<mvo> zyga: I think we can do that right after 6741 landed
<mborzecki> zyga: probably interesting for you too: https://github.com/snapcore/snapd/pull/6748
<mborzecki> zyga: still, makes me wonder how / got devpts_t label
<mvo> pedronis: just to double check - for the remodel use-case I just add code to DeviceCtx(.., task, ...) that gets it from the task (and hang it on the right task in devicestate.Remodel() (?)
<zyga> mborzecki: what does -i do?
<mborzecki> zyga: --interpret
<mborzecki> zyga:  tehre's an example in PR description
<mborzecki> (and a commit message too)
<zyga> back now
<pedronis> mvo: not quite like that
<pedronis> mvo: where do you need the info again?
<mvo> pedronis: I think I have ideas now, I can pastebin in 5-10min what I have. I need the info in the mount-snap handler in snapstate
<pedronis> mvo: I still think we should set the model on the change
<mvo> pedronis: my idea was to define "ModelForTask" (similar to ModelFromTask) that adds a new remodelDeviceContext
<mvo> pedronis: aha, ok
<pedronis> mvo: you should not need new helper
<pedronis> s
<pedronis> I did it wrong if you do
<pedronis> you need more code in devicestate
<mvo> pedronis: I was thinking I need a new "remodelDeviceContext" struct and then need to add it as data to task/change, yes?
<zyga> okay
 * zyga checks backlog first
<zyga> then reviews
<pedronis> mvo: yes, you need a remodelDeviceContext correct
<pedronis> mvo: then you need to teach  devicestate.DeviceCtx that if task is passed in
<pedronis> and it's change has  new-model data attr,  to make a remodelDeviceContext
<mvo> pedronis: cool, so I add remodelDeviceContext and change Remodel() to return a change and in the handlers will get the remodel from the change (via DeviceCtx)
<pedronis> mvo: because Install etc also might check model
<pedronis> you also want to make remodelDeviceContext by hand inside Remodel
<pedronis> and pass to Install Update etc
<mvo> pedronis: right
<pedronis> as I explained in the PR description its a simple change
<pedronis> there's an example of what should happen to install for example
<pedronis> we need to do that only for snapstate functions that we plan to use in the remodel
 * mvo nods
<pedronis> mvo: this change will need some kind of unit test though
<pedronis> mvo: when there will be a temporary store as well this changes will also help
<pedronis> together with the changes I will do around the use of snapstate.Store
<mvo> pedronis: indeed
<mvo> pedronis: for my current PR (allow different kernel) I *may* not need to change Install() as we do the checks late in mount-snap if we can install the kenrel or not. I can still change the signtuare or keep it for the initial PR, what do you prefer?
<pedronis> mvo: as you prefer, if you don't do the change please add a TODO at least
<pedronis> though
<mvo> pedronis: thanks, will do - I dive deeper now
<pedronis> (I might have forgotten everything after my vacation ;) )
<mvo> pedronis: heh :)
<pedronis> mvo: I forgot about ifacestate (because it's using directly  devicestate)
<pedronis> mvo: it's actually clear that except some form for tests, devicestate.Device/SetDevice/Model/Serial should go away
<pedronis> as public methods
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1825298
<pedronis> mvo: daemon etc can use the methods on the DeviceManager itself
<pedronis> mvo: to be clear it's not a blocker for your work, just shows there is a bit more to do
<mvo> pedronis: ok, I think we need to add this to a card somewhere
<pedronis> and that some aspects of the old devicestate api is dangerous now
<pedronis> because what is the relevant model is not so a fixed concept
 * pstolowski doh @ get_journal_log
<pedronis> mvo: don't know if noticed but seems we need to increase the timeout on debian-sid-64:tests/main/sbuild
<pedronis> I have seen it fail timing out quite often
<pedronis> https://api.travis-ci.org/v3/job/521593407/log.txt
<pedronis> (maybe is just a symptom, anyway9
<pedronis> Chipaca: degville: some wondering from me that you might consider in my comments to #6669, also Chipaca that one is something for you to review when you have a bit of time
<Chipaca> pedronis: I wasjust about to say
<Chipaca> pedronis: 'expiration' is a date
<Chipaca> not a duration
<pedronis> yes, not a fan
<Chipaca> and obviously it makes no sense for this to be a date
<pedronis> no
<Chipaca> automatic-snapshots.keep ?
<Chipaca> then it could be a duration or "no"
<pedronis> that is too terse
<pedronis> for me
<pedronis> Chipaca: we are trying to get rid of automatic-snapshots
<pedronis> it needs to be snapshots.something
<pedronis> also
<Chipaca> right
<zyga> snapshot.retention
<pedronis> auto-saves-retention=2h or no
<pedronis> would seem ok (a bit clunky but ok)
<pedronis> I don't want to just have retention because it doesn't apply
<pedronis> to other snapshots
<zyga> mmm
<Chipaca> snapshots.auto-saves-retention seems a'ight
<zyga> snapshots.automatic.retention?
<Chipaca> ooh
<Chipaca> schnazzy
<pedronis> nesting
<pedronis> losting
<zyga> losting? :)
<Chipaca> snapshots.automatic.on-removal=no
<Chipaca> :-)
<pedronis> I'm 50/50 whether I want more nesting or not
<zyga> flip a coin
<zyga> I take tails
<pedronis> not today
 * Chipaca watches it land on its edge
<pedronis> no coin flipping before holidays
<Chipaca> shouldn't've used a pound coin
<pedronis> hard rule
<zyga> "god does not throw a coin" said someone, somewhere
<Chipaca> zyga: *play dice
<zyga> I know :D
<zyga> in absence of dies you use dimes ;)
<Chipaca> zyga: clearly einstein was a lousy DM
<pedronis> Chipaca: do we have anything already with two levels?
<Chipaca> yes
<Chipaca> pedronis: service.rsyslog.disable
<Chipaca> pedronis: and ssh, same
<degville> pedronis: Chipaca: ...ah, I've only just seen this discussion :) for some reason my IRC session was stuck a few pages up. Actually, my nick had disconnected.
<Chipaca> degville: the internets. because just simple networks were too reliable.
<pedronis> Chipaca: pstolowski: let's go with snapshots.automatic.retention
<Chipaca> \o/
<zyga> woot
 * zyga helped name something :)
<pstolowski> pedronis: sounds good
<pstolowski> and gives room for more options under "automatic"
<degville> sounds good!
<zyga> mborzecki: looking at the volumes PR again
<mborzecki> zyga: great, thanks!
<zyga> Chipaca: if the string value is relevant then simply explain that
<zyga> Chipaca: my point was that it is a magic string
<zyga> so some context is useufl
<zyga> *useful
<Chipaca> # magic
<Chipaca> zyga: noted
<Chipaca> wait was your comment on the 'snap download --cohort' test done in the create-cohort pr
<zyga> yes
<zyga> I didn't notice there are two
<Chipaca> :-)
<Chipaca> I'm off to do some exercise again, bbiab
 * Chipaca really goes now
<pstolowski> fun fact. the semantics of (some) network errors in Go are different between 16.04 & 18.04 - at least in the case i'm interested wrt to auto-refresh issue :/
<pstolowski> that's the little unexpected dragon hiding there after all
<zyga> mborzecki: sent partial review on gadget validation
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6749 one for you, mainly to check if you agree with the rationale
<zyga> pstolowski: and if you are in review mood, maybe also https://github.com/snapcore/snapd/pull/6717
<pstolowski> zyga: yeah i remember about that one, sorry i didn't get to it yet. it needs full focus
<zyga> pstolowski: no apologies needed
<zyga> the watch is telling me to get up but I sprained my ankle yesterday
<zyga> eh
<mborzecki> zyga: hm the offset thing is inability of current structure to distinguish a case when there's explicit offset:0 and when no offset was set at all, i have a patch for that in another branch, maybe i should include it in the PR
<zyga> please
<mborzecki> zyga: fwiw it's kind of ugly :/ things become pointers and so on
<zyga> yes, unavoidably so
<mborzecki> wish we could do better but not with Go
<zyga> or start to use magic -1 ;)
<mborzecki> haha :P
<zyga> how would we do better?
<mborzecki> zyga: we'd need to have a none like thing
<zyga> that's *exactly* a pointer :)
<mborzecki> well, not exactly, but i won't start that without a glass of beer :P
<zyga> mborzecki: value vs reference but yeah
<zyga> actually beer sounds good regardlesss ;)
<pstolowski> zyga: +1 with one remark
<zyga> pstolowski: thanks
<zyga> just to clarify here before I commit to the code: they are optional in the sense that we don't die on absence of a cookie
<zyga> unless you think that should change
<pstolowski> zyga: no, that is fine; we need to have a clue if that happens, and snapctl should give us one (but that shouldn't happen anymore)
 * pstolowski lunch
<pedronis> zyga: I still dislike the solution in 6117, as did originally
<zyga> hmm?
<zyga> probably wrong PR number
<pedronis> 6717
<zyga> ah
<zyga> because of the public data piece (Scoped)?
<pedronis> yes
<zyga> I can make it private and write a PublicDeepEquals
<zyga> it's really only public because of unit tests
<pedronis> that doesn't sound better
<zyga> hmm
<zyga> so is it the data piece of the access to the data piece that is problematic in your eyes?
<pedronis> zyga: the data, we use Plug/SlotInfo too much as standalone things
<pedronis> also it makes public a semantics detail
<pedronis> of which nothing later should care about afaik
<zyga> hmm, not sure I follow, the standalone aspect is that they are too standlone or?
<pedronis> I still prefer some kind of private maps on Info
<zyga> counterpoint: maps take more memory, this is literally a bit of information (well, a word because go)
<zyga> pedronis: please add a comment to the PR, I can rework it to use private maps if you strongly prefer that
<zyga> though personally I think this is okay, I don't see the risk of storing it this way (I only dislike that it is public)
<pedronis> strictly speaking we don't even need to attach the maps to the struct
<zyga> interesting
<zyga> I think the calling order is a bit unfortunate but with some shuffling I think  you are right
<zyga> perhaps I remember wrong but AFAIR implicit hooks are added in a separate pass at a later stage so we'd have to return the maps to that stage to proceed
<pedronis> infoFromSnapYamlWithSideInfo
<pedronis> is internal
<pedronis> so we can change it's signature
<zyga> yeah
<zyga> I will also explore the idea to load the hooks first
<pedronis> to return a map or take one
<zyga> that would be easier, as the maps would be totally internal
<pedronis> that might be painful I fear
<pedronis> anyway all that code is a bit strange (evolved very organically)
<zyga> I agree :)
<pedronis> and under weird constraints (some we cannot get rid of though)
<zyga> I'm happy to rework it, probably tomorrow because today I need to break for a doctor visit
<zyga> it would be nice to rework to something that uses canonical yaml
<zyga> and a series of passes that transform the input yaml
<zyga> and yaml is used freely here, it's just the yaml* types that we have there
<zyga> load yaml, (processing passes), single analysis pass that reads "canonical form"
<pedronis> we are still trying to fix a bug, not rework the all thing over 3 months
<zyga> yes :)
<zyga> I'm only making a point on how it could be cleaned up from the organic growth
<zyga> we could merge as-is and iterate
<zyga> the bug would be fixed for 2.39
<pedronis> were to we check that a plug and a slot cannot have the same name?
<pedronis> *where
<pedronis> *where do we
<zyga> pedronis: we have a checker for that
 * zyga looks
<zyga> ohh
<zyga> maybe we only do in repo
<zyga> let's check
<pedronis> we shouldn't do it only that late
<pedronis> fwiw
<pedronis> if that's the case
<zyga> plugsSlotsUniqueNames
<zyga> fortunately we do validate early
<cachio> zyga, hey, I found a problem in the test core16-provided-by-core and I think it is realted to ns
<zyga> cachio: tell me
<cachio> zyga, if you run spread -debug -repeat 2 google:ubuntu-core-16-64:tests/main/core16-provided-by-core
<cachio> zyga, it fails the second execution
<cachio> bacause it is not falling back to core
<pedronis> zyga: it's in validate though, so we do it after everything else
<pedronis> anyway that's fine
<cachio> I was debugging this and the problem is about how we reset
<zyga> cachio: how do we reset?
<zyga> cachio: (please tell me all you know)
<cachio> zyga, the reset.sh uninstall all the snaps
<cachio> but core, kernel. etc
<cachio> and then
<cachio> discard all mount namespaces and active mount profiles
<zyga> active mount profiles?
<cachio> zyga, https://paste.ubuntu.com/p/8tW5M7Bcgy/
<cachio> is it doing that
<zyga> ah, the comment is confusing, I understand
<cachio> when I run this it makes the test fail
<cachio> in fact the test is failing master with the same error
<cachio> depending of the tests which run before
<zyga> how does the test fail? do you understand the problem and know what do do about it or are sharing information to get support in fixing it?
<cachio> zyga, I don't really understand why it is happening
<cachio> I took the look to the code and I think it is failing in snap-confine-invocation.c
<zyga> how is it failing?
<cachio> I mean there is where it should fall back to core and it is skipping that part
<cachio> but not sure
<cachio> perhaps you do :)
<zyga> no, I don't
<zyga> that part is never skipped
<zyga> I bet that the problem is indeed in how we reset
<pedronis> zyga: I'm loooking at it myself, I don't think reworking it from the current state should be a lot of work (last famous words)
<zyga> and that if we look at the before / after state (before 1st run, after reset on 1st run) you will see the difference
<zyga> pedronis: +1
<zyga> pedronis: do push if you have a patch, my remark was really only about that it is fixing the bug as-is and it's green; it's certainly something we can rework
<cachio> zyga, ok, I'll add some debug to the code to see if that helps
<zyga> cachio: please do, my recommendation is really to start checking for leftovers
<zyga> if the code fails on 2nd run reliably
<zyga> it is clearly because the environment is no longer the same
<zyga> right?
<cachio> zyga, I suppose that
<cachio> I already compared that
<zyga> what state did you compare and what did you find?
<cachio> and I couldnt detect the diff
<cachio> everything inside /run/snapd/ns/
<zyga> that's not sufficient, the code looks at /snap/*
<cachio> ok
<zyga> my advice is to compare: /snap/* , /var/lib/snapd/* and /run/snapd/ns
<cachio> zyga, I'll compare that too
<zyga> I'm sure that whatever you will surely find will fix not only this test
<zyga> but many others
<cachio> zyga, great
<zyga> cachio: you can also compare /proc/self/mountinfo
<zyga> to see if we are leaking something
<zyga> perhaps also look inside existing mount namespaces, among the set we are not discarding
<zyga> good luck
<cachio> zyga, nice
<cachio> zyga, thanks, I'll continue with this
<zyga> thank you!
<pedronis> zyga: I have the rework, to you want me to push it separately or on the PR ?
<diddledan> ergh. I wish the build.snapcraft.io would tell me why it thinks the yaml is invalid!!
<diddledan> how can I fix it if it won't tell me what's wrong?!
<zyga> pedronis: push it directly there please
<pedronis> zyga: in meetings, but will do, it seems to work nicely, but it was quick hacking so names etc can maybe be tweaked
<zyga> sure
<zyga> thank you!
<cachio> zyga, well I found the problem
<cachio> zyga, well, almost
<cachio> after reset
<cachio> zyga, https://paste.ubuntu.com/p/S25ntst2xQ/
<cachio> core16 is not installed but it remains in /snap
<cachio> zyga, https://paste.ubuntu.com/p/NqdzDvjKVg/
<cachio> I am trygin a fix now
<pedronis> zyga: I pushed it
<mborzecki> zyga: pushed updates to cross structure validation PR
<zyga> pedronis, mborzecki: ack
<zyga> pedronis: I opened trivial https://github.com/snapcore/snapd/pull/6751
<zyga> it's the whole feature sans the tests
<zyga> at +16,-3 it's the smallest feature branch I can recall :)
<zyga> off-topic: being in snap world where releases happen often and when they are ready I find the current craze around 19.04 release oddly quaint :)
<zyga> non the less, time to update
 * Chipaca wanders off
<cachio> zyga, found the issue
<cachio> https://paste.ubuntu.com/p/CwPtSXqcdV/
<zyga> where is that code? in the test?
<cachio> we need to trim the variable when there is just 1 base snap to remove
<zyga> aah
<zyga> heh
<cachio> I added logs to reset.sh
<zyga> I see
<cachio> hehehe
<zyga> how was that not broken?
<zyga> as in, not breaking the execution before
<zyga> is the error ignored?
<zyga> cachio: in any case, super nice find, thank you for chasing this! :)
<cachio> set -e -x
<cachio> I'll fix it
<cachio> zyga, and also I'll add a new pr to print the tree for the state and compare it with the initial one
<cachio> thanks to that I found the problem
<zyga> cachio: please coordinate with Chipaca on that work, he's started this under the invariants theme
<cachio> zyga, yes
<pedronis> pstolowski: I added some comments to your timings PRs
<pstolowski> pedronis: ty
<pstolowski> pedronis: btw are you off tomorrow?
<pedronis> yes
<pstolowski> and then on vacation?
<pedronis> yes, back on April 30
<pstolowski> ok
<zyga> mborzecki: 2nd pass on 6688
<cachio> zyga, this is the fix #6753
<zyga> mvo: https://github.com/snapcore/snapd/pull/6753 needs a 2nd review
 * zyga EODs
<zyga> ttyl everyone
<cachio> zyga, thanks for the review
<cachio> zyga, #6744 updated
<cachio> thanls
 * cachio lunch
<mvo> zyga: thank you
<mvo> a second review for 6720 would be great
<mvo> cachio: I will release 2.39~pre1 to beta hopefully later tonight, its already building in the ppa
<mvo> cachio: can we move the 2.38.1 snapd snap to candidate? or is there more validation required?
<cachio> mvo, my validation is done for 2.38.1
<cachio> I was waiting for cert
<cachio> let me check
<mvo> cachio: ta
<om26er> Hi! Is there someone I could ping here to get that done quickly https://forum.snapcraft.io/t/please-transfer-flatc/10980
<om26er> @popey ^^
<roadmr> om26er: hi I can help
<om26er> roadmr thanks for verification https://github.com/google/flatbuffers/pull/5293#issuecomment-484654914
<roadmr> om26er: a github conversation is super helpful because it lets me verify the recipient's acceptance and identity in addition to verifying your email in github matches your snap store developer email :)
<om26er> roadmr heh, true. I added a comment on the forum :-)
<roadmr> done, om26er â
<om26er> roadmr super! thank you. So what would be the next step here, should I delete the autobuild entry I had created in https://build.snapcraft.io/user/om26er ?
<roadmr> om26er: hm, not very sure about what happens with build.snapcraft.io but I think it would be sane for you to delete it and let upstream set up auto-builds
<zyga> Chipaca: https://eng.uber.com/optimizing-m3/ <- interesting, also in terms of our state engine and memory usage
<om26er> roadmr ok, so if he setups the autobuild, will I be a "collaborator" by default or would he need to add me again ?
<roadmr>         om26er you're already a collaborator, this is set up at the snap store level and is done automatically when a snap is transferred
<roadmr> om26er: as a collab, in principle you could own the auto-build on build.snapcraft.io (you have access to the upstream source, and can publish/release revisions for the snap)
<roadmr> om26er: so in principle, what you have *should* work, but because the ownership changed, maybe the authentication credentials will go stale and you might need to reauthenticate or something
<om26er> roadmr ok, thanks a lot for the help :-)
<roadmr> np, happy to help!
#snappy 2019-04-19
<mborzecki> morning
<zyga> Good morning
<zyga> mborzecki: did you see my second pass review
<mborzecki> zyga: hey
<mborzecki> zyga: yes, i pushed an update with comments
<zyga> Thanks, Iâll look soon
<zyga> Lovely day
<pstolowski> morning
<pstolowski> hey zyga, i'm planning to review your implicit plugs/slots stuff today
<mborzecki> pstolowski: hey
<zyga> pstolowski: thank you
<zyga> pedronis: changed it as well, it looks very good imo
<zyga> Look at patch history please
<pstolowski> ack
<zyga> https://github.com/snapcore/snapd/pull/6740 is short and could help me move snap-update-ns forward
<zyga> pedronis: I noticed that defer is blocked, is there something specific you want me to focus on? I would love to be able to move it forward next week while you are away
<pstolowski> zyga: he is off from today
<zyga> eh
<zyga> not great
<zyga> ok
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6748 ?
<pstolowski> yep
<zyga> pstolowski: hey, can you please look at https://github.com/snapcore/snapd/pull/6740 next
<zyga> pstolowski: and please tell us what to review
<zyga> I think that's all of us today
<zyga> pstolowski: in https://github.com/snapcore/snapd/pull/6755 could you add a Fixes: ... line that references the bug number?
<pstolowski> zyga: it's a private bug
<zyga> that's fine
<zyga> it's only private for now
<pstolowski> ok
<zyga> it will become public once the security aspect expires
<pstolowski> zyga: shall i add it in the code, or PR description only?
<zyga> pstolowski: in the PR commit message please
<pstolowski> k
<zyga>  thanks!
<zyga> jdstrand: hey, is https://github.com/snapcore/snapd/pull/6681 ready for review?
<jdstrand> zyga (cc pedronis and mvo): yes, I made some adjustments to the PR for the investigation yesterday. what remains is a) trying to figure out why spread is failing in:
<jdstrand> 2019-04-19 13:02:27 Error executing google:ubuntu-16.04-32:tests/main/static :
<jdstrand> -----
<jdstrand> + CGO_ENABLED=0
<jdstrand> + go build -o snapd.static github.com/snapcore/snapd/cmd/snapd
<jdstrand> # github.com/snapcore/snapd/overlord/snapstate
<jdstrand> ../../../overlord/snapstate/check_snap.go:433:16: undefined: osutil.FindUid
<jdstrand> ../../../overlord/snapstate/check_snap.go:434:16: undefined: osutil.FindGid
<jdstrand> b) comment updates from pedronis
<zyga> jdstrand: perhaps those are failing because FindUid requires cgo?
<zyga> jdstrand: FYI, I'm off on Monday
<jdstrand> c) more spread tests to verify functionality of the bpf
<zyga> jdstrand: if you have a moment please review 6714
<zyga> jdstrand: did you get to the bottom of the getuid issue?
<zyga> is it a bug in libseccomp or a glibc wrapper confusing the actual syscall?
<zyga> jdstrand: perdonis is off today and next week
<jdstrand> zyga: please see the comment in the PR (I put it all in there)
<jdstrand> zy
<zyga> jdstrand: percfect, I surely will :)
<jdstrand> zyga: so, FindUid is not new and this only started failing within the last couple days
<zyga> hmm
<zyga> odd, perhaps it was not build with CGO_ENABLED=0
<jdstrand> I don't know...
<zyga> but I didn't look, my comment was just a hunch
<jdstrand> this is the function that snap-seccomp uses to resolve u:root
<zyga> jdstrand: snap-seccomp is built with cgo
<zyga> jdstrand: snapd is not
<zyga> jdstrand: you cannot use this function from snapd
<jdstrand> zyga: I literally have to
<zyga> we cannot :/
<zyga> we need a helper to resolve it then
<zyga> a process you can call to give you the value
 * jdstrand sighs
 * zyga is happy at least that part is not mysterious anymore
 * zyga hugs jdstrand 
<zyga> sorry, I know this is painful
<jdstrand> I can call out to getent I guess
<zyga> probably yeah
<jdstrand> or parse /etc/passwd and /etc/group myself
<zyga> jdstrand: that doesn't work
<zyga> jdstrand: you can use go functions for that anyway
<zyga> jdstrand: the real problem is nsswitch.conf
<zyga> and ldap like systems
<jdstrand> the go functions are what are doing this
<zyga> jdstrand: that's why you need to use cgo to use that
<zyga> jdstrand: there's a line where pure go can do simple things
<zyga> like read passwd files
<zyga> and cgo can call the glibc functions that do everything
<jdstrand> zyga: I know that. though for this particular thing, it should really be on the system
<zyga> jdstrand: we chose not to cross that line in snapd
<zyga> jdstrand: then perhaps you just need to use the simple functions and not the osutil ones?
<jdstrand> well, jeez
<jdstrand> the check is to make sure the user/group is available and bail early (an implied 'assumes')
<jdstrand> but it should really behave exactly like what snap-seccomp is doing
<jdstrand> snap-seccomp could move to parsing /etc/passwd and /etc/group
<zyga> jdstrand: (silly Friday idea): call snap-seccomp with setgid g:daemon and parse the word out of the filter ;)
<jdstrand> but that is a bigger change than I want to make
 * jdstrand goes with getent
<jdstrand> heh
<zyga> jdstrand: I think there are builtin go functions that give you that answer
<jdstrand> I think getent will be much cheaper :)
<zyga> *think*
<zyga> not sure
<zyga> you don't need to shell out to getent
<jdstrand> I just googling-- people seem to have packages for it but not a part of the language
 * zyga looks
<jdstrand> hmm, actually, this starting failing when I added the implied assumes most likely. that makes more sense
<zyga> jdstrand: os/user.LookupGroup
<jdstrand> zyga: yes, that is what we are doing
<jdstrand> well
<zyga> then get group.GID if it didn't fail
<jdstrand> we are using LookupUser
<zyga> hold on? are we?
<jdstrand> yes
<zyga> wait, and that doesn't compile?
 * zyga is sceptical now
<jdstrand> os.FindUid uses LookupUser
<zyga> can you do a tiny program that calls LookupGroup?
<zyga> yes
<zyga> LookupUser is old
<jdstrand> LookupUser has always existed in golang
<zyga> LookupGroup is new
<zyga> *new enough for us though
<jdstrand> the test is failing on FindUid
<jdstrand> yes, we stole LookupGroup from newer golang
<jdstrand> and could remove that code
<zyga> FindUid is different
<jdstrand> I was actually planning on doing that in another PR since we now require 1.10
<zyga> I mean
<roadmr> hey folks, what happens if I have a snap named "foo" and then I install a "bar" snap that has an autoalias bar.foo -> foo  ?
<jdstrand> but why is FindUid failing?
<zyga> jdstrand: we can probably drop lookupGroup
<zyga> jdstrand: and just use the plain versions
<jdstrand> zyga: yes, I just said that :)
<zyga> jdstrand: and that will get you out of the issue
<zyga> jdstrand: that is probably the only thing that requires C
<zyga> jdstrand: cool, ping me and mborzecki for review please
<jdstrand> it will get me out of the issue for FindGid, but not FindUid, no?
<zyga> jdstrand: no, why?
<zyga> jdstrand: it's just the "import C" that breaks you
<zyga> drop that from osutil and you are good
<jdstrand> because of what I jus wrote?
<jdstrand> findUid does user.Lookup
<mborzecki> hm had a branch somewhere that drops all C dependant bits from osutil
<zyga> jdstrand: I don't get it then, sorry, can you reprhase?
<zyga> jdstrand: calling user.Lookup is not the problem
<zyga> jdstrand: osutil *does not build*
<jdstrand> the spread test fail because of FindGid *and* FindUid
<zyga> jdstrand: when you disable C
<zyga> at least not that part :)
<jdstrand> ok, not that makes more sense
<jdstrand> now*
<jdstrand> nothing else used group.gp presumably
<mborzecki> jdstrand: https://github.com/bboozzoo/snapd/commit/66e761e11bdb4f29ba279113b20c55d000035fda ?
<jdstrand> let me do a quick PR for that
<jdstrand> mborzecki: so are you saying that FindUid also needs cgo even though it is using user.Lookup?
<zyga> jdstrand: it's one file
<zyga> the whole file gets removed from the build process
<zyga> that's all
<jdstrand> zyga: right, I understand your point
<jdstrand> that makes sense
<jdstrand> but then mborzecki pointed me at https://github.com/bboozzoo/snapd/commit/66e761e11bdb4f29ba279113b20c55d000035fda which stubs FindUid
<jdstrand> when it seems it may only need to stub FindGid
<jdstrand> so I wanted a clarification on that
<jdstrand> since if FindUid also needs cgo, then the LookupGroup fix is valid on its own, but doesn't help me
 * zyga has a new flower pot :)
<jdstrand> I mean, I can just try this out I guess
<zyga> :D
<jdstrand> zyga: anyway, so there a few things to tie up with my PR and I'll be adding more tests, but it is ready for review. you could wait til Tuesday I guess (all my bits should be done then)
<jdstrand> and yes, I plan to look at PRs today
<zyga> jdstrand: cool,
<zyga> jdstrand: I have a few piles of changes for snap-confine pending but I don't want to throw this all at you
<zyga> jdstrand: one thing that was bugging me a while ago was stdlib's IO functions that we cannot use because they apparently suck on error reporting
<zyga> jdstrand: so I wrote my own proof of concept with tests to show what happens in all error cases
<mborzecki> jdstrand: if you want to have cgo enabled, but use non-cgo implementation of os/user bits you'd have to pass -tags osuser (and wit that patch i linked -tags osutil too)
 * zyga is starving
<zyga> time to eat
<jdstrand> mborzecki: that is interesting, but I think a different answer to my question
<jdstrand> mborzecki: I am going to do a PR to use user.LookupGroup
<jdstrand> mborzecki: and remove all the cgo stuff in osutil
<jdstrand> mborzecki: I thought that would fix stuff, but then your commit stubbed osutil.FindUid, that already used user.LookupUser, so I didn't know why you did that one since it was already using the bultin
<mborzecki> jdstrand: that's tricky i think, we'll loose /etc/nss* and probably extrausers too
<jdstrand> I see
<jdstrand> so the builtins don't use nss at all
<jdstrand> we need extra users
<mborzecki> yup, let me point you to the source code
<jdstrand> ok, I think instead of using builtins, I can convert FindUid and FindGid to use getent
<mborzecki> jdstrand: https://github.com/golang/go/tree/master/src/os/user look at cgo_lookup_unix.go and lookup_unix.go
<jdstrand> actually, for this PR, I will probably use LookupGroup. then add a code comment that when we need extrausers, we will need to use getent
<jdstrand> since we don't need extrausers for this now
<jdstrand> but we will later
<jdstrand> passwd:         compat extrausers
<jdstrand> from nsswitch.conf
<jdstrand> ok, this is all clear now
<jdstrand> zyga, mborzecki: thanks
<mborzecki> jdstrand: btw. that also makes calling the os/user bits from snap-exec snap-update-ns bit problematic, as those are built statically via -extldflags=-ldflags=-static, but will still attempt to dlopen the nss bits
<jdstrand> mborzecki: I'm sorry, if I'm using only builtins, what is the problem?
<jdstrand> mborzecki: nothing except snap-seccomp and my PR use FindUid and FindGid
<mborzecki> jdstrand: because builtins only know about /etc/groups & /etc/passwd
<jdstrand> mborzecki: I know. but snap-exec and snap-update-ns don't do lookups... ?
<jdstrand> mborzecki: at least not via these functions. I feel like I am missing your point
<mborzecki> jdstrand: they don't, i stumbled upon this problem when trying to do the mapping for $HOME/snap_<instance> to $HOME/snap with parallel installs
<mborzecki> jdstrand: which we eventually dropped anyway
 * zyga breaks for lunch 
<jdstrand> zyga: fyi https://github.com/snapcore/snapd/pull/6759
<zyga> Back in 10
<zyga> back now
<zyga> jdstrand: the error on https://travis-ci.org/snapcore/snapd/jobs/522179183 is puzzling!
<zyga> jdstrand: as a nitpick, could you please expand the commit message, it's nicer to know _why_ we are doing that not what is being done
<zyga> jdstrand: the error talks about build ID, I would suspect it is caused by lack of cgo now
<zyga> jdstrand: and default build mode that don't inject build-id
<Son_Goku> zyga, any idea from the snap side for this? https://github.com/livecd-tools/livecd-tools/issues/125
<zyga> looking
<zyga> hmm, no idea if we are using livecd-tools anymore
<zyga> it's a distro question
<zyga> for snapd side I can say this
<zyga> you can put seed data on a filesystem
<zyga> then on 1st boot snapd spots the seed and installs the snaps listed there
<Son_Goku> I don't know anything about those things
<zyga> this is done for ubuntu live CD for instance
<Son_Goku> so it'd be handy if you could detail that for this
<zyga> but I don't know anything about livecd-tools
<zyga> I don't know much about this honestly, this is really mvo/chipaca area
<zyga> I can try to ask them after easter
<Son_Goku> livecd-tools just basically uses a kickstart file as input to create live media
<Son_Goku> it's how Fedora and other derivatives of Fedora make media
<zyga> *basically* is what most people would not use :)
<zyga> I don't know how distros do that today
 * zyga (I mean the word basically assumes you know this)
<Son_Goku> I use basically as "simply speaking"
<Son_Goku> sorry
<zyga> no worries :)
<zyga> I'm looking for seeding docs
<zyga> Son_Goku: I answered in the github issue now
<Son_Goku> thanks
<zyga> jdstrand: I commented on https://github.com/snapcore/snapd/pull/6759
<zyga> I'm back to hacking on groups
<zyga> I solved my conundrum
 * zyga begs for review on https://github.com/snapcore/snapd/pull/6714
<zyga> jdstrand: ping
<zyga> jdstrand: my last patch of the day
<zyga> jdstrand: in case you are around I wanted to explain some of the things since you will be probably the only one that _has to_ review it
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6760
<zyga> jdstrand: I'm EODing and EOWing now, please if you have some time left today have a look at  https://github.com/snapcore/snapd/pull/6714 which is the follow-up from the /tmp security issue
 * zyga waves
<sergiusens> zyga: hey, if you are around, mind giving some insight on https://github.com/ChristianPauly/fluffychat/issues/117#issuecomment-484959454 ... I suspect this is a host lacking many services, but have not dug into it and you might know more about it
<zyga> sergiusens: someone has staged real xdg-open and it took priority
<zyga> sergiusens: our xdg-open doesn't use dbus-launch and does not print that output
<zyga> jdstrand: thank you for both reviews
 * zyga started another print and goes to sleep
#snappy 2019-04-20
<sergiusens> zyga: consider that we both run the same snap and did "snap run --shell", if it had been staged, it should be failing for me too
<zyga> sergiusens: I must have misunderstood then; I will check later
<brlin> Found it mildly interesting https://www.irccloud.com/pastebin/TZuveJwP/
<brlin> I need someone to proofread https://forum.snapcraft.io/t/system-options/87#heading--refresh-hold
<zyga> hey brlin
<zyga> how are you doing?
<zyga> brlin: so does refresh hold set the time or a boolean flag?
<zyga> brlin: I think having an example would be useful
<brlin> zyga: It set the time in a certain RFC format AFAICT, I'll craft a example.
<zyga> brlin: thank you
 * zyga is very sleepy today
<zyga> pedronis: the seed is indeed broken
<zyga> pedronis: I poked will cooke with the details
<zyga> pedronis: since it is snapd seeding itself that is affected sending a fixed snapd to the core snap won't help as snapd keeps panicking
<zyga> pedronis: we would need to update snapd via the debian package to address this
<zyga> pedronis: with regards to seed damage: I would suggest that we do ignore nil values and carry on as I implemented
<zyga> this has higher chance of actually working than snapd perpetually erroring on the seed process
<zyga> alternatively desktop should fix the seed file post-install
<zyga> not great 19.04 release though, I hope it's just from alpha images
<luciom> Hello, I am trying to create a snap for gtk-gnutella. This is the script: https://github.com/luciomarinelli/gtk-gnutella/blob/master/snap/snapcraft.yaml the compile runs well, however what I get is an empty snap package. It looks like the "make install" step is not performed. What am I missing?
<brlin> luciom: The part is using custom build script, the autotools plugins specify null prefix and set the DESTDIR to point to SNAPCRAFT_PART_INSTALL by default but that customization won't apply to custom build script.  Replace the build script with equivalent commands (aside from those autotools plugin run for you, which can be triggered by running `snapcraftctl build`) in the override-build scriptlet or reimplement the entire build
<brlin> step entirely
<brlin> s/step entirely/step completely/
<brlin> You may check out what command the autotools plugin are running at the source: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/autotools.py
<luciom> brlin, hello if I remove the override-build part i get the error: "Failed to run 'autoreconf -i' for 'gtk-gnutella': Exited with code 1. Verify that the part is using the correct parameters and try again."
<cmatsuoka> luciom: hi, I didn't see you were here and answered in the forum post
<cmatsuoka> luciom: it seems that gtk-gnutella doesn't like DESTDIR and uses INSTALL_PREFIX instead
<cmatsuoka> luciom: I added a suggestion there
<luciom> cmatsuoka, thanks I just read your forum post, I am going to try it out
<luciom> cmatsuoka, if I add the override-build string you suggest it gives me error "Issues while validating snapcraft.yaml: mapping values are not allowed in this context on line 14, column 21" which refers to the | symbol
<cmatsuoka> luciom: I just tried with this yaml file: https://pastebin.ubuntu.com/p/jVyPBQWckG/
<cmatsuoka> it builds the package, but it still has many runtime libraries missing
<cmatsuoka> luciom: added one more note about SDL to the forum post
<cmatsuoka> I don't think gtk-gnutella needs SDL
<luciom> cmatsuoka, I used your script in pastebin and the process went forward, the snap is no longer empty!
<cmatsuoka> \o/
<luciom> cmatsuoka, it built without errors on my virtual machine, however on spancraft.io still errors: https://build.snapcraft.io/user/luciomarinelli/gtk-gnutella/534538
<cmatsuoka> luciom: I can't see the log, could you paste the error message somewhere?
<cmatsuoka> gotta go, will be back later
#snappy 2020-04-13
<mup> Issue # closed: pc-amd64-gadget#20, pc-amd64-gadget#30, pc-amd64-gadget#36, pc-amd64-gadget#41
<mup> PR pc-amd64-gadget#37 closed: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> Issue # opened: pc-amd64-gadget#20, pc-amd64-gadget#30, pc-amd64-gadget#36, pc-amd64-gadget#41
<mup> PR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<exit70> hi i found some snap packages are incorrectly marked as proprietary
<exit70> https://snapcraft.io/sunwait
<exit70> https://snapcraft.io/mgba
<mup> PR snapcraft#3029 closed: tests: speed up clean command unit tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3029>
<ijohnson> cmatsuoka: cachio_: could y'all take a look at https://github.com/snapcore/snapd/pull/8474 ?
<ijohnson> master seems to still be red
<mup> PR #8474: tests: fix timeserver-control-test <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8474>
<cmatsuoka> ijohnson: sure
<ijohnson> thanks
<cmatsuoka> ijohnson: done
<ijohnson> I will say it is nice that with github actions, it's nice that for spread runs on CI, we only end up racing with ourselves, so even if the rest of the world is having a bad day for CI, our queue is only affected by how many PR's we have open
<ijohnson> so on a quiet day like today, stuff runs instantly without any waiting
<cmatsuoka> I almost locked myself out of my bank account because I was trying to use it with the ubuntu sso 2fa
<zyga> cmatsuoka, ijohnson: hey
<zyga> can I interest you in https://github.com/snapcore/snapd/pull/8482
<zyga> it fixes PRs for master
<mup> PR #8482: tests: rewrite timeserver-control test <Created by zyga> <https://github.com/snapcore/snapd/pull/8482>
<cmatsuoka> zyga: hey zyga! checking that, thanks
<ijohnson> zyga: hmm, looks shiny
<zyga> ijohnson: it's surprisingly able to pass on 14.04+
<zyga> and all systems
<ijohnson> that is impressive
<ijohnson> I was going to just use pawel's PR to unbreak master but this does seem to be the better way to write the test
<ijohnson> I don't want to encourage working on Sunday nights though :-)
<cmatsuoka> I love redef.sh
<zyga> :D
<zyga> did I write redef.sh?
<zyga> it was meant to be defer backwards :)
<cmatsuoka> and the best use for tac I've seen this far
<cmatsuoka> refed
<cmatsuoka> sorry, my dyslexia
<cmatsuoka> I thought refed but I just typed redef automatically :D
<cmatsuoka> zyga: a good one to process in background: what could cause random processes to be killed on a single cpu vm but not when it's configured with a higher smp count?
<zyga> cmatsuoka: a linux process dies on a SMP=n vm that doesn't die otherwise?
<zyga> cmatsuoka: what is the process doing?
<cmatsuoka> sergio reported this behavior, apparently a set of processes including ssh is being killed only when n=1
<zyga> hmm
<cmatsuoka> and it happens when cpu usage hits 100%
<zyga> cmatsuoka: do we know any more, we should get a bug report with whatever kind of way to reproduce it
<cmatsuoka> cachio_: ^^, did I describe it correctly? do you have any further details?
<zyga> please report a bug if you can
<zyga> I'll look
<zyga> (I'm off today)
<cachio> cmatsuoka, zyga I'll report a bug with the information about how we create the instance and how to run the tests so we can discuss it tomorrow
<zyga> super
<cmatsuoka> zyga: you're not very good at being off from what I see :)
<zyga> meanwhile I think master will not be red anymore and everyone can make some progress :)
<the-mentor> hi zyga
<zyga> hi
<the-mentor> any chance to get your help with something ?
<zyga> maybe, what do you need?
<the-mentor> zyga https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378
<the-mentor> if you can take a look i will appreciate it
<zyga> hmmm
<zyga> there are several things here
<zyga> the-mentor: currently many snaps ship userspace hardware drivers
<zyga> the-mentor: mesa and everything it pulls in
<zyga> the-mentor: this is not scalable and we want to stop doing that at some point
<the-mentor> zyga the snaps i'm building do not pull mesa or any userspace drivers
<zyga> the-mentor: another thing is that userspace drivers are not just .so files, as you see here there are various data that are loaded from fixed locations
<zyga> the-mentor: those are scattered all around the FS and are hard to support
<the-mentor> I'm just trying to find a way to get vulkan to work
<zyga> the-mentor: the presence of libvulkan_intel.so in your post seems to counter that
<zyga> the-mentor: the last part is that nvidia handling is a special snowflake
<zyga> the-mentor: it was never meant to last this long
<zyga> the-mentor: we were supposed to replace it by now
<zyga> but that didn't happen
<zyga> now
<zyga> can we do a one-off patch that addresses this specific failure somehow - perhaps
<zyga> but that's not the replacement for the better system where we don't need to perpetually play catch-up
<zyga> the-mentor: I cannot spare any cycles now. I know this is not what you want to hear sadly.
<zyga> the-mentor: after 20.04 and core 20 ships
<zyga> the-mentor: and we have a new allocation for roadmap items
<zyga> the-mentor: we may be able to do it
<zyga> the-mentor: unfortunately this is a huge chunk of work end-to-end
<the-mentor> zyga I appreciate the feedback
<the-mentor> also i think you gave me a few pinpoints to look at
<zyga> the-mentor: unofficially I made some snaps that provide nvidia userspace bits
<zyga> the-mentor: but I didn't even reach vulcan testing
<zyga> the-mentor: one thing that would be really useful
<zyga> is some kind of test payload
<zyga> an app that you can use to verify that various bits work
<zyga> (different versions of opengl, vulkan, etc)
<the-mentor> zyga i think you are right about the snap shipping mesa since i have these so i'll try to remove them and see if it helps
<the-mentor>       ## vulkan
<the-mentor>       - libvulkan1
<the-mentor>       - mesa-vulkan-drivers
<zyga> the-mentor: mesa, nvidia should be snaps
<zyga> the-mentor: this would allow one to make a snap based on core16
<zyga> the-mentor: build it once in 2020
<zyga> the-mentor: and then use it to run on future hardware in 2022
<zyga> the-mentor: without rebuilding on core18, core20 or core22
<the-mentor> zyga make sense as a long term solution
<the-mentor> I'm working on packaging a few wine based games and I see a lot of issues with nvidia which led me down this path
<zyga> I appreciate you are showing us the limitations of our current system
<zyga> we are well aware, I wish we I had the allocation to improvei t
<zyga> *improve it
<the-mentor> zyga i'm sure it will happen eventually
<the-mentor> i was hoping a can snap battle net :D but i guess i'll have to wait a little longer :D
<the-mentor> snaps are amazing and i'm really excited that they even exist
<zyga> the-mentor: note, you could probably use a layout to put nvidia_icd.json in place
<zyga> the-mentor: and that _might_ fix your particular case
<the-mentor> I tried doing it but maybe i didnt do it properly
<zyga> the-mentor: bind-file to /usr/share/vulkan/icd.d/nvidia_icd.json
<zyga> and make sure that at runtime you see libGLX_nvidia.so.0 in $SNAP_LIBRARY_PATH (/var/lib/snapd/lib/gl/*)
<zyga> or maybe /var/lib/snapd/lib/*
<zyga> I forgot the details now
<the-mentor> zyga this is what i tried based on a forum post somewhere https://pastebin.com/wXn4MuAC
<zyga> the symlinks for libraries are not needed
<the-mentor> can you send me the right way if you dont mind ?
<zyga> try with just what I said above
<zyga> just the one item that gives you the json icd
<zyga> make sure you can read if from snap run --shell
<the-mentor> ok i'll try it out and report back
<zyga> that ought to give vulkan a way to know the soname to dlopen
<zyga> then look if you can find that soname from the snap's point of view
<the-mentor> im trying to first build the snap without mesa etc
<zyga> the-mentor: I don't think that's useful for now
<zyga> the-mentor: until the system is in place everyone bundles mesa
<the-mentor> i see
<the-mentor> so just do the bind workaround ?
<zyga> yeah, put the icd file where vulkan wants to see it
<zyga> but honestly, I don't remember the details anymore, you may need to jump through more hoops
 * zyga goes away
<zyga> ijohnson: it was already Monday, no? :-)
<ijohnson> maybe in Australia :-)
<zyga> I think I EODed after midnight
<zyga> But just slightly
<zyga> That test was interesting
<zyga> ijohnson: if you guys land one of the fixes subsequent master PRs should be more less green. There are few random issues still but I wonât touch more today
<ijohnson> zyga: sure I will land things in a bit, debugging uc20 things with cmatsuoka right now
<mup> PR snapd#8482 closed: tests: rewrite timeserver-control test <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8482>
<mup> PR snapd#8473 closed: tests: when restoring chrony do not restart systemd-timesyncd <Test Robustness> <Created by mvo5> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8473>
<mup> PR snapd#8474 closed: tests: fix timeserver-control-test <â  Critical> <Created by stolowski> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8474>
<mup> PR snapd#8480 closed: tests: fix timeserver-control-test for 2.44 <â Blocked> <Created by stolowski> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8480>
<ijohnson> thanks cachio
<ijohnson> cachio: can you merge updated master into 8481?
<cachio> sure
<cachio> ijohnson, 1 minutes
<mup> Issue core20#37 opened: Missing mkfs.vfat, should have tests for mkfs.vfat and mkfs.ext4 existing <Created by anonymouse64> <https://github.com/snapcore/core20/issue/37>
<cachio> ijohnson, done
 * cachio lunch
<ijohnson> thanks cachio
<cmatsuoka> ijohnson: uhm, what was the command line to create a new focal image suitable for qemu-backed spread testing?
<ijohnson> cmatsuoka: it's in the HACKING.md
<ijohnson> cmatsuoka: `autopkgtest-buildvm-ubuntu-cloud -r focal`
<cmatsuoka> ah thanks, I knew I read it somewhere
<ijohnson> afaik it didn't change in focal
<mup> PR snapd#8483 opened: snap-bootstrap: fix partition numbering in create-partitions <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8483>
<cmatsuoka> ijohnson: refactored it a bit more and created the PR above
<ijohnson> nice thanks
<ijohnson> will take a look in a bit
<zyga> re
<zyga> guys can you please make sure 2.44 passes tests?
<zyga> a 8482 variant for 2.44 would be great
<zyga> cachio: not sure if this helps
<zyga> https://github.com/snapcore/snapd/pull/8484
<zyga> cachio: I don't have spread 2 build
<mup> PR #8484: tests: ignore user@12345.service hierarchy <Created by zyga> <https://github.com/snapcore/snapd/pull/8484>
<zyga> can you check if that still fails with the test case you had please
<mup> PR snapd#8484 opened: tests: ignore user@12345.service hierarchy <Created by zyga> <https://github.com/snapcore/snapd/pull/8484>
<cachio> zyga, ahh, let see, but it seems to be ok
<cachio> zyga, thanks!!
<zyga> sure, let me know if it passes please
<zyga> I'm in the office for now, making the space tidy
<zyga> so much dust everywhere
<cachio> zyga, hhehe
<cachio> I'll follow the execution
<mup> PR snapcraft#3033 opened: build providers: do not print network test output for LXD <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3033>
<mup> PR snapd#8485 opened: cmd/snap/debug/boot-vars: add opts for setting dir and/or uc20 vars <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8485>
<mup> PR snapd#8486 opened: bootloader, gadget, cmd/snap-bootstrap: misc cosmetic things <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8486>
<mup> PR snapd#8487 opened: [RFC] gadget, cmd/snap-bootstrap: hack some things into place to get rpi4 semi-working <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<mup> PR snapcraft#3030 closed: repo: drop _AptCache and add migrate to install_stage_packages() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3030>
<mup> PR snapcraft#3033 closed: build providers: do not print network test output for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3033>
<mup> PR snapcraft#3034 opened: repo: add initialize_snapcraft_defaults() to set default source lists <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3034>
<mup> PR snapd#8486 closed: bootloader, gadget, cmd/snap-bootstrap: misc cosmetic things <Simple ð> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8486>
<mup> PR snapd#8488 opened: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8488>
<mup> PR snapcraft#3032 closed: plugins: introduce v2.MakePlugin with rebuilding <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3032>
#snappy 2020-04-14
<mup> PR snapcraft#3035 opened: repo: fix resolution of virtual build packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3035>
<mup> PR snapd#8484 closed: tests: ignore user@12345.service hierarchy <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8484>
<mup> PR snapcraft#3036 opened: travis: use stable channel for building snapcraft snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3036>
<zyga> Good morning
<mborzecki> morning
<zyga> Hey Maciek
<mborzecki> zyga: hey hey
<zyga> Frosty morning
<mborzecki> hm we should package the .3 release
<zyga> Or make .4
<zyga> Letâs wait for mvo
<zyga> I suspect we may do .4
<mborzecki> .4? interesting things happend over the weekend then?
<zyga> Yes
<zyga> Look at my PRs
<zyga> There is one still open IIRC
<zyga> https://github.com/snapcore/snapd/pull/8481
<mup> PR #8481: cmd/snap-update-ns: handle EBUSY when unlinking files <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8481>
<zyga> Back from walk
<zyga> I fixed random failures plaguing master over Easter
<zyga> Hopefully all most common
<zyga> I didnât rebase that important fix though
<zyga> Iâll make coffee and start the day soon
<mup> PR snapd#8479 closed: release: 2.44.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8479>
<zyga> Hey mvo
<mvo> zyga: good morning
<the-mentor> good monring zyga
<zyga> Hey the-mentor
<zyga> mvo: so, I guess I need to ask
<zyga> Do we do a .4
<zyga> Or are we pushing for with .3 and buffer fixes for now
<the-mentor> zyga i tried what you told me yesterday with the bind-file but from within the snap the file seems empty or cant be opened
<zyga> What layout did you specify?
<zyga> Note: you have to add the icd file into your snap for now
<the-mentor> layout:
<the-mentor>    /usr/share/vulkan/implicit_layer.d/nvidia_layers.json:
<the-mentor>      bind-file: $SNAP/usr/share/vulkan/implicit_layer.d/nvidia_layers.json
<zyga> Also note that mborzecki has some knowledge about vulkan and might offer advice
<the-mentor> mborzecki howdy !
<zyga>  Did you try using the same name as you had on your host originally?
<the-mentor> i did
<zyga> Not sure if this is relevant or not
<the-mentor> i'm pointing too the file on the host
<mborzecki> the-mentor: hm? vulkan?
<mborzecki> haven't heard that name in a long time
<the-mentor> mborzecki i'm trying to get vulkan to work in my sanp
<zyga> Note that you have to put the actual file in your snap as well
<the-mentor> since i'm trying to snap a few wine based games
<zyga> On nvidia
<the-mentor> zyga ahh i see but that file might be different depending on the host no ?
<the-mentor> mborzecki seems like vulkan is the new hot stuff in the gaming world so many games work better with vulkan + dxvk
<mvo> zyga: why would we do a .4 again, please remind me
<mborzecki> the-mentor: isn't making sure that nvidia icd.d files are at the right place enough?
<the-mentor>  mborzecki https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378
<the-mentor> check out this post i've made with more info about my issue
<zyga> mvo: to apply the patch fixing microk8s with strict confinement
<mvo> zyga: 8481?
<zyga> indeed
<mvo> zyga: maybe we need a .4 - let me check the bugreport. do people need to enable robust namespace updates to make the fix work? iirc you mentioned yes(?)
<zyga> oh, yes, they would
<zyga> hmm, so that suggest 2.45 instead
<zyga> but I don't know the details on their side, it just seems that if we need to do a .5 it's either now or not at all (because schedules)
<mvo> zyga: yeah, if we need the robust namespace updates it suggests to get on with 45 asap
<mborzecki> the-mentor: try setting VK_ICD_FILENAMES to point it to nvidia icd file and see if that makes vulkaninfo happy
<the-mentor> mborzecki what do you mean ? using bind-file ?
<mborzecki> the-mentor: no, snap run --shell, then probably something like: `VK_ICD_FILENAMES=/var/lib/snapd/hostfs/usr/share/vulkan/icd.d/nvidia_icd.json vulkaninfo`
<the-mentor> mborzecki ok i'll give it a shot
<mborzecki> the-mentor: hmm actually can you check that /usr/share/vulkan/icd.d/nvidia*.json exists inside the snap?
<the-mentor> mborzecki i need classic confinment to access /var/lib/snapd/hostfs right ?
<the-mentor> mborzecki it doesnt
<the-mentor> so i added these layers config to try and make it available
<the-mentor> layout:
<the-mentor>    /usr/share/vulkan/implicit_layer.d/nvidia_layers.json:
<the-mentor>      bind-file: $SNAP/usr/share/vulkan/implicit_layer.d/nvidia_layers.json
<mborzecki> the-mentor: how about /var/lib/snapd/lib/vulkan/icd.d/nvidia*.json?
<the-mentor> mborzecki that exists and has content
<the-mentor> and i can read it from inside the snap
<mborzecki> the-mentor: ok, cool, try running `VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json vulkaninfo` and see if that works
<mborzecki> the-mentor: perhaps it's enough to use layouts to move that file into /usr/share/vulkan/icd.d/
<mborzecki> zyga: do layouts allow using /var/lib/snapd/lib?
<the-mentor> that works
<the-mentor> it ran vulkaninfo properly
<zyga> mborzecki: no
<zyga> mborzecki: you cannot put files there
<mborzecki> zyga: hm i meant to use /var/lib/snapd/lib/ as a source
<zyga> layouts cannot use anything but $SNAP, $SNAP_DATA or $SNAP_COMMON as source
<zyga> a mount profile could use anything
<mborzecki> hmm ok
<mborzecki> the-mentor: so maybe as a workaround you'd need to have a wrapper that globs /usr/share/vulkan/icd.d* and /var/lib/snapd/lib/vulkan/icd.d/* and sets VK_ICD_FILENAMES to the list of all paths that were found
<mborzecki> that or teaching the vulkan loader upstream about directories
<the-mentor> mborzecki i already have a wrapper that launches the wine executable
<mvo> zyga: are you working on the gh action partitioning currently? if not I can do it now
<the-mentor> mborzecki so what should VK_ICD_FILENAMES look like ?
<zyga> mvo: no, not yet
<zyga> mvo: sure, give it a try :)
<mborzecki> the-mentor: https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md#overriding-the-default-icd-usage
<mborzecki> iirc it's file:file:file
<the-mentor> mborzecki i wonder if there is a way to check within the snap what is the graphics driver and only overwrite if its nvidia propriatery
<zyga> mborzecki: since we only have nvidia support via hostfs I would suggest to special case the single nvidia icd file
<zyga> and nothing else
<zyga> after all, there are no other .so files to load
<mborzecki> the-mentor: i think you shouldn't need to, it's up to the loader and specific implementations to check that
<the-mentor> mborzecki would the /usr/share/vulkan/icd.d/nvidia*.json file not exists if the drivers is not installed?
<mvo> mborzecki: can 8464 be merged or does it need changes in the initrmafs first?
<mborzecki> the-mentor: it likely wouldn't but i still think that app should not make assumptions about that, it's up the loader to figure out what's available by trying to load all implementations, find out which work, and give a choice to the vk consumer app
<the-mentor> mborzecki ok let me send you what i'm going to set the VK_ICD_FILENAMES to so i can see if i understand it correctly
<mborzecki> mvo: we're waiting for a fix in initramfs from xnox, there was some dependency problem on thursday where initramfs would stop before switch-root
<the-mentor> mborzecki VK_ICD_FILENAMES=/var/lib/snapd/lib/vulkan/icd.d/nvidia_icd.json:$SNAP/usr/share/vulkan/icd.d/intel_icd.x86_64.json:$SNAP/usr/share/vulkan/icd.d/radeon_icd.x86_64.json
<pstolowski> morning
<mup> PR snapd#8296 closed: httputil/client_test.go: add two TLS version tests <Simple ð> <Skip spread> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8296>
<the-mentor> mborzecki just ran some testing on my system and it seems to know which file to use
<zyga> good morning pawel
<mborzecki> the-mentor: yeah, looks ok to me
<mvo> good morning pstolowski
<mborzecki> the-mentor: let me put some notes in the topic
<the-mentor> mborzecki ill rebuild the snap and see if it works in there. thank you very much for all the help
<mup> PR snapd#8489 opened: github: partition the github action workflows <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>
<zyga> mvo: did you forget to git add?
<mvo> zyga: no, it's still draft, want to make sure the right go version is picked up
<zyga> ah ok :)
<abeato> good morning! What would be the easiest way to get the sign-key-sha3-384 for a key registered by a user in the store?
<pedronis> abeato: do you mean the key that signed the key itself?  that should be the store key
<pedronis> or the hash of the key?
<pedronis> abeato: what do you have as starting point?
<abeato> pedronis, the hash that is used in assertions
<abeato> pedronis, a key registered with snapcraft register-key
<pedronis> abeato: snapcraft list-keys and snap keys shows exactly that under "SHA3-384..."
<abeato> pedronis, I thinka that is public-key-sha3-384, not sign-key-sha3-384, by looking at the account-key assertion
<pedronis> abeato: the sign-key-sha3-384 of a signed assertion matches the public-key-sha3-384 of the signing key
<abeato> pedronis, as a side note, of course the information is in that asssertion, but to get it I had to create an image with ubuntu-image :)
<pedronis> but maybe I still don't understand what you need
<abeato> pedronis, I'd like to get that info to manually craft a system-user assertion
<pedronis> abeato: you need the key to craft an assertion
<xnox> mborzecki:  yes
<abeato> pedronis, I have registered a key, which is shown by:
<abeato>  $ snapcraft list-keys
<abeato> *   labkey        -aWK1CFTXhjR8BpMMplySRp3hRS6AKD8q-mJglQDXxA9-1LknJVV5cEI2pExGj6c
<abeato> I'd like to create a system-user assertion signed by that one
<mup> PR snapd#8490 opened: cmd/snap-bootstrap: no error when not input devices are found <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8490>
<pedronis> snap sign -k labkey
<abeato> so I need to access sign-key-sha3-384
<pedronis> -aWK1CFTXhjR8BpMMplySRp3hRS6AKD8q-mJglQDXxA9-1LknJVV5cEI2pExGj6c is what will end up in sign-key-sha3-384
<pedronis> I don't think it helps you though
<pedronis> you need snap sign -k labkey and the right json input
<pedronis> unless I'm still missing what you are trying to do
<abeato> pedronis, I am trying to create a system-user assertion
<pedronis> snap sign -k labkey
<pedronis> the sign-sha-3-384 is added by the tooling
<abeato> pedronis, ah, got it, so I do not need sign-key-sha3-384 in the json, snap sign does that for me
<abeato> thanks!
<pedronis> yes, same as with model
<abeato> right
<mup> PR core18#98 closed: hooks: add symlinks for snapd's D-Bus configuration files <Created by jhenstridge> <Closed by jhenstridge> <https://github.com/snapcore/core18/pull/98>
<mup> PR core18#150 opened: static: make /etc/dbus-1/session.d writable <Created by jhenstridge> <https://github.com/snapcore/core18/pull/150>
<zyga> small comment there jamesh
<jamesh> zyga: as mentioned in the PR, I think it would probably be harmless to switch to just /etc/dbus-1 in core18 too
<jamesh> zyga: I'd definitely go for /etc/dbus-1 for core20, yeah.
<zyga> I don't know about 18 to be sure (it would be okay after testing)
<zyga> just suggesting that we do it straight away for 20 :)
<jamesh> maybe it's not worth it for core18
<mborzecki> btw. anyoen remember why `snap debug boot-vars` is hidden?
<zyga> nope
<zyga> because we hide stuff left and right?
<mborzecki> zyga: heh, idk ;)
<mborzecki> zyga: heh, idk ;)
<jamesh> zyga: https://github.com/snapcore/core20/pull/38
<mup> PR core20#38: static: make all of /etc/dbus-1 writable <Created by jhenstridge> <https://github.com/snapcore/core20/pull/38>
<mup> PR core20#38 opened: static: make all of /etc/dbus-1 writable <Created by jhenstridge> <https://github.com/snapcore/core20/pull/38>
<pedronis> mborzecki: because it was introduced for our own tests, and never got a extra review/polish pass
<mup> PR snapd#8491 opened: cmd/snap: do not hide debug boot-vars on core <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8491>
<mborzecki> wonder whether pushing the error on classic is too far, one could try to inspect the root directories populated by snap image
<pedronis> mborzecki: should it output = or :
<pedronis> mborzecki: it was hidden not to have to find answers to all these questions
<pedronis> mborzecki: mvo: we are getting failures now in travis with the devel go version
<pedronis> some are obvious, one is not
<mvo> pedronis: looking at it
<zyga> is that go 1.14?
<pedronis> no, it's really devel I think
<mvo> it's annoying, it looks like even --channel=latest/edge is not failing yet
<zyga> maybe not worth testing with devel then
<mvo> (so travis is really ahread)
<mvo> zyga: it's a good question, probably still worth it as it will eventually bite us. but yeah, kind of annoying if it happens out of the blue
<mup> PR snapd#8492 opened: overlord: update tests to work with latest go <Created by mvo5> <https://github.com/snapcore/snapd/pull/8492>
<zyga> mvo: I agree that there's some value in seeing what's on the horizon but I think we have enough things that are flaky; we need to find the right balance
<mvo> zyga: yeah
<pedronis> right now these tests are still required, I mentioned it because the keys one is puzzling/unclear what is going on
<pedronis> the duration ones are trivial if annyoing
<mup> PR snapd#8483 closed: snap-bootstrap: fix partition numbering in create-partitions <Simple ð> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8483>
<pedronis> *annoying
<mup> PR snapd#8461 closed: github: run non-canary if label is present <Run spread> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8461>
<mvo> pedronis: 8492 (go-latest) fixes passes on travis, so should be good
<pedronis> ok, so the key one was a fluke?
<mvo> pedronis: probably
<mvo> pedronis: I don't even remember seeing it on the failure I looked at
<mvo> zyga: I guess there is no "include" in workflows? I was looking into moving the common code out
<zyga> mvo: maybe at yaml level
<zyga> I don't think so
<mvo> mwhudson: hey, I noticed that go/latest/edge was not updated in a couple of days, is that expected?
<mwhudson> mvo: builds have been failing, i haven't looked at why
<mwhudson> mvo: https://launchpad.net/~mwhudson/+snap/go-tip
<zyga> maybe tests are not passing? ;-)
<mwhudson> zyga: it's possible!
<zyga> https://www.irccloud.com/pastebin/kBpBEI5J/
<mwhudson> oh is that the hacks i put in for trusty i wonder
<mvo> mwhudson: aha, that's fine, was mostly wondering if it's known
<mwhudson> hm that wouldn't explain the failures on ppc64el
<mwhudson> mvo: well someone asking makes it more likely that i'll look into it i guess
<zyga> mwhudson: actually the same error is reported on other arhces
<zyga> *arches
<zyga> weird
<mup> PR snapd#8490 closed: cmd/snap-bootstrap: no error when not input devices are found <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8490>
<mvo> mwhudson: heh :) fwiw, we value it as a very useful way to test things
<mvo> (it being go/latest/edge)
<zyga> mvo: hush, don't tell anyone
<zyga> it's our secret!
<zyga> though there's one downside
<zyga> makes you gray quickly
 * zyga ventures into dbus 
<zyga> mborzecki: btw, not sure if you noticed
<zyga> mborzecki: I changed the pulseaudio test on Friday
<zyga> mborzecki: some lessons learned there
<zyga> mborzecki: it needs more love though
<zyga> mborzecki: the restore section is still racy
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8478 ?
<mup> PR #8478: tests: fix racy pulseaudio tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8478>
<zyga> yes
 * zyga is afk
<mborzecki> zyga: heh, yeah, we should probably port the test
<mborzecki> zyga: although masking seems fine now, the test starts its own pulseaudio with a specific config
<mup> PR snapd#8491 closed: cmd/snap: do not hide debug boot-vars on core <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8491>
<the-mentor> mborzecki i'm also seeing this issue
<the-mentor> libGL error: No matching fbConfigs or visuals found
<the-mentor> libGL error: failed to load driver: swrast
<the-mentor> X Error:  GLXBadContext
<the-mentor>   Request Major code 151 (GLX)
<the-mentor>   Request Minor code 6 ()
<the-mentor>   Error Serial #174
<the-mentor>   Current Serial #173
<mup> PR #174: added missing hyphen to autoupdate config example <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/174>
<mup> PR #173: asserts: generate just a couple private keys and reuse them across tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/173>
<the-mentor> any ideas ?
<the-mentor> zyga maybe you know ?
<zyga> re
<zyga> mborzecki: I saw a failure just now where it failed because XDG_RUNTIME_DIR was still busy
<zyga> mborzecki: so some work required on making shutdown not race
<zyga> the-mentor: strace the app, I saw a failure where it looked for an innocent looking file
<zyga> the-mentor: and failed entirely when that file was absent
<the-mentor> zyga strace?
<zyga> the-mentor: it's a PCI ID to driver name mapping file
<ogra> snap run --strace
<zyga> the-mentor: are you familiar with strace?
<the-mentor> no i'm not
<the-mentor> but ill try it out
<zyga> the-mentor: it's a very useful analysis tool, read the manual page but it's generally showing interactions with the system at the system call level
<zyga> the-mentor: so you see which syscalls are executed and if they succeed or not
<zyga> the-mentor: you can use it to see which files are being accessed, for example
<zyga> the-mentor: strace -e openat ls
<the-mentor> zyga ok thats good to know
<the-mentor> zyga how can i filter only open files with the snap strace?
<the-mentor> since its a wine app there is tons and tons of info
<zyga> the-mentor: --strace= is an argument you can pass to snap run
<zyga> you can pass strace options this way
<zyga> you can then use it to filter by system calls that access files such as stat, open etc
<zyga> remember that you have to give the real system call name
<zyga> e.g. openat vs open, 2 or 3 suffixes on some
<zyga> requires some practice to get the right result
<zyga> the-mentor: you can use strace -o to save the result to a file
<zyga> and analyze this way
<zyga> may be easier
<zyga> the-mentor: you can also look for ENOENT error
<zyga> that's something that was searched for but not found
<zyga> should help you find the right things
<the-mentor> ok i'll give it a shot and see what i can find
<the-mentor> i'm happy that the vulkan smoketest now works
<pstolowski> hey cachio
<pstolowski> i've been waiting for you ;)
<cachio> pstolowski, hey
<mborzecki> the-mentor: so vulkan works now, but gl does not yet?
<pstolowski> cachio: hey, see private message
<mvo> cmatsuoka: good morning! I pushed a tiny commit to 8476 to make it build on fedora/debian
<mvo> cmatsuoka: just fyi
<mvo> cmatsuoka: hrm, apparently my push there is somehow incomplete, I took it from the other tpm one, I have a look after lunch (but feel free to push a fix yourself if its something obvious, probably just something with -tags quoting
<mvo> )
<cmatsuoka> mvo: thanks! yeah, I was unsure about cherry-picking your commit from the other PR or just waiting for the other one to land and then merge master to have things automagically working
<cmatsuoka> mvo: I'll check what's wrong and fix it
<mup> PR core20#39 opened: ensure that /host exists <Created by bboozzoo> <https://github.com/snapcore/core20/pull/39>
<mborzecki> mvo: ^^
<pedronis> ijohnson: hi, I'm going to work a bit on #8488 to avoid the back and forth
<mup> PR #8488: bootloader: add efi pkg for reading efi variables <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8488>
<ijohnson> pedronis sure thanks
<ijohnson> And hello again by the way, hope you all enjoyed your long weekend
<mup> PR snapd#8493 opened: If finalrd is available, do not run snapd.system-shutdown service <Created by xnox> <https://github.com/snapcore/snapd/pull/8493>
<mup> PR core20#39 closed: ensure that /host exists <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/39>
<mup> PR snapd#8494 opened: tests: preserve size for centos images on spread.yaml <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8494>
<mup> PR core20#38 closed: static: make all of /etc/dbus-1 writable <Created by jhenstridge> <Merged by xnox> <https://github.com/snapcore/core20/pull/38>
<abeato> mvo, hey, is https://bugs.launchpad.net/snapd/+bug/1872486 under your radar?
<mup> Bug #1872486: snap prepare-image gets confused when the default track is not "latest" <snapd:New> <https://launchpad.net/bugs/1872486>
<the-mentor> mborzecki i think that gl was broken before but yea vulkan works and gl doesnt
<the-mentor> mborzecki i'm adding mesa-utils to the snap so i can get more info
<oSoMoN> jdstrand, you might be interested in https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=82ee1ce51514ee197ee6fd908c9f0af881f1f2ac
<mvo> abeato: thanks, not on my radar yet
<the-mentor> mborzecki looks like glxgears and glxinfo are working as expected
<the-mentor> maybe its related to wine somehow but it looks like i'm not the only one that has these issues
 * zyga -> lunch
<zyga> oSoMoN: interesting
<zyga> oSoMoN: I should talk to you about the snapctl APIs for checking and getting information about updates
<mup> PR core20#40 opened: hook-tests: fix extra files test <Created by bboozzoo> <https://github.com/snapcore/core20/pull/40>
<oSoMoN> zyga, I'd be very interested in those, what IÂ implemented for the chromium snap is only a stop-gap
<mborzecki> mvo: trivial fix for issue that jamesh spotted ^^
<mup> PR snapcraft#3036 closed: travis: use stable channel for building snapcraft snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3036>
<mup> PR core20#40 closed: hook-tests: fix extra files test <Created by bboozzoo> <Merged by xnox> <https://github.com/snapcore/core20/pull/40>
<ijohnson> abeato: mvo: I confirmed https://bugs.launchpad.net/snapd/+bug/1872486 and assigned it to pedronis, perhaps it should go to someone else, but it does seem to be a bad bug for building images
<mup> Bug #1872486: snap prepare-image gets confused when the default track is not "latest" <snapd:Triaged by pedronis> <https://launchpad.net/bugs/1872486>
<mup> PR pc-amd64-gadget#42 opened: Hide menu by default <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/42>
 * cachio afk
<zyga> oSoMoN: I'll do my best to be able to give you those in the next few weeks
<oSoMoN> zyga, excellent, I'm looking forward to it
<mvo> ijohnson: thanks
<mup> PR core20#41 opened: 001-extra-packages.chroot: add dosfstools to get mkfs.vfat <Created by anonymouse64> <https://github.com/snapcore/core20/pull/41>
<mup> Issue core18#151 opened: Please set templates on issues & PRs requring links to core20 issue & PR <Created by xnox> <https://github.com/snapcore/core18/issue/151>
<mup> Issue core20#37 closed: Missing mkfs.vfat, should have tests for mkfs.vfat and mkfs.ext4 existing <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/37>
<mup> PR core20#41 closed: 001-extra-packages.chroot: add dosfstools to get mkfs.vfat <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/core20/pull/41>
<mup> PR core20#42 opened: drop `unminimize` instructions that are not applicable on Core <Created by xnox> <https://github.com/snapcore/core20/pull/42>
<mup> PR core18#149 closed: hooks/motd: cleanup dangling symlink, fix typo <Created by bboozzoo> <Merged by sil2100> <https://github.com/snapcore/core18/pull/149>
<abeato> ijohnson, thanks - it can certainly be a problem when including snaps in required-snaps. Being able to set the track in the model would help
<jdstrand> oSoMoN: cool!
<mup> PR snapd#8492 closed: overlord: update tests to work with latest go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8492>
<mvo> cmatsuoka: I pushed a fix to 8476 for debian-sid
<mvo> cmatsuoka: it's a bit ugly but *shrug*
<cmatsuoka> mvo: thanks!
 * zyga takes a break for coffee
<zyga> testing dbus is not fun
<zyga> or
<zyga> it will be fun when it's easy
 * zyga fails and EODs
<zyga> oh well
<zyga> tomorrow will be better
<mup> PR snapcraft#3035 closed: repo: fix resolution of virtual build packages <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3035>
<mup> PR snapcraft#3037 opened: plugins: introduce v2.CMakePlugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3037>
<pedronis> cmatsuoka: ijohnson|lunch:  updated #8488
<mup> PR #8488: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8488>
<cmatsuoka> pedronis: thanks!
<mup> PR snapcraft#3038 opened: travis: add and ship a self-hosting build of snapcraft <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3038>
<mup> PR snapcraft#3039 opened: build providers: setup initial apt source configuration <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3039>
<mup> PR snapd#8495 opened: cmd/snap-bootstrap: specify a 512-bit key size for the LUKS2 container <Created by chrisccoulson> <https://github.com/snapcore/snapd/pull/8495>
<cachio> xnox, hey
<cachio> I see this lines in journal log when a vm with secure boot is killed
<cachio> xnox, Apr 14 18:09:41 apr141722-614284 kernel: kvm [61215]: vcpu0, guest rIP: 0xffffffffb72788b4 disabled perfctr wrmsr: 0xc2 data 0xffff
<mup> PR #14: Bugfix/lp1488114 import msg <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/14>
<cachio> any idea how to get any extra information about the error?
<mup> PR snapcraft#3040 opened: V2 autotools plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3040>
<mup> PR snapd#8493 closed: data/systemd: do not run snapd.system-shutdown if finalrd is available <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8493>
<mup> PR snapcraft#3038 closed: travis: add and ship a self-hosting build of snapcraft <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3038>
<cmatsuoka> cachio: I moved my test that depends on tpm to main/nested/classic and it was successful
<xnox> cachio:  read kernel source code? increase kernel verbosity of messages for the kvm module?
<xnox> cachio:  chat with kvm maintainers ie. #ubuntu-server / cpaelzer etc?
<cachio> xnox, ok, I'll do taht
<cachio> cmatsuoka, nice
<cmatsuoka> cachio: but wait, it also worked when it was not supposed to so the result is still inconclusive :)
<roadmr> you just need a boolean negation then, right?
<cachio> cmatsuoka, ok
<cmatsuoka> I just want my tests to fail! they're all passing
<cachio> cmatsuoka, do yo uwant to share the test?
<cmatsuoka> cachio: I'm updating them, some changes in key encryption
<cachio> cmatsuoka, nice, just ping me if you need any help
<mup> PR snapcraft#3041 opened: V2 python plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3041>
<mup> PR snapd#8496 opened: interfaces/apparmor: use differently templated policy for non-core bases <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8496>
<jdstrand> kenvandine: fyi, ^
<mup> PR snapd#8497 opened: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8497>
<mup> PR snapd#8498 opened: run-checks: use consistent "Checking ..." style messages <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8498>
<cmatsuoka> ijohnson: still there?
<kenvandine> jdstrand: awesome!
#snappy 2020-04-15
<ijohnson> hey cmatsuoka what's up
 * ijohnson is mostly there he thinks
<cmatsuoka> hmm I forgot what I was going to say
<cmatsuoka> anyway
<cmatsuoka> I see many test failing because pi-kernel is not available, do you know what happened there?
<ijohnson> cmatsuoka: hmm could be store outage
<ijohnson> cmatsuoka: I can see the pi-kernel on my arm64 machine now
<cmatsuoka> ijohnson: could you try to download the snap?
<ijohnson> let me try
<ijohnson> cmatsuoka: you need to specify a channel, there is no latest channel on the pi-kernel
<cmatsuoka> ah I see
<ijohnson> if you do `snap download pi-kernel --channel=20/edge` it works
<ijohnson> but just `snap download pi-kernel` won't work
<cmatsuoka> but did that change recently?
<ijohnson> cmatsuoka: hmm don't think so
<cmatsuoka> because some old tests started to fail
<ijohnson> hmm did you check the full snapd service logs?
<ijohnson> the spread tests will always do verbose HTTP logging for when they talk to the store
<ijohnson> so you should see some 400s or 500s if the store was having a fit
<cmatsuoka> let me see...
<cmatsuoka> ijohnson: https://github.com/snapcore/snapd/pull/8495/checks?check_run_id=587219964
<mup> PR #8495: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <https://github.com/snapcore/snapd/pull/8495>
<cmatsuoka> ijohnson: maybe you can see something there that could tell us what's happening
<cmatsuoka> oh it's in prepare-image
<ijohnson> cmatsuoka: yeah looks like store having a fit
<ijohnson> https://www.irccloud.com/pastebin/6ZKFXKKS/
<ijohnson> store responded with 429
<mup> PR snapcraft#3037 closed: plugins: introduce v2.CMakePlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3037>
<cmatsuoka> too many requests
<cmatsuoka> pft, ok
<cmatsuoka> do you know when it resets the request counter?
<ijohnson> cmatsuoka: just restart the test, it's usually temporary
<cmatsuoka> ok good, thanks, will do that
<ijohnson> np
<mup> PR snapcraft#3042 opened: repo: minor debug log tweaks <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3042>
<mup> PR snapcraft#3034 closed: repo: add initialize_snapcraft_defaults() to set default source lists <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3034>
<mup> PR snapcraft#3040 closed: V2 autotools plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3040>
<mup> PR snapcraft#3042 closed: repo: minor debug log tweaks <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3042>
<jamesh> cjp256: I've updated PR 3031 to use a custom parameter type.  Let's see how that goes.
<mup> PR #3031: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3031>
<mup> PR snapd#8499 opened: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>
<mborzecki> morning
<zyga> Good morning
<mvo> good morning zyga
<zyga> How are you guys
<zyga> Hopefully today I will make progress on dbus
<mborzecki> zyga: mvo: morning guys
<mborzecki> have you seen https://github.com/snapcore/snapd/pull/8496 ?
<mup> PR #8496: interfaces/apparmor: use differently templated policy for non-core bases <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8496>
<mborzecki> supper happy this is moving forward
<mvo> good morning mborzecki
<zyga> mborzecki: not yet
<zyga> but we talked about this in Toronto
<pstolowski> morning
<zyga> hey pawel :)
<mborzecki> pstolowski: hey
<mborzecki> hhm trying to investigate the context deadline exceeded thing that happens in our tests randomly https://paste.ubuntu.com/p/zr6fNXMMbf/
<mborzecki> but looking at go stdlib side, the whole timeout detection in http.Client.do() looks quite brittle
<mborzecki> heh `time.Now().After(deadline)` heh if this is true then Client.do() returns httpError{timeout:true} otherwise it's urlError
<pedronis> mvo: hi
<mvo> pedronis: hi
<pedronis> mvo: #8489 is all green but of course the required things don't exist there, it needs reviews and you will have to land it manually I suppose
<mup> PR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>
<pedronis> mborzecki: zyga:  ^ needs reviews
<zyga> mm
<mvo> pedronis: yeah, it does not have review, once it does I can land it manually and adjust the required things in the settings
<pedronis> zyga: do you noticed/know why it seems we don't get the tooltip/panels with the detected error lines anymore?
<zyga> yeah, I noticed
<zyga> I was looking at why just now when looking at this diff
<zyga> I think            echo "::add-matcher::.github/spread-problem-matcher.json" needs to be in an earlier step
<zyga> or there's a typo
<pedronis> but it happens  not only here
<pedronis> also weirdly enough the emails I get have the count
<zyga> hmm
<pedronis> mvo: could you land #8488, it failed on the store in one test,  it will unblock various other PRs
<mup> PR #8488: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8488>
<mvo> pedronis: sure, will do
<mvo> pedronis: meh, I had no idea how annoying efi vars are :(
<mvo> pedronis: anyway, landed
<mup> PR snapd#8488 closed: bootloader: add efi pkg for reading efi variables <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8488>
<pedronis> mvo: thank you, I will pick up now Claudio's #8463
<pedronis> now
<mup> PR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>
<mvo> zyga,pedronis: re, looks like network is a bit unstable today, did I miss anything in the last 20min
<zyga> mvo: I'm doing a review of your actions patches
<zyga> mvo: hopefully nothing else
<pedronis> mvo: I updated #8463 if you want to double check my changes
<zyga> mvo: https://github.com/snapcore/snapd/pull/8489#pullrequestreview-393570583
<mup> PR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>
<mup> PR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>
<jamesh> Are updates to core20/edge held up for manual review?
<mup> PR snapd#8498 closed: run-checks: use consistent "Checking ..." style messages <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8498>
<mborzecki> omg that github workflow PR, wish we didn't need to have this hack
<mvo> mborzecki: you mean the amount of duplicated code?
<mvo> mborzecki: that is very sad indeed
<mborzecki> and the full workflow name appears in the jobs list :/
<mborzecki> and it's controlled by repo level switches :/
<mborzecki> and it's all duplicated
<mborzecki> mvo: a clever hack nonetheless ;)
<mborzecki> feels like gh actions are half baked atm
<mvo> mborzecki: yeah, I wish we had yaml ancors or anything really
<jamesh> rustup generates their workflows from parameterised source yaml files
<mborzecki> jamesh: but it's done offline right?
<mborzecki> or is there an action that does that? :)
<jamesh> mborzecki: yes.  The generated workflows need to be committed to git
<mborzecki> we still need the dependency on the unit tests
<mborzecki> (even if we were to split workflows per spread ssytem)
<zyga> mvo, mborzecki: jobs and steps can have a name and an ID
<zyga> we can keep the ID as is but give it a shorter name
<zyga> brb
<mup> PR snapd#8500 opened: httputil: fix client timeout retry tests <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8500>
<mborzecki> shoud help with random failure in httputil retry tests ^^
<mborzecki> still a mess, but nothing we can do, especially when sticking to older go versions
<mborzecki> mvo: zyga: so a silly thought about gh actions, what if we just accept to run the unit tests more than once, and run it on the target system if possible (eg. via a docker container and whatnot) or a reasonmable default eg 18.04
<zyga> mborzecki: that's what mvo did, no?
<mborzecki> zyga: i mean workflow per spread system
<zyga> yeah
<zyga> as for running them only in spread
<zyga> I disagree
<zyga> that's somewhat slower and much more costly
<zyga> but we can just try
<mvo> mborzecki: you suggest one workflow per spread system and each workflow would have the unit tests first?
<pedronis> I think we should try to live with a setup for a bit, after mvo split lands, before making other changes
<zyga> yeah
<pedronis> we are really blocked at the moment by everything being red and and needing full re-run or mvo override
<zyga> I would only make cosmetic tweaks (names) so that it's nicer on a PR page
<mvo> or we land it and do cosmetic tweaks in the followup :)
<mvo> ?
<mvo> (it still needs a +1)
<zyga> yes totally
 * zyga checks the comments
<mborzecki> mvo: yes, the unit test could run in a docker container of the target system or some known default if there's none or just run the spread unit test job on the target system separately first
<pedronis> that seems it would slow down things
<pedronis> anyway it all sounds more work than we can afford atm
<mborzecki> the downside it it'd obviously take longer, the upside is that unit tests would run on more systems where they happen o fail sometimes when mocking is lacking
<mborzecki> but you can also restart workflows :P
<mvo> mborzecki: we run the unit tests in spread on the target too (tests/unit/go)
<pedronis> this all sounds a discussion to have at the earliest in 3 weeks
<pedronis> tbh
<mvo> the trade-off is unit tests first or the risk of spinning up 50 machines that all fail
<zyga> FYI: I scaled down my deployment to 7 nodes (currently busy) to force some traffic onto canonistack instances
<zyga> if something falls over I will scale back up
<mborzecki> hmmm could we cache the job results somehow?
<zyga> https://github.com/snapcore/snapd/pull/8489#pullrequestreview-393621491
<mup> PR #8489: github: partition the github action workflows <Created by mvo5> <https://github.com/snapcore/snapd/pull/8489>
<zyga> mborzecki: yes
<mborzecki> as in, cache the result of unit tests or individual spread tests
<zyga> mborzecki: we could
<zyga> mborzecki: that's actually pretty brilliant
<mborzecki> and then skip those jobs when workflow restarts?
<zyga> mborzecki: if sha matches and is green
<zyga> just go ahead :)
<mvo> oh, that's interessting
<zyga> we could use the cache action for that
<zyga> mvo: https://github.com/snapcore/snapd/pull/8489#pullrequestreview-393621491
<mup> PR snapd#8489 closed: github: partition the github action workflows <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8489>
<zyga> mborzecki: can you merge master or rebase https://github.com/snapcore/snapd/pull/8500
<mup> PR #8500: httputil: fix client timeout retry tests <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8500>
<zyga> mborzecki: it will need the new checks to pass anyway
<zyga> mborzecki: and I want to use it as a guinea pig
<mborzecki> haha ok
<zyga> with a bit of luck canonistack workers will now pick it up
<mborzecki> hmm Error restoring google:ubuntu-18.04-64:tests/completion/ (apr150717-345956) : read tcp 10.113.57.178:48146->35.229.25.208:22: read: connection reset by peer
<mborzecki> did we run out of some quota on gce?
<zyga> no, probably my fault
<zyga> let's wait for 20 minutes to see if the new setup works
<mup> PR snapd#8494 closed: tests: preserve size for centos images on spread.yaml <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8494>
<zyga> mborzecki: we should figure out caching for "go test"
<zyga> 7 minutes of each run is there
<mup> PR snapd#8495 closed: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8495>
<mborzecki> ehh more of that `Error restoring google:ubuntu-20.04-64:tests/main/parallel-install-services (apr150717-996191) : read tcp 10.113.57.84:36100->34.74.8.8:22: read: connection reset by peer`
<zyga> we are mow using canonistack as well as my "cloud"
<zyga> 6 workers but hopefully with way better network
<zyga> we have enough memory and CPU load is low
<zyga> and network is much faster actually
<mborzecki> hmm https://github.com/snapcore/snapd/pull/8499 wat?
<mup> PR #8499: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>
<zyga> hmmm?
<zyga> mborzecki: maybe he has a github repo
<zyga> we can send a PR with a response
<zyga> / thank you for this comment
<mborzecki> it's probably some weird snap that produces lots of data in $SNAP_DATA or somesuch
<zyga> mborzecki: lol
<zyga> he made a typo
<zyga> so we didn't waste money "testing" that PR
<zyga> mvo: I guess that's one for you to handle
<zyga> mvo: https://github.com/snapcore/snapd/pull/8499
<mup> PR #8499: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <https://github.com/snapcore/snapd/pull/8499>
 * mvo is in a meeting
<zyga> brb
<mborzecki> damn, error: cannot download snap "pi-kernel": no snap revision available as specified
<mborzecki> keeps repating
<mborzecki> weird, why it's using 20-pi3/edge while xnox's xnox-core-20-pi-arm64.model is using 20/edge
<mvo> mborzecki: yeah, I think the kernel team did something to "pi-kernel"
<pedronis> I think 20-pi3 doesn't exist anymore
<mborzecki> xnox: do you know whether we should be using 20/edge for pi kernels now?
<pedronis> also why are we 20 there ?
<pedronis> we using 20 there?
<mvo> oh, funny "pi-kernel" has no latest track anymore
<mvo> so snap info pi-kernel gives no reply
<mborzecki> pedronis: this is what we're using https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/developer1-pi-uc20.model.json
<pedronis> I think that's broken now
<mborzecki> ok, the official (?) model ubuntu-core-20-pi-arm64.model is using 20/stable, so 20/edge is ok right?
<pedronis> mborzecki: yes
<pedronis> I think so
<xnox> mborzecki: please stop using that, and instead use canonical signed dangerous model that is now available from models repo & from assertions service.
<mup> PR snapd#8501 opened: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8501>
<xnox> 20/edge is the way to go
<mborzecki> xnox: thanks!
<pedronis> that's our own prepare-image tests
<ogra> xnox, a post on the forum would be really nice (where to find models etc) ... though probably post-release
<ogra> so our customers can start rolling their own core20 imgs
<xnox> ogra:  no =) nobody shall find out anything about core20 ever.
<ogra> haha
 * xnox giggles
<pedronis> mvo: for latest you need pi2-kernel I think, pi-kernel is 18/20 only afaict
<zyga> cachio: hey
<zyga> cachio: around? :)
<mup> PR snapd#8502 opened: github: try caching test results <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8502>
<mborzecki> zyga: ^^
<zyga> yeah, noticed :)
<mborzecki> zyga: poor man's test result cache
<cmatsuoka> zyga: hey
<zyga> mmm
<zyga> what's up :) ?
<cmatsuoka> zyga: are you aware of snap-confine-undesired-mode-group errors in fedora? or are these fixed already in master?
<zyga> cmatsuoka: can you show me the log please
<cmatsuoka> sure, just a sec
<zyga> cmatsuoka: there's one thing in master that is fixing the only known, to me, failure of this test
<cmatsuoka> https://github.com/snapcore/snapd/pull/8495/checks?check_run_id=587546789
<mup> PR #8495: cmd/snap-bootstrap: switch to a 64-byte key for unlocking <UC20> <Created by chrisccoulson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8495>
<zyga> yes
<zyga> this is fixed in master
<cmatsuoka> excellent, thanks!
<pedronis> cmatsuoka: hi, I worked a bit on #8463, it should be ready to land I think, but it's very red (for various reasons)
<mup> PR #8463: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>
<cmatsuoka> pedronis: I just checked it, thanks for the fixes/improvements
<pedronis> cmatsuoka: Chris asked you to review: https://github.com/snapcore/secboot/pull/46
<mup> PR secboot#46: Make SealKeyToTPM enforce a key size of 64-bytes <Created by chrisccoulson> <https://github.com/snapcore/secboot/pull/46>
<cmatsuoka> ack
<mup> PR snapcraft#3039 closed: build providers: setup initial apt source configuration <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3039>
<mborzecki> mvo: can you use your superpowers and merge https://github.com/snapcore/snapd/pull/8501 ?
<mup> PR #8501: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8501>
<mvo> mborzecki: sure
<mborzecki> mvo: thanks!
<mup> PR snapd#8501 closed: tests/lib/assertions/developer1-pi-uc20.model: use 20/edge for kernel and gadget <Test Robustness> <UC20> <â  Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8501>
<mvo> mborzecki: does 8476 look ok otherwise (beside this one point you made there)
<zyga> ok, I can now turn off my home server
<zyga> we have 38 workers in two locations
<roadmr> zyga: maybe you can lease some DC capacity from StÃ©phane :)
<zyga> roadmr: that's an interesting idea
<zyga> mvo: ^ we probably could :)
<mup> PR snapd#8476 closed: secboot: add tpm support helpers <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8476>
<mvo> zyga: heh, interessting
 * zyga breaks for lunch
<mup> PR snapd#8481 closed: cmd/snap-update-ns: handle EBUSY when unlinking files <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8481>
<mup> PR snapd#8485 closed: cmd/snap/debug/boot-vars: add opts for setting dir and/or uc20 vars <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8485>
<zyga> thank you mvo!
<pedronis> cmatsuoka: not really urgent but we should probably merge secboot_tpm.go and tpm.go at some point, they are not big, it's not very clear what each does. the other option is to rename secboot_tpm.go to something else
<mup> PR snapd#8500 closed: httputil: fix client timeout retry tests <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8500>
<ijohnson> zyga: so is robust mount namespace updates already enabled by default on master ?
<cmatsuoka> pedronis: agree, I considered that myself when moving tpm.go to secboot but decided to propose that later to avoid changing too much in a single step
<zyga> ijohnson: yes it is
<ijohnson> nice
<zyga> ijohnson: 2.45 will have it
 * zyga is partially away, prepping food 
<pedronis> ijohnson: cmatsuoka: I did some digging about the SecureBoot variable
<cmatsuoka> pedronis: ah interesting, any new finding?
<pedronis> cmatsuoka: see the PR comments
 * cmatsuoka checks
<zyga> hmmmm
<zyga> did canonistack just die?
<roadmr> deadstack
<zyga> hmm
<zyga> not sure what happened
<mup> PR snapd#8453 closed: [RFC] travis.yml: re-enable travis <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8453>
<ijohnson> pedronis: #8497 is ready again
<mup> PR #8497: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8497>
<pedronis> ijohnson: I was in meetings, looking now
<ijohnson> thanks
<pedronis> ijohnson: commented
<ijohnson> pedronis: do you want a separate PR/rebase to extract just the change for https://github.com/snapcore/snapd/pull/8497#discussion_r408941648 ?
<mup> PR #8497: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8497>
 * zyga settles for quiet work
<pedronis> ijohnson: maybe yes, I would expect a test change for it in some form
<ijohnson> pedronis: ok, fwiw that was changed in the PR that's open
<ijohnson> that will be easy to extract out though
<mup> PR snapd#8503 opened: boot/bootstate20: fix bug in try-kernel cleanup <Bug> <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8503>
<ijohnson> pedronis: broken out as ^
<pstolowski> mvo: i've pushed my early config test to https://github.com/stolowski/snapd/tree/core18-early-config
<jdstrand> sil2100 (cc mvo): hey, the core20 snap is failing with https://paste.ubuntu.com/p/DrhfhjWG9y/. can you confirm this is ok or not?
<pstolowski> mvo: to run it: google-nested:ubuntu-18.04-64:tests/nested/manual/core-early-config
<cmatsuoka> cachio: unfortunately we still need sb enabled to be able to run the full encryption test
<cmatsuoka> cachio: error: cannot seal the encryption key: cannot store encryption key: cannot add EFI secure boot policy profile: cannot compute secure boot policy digests: the current boot was performe
<cmatsuoka> d with secure boot disabled in firmware
<jdstrand> sil2100 (mvo): I'm going to approve it to unblock the queue, but please look into it
<mvo> pstolowski: thanks, in a meeting right now, will have a look once that is over
<cachio> cmatsuoka, is that on classic?
<pedronis> ijohnson: thanks, it wasn't clear that the calls number where not a consquences of some of the refactorings
<mvo> jdstrand: thanks, problably https://paste.ubuntu.com/p/DrhfhjWG9y/ is something for xnox to review
<ijohnson> pedronis: yes the refactor actually exposed the bug :-)
<cmatsuoka> cachio: mm, yes, the test is supposed to run on classic
<cachio> cmatsuoka, ok, I'll take a look
<xnox> mvo:  can you explain that output?
<cmatsuoka> cachio: thanks, I'll run a few more tests here and will be back after lunch
<cachio> cmatsuoka, just first let me finish the tests changes I did
<cachio> could you give me a link to your tests?
<xnox> mvo:  i.e. these files were removed from .deb's in focal, and hence new revisions of core20 snap don't have them......
<mvo> xnox: jdstrand runs a tool that compares the files from one base to the next base and when stuff is removed it alerts and blocks the snap
<ijohnson> mborzecki: around?
<xnox> mvo:  why are you asserting contents of .deb's that are part of core20 snap?
<cmatsuoka> cachio: yes, of course. I'm running the test with PR #8409
<mvo> xnox: I don't, the store-review-tools do
<mup> PR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>
<mvo> xnox: it's there to ensure that bases are stable and drop support
<xnox> jdstrand:  those files are dropped in focal, despite equivalent functionality still present.
<xnox> jdstrand:  you should see new added files, like subiquitycore/palette.py
<xnox> jdstrand:  and that systemd-timesyncd is now a standalone package, which is included.
<jdstrand> xnox: ack, that's fine. thanks!
<jdstrand> xnox: just wanted to make sure it was intentional
<xnox> jdstrand:  it was =)
<xnox> jdstrand:  if you have questions like these in the future, core20 bug tracker is on github snapcore/core20 issues
<xnox> jdstrand:  or foundations-crew@lists.canonical.com as foundations owns/builds core20
<cachio> cmatsuoka, nice, I'll take a look after lunch as well
<jdstrand> xnox: right, that is why I pinged sil2100, but I can change the workflow
<xnox> jdstrand:  he mostly deals with "stable" like core18 / core16
<xnox> jdstrand:  core20 will be dead to me next thursday! and onto bootstrapping core22
<jdstrand> xnox: heh, so should foundations-crew@lists.canonical.com be used for core16 and core18?
<sil2100> I like how xnox said "stable" ;)
<jdstrand> mvo: ok, so core20 revisions are now passing automated reviews again and should be caught up in a few minutes
<xnox> jdstrand:  yes you can. foundations-crew@ is one stop shop for core snaps, subiquity, netplan, etc.
<jdstrand> ok, thanks
 * cachio lunch
<jdstrand> xnox: that list is internal only, right?
<xnox> jdstrand:  yes.
<mvo> cmatsuoka: looks like 8463 is ready to land but one core20 test is failing, i.e. google:ubuntu-core-20-64:tests/core/basic20, could you please disable this part of the test and/or move to nested (if disable, TODO:UC20: is probably fine). then this can land
<mvo> cmatsuoka: nevermind
<mvo> cmatsuoka: pushed it
<cachio> cmatsuoka, I don't see any nested test on #8409
<mup> PR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>
<cachio> cmatsuoka, is that the PR?
<cmatsuoka> cachio: yes, the test is currently in tests/main/uc20-create-partitions-encrypted, it will be moved to nested
<cachio> cmatsuoka, ah
<cachio> ok
<pedronis> this failure is weird: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/1163/signedlogcontent/31?urlExpires=2020-04-15T17%3A04%3A50.7188367Z&urlSigningMethod=HMACV1&urlSignature=n1FukofiSafDmCcRwGnoncpLJS8mfgpiWZRJABATpvc%3D
<ijohnson> pedronis: that url seems to be expired
<ijohnson> which PR was that from?
<pedronis> ijohnson: your PR
<ijohnson> I noticed an odd lxd error from 8503, but I saved the logs and restarted the check
<ijohnson> ah okay so same thing I saw
<ijohnson> I'm looking into the issue now
<pedronis> yes, weird failure in a lxd regression test
<pedronis> ijohnson: it failed also in your other pr
<pedronis> so maybe it's real
<ijohnson> that's silly
 * ijohnson will look more into it after lunch
<zyga> what was the failure?
<zyga> (in the lxd regression test)
<cmatsuoka> pedronis: what would be a good place to define the kernel command line used in tpm sealing?
<pedronis> ijohnson: that test is failing for master too
<zyga> pedronis: do you have logs?
<zyga> which test is it?
<pedronis> something thinks we should have snapd around
<pedronis> but actually we have core
<pedronis> # lxc file push /usr/bin/snap bionic/usr/bin/snap
<pedronis> Error: open /snap/snapd/current/usr/bin/snap: no such file or directory
<zyga> ah
<zyga> I think I know that this is
<zyga> one moment
<zyga> I think it's a race, I've seen things like that today
<zyga> lxc launch ...
<pedronis> it's google:ubuntu-18.04-64:tests/regression/lp-1871652
<zyga> lxc file push ...
<zyga> that fails
<pedronis> it fails on master, running alone
<zyga> I added lxc exec -- ls -l ...
<zyga> that makes the container "ready" somehow
<zyga> pedronis: thanks, I'll run it now
<pedronis> cmatsuoka: the bootloaders should know about this, but for now you can hard code it in devicestate if it's easier
<cmatsuoka> pedronis: ok, thanks
<pedronis> cmatsuoka: actually is not devicestate, right? this goes into snap-boostrap?
<pedronis> anyway you can hard code it in snap-boostrap for now
<cmatsuoka> mm, yes, it's in snap-bootstrap
 * ijohnson is back
<ijohnson> zyga: did you reproduce/fix the issue?
<zyga> ijohnson: yes, not yet
<ijohnson> ah finally my spread run just got there I've got it now too
<zyga> so
<zyga> this is weird
<zyga> there are two systems
<zyga> the host and the container
<zyga> neither has snapd snap
<zyga> yet
<zyga> lxc file push says
<zyga> Error: open /snap/snapd/current/usr/bin/snap: no such file or directory
<zyga> this is lxd 4.0.0
<zyga> maybe lxd bug?
<stgraber> you must have SNAP or SNAP_NAME in the environment
<ijohnson> stgraber: we don't
<zyga> indeed
<ijohnson> https://www.irccloud.com/pastebin/dtcv3kfp/
<zyga> and this passed recently as it's a fix for the bug that was plaguing lxd (from snapd side)
<stgraber> what's the "lxc file push" you're running?
<zyga> lxc file push /usr/bin/snap bionic/usr/bin/snap
<zyga> I'm copying the snap command from the host (deb) to the guest
<zyga> since the host has locally built snapd
<stgraber> hmm, odd
<ijohnson> stgraber: if I switch to 3.23/stable channel the same command works
<ijohnson> and actually switching back to 4.0/stable channel again the same command fails again
<ijohnson> looks like a lxd regression to me
<stgraber> hmm, we didn't touch any of the file code between 3.23 and 4.0
<zyga> yeah, I just tried that too
<zyga> stgraber: did you release 4.0 recently?
<stgraber> we did just switch the snap over to core18 though
<ijohnson> zyga: did you see the same behavior?
<zyga> yes
<zyga> works perfectly on 3.23
<zyga> ijohnson: shall we update LXD channel and call it a day?
<ijohnson> zyga: yeah I think that's fine for now
<ijohnson> I'll file a PR
<zyga> thank you!
<zyga> may I suggest something?
<zyga> ijohnson: adjust the test to respect a variable
<stgraber> testing with current 4.0 with same file push here to see if it reproduces easily
<zyga> and update the variable in spread.yaml
<zyga> I think I missed that we have this in the first place when I wrote the test
<ijohnson> zyga: that's a great idea sure
<zyga> thanks!
<stgraber> root@sateda:~# nsenter --mount=/run/snapd/ns/lxd.mnt  -- ls -lh /usr/bin/snap
<stgraber> lrwxrwxrwx 1 root root 32 Mar 11 05:46 /usr/bin/snap -> /snap/snapd/current/usr/bin/snap
<stgraber> that would be why ^
<zyga> !!!
<zyga> that's weird
<zyga> how did we get that symlink?
<stgraber> presumably this wasn't that way on core16 so that wasn't a problem
<zyga> is that a core18 regression?
<zyga> is 3.23 using a different base?
<stgraber> I mean, it's still a bug, it shouldn't actually pull the thing from inside the snap, it needs to pull it from the host
<stgraber> yeah, we switched based from core to core18 a few hours ago
<zyga> indeed
<zyga> this makes sense
<stgraber> root@sateda:~# nsenter --mount=/run/snapd/ns/lxd.mnt  -- ls -lh /var/lib/snapd/hostfs/usr/bin/snap
<stgraber> -rwxr-xr-x 1 root root 14M Oct 30 12:17 /var/lib/snapd/hostfs/usr/bin/snap
<zyga> cool, do you need a bug report for tracking?
<stgraber> that's still fine and it should be using that
<stgraber> you can if you want, but I'll probably have it fixed in 5min or so
<zyga> ok, no need then
<stgraber> INFO[04-15|18:27:30] Pushing /var/lib/snapd/hostfs/usr/bin/snap to /usr/bin/snap (file)
<stgraber> that's more like it
<stgraber> I absolutely hate that logic...
<stgraber> such a mess to support absolute and relative paths, with and without symlinks in the middle, ...
<stgraber> zyga, ijohnson: https://github.com/lxc/lxd/pull/7198
<mup> PR lxc/lxd#7198: shared/util: Never look into the snap <Created by stgraber> <https://github.com/lxc/lxd/pull/7198>
<stgraber> will be in the stable snap in the next 4-5 hours I'd say
<ijohnson> cool thanks stgraber
<zyga> stgraber: you like to live dangerously ;-)
<zyga> but I admire that
<stgraber> I've been doing daily stable cherry-picks lately
<zyga> ah
<zyga> I see
<zyga> that's interest
<zyga> *interesting
<zyga> perhaps something we could do?
<ijohnson> ahhhh we would have many folks very mad if we did as many stable releases as often as lxd :-)
<stgraber> well, we have pretty reasonable testing on all distros and architecture, that's why it takes 4-5 hours before we're pretty confident it's not horribly broken :)
<zyga> stgraber: having a regression test for push would be great tho :D
<stgraber> yeah, not very practical to test in CI since we don't use any snaps there, but I'll sneak some file push testing into our snap tests
<stgraber> test added
<zyga> thank you :)
<ijohnson> zyga: fancy a +1 before you EOD? https://github.com/snapcore/snapd/pull/8504
<mup> PR #8504: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8504>
<ijohnson> :-)
<zyga> looking
<zyga> I'm not EODing yet
<zyga> deeeeply in dbus
<ijohnson> one might say you are dbusly in dbus
 * ijohnson stops
<mup> PR snapd#8504 opened: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8504>
<zyga> hahaha
<zyga> +1
<zyga> there's something magic about the words
<zyga> "in progress"
<zyga> that's so much better than "queued" we had before
<mup> PR snapd#8505 opened: spread.yaml: switch back to latest/candidate for lxd snap <Test Robustness> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8505>
<zyga> ijohnson: ^ nice
<ijohnson> in progress does sound much better
<ijohnson> I think in general whenever we need to do things like this, i.e. revert something to unbreak master while something is fixed, we should always open a PR undoing that change at the same time so at least we remember because there's an open PR about changing
<zyga> yes
<ijohnson> i.e. same thing when we move a system to unstable, we should open another PR which moves it back to stable
<ijohnson> pedronis: we fixed the lxd issue on master
<ijohnson> well we have a PR open
<mup> PR snapd#8463 closed: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8463>
<pedronis> ijohnson: I see
<pedronis> ijohnson: anyway proves why I'm not a fan of dangling symlinks in bases
<ijohnson> pedronis: yes but also why we should be very strict about letting snaps access things in bases too
<pedronis> yes
<ijohnson> pedronis: also did you discuss with maciej about picking up the necessary changes to gadget pkg et al to enable mbr support for create-partitions? should I try to push that forward? I was kinda hoping that he would pick that up but I keep forgetting to ask him before he EODs
<pedronis> ijohnson: I don't know, it's actually a prereq to make the run mode changes relevant, right? because it's install time?
<ijohnson> pedronis: yes
<ijohnson> yes it's a blocker I mean
<pedronis> ijohnson: have you started the other bootloaderKernelState ?
<ijohnson> I'm wrapping it up now, but I need to figure out a way to write tests for it, I'd rather not rewrite the dozens of tests we already have for bootstate20 to use a mock uboot bootloader, etc.
<pedronis> ijohnson: maybe just write direct tests for it?
<pedronis> we probably need to reorg some of the other tests as table tests so that they are easier to reuse
<ijohnson> pedronis: yes perhaps, need to think about it a little bit
<pedronis> or have a actual test mixins
<pedronis> we don't have a lot of the latter but we don sometimes
<ijohnson> yeah we could refactor some of the tests big chunks to use helpers too
<ijohnson> lots of the tests are just bootloader setup anyways
<pedronis> cmatsuoka: is #8409 ready for Chris to look at it?
<mup> PR #8409: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8409>
<cmatsuoka> pedronis: will be in a minute, pushing a final commit
<cmatsuoka> pedronis: pushed
<mup> Issue core20#36 closed: SSH login shell says the system was minimized and to run "unminimize", but should not <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/36>
<mup> PR core20#42 closed: drop `unminimize` instructions that are not applicable on Core <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/42>
<mup> PR snapd#8284 closed: config: add system.store-certs.[a-zA-Z0-9] support <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8284>
<mup> PR snapd#8503 closed: boot/bootstate20: fix bug in try-kernel cleanup <Bug> <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8503>
<mup> PR snapd#8504 closed: spread.yaml,tests/many: use global env var for lxd channel <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8504>
<mup> PR snapd#8506 opened: Add libnvidia-opticalflow as Nvidia library <Created by joedborg> <https://github.com/snapcore/snapd/pull/8506>
<joedborg> hey everyone, if someone could take a quick look at ^ it'd be much appreciated
<mwhudson> what determines what ends up in parts/$PART/install/usr/lib/python3/dist-packages using the python plugin?
<mup> PR snapcraft#3043 opened: package-repositories: initial schema and meta read/write support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3043>
<mup> PR snapcraft#3044 opened: build providers: use ubuntu-ports mirrors for non-x86 platforms <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3044>
#snappy 2020-04-16
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> mvo: idk if you've seen https://github.com/snapcore/snapd/pull/8325#issuecomment-614223448
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mvo> mborzecki: how are the tests today?
<mvo> mborzecki: not seen yet, looking
<mvo> mborzecki: oh no :(
<mvo> mborzecki: I wonder if the initrd really "reads" what we ask it to mount or if it has it's own list of things to mount
<mborzecki> on a side note, i tried some tricks with snap-store and zoom-client snaps, sice one only renders boxes and theother just segfaults on arch (backtrace points to something fonts related)
<mborzecki> mounting a clean tmpfs over /etc/fonts so that it dones't pick up anything from the host does not change anyting so still no luck :(
<mvo> mborzecki: hrm, hrm, this is strange, does mounting tmpfs over the fontcache dirs also yield no results?
<mborzecki> mvo: first thing i tried ;)
<mvo> mborzecki: heh - I suspected that. sad :(
<mvo> mborzecki: also strange what is bleeding into the namespace
<mup> PR snapd#8506 closed: Add libnvidia-opticalflow as Nvidia library <Created by joedborg> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8506>
<mup> PR snapd#8497 closed: boot/bootstate20: re-factor kernel methods to use new interface for state <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8497>
<zyga> hey
<zyga> what's up guys?
 * zyga is feeling terrible 
<mborzecki> zyga: hey
<zyga> since 5AM I'm awake and blowing my nose every 20-40 seconds
<zyga> something I'm allergic to is blooming
<zyga> mborzecki: jamie asked us to review the base permissions PR
<mborzecki> mhm, added myself there
<pstolowski> hi
<mborzecki> pstolowski: hey
<zyga> hey pawel
<zyga> I will start late
<zyga> sorry
<mborzecki> jamesh: any idea whether the cache namespace is still per job when a matrix setup is used?
<jamesh> mborzecki: I'd assume it is shared.  Or is the real question whether matrixed jobs have their own github.job value?
<mborzecki> jamesh: that or whether a different combination of matrix elements is a new job, thus a new namespace(?) or still the same job, so a shared namespace
<jamesh> mborzecki: a job is a unit of work deployed to a single runner, so the matrix expands to multiple jobs
<mborzecki> jamesh: can check that by pushing code but wanted to ask you first, since i seems you've been on that road already :P
<mup> PR core18#150 closed: static: make /etc/dbus-1/session.d writable <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core18/pull/150>
 * zyga is unable to work for some time
 * zyga loves summer but sometimes hates the spring
<mborzecki> quitk errand, back in 30
<mup> PR snapd#8507 opened: packaging: fix build on Centos8 to support BUILDTAGS <Created by mvo5> <https://github.com/snapcore/snapd/pull/8507>
<mborzecki> re
<pstolowski> mvo: hey, i've found out some more about my yesterday's problem (and also recreated the image from the spread test locally). i think that for some reason the extra user defined by cloud init data is not copied to extra-users (but sshd actually works) - as if messing with /etc wrt early config somehow affected cloud init (?)
<mvo> pstolowski: meh, sorry, I did not really managed to look at this yet, can ypu please paste the link again? so sorry
<pstolowski> mvo: system-data/var/lib/cloud/seed/nocloud-net/ on the image looks ok to me, afaict
<pstolowski> mvo: no worries, i know it was late yesterday
<pstolowski> mvo: https://github.com/stolowski/snapd/tree/core18-early-config
<mvo> pstolowski: aha, that is interessting, can you share the image via gdrive or something? if you boot it with "systemd.debug-shell=1" do you see anything interessting in the cloud-init logs that may indicate what went wrong?
<pstolowski> mvo: let me try; sure i can upload it
 * zyga found some anti-allegric meds 
<mvo> pstolowski: maybe first poke a bit with the debug shell but if you don't find anything I can poke a bit too
<pstolowski> mvo: yes, looking, thanks
<mvo> pstolowski: the general rule is that if there is a "clash" of files/dirs in /snap/core18/current/... with the dir in the image and writable-path then there is aproblem
<mvo> pstolowski: i.e. if there is /var/lib/cloud in writable-path and there is such a dir in core18 with relevant data and the image also creates it
<mvo> pstolowski: does that explaination make sense? if not, we can have a quick HO
<pstolowski> mvo: yes, makes sense
 * zyga gets to work
<pstolowski> mvo: passing systemd.debug-shell=1 to kernel commandline has no effect (no extra tty created for it), is it expected to work with core?
<zyga> try _
<zyga> pstolowski: it changed across versions
<zyga> pedronis: systemd.debug_shell=1
<zyga> er
<zyga> pstolowski: ^
<zyga> sorry pedronis, bad tab complete
<mvo> pstolowski: it should work, this is core or core18 ? but in either case it should work :(
<pstolowski> mvo: core18
 * mvo quickly double checks
<zyga> mvo: ^^^^
<zyga> mvo: systemd.debug_shell=1
<pstolowski> ah underscore?
<zyga> cat /snap/core18/current/lib/systemd/system/debug-shell.service and man systemd-debug-generator
<zyga> yes
<zyga> it used to be -
<zyga> now it is _
<mvo> pstolowski: fwiw on uc18 https://photos.app.goo.gl/UfrQFWkfRhAaEqNC6 works for me
<zyga> mvo: https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c#L62
<mvo> zyga: sure, just saying this works on uc18
<zyga> sure :)
<zyga> shame old value doesn't work
<mvo> zyga: yeah, it seems strange to break backwards compat
<mvo> zyga: oh well
<mvo> zyga: otoh, it's just a debug value
<pstolowski> mvo: and you're getting a tty9 with a debug shell?
<mvo> pstolowski: yes
<mvo> pstolowski: not sure which one, I just use alt-arrow to cycle through them
<pstolowski> mhmm
<pstolowski> mvo: yes, it works, thank you! i had to run qemu with its ui; for some reason with -nographic it wouldn't work (i was using sendkey .. from the monitor)
<mvo> pstolowski: ok
<mup> PR snapcraft#3045 opened: grammar: pick from properties if attributes not in the plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3045>
<pstolowski> mvo: so it appears that cloud-init is not executed at all (no logs in /var/log/). only when i start cloud-init service manually it creates extra-users. i could see that /var/lib/cloud was mounted at boot time
<pedronis> pstolowski: anything interesting in /etc/cloud ?
<mup> PR snapd#8508 opened: github: run all spread systems in a single go with cached results <Skip spread> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8508>
<mvo> pstolowski: what does /etc/cloud look like? any "nocloud" files anywhere?
<pedronis> mvo: I am a bit confused by the caching branches, shouldn't the test be re-run if there were more commits to the PR?
<pstolowski> pedronis, mvo : cloud.cfg, ds-identity.cfg, templates and cloud.cfg.d
<mvo> pedronis: they will be
<mvo> pedronis: it's all a bit mood right now anyway because there is a bug
<pedronis> pstolowski: is there anything in /run/cloud-init ?
<pstolowski> pedronis: yes, cloud.cfg, enabled, and two .log files. fwtw i run cloud-init service manually, should i check this directory  right after boot of my pristine image?
<pedronis> pstolowski: yes
<pstolowski> pedronis: it looks the same
<pedronis> pstolowski: look at the log files then, something cloud-init run
<pstolowski> pedronis: there are no logs from cloud-init until i manually systemctl restart cloud-init (as if it wasn't run during the boot)
<pedronis> pstolowski: sorry, then didn't look the same
<pedronis> pstolowski: there's only an empty directory for /run/cloud-init? no directory? only ds-indentify stuff?
<pstolowski> pedronis: /run/cloud-init & /etc/cloud look the same (and run/cloud-init has two .log files). but there are no logs under /var/log unless i start cloud-init manually
<pedronis> pstolowski: sorry, I mean to look at the logs in run/cloud-init
<pedronis> I know you said there are no /var/logs
<pstolowski> "Found single datasource: NoCloud"  in ds-identify.log; relevant?
<pedronis> yes, but that's just expected
<pedronis> it means it will look at user-data etc in the usual places
<pedronis> pstolowski: mvo: also our early does debug-shell run?
<pedronis> it might just be normally too early?
<pedronis> from the description it sounds like it's meant ot run very
<pedronis> early
<pstolowski> pedronis: fwtw i see 'Cloud-init target reached' as one of the last messages on tty1; the other tty has console-conf waiting
<mup> PR snapd#8502 closed: github: try caching test results <Skip spread> <Created by bboozzoo> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8502>
<mborzecki> ehh bummer
<mvo> mborzecki: well, it's not all lost, once the github cache thing is fixed we will land this!
<mborzecki> mvo: thanks for trying! subscribed to https://github.com/actions/cache/issues/208
<emitorino> good morning all
<pedronis> pstolowski: can you remind me? we are trying to debug why ssh doesn't work right?
<pstolowski> pedronis: yes. but sshd works, just user doesn't get created
<pedronis> pstolowski: ok, maybe we can do a HOÂ sharing a screen and IÂ can help more?
<pstolowski> pedronis: and it seems the be happening when i add defaults: to gadget. although i probably need to re-try without defaults again
<zyga> I made good progress today
<zyga> I'm writing actually useful dbus tests now
<zyga> I'll split this off this effort and propose separately after the standup
<pstolowski> pedronis: sure, appreciate it
<pstolowski> pedronis: is after standup fine?
<pedronis> pstolowski: might after a short break after the standup
<pstolowski> ok
<cmatsuoka> ijohnson: does this look like the same snap upgrade problem you investigated? https://bugs.launchpad.net/snapd/+bug/1873260
<mup> Bug #1873260: All installed snaps are broken after upgrading to Focal <snapd:New> <https://launchpad.net/bugs/1873260>
<ijohnson> cmatsuoka: no that looks slightly different on the surface
<ijohnson> cmatsuoka: I'll respond though
<cmatsuoka> ijohnson: thanks
<mup> PR snapcraft#3045 closed: grammar: pick from properties if attributes not in the plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3045>
<zyga> ijohnson: there's a bug for this issue but I cannot find it now
<ijohnson> zyga: you mean the stale snapd tools in the mount ns ?
<zyga> yes
<ijohnson> k, let me know if you find it but if not I'll just file a new one sometime today
<zyga> ok
<zyga> it's just a pretty old bug as we went to core18 with it
<mup> PR snapcraft#3044 closed: build providers: use ubuntu-ports mirrors for non-x86 platforms <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3044>
<zyga> ijohnson: let's open a new one
<zyga> ijohnson: perhaps it is reported on the forum, not in the tracker
<zyga> or may have been reported in github while we still had issues
<zyga> I think it must be the forum
<zyga> because we discussed ideas there
<zyga> https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139
<zyga> ijohnson: ^^^^
<zyga> and you commented on it as the last person :)
<ijohnson> right I remember your forum topic
<ijohnson> :-)
<zyga> please link it to the bug
<zyga> and we should really make some progress and fix it
<zyga> it will affect all core18 and core20 systems
<ackk> hi, is this somehow intentional or should I file a bug about it: https://paste.ubuntu.com/p/5pxZwTYgx3/ ?
<ackk> (inside a snap run --shell for a strictly confined snap)
<ijohnson> ackk: yes because `test -r` will use the `stat`syscall which we always allow
<ackk> ijohnson, won't that break stuff as if you test that you can read something and then try to read it, it fails?
<ijohnson> ackk: I'll defer to jdstrand and/or zyga on why stat is always allowed, I don't recall the why, I just recall that it is
<zyga> ackk: stat is always allowed by apparmor
<zyga> ackk: it's not mediated IIRC
<zyga> ackk: (by apparmor)
<ackk> zyga, so it ends up lying because the policy is actually only enforced on open() ?
<zyga> ackk: and you are correct, there is even a comment somewhere in the LSM stack about this
<zyga> yes
<ackk> I see
<ijohnson> zyga: you mean stat is always allowed by seccomp
<ackk> zyga, side, note, why is /etc/issue not readable? :)
<zyga> ackk: as in, not allowed by the policy?
<zyga> because anything that was allowed by the policy would be something we have to keep
<zyga> so it was used as a way to limit what we need to keep across core revisions
<zyga> so if you cannot read it, it's not "ABI"
<zyga> as to issue specifically
<zyga> just nobody asked?
<zyga> ijohnson: seccomp separately
<zyga> ijohnson: but apparmor just says "yes" to stat
<ijohnson> right that's what I meant sorry we are in agreement
<zyga> ijohnson: right
<ackk> zyga, out of curiosity is that something that apparmor plans to fix (returning the truth in stat) or is that not possible?
<zyga> I don't know
<zyga> perhaps jjohansen or jdstrand can respond
<zyga> it's possible, it's just code
<ackk> SMOP :)
<zyga> smop?
<ackk> small matter of programming
<zyga> haha
<zyga> and upstreaming
<zyga> Small matter of sending it to the LKML and getting it merged ;)
<ackk> zyga, I meant more, not doable as filtering stat() might heavily affect performance or something
<zyga> IIRC selinux does this
<ackk> I guess it'd have to do a bunch of extra checks
<ackk> oh, I see
<jdstrand> ackk: we used to mediate it but found that basically everything needed it and required large-scale policy changes
<jdstrand> there is a bug on it. let me see if we can find it
<jdstrand> https://bugs.launchpad.net/apparmor/+bug/1655435
<mup> Bug #1655435: stat() unconditionally allowed via apparmor_inode_getattr() <AppArmor:Triaged> <https://launchpad.net/bugs/1655435>
<ackk> jdstrand, thanks
<jdstrand> it's possible to fix with a number of changes
<zyga> ackk: are you using stat or access?
<ackk> zyga, I saw the issue in a bash script that was doing pretty much the same thing as my paste
<ackk> it seems test uses stat()
<mup> Bug #1873276 opened: Deliberate use of 'partial confinement' in order to mean 'unconfined' <selinux> <Snappy:New> <https://launchpad.net/bugs/1873276>
<zyga> I'm off for lunch
<mup> Bug #1873276 changed: Deliberate use of 'partial confinement' in order to mean 'unconfined' <selinux> <Snappy:Invalid> <https://launchpad.net/bugs/1873276>
<pstolowski> pedronis: do you have a moment now?
<pedronis> pstolowski: yes, sorry the after standup was long and needed a break
<pedronis> pstolowski: I'm in the standup HO
<pstolowski> 1 sec
<ijohnson> mvo: lxd latest/candidate snap is unbroken so I think we can merge #8505, the only unfailed test there is from an unstable system
<mup> PR #8505: spread.yaml: switch back to latest/candidate for lxd snap <Test Robustness> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8505>
<mvo> ijohnson: cool, looking
<mup> PR snapd#8505 closed: spread.yaml: switch back to latest/candidate for lxd snap <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8505>
<ijohnson> thanks mvo
<mup> PR snapd#8356 closed: cmd/snap: Implement a "snap routine file-access" command <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8356>
<mup> PR snapcraft#3043 closed: package-repositories: initial schema and meta read/write support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3043>
<jjohansen> zyga, ackk: we would love to fix the whole stat issue, doing so however requires us to get a patch upstream that some people are fundamentally opposed to
<jjohansen> we haven't tried recently, it is something we should circle around to and try again
<zyga> I solved the dbus signature issue
<zyga> making more progress now
<zyga> ijohnson: not for me, but perhaps ackk has some priority there
<ijohnson> zyga: sorry missed the context, what's up?
<zyga> er, jjohansen ^
<zyga> sorry I'm bad at tab completion apparently:)
<zyga> or perhaps my body tells me to make coffee
<zyga> or both
<jjohansen> zyga: ?
<jjohansen> I was responding to "(06:45:48 AM) ackk: zyga, out of curiosity is that something that apparmor plans to fix (returning the truth in stat) or is that not possible?
<jjohansen> (06:46:03 AM) zyga: I don't know
<jjohansen> (06:46:15 AM) zyga: perhaps jjohansen or jdstrand can respond"
 * cachio lunch
<jjohansen> yes it is just code, yes we would love to fix it, no it isn't happen soon because there are people upstream who are opposed to it
<jjohansen> it is one of the abilities we lost when upstreaming
<jjohansen> so 12 years ago apparmor actually did mediate stat and access
<pstolowski> pedronis: i've created a clean core18 with cloudinit data and diff'ed system-data before and after first boot; and the problematic image is missing those https://pastebin.ubuntu.com/p/CgdTHzTXkz/
<pstolowski> pedronis: now need to find: why :/
 * pstolowski afk
<jdstrand> thanks jjohansen :)
<pedronis> mvo: ^ what Pawel mentioned seems writable path related
<mvo> pedronis: totally, let me have a HO with him in the morning
<mvo> pedronis: setup a meeting with him for this
<pedronis> mvo: we created something in /etc/systemd/system in the image and /etc/systemd is one of the things handled by writable-paths
<pedronis> we do the same with /etc/cloud but that has a strange comment in in the writable-path config
<mvo> pedronis: yes, that is exactly my suspicion
<mvo> pedronis: if mode is not "synced" dirs that exist will be ignored
<pedronis> mvo: but if I understand the issue is kind of the reverse, the problem is that /etc/systemd/system is not empty in core18
<pedronis> (not that we can fix that easily)
<mvo> pedronis: so we create a /dev/null link in /etc/systemd/system/rsyslog.service in the image already, right? that's what pawel is doing in this test?
<pedronis> mvo: yes
<pedronis> is not the test code to be clear, it's actual configcore code run early
<mvo> pedronis: then it all makes sense, sorry, I should have had this conversation with him earlier :( https://paste.ubuntu.com/p/CwkSnnGgqB/
<mvo>  
<mvo> pedronis: this would fix it but the price is high
<mvo> pedronis: I think we need to ponder what to do
<pedronis> mvo: I think, yes, that's what we need
<pedronis> anyway the commetn about /etc/cloud is also obsolete
<pedronis> I think your code
<pedronis> also need /etc/cloud synced
<pedronis> that one is already mark as synced though
<mvo> pedronis: let's talk tomorrow, I need to get dinner but I really want to explore what we can do, setting syned has it's own issues
<pedronis> mvo: yes, just making clear that we have the same kind of issues both for /etc/systemd and /etc/cloud
<pedronis> it's not just pawel new code
<pedronis> mvo: I mean this code https://github.com/snapcore/snapd/blob/master/overlord/devicestate/handlers_install.go#L105 and the same kind of code in bootstrap
<pedronis> mvo: both the base and potentially writable have files to put there
<mup> PR snapcraft#3041 closed: V2 python plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3041>
 * zyga -> dinner
<mup> PR snapcraft#3046 opened: plugins: introduce v2.GoPlugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3046>
<sergiusens> zyga: stgraber lately I daily experience "Error: websocket: close 1006 (abnormal closure): unexpected EOF" which kicks me out of my "lxc exec"... is this new behavior expected?
<stgraber> sergiusens: this isn't a new behavior, it happens when LXD reloads, usually because of a refresh
<stgraber> if this didn't happen because of an auto-refresh, then there may be an associated LXD crash we'd want to look at
<sergiusens> stgraber: container itself is not killed, right? If I were ssh'ed in I wouldn't see it
<stgraber> sergiusens: correct
<stgraber> we never restart containers on refresh even during upgrades, but anything connected to the daemon over the REST API does get disconnected which includes exec sessions
<stgraber> we've considered some options around that but they all kinda suck
<sergiusens> stgraber: refresh happened 10 minutes ago, coincides with this event, so no worries and carry on
<stgraber> we could have a grace period and have the daemon tell you you're about to disconnect due to refresh
<stgraber> but we have no idea how to tell you that without injecting stuff in your terminal
<stgraber> which is a very bad idea on its own :)
<sergiusens> that would be nice, if only to save my bash history
<stgraber> as people redirect "lxc exec" to various things, including netcat, files, disk, ... so having it ever write something other than what you expect or an error would be a big issue
<sergiusens> yeah, this would need some snapd/desktop intergration that you could hook into (for the local scenario)
<stgraber> yeah, if the user who's logged in on a desktop happens to be in the lxd group, then we could in theory hold on the restart, notify them that they have 10min to disconnect all pending exec sessions, then continue
<stgraber> we do have the API in place to list all ongoing exec sessions (lxc operation list) so it's pretty much just packaging at that stage
<ijohnson> stgraber: well also if there was refresh app awareness, then you wouldn't get refreshed automatically if there's an `lxc exec` process running
<stgraber> ijohnson: oh no, we definitely do want to kill those eventually
<stgraber> ijohnson: a security fix in a service running as root and listening to the network, definitely trumps the inconvenience of having to re-connect to an exec session :)
<ijohnson> sure, but you could at least defer a refresh for some amount of time while there are things running
<sergiusens> with refresh app awareness, snapd would not trigger the refresh at all, so not sure you have a say in that if someone enables it
<ijohnson> sergiusens: there will also be an api for a snap to be notified or query if there is a pending refresh
<zyga> lxc is capable of escaping all tracking
 * zyga is afk
<ijohnson> well true, lxc is it's own special snowflake when it comes to snapd features I guess
<stgraber> the `lxc` command doesn't do any bypass that I'm aware of (other than apparmor) so yeah, that'd work, unless your LXD is clustered in which case as soon as any of the cluster nodes detects a new revision, they all self-refresh whether you like it or not
<stgraber> but yeah, some kind of grace period on LXD shutdown when we have ongoing operations is probably fair
 * stgraber adds to ideas list
<pedronis> yes, there will be ways to be aware, though I think we need to redefine our thinking there, because there is some assumptions about a user being present
<pedronis> the design of that feature which is still wip, was driven more by desktop apps
<mup> PR snapd#8509 opened: boot/bootstate20: small changes to markSuccessful <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8509>
<ijohnson> pedronis: I opened ^ because it's a simple thing, but could be considered a behavior change so I wanted to make it easy to review
<pedronis> ijohnson: it doesn't read as simple at all, also how can it be a behavior change if no tests changed
<ijohnson> pedronis: it's not a behavior
<ijohnson> change
<ijohnson> sorry maybe I should not move the comment in this PR
<pedronis> ijohnson: also remember that Marksucceful is called on all kind of boths
<pedronis> even non successful ones
<pedronis> it has kind of a bad name
<pedronis> s/boths/boots/
<ijohnson> pedronis: but is there any situation where MarkSuccessful shouldn't result in having DefaultStatus at the end of it?
<ijohnson> pedronis: because that's the current behavior, I'm just making that decision to always set DefaultStatus more obvious by not making that decision in commit() and instead making that decision in markSuccessful() proper
<pedronis> ijohnson: I'm just saying that you are adding a large commit that sounds like mark successful
<pedronis> is there only for successful boots
<pedronis> s/commit/comment
<pedronis> that is not true
<ijohnson> mmm, I guess in my mind, a "successful" boot is one where we get to userspace with some boot snap combo
<ijohnson> and thus we get to call MarkSuccessful
<ijohnson> even if the overall operation of upgrading a boot snap failed, we still eventually successfully booted something
<pedronis> yes, but as I said the terminogy is confusing here
<pedronis> it's very old
<pedronis> we need to be careful not to give the wrong impression
<ijohnson> okay, so instead of renaming all markSuccessful ish things here how about I just adjust the comment that says "always set the commit status on the bks on the bootStateUpdate we return to be empty"
<ijohnson> to say something like:
<pedronis> basically I'm not sure this PR is an improvement
<pedronis> it adds even more action at a distance
<ijohnson> "set the kernel status to be default again because we booted some kernel snap"
<pedronis> but I'm probably missign the simplification that comes with it
<ijohnson> pedronis: the simplification is that right now, the decision to always set kernel_status to default after calling MarkSuccessful is done in commit()
<ijohnson> pedronis: I thought that was confusing because if you just read markSuccessful you won't get that impression
<ijohnson> pedronis: so instead I thought let's make that more obvious and explicit by doing it in the markSuccessful function instead of commit()
<ijohnson> as I said there isn't an actual behavior change, in my mind this is just making it more obvious what we are doing
<ijohnson> if we are doing the wrong thing right now, then perhaps that's justification enough that we should never have made that decision to do that in commit() in the first place
<ijohnson> (because it wasn't obvious)
<pedronis> ijohnson: I think the issue is more that markSuccefulKernel is strange
<pedronis> I probably didn't notice it yesterday
<ijohnson> pedronis: well right now that function is just markSuccessful
<pedronis> but remember that my plan was not to attach commitKernelStatus to that level
<pedronis> so it's a bit different from my original idea
<ijohnson> mm I guess it is
<pedronis> it's not a problem, but reading it again in the new context, it's clear that some bits are confusing
<ijohnson> after looking at it more I conclude that it's clear that it's unclear
<ijohnson> well anyways I don't really need this PR, it was just going to make things a bit nicer
<ijohnson> I think if this PR is going to cause us to rathole on what it means to mark something successful it's probably not worth the time right now
<pedronis> basically this if is odd:  bks.commitKernelStatus != bks.currentKernelStatus
<pedronis> given that then we pick a constant inside it
<pedronis> I don't think setting commitKernelStatus helps though
<ijohnson> pedronis: well in the PR I just opened that if looks much more sane
<pedronis> yes in some way, no in others
<ijohnson> if bks.commitKernelStatus != bks.currentKernelStatus { ... use bks.commitKernelStatus
<ijohnson> we're not using a constant there anymore
<pedronis> I know
<ijohnson> okay how about this, should I just get rid of commitKernelStatus on extractedRunKernelImageBootloaderKernelState and instead carry that on bootState20Kernel instead ?
<ijohnson> then markSuccessfulKernel() takes in the status to set as an arg like you originally watned?
<ijohnson> *wanted
<pedronis> ijohnson: well, it's always going to be DefaultStatus, as far as we understand, right?
<pedronis> so we don't need to pass it to it I suppose
<pedronis> but we do need to pass it in to the other method
<ijohnson> pedronis: what I don't want is to have the constant inside markSuccessfulKernel
<ijohnson> because that function is only called from commit()
<ijohnson> it feels weird to me that commit() is essentially making that decision to always use DefaultStatus
<pedronis> it's a commit of a given operation, is not a general commit
<pedronis> one can see it both ways
<ijohnson> mmm again it seems we have something that is clearly unclear
<pedronis> ijohnson: the issue really, is this, the idea of commit comes from the bootstate16 work
<pedronis> there commit is fairly generic
<ijohnson> yes
<pedronis> we lost that property in bootstate20
<pedronis> so in obvious (constants) and non obvious ways
<pedronis> there are some assumptions and semantics encoded in the commits
<pedronis> that are operation related
<pedronis> so as long at ther is this hybridity I'm just not seeing a big win moving things before or later than the commit
<pedronis> as long as the behavior is correct and explained
<pedronis> but that might just be me
<ijohnson> yes this hybridness does make things a bit weird
<ijohnson> I'm not sure, but let me frame the question this way, do you want me to refactor the setNextKernel to take in the status ?
<pedronis> yes
<ijohnson> okay, so then let me make a symmetry argument and let's just make markSuccessfulKernel take in a status too?
<pedronis> I'm ok with that, is not strictly necessary but that's ok
<ijohnson> ok
<pedronis> ijohnson: notice that we don't this for the base either, the state is hard coded in commit
<ijohnson> yes I'd say that's just as wrong as kernel tbh
<pedronis> as I said, given how we organized is not wrong or not wrong
<pedronis> commit is not generic
<pedronis> we have 3 of them
<ijohnson> I mean looking at the doc-comment for commit() it says "bootStateUpdate carries the state for an on-going boot state update. At the end it can be used to commit it"
<ijohnson> it doesn't feel like the commit() method on bootStateUpdate should really be making decisions, it should just take the state that's already in bootStateUpdate and then commit it
<pedronis> ijohnson: if we followed the spirit of that, we would have one commit implementation
<pedronis> we don't
<pedronis> as I said, is not wrong or not wrong
<ijohnson> well I'd say the reason we don't have one commit implementation is for robustness reasons
<ijohnson> we can't commit everything in the same order and always be robust
<pedronis> I say, it's more for readability
<pedronis> we could have one commit
<pedronis> it would be not very readable
<ijohnson> fair
<ijohnson> anyways 8509 now passes in status and I unmarked "Simple" :-)
<pedronis> ijohnson: I commented, I still don't think that the comment on the interface method trumps the realities of the actual implementations' code, also less state manipulation is almost always a win in my book
<mup> PR snapd#8509 closed: boot/bootstate20: small changes to markSuccessful <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8509>
<ijohnson> pedronis: I don't think it's productive for either of us to pursue this more right now, I will have another PR which just makes the comment move change I wanted
<pedronis> ijohnson: I think the changes to the interface where fine and improved things (less places carrying state)
<ijohnson> sure I will just do that change then
<mup> PR snapcraft#3047 opened: repos: fix returned strings for install_stage_packages() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3047>
<mup> Bug #1873363 opened: openvswitch interface support for ovs-appctl <Snappy:New> <https://launchpad.net/bugs/1873363>
<mwhudson> how can i see the base for an installed snap?
<mwhudson> if i say snap info <snap> it's talking to the store
<mwhudson> ah meta/snap.yaml
<mup> PR snapd#8510 opened: boot/bootstate20: small changes to bootloaderKernelState20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8510>
<pedronis> ijohnson: thanks ^
<ijohnson> pedronis: np, I am close to opening up the next PR which is a big refactor of the tests to enable easy writing of the new tests for the uc16 style bootloader
<pedronis> ijohnson: great, I should really go to rest here though
<ijohnson> of course, have a good night, talk to you tomorrow
<mwhudson> is there a way to see the base of a snap from a non-default channel?
<mwhudson> i.e. something like snap info --channel, but that doesn't exist
<ijohnson> mwhudson: do you mean for a snap that's not installed?
<mup> PR snapd#8511 opened: tests/boot: refactor to make it easier for new bootloaderKernelState20 impl <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8511>
<mup> PR snapd#8512 opened: boot/bootstate20: add pure bootenv bootloader implementation <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8512>
<mwhudson> ijohnson: yes
<mwhudson> ijohnson: found a workaround though, download the snap and point info at that
<ijohnson> mwhudson: I don't think you can do that through any snap cmd, but you can get it through the store's json
<ijohnson> I just EOD'd so I don't have an example in front of me unfortunately
<mwhudson> ijohnson: it's ok we thing :)
<mwhudson> *think
#snappy 2020-04-17
<mup> PR snapd#8513 opened: snap-bootstrap: lock access to sealed keys <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8513>
<zyga> Good morning
 * zyga is tired after working past midnight
<mborzecki> morning
<zyga> Hey
<zyga> Made some more progress last night
<zyga> But tired now
<zyga> Iâll start at around 9
<mborzecki> mvo: zyga: hey
<mvo> mborzecki: good morning
<zyga> Hey mvo
<mvo> hey zyga
<zyga> How is bit cacher?
<mvo> zyga: seems to be working, running a real spread run this morning to see if it behaves
<zyga> Cool
<zyga> I guess we could then return to phased testing, with one build of snapd deb/snap
<mvo> zyga: yes, I think those can be distributed via artifcats
<zyga> That would be superb.
<mup> PR snapd#8510 closed: boot/bootstate20: small changes to bootloaderKernelState20 <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8510>
<mup> PR snapd#8507 closed: packaging: fix build on Centos8 to support BUILDTAGS <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8507>
<mborzecki> mvo: i'm going to file a bug in rhel about the build tags macro
<mborzecki> just upadting my rhel8 vm
<mvo> mborzecki: nice, thank you! fwiw, the git report referenced in the code has what we need
<pstolowski> morning
 * zyga starts the day
<mup> PR snapcraft#3047 closed: repos: fix returned strings for install_stage_packages() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3047>
<mborzecki> pstolowski: hey
<zyga> my dbus test passes without hanging for the first time
<zyga> let me clean it up a little and propose :)
<pstolowski> mvo: can you grant me edit rights to the doc?
<mvo> pstolowski: please reload, you should have it
<mup> PR snapd#8514 opened: Extend openvswitch interface to support ovs-appctl <Created by dosaboy> <https://github.com/snapcore/snapd/pull/8514>
<pstolowski> mvo: ty
<mvo> mborzecki: hey, just fyi - ondra shared some fun initrd building snippet https://git.launchpad.net/~ondrak/ondras-snaps/+git/linux-kernel/tree/snapcraft.yaml?h=ubuntu-focal-qcomlt-uc20#n50
<mborzecki> mvo: mhm, right, that's what we do too
<mvo> mborzecki: aha, ok
<mborzecki> otherwise it's lots of pain
<pstolowski> pedronis: hey, not sure if you saw my yesterday's finding (pastebin from the evening)? mvo figured out the reason (it's due to how writable is handled) and proposed how to handle it; we discussed it in a HO this morning. i'm sharing this notes with you and we can discuss when you have a moment today
<pedronis> pstolowski: mvo: did you discuss what to do about /etc/cloud, it has the same problem?
<mvo> pedronis: the soution outlined in the gdoc (number c) should apply to all of them equally
<pstolowski> pedronis: it's defined as synced per https://github.com/snapcore/core18/blob/master/static/etc/system-image/writable-paths#L54
<pedronis> mvo: ok, I'll wait for the doc to be finished
<mvo> pedronis: it's finished, (d) is really a bit of a distraction
<mvo> pedronis: it's super interessting but I'm not sure if it's worth it given that we also need to support uc16/uc18
<pedronis> mvo: c for 16/18 needs initramfs changes there, right?
<mvo> pedronis: correct
<mborzecki> huh, whole session froze
<pedronis> mvo: maybe if we need to do changes, we should do the same thing as uc20 and call a hook inside the bases?
<pedronis> but upgrades
<pedronis> there's probably a way to do that though
<pedronis> reexec like
<mvo> pedronis: that's a very interessting idea, let me look at the old initramfs code
<mvo> pedronis: I like this, should be totally doable (also in a backward compat way). it's a bit risky as it involves initrd changes but would be nice and clean and more uniform
<pedronis> mvo: notice though that we can't probably remove any synced from core18 writable-paths
<pedronis> because we don't know what people did with ubuntu-image hooks
<pedronis> we can/should remove them from core20 though
<mvo> pedronis: +1
<pedronis> mvo: there is probably some other wrinkle as well, related to prepare-image
<pedronis> I'll write some notes in the doc, when I have a moment. Finishing something else atm
<mvo> pedronis: thanks! adding some notes myself too
<pedronis> mvo: ok, yes, one point I wanted to make was indeed iv
<pedronis> mvo: pstolowski: made a couple of comments
<mvo> pedronis: thanks for adding the comment about the fallback!
<pstolowski> thanks
<mup> PR snapd#8515 opened: testutil: add NewDBusTestConn <Created by zyga> <https://github.com/snapcore/snapd/pull/8515>
<zyga> I pushed the test helper alone here
<zyga> and the tests are in https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pstolowski> mborzecki: hey, what's the plan with #7414?
<mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<zyga> I will write a few more tests to exercise all the interactions
<mborzecki> pstolowski: probably needs a merge from master and making sure it still works
<zyga> but now I need a break, my back is killing me
<mborzecki> need to run an errand, back in 1.5-2h, hopefully sooner
<mup> PR snapcraft#3048 opened: V2 dump plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3048>
 * zyga is pissed off at go fmt
<zyga> can we move to non-ancient go fmt
<zyga> it doesn't matter for compiling
<zyga> is anyone in the team still using "go fmt" from 1.6 because they cannot use newer go?
<zyga> I have to fight my editor to hand-craft restore some alignment
<pedronis> I made an alias go-fmt that calls the old go fmt from a snap installation fwiw, I'm also happy to discuss how to switch to something newer, but probably after the beta at this point
<mup> PR snapd#8516 opened: github: format with modern go <Created by zyga> <https://github.com/snapcore/snapd/pull/8516>
<mup> PR snapd#8516 closed: github: format with modern go <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8516>
<zyga> pedronis: huh
<pedronis> zyga: what part of until beta you didn't get?
<zyga> pedronis: I just read you writing that
<zyga> pedronis: and you could have just marked it as blocked or something
<zyga> pedronis: not nice
<pedronis> zyga: if we don't land it, it will need tending, so I don't see how marking it blocked helps
<pedronis> zyga: I don't know what people workflows are like, I don't think I want to even discuss that before beta
<pstolowski> it seems that jenkins deb is not authenticated in special-home-can-run-classic-snaps, despite adding the key in the test? i saw this test failing on some PRs
<mborzecki> re
<mup> PR core-build#59 opened: initramfs: add new handle_writable_defaults() <Created by mvo5> <https://github.com/snapcore/core-build/pull/59>
<mvo> pstolowski: ^- that is probably all we need, the interessting part if of course the next step where we test this :)
<mvo> pstolowski: we can look into this after the standup
<mvo> zyga: fwiw 8508 works, thanks again for your help with that
<pstolowski> mvo: oh thank you, i didn't expect you to take this! thanks!
<mvo> pstolowski: no worries, it's just a tiny step
 * mvo gets some lunch
<mvo> mborzecki: (8505 - your caching idea ftw!)
 * mvo really gets lunch
<mup> PR snapd#8517 opened: tests: temporarily allow unauthenticated jenkins deb <Created by stolowski> <https://github.com/snapcore/snapd/pull/8517>
<pstolowski> ^ a bit scary, perhaps we should disable the test for now..
<pedronis> so much weirdness
<pedronis> pstolowski: we probably need mvo input on that one
<mborzecki> cmatsuoka: hi, i seem to be getting a differnt output from lsblk --fs --json than the tests expect
<cmatsuoka> mborzecki: that sounds bad, what test?
<mborzecki> cmatsuoka: here's the test data vs what i get from the tool https://paste.ubuntu.com/p/qSCBCC44zF/
<mborzecki> cmatsuoka: the parsing only handles blockdevice.[i] elements, does not descend into blockdevice.[i].children[j]
<cmatsuoka> mborzecki: I think the test output is simulating the output when lsblk is called directly on the partition and not the disk
<mborzecki> aah w8
<mborzecki> right
<cmatsuoka> does it make sense?
<mborzecki> yeah, it does now
<mborzecki> meh, more mocking in tests :/
<cmatsuoka> ah ok good
<ijohnson> morning folks
<cachio> pstolowski, hei, there is a beg assigned to you, lp:1872115
<cachio> pstolowski, did you see that? is there a priority for that?
<cmatsuoka> hey ijohnson
<ijohnson> hey cmatsuoka o/
<cmatsuoka> cachio: I had problems with the tpm branches yesterday, will try the sb test again after the SU
<cachio> cmatsuoka, sure
<pstolowski> cachio: no, i didn't see that, thanks. i guess zyga assigned it to me because of my other rsyslog work, need to check
<cachio> cmatsuoka, ping me if you need any help
<ijohnson>  ugggh pulseaudio
<mup> Bug #1873452 opened: 'snap install' | "INFO Waiting for restart..." <Snappy:New> <https://launchpad.net/bugs/1873452>
<roadmr> hi diddledan are you around?
<diddledan> ello
<roadmr> diddledan: I got a request from the mycroft devs to have the snap transferred to them. Are you OK with that?
<diddledan> yup
<roadmr> sweet, ok thanks, all I needed was confirmation :) I'll take it from here
<roadmr> happy Friday
<diddledan> coolbeans :-)
<mup> PR snapd#8517 closed: tests: temporarily allow unauthenticated jenkins deb <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8517>
<mup> PR snapd#8518 opened: tests: disable special-home-can-run-classic-snaps due to jenkins repo issue <Created by stolowski> <https://github.com/snapcore/snapd/pull/8518>
<mup> PR snapcraft#3046 closed: plugins: introduce v2.GoPlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3046>
<pedronis> ijohnson: to be clear I'm not sure if there are different scenarios were we need that divergent snap, we don't with the current tests
<ijohnson> I don't think we will need it, I'm not sure what scenarios we could end up with that, where the kernel the bootloader boots is not the one we want as the "normal" kernel on the bootloader after MarkSuccessful runs
<pedronis> ijohnson: that sounds right
<pedronis> we still want to check before and after though
<pedronis> just for the same value, to be clear
<ijohnson> what do you mean check before and after?
<ijohnson> before and after the MarkSuccessful ?
<pedronis> yes
<pedronis> I suppose
<ijohnson> hmm ok I can make that work
<pedronis> ijohnson: I thougth, it's an easy change, we are probably talk cross-purpose
<mup> PR snapcraft#3049 opened: build providers: rename default sources <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3049>
<roadmr> jdstrand: hi, are you around?
<ackk> hi, I'm having an issue. my lxd snap suddenly broke, looking at /snap/lxd there's no snap dir there, just a broken "current" link
<jdstrand> roadmr: I'm here today but stepping away for a little bit. please ask and I'll answer when I get back
<ackk> and no lxd snap file in /var/lib/snapd/snaps
<roadmr> jdstrand: remember https://dashboard.snapcraft.io/snaps/inkscape/feedback/ timing out? it's because the page lists thousands of items. Are you OK with paginating that by e.g. 100 items at a time?
<mup> PR snapcraft#3050 opened: meta: split up package repository sanity checks <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3050>
<jdstrand> roadmr: I can answer that now
<jdstrand> roadmr: yes. please yes
<jdstrand> :)
<roadmr> \o/ hehe ok jdstrand we'll do it that way then
<jdstrand> zyga: you have mail :)
 * jdstrand steps away
<ackk> is there a way I can make snapd happy and mount the lxd snap again?
<popey> error: cannot communicate with server: timeout exceeded while waiting for response
<popey> My machine ^. Can't install or update anything.
<mup> PR snapcraft#3051 opened: project: introduce 'keys' for project assets <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3051>
<pstolowski> popey: journalctl -u snapd
<pstolowski> ?
<mborzecki> ijohnson: pushed the changes to https://github.com/snapcore/snapd/pull/8487 and marked it as ready for review
<mup> PR #8487: [RFC] gadget, cmd/snap-bootstrap: hack some things into place to get rpi4 semi-working <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<popey> https://paste.ubuntu.com/p/mDrRqBJNrZ/  pstolowski
<ijohnson> thanks mborzecki
<ijohnson> I'll give it a try on my pi today
<ijohnson> popey: can you still run snaps?
<pstolowski> popey: ok, not much interesting there, anything else in the logs?
<popey> yes, i can run snaps
<popey> i just can't refresh, or it does, but i get that error
<pstolowski> apparently deamon is not running
<stgraber> mvo, zyga: https://discuss.linuxcontainers.org/t/unable-to-start-snap-lxd-on-debian-10/7456/17?u=stgraber
<stgraber> this feels like pretty crap experience :)
<mvo> stgraber: in a meeting right now, but I though we did test lxd on debian :(
<zyga> mvo: reexec
<zyga> mvo: backports
<zyga> stgraber: can you add assumes to lxd?
<zyga> stgraber: and at least put a FAQ that you need to snap install core
<zyga> it will break in a nicer way IMO
<zyga> unless we update backports we have few optiosn
<zyga> *options
<zyga> stgraber: I totally agree about the UX
<pstolowski> popey: 'snap changes' fails the same I presume?
<mvo> yeah, assumes should fix things
<stgraber> zyga: where is the doc on assumes?
<popey> pstolowski snap changes returns immediately
<zyga> https://snapcraft.io/docs/snapcraft-top-level-metadata#heading--assumes
<zyga> stgraber: ^ add the assumess snapdX.YY version that meets your expectations
<stgraber> ah yeah, just found it too
<stgraber> zyga: so what's the minimum version that's known to behave?
<zyga> stgraber: perhaps we could patch snapd in debian 10 to say something like
<mup> PR snapcraft#3049 closed: build providers: rename default sources <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3049>
<zyga> stgraber: anyone that you pick as right for you
<zyga> stgraber: it depends on a snap
<stgraber> zyga: well, in this case the issue is apparently the snapd didn't connect any of the interfaces, so I have no idea when you fixed that :)
<pstolowski> popey: anything else in the logs? a crash/panic?
<zyga> stgraber: perhaps we could patch debian 10 snapd to say "you need snapd X.YY, you may try to get it from backports <URL> or by installing core"
<stgraber> zyga: we purposefuly don't use anything new/fancy in the snap
<popey> pstolowski not that I have seen :(
<zyga> stgraber: put a version that you tested as ok and that's enough
<zyga> stgraber: it's fine to depend on new snapd
<pstolowski> popey: and what does 'systemctl status snapd.service snapd.socket' say?
<zyga> pstolowski, popey: this is assertion check being >> than snap client timeout
<zyga> IIRC we ran into it before and debugged it to that
<zyga> but I could be wrong
<stgraber> zyga: looks like 2.39 and higher based on the versions our CI sees on the distros we test
<popey> pstolowski https://paste.ubuntu.com/p/zPcXzjtpNJ/
<pstolowski> zyga: can you elaborate on the assertion check, what do you mean?
<zyga> pstolowski: that's for stgraber
<zyga> pstolowski: it's unrelated to the issue you are looking at for popey
<zyga> I can explain if you want to, just wanted to make this clear
<pstolowski> ack
<pstolowski> popey: and 'snap --version' ?
<popey> https://paste.ubuntu.com/p/zNtPDNF8ns/
<zyga> pstolowski: to reproduce install 300 snaps
<zyga> and refresh
<popey> I have 113 installed
<zyga> pstolowski: if I'm correct your work on assertion refreshes will help immensly
<zyga> pstolowski: but would be good to undestand this in depth, perhaps there are other inefficiences
<zyga> (each from the store, not local)
<zyga> hmm, we could actually use
<pstolowski> zyga: i'm not working on assertion refreshes afaik ;)
<zyga> test-snapd-manysnap-$(seq...)
<zyga> in the store
<zyga> pstolowski: oh, sorry, I though that was in the new store API work
<zyga> anyway
<pstolowski> no i was new search v2 api
<pstolowski> *it*
<zyga> I see
<mup> PR snapcraft#3052 opened: build providers: wait for systemd and better nameserver setup on LXD <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3052>
<ijohnson> zyga: I thought pedronis was working on bulk assertion refreshes
<pstolowski> yes
<zyga> ijohnson: yeah, I must have confused the store work with "anything related to store"
<ijohnson> is this issue related to the internet? must be the store
<ijohnson> and that folks is how you do investigative work
<zyga> ijohnson: IIRC just that we cannot grab the lock
<zyga> ijohnson: needed to produce most "snap foo" responses
 * ijohnson was joking
<zyga> ah :)
<zyga> sorry
<ijohnson> I have no idea honestly what this issue is
 * zyga should really EOD
<zyga> I've reviewed half of James' user session services PR
<zyga> yeah, let's rest
<mup> PR snapd#8518 closed: tests: disable special-home-can-run-classic-snaps due to jenkins repo issue <Simple ð> <â  Critical> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8518>
<ijohnson> alright master should be at least not red due to jenkins again
<ijohnson> pstolowski: you wanna quick open up the PR re-enabling the jenkins test?
<ijohnson> if you want I can do it too
<pstolowski> popey: does ps aux|grep apparmor show anything?
<popey> no
<pstolowski> ijohnson: please do, thanks, trying to figure out popey's issue
<ijohnson> ack
<pstolowski> popey: how about 'sudo snap debug state /var/lib/snapd/state.json' ?
<popey> (that looks like snap changes)?
<popey> https://paste.ubuntu.com/p/wHXFrdQhJ2/
<pstolowski> popey: yes, but it doesn't talk to the daemon
<popey> ahh
<pstolowski> popey: does 'snap list' work?
<popey> yes
<pstolowski> popey: ah, so snapd does respond, i got confused by that first communication error. perhaps store is acting up? how about 'snap find ...'?
<popey> snap find works
<popey> bah, now I'm not getting the error when I refresh!
<zyga> pstolowski: my theory is wrong, based on the debug output
<pstolowski> popey: i bet that was a store problem, maybe of limited scope (i was testing with same snapd as you have without issues)
<pstolowski> popey: there was no sign of snapd errors/malfunction in the info you got me so far
<ijohnson> popey: how performant is this machine with 116 snaps? and also what kind of disk is it on?
<ijohnson> popey: given that it keeps finding bugs, maybe turning on debug logging for snapd would be a good idea, even maybe http debug logging too
<popey> it's an ThinkPad T450, i7, 32GB RAM
<popey> brb, meeting
<ijohnson> pedronis: if you have time yet today, 8511 is updated with your comments
<ijohnson> ah actually I forgot one thing, let me push that quickly
<pstolowski> eow, cu all!
<mup> PR snapd#8409 closed: snap-bootstrap: seal and unseal encryption key using tpm <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8409>
<cmatsuoka> \o/
<pedronis> ijohnson: yes, I'll try to wrap up a couple of things and some reviews after dinner
<ijohnson> thanks pedronis
<ijohnson> congrats cmatsuoka !
<cmatsuoka> ijohnson: many fixes still to come
<pedronis> cmatsuoka: can you merge master into your locking keys PRs now
<cmatsuoka> pedronis: doing that right now
<pedronis> thx
<cmatsuoka> cachio: ok, ready to run the sb/tpm tests
<cachio> nice
<cmatsuoka> cachio: I'm using your spread, which back-end should I use?
<mup> PR snapcraft#3051 closed: project: introduce 'keys' for project assets <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3051>
<cmatsuoka> cachio: and should I run on master or tests-extend-uc20-nested-suite?
<cachio> cmatsuoka, you should use the google-tpm I sent yesterday
<cachio> which test do you want to run?
<cmatsuoka> uc20-create-partitions-encrypted
<cachio> you should add this new tpm backend to the spread.yaml
<cmatsuoka> ah yes, I remember now, let's do this
<cachio> and run spread -debug google-tpm:ubuntu-20.04-64:tests/main/uc20-create-partitions-encrypted
<cachio> cmatsuoka, when you run this please tell me so I can monitor the vm
<mup> PR snapcraft#3050 closed: meta: split up package repository sanity checks <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3050>
<mup> PR snapcraft#3053 opened: snap_packaging: quote final LD_LIBRARY_PATH <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/3053>
<mup> PR snapcraft#3054 opened: Add note about docker snap <Created by sixcorners> <https://github.com/snapcore/snapcraft/pull/3054>
<mup> PR snapcraft#3048 closed: V2 dump plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3048>
<mup> PR snapcraft#3052 closed: build providers: wait for systemd and better nameserver setup on LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3052>
<mup> PR snapcraft#3055 opened: repo: add identifiers for gpg keys and sources <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3055>
<bdx> hello
<bdx> I'm trying to release a snap that uses classic confinement, and need an approval to release it to the snap store. I have started a discourse post here https://forum.snapcraft.io/t/classic-confinement-request-for-nhc-snap
<bdx> is there someone from the reviewers team available to possibly give some feedback ^?
<bdx> thanks!
<mup> PR snapcraft#3056 opened: remote-build: package up local sources with source-type 'git' <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3056>
<mup> PR snapd#8325 closed: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mup> PR snapd#8514 closed: interfaces/openvswitch: support use of ovs-appctl <Created by dosaboy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8514>
<mup> PR snapcraft#3057 opened: repo: format $SNAPCRAFT_APT_RELEASE instead of ${release} for suites <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3057>
<mup> PR snapcraft#3055 closed: repo: add identifiers for gpg keys and sources <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3055>
<pedronis> ijohnson: I reviewed #8511
<mup> PR #8511: tests/boot: refactor to make it easier for new bootloaderKernelState20 impl <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8511>
<ijohnson> thanks pedronis
<ijohnson> Have a good weekend!
 * ijohnson continues fighting the pi 
<mborzecki> ijohnson: hey, saw your comment, pushed a patch
<ijohnson> hey mborzecki thanks let me look now
<ijohnson> I locally had a simple patch to work around it, but didn't push anything cause I wasn't sure what the right way to do it is
<mborzecki> ijohnson: missed that ensure layout compatiblity check, but it shoudl be ok now
<ijohnson> ah yeah I think your check is better, I forgot that the gadgetLayout has Schema on it to check that it's mbr
<mborzecki> ijohnson: i mean, there's nothign we can check there if there's no way store the name on disk :P so well
<ijohnson> true
<mborzecki> as long as we don't erase ubuntu-seed things should be ok xD
<mborzecki> what reminds me i need to discuss gadget updates in uc20 on monday
<mborzecki> ijohnson: anyways, thanks for catching that! hope it works now
<mup> PR snapd#8511 closed: tests/boot: refactor to make it easier for new bootloaderKernelState20 impl <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8511>
<mup> PR snapcraft#3058 opened: package-repositories: make 'name' optional <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3058>
<mup> PR snapd#8423 closed: tests: uc20 nested suite part II <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8423>
<mup> PR pc-amd64-gadget#42 closed: Hide menu by default <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/42>
<mup> Issue pc-amd64-gadget#41 closed: Hide the menu by default <Created by xnox> <Closed by xnox> <https://github.com/snapcore/pc-amd64-gadget/issue/41>
<mup> PR pc-amd64-gadget#37 closed: Drop duplicate grub.cfg-* <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR core20#43 opened: extra-packages: add dbus-user-session for user-session dbus <Created by xnox> <https://github.com/snapcore/core20/pull/43>
<mup> PR snapd#8519 opened: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
<mup> PR core20#44 opened: travis: use bionic <Created by xnox> <https://github.com/snapcore/core20/pull/44>
<mup> PR core20#44 closed: travis: use bionic <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/44>
<mup> PR core20#45 opened: Add arches <Created by xnox> <https://github.com/snapcore/core20/pull/45>
#snappy 2020-04-18
<mup> PR snapcraft#2854 closed: Core20 <Created by sd-hd> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2854>
<mup> PR snapcraft#3057 closed: repo: format $SNAPCRAFT_APT_RELEASE instead of ${release} for suites <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3057>
<mup> PR snapcraft#2859 closed: meson plugin: add support for core20 <Created by sd-hd> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2859>
<mup> PR snapcraft#2896 closed: Fix the package 'python3-distutils' not found on Ubuntu Xenial <Created by khiemdoan> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2896>
<mup> PR snapcraft#2544 closed: Remove legacy --no-compile option given to pip <Created by tonysimpson> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2544>
<mup> PR snapcraft#3058 closed: package-repositories: make 'name' optional <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3058>
<mup> PR snapd#8520 opened: Fixing shellcheck warnings <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
<mup> PR snapcraft#3059 opened: plugins: introduce v2.MesonPlugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3059>
<mup> PR snapcraft#3056 closed: remote-build: package up local sources with source-type 'git' <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3056>
<mup> PR snapcraft#2944 closed: add github action ci/cd <do-not-merge> <Created by sd-hd> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2944>
<mup> Issue core20#12 closed: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 closed: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#34 closed: please provide dbus-launch <Created by zyga> <https://github.com/snapcore/core20/issue/34>
<mup> PR core20#11 closed: Add arm64 architecture <Created by xnox> <https://github.com/snapcore/core20/pull/11>
<mup> PR core20#43 closed: extra-packages: add dbus-user-session for user-session dbus <Created by xnox> <https://github.com/snapcore/core20/pull/43>
<mup> PR core20#45 closed: Add arches <Created by xnox> <https://github.com/snapcore/core20/pull/45>
<mup> Issue core20#12 opened: Drop consoleconf from the core snap <question> <Created by xnox> <https://github.com/snapcore/core20/issue/12>
<mup> Issue core20#32 opened: The machine-id file should be writable <question> <Created by zyga> <https://github.com/snapcore/core20/issue/32>
<mup> Issue core20#34 opened: please provide dbus-launch <Created by zyga> <https://github.com/snapcore/core20/issue/34>
<mup> PR core20#11 opened: Add arm64 architecture <Created by xnox> <https://github.com/snapcore/core20/pull/11>
<mup> PR core20#43 opened: extra-packages: add dbus-user-session for user-session dbus <Created by xnox> <https://github.com/snapcore/core20/pull/43>
<mup> PR core20#45 opened: Add arches <Created by xnox> <https://github.com/snapcore/core20/pull/45>
<mup> PR snapcraft#2892 closed: Add snapcraft plugin for Qt Build Suite (qbs) <Created by bjorn> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2892>
<mup> PR snapcraft#2834 closed: dirs: support --user install on Linux <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2834>
<mup> PR snapcraft#3054 closed: Add note about docker snap <Created by sixcorners> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3054>
<mup> Bug #1873363 changed: openvswitch interface support for ovs-appctl <snapd:In Progress by hopem> <https://launchpad.net/bugs/1873363>
<mup> PR snapcraft#3060 opened: V2 npm plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3060>
#snappy 2020-04-19
<mup> PR snapcraft#3053 closed: snap_packaging: quote final LD_LIBRARY_PATH <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3053>
<mup> PR snapcraft#3061 opened: V2 rust plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3061>
<mup> PR snapd#8521 opened: snap-bootstrap,secboot: clear tpm if provisioning fails <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8521>
<mup> PR snapcraft#3059 closed: plugins: introduce v2.MesonPlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3059>
<mup> PR snapcraft#3062 opened: tests: stub job to get autokpgtest for edge <do-not-merge> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3062>
