#snappy 2015-07-27
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Monday, and happy Walk on Stilts Day! ð
 * Chipaca winces
<JamesTait> Chipaca, what could possibly go wrong?
<Chipaca> JamesTait: with *my* balance and co-ordination? *EVERYTHING*
<Chipaca> oh, maybe i forgot to mention my endemic bad luck also :)
<JamesTait> Chipaca, I never got the hang of it myself. But then I probably should have tried for more than a couple of minutes.
<ogra_> phew .. so much fallout
<ricmm> ogra_: of?
<ogra_> ricmm, https://plus.google.com/+OliverGrawert/posts/iF5CqLtFEAR?cfem=1
<ogra_> ricmm, which turned into http://news.softpedia.com/news/kde-s-plasma-mobile-not-giving-credit-to-ubuntu-touch-says-developer-487806.shtml
<ogra_> (which got me a bit of mail and comments ... )
<ricmm> :)
<ricmm> not sure about continuing to reply in that g+ post
<ricmm> it will clearly go to flameland
<ogra_> yeah, it atarted to get quieter now, i surely wont stir it up again :)
<svij> ogra_: I like this part: "how about we talk about it over a beer at #ubucon ? ;)ï»¿" ;-)
<ogra_> ;)
<ogra_> sadly he didnt answer it
 * ogra_ wanted to trigger commitment that some KDE people would show up :)
<svij> martin grÃ¤Ãlin showed up 2012 + 2013
<svij> (at ubucon de)
<ogra_> well, after his mir battling i doubt he will this time
<svij> yeah :(
<Chipaca> ogra_: the part that yanks my chain on that is their explicitly announcing it as "free of corporate [somethingorother]"
<Chipaca> which i read as canonical (amongst others, sure)
<ogra_> hah, i didnt even notice that yet :)
<svij> Blue Systems is based in Bielefeld and all Germans know, that Bielefeld doesn't exist. So it's kinda true. :P
<ogra_> hahaha
<ogra_> oh !
<ogra_> sebas commented ...
 * Chipaca ~> luncheon
<Chipaca> that's like a lunch that lasts an eon \o/
<elopio> good morning.
<rsalveti> ricmm: ogra_: would be fun to compare performance between wayland and mir though
<rsalveti> since it's using ubuntu-touch anyway
<lool> rsalveti: oh the plasma thing is on wayland? interesting
<lool> I thought they were on mir for that demo
<rsalveti> lool: http://vizzzion.org/blog/2015/07/embracing-mobile/
<rsalveti> I would need to check the src code for it, but I'd assume they are using wayland
<rsalveti> libhybris enables both wayland and mir
<rsalveti> which is why it would be nice to compare both :-)
<lool> rsalveti: right, I saw the video but in the context of a quite limited french translation of the original
<rsalveti> it might generate some great flames :-)
<lool> haha
<ogra_> they are using wayland
<lool> yeah, the blog post keeps rehashing that point
<ogra_> after being bashed for two days after my post i can tell you for sure it is wayland ;)
<lool> ogra_: I give you credit for a good flame
<ogra_> lol
<ogra_> rsalveti, isnt wayland still limited to only a few android drivers though ?
<rsalveti> ogra_: same drivers as we are
<rsalveti> in the end it's all libhybris
<ogra_> ah, i thought thesir situation was worse ... http://www.jlekstrand.net/jason/projects/wayland/wayland-android/
<rsalveti> our situation is not so much better
<rsalveti> which is why we always end up requiring changes at the driver side
<ogra_> ah
<ogra_> mterry, hmm, so snapcraft wont support multiarch snaps ?
<ogra_> thats quite a drawback
<mterry> ogra_, well it doesn't right now anyway
<rsalveti> ogra_: we don't plan to block that work, but don't want to solve that now
<mterry> ogra_, the plan seems to be to build multiarch/crossbuilding support on top of snapcraft via comfy and such
<ogra_> ok
<rsalveti> ideally the store would allow multiple uploads for multiple archs
<ogra_> well, as long as i dont have to have a foo-armhf and a foo-x86 snapy that i need to inependently maintain
<rsalveti> but, until that is done, we'd need some sort of helper to mix both snaps and create a fat package
<ogra_> *snap
<ogra_> right
<beuno> ...and we'll support separate binaries for separate arches in the store in the mid-term
<ogra_> i thought that was what snapcratf was upposed to do ...
<ogra_> beuno, yes, but i dont want them :)
<rsalveti> snapcraft is about helping you creating one snap
<ogra_> as a maintainer i dont want to have to care for different trees and packages :)
<beuno> ogra_, the store will support both
<rsalveti> right, we'll get there
<ogra_> but as long as we can have somethin on top that can merge both ... or if it is easy to script something around that. i'm fine
<rsalveti> ogra_: all good with 132 then, right?
 * rsalveti resuming the release process
<rsalveti> let me push that to alpha
<ogra_> rsalveti, if QA doesnt have anything .-.. and if we are happy with the missing rollback, yes
<rsalveti> and give it another round of tests
<rsalveti> unfortunately, not much we can do in there
<ogra_> yeah
<rsalveti> alpha here we go
<rsalveti> elopio: ogra_: fgimenez: upadte from 8->9->8 should work now
<rsalveti> at least that's the hope :-)
<ogra_> it did between 131 and 132 at least
 * ogra_ rolls an alpha image
<fgimenez> rsalveti, ok, on it
<ogra_> grrr
<ogra_> forgot to use --revision
 * ogra_ starts over
<fgimenez> rsalveti, 8 -> 9 -> 8 goes fine here, i'm executing now the automated suite against 9
<rsalveti> cool
<vmayoral> ogra_: is there any way to install OEM snap without using the ubuntu-device-flash tool (dev purposes)?
<ogra_> i dont think there is
<beuno> vmayoral, you mean, to update a client, for example?
<beuno> or a genuine fresh install of the OEM snap to a running client who hasn't installed it before?
<vmayoral> ogra_, beuno: let me rephrase it: I'm making changes in our OEM snap and everytime i want to install it (to test it), do i need to create a new image?
<ogra_> rsalveti, i'm still getting the "cant find vmlinuz" ... beyond that the upgrade looks good
 * ogra_ reboots and rolls back
<rsalveti> ogra_: yeah, that's expected because of the system-image issue
<ogra_> right
<rsalveti> no kernel differences
<ogra_> we need to mention it in the release notes
<beuno> vmayoral, I think if it was part of the original installed image, you should be able to push to the device and just upgrade
<rsalveti> it should work just fine when migrating to stable
<rsalveti> because it's a different kernel
<ogra_> because it swallows the "reboot required" message
<rsalveti> ogra_: is there a way to remove an image from the channel easily?
<vmayoral> beuno: that makes sense, but that'll imply having the OEM snap already accepted in the store
<rsalveti> would be nice to simulate the stable again, since we got so many more images in alpha
<ogra_> rsalveti, hmm, i've never done that ...
<rsalveti> maybe creating a temporary channel or some sort of it
<rsalveti> need to think
<vmayoral> beuno: isn't there a quick way of changing the OEM snap for dev purposes?
<beuno> vmayoral, oh, you should be able to sideload the oem snap
<ogra_> are you sure ?
 * ogra_ isnt so sure that works
<vmayoral> beuno: could you explain what you mean by "sideloading" the oem snap?. I've seen the ".sideload" in a few test snaps i've made in the last days but didn't quite get it
<beuno> vmayoral, sideloading is installing outside of the store, for development purposes
<beuno> it's lterally pushing the snap and installing it locally
<beuno> to allow for fast development cycles
<beuno> you will have to pass in a flag, --allow-untrusted or something similar
<ogra_> scp it it and "snappy install /path/to/snap" ...
<beuno> so it skips checking the signature
<ogra_> or you use snappy-remote from a remote machine
<vmayoral> beuno, ogra_: thanks for explaining, tried that with the "--allow-unauthenticated" flag
<vmayoral> and that doesn't help with the oem snap
<vmayoral> it seems to be restricted somehow
<ogra_> yeah, i expected that
<beuno> hm
<beuno> so we need to fix that
<beuno> cc rsalveti ^^
<beuno> iterating on the OEM snap
<sergiusens> ogra beuno: vmayoral oem snaps can't be sideloaded
<Chipaca> vmayoral: beuno: i don't think you can sideload the oem snap yet
<Chipaca> vmayoral: beuno: you can tell u-d-f to use a local one though afaik
<sergiusens> u-d-f --oem [oem.snap] --developer-mode
<Chipaca> sergiusens: golang and python's standard libraries both check http_proxy and HTTP_PROXY :)
<vmayoral> sergiusens, Chipaca: searched for "u-d-f" but didn't find anything, mind pointing out where can i find that tool?
<Chipaca> vmayoral: ubuntu-device-flash
<vmayoral> silly me, thanks!
<beuno> Chipaca, sergiusens, sounds like we at least want to document this piece
<beuno> how to iterate on OEM snaps
<elopio> fgimenez: I can take your fix-expected-yaml-parse-error branch and extend it to make all the tests pass in 15.04.
<elopio> I think that would be a good use of my time today.
<fgimenez> elopio, ok, that would be great :)
<fgimenez> elopio, about the refactoring card, we could begin by extracting the build and adtrun code to helpers, what do you think?
<elopio> fgimenez: yes, that would be good too. Want me to start?
<fgimenez> elopio, as you like, if you don't finish it i can continue tomorrow
<elopio> fgimenez: if we want to test those, we can use the link Chipaca sent. http://npf.io/2015/06/testing-exec-command/
<elopio> I'm not yet sure how much I want to test them, but adding a couple of tests never hurts.
<fgimenez> elopio, ok looks very good
<Chipaca> ogra_: sergiusens: but s-i uses https to get the image, which makes proxying it a little bit harder :-(
<ogra_> Chipaca, it is really not *that* important (as long as core stays small)
 * Chipaca considers making a wwwwoffle snap
<fgimenez> elopio, about executing the suite from tarmac, maybe we can reuse part of the snappy-tests-job, or autopkgtest's nova script
<vmayoral> sergiusens, Chipaca: tried using "--oem" in u-d-f, that option is not available anymore
<vmayoral> just updated snappy-tools to make sure i've got the latest
<vmayoral> same result
<elopio> fgimenez: you tell me. We can change the .tarmac.sh to be anything, like a call to snappy-test-job's main, or  two calls, one to provision and one to _integration-tests/main
<fgimenez> elopio, we can try both approaches, the nova script makes a lot of sense, but we should fork and modify it
<rsalveti> vmayoral: which version of u-d-f are you using?
<sergiusens> vmayoral: ubuntu-device-flash core rolling --oem [.snap]
<rsalveti> right, --oem needs to be after core
<rsalveti> ubuntu-device-flash core --help
<vmayoral> rsalveti: https://gist.github.com/vmayoral/90da57bebc20ada52f56
 * vmayoral is removing u-d-f and reinstalling it
<rsalveti> looks like an old version
<rsalveti> try the one from https://launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed
<rsalveti> we're migrating it to https://launchpad.net/~snappy-dev/+archive/ubuntu/tools later today
<rsalveti>  goget-ubuntu-touch 	0.27-0ubuntu1
<vmayoral> ok, let me write that down, will try it again later and give feedback, thanks
<kyrofa> seb128, have you had any time to check out https://code.launchpad.net/~kyrofa/ubuntu-seeds/ubuntu-touch.wily_add_unity-scope-snappy/+merge/265568 ?
<seb128> kyrofa, no
<seb128> sorry, busy on other things atm
<seb128> but maybe ogra_ or mvo can help you
<kyrofa> seb128, alright, thanks!
<kyrofa> ogra_, ^^ trying to get the snappy scope into the Ubuntu Personal seed, if you have any time to check it out
<seb128> kyrofa, sorry about that, I need to spend some cycles on wily work but I plan to go back to snappy personal in a few days
<ogra_> seb128, hmm, does that use a metapackage ? do you knwo ?
 * ogra_ can indeed just merge the seed
<kyrofa> seb128, that's quite alright, I understand!
<ogra_> i'm just not sure the meta is actually used for the snappy image
<seb128> ogra_, yes, the seed are used to build the iso
<ogra_> yes, i know how tezh iso works ... for snappy core we dont have a metapackage though, it uses germinate directly
<seb128> unsure what desktop does, it's based on what core does I think
<seb128> in any case the seed need to be updated no?
<ogra_> yeah
<kyrofa> ogra_, seb128 do I need to make a MP elsewhere as well?
<ogra_> kyrofa, hmm, i cant merge it ... i think the desktop-next part actually comes from the touch seed
<kyrofa> ogra_, not the desktop seed?
<ogra_> lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/
<ogra_> and in there the desktop file
<seb128> correct
<kyrofa> ogra_, I'm confused... isn't that what this MP is against?
<ogra_> oh
<ogra_> silly me
<ogra_> kyrofa, merged and pushed (might need a meta package rebuild though, but the seed should be fine now)
<kyrofa> ogra_, thank you! I'm unfamiliar with the meta package to which you're referring
 * ogra_ too ;)
<kyrofa> Oh :P
<ogra_> if there is one, i guess Laney knows about it
<kyrofa> ogra_, walk me through that real quick-- I generate an Ubuntu Personal image using u-d-f personal rolling --channel edge . Magic happens, and I have an image
<Laney> for what?
<Laney> desktop-next -> ubuntu-touch-meta
<ogra_> Laney, desktop-next ... does the snappy build use a meta package ? (core doesnt, thats why i ask)
<ogra_> ah, ok, even on snappy then
<Laney> it uses the tasks
<Laney> but the metapackage exists
<Laney> (IIRC)
<ogra_> bah
<ogra_> ogra@anubis:~/Devel/packages/ubuntu-touch-meta-1.234$
<Laney> Â»Â·Â·Â·Â»Â·Â·Â·add_task install minimal standard ubuntu-desktop-next ubuntu-sdk-libs
<ogra_> i really really dont want to update that ... look at the version !
<Laney> ya
 * ogra_ tries to overcome the resistance to break that beautiful schema
<kyrofa> Hahaha
<kyrofa> A month down the road ogra_ gets hit with "Why is ubuntu-touch-meta on 1.2.34-0ubuntu145?
<kyrofa> "
<ogra_> heh
<kyrofa> ogra_, are you taking care of that, then? Or do I need to do something?
<ogra_> yes, the metapackage is already updating here, that takes a bit
<ogra_> i'll upload it then
<ogra_> nothing to do for you
<seb128> ogra_, thanks
<seb128> the next time I look at the personal image maybe the snappy scope works out of the box ;-)
<seb128> but I need to deal with some desktop backlog and look at that gcc5 transition this week, before going back to snappy
<kyrofa> seb128, hey, take care of that desktop stuff, it's important to all of us :P
<seb128> :-)
<kyrofa> ogra_, thank you for your time and help :)
<ogra_> np
<ogra_> and uploaded ... next image build should have your scope
<kyrofa> ogra_, fantastic!
<zeromon_> Why does Ubuntu use snappy instead of using apt-get?
<elopio> \o/ all tests passing in 15.04 edge.
<beuno> zeromon_, why does Ubuntu Snappy use snappy instead of apt-get?
<zeromon_> beuno: ye.. sorry that is what I want to ask exactly..
<beuno> zeromon_, I don't understand the underlying question. This flavor of Ubuntu is based around the fact that it doesn't use debian packages
<beuno> is your question why this flavor exists?
<beuno> I mean, Ubuntu with apt-get is just classic Ubuntu
<beuno> which still exists, obviously
<ogra_> and wont go away any time soon
<zeromon_> beuno: I mean... Are there some significant benefits??? Or Ubunt wants to have their own packaging system... What is the point?
<ogra_> yes, there are plenty of benefits ...
<beuno> zeromon_, so, I can't tell if you're just here to troll, but lets give it a go
<ogra_> (rollback abilities, diff upgrades, no dependencies, to just name a few)
<beuno> let me find you some information about why this flavor doesn't use debs
<beuno> https://developer.ubuntu.com/en/snappy/
<beuno> there's some high-level information
<ogra_> well, technicallly we use debs ... to build the images :)
<zeromon_> beuno: I am not to troll here. I am very curious what the difference is..
<ogra_> and you will also be able to create a snap out of a bunch of deb packages
<zeromon_> ogra_: thanks for kind explanation
<ogra_> so if you have a project ... say "mailserver" ... you can create a snap that contains postfix, dovecot and all the bits and pieces to have a fully functional mailserver setup in a single snap (and the snap will be able to give you access to settings via the snappy config commabnd)
<beuno> zeromon_, and on a lower level than that link, here's some information on security benefits: https://penguindroppings.wordpress.com/2015/01/30/snappy-app-trust-model/
<beuno> well, and many other benefits
<zeromon_> thanks fot information. I am trying to understand it.
<zeromon_> Can I install Ubuntu snappy core on the normal PC?
<elopio> Chipaca: sergiusens: could you please check if we have too many packages in there? http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/_integration-tests/helpers/
<elopio> I'm have the feeling that things are conceptually and functionally different, but it feels weird to have one package per go file.
<sergiusens> elopio: too many packages? doesn't seem so; if anything I just don't like calling things 'helpers' :-P
<elopio> zeromon_: you can install it now in a kvm: https://developer.ubuntu.com/en/snappy/start/#snappy-local
<elopio> at some point in the future you will be able to install the ubuntu personal flavor.
<elopio> sergiusens: I didn't want to have that folder, but otherwise I can't distinguish between integration tests, and the other tests.
<zeromon_> elopio: thanks a lot
<elopio> sergiusens: if you can think of a better name, or a way to exclude a package from the test run, please let us know.
<sergiusens> elopio: testutils?
<sergiusens> elopio: I don't mind the folder, I just don't like the generic name ;)
<elopio> testutils and _integration-tests/helpers sound like the same for me, but if you are happy with that, I'm happy.
<elopio> sergiusens: is it ok put some files in testutils/ and some files in testutils/config, for example?
<sergiusens> elopio: yes
<sergiusens> elopio: look at path and path/filepath
<sergiusens> elopio: http://golang.org/src/path/
<elopio> right.
<elopio> so the current helpers/utils/utils.go should probably live in testutils/utils.go
<elopio> probably some things from helpers/common/common.go should be there too.
<elopio> and instead of common, we should name it base, or something like that.
<sergiusens> elopio: ah, I thought you were only talking about layout, I have no idea what is expected of each package, we can look at that too
<elopio> sergiusens: yes, federico wants to split things because main and common are too big. So I will be sending some branches.
<elopio> please leave your suggestions on the MPs.
<ted> Is there a reason we don't have snappy generic images for arm and other arches?
<beuno> ted, from what I know, there is no such thing as generic arm, due to booting
<beuno> and the x86, AFAIK, is generic
<ted> beuno, Then what does qemu-arm take?
<beuno> ted, some form of specific arm?  :)
<beuno> my understanding is that ARM doesn't have a standard for booting, so you need a different kernel for each, many times with trivial differences
<rsalveti> it's as generic as the kernel is
<rsalveti> as long the kernel supports qemu-arm (which is probably the case), we only need the generic oem for it
<rsalveti> similar to what we have for amd64
<rsalveti> beuno: we do have a standard in there, the generic armhf kernel we have is indeed generic
<rsalveti> the hardware specific part is described by the device tree
<rsalveti> the problem is that not necessarily every hardware is supported by the upstream kernel
<ted> Sure, but I only need QEMU's CPU and networkng.
<rsalveti> right, I believe it might be easy to support that, but would required a generic oem
<rsalveti> in the past we had omap3 targets in qemu, not sure how well supported is that atm
<ted> Would be handy if I could build these docker images on Snappy, just so it's all the same version of docker, etc.
<rsalveti> ted: well, you could simply have a docker image with ubuntu and build the docker image inside that docker image :-)
<kickinz1> ted, you can
<rsalveti> docker inception
<ted> Heh, yeah.
<rsalveti> utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable
<rsalveti> or latest edge (132)
<rsalveti> utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets?
<rsalveti> beuno: sergiusens: why is the mir framework showing up on webdm even on armhf?
<rsalveti> afaik it's only amd64
<ted> rsalveti, I can't seem to find a prebuild .img file for ARM on cdimage, do you know of one I'm missing?
<rsalveti> ted: we only have for beaglebone
<ted> rsalveti, For snappy, is there one for deb-based Ubuntu?
<rsalveti> maybe just the tarball
<rsalveti> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/
<rsalveti> let me look
<rsalveti> guess only the tarball indeed
<ted> Bummer, was hoping to not have to build the image.
<sergiusens> rsalveti: probably marked as arch all
<sergiusens> rsalveti: oh, it's not...
<sergiusens> rsalveti: it still has no alias
<rsalveti> right, but would that have anything to this issue?
<sergiusens> rsalveti: no, the snappy client (webdm in this case) just sends a request with X-Architecture: amd64 and the store returns the results
<rsalveti> right
<rsalveti> so probably something for beuno to check
<sergiusens> rsalveti: curl -s -H 'accept: application/hal+json' -H "X-Ubuntu-Release: 15.04-core" -H "X-Ubuntu-Architecture: armhf" "https://search.apps.ubuntu.com/api/v1/search?q=mir" | python -m json.tool
<sergiusens> works fine
<sergiusens> setting to amd64 makes it return
<sergiusens> rsalveti: what image?
<sergiusens> I can check
<rsalveti> sergiusens: hm, maybe I ended up messing up with my ips in here
<rsalveti> I think it might end up being the amd64 one
<rsalveti> doing testing in parallel
<rsalveti> sergiusens: beuno: yeah, my mistake
<rsalveti> sorry for the noise
<sergiusens> rsalveti: no worries, was going to be my next question :-)
<sergiusens> rsalveti: fwiw, the banners should be different in webdm
<rsalveti> sergiusens: yeah
<sergiusens> rsalveti: even in cli ;-)
<rsalveti> sure :-)
<rsalveti> the problem of doing many things in parallel
<kgunn> just curious, i've a snap (& client) that i'm working to make confined
<ted> rsalveti, All the instructions I can find for building an img assume you can chroot into it to install stuff. Is there a way to cross build an img?
<kgunn> i had the mir server confined and running reliably, just rebuilt (as i had done a few times before)
<kgunn> and now getting "new" denials
<kgunn> anyone seen something strange like that ?
<rsalveti> ted: rootstock-ng is one way, you can give qemu-arm-static to debootstrap
<rsalveti> http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch
<rsalveti> it's currently touch focused, but might be easy to change to produce a core image instead
<kgunn> mterry: for your deb2snap, i looked, but you're not injecting "unconfined" templates  are you? ( i see you do for xmir...but that shoulndt effect me)
<ted> rsalveti, K, let me give that a try
<mterry> kgunn, not by default.  You can pass --aa-template unconfined or something like that to make it unconfined
<mterry> kgunn, but without arguments, we use default confinement
<kgunn> mterry: ok, and nope...actually trying to make sure it's confined
<kgunn> just seeing weird stuff
<rsalveti> ted: also make sure to use https://launchpad.net/~snappy-dev/+archive/ubuntu/image since we got a specific livecd-rootfs version in there
<rsalveti> and this ppa is also used when creating the image
<mterry> kgunn, hrm.  You can always check the resulting snap's package.yaml file
<sergiusens> Chipaca: jdstrand is /var/lib/apparmor/clicks still needed or can we do with just .../snappy ?
 * kgunn suspects he's done too much to this image and vmm project files...blows aways and starts fresh
<jdstrand> sergiusens: it is needed as long as click-apparmor is around
<jdstrand> which abviously is meant to go away
<jdstrand> the dir could obviously be changed
<sergiusens> jdstrand: k, just seeing we have /var/lib/apparmor/[snappy|clicks] ... but I don't have snappy proper running right now to double check they are the same
#snappy 2015-07-28
<biezpal> guys, we need to create additional users to Snappy Ubuntu. How we should do this in proper way?
<dholbach> good morning
<fgimenez> good morning dholbach and all
<dholbach> hey fgimenez
<ogra_> grumble ... ubuntu-fan ... grumble
<JamesTait> Good morning all; happy Milk Chocolate Day! ð
<davmor2> ogra_: You know when you add the grumbles you sound less of a fan and more of a stalker right ;)
<ogra_> heh
<ogra_> hmpf ... i dont et it
<ogra_> *get
<Chipaca> ogra_: ?
<ogra_> buildin an armhf rootstock rootfs always fails with dependency issues
<ogra_> and its the same missing deps no matter what release i use
<ogra_> amd64 vivid is up to now the only one i manaed to get to build
<ogra_> wily fails there too
<ogra_> (though not dep issues)
<Chipaca> ogra_: is it bad that i don't know what rootstock is in this context? (i assume you're not building a social investment society)
<ogra_> http://paste.ubuntu.com/11953230/ i really dont know what to make out of that ... it is using the stable archive
<ogra_> oh
<ogra_> perhaps it should also use -updates
<ogra_> Chipaca, a rootfs builder tool ... project-rootstock-ng on launchpad
<Chipaca> ogra_: otherwise, check with barry maybe? he's usually ontop of python weirdness :)
<ogra_> well, this is vivid ... we build regular snappy imaes from it :)
<ogra_> *images
<ogra_> rootstock uses exactly the same setup as the livefs builders so theoretically there is no reason for it to fail if the official images build
 * ogra_ tries adding -updates to the sources.list
<ogra_> OOOOH !
 * ogra_ slaps forehead
<ogra_> the snappy livecd-rootfs comes from the PPA
<ogra_> so indeed i'm missing all the hacks
<ogra_> hmpf, adding -updates doesnt change a thing
<longsleep> ogra_: hey - any news about getting a stable snappy 15.04 with the uboot.env changes?
<ogra_> longsleep, rsalveti wanted to release it last night, seems that didnt happen
<ogra_> not sure why
<longsleep> ogra_: ok thanks - i will keep monitoring then :)
<jdstrand> sergiusens: /var/lib/apparmor/clicks and /var/lib/snappy/apparmor are different. basically, /var/lib/snappy/... is where we want to go and I started to go there with seccomp. /var/lib/apparmor/... is where we want to move from and we'll do that when click-apparmor is gone
<ogra_> jdstrand, is anyone from the security team looking into the libstagefright issue on the phone (sorry for the echan)
<ogra_> sounds pretty serious even for us
<Chipaca> elopio: you around?
<elopio> Chipaca: o/
<elopio> how can I help you?
<Chipaca> elopio: integrations test asplode nicely in wily
<Chipaca> elopio: here i was all excited because they should finally work again (because networking is working \o/)
<Chipaca> very disappointed; i thought i'd be able to convert "made integration tests work again on wily" into "get bottle of aged rum from elopio"
<elopio> Chipaca: I'm not sure if I should be happy or sad.
<elopio> Chipaca: throw the log at us. fgimenez is using wily, so he should be able to tell what's going on.
<Chipaca> http://pastebin.ubuntu.com/11953399/
<elopio> I'm just running in vivid, and it works.
<elopio> Chipaca: your udf failed
<rsalveti> ogra_: waiting to see if we could get any update from utlemming
<rsalveti> but will release it later today
<utlemming> rsalveti: huh?
<Chipaca> elopio: yep
<elopio> Chipaca: this would increase your chances of getting aged rum: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333
<ubottu> Launchpad bug 1473333 in goget-ubuntu-touch (Ubuntu) "exits with zero on error" [Undecided,Confirmed]
<rsalveti> utlemming: hey :-), what I asked you yesterday:
<Chipaca> utlemming: it's all your fault, see?
<rsalveti> <rsalveti> utlemming: we're just finishing the testing phase for our current alpha image (image 9), and that will be migrated to stable
<rsalveti> <rsalveti> or latest edge (132)
<jdstrand> ogra_: not to my knowledge. tyhicks, do you know? ^
<Chipaca> :-p
<rsalveti> <rsalveti> utlemming: can you run your usual testing scenarios over it and see if there is any issue with the cloud targets?
<utlemming> rsalveti: ah, okay
<utlemming> rsalveti: sorry, I didn't see the request, doing it now
<rsalveti> utlemming: no worries, thanks
<Chipaca> elopio: maybe i should just rerun it :)
<elopio> Chipaca: the same udf command works for me. fgimenez: ^ can you give it a try?
<Chipaca> elopio: fgimenez: the re-run has gotten further
<fgimenez> elopio: Chipaca yep on it, anyway that error may disappear eventually
<fgimenez> Chipaca yep here it's working fine
<elopio> so blame sergiusens, that's good B-)
<Chipaca> \o/ then
<Chipaca> but it's not being able to ssh in
<fgimenez> Chipaca: that's probably because ens3 is down
<Chipaca> fgimenez: that's what i fixed :)
<fgimenez> Chipaca: then it must be something else :)
<fgimenez> Chip
<fgimenez> Chipaca: you can try to create the image, launch it with kvm and run the tests passing ip and port
<elopio> Chipaca: you fixed it, but udf is deploying yesterday's rolling edge
<elopio> Chipaca: go run _integration-test/main.go --ip localhost --port 8022.
<elopio> and we will know if rolling edge works until later. :(
<Chipaca> elopio: um
<Chipaca> ah
<Chipaca> elopio: i'm guessing it copies in snappy after ?
<elopio> Chipaca: yes. Some discussion in here: https://trello.com/c/VUKDVa97/106-generate-an-image-with-snappy-from-a-branch
<utlemming> rsalveti: I'm seeing an image with a serial of 132
<rsalveti> utlemming: right, that's the one we're going to promote to stable
<rsalveti> unless we find yet another bug
<elopio> Chipaca: and note that there's one failover test that regressed, so the suite will fail.
<elopio> https://bugs.launchpad.net/snappy/+bug/1476129
<ubottu> Launchpad bug 1476129 in Snappy "automatic reboot fails with rc.local crash" [Undecided,New]
<elopio> fgimenez: all my refactor branches are updated. What's missing I think is to give a better name to common.go like basetest.go, but I'm not sure if go test would try to run it.
<fgimenez> elopio: ok i'll take a look, there are more failover tests that are not working because of the new location of the kernel files, i'll put hands on that too
<elopio> fgimenez: oh, that's sad.
<elopio> we are so close to be in-sync, but things keep falling appart. Thanks fgimenez.
<ogra_> rsalveti, so latest rootstock should theoretically be able to build core for vivid and wily ... but .... bug 1450980
<Chipaca> pitti: you around?
<ubottu> bug 1450980 in debootstrap (Ubuntu) "Python 3.4.3 package fails to install with deboostrap on armhf" [High,Confirmed] https://launchpad.net/bugs/1450980
 * elopio goes offline now. Telegram if you need me.
<Chipaca> elopio: i *think* you meant to thanks fgimenez for keeping things in sync, but it reads like you're blaming him for things falling apart :)
<rsalveti> ogra_: =\
<ogra_> there is a workaround mentioned, trying that now
<elopio> Chipaca: ok, to be clearer, I blame everybody except fgimenez ;)
<fgimenez> elopio: i want my part of blame too! :)
<ogra_> oooh, that looks a lot better !
<pitti> hey Chipaca; yes, back from holidays
<Chipaca> pitti: welcome back!
<pitti> thanks!
<Chipaca> pitti: i'm fighting with network-online.target; a service has it as a requires: and after: dependency, and it's still started before a network interface comes up
<Chipaca> pitti: i'm starting to suspect either i'm misunderstanding something deeper, or something's broken in snappy wrt systemd & networking
<Chipaca> (btw, dunno if you remember but udevadm failed to bring up the network after adding a hotplug file to interfaces.d; had to systemctl restart networking)
<pitti> Chipaca: do you have a journalctl from the full boot? that shows the sequence of ifup-wait-all-auto.service, network-online.target, and your service
<ogra_> onions ... so tiring ...
 * ogra_ yawns
<pitti> ogra_: ?
<Chipaca> pitti: how do i get that?
<ogra_> pitti, rootstock uses three chroots wrapped into each other to fake a real livefs builder ... ultra boring to watch it :)
<pitti> Chipaca: "sudo journalctl > /tmp/journal.txt", and scp/pastebin that
<ogra_> onion model :)
<pitti> or just "sudo journalctl | pastebin -" if you have something like that installed
<Chipaca> pitti: http://paste.ubuntu.com/11953525/
<utlemming> rsalveti: things look good for all the clouds
<rsalveti> utlemming: great
<pitti> Chipaca: so ifup-wait-all-auto.service is done at line 676, network-online.target is done at 735
<pitti> Chipaca: what's your service?
<ogra_> can clouds roll back ?
<Chipaca> pitti: webdm
<Chipaca> pitti: how is network-online done, if the network is not online?
<pitti> Chipaca: erk, cloud-init runs afterwards, and calls ifupdown stuff
<ogra_> yeah, we should realyl get rid of it
<ogra_> the three to fix things it does for use all have equivalents in the distro we could use instead
<pitti> Chipaca: may it be that there isn't actually an /etc/network/interfaces at boot, or cloud-init creates that?
<ogra_> s/fix/five/
<Chipaca> pitti: just to be clear, there is no configured network; it should not start at all :)
<pitti> in general, I really recommend not running cloud-init on every boot, unless you have a very good reason to
<pitti> Chipaca: aah
<pitti> Chipaca: well, our ifup-wait-all-auto.service only waits until all configured interfaces are up
<pitti> and as there are none, it succeeds immediately then
<Chipaca> oh
<Chipaca> daaaaamn
<Chipaca> ok, let's see if i tell it there's a fake one
<pitti> so you need some other service that hooks into network-online.target and waits until you configure your network
<Chipaca> that might be a good option still
<pitti> we can't make the default distro ifup-wait-all-auto.service not fire at all in this case
<Chipaca> understood
<pitti> as you can also use NetworkManager, connman, networkd, or something else
<Chipaca> pitti: the "no network configured" thing is me trying to fake bug 1466672
<ubottu> bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672
<pitti> Chipaca:if cloud-init brings up the network, then perhaps it could order itself before network-online.target?
<pitti> Chipaca: also:
<pitti> dhclient[895]: can't create /var/lib/dhcp/dhclient.leases: Permission denied
<Chipaca> pitti: that was me running dhclient by hand
<ogra_> wow
<pitti> ah, ok
<Chipaca> without sudo
<Chipaca> :)
<pitti> ok, I ignore this then :)
<Chipaca> ogra_: de-panic :)
<ogra_> not panicing :)
 * ogra_ is just bored ... watching rootstock ... waiting 
<pitti> Chipaca: it looks like cloud-init also calls ifup -a
<Chipaca> pitti: thank you; i have plenty of things to poke for now then :) i'll pester you again if i run out again
<pitti> with some errors, but did that actually work?
<pitti> i. e. after it's done, do you have network?
<Chipaca> pitti: i have no idea :)
<pitti> Chipaca: well, wait until cloud-init is done, and check "ip a" and "ip route"?
<Chipaca> pitti: sorry, to be clear, in this case no it did not do anything
<pitti> Chipaca: and of course if it wrote something sensible into /etc/network/interfaces
<Chipaca> pitti: because i manually disabled networking by moving a file away from interfaces.d
<Chipaca> pitti: but i think your general question is whether that is the thing that actually brings up the network
<Chipaca> pitti: i will know shortly :)
<pitti> Chipaca: ok, so it's not cloud-init then; I guess you have something else that writes /e/n/i then?
<pitti> or is supposed to
<Chipaca> pitti: snappy firstboot writes a file to interfaces.d
<pitti> Chipaca: that finishes on line 742, so indeed after network-online.target
<pitti> Chipaca: so if you order that Before=network.target, that might help
<pitti> Chipaca: i. e. it should write /e/n/i.d/ early, and then the ifup-wait-all-auto.service magic should kick in
<ogra_> update-initramfs: Generating /boot/initrd.img-3.19.0-25-generic
<ogra_> /bin/df: Warning: cannot read table of mounted file systems: No such file or directory
<ogra_> Warning: root device  does not exist
<ogra_> Unable to abort; system will probably be broken!
<ogra_> GEEZ !"
 * pitti tosses a /proc mount to ogra
<ogra_> could we make update-initramfs warnings a little less scary
<ogra_> pitti, thats expected, it is run by live-build in that context
<Chipaca> pitti: i tried ordering firstboot before network-pre, but it didn't work
<ogra_> but update-initramfs is full of such warnings about trivial bits that sound like the end of the world
<Chipaca> pitti: however you weren't here to pester :) so maybe i should retest that later
<Chipaca> pitti: this is with the same config as just now, but with a (fake) entry in interfaces.d: http://paste.ubuntu.com/11953575/
<Chipaca> pitti: interesting things are, for a start, a "sh segmentation fault"
<Chipaca> and that ifup-wait-all-auto failed, but network-online succeeded
<pitti> Chipaca: right, that times out after 2 mins; I did that to do the same as what we did under upstart, i. e. block the boot for at most 2 mins on ifup
<pitti> ifquery[535]: segfault at 1 ip 0000000000403187 sp 00007ffd59263e90 error 4 in ifup[400000+d000]
<pitti> go, ifupdown!
<ogra_> lol
<ogra_> that might explain the 30sec delay during boot :)
<Chipaca> pitti: to be fair, i did just tell it to try to bring up ens42
<ogra_> pitti, seems to not be 2min in the new world
<pitti> 13:16:29 localhost.localdomain systemd[1]: Starting Wait for all "auto" /etc/network/interfaces to be up for network-online.target...
<pitti> 13:18:29 localhost.localdomain systemd[1]: Failed to start Wait for all "auto" /etc/network/interfaces to be up for network-online.target.
<pitti> looks like 2 mins to me :)
<ogra_> well, my BBB sits for 30-40sec
<Chipaca> ogra_: this is so big a mess, i suggest we take a look at some point
<ogra_> +1
<Chipaca> not right now tho :)
<ogra_> haha
<ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ ls -l out-20150728
<ogra_> insgesamt 218368
<ogra_> -rw-r--r-- 1 root root    188192 Jul 28 15:26 build-20150728-armhf.log
<ogra_> -rw-r--r-- 1 root root 163712102 Jul 28 15:26 ubuntu-core.device.tar.gz
<ogra_> -rw-r--r-- 1 root root      8217 Jul 28 15:26 ubuntu-core.manifest
<ogra_> -rw-r--r-- 1 root root  59685713 Jul 28 15:26 ubuntu-core.rootfs-armhf.tar.gz
<ogra_> HOORAY !!!!
 * ogra_ dances
<Chipaca> pitti: so, um, what do i do if i want to start a service after the network is up? so it works in the "network device is there but cable not plugged in" case
 * pitti hugs ogra
 * ogra_ hugs pitti 
<ogra_> so now on to a wily build ... if that works too i'll declare rootstock ready for usage :)
<pitti> Chipaca: can you please clarify? if there's no cable, you're technically never online
<Chipaca> pitti: in that case, the service shouldn't start. It should start after a cable is plugged in (stopping if unplugged would be a bonus)
<pitti> Chipaca: right now we delay network-online.target for up to 2 mins on /e/n/i coming up (mimicking what we did in upstart); apparently that was the right thing for desktop/server, but maybe not for snappy
<pitti> Chipaca: so I guess we need a different "implementation" of n-o for that, i. e. not ifup-wait-all-auto.service
<Chipaca> pitti: i'm not so sure; i'd like to be able to getty in even if the network is disconnected, for example
<pitti> for a start, an infinite timeout
<pitti> Chipaca: yes, getty doesn't need n-o, so that's always possible; ideally very few services are requires/after n-o
<pitti> n-o.target is really mostly a hack for legacy software which doesn't know how to listen to networking changes itself
<Chipaca> ah, ok
<Chipaca> hey, i could just say "bug in webdm" and see what rsalveti says :)
<pitti> but we can certainly write an implementation that makes n-o go up an down while some ifupdown interface is up
<rsalveti> Chipaca: I'd probably say just fix webdm then :P
<Chipaca> rsalveti: wfm, but i can see many other, lesser, app developers blaming snappy and not their code :)
<rsalveti> sorry, need to read the entire backlog for context
<Chipaca> rsalveti: bottom line is: my sneaky plan of making it work by hanging off of network-online.target will not work unless we rewrite stuff (and depart from what works for the rest of ubuntu)
 * ogra_ thinks we should just go back to upstart :P
<Chipaca> or forwards to systemd-networkd!
<kgunn> Jul 28 13:34:08 localhost kernel: [  228.622474] audit: type=1400 audit(1438090448.373:13): apparmor="STATUS" operation="profile_load" profile="unconfined" name="mir_system-compositor_snap1.1" pid=1068 comm="apparmor_parser"
<kgunn> jdstrand: so got to the point of final testing....
<pitti> Chipaca: yeah, for use cases like that it'd certainly be more practical to "eternally" delay n-o; we can't do that on desktop/server where networks can be brought up by other means, but if ifupdown/snappy-firstboot is the only thing that configures it we can be stricter
<kgunn> and just happened to lock at the syslog, i don't have any "unconfined" in my profiles so why does it say that ^
<pitti> ogra_: FWIW, upstart has exactly the same behaviour :)
<kgunn> jdstrand: could it be that at one point, an unconfined template was used ? e.g. it's not specified by keyword "unconfined"
<kgunn> but the structure ?
<ogra_> pitti, yeah, but i know from the top of my head how to work around it in upstart :P
<Chipaca> so, another thing i could do, is add a wait to the service itself
<ogra_> systemd isnt injected enouh in my cortical system yet :)
<ogra_> Chipaca, sleep 30
<ogra_> :P
<Chipaca> ExecStartPre=wait4tehnetworz
<Chipaca> pitti: would that work?
<pitti> ogra_: don't let it -- it's not designed for human brains :)
<pitti> Chipaca: sure; although, that's conceptually a bit broken
<Chipaca> pitti: tell me more
<ogra_> pitti, but it fits into lennarts !
<pitti> Chipaca: I'd suggest, if you have a thing like this, rather stick it in ifup-wait-all-auto.service
<pitti> ogra_: obviously :)
<pitti> Chipaca: well, you can eternally wait in ExecStartPre= if you also disable the unit timeout
<Chipaca> ah. forgot about that pesky timeout thing :)
<pitti> Chipaca: but it's still not very elegant; for such long (potentially indefinite) waits it's better to put that waiting logic into a separate unit (ifup-wait-all-auto.service *cough*), and order yourself after it
<pitti> Chipaca: well, TimeoutStartSec=0 :) (but then real hangs won't ever be detected)
<Chipaca> pitti: i'm reticent to modifying ifup-wait-all-auto.service though
<pitti> Chipaca: it could also be a new one, like ifupdown-wait-online.service
<pitti> Chipaca: there's no harm in making network-online.target wait for both
<pitti> Chipaca: on a desktop it e. g. waits for ifup-wait-all-auto.service and NetworkManager-wait-online.service
<Chipaca> pitti: and how is that difference sorted?
<pitti> Chipaca: so, for experimentation: fine to put it into ExecStartPre=
<pitti> Chipaca: (and disable the timeout)
<pitti> that might be simplest for iterating on the logic of wait4tehnetworz
<pitti> Chipaca: but once you do have a wait4tehnetworz, let's rather put that into a new ifupdown-wait-online.service which is Before=network-online.target
<pitti> Chipaca: difference?
<Chipaca> pitti: wait4tehnetworz is just âwhile [ "$(GET "http://start.ubuntu.com/connectivity-check.html" | md5sum | cut -d\  -f1)" != "4589f42e1546aa47ca181e5d949d310b" ]; do sleep 1; doneâ, for example
<Chipaca> (possibly not *actually* in sh) :)
<jdstrand> kgunn: that is not a denial, that is a profile load. That log entry is completely normal. it is saying an unconfined process (ie, apparmor_parser, snappy, whatever) loaded the profile
<Chipaca> pitti: difference == how to ship one config for desktop and a different one for server (and now a different one for snappy)
<Chipaca> i don't know how that part of the system is glued up
<pitti> Chipaca: ah, just ship it in the snappy package, together with a /lib/systemd/system/network-online.target.wants/ symlink
<pitti> Chipaca: I don't think you actually need to disable ifup-wait-all-auto.service -- your's should be stricter in all cases
<Chipaca> gotcha
<pitti> Chipaca: i. e. I don't see a case where ifup-wait-all-auto.service would still wait while your's would alreaydy succeed
<Chipaca> now i understand what the symlinks are for :-D
<pitti> Chipaca: shipping the symlink is the same as adding an [Install] section and calling systemctl enable (teh latter just creates that symlink)
 * pitti needs to run to the grocery store, back in 30
<kgunn> jdstrand: i realize that's not a denial, my point is...i'm going thru the process of making sure the mir snap and client are confined
<kgunn> and wondering, if i've made it all confined why is it saying unconfined....so you say the process that started it is
<kgunn> which i guess would be the launching script that's part of the snap ?
<beuno> kgunn, I think he's saying that by design, unconfined processes start apps and services
<beuno> so it's an ignorable log entry
<kgunn> beuno: that was my other thot, thanks for confirmation
<jdstrand> kgunn: what is saying unconfined exactly? the log entry you pointed to doesn't say anything about the mir process or the client process
<jdstrand> kgunn: it is only saying that the profile was loaded by an unconfined process (ie, when you ran apparmor_parser, or when you installed the snap)
<jdstrand> kgunn: like beuno said, you can ignore it
<kgunn> jdstrand: got it, so pid 1068 was the unconfined thing
<jdstrand> kgunn: if you want to know if the mir and client processes are confined, you can use 'sudo aa-status' or 'ps Z'
<kgunn> ta
<jdstrand> kgunn: 1068 was ultimately apparmor_parser, yes
<kgunn> jdstrand: thanks, i think i'm actually done with mods to aa and seccomp to get the mir svr and client app to run confined
<kgunn> altho i'm sure you or designate will need to take a look
<kgunn> and tell me to "improve" potentially :)
<jdstrand> kgunn: great! yeah, whenever you upload ping me and I'll look at it. at this point I imagine we are getting to the point of just filing bugs
<kgunn> cool
<kgunn> just doing some clean testing to make sure i'm all  good
<Chipaca> pitti: for the record, a delayed network-online results in no gettys for 2m
<pitti> Chipaca: hmm, that's bad; so we block user-sessions on that? /me checks
<pitti> ah, we had bug 1425376 earlier due to that
<ubottu> bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376
<pitti> ah, so we block network.target, which is really bad
<Chipaca> pitti: it does give me a nice red ascii throbber to look at on console though :)
<Chipaca> pitti: this is bad news for my wait4networz service, which ... um ... waits for the networz
 * Chipaca should trademark that
<Chipaca> pitti: but that bug says it's fixed released; am i missing something?
<pitti> Chipaca: yes, it is, I just remembered that we had such a case before
<pitti> so we need to find out why network.target is blocked on getting online
<pitti> apparently something orders itself after network-online.target but before network.target, and we need to LART it
<davmor2> Chipaca: yeap but no wonder your network is down.  I mean there are always casualties in worz
 * Chipaca deploys networz on davmor2
<pitti> ah, could be /etc/init.d/networking
 * davmor2 plays c6 and sinks Chipaca's battle ship
 * Chipaca sneaks a spy into davmor2's capital and sets off a nuke
<Chipaca> pitti: fwiw ifup-wait-all-auto bailed as expected
<davmor2> Chipaca: Thanks Wolverhampton really need a facelift
<Chipaca> who says wars don't settle arguments
<ogra_> Chipaca, that is because you dont use ifup-wait-all-auto-do-no-bail
<Chipaca> ogra_: --pretty-please
<davmor2> No no worz alway settle arguments the issue is in war no one remembers the argument that triggered it so they keep resetting the argument ;)
<ogra_> :)
<pitti> Chipaca: btw, in case it's any easier, you can run stuff from /etc/network/if-up.d/, which are called when (any) interface gets connected
<pitti> Chipaca: if you have a journalctl from that boot with the stalled getty, I'd be interested
<pitti> Chipaca: (also, stalled -- talking to other folks)
<Chipaca> pitti: how can i get journalctl from a stalled boot?
<Chipaca> given no network & no getty
<pitti> Chipaca: you could boot with systemd.debug-shell, and ctrl+alt+f9
<Chipaca> that was it
<Chipaca> yep
<pitti> Chipaca: or disable your new unit, and just let the standard stuff time out after 2 mins
<Chipaca> pitti: i don't know how do disable my new unit :)
<pitti> Chipaca: or just plug in ethernet after 2 mins :-) I'm merely interested what's (not) starting until the network comes up
<pitti> Chipaca: remove the symlink
<Chipaca> pitti: with no network and no getty
<pitti> ah
<Chipaca> :)
<pitti> well, debug shell it is then, I figure :)
<pitti> Chipaca: but it does sound like bug 1425376 is back?
<ubottu> bug 1425376 in systemd (Ubuntu) "Ubuntu Core provides no console login prompt if network is unavailable" [Undecided,Fix released] https://launchpad.net/bugs/1425376
<Chipaca> pitti: if it ever truly went away, yes
<Chipaca> i've seen this spinner before, didn't realise it was a bug
<kgunn> jdstrand: so here's my "confined" attempt
<Chipaca> pitti: http://paste.ubuntu.com/11954006/
<kgunn> https://code.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/+merge/266111
<kgunn> jdstrand: so dunno if that's for you or tyler feel free to change
<kgunn> also do you want snaps built ?
<jdstrand> kgunn: I don't need snaps built
<Chipaca> why are we running cloud init on *every* boot? isn't it a firstboot thing?
<pitti> Chipaca: oh, cloud-init
<Chipaca> sergiusens: do you know^?
<pitti> Chipaca: right, cloud-init is indeed blocking gettys, and it takes effing long
<kgunn> jdstrand: ok, to test you can follow the "snappy gui anyone" blog
<Chipaca> pitti: cloud init depends on network-online afaik
<kgunn> the one step not to forget is the "export LC_ALL=C.UTF-8" ;)
<jdstrand> kgunn: ok. I probably won't get to this immediately, but will soon
<pitti> Chipaca: right, and blocks user sessions
<jdstrand> tyhicks: there is already a card for this. I'll assign it to me since I looked at the others
<Chipaca> yes, requires: network-online
<kgunn> jdstrand: no worries, i just didn't want to drop our responsibility of following up :)
<pitti> Chipaca: so if there's no network, cloud-init will block
<Chipaca> lurvely
<tyhicks> ogra_: are you saying that we use stagefright on our phones?
<jdstrand> tyhicks: see #phablet
<ogra_> tyhicks, seems we dont use it but there are ~30 .so files in the android container under /system/lib
<pitti> Chipaca: OOI, what do you use cloud-init for?
<ogra_> accordin to jhodapp they are not used by anything though
<pitti> Chipaca: with the r/o file system it can't actually do much, can it?
<tyhicks> ogra_: thanks
<Chipaca> pitti: I don't know what we use it for, exactly :-)
<Chipaca> pitti: i'm hoping sergiusens knows
<sergiusens> Chipaca: cloud-init runs on every boot
<ogra_> yeah :/
<sergiusens> Chipaca: pitti that is the way of cloud-init, I was told it should be this way; maybe smoser or utlemming can expand
<tyhicks> jdstrand: ack - thanks for taking the review
<sergiusens> cloud-init does not run through the whole thing on every boot though
<sergiusens> it has run-once's
<pitti> right, but it blocks the boot on network-online.target, that's the main problem
<pitti> i. e. if you aren't online, it stalls the boot
<sergiusens> pitti: Chipaca wrt what we use it for, it's used for the cloud and btw https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init
<Chipaca> sergiusens: any ideas as to where to put http://pastebin.ubuntu.com/11954094/ so we can ship it in the snappy package easily?
<kgunn> Chipaca: hey there, i've recently tried to confine the mir snap, i wanted to grab olli's qml app and run on top...see if i get any sec issues compared to my qt clock ref
<kgunn> where would i find that snap ?
<Chipaca> kgunn: i think ted has a snap built with the qml snapcraft plugin
<Chipaca> kgunn: otherwise chinstrap.canonical.com/~ories/public_html/digital_sign_deb2snap_tree.tar.bz2 is ollie's (old) thing
<Chipaca> kgunn: but you probably meant the qml snapcraft route
<kgunn> Chipaca: yeah, preferably latest/greatest
<Chipaca> kgunn: um, s.public_html/..
<Chipaca> ted might not be here though
<Chipaca> 1 sec
<Chipaca> kgunn: this is snapcraft with the qml plugin (not merged yet): https://code.launchpad.net/~ted/snapcraft/qml
<Chipaca> kgunn: this is a snapcract project that uses it: https://code.launchpad.net/~ted/+junk/photoviewer
<kgunn> ta
<Chipaca> kgunn: um. there's also the snapcraft ppa
<Chipaca> kgunn: because without a patched libxkbcommon some things will fail
<kgunn> ah-ha
<Chipaca> kgunn: if you're in wily, you already have the patch
<Chipaca> kgunn: which we successfully upstreamed, btw :) https://github.com/xkbcommon/libxkbcommon/pull/25
<Chipaca> where's golang-uboot-go-dev supposed to be at?
<Chipaca> sergiusens: ogra_: any idea? ^
<ogra_> never heard of it
<Chipaca> ogra_: it's mvo's uboot-go, packaged
<Chipaca> it's a build dependency
<ogra_> ah
<Chipaca> but it doesn't exist
<ogra_> well, he didnt want to include it anyway
<ogra_> the binary is like 2MB or so
<ogra_> so dont bother for now
<ogra_> he can handle it when coming back
<Chipaca> ogra_: but i can't dpkg-buildpackage without it :-.
<ogra_> hmm
<ogra_> why would he include uboot-go after telling me it is to big for inclusion
<Chipaca> ogra_: i'm not sure what binary you mean, btw
<ogra_> the uboot-go binary
<Chipaca> ogra_: we need it because bootloader_uboot uses uboot-go/uenv
<ogra_> no, it doesnt
<Chipaca> yes it does :)
<ogra_> it uses fw_setenv/fw_printenv
<ogra_> mvo explicitly kept uboot-go out
<ogra_> at least he told me so
<Chipaca> well ... it's there on trunk
<ogra_> hmm
 * Chipaca does a bzr pull just in case
<ogra_> i only ever worked with the fw_* tools
<Chipaca> there's no fw_ in snappy
<ogra_> its seeded
<ogra_> uboot-tools or some such
<Chipaca> ogra_: this uboot-go is the thing that mvo wrote that parses uenv.txt
<Chipaca> ogra_: and writes it out without causing reallocations
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ dpkg -S $(which fw_printenv)
<ogra_> u-boot-tools: /usr/bin/fw_printenv
<Chipaca> ogra_: sure, but nowhere in snappy do we call out to fw_
<ogra_> uboot-go is plain go to eventually replace the fw_ tools
<ogra_> but today we definitely use fw_*
<Chipaca> no we don't -- not in trunk
<ogra_> well, thats all i know
<Chipaca> not from snappy
<Chipaca> :-(
<ogra_> http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1183
<ogra_> thats the only code i know ... beyond that mvo threw some revisions of a uboot-go binarry over the fence to me to test it for him ... but with the comment that this wont be used yet because it is to big
<ogra_> (and afaik uboot-go doesnt use the config from that above merge at all)
<ogra_> probably longsleep remembers more
<sergiusens> Chipaca: ogra_ https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=uboot&field.status_filter=published&field.series_filter=
<ogra_> ah, look
<sergiusens> ogra_: as a separate binary maybe, but it is used within snappy itself
<ogra_> well, he told me it wouldnt be used
<sergiusens> ogra_: in summary, mvo was lazy to dput to the archive or maybe it's stuck in new
<ogra_> (i actually thought he exec()s fw_*)
<sergiusens> ogra_: nope, he uses the lib, which is fine, doesn't make for a bigger binary
<ogra_> yeah
<sergiusens> ogra_: btw, what is your g+ exit strategy?
<ogra_> i have none yet
<ogra_> lets see how it changes
 * ogra_ will react on the go ... they dont publish actual plans, do they ? 
<ogra_> (apart from ... "we'll split everything out")
<longsleep> ogra_: what would i have to remember?
<longsleep> ogra_: reading backlog now
<Chipaca> and now tests under dpkg-buildpackage fail in very weird ways
<Chipaca> siiigh
<ogra_> longsleep, seems all solved ... (what was up with uboot-go)
<longsleep> ogra_: all right
<longsleep> ogra_: so whats the result of your discussion, fw_* is used or the go tool?
 * longsleep has used both
<ogra_> seems snappy internally doesnt use fw_*
<longsleep> yeah that was what i had remember from last week as well - i think the fw_* tools were just for us to test stuff, but snappy internally was using the go library?
<longsleep> seems that is the conclusion you reached as well?
<ogra_> yeah, thats apparently the bit i missed
<longsleep> well i did not check the go code what it actually does
<ogra_> itr is the conclusion Chipaca reached by reading the code :)
<longsleep> ah great - so the fw_* tools could go away in favor of the uboot-go commandline tool eventually
<Chipaca> longsleep: i think they're still used to build the image though
<Chipaca> that is, used from livecd or whatever it's called
<longsleep> oh ok
<Chipaca> which might be where the confusion comes from
<longsleep> what does the livecd builder do with it?
<Chipaca> snappy uses a go lib, because it's more careful about some things that cause corruption
<Chipaca> but livecd-rootfs uses the fw_ tools still, presumably because there's no benefit to using a (rather massive) binary at that point
<Chipaca> longsleep: um. Dark magic, if you ask me. :-)
<ogra_> no, nothing uses it
<ogra_> we could unseed it
<longsleep> +1 - what could it be used for
<ogra_> we use mkenvimage or what it is called during oem snap creation from the u-boot upstream tree
<ogra_> and then dont touch the env file anymore
<longsleep> right thats what i do when building the oem snap as well
<ogra_> ogra@anubis:~/datengrab/rpi/uboot/bbb/snappy/snappy-systems$ apt-cache show  u-boot-tools|grep ^Installed
<ogra_> Installed-Size: 203
<ogra_> its not like it takes any space though
<longsleep> fw_* writes or reads env files, so why that would be required doring rootfs build i cannot see
<longsleep> ogra_: right
<longsleep> ogra_: problem is that people might use the tools and eventually corrupt their env file (remember the 4 vs 5 byte header?)
<ogra_> otoh people might use them to debug stuff without trashing the file :)
<longsleep> ogra_: i mean the scary configuration file the fw_ tools needs is reason enough to get rid of them :)
 * ogra_ doesnt see an urgent reason to drop the tools
<Chipaca> sergiusens: poke (again) :)
<longsleep> yeah they do not hurt
<ogra_> they should be dropped once we do a general cleanup though ... one where every byte counts :)
<ogra_> for the moment i'd leave them there
<Chipaca> pitti: in snappy we're using dh_systemd_enable; how do i add something to wants using that?
<Chipaca> pitti: never mind, thank you :)
<Chipaca> i should take a break
<Rlyeh> Hi
<Rlyeh> Guys, where is "ubuntu-core" config file? I just can't find config file to change!
<Rlyeh> Since "ubuntu-core" isn't a snap, ther is no any 'package.yaml '
<beuno> Rlyeh, what are you trying to change?
<Rlyeh> Timezone :(
<beuno> Rlyeh, you change it through the command line
<ogra_> you should be able to change that via the snappy config command
<Rlyeh> "snappy config ubuntu-core" ? It just return vealues
<Rlyeh> How can I do that?
<ogra_> bug 1472788 has some hints irc
<ubottu> bug 1472788 in Snappy "snappy config does not work from stdin" [Undecided,New] https://launchpad.net/bugs/1472788
<Rlyeh> This means it's not possible to change "ubuntu-core" config file?
<beuno> Rlyeh, it's a read-only files system  :)
<beuno> it takes config via a command line
<Rlyeh> I knew that, but didn't thought "ubuntu-core" is read-only too!
<Rlyeh> So, I can't change the timezone? :(
<ogra_> Rlyeh, did you read the bug ?
<ogra_> it has an example how to change the timezone
<Rlyeh> No, in time, i'm using xchat on my BBB using debian, It's too slow to open a browser, but I'll check it on my PC
<Rlyeh> Thank you all :)
<longsleep> What is wrong when my snappy just says 'Invalid package on system' ?
<longsleep> a colleague of mine just has that problem
<ogra_> good question
<ogra_> Rlyeh, snappy config ubuntu-core - <(echo -e 'config:\n ubuntu-core:\n timezone: Europe/Berlin\n')
<ogra_> Rlyeh, that sets it to berlin for me
<longsleep> i cant even 'snappy list'
<ogra_> wow
<longsleep> He was even using a pre built image Run vagrant init http://cloud-images.ubuntu.com/snappy/15.04/core/stable/current/core-stable-amd64-vagrant.box
<Rlyeh> Thank you ogra, very much :)
<ogra_> longsleep, broken clock or something ?
 * ogra_ has seen weird behavior when the clock was massively off
<longsleep> no that does not seem to be it
<longsleep> i can reproduce
<longsleep> hold on
<longsleep> mhm or not :/
<longsleep> something is strange there
<longsleep> (amd64)root@ubuntu-core-stable-3:~# date
<longsleep> -su: /bin/date: Input/output error
<longsleep> wtf?
<ogra_> disk screwed up ?
<ogra_> (dmesg ? )
<longsleep> mhm he deleted and reinstalling already
<longsleep> lets see if he breaks it again
<longsleep> mhm looks like it works now - disk must have been broken
<elopio> I'm back.
<elopio> mterry: are you happy with this one? https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354
<mterry> elopio, ah nice, missed your comment
<mterry> elopio, I'm in the middle of something now but will re-review
<elopio> mterry: ok, thanks.
<mterry> elopio, looking at your branch -- now some things are bold that weren't before
<mterry> elopio, look at the diff in LP and you can see some things were just print() lines before
<mterry> elopio, specifically when we ran a subcommand, it would not be bold
<mterry> elopio, and a couple tiny other places
<mterry> elopio, what's the cleanest way to distinguish there?  Use another logger command than info?
#snappy 2015-07-29
<Chipaca> sergiusens: take a poke https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 when you have a bit plz
<Chipaca> rsalveti: ^ that's my take on the fix/workaround for bug 1466672
<ubottu> bug 1466672 in Snappy trunk "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,In progress] https://launchpad.net/bugs/1466672
<rsalveti> omg, system-image import takes forever, impossible to get the lock
<pitti> Chipaca: add an [Install] section to it with WantedBy=
<pitti> Chipaca: or just ship the symlink in the deb, as you wish
<xaj> Can anyone help me get git installed in ubuntu-15.04-snappy-armhf-rpi2?
<xaj> I was able to install wget and Iâve been pulling my hair out trying to get dependencies built with dpkg for git
<xaj> aaand nobody gaf >_>
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy Rain Day! ð
<Chipaca> zyga: finally got round to adding tests and pushing https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266199
<Chipaca> oh, drat, forgot the prereqs
<Chipaca> 1 sec
<zyga> Chipaca: hi
<zyga> Chipaca: looking
<Chipaca> zyga: https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200
<zyga> ohhh
<zyga> nice
<zyga> one tip/request
<Chipaca> shoot
<zyga> please get into the habit of writing manual pages
<zyga> it makes software far far better to discover
<Chipaca> we suck at that, don't we
<zyga> I'll start using .snapignore right away
<Chipaca> systemd puts us to shame
<zyga> hehe
<zyga> yes
<Chipaca> zyga: it's not on trunk yet!
<zyga> systemd is really good about this
<zyga> Chipaca: we started doing this for plainbox
<zyga> Chipaca: and it's really easy actually
<zyga> Chipaca: just requires discipline and merge request reviewers to spot
<zyga> Chipaca: feel free to copy the sphinx integration bits
<zyga> http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/files/head:/plainbox/docs/manpages/
<zyga> Chipaca: that and the conf.py file for sphinx is all we need
<zyga> Chipaca: it's a world of difference for our users
<zyga> Chipaca: one more suggestiong
<zyga> *on
<zyga> Chipaca: perhaps remove the built-in list and create the .snapingore file with that list if missing
<zyga> Chipaca: it's better than having two, one secred that nobody knows of, and one in the file
<Chipaca> hmm
<Chipaca> i see your point
<Chipaca> can you make that comment on the merge?
<Chipaca> i think it needs sergio or mvo to comment
<zyga> sure
<Chipaca> zyga: also: http://paste.ubuntu.com/11958678/
<zyga> btw, we have some code that automates that :)
<Chipaca> missing quite a bit of work still, but that might be a good place to start
<zyga> so we get the manual page for plainbox commands (all dozens of them) auto-synchronized with sphinx
<Chipaca> zyga: that's produced by "snappy man"
<zyga> ah
<Chipaca> ... which is not a thing on trunk yet either
<zyga> Chipaca: random man page from plainbox
<zyga> http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-dev-list.rst
<zyga> the ..argparse part is also a plainbox feature though I'm moving that to python-guacamole for anyone to use
<zyga> (that example was poor) http://plainbox.readthedocs.org/en/latest/manpages/plainbox-run.html and http://bazaar.launchpad.net/~checkbox-dev/checkbox/trunk/view/head:/plainbox/docs/manpages/plainbox-run.rst
<Chipaca> zyga: and this is the code that adds "snappy man": https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203
<zyga> looking
<zyga> ah, but that's go, I thought this part is written in python
<zyga> Chipaca: so it's a feature of the argument parser that go provides
<Chipaca> well, of the one we use :)
<zyga> right
<Chipaca> it also produces bash completion things
<Chipaca> which we aren't using (why not? :) )
<zyga> nice, it's somewhat similar, we have a sphinx plugin that looks at the parser object
<Chipaca> ogra_: why don't we ship bash completion in core?
<zyga> Chipaca: bash is not in the core ;-)
 * zyga ducks
<Chipaca> if it weren't, i'd be happy
<Chipaca> but as it is, we might as well use it :)
<zyga> hehe
<zyga> yeah, I was kidding
<Chipaca> me, i'd strip core down so much it would make peoples eyes water
<Chipaca> but it's not (yet) my fight
<zyga> Chipaca: the 1995 boot floppy!
<Chipaca> exactly!
<ogra_> Chipaca, we should just drop bash
<Chipaca> dhcp in the kernel baby!
<ogra_> iirc the completion db isnt actually small ... and it refers to aps
<ogra_> *apt
<Chipaca> also the kdrive x server, man that thing was sweet
<ogra_> !
<ogra_> i loved that
<Chipaca> ogra_: wrt bash completion, we ship random things in /etc/bash_completion.d, which we should probably look at (wrt apt, etc) and nuke, but we don't ship /etc/bash_completion so even if we ship snappy's completion thing, it won't be picked up
<Chipaca> also shipped: 400k in /usr/share/bash-completion/completions
<ogra_> hm i thought it was more in the megabytes
<Chipaca> ogra_: it can be :)
<ogra_> but perhaps i shouldnt justdge by desktop standards ;)
<Chipaca> 2.4M on my notebook
<zyga> ogra_: we should start measure snappy core image sizes in terms of 720 floppies
<ogra_> yeah, thats more like i remember
<zyga> ogra_: this will let us see how big we are ;-)
<ogra_> +1
<ogra_> we are to big ... for sure
<Chipaca> right! swapping libc to musl in 3...
<ogra_> lol
<ogra_> lib modules as squashfs image !
<ogra_> err
<ogra_> /lib/modules
<Chipaca> initrd is whole root system!
<Chipaca> go works fine linking with musl, fwiw :)
<Chipaca> http://dominik.honnef.co/posts/2015/06/statically_compiled_go_programs__always__even_with_cgo__using_musl/
<ogra_> how abouot klibc ?
<ogra_> (that is actually well maintained in ubuntu)
<Chipaca> http://www.etalabs.net/compare_libcs.html
<Chipaca> ah, does not include klibc
<Chipaca> ogra_: wasn't klibc kernel-only or something?
 * Chipaca reads
<ogra_> no,. its a cut down glibc iirc
<Chipaca> i don't think systemd will work with that
<Chipaca> in fact i think the only one there are patches for systemd to work with is uclibc
<ogra_> good !
<ogra_> upstart will ;)
<Chipaca> ogra_: so you're going to implement socket activation for upstart?
<ogra_> we just need to change everything back
<Chipaca> \o/
<ogra_> we kind of have socket activation in use on the phone ;) (via hacked upstart jobs)
<Chipaca> remember when you searched for two words in google, and the first result actually included both words you looked for?
<zyga> ogra_: replace socket activation with dip switches
<zyga> ;)
<Chipaca> google "klibc systemd", first result has no systemd in it :(
<ogra_> yeah, dip switzches definitely dont get the attention they deserve anymore ...
<Chipaca> nor second, nor third, nor ...
<ogra_> jumpers killed the dip switch !
<Chipaca> there's a rather dark joke hiding in that statement, but i'm unable to wiggle it out
<ogra_> Chipaca, http://lists.freedesktop.org/archives/systemd-commits/2012-June/002047.html is what i hit when searching for klibc and systemd ...
<ogra_> but that seems to only refer to udev
<ogra_> (and is years old)
<shuduo> hi guys, i see someone (seems lool) is working on porting snappy onto edison but i'm not sure where it is. could anyone let me know if there is a  workable image already?
 * ogra_ doesnt think there is, but i could be wrong
<Chipaca> lool would know, though
<ogra_> yeah
<Chipaca> how bad would it be if, on installing a snap, all installed snap services restarted?
<ogra_> Chipaca, pretty bad i'd say
<Chipaca> unfortunately the documentation is unclear on whether that will happen, meaning i need to implement this before knowing
<ogra_> well, rolling is expected to break ;)
<ogra_> Chipaca, uuuh ... implementing a "phone home" service  to check if the network is up ?
<ogra_> Chipaca, how about instead checking if a default route exists ?
<sergiusens> morning
<Chipaca> ogra_: it's the standard "do you have internets" thing that's used in at least two other places
<ogra_> hmm
<Chipaca> ogra_: but, um, looking for a default route would work, also :)
<Chipaca> ogra_: comment on the mp?
<ogra_> just did :)
<Chipaca> sergiusens: mo'in!
<Chipaca> ogra_: ta
<sergiusens> Chipaca: I hink he has
<sergiusens> think*
<Chipaca> sergiusens: any comment on zyga's comment in the dynamicExclude branch?
<Chipaca> on the one hand, putting a file in the user's thing is Not What We Do
<Chipaca> on the other hand i see his point about it being magic and obscure and stuff
<sergiusens> @activereviews
<nothal> sergiusens: No such command!
<sergiusens> @activereview
<nothal> sergiusens: No such command!
<sergiusens> @help
<nothal> "list" To see the available commands ; "help cmd" for specific command help
<sergiusens> @list
<nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~fgimenez/snappy/config-for-remote-testbeds/+merge/266214 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/snappy-man/+merge/266203 | Needs Information: 1 (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/dynamicExclusion/+merge/266200 | Needs Fixing: 1 (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/generalize-build-tests-across-versions/+merge/266191 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 | Needs Information: 2 (less than a day old)
<sergiusens> Chipaca: we should have an alias, it's called activereviews in lp :-P
<Chipaca> agreed
<sergiusens> Chipaca: and help should just list :)
<Chipaca> sergiusens: https://code.launchpad.net/~verterok/lalita
<sergiusens> thanks
<ted> Morning folks!
<Chipaca> ooh, look at that, it *doesn't* restart everything \o/
<elopio_> hello, good morning.
<elopio> mterry: I did a shortcut to get this merged: https://code.launchpad.net/~elopio/snapcraft/fix1476452-python_log/+merge/265354
<elopio> next, if you give me the specs for the logging that you want I can configure the loggers.
<mterry> elopio, OK.
<mterry> elopio, so was the point of that MP to use loggers or to get rid of common.log?  Because you could have kept common.log and automatically had it add the bold to the message just like before and just done sed s/print/logger.info/
<elopio> mterry: the problem with keeping the old common.log is that you can't handle the messages differently depending on their origin and type.
<elopio> so I still like this one as a fist step towards using fancier logging.
<Chipaca> ogra_: parlez vous ip(8)?
<mterry> elopio, that's what arguments to a method are for  :)  but ok
<elopio> it handles differently info, error and warning, which we didn't have before. And opens the option to do bold depending on the origin. It's just that current bold rules are not consistent.
<mterry> elopio, or even common.info  :)
<mterry> elopio, not consistent?  We use them for step declarations and error messages
<jdstrand> rsalveti: where is the "user button" on the bbb? I feel silly...
<elopio> mterry: well, you can disapprove if you don't like it or don't find it useful. I won't feel bad :)
<elopio> mterry: isn't this a step:  print("Installing required packages on the host system: " + ", ".join(newPackages)) ?
<mterry> elopio, eh, that's an action inside a step.  we don't bold commands that plugins run
<rsalveti> jdstrand: near the sd card
<rsalveti> there is only one button
<ogra_> Chipaca, "ip -4 route list 0/0"
<Chipaca> ogra_: and if they're ipv6-only?
<Chipaca> :)
<ogra_> Chipaca, thnen you omit -4
<rsalveti> jdstrand: https://learn.adafruit.com/system/assets/assets/000/008/680/medium800/beaglebone_BeagleBoneBlack.jpeg
<Chipaca> ogra_: nice about 0/0
<elopio> mterry: what about snapcraft.common.log(stage + " " + self.part_names[0] + hint) ? Isn't that a command a plugin runs?
<mterry> elopio, I'm fine with the idea of loggers in general.  And I don't hugely care how it's implemented.  It just seems like you went out of your way to dismantle central message handling and then bemoan the lack of features that central message handling gives you  :)
<mterry> elopio, no that's the 'step declaration'
<Chipaca> ogra_: sad that it doesn't error if there's no route to it :)
<mterry> elopio, or stage declaration more accurately
<ogra_> Chipaca, yeah, it even returns 0
<ogra_> you need to check for stdout
<Chipaca> mhmm
<Chipaca> worse things have come to pass ;)
<elopio> mterry: it's more like I got rid of all the things I haven't understood yet, so I could make a transparent change first.
<elopio> with these answers you are giving me, I can configure the logging to get rid of the prints. I dislike the central messages because they replace the origin with the common module.
<elopio> so maybe if you want, you can wait for me to propose the next couple of branches.
<mterry> elopio, makes sense, I'm on board with your changes
<mterry> elopio, I'll look at your new branch this morning
<jdstrand> rsalveti: boy, not sure I'm coordinated enough to do this (I have mine in the case and turn it on/off by pulling the plug). here goes nothing...
<rsalveti> jdstrand: you could as well just erase the internal u-boot (in emmc)
<rsalveti> and reboot, that will force it to load the u-boot from the sdcard
<jdstrand> rsalveti: it wasn't clear it was possible to do that from my laptop
<rsalveti> no, you need do call it on a running system, so under bbb
<jdstrand> ie, I thought I might have to actually get into snappy, then erase it
<jdstrand> right
<jdstrand> hence the being coordinated part :)
<rsalveti> so yeah, you'd need to press the user button at least once
<jdstrand> anyhoo, I'll figure it out
<rsalveti> keep it pressed and then add power to it
<rsalveti> reset is not enough
<jdstrand> any news on flashing the emmc?
<rsalveti> not yet
<mterry> elopio, you left fatal in place, which is fine.  But there's a separate bug about snapcraft having too many exit points, and that maybe those fatal calls should be an exception that bubbles up to main() and gets logged there with a sys.exit call there.  Does that ruin your origin info too, or would the exception keeping track of the origin be usable when logging it?  (you don't need to do the exception thing in your branch, just thinking of future ch
<mterry> anges)
<jdstrand> rsalveti: so, I'm running a 4.2 kernel now (on vivid). I noticed that when I put the sd card in it showed up as /dev/mmcblk0 instead of /dev/sdX
<jdstrand> rsalveti: so I just specified /dev/mmcblk0 instead to the dd command. is this something you've seen or think it might be a problem?
<jdstrand> rsalveti: I'm talking about the dd to the sd card after creating an image with udf
<elopio> mterry: the traces have origin information, but anyway we don't want them to be visible to the user.
<ogra_> jdstrand, mmc devices never show up as sdX unless you use a USB reader
<rsalveti> jdstrand: yeah, depends on your host
<sergiusens> jdstrand: fwiw, my trusty laptop has always had mmcblk nodes
<rsalveti> if it's native, it shows up as mmcblk0
<jdstrand> ok good to know
<sergiusens> depends on how it's connected
<elopio> mterry: so the approach I think we should have is replace all those fatal calls by raise. But keep the logging on the module that generates the message.
<rsalveti> if under a usb bus, then it shows as /dev/sdX
<sergiusens> not sure why it would change though
<ogra_> right
<jdstrand> before I flashed with a reader in another host. this time I have a slot for the sd card
<mterry> elopio, so log the message then raise an error that doesn't include a message (or includes a duplicate, unused message)?
<jdstrand> gotcha. I was thinking that was the case but wasn't sure
<sergiusens> ogra_: a sw upgrade bringing in a hw upgrade :-P
<ogra_> hah
 * sergiusens wants his 8 gig of ram sw upgraded to 16!
<ogra_> just add zram :P
<sergiusens> jdstrand: ah, that explains it
<Chipaca> ogra_: better like this?
<Chipaca> ogra_: (talking about https://code.launchpad.net/~chipaca/snappy/delayed-service-start/+merge/266166 )
<ogra_> Chipaca, beauty !
 * Chipaca knows he is
<ogra_> :D
<Chipaca> one improvement could be to specify /sbin/ip instead of just ip
<Chipaca> not sure if i should care :)
<elopio> mterry: we can instantiate the exception first, and then use https://docs.python.org/3/library/logging.html#logging.Logger.exception
<elopio> we can choose if we want to log immediately after the exception was instantiated, or in a handler in one of the callers.
<Chipaca> ogra_: can i say your 'check for default route' insight solved all the ugly/iffy problems in the branch? hence why i say it was brilliant
<ogra_> heh, thanks :)
<Chipaca> sergiusens: webdm is where the bug is pointed at, but everybody wanting to do multicast will have the same problem
<Chipaca> sergiusens: which can be fixed per service by a single setsockopt call before you listen
<Chipaca> sergiusens: but golang doesn't let you setsockopt
<Chipaca> sergiusens: especially not before listening for multicast udp
<Chipaca> sergiusens: youd'd have to rewrite a buuunch of net/
<Chipaca> sergiusens: IP_FREEBIND is the sockopt fwiw
<sergiusens> Chipaca: yeah, I read the bug report
<sergiusens> Chipaca: btw; do we need a separate go bin, or on a different subject, does this need to be a go exec?
<Chipaca> sergiusens: webdm -> mdns's openSocket (private) -> net.ListenMulticastUDP[6] -> net.listenIPv{4,6}MulticastUDP (private) -> net.joinIPv{4,6}Group (private)
 * Chipaca suddenly feels lagged to the universe
<Chipaca> sergiusens: i'm not sure which "this" you mean wrt go exec
<Chipaca> sergiusens: you mean, does wait4network have to be go? no
<Chipaca> sergiusens: does it need to be separate? well, given it's potentially long lived, i'd rather it weren't all of snappy :)
<Chipaca> sergiusens: i could write it in C
<Chipaca> sergiusens: it could be sh, also
<sergiusens> Chipaca: long lived? doh, didn't see any exit; it's fine as is
<Chipaca> sergiusens: I could also stuff it as sh into ExecStart
<Chipaca> ExecStart=while ! ip route show 0/0 | grep -q .; do sleep 5; done
<Chipaca> dunno what sh systemd uses; if it has builtin [, i could use [ instead of grep for moar cheap
<Chipaca> e.g. while [ -z "$(ip route show 0/0)" ]; do sleep 5; done
<Chipaca> but that's asking a lot of a random sh
 * Chipaca does perf testing of that
<elopio> mterry: in this case:
<elopio> 133	+    logger.info('Wrote the following as snapcraft.yaml.')
<elopio> 134	     print()
<elopio> 135	     print(yaml)
<elopio> what you want is the first line to be bold, and the rest to be normal? Is that a rule we can apply to all the messages?
<jdstrand> rsalveti: sorry for being a pain. are there any known issues with 15.04/edge r132 and bbb? I flashed the sd card and booted holding the button and for sure the emmc didn't load, but neither did snappy
<jdstrand> I have udf 0.27-0ubuntu1
<rsalveti> jdstrand: hm, did it even boot into u-boot?
<rsalveti> U-Boot SPL 2015.07-dirty (Jul 17 2015 - 11:40:49)
<rsalveti> that is the boot loader that we are now using
<jdstrand> rsalveti: I don't know-- I only ever ssh in. I think I need a cable I don't have
<jdstrand> :\
<rsalveti> oh, ok, you don't have serial
<rsalveti> how did you generate the image?
<jdstrand> sudo ubuntu-device-flash core --channel=edge --oem=beagleblack --enable-ssh --output=15.04-edge.bbb 15.04
<jdstrand> sudo dd if=15.04-edge.bbb.r132 of=/dev/mmcblk0 bs=32M && sync
<mterry> elopio, that case is a little different than the others, a different flow (it's not iterating over parts or whatnot).  So I felt like the 'wrote' message was Snapcraft's top-level "here is what I'm doing" and the yaml was the content (plus it would be too intense if all the yaml was bold)
<jdstrand> (I had a mv 15.04-edge.bbb 15.04-edge.bbb.r132 in between)
<mterry> elopio, I'm happy to change some of these bold/not-bold decisions.  I just didn't want to block your python logger branch on hashing them out
<rsalveti> jdstrand: let me flash it from scratch and see
 * mterry is testing your branch right now
<elopio> mterry: ok, so what we need is two arguments, a message and a content. Or something like that.
<mterry> elopio, except usually the content comes much later (like when running a plugin's step, which has subcommands and all that)
<jdstrand> I'm excited to use the snappy-- I think I was affected by the fatwrite stuff cause every once in a while it would upgrade and never come back
<elopio> mterry: no, that's alright. We need to figure out a way to make it easier for all the cases. Which is not easy  :)
<elopio> there are many ways to do this, with filters, handlers, format and namespaces.
<elopio> I'm just trying to figure out which would be clearer.
<rsalveti> jdstrand: hm, worked fine in here, got ssh running and was able to get in just fine
<rsalveti> took a minute to boot, because of cloud-init, but it was fine
<rsalveti> jdstrand: did you put power while pressing the button?
<rsalveti> jdstrand: can you also give http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf+bbb.img.xz a try?
<jdstrand> rsalveti: I'll try the whole thing again
<rsalveti> this is latest stable
<rsalveti> has webdm and ssh by default
<jdstrand> I'll try with edge, if that doesn't work, I'll try with stable
<jdstrand> thanks
<rsalveti> cool
<rsalveti> it sucks not having serial easily
<jdstrand> and, yes, I held the button down while applying power
<rsalveti> jdstrand: can you see blinking leds?
<jdstrand> it was difficult, but I mustered the dexterity :)
<rsalveti> and the ethernet led as well
<rsalveti> just to know if the system booted or not
<jdstrand> yeah, all that is illuminated
<jdstrand> but it never asked for an ip address
<rsalveti> right, so it should be up
<jdstrand> actually, there are no blinking leds
<jdstrand> there is a solid blue, and then the green for the ethernet
<jdstrand> the green is blinking sporadically
<jdstrand> anyway, let me try it from scratch
<rsalveti> right, the ethernet led is already enabled by u-boot
<rsalveti> just the blue leds are the one that actually shows if the kernel booted or not
<rsalveti> if it doesn't work, guess you can mount at your host and look for the syslog
<ogra_> rsalveti, btw, do we have any docs how we generate that releases.u.c image ?
<rsalveti> see if booted in any way
<rsalveti> https://trello.com/c/PUpWXouz/89-stable-release-checkpoints
<ogra_> (i.e. any ready made scripts or anything)
<rsalveti> ogra_: ^
<ogra_> ah, k
<ogra_> :)
<mterry> elopio, you have a conflict on https://code.launchpad.net/~elopio/snapcraft/fix1477638-format_strings-2/+merge/265717
<Chipaca> ogra_: sergiusens: http://pastebin.ubuntu.com/11959990/
<Chipaca> ogra_: sergiusens: C wins every time :) but sh and go are tied
<Chipaca> and they're tied if you're generous towards go ;)
<ogra_> heh
<Chipaca> go is the only one that made the cpu think
<ogra_> yeah
<Chipaca> C manages to do it without context major pagefaults \o/
<sergiusens> Chipaca: do shell I guess
<sergiusens> Chipaca: try python for the kicks :-P
<ogra_> lol
<Chipaca> i love python, but this is not a dick contest it'd win, ever
<ogra_> especially not on arm :)
<Chipaca> micropython, however .... :-p
<ogra_> hahaha
<jdstrand> rsalveti: ok, I have a solid blue led then a couple of rapidly blinking blue leds over the usb port
<jdstrand> they are now solid
<rsalveti> hm, kernel booted then
<ogra_> yeah
<jdstrand> and now it is pingable
<jdstrand> ok, good!
<rsalveti> dholbach: how to change https://developer.ubuntu.com/en/snappy/start/ ?
<rsalveti> I get "You do not have permission to edit this plugin"
 * jdstrand guesses something went wrong with the initial dd
<jdstrand> it's working now though
<dholbach> rsalveti, you logged in using /openid/login and all the boxes were ticked?
<rsalveti> dholbach: yeah
<dholbach> rsalveti, which part of the page are you trying to edit?
<rsalveti> dholbach: Getting started with a Beaglebone Black
<rsalveti> to add the instruction about the sdcard booting process
<dholbach> let me see if I can change it
<dholbach> strange, it works for me
<rsalveti> hm, let me try to login again
<dholbach> mhall119, do you have any idea why rsalveti might get "You do not have permission to edit this plugin" when trying to edit the "Getting started with a Beaglebone Black" section on https://developer.ubuntu.com/en/snappy/start/?
<rsalveti> still, even after doing a clean login on another browser
<rsalveti> and I was in the developerportal-editors group
<mhall119> dholbach: because rsalveti is a suspicious character with questionable motives?
<rsalveti> that might be true
<rsalveti> :P
<mhall119> or because he didn't tell SSO to pass along his team membership?
<rsalveti> I did
<mhall119> or his session cookie has expired
<rsalveti> mhall119: dholbach: so I can change the top part of that page
<rsalveti> but not the bbb piece
<rsalveti> maybe that is a different page
<mhall119> not a different page, but a different content plugin within the page
<rsalveti> if I double click at "Getting started with a Beaglebone Black", I get not enough permission
<rsalveti> I can change the rpi2 part
<mhall119> hmmmm, I can save it (I made no changes)
<rsalveti> but not the bbb
<rsalveti> the vagrant part is also fine
<mhall119> weird...
<mhall119> rsalveti: have a call right now,but I'll keep investigating
<rsalveti> mhall119: np
<Chipaca> pitti: a first pass at moving our services to a generator shows that generators are run before the local fs is mounted
<pitti> Chipaca: correct
<pitti> they run as pretty much the first thing, as they could (and often do) create early-boot units
<Chipaca> pitti: and yet they purport to be for converting one config to systemd services
<pitti> like fstab :)
<Chipaca> pitti: which is hard to do without a filesystem
<pitti> Chipaca: why? the generated units are in /run/
<ogra_> tmpfs ftw
<Chipaca> pitti: how do you read the config you're trying to convert?
<pitti> a generator should *only* create units, it shoudln't actually run logic
<pitti> Chipaca: well, you have a r/o root, you can read it?
<pitti> oh, unless you need mounts from fstab
<Chipaca> i don't seem to have that, no
<Chipaca> :)
<pitti> we still don't do the writable-mounts from initramfs, but from the running system, don't we
<ogra_> yes, you should have the ro root
<pitti> Chipaca: ok, if you need info from fstab mounts, you can't use generators, I'm afraid
<ogra_> else systemd wouldnt be running ;)
<ogra_> the binary was started from that ro root
<Chipaca> pitti: can a unit call daemon-reload without the world asploding?
<pitti> Chipaca: yes, that should work; daemon-reload is done all the time
<Chipaca> that'd work then
<pitti> that'll re-run the generators
<Chipaca> exactl
<Chipaca> y
<pitti> but it won't auto-start the new units, as the initial boot transaction already ran; so you need to do that too
<pitti> or (and I think that makes much more sense), we move the writable mounts that you need into initramfs
<Chipaca> that does sound nicer :)
<pitti> booting from a root partition which isn't actually your root partition has caused tons of trouble, you are just experiencing the n+1st one
<Chipaca> we'll see; right now i think i need to step away from this for a bit again to do some paperwork
<Chipaca> oh man, +1 to initrd-is-root-is-all :)
<pitti> yeah, I still remember several hacks because we don't do that, and I'm not even working on snappy :) I guess you guys must have done tons of them
<Chipaca> pff
<ogra_> pitti, hacks ?
<Chipaca> you say hacks, i say flexible engineering
<pitti> :)
<ogra_> we use the mountroot function of initramfs-tools ... :)
<ogra_> (we just replaced all of it, but thats a small detail :P )
<Chipaca> that's like saying "oh, no, it's pure regular python; we just patched it to make func_code writable"
<ogra_> *g*
<Chipaca> ... except in 3.4 func_code *is* writable
<Chipaca> hah
<longsleep> ogra_: i just got fat corruption with old style u-boot on odroidc ... i guess i should roll a new image asap
<ogra_> longsleep, +1 ... stop scaring me like that :)
 * ogra_ saw uboot and corruption as first word even before reading the whole line 
<longsleep> ogra_: hehe sorry - OLD style uboot only
<ogra_> yeah :)
<ogra_> *words
<longsleep> now of someone would review my OEM snap so i could test with that as well ;-)
<ogra_> i wonder if beuno is around to do that :)
<longsleep> Now that i am testing again is there something i can do to get rid of all the DISCARD mount output on boot (see http://paste.ubuntu.com/11960346/), or is this normal?
<ogra_> i *think* thats a leftover from the phone code
<ogra_> but if oyur controller and Sd support it it will speed up your IO
<ogra_> we should probably make that configuarable so you can turn it off for HW that doesnt
<longsleep> ogra_: yeah - but i think sdcards never support discard
<ogra_> i had some (not micro) that did in my ac100 netbook (they made a significant difference on that tiny arm device)
<ogra_> not sure if there are any microSDs that support it at all though
<ogra_> but i dont think i have seen that error on the BBB
<longsleep> oh really - i thought sdcards no matter what size do wear leveling internally
<ogra_> http://paste.ubuntu.com/11960398/
<longsleep> ok similar
<ogra_> no DISCARD messages
<longsleep> yes - there are sd controllers pretending to support discard - but still it will not work afaik
<ogra_> yeah
<longsleep> there is a MMC_ERASE command in the SD spec, not sure how this adapts to discard though
<ogra_> the "couldn't mount" thing is fine, thats just the kernel looping over all possible ext filesystems it knows
<longsleep> ah ok
<longsleep> ogra_: so on the BBB it seems to mount with discard for you?
<ogra_> no idea why it first tries ext3, then ext2 and only then ext4
<ogra_> yeah, at least it doesnt complain
<longsleep> ok let me check that then
<longsleep> what card is that ?
<ogra_> apw, isnt there a way to turn off that babbling about the kernel trying out filesystems in the logs ?
<ogra_> longsleep, some 4GB panasonic one, dunno the exact name ... mediamarkt-cheapo-ware
<ogra_> says "made in taiwan" pretty prominently at the front :)
<longsleep> ogra_: oh panasonic should be enough, i only seem to have sandisk and sony ones here
<ogra_> i dont use the good ones for frequent dd sessions ... i have others indeed
<ogra_> 32-128G
<ogra_> samsung and lexar
<longsleep> ogra_: but even if it would support it, i would still suggest not to use discard mount option. It is much better to regularly run fstrim
<longsleep> ogra_: and those mount fine with discard as well?
<ogra_> pitti, ^^^ do you know if we do that on snappy
<ogra_> longsleep, i have never noticed your error during my boots so i guess they at least hide it well (or i simply never noticed :P )
<longsleep> yeah well, some sd controllers just claim they support discard
<ogra_> i know we have some userspace stuff to run fstrim regulary ... if the discard option isnt set in fstab
<ogra_> but i'm not sure we ship that bit on snapy
<longsleep> so when you run fstrim -v /
<longsleep> does it trim something ?
<ogra_> /: 533 MiB (558919680 bytes) trimmed
<ogra_> not bad :)
<longsleep> ok - so try again and see if it is zero now
<ogra_> yeah, i guess we should make sure to have pitti's fstrim stuff included then
<ogra_> yup, it is
<longsleep> ok - that seems nice then
<ogra_> (and drop discard)
<longsleep> mhn no hdparm on snappy :/
<ogra_> that was on the list for comfy iirc
<longsleep> ogra_: so for your sdcard, can you try to trim system-a from the pc? Also on the pc, what does 'sudo hdparm -I /dev/$sdcard' show for yours if you find the time.
<longsleep> ogra_: mine looks like this: http://paste.ubuntu.com/11960496/
 * longsleep wants to make sure that it is the sdcard and not the kernel or card reader
<ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ sudo fstrim -v /media/ogra/system-a
<ogra_> fstrim: /media/ogra/system-a: FITRIM ioctl failed: Vorgang wird nicht unterstÃ¼tzt
<ogra_> longsleep, seems my USB reader doesnt hand it through
<longsleep> ogra_: so you cannot trim on the PC but on the device?
<ogra_> yep
<ogra_> might be the cheapo reader i use on the PC
<longsleep> ok
<ogra_> hdparm isnt helpful either
<ogra_> /dev/sdc:
<ogra_> SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<ogra_> Unknown device type:
<ogra_> 	bits 15&14 of general configuration word 0 both set to 1.
<ogra_> thats all i get from it
<longsleep> oh
<longsleep> that is not much - ok so i need to dig deeper and see if i can get this card to trim on another device - thanks for your help
<ogra_> thanks or pointin it out, i'll try to catch pitti tomorrow to take a deeper look
<longsleep> sounds good thanks
<ogra_> *for pointing ...
 * ogra_ needs a break :)
 * longsleep grabs a Cuba Libre soon :P
<ogra_> +1
<elopio> mterry: "each part is build" is wrong, right? It should be built, I think.
<elopio> english is hard.
<mterry> elopio, uh oh, in my docs branch?  Let me see
<ogra_> everyone is build !
<longsleep> everyone is bluna
<mterry> elopio, fixed
<ogra_> yummy !
<longsleep> New snappy images for ODROID-C1: https://www.stdin.xyz/downloads/snappy/odroidc/20150729/ if anyone wants to try it before i write release notes tomorrow
<elopio> mterry: +1, but there seems to be a conflict.
<apw> re
<elopio> well, a wrong merge actually, you have 415	-<<<<<<< TREE
<apw> ogra_, lowering loglevel perhaps, or lowering level logged by syslog
<mterry> elopio, in which branch?
<mterry> elopio, I just did a merge from trunk, may have screwed up something
<ogra_> apw, well, without tweaking the loglevel ... i find this annoying on my desktop too :)
<ogra_> couldnt we quieten the driver ?
<ogra_> i think it causes a lot of confusion for many people
<elopio> mterry: https://code.launchpad.net/~snappy-dev/snapcraft/docs/+merge/266243
<ogra_> "i have an error when my rootfs gets mounted"
<apw> hmmm really? it has always always done that
<mterry> elopio, can you pull or branch again?  I think you have old code?
<elopio> mterry: I'm just looking at the MP on launchpad.
<elopio> mterry: might be launchpad being crazy.
<ogra_> apw, i think it only started with ext4
<ogra_> before it didnt loop over ext2 to mount ext3 ... or it simply was quiet when doing that
<mhall119> rsalveti: can you try editing the bbb section again?
<mterry> elopio, yeah I don't see why it's doing that
<mterry> elopio, I mean, I see it doing it.  I just don't understand why
<mterry> elopio, ok, merged again from pre-req branch, fixed it
<elopio> yes, looks good now.
<mterry> lool, when I try your tomcat-webapp-demo, it doesn't seem to run correctly.  journalctl shows "Tomcat started" but no processes are running by the time I get to do a 'ps'
<rsalveti> longsleep: still need help with the oem review?
<rsalveti> it seems it already landed
<rsalveti> so should be all good
<rsalveti> mhall119: still can't change it
<mhall119> rsalveti: how about now?
<rsalveti> mhall119: nops
<mhall119> rsalveti: log out and back in?
<rsalveti> mhall119: nops
<rsalveti> still You do not have permission to edit this plugin
<rsalveti> just this part
<mhall119> ok...this is very strange indeed
<mhall119> rsalveti: ok, one more time, log out and back in, refresh the page (clearing cache) and try it again
<rsalveti> mhall119: yay, finally
<rsalveti> mhall119: what was it?
<mhall119> ok, ok, don't get too excited
<mhall119> rsalveti: I made you a super-user, gives all perms to everything, which I'm revoking now
<mhall119> rsalveti: log out, back in, and try again please
<rsalveti> mhall119: same error
<mhall119> heh, well, that narrows it down a little...
<mhall119> rsalveti: again please
<rsalveti> mhall119: nops
<mhall119> rsalveti: again?
<mhall119> logging out and back in, refreshing, etc
<rsalveti> mhall119: seems to be working
<mhall119> getting closer
<rsalveti> mhall119: did you fix it or are you trying something else?
<mterry> ogra_, OK...  I'm setting up my beaglebone black.  I booted up an sd card with the latest image.  I'm attached via usb.  But when I try to ssh into webdm.local, it isn't responding.  How do I know where I went wrong?
<rsalveti> mterry: did you try to boot while holding down the user button?
<rsalveti> so it forces it to boot from the sdcard
<rsalveti> also, which image are you using?
<mterry> rsalveti, one published yesterday or so
<mterry> rsalveti, I have to hold down the user button!  didn't know
<mhall119> rsalveti: I have you more permissions, now I'm going to take some away until it stops working again
<rsalveti> mhall119: alright
<rsalveti> mterry: yeah, that's why I'm trying to update our docs :-)
<rsalveti> and fighting that over with mhall119
<mterry> rsalveti, is it that unlabled button near the sd card?
<rsalveti> mterry: https://learn.adafruit.com/system/assets/assets/000/008/680/medium800/beaglebone_BeagleBoneBlack.jpeg
<rsalveti> yeah
<mterry> rsalveti, ...  that is not user friendly  :)
<rsalveti> hold it down and then put power in your board
 * mterry loves software
<rsalveti> once booted you can erase the u-boot from emmc
<rsalveti> then it will automatically load the one from the sdcard
<mhall119> rsalveti: try again please
<mterry> rsalveti, is there a doc for doing that?  (I have SO little experience with circuit boards)
<rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
<rsalveti> once booted
<mterry> k
<rsalveti> mterry: just the email I sent yesterday atm
<rsalveti> mhall119: still fine
<mhall119> rsalveti: and now?
<rsalveti> mhall119: not anymore
<mhall119> rsalveti: how about now, working again?
<rsalveti> mhall119: yes
<mhall119> ah ha! identified the missing permission
<rsalveti> cool, what was it?
<mhall119> rsalveti: one last try, I've set the missing permission to the ubuntudeveloperportal-editors group and removed it from your user account, so please try it again and it should (hopefully) still work
<rsalveti> mhall119: still working
<mhall119> \o/
<mhall119> rsalveti: it was the raw HTML plugin permission you didn't have
<rsalveti> mhall119: interesting
<rsalveti> mhall119: why just that piece?
<mhall119> the db setup command gives the editors group permissions to all the Django CMS stuff, but the raw html plugin was something we created, and so it lives outside of the django-cms permissions set
<rsalveti> oh, alright
<mhall119> so we need to fix the initdb.py command to include that
<lool> mterry: Yes, I have to patch the catalina.sh still
<mhall119> but for now it's fixed in the production db
<lool> mterry: I didn't figure out why exactly, but I need to remove the "&" in the "start" invocations
<rsalveti> mhall119: awesome, thanks for helping me out with this
<lool> mterry: I couldn't really tell who was at fault, so I didn't examine this further; one way out of it, it to fork catalina.sh into the demo snap, but I had already copied the config and wanted to avoid copying the whole tomcat dist over
<mhall119> rsalveti: no problem, thanks for patiently helping me debug it
<mterry> Maybe my sd card is bad
<mterry> When I press the user button all I ever get is power light on, but no flashing "activity" lights.  and no webdm
<mterry> rsalveti, ogra_: ^ tried again with new flashed card.   Is there a way to see what's happening after I boot with the user button pressed?  (definitely different behavior without pressing, but not leading to a working BBB)
 * mterry is an idiot!
<mterry> BBB isn't connected to ethernet
<mterry> I assume I have to do that
<rsalveti> if you don't have serial, yes
<rsalveti> the only way to access would then be with ssh
<rsalveti> without the user button I believe it will end up booting debian instead (which is flashed in the emmc by default)
<rsalveti> unless you erased your emmc before
<mterry> rsalveti, I think I'm booting off the sd card (I get different light behavior than booting without user button)
<rsalveti> right
<mterry> rsalveti, ethernet plugged in didn't seem to let me get wedm.local either (and I rebooted the BBB)
<rsalveti> might just be missing the ethernet cable :-)
<rsalveti> make sure to press the button when powering up the device, only when rebooting is not enough
<rsalveti> might take one minute to boot due cloud-init
<mterry> rsalveti, powering on is what i meant
<mterry> not rebooting
<mterry> yeah, i've waited several minutes
<mterry> :(
<mterry> maybe I will try the raspberry pi
<rsalveti> mterry: did you use the pre-built image or did you create one with ubuntu-device-flash?
<rsalveti> http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/20150729/
<mterry> rsalveti, I used http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-armhf-bbb.img.xz
<rsalveti> yeah, should be good
<rsalveti> it's the same
<rsalveti> that is annoying
<rsalveti> when it boots here the blue leds blink for a while
<mterry> rsalveti, I'm sure it's user error.  I've just not done this before
<mterry> rsalveti, ah interesting.  I get no blinking when I hold down the user button
<rsalveti> that means it's not even booting the ubuntu image
<mterry> :(
<rsalveti> wonder if the default debian image got ssh or some sort of it by default
<rsalveti> let me check that
<rsalveti> try booting without the sd card to see what happens
<mterry> rsalveti, well, booted without the user button anyway.  ethernet in.  Do you know what the default address is?
 * mterry will resume this later
<rsalveti> Note: Depending on your internal network these may work out of the box
<rsalveti> Apache, Port 80: http://arm.local/ (Bone: via usb) http://192.168.7.2
<rsalveti> SSH, Port 22: ssh debian@arm.local (Bone: via usb) debian@192.168.7.2
<rsalveti> Getty, Serial Port
<rsalveti> check http://elinux.org/BeagleBoardDebian as well
<mterry> rsalveti, found 192.168.7.2 online yeah
<mterry> rsalveti, I can log in to default debian image
<rsalveti> nice
<mterry> so it's not the board or the ethernet.
<rsalveti> sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1024 count=1024
<mterry> rsalveti, i checked the shasum of my downloaded image
<rsalveti> that will kill the internal emmc u-boot
<rsalveti> and will force it to always boot via the sdcard
<mterry> rsalveti, ok.  so no user button now
<rsalveti> yeah
<mterry> rsalveti, hrm.  no blinking lights  :)
<rsalveti> makes no sense
<rsalveti> maybe try running dd again
<rsalveti> sudo dd if=ubuntu-15.04-snappy-armhf-bbb.img of=/dev/mmcblk0 bs=32M
<mterry> rsalveti, I already did that over once...  :-/  When I plug it into my laptop, I see all the partitions.  It feels right
<mterry> rsalveti, but I can try again, doesn't hurt
<rsalveti> unless it's an issue with the sdcard or the reader in the bbb
<rsalveti> or a different beagle revision
<rsalveti> mterry: give http://cdimage.ubuntu.com/ubuntu-snappy/15.04/stable/20150609/ a try as well
<rsalveti> if it doesn't work, that is our previous image
<rsalveti> contains a different bootloader
#snappy 2015-07-30
<murphylaw>  /msg nickserv register clobrano irc*10QpAlZm
<dholbach> good morning
<fgimenez> good morning
<admcleod1> hi guys, deplying docker containers in bridge mode, looks like im hitting a veth (or mac address? limit) seems to be ~50: systemd-udevd[5378]: Could not generate persistent MAC address for veth8aed386: No such file or directory
<admcleod1> is it code or config?
<JamesTait> Good morning all; happy Cheesecake Day! ð
<vmayoral> ogra_: ping
<ogra_> hey vmayoral
<vmayoral> ogra_: greetings :), could you please point out which config file you guys use to compile BBB kernels?
<ogra_> vmayoral, oh, thats ppisati  land :)
<vmayoral> ogra_: great, thanks for referring
<ogra_> effectively it should be in /boot by default though
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 3.19.0-23-generic #24-Ubuntu SMP Tue Jul 7 18:56:34 UTC 2015 armv7l armv7l armv7l GNU/Linux
<ogra_> (BeagleBoneBlack)ubuntu@localhost:~$ ls /boot/config*
<ogra_> /boot/config-3.19.0-23-generic
<vmayoral> ppisati: true! found it, thanks a lot
<vmayoral> i was fighting with "omap2plus_defconfig" but didn't looked there. Great, thanks!
<ogra_> make sure the version matches ... that only works on installs that havent seen a kernel upgrade yet
<ogra_> (its a bug, we need to actually ship the config in the a/b subdirs)
<ogra_> pitti, hey ho ....
<ogra_> pitti, in the systemd world, which parts of the system are responsible for fstrim ?
<pitti> hey ogra_
<ogra_> we moount with discard by default currently ... but that seems to be a no-op on most SDs
<ogra_> (and i bet on many USB sticks too if it comes to x86)
<pitti> ogra_: it's not really init system specific -- util-linux has /etc/cron.weekly/fstrim which regularly calls it
 * ogra_ checks if we ship that
<ogra_> yeah, we seem to
<pitti> ogra_: it seems regularly calling fstrim is preferred over "discard", at least on desktop-ish use cases
<pitti> it's a "performance sucks once a week" vs. "performance sucks a little all the time" tradeoff mostly
<ogra_> pitti, yeah, discard comes from our phone install
<pitti> but at least in the past there were also some actual bugs with discard
<ogra_> the MMCs fully support it so we preferred to not have a userspace process consuming extra cycles IIRC
<pitti> (back in 20 mins)
<ogra_> for snappy we should drop the discard though i think
<pitti> ogra_: yeah, the tradeoff might be different on a phone; discard might make sense there, then the cronjob ought to be a no-op (and we could even disable it)
<ogra_> and rely on fstrim
<pitti> I agree
<pitti> snappy usually runs all the time, phones are often suspended etc, so cron jobs don't work well on a phone
<pitti> ... until we snappify the phone of course :)
<ogra_> yep
<ogra_> bug 1479711
<ubottu> bug 1479711 in initramfs-tools-ubuntu-core (Ubuntu) "snappy should not mount with "discard" option" [Undecided,New] https://launchpad.net/bugs/1479711
<ogra_> pitti, ^^^
<longsleep> yay +1
 * ogra_ will collect some more freedback and then just drop it from the initrd if nobody objects
<ogra_> ooooh ... new splash screen on my phone, nice !
<longsleep> quick snapcraft questin - can i just add a plugins into my project or do i need to att them to snapcraft plugins folder?
<clobrano> hi guys, I'm trying to package some simple utilities like minicom/wget, but I don't get how to declare their shared libraries dependencies
<ogra_> you dont, you ship them in the snap
<ogra_> under usr/lib/<arch_triplet>/
<clobrano> I though it was like this, but still get errors like "error while loading shared libraries"
<clobrano> ogra_: ah sorry, didn't read the last message, I'll try that
<longsleep> anyone can point me on an example snap which starts a service with a configuration file, preferrably created on first start or something?
 * longsleep wonders if he is the first one who needs to do that
<clobrano> ogra_: thank you, that worked
<ogra_> :D
<clobrano> ;)
<Chipaca> longsleep: what do you mean?
<Chipaca> longsleep: you've got $SNAP_APP_DATA_PATH
<Chipaca> longsleep: you can write to that, if that's what you mean
<Chipaca> (and if you can't, that's a bug :) )
<longsleep> Chipaca: yes - i learned a lot about this the last hour - though i was wondering if i have to write all the scripts myself or if there is some generic scripting somewhere to do this
<longsleep> i mean, i was looking for something similar to the postinst preinst stuff from debian packages
<Chipaca> longsleep: i'm not sure what scripts you mean, here
<Chipaca> ahhh
<Chipaca> no such thing
<Chipaca> so, atm, yes you write your own thing
<Chipaca> i'd be glad to help
<longsleep> all right - thats what i figured - so i was wondering if someone else already did something
<longsleep> any help would be very welcome, i can easily script the stuff but i would prefer to know something about why my script is started
<longsleep> was it the first install
<longsleep> what was the old version
<longsleep> stuff like that
<Chipaca> yes, i was just thinking about that a bit
<Chipaca> i don't have anything particularly insightful yet :)
<longsleep> also there seems to be a folder "current" inside /writable/system-data/apps/spreed-webrtc/
<Chipaca> but i suspect a lot of people will need to have something like a "run once" or "run on version change" script
<longsleep> can you tell me if that is always the case?
<Chipaca> longsleep: if the current symlink isn't there, the app isn't "installed"
<Chipaca> longsleep: (you can have it present but not installed)
<longsleep> Chipaca: ok - so i should always use the current path in anything i need to access from there?
<Chipaca> longsleep: anything where you don't care about the version, yes
<longsleep> ok that is helpful already :)
<Chipaca> ogra_: do you know if Bad Things happen if I reference a mounted partition from g_multi?
<Chipaca> longsleep: note you've got a bunch of environment variables to help you with this
<Chipaca> longsleep: hello-world.env prints them out
<Chipaca> the ones starting with SNAPP_ are deprecated ;)
<longsleep> Chipaca: yes - i saw that one - i will check it out
<longsleep> Chipaca: oh - all right so i will try to avoid those
<longsleep> Chipaca: what about calling system utilities in general, how should i call to those, full path, expect them to be in $PATH, do not call them, ship them?
<longsleep> for example openssl
<ogra_> Chipaca, hmm, for what usecase with the g_milti module ?
<Chipaca> ogra_: i'm testing it out on snappy bbb; main thing i want is to have network (& serial?) but if it also gives me safe access to a partition that's a win
<Chipaca> longsleep: try it and tell us? it should work unless you're reading/writing things you shouldn't (or we forgot about :) )
<ogra_> you want to expose it as usb device to be able to mount it ?
<Chipaca> ogra_: g_multi lets me do that, apparently. I'm asking if it's safe :)
<ogra_> that should be possible ... the MMC debian install does it, i bet just stealing the config from there would work ;)
<longsleep> Chipaca: so the question is what i can expect for tools like sed, grep, awk, openssl and possibly other stuff. I mean for debian packages i have dependencies on those. What if one of these tools are suddenly gone in newer images?
<ogra_> (since that seems to be tested and proven already)
<Chipaca> ogra_: but the debian mmc seems to reference the sd card
 * Chipaca looks
<ogra_> and you dont want that ?
<Chipaca> sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p1 host_addr=D0:5F:B8:A3:92:81 iManufacturer=Circuitco iProduct=BeagleBoneBlack iSerialNumber=C0-3614BBBK6053 idProduct=0 idVendor=0 luns=0 nofua=Y num_buffers=2 qmult=5 removable=Y stall=N
<ogra_> i think it even only references /boot currently
<Chipaca> ^ that's what debian does, translated into modprobe
<Chipaca> i need to boot back into debian to see if mmcblk0 is the sd card or not
<ogra_> yeah, so just copy it and use whatever file= option you like :)
<Chipaca> longsleep: sed, grep, awk should work
<ogra_> i think it is the MMC in debian
<Chipaca> longsleep: openssl should work afaik
<Chipaca> longsleep: when i say "should" i mean "it's a bug if it doesn't", and also that we're using some of those in e.g. hello-world stuff
<longsleep> Chipaca: yes they all work at the moment, though i could not find a list of "save to use tools from the system". It is probably something which should be created.
<Chipaca> longsleep: that is: you can execute anything in the usual system path
<Chipaca> longsleep: some things, like python :), will go away at some point (from core)
<longsleep> Chipaca: right, but how do snaps handle it when they depend on a tool which went away?
<Chipaca> longsleep: we might at some point go crazy and replace all the rest with busybox, but it's unlikely :)
<Chipaca> hmm.
<Chipaca> longsleep: that's a good question
<Chipaca> longsleep: the quick and wrong answer is that they shouldn't depend on things that're going to away
<Chipaca> :)
<longsleep> right :)
<Chipaca> the true answer is probably "we need to write some kind of thing that promises what won't go away"
<Chipaca> longsleep: for a start, everything POSIX asks for, will be there always
<Chipaca> longsleep: that leaves out, i think, awk, perl, and python
<Chipaca> and iptables, say :)
<longsleep> Chipaca: Perl and Python should be frameworks if you ask me
<Chipaca> longsleep: well, except frameworks don't work like that, but yes
<longsleep> Chipaca: awk is nice to have, for my use case, i need to make sure i got openssl
<Chipaca> longsleep: the expectation right now is that if you're building using perl or python, you should ship those in your snap
<longsleep> Chipaca: all right, thanks - lets see what i can do with some script fu
<Chipaca> ogra_: rsalveti: we need to make a list of things that are not going away :)
<longsleep> Chipaca: what about the shell, is it bash, dash, whatever else?
<Chipaca> ogra_: rsalveti: and pretty pleas let's have openssl on that
<Chipaca> longsleep: /bin/sh is dash
<longsleep> Chipaca: ok, any plans to change that?
<longsleep> or rather, dropping /bin/bash ?
<Chipaca> longsleep: i don't know about bash
<Chipaca> longsleep: in my mind, it's huge and bloated and i love it
<Chipaca> :)
<Chipaca> longsleep: so once things settle and we start paring down, it's a candidate to go
<Chipaca> longsleep: in my mind
<Chipaca> longsleep: but note we have not discussed this at all
<longsleep> well, i might be able to use dash only - though i do not really like it
 * Chipaca is aware
 * ogra_ would like to see bash moved to comfy 
<ogra_> longsleep, https://wiki.ubuntu.com/DashAsBinSh has some hints for scripters :)
<Chipaca> we should go make our own distro, call it uubuntu (because u- is for Âµ; also because the long first vowel is distinctive of my CÃ³rdoba roots)
<longsleep> ogra_: yeah - i had some fun in the past porting scripts to upstart
<Chipaca> dash and busybox's ash are essentially the same, yes?
<longsleep> Chipaca: so the hello world example showing the variables you mean http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-world/meta/ right?
<Chipaca> with all the bling turned on in busybox that is
<Chipaca> longsleep: i mean if you install it and run hello-world.env it'll print them out for you
 * longsleep has no idea about the differences between dash and busybox
<longsleep> Chipaca: right - let me try that
<Chipaca> we could sort the output, that would be nice of us
<Chipaca> ogra_: any idea whether i can read the bbb's serial number from anywhere?
<Chipaca> ogra_: also, any idea for generating a stable random mac on the bbb :)
<longsleep> Chipaca: well anyone can |sort
<Chipaca> longsleep: yes. But if the script did it itself, you'd know more about what tools you can use :)
<longsleep> right, what is the history of the SNAPP double P vars?
<ogra_> Chipaca, no, i just noticed it isnt set ... usually from /proc/cpuinfo
<Chipaca> longsleep: snappy app -> snapp
<Chipaca> longsleep: somebody thought it was a good idea
<ogra_> with the latest image you should definitely have afixed MAC though
<Chipaca> longsleep: they changed their mind :)
<ogra_> i surely do here
<Chipaca> ogra_: i meant for g_multi
<Chipaca> ogra_: because the bbb has *two* ethernets! one is hidden inside g_multi :D
 * Chipaca loves all the ethernets
<ogra_> oh
<ogra_> hmm, probably there is something hidden in sysfs
<Chipaca> ogra_: i'll grep
<longsleep> for the ODROID, the serial is available in U-Boot and could be passed as parameter to the kernel.
<longsleep> maybe it is similar with the bbb
<Chipaca> looks like it
<ogra_> yes, i just dont get why it doesnt end up where it should
 * ogra_ will have to dig
<Chipaca> eeee
 * Chipaca just mounted /writable on his host
<davmor2> ogra_: I don't know how often I can explain this, but technology hates us, you have to hate it back, it doesn't help the issue but it makes you feel a lot better ;)
<Chipaca> ogra_: i could also just let g_multi assign random things, that works
<ogra_> well, i dont really think it matters since the USB cable will never see a real ethernet :)
<ogra_> so theoretically your MAC can be whatever you want it :)
<Chipaca> ogra_: it only matters if you're doing fancy firewally stuff
<ogra_> 00:11:22:DE:AD:BE:EF
<ogra_> :)
<ogra_> doews that MAC matter for firewalling over USB ? i'd expect that to hook into a higher layer
<ogra_> it might matter for IP assignment
<longsleep> Chipaca: so where should i create the config file, in the environment i only see folders which contain the version. I need to store stuff which is independent from version.
<longsleep> Chipaca: i see this SNAP_APP_DATA_PATH=/var/lib/apps/hello-world.canonical/1.0.18
<longsleep> but i would need /var/lib/apps/hello-world.canonical/
<longsleep> (assuming it is writable)
<Chipaca> longsleep: the data path is always versioned
<longsleep> Chipaca: mhm so where do i store stuff i want to keep across versions then?
<Chipaca> longsleep: you should have /var/lib/apps/, and it should be writable by your service
<Chipaca> longsleep: on upgrade, the data directory is copied
<longsleep> Chipaca: ah ok
<Chipaca> longsleep: service stopped, data directory copied, current symlink redirected, service started
<longsleep> Chipaca: sounds good thanks
<Chipaca> longsleep: um
<ogra_> AHA
<Chipaca> longsleep: if the user rolls back, and then rolls forward, things get iffy
<ogra_> usbnet_devaddr=78:a5:04:f4:c1:00
<ogra_> seems uboot has it
<ogra_> how do we get it across to the kernel now ?
<longsleep> just add some parameter and parse /proc/cmdline in user space
<longsleep> (that is how android does it)
<ogra_> well, i would be hoping there is no need to parse anything if we use the right cmdline option
<longsleep> ogra_: yeah - you might have a driver in place which does it already
<Chipaca> ogra_: sudo modprobe g_multi bcdDevice=0 cdrom=N file=/dev/mmcblk0p4 iManufacturer=Circuitco iProduct=BeagleBoneBlack idProduct=0 idVendor=0 luns=0 nofua=Y qmult=5 removable=Y stall=N
<Chipaca> ogra_: check if that gives you the right mac (in dmesg)
<Chipaca> i wonder what it used iSerialNumber for; it isn't complaining without it
<Chipaca> ogra_: i say we add that to bbb's modprobe.d :)
 * ogra_ twiddles thumbs waiting for cloud-init again 
<Chipaca> then i can ditch the clumsy ethernet cable! woo :)
<Chipaca> grmbl grmbl cloud-init
<ogra_> hmm, no, the MAC doesnt match anything from uboot
<sergiusens> Chipaca: implement https://trello.com/c/W5WiZQM7/117-core-config-for-cloud-init ;-)
<Chipaca> ogra_: ah well
<Chipaca> ogra_: i still say we add that to the modprobe
<Chipaca> can figure out the serial number and mac later
<Chipaca> it doesn't seem like anything breaks without 'em
<ogra_> yeah
<Chipaca> note that modprobe lets you mount writable on the host
<Chipaca> which is pretty sweet, if you ask me :)
<Chipaca> sergiusens: i'd love to
<Chipaca> rsalveti: ^ put me down for core-config-for-cloud-init when i return from my holidays
<Chipaca> pretty please :D
<Chipaca> things i learned while having lunch and looking into mac addresses: osteodiastasis is nasty
<rsalveti> Chipaca: sure :-)
<elopio> good morning.
<rsalveti> elopio: good morning
<longsleep> Another snapcraft question, any ideas if someone tried to do cross snapcraft, eg. create a snap for armhf on amd64?
 * longsleep wonders how multi arch snaps work anyway
<ogra_> longsleep, i guess thats a mterry or ted question
<ogra_> (like all snapcraft questions somehow :) )
<ogra_> both are in US TZ ...
<mterry> longsleep, I'm up
<longsleep> great :D
<ted> longsleep, We're gonna initially target people building an arm snap on arm.
<ted> Which isn't ideal, but that's phase 1.
<mterry> longsleep, plan right now is you build on the target platform.  Future plan is to use comfy to make that much easier
<longsleep> ted: all right, i guess i can do some chroot stuff then
<ogra_> the magical comfy
<longsleep> mterry: i still do not know what comfy is
 * ogra_ adjusts his macros from "snappy will fix everything" to "comfy will fix everythng" :)
<mterry> ogra_, :)
<longsleep> ted, mterry, ogra_ and what about the multi arch. Do i have to build multiple snaps for each arch and somehow can upload them all into the store?
<mterry> longsleep, it's basically "normal Ubuntu embedded in Snappy for developers' benefit"
<ogra_> longsleep, i think thats possible, yup
<longsleep> ok - so the file name of the snap should include the architecture?
<mterry> longsleep, the current only way to do that is embed multiple binaries in one snap (which is gross and tooling isn't great).  Future plan is to allow uploading multiple snaps, one per arch, for one store item.  Or you could upload them as separate store items now
<ogra_> (i personally prefer one snap for all arches, but then you cant use snapcraft atm as i understand)
<longsleep> oh - so i have to put them all into one snap :/ that is unfortunate
<ogra_> no, you dont
<mterry> longsleep, it's a store limitation right now
<sergiusens> ogra_: you flip flopped the preference it seems ;)
<mterry> ogra_, did store grow support for multiple snaps?
<ogra_> sergiusens, after using the model, yes :)
<sergiusens> ogra_: it is easier in some aspects, just not ideal for huge snaps
<ogra_> mterry, hmm, not sure about package namin, but you can surely upload for a specific arch ... would likely have to be $snapname-$arch.snp then though
<ogra_> i know i can upload armhf only or amd64 only for one snap
<ogra_> sergiusens, indeed, size matters :)
<mterry> ogra_, yeah but you have to upload each arch as a separate store item right now
<ogra_> right
<mterry> ogra_, which is gross is all  :(
<longsleep> what does it mean separate store item? Can it use the same name then?
<ogra_> yeah, surely not idea
<ogra_> l
<mterry> longsleep, I'm meaning separate names when I mean separate store item
<mterry> longsleep, store can't handle multiple arch-specific snaps for same name yet
<ogra_> longsleep, myshinysnap-armhf_1.2.3.snap ... and myshinysnap-amd64_1.2.3.snap
<longsleep> yes file names are good, though regarding the store i am unsure
<ogra_> that will be two separate store items with separate metadata pages in the store
<longsleep> is there an example in the store already?
<ogra_> (and two different places to upload to etc)
<longsleep> i think i can be ok with that
<longsleep> but probably will only create armhf then for now
<longsleep> mterry: how do you folks manage that for webdm? Does it have a different name for other archs?
<mterry> longsleep, I don't know...  I don't manage that myself
<mterry> rsalveti, tried old BBB image, still didn't work!  So it's either user error, messed up SD card, or messed up BBB (though all are new...).  I'm going with user error...  Trying my raspberry pi2 just in case
<sergiusens> mterry: after dd'ing make sure records out and in match ;-)
<mterry> sergiusens, interesting...  but looking at scrollback, it seems fine
<Chipaca> longsleep: i like your case, btw :)
<rsalveti> mterry: makes no sense
<rsalveti> guess we can only know for real with a serial console
<rsalveti> like http://elopio.net/en/node/1042
<rsalveti> mterry: is yours also bbb rev c?
<rsalveti> should have a bit C in one of the stickers
<rsalveti> *big
<ogra_> mterry, can we see your serial output during boot ?
<Chipaca> sergiusens: where was it golang-uboot-go-dev was at?
<Chipaca> and how do i add that to a schroot
<sergiusens> Chipaca: in the ppa:snappy-dev/image
<sergiusens> Chipaca: https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs
<Chipaca> yep, just found that
<Chipaca> thanks
<sergiusens> Chipaca: you could add it permanently into a snappy branded schroot as it is the base of our builds anyways
<Chipaca> yep, am doing so :)
<ogra_> longsleep, https://insights.ubuntu.com/2015/07/30/spreedbox-most-private-video-chat-and-file-exchange/
<ogra_> ;)
<mterry> rsalveti, ogra_: sorry was in meeting about this MIT demo.  rsalveti: it is rev C.  ogra_: I've moved on to trying with the raspberry pi2 but can go back and try to get more output later
<rsalveti> ogra_: nice
<rsalveti> same rev we all use, weird
<rsalveti> yeah, but you'd need a serial cable around
<ogra_> well, we should somehow make clear that a serial cable is kind of expected on embedded HW :)
 * ogra_ gives up trying to re-share rsalveti's Win10 post on the phone and does it from the PC 
<ogra_> unbelivabe ... i cant switch back and forth between browser and G+ to actually type one sentence off the website into my post
<longsleep> ogra_: very nice thanks!
<ogra_> either G+ or the browser goes white
 * ogra_ wants 4GB on phones :P
<ogra_> (that will at least allow me two apps at the samer time :P )
<Chipaca> ogra_: unless one of them is a browser ;)
<ogra_> yeah, then you need 8GB
<longsleep> is there any phone which actually can use more than 3GB ?
<longsleep> i read somewhere that the oneplus 2 should have 4GB
<sergiusens> ogra_: yeah, I have this problem when attaching a photo through the content hub as well, the app that requested the content hub ceases to exist on return :P
<ogra_> i dont think there are actual 64bit phones ...
<ogra_> the 64bit ones i know all run in a 32bit compatibility mode
<ogra_> which would limit your to 3G
<sergiusens> ogra_: mem management is atrocious on the phone lately
<sergiusens> ogra_: I don't use g+ on it anymore, too depressing
<ogra_> sergiusens, well, i see people complaining about that photo thing all the time ... works for me ... but then i only use G+ to share stuff
<ogra_> (and very rarely telegram)
<sergiusens> ogra_: right, my use case is untappd (take photo and return to nothing)
<ogra_> (and indeed i use my G+ app, not that official canonical thing :) )
<sergiusens> ogra_: now I take the photo just in case I lose it ;-)
<sergiusens> and then open the hub
<ogra_> ah, so you share from the camera app
<ogra_> i always pick gallery (and make sure the camera is closed when i do)
<ogra_> seems thats less memory hungry
<sergiusens> ogra_: oh, good point
<mterry> ogra_, rsalveti: now...  with pi2, my first ssh attempt is reset by peer and the second hangs.  :-/  but that's further than bbb...
<ogra_> mterry, and you dont have a serail cable ?
<mterry> ogra_, no, I'm connecting over local network (ethernet on pi2 and wifi on laptop)
<ogra_> ah, well, that wont give us many meaningful infos ...
<ogra_> try pulling the syslog off the writable partition (but i guess thats to late to catch boot inssies)
<mterry> ogra_, but might help for pi2... i could get openssh logs
<ogra_> well, you can just pull the log from the SD directly
<mterry> ogra_, that's what I meant, get the openssh logs from the SD
<mterry> since I can't ssh in
<ogra_> well, syslog would be more interesting ... the only "ssh log" we have is auth.log
<ogra_> (and that usually hasnt mugh meaningful to debug anything beyond login issues)
<ogra_> *much
<mterry> ogra_, http://paste.ubuntu.com/11967112/
<ogra_> mterry,  looks like cloud-init didnt generate the keys properly
<mterry> ogra_, is something like a "USB to Serial adapter" what I want?
<ogra_> one sec
<ogra_> http://www.amazon.de/SainSmart-Serial-Debug-Console-Raspberry/dp/B00KVUSI30/ref=sr_1_1?ie=UTF8&qid=1417690697&sr=8-1&keywords=FTDI+Cable+3.3
<ogra_> that is what i got here
<ogra_> you want one with the flying cablÃ¶es at one end so you can use it on boards that have different order
<ogra_> (instead of a fixed 4-prong thinie)
<mterry> ogra_, haha, little tentacle cables.  OK
<ogra_> yeah :D
<mterry> ogra_, will search for one at my local store
<fgimenez> Chipaca, can you give me a hand with a failing service test?
<Chipaca> sure
<fgimenez> Chipaca, not sure if fails the service or the test :)
<fgimenez> Chipaca, here's the error http://10.55.61.165:8080/job/snappy-integration-tests-canonistack-1504-edge/35/console
<fgimenez> Chipaca, you can search for FAIL:
<fgimenez> and here's the test's code http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/installFramework_test.go
<fgimenez> Chipaca, it fails eventually, usually all is fine
<Chipaca> fgimenez: could you pastebin console? i don't have my vpn setup working for some reason
<fgimenez> Chipaca, sure http://paste.ubuntu.com/11967413/
<Chipaca> fgimenez: can you get more logs than that? it looks like your app is panic'ing
<fgimenez> Chipaca, yes, that's because this failed assert http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/_integration-tests/tests/installFramework_test.go#L86
<fgimenez> Chipaca, the problem is the output of "systemctl status docker_docker-daemon_1.6.1.002.service"
<Chipaca> fgimenez: is this with snappy trunk?
<fgimenez> it expects to find the service active
<fgimenez> Chipaca, yes
<fgimenez> Chipaca, the test usually passes but 10% of the time fails
<Chipaca> fgimenez: is network up on the kvm?
<Chipaca> fgimenez: is this recent?
<Chipaca> fgimenez: wrt "network up", i'm asking if there is a default route, fwiw
<fgimenez> Chipaca, the network is up, it is being tested against a 15.04 image, and the code has been there for some time
<Chipaca> fgimenez: i mean, are the failures recent
<Chipaca> but if it's 15.04 then it's not what i thought it might be
<fgimenez> Chipaca, not afaic, we are checking if the service is up after a reboot, maybe we are asking for it too soon?
<Chipaca> fgimenez: give me a sec
<Chipaca> systemctl show -p ActiveState network-online.target
<Chipaca> fgimenez: delay the check until that^
<Chipaca> fgimenez: returns "ActiveState=active"
<Chipaca> fgimenez: and let me know how it goes
<Chipaca> (even better if you wait a bit *after* it got to "active")
<Chipaca> fgimenez: if you need to cap it, that should not be more than say 3 minutes after boot
<fgimenez> Chipaca, ah! ok that makes sense, i'll try that thanks a lot! :)
<Chipaca> as even in the worst case the network-online thing will only wait 2 minutes, as things stand
<Chipaca> fgimenez: also
<Chipaca> fgimenez: this check might be overkill right now (maybe with a sleep you'll have enough)
<fgimenez> Chipaca, yes, i was going to ask you about that
<Chipaca> fgimenez: but there'll be code in 15.04 soon that will break if you don't wait for this, so you might as well do it now
<Chipaca> fgimenez: but, your choice, really
<fgimenez> Chipaca, ok i'll go for checking the state, thanks!
<ogra_> rsalveti, hmmm ... i was just looking closer at mterry's log ....
<ogra_> Feb 16 20:55:26 localhost systemd[1]: Starting Initial cloud-init job (metadata service crawler)...
<ogra_> Jul 30 14:41:40 localhost systemd[1]: Time has been changed
<ogra_> Jul 30 14:41:42 localhost cloud-init[722]: Cloud-init v. 0.7.7 running 'init' at Mon, 16 Feb 2015 20:55:35 +0000. Up 51.59 seconds.
<rsalveti> right
<ogra_> seems the time gets updated in the middle of cloud-init runnign
<rsalveti> that is indeed interesting
<ogra_> and cloud-init still keeps the old time cached somehow
<ogra_> it is also weird that the last mount time doesnt seem to have been updated between the two boots ... they both start at feb 16th
<ogra_> rsalveti, hmm, did you do a vivid build tonight ?
 * ogra_ just notices an arm64 build failure mail from 7am this morning for a vivid build
<ogra_> i wonder if someone played with the crontab commants on nusakan
<ogra_> *comments
<admcleod1> so.... any ideas why i cant create more than 50 veth's with docker in snappy on an rpi2? :}
<ogra_> kirkland, any idea ? ^^
<ogra_> (or any idea whom to point admcleod1 to ? )
<longsleep> is there a way to directly use git with launchpad?
<ogra_> longsleep, yeah, i think so ... ask in #launchpad though
 * ogra_ still uses bzr if he can choose :) 
<longsleep> right, i want to add a simplified plugin to snapcraft which can directly use a .deb file
<mterry> ogra_, rsalveti: ok, back from a long trek to find serial cables and lunch.  Everywhere is out of them, so I ordered an overnight amazon cable
 * mterry will try again on current devices / work on other aspects of presentation
<ogra_> mterry, yeah, lets look tomorrow then ... but see above, there is something going on with the clock and last mount time it seems
<mterry> ogra_, huh, I don't know what to do with that information...  :)  but interesting clue
<mterry> ogra_, does ethernet need to be plugged in at boot for it to work?
<ogra_> mterry, nothing ... lets inspect it deeper tomorrow :)
<mterry> maybe I can plug it in later to avoid updating time in middle of boot
<ogra_> well, therenet is needed by cloudinit i think
<ogra_> *ethernet
<ogra_> the thing is, cloud-init generates your ssh keys ... i'm not sure what actually happens if the clock gets changed in the middle of generating them
<ogra_> (i'm also not sure why your last mount time (which is what fixrtc sets the system time to if there is no rtc) is feb 16th ... that kind of predates the released image)
<mterry> ogra_, I hate hardware.  Why can't everything just be ethereal bits?
<ogra_> haha
<ted> Man, I looked and look at what I did wrong. Turns out just needed to fix the expected result of the test, it changed.
<mterry> ogra_, rsalveti: my third rewritten sd card worked for pi2....
<mterry> I don't get it, but I'm not asking questions
<rsalveti> mterry: weeeird
<rsalveti> ogra_: I enabled the cronjob for 15.04/edge again
<rsalveti> since the release is out
<mterry> rsalveti, not confidence inspiring for sure
<rsalveti> do you have any external usb-sd card reader?
<sergiusens> mterry: maybe get a new sdcard?
<rsalveti> or that
<mterry> ogra_, people have used this webcam-demo.canonical app and it works and all that?  I'm getting "GD Error: gd-jpeg: JPEG library reports unrecoverable error: Not a JPEG file: starts with 0x26 0x81" -- trying to figure out if it is the snap or something else
<ogra_> rsalveti, what for ? the archive wont change, dailies dont really make sense for 15.04
<rsalveti> ogra_: does change, -updates and -security
<ogra_> well, true indeed
<rsalveti> I think federico tested the webcam demo with latest release, maybe elopio gave that a try as well
<elopio> I haven't tried that one for a month, at least.
 * ogra_ knows that asac tested it too not to far ago
<ogra_> but probably before QA did
<mterry> OK...  what's the best way to run a native go arm executable?  We have golang-go for armhf.  But running under qemu dies (known bug).  Is there anything like comfy that I can fake to get an armhf deb-based system running on my board?  using docker and installing a cloud image in that?
<rsalveti> yeah, docker and an ubuntu image
<rsalveti> ted probably got something
<rsalveti> since he's working at the comfy idea
<mterry> rsalveti, I'm having a hard time finding an armhf image that isn't our "cloud" image.  Is that fine?  ubuntu-server and ubuntu-desktop don't seem to publish normal everyday armhf images
<rsalveti> it should be fine
 * mterry has never used cloud before, but assumes it's close to server
<ted> Yeah, I think there's another image that people seem to be using, but not an official one.
<ted> Let me find it.
 * ted is curious why we don't seem to have an official one.
<mterry> rsalveti, I realized that our current Go plugin in snapcraft is amd64-only and expanding it to armhf is easy, but hard to actually test.  :)  Most of our fun examples for snappy involve Go
<rsalveti> yeah :-)
<rsalveti> and why ted is fixing that issue for us :-)
<mterry> Three cheers for ted!  :)
<ted> Heh
<ted> mterry, https://registry.hub.docker.com/u/armbuild/ubuntu/
<mterry> ted, I don't like downloading things from non-ubuntu.com sites  :)  feels dirty
<ted> mterry, It is, but make sure to not put important stuff on that device :-)
 * mterry scp's private gpg keys
 * mterry needs to probably update my gpg key to something new....  I haven't done that in 15 years
<mterry> I'm probably using md5 as the core key mechanism
<ted> Yeah, I updated mine a while ago for that reason. I choose a really big number for the new key.
<ted> I'm sure that makes it perfect for another 20 years.
<mwhudson> hey can i trick someone into looking at https://bugs.launchpad.net/snappy/+bug/1478736
<ubottu> Launchpad bug 1478736 in Snappy "tests fail with 1.5 tip" [Undecided,New]
<rsalveti> elopio: Chipaca: ^
<elopio> mwhudson: that's definitely not happening on trusty, because that's what our tarmac runs.
<mwhudson> elopio: no it's definitely not
<elopio> and it's not happening for me on vivid, probably not either on wily because that's what federico uses.
<mwhudson> elopio: context https://wiki.ubuntu.com/MichaelHudsonDoyle/Go15Preparation#preview
<elopio> mwhudson: please give us as many information about your environment as possible. I'll try to reproduce it when I return.
 * mwhudson edits bug summary
<elopio> oh, I see.
<elopio> mwhudson: I need a couple of hours in the scary outside world. I'll reply to the bug when I come back.
<mwhudson> :-)
<mwhudson> thanks
#snappy 2015-07-31
<pilil__> good morning.
<pilil__> I have a question about system wrappers. After installation all apps and services should be started only through wrappers, but when one wrapper trying to launch another wrapper I receive errors like this:
<pilil__> $sudo /usr/bin/ubuntu-core-launcher myapp myapp_service_0.0.1 /apps/myapp/0.0.1/bin/myapp-wrapper
<pilil__> ubuntu-core-launcher: error while loading shared libraries: cannot apply additional memory protection after relocation: Permission denied
<pilil__> even with frameworks
<pilil__> without ubuntu-core-launcher - everything ok
<pilil__> Is there proper way to launch one file from another?
<dholbach> good morning
<fgimenez> good morning
<elopio> fgimenez: crazy day here today, but all your branches are +1-ed. Sorry for the delay.
<fgimenez> elopio, hey, np thanks :)
<fgimenez> elopio, i'll apply your suggestion to the config testbed one, i like the boolean value option
<elopio> fgimenez: as you prefer. The change would be pretty simple, so if it passes for you also feel free to top-approve.
<elopio> I'm leaving now. See you soon.
<fgimenez> elopio, ok see you
<ogra_> pilil, this sounds like a question for the security team, either wait til the US gets up or write a mail to the mailing list
<longsleep> Moin folks, so is there a place where i can add feature requests for snapcraft?
<ogra_> file a whishlist bug
<ogra_> und moin :)
<longsleep> whishlist bug ok - let me try that
<longsleep> haha bug #50788
<nothal> Bug #50788: We don't need "Wishlist"  <http://launchpad.net/bugs/50788>
<ubottu> bug 50788 in Launchpad itself "We don't need "Wishlist"" [Undecided,Invalid] https://launchpad.net/bugs/50788
<ogra_> lol
<ogra_> reported 2006-06-23 :)
<longsleep> yeah
<longsleep> and marked invalid
<longsleep> just was the first hit
<ogra_> man, these names bring back memories :)
<pilil> ogra_, who should I ask it from security team?
<ogra_> pilil, try jdstrand or tyhicks (i'm not sure who exactly could help here)
<pilil> ogra_, I got it, thanks
<pilil> ogra_, there is another question. How can we add new extrauser to Snappy, cause tools like passwd or useradd still works with /etc/passwd instead of /var/lib/extrausers?
<ogra_> pilil, i think that is fixed in the rolling release, it is quite a change so it was not backported afaik
<longsleep> ogra_: bug #1480144 added, i tagged it with wishlist, not sure if that is the correct way
<nothal> Bug #1480144: Snapcraft should be able to run in clean environment with pbuilder/cowbuilder <Snappy:New> <http://launchpad.net/bugs/1480144>
<ubottu> bug 1480144 in Snappy "Snapcraft should be able to run in clean environment with pbuilder/cowbuilder" [Undecided,New] https://launchpad.net/bugs/1480144
<pilil> ogra_, thanks
<ogra_> longsleep, i know cross building is planned, but it will likely still take a bit before it happens
<ogra_> (not on top of the list)
<tasdomas> hi
<tasdomas> why does the raspberry pi2 snappy image contain an .ssh/authorized_keys entry for ogra@anubis?
<ogra_> tsthats a fake key ... ubuntu-device-flash needs a valid key if you enable --develper-mode during build
<ogra_> tasdomas, ^^^
<ogra_> tasdomas, i hope to finish a new image today and will make that clearer (calling it dummy@dummy or some such) in that build
<longsleep> ogra_: yeah - in the meantime i might just create a small tool "debsto
<longsleep> err
<longsleep> ogra_: debs2snap or something
<ogra_> haha
<longsleep> that way i can just use the existing gear plus one extra step
<biezpal> ogra_, question about systemd and snaps. In the package.yaml we can specify the type of service (dbus or not), is there a plans to implement other types of services, like forking or other?
<ogra_> biezpal, hmm, not sure what you mean by type of service ... do you mean the bus-name filed for framework snaps ?
<ogra_> https://developer.ubuntu.com/en/snappy/guides/package-metadata/
<JamesTait> Good morning all; happy Friday, and happy System Administrator Appreciation Day! ð
<ogra_> wasnt that yesterday ?
<ogra_> oh, wasn't :P
<biezpal> ogra_, I'm talking about systemd service unit Type
<biezpal> [Unit]
<biezpal> Description=swamp services management service
<biezpal> After=syslog.target
<biezpal> [Service]
<ogra_> hmm, then i dont see the relation to package.yaml here
<biezpal> Type=forking
<biezpal> we want to specify type of service described in package.yaml
<ogra_> but package.yaml doesnt offer that (at least currently)
<biezpal> we can describe service from package.yaml, but not the type of it?
<ogra_> you can put into the description what you want ... but there is no "type" field or anything that would do anything meaningful with it
<ogra_> (see the linked documentation above)
<biezpal> forked service is being killed by systemd because systemd is thinking that process is stopped
<biezpal> now, to get rid of it we are manually edit systemd unit and specify Type = forking
<ogra_> righ
<ogra_> t
<ogra_> and where does the package.yaml come into play here ? thats the bit i dont understand
<biezpal> we want Type of service to be taken from package.yaml
<ogra_> oh, so this is a feature request ?
<biezpal> it's just a question to find the way
<ogra_> (to extend package.yamnl ?)
<biezpal> to build unit automatically with additional options
<c-lob> sorry if I stick my nose in this discussion, but isn't it possible to pack the .service file into the snap?
<ogra_> right, that doesnt sound like something supported yet ... i'd start a thread on the mailing list
<ogra_> c-lob, indeed you can do that
<biezpal> c-lob, where we can read about that option?
<c-lob> biezpal, well I'm just thinking about now :)
<c-lob> biezpal, well I'm just thinking about it now :)
<biezpal> lol
<biezpal> ogra_, maybe you know?)
 * ogra_ takes a look at webdm
<ogra_> hmm, so i dont see a way, it uses the generated unit too (which fires up a script that cares for all teh rest). i guess you should try starting a thread on the ML
<ogra_> (there is probably no way to change the type of the unit, but surely a way to achieve what you wanted to do with setting it via some other mechanism)
<vmayoral> ppisati: just e-mailed you, i'm experiencing some issues with the compiled kernels when booting with the Snappy FS, apparently the "system-boot" partition fails to get mounted. Would be great getting your input here
<ppisati> vmayoral: i'm looking
<vmayoral> ppisati: thanks
<ppisati> mount: wrong fs type, bad o
<ppisati> missing codepage or helper
<ppisati> vmayoral: can you complete a boot?
<vmayoral> ppisati: i get into emergency mode https://gist.github.com/vmayoral/fc2c7ebbd679ea7d9a9b
<ppisati> vmayoral: do you see something in dmesg?
<ppisati> vmayoral: let me check the config
<vmayoral> ppisati: nothing relevant that i can identify https://gist.github.com/vmayoral/193f5c1e71f5cfb9bd67
<ppisati> FAT-fs (mmcblk0p1): IO charset iso8859-1 not found
<ppisati> that config is missing the option
<ppisati> two things:
<ppisati> 1) did you check that the resulting config are the same?
<ppisati> 2) you are using an old version #18 while we are at...
<ppisati> 23?
<ppisati> something like that
<ppisati> let me take a closer look at that tree
<ppisati> ah
<ppisati> ok
<ppisati> to compile that tree and get a debian package, you have to do this:
<ppisati> export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati> fdr clean; debian/rules build; fdr binary-generic
<ppisati> the config is store in:
<ppisati> *stored
<ppisati> master/debian.master/config
<ppisati> split among
<ppisati> config.common.ubuntu
<ppisati> and the other snippets in debian.master/config/armhf*
<ppisati> if you did as i read in the REAME.md of that git tree:
<ppisati> ARCH=arm ./scripts/kconfig/merge_config.sh arch/arm/configs/omap2plus_defconfig arch/arm/configs/snappy/*.config
<ppisati> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage dtbs -j4
<ppisati> you are missing some options
<ppisati> so, it's up to you
<vmayoral> i see
<vmayoral> regarding the kernel
<ppisati> either you add that charset in your config
<vmayoral> i fetched it from http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/ a few days ago
<vmayoral> will rebase it now to get up to date
<ppisati> i think your config is quite good
<ppisati> the way you build the kernel is correct
<ppisati> it is how it's done when you are developing
<ppisati> it's faster
<ppisati> it easier if you just made a change and you want to test it
<ppisati> etc
<ppisati> but if you want exactly our kernel packages
<ppisati> you should follow the 'fdr *' instructions up here
<ppisati> where fdr is an alias for
<ppisati> 'fakeroot debian/rules'
<ppisati> just in case
<vmayoral> thanks a lot for explaining, is this documented somewhere?
<ppisati> vmayoral: yep
<ppisati> vmayoral: hold on
<ppisati> https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile
<ppisati> ok, this is a bit old
<ppisati> since it covers the omap4 kernel
<ppisati> and back then i was suggesting:
<ppisati> export $(dpkg-architecture -aarmhf); export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati> fakeroot debian/rules clean
<ppisati> fakeroot debian/rules binary-omap4
<ppisati> but the stuff that i pasted here is faster
<ppisati> and works for generic
<ppisati> (instead of binary-omap4 you use binary-generic)
<ppisati> and it tells you how to change the config too
<ppisati> fakeroot debian/rules editconfigs
<ppisati> in your case it's the generic flavour that you are interested
<vmayoral> great, I'll go ahead and reproduce it all. If it adds some value, I'll be happy to document it  and maybe this way i can contribute.
<vmayoral> ppisati: thanks a lot for your time.
<biezpal> ogra_, thanks for answer
<vmayoral> ppisati: it'll be great if you guys could also consider including the PRU patches in the vivid tree. Many BBB users make use of these units on the SOC.
<vmayoral> also, ppisati, what's you opinion on changing the kernel released on snappy images to be preemptible (pretty match activating the PREEMPT option)?. IOT devices could make good use of this kind of kernels
<ppisati> vmayoral: ATM the BBB is the same kernel that we use across all ubuntu armhf devices
<vmayoral> current OEM snap allows to change the kernel (i believe) so that should be manageable
<ppisati> vmayoral: but we are having a discussion about it, where to take it, the direction we want to give it, etc
<ppisati> right
<ppisati> vmayoral: question - i now that you use the PRUs for the sensors on your drone, right?
<vmayoral> ppisati: great hearing that. I don't mind compiling the kernels with PREEMPT or PREEMPT_RT options but it'll be great for many avoiding this and going straight into the official images
<vmayoral> ppisati: yes, we use it for fast PWM generation and PPM signal processing
<ppisati> vmayoral: ok
<vmayoral> but there's a lot happening in the PRU world
<ppisati> vmayoral: so, you load a binary into PRUs, right?
<vmayoral> yes, every year, there're GSOC project that build on top
<ppisati> vmayoral: did you try to "port" your code to the remoteproc facility?
<vmayoral> no we have not. What i'm most concerned about is the maintainability if we were to do so.
<vmayoral> Current Dronecode Foundation helps a lot with that
<vmayoral> if we were to move to the PRUs...
<ppisati> vmayoral: what you mean?
<vmayoral> i mean that there's an existing community supporting the code based on a single (or multiple) core symmetric processors based on userspace drivers. If we were to port a  part of the code to an assymetric arch. (e.g. the PRUs) we would loose the community support
<vmayoral> with our current size and dev. force we can't afford it
<vmayoral> nevertheless, i'm seeing how the PRU-world grows every year and there's even people bit-banging protocols on them
<ppisati> vmayoral: ok, sorry i'm confused now
<ppisati> vmayoral: i asked you if you were using the PRU and you told that you were using it
<ppisati> 12:06 < vmayoral> ppisati: yes, we use it for fast PWM generation and PPM signal processing
<vmayoral> yes, we are
<vmayoral> for PWM and PPM generation/processing
<ppisati> ok
<vmayoral> probably i misunderstood it at some point.
<ppisati> vmayoral: so, there's are two ways to interact with the hw PRUs AFAIK
<ppisati> vmayoral: the PRU patches that you applied
<ppisati> vmayoral: unsupported by TI
<ppisati> vmayoral: of their supported mechanism, the remoteproc
<ppisati> *or
<ppisati> since you applied thse patches to your kernel, i assume you are using the userspace driver
<ppisati> and i was wondering if you have ever tried/considered to move it to remoteproc
<ppisati> that's beause, part of the TI BSP kernel requires the remoteproc facility for some of its features
<ppisati> e.g. the power management code has a requirement on it
<vmayoral> i see, i don't have much understanding about how remoteproc works but i was assuming that any interaction with the PRUs was done through the remoteproc framework.
<vmayoral> the patches came originally from a tree maintained by Robert Nelson who is working tightly with TI and BeagleBoard https://github.com/RobertCNelson/bb-kernel/tree/am33x-rt-v4.1/patches/pru
<vmayoral> (AFAIK)
<longsleep> is there a way to launch a shell in the environment of a snap?
<longsleep> my snap fails to start, and the systemd log is not very helpful
<ogra_> i had a nodejs based terminal once, running the shell inside teh snap env,  but the snap isnt functional currently
<ogra_> i think there was another one in the examples or some such, but i cant remember exactly
<longsleep> well i guess i could just set the environment variables manually
<ogra_> do you have a start script ?
<ogra_> you could just make it print the env to some logfile
<longsleep> yes
<longsleep> aha
<longsleep> the error is cp: cannot create regular file â/server.confâ: Read-only file system
<ogra_> looks like an unset variable
<ogra_> SNAP_APP_PATH ?
<ogra_> or SNAP_APP_DATA_PATH
<longsleep> yes CONF=$SNAP_APP_DATA_PATH/server.conf
<ogra_> weird, that should definitely be set
<longsleep> yes it is not set when i run it manually
<longsleep> for testing
<longsleep> found the error now
<ogra_> heh, indeed not
<longsleep> sed: -e expression #1, char 88: unterminated `s' command
<longsleep> narf
<ogra_> heh
<longsleep> but it would be really helpful if one would see these errors in systemd
<ogra_> +1
<ogra_> they used to show up when we used journald ... not sure why they dont end up in syslog now
<longsleep> mhm let me check syslog, i was using systemctl
<ogra_> ah
<longsleep> ogra_: you are right, it is in syslog
<longsleep> Jul 31 11:04:22 odroid ubuntu-core-launcher[1327]: sed: -e expression #1, char 88: unterminated `s' command
<longsleep> thats good enough i think
<ogra_> ah, cool
<Chipaca> longsleep: should also be in journalctl
<ogra_> Chipaca, do you knwo why we use both ?
<Chipaca> but i admit to not being proficient in journalctl usage
<ogra_> smells bloated
<Chipaca> ogra_: because that's how we roll? :-p
<Chipaca> ogra_: i think we want to drop syslogd, but had to bring it back for <something>
<Chipaca> happened before i got on board
<ogra_> ah
<Chipaca> ogra_: but aiui it's wanted to go away
<ogra_> ok
<Chipaca> that is, we want to drop syslogd, but something or other depends on it still
 * ogra_ doesnt care which one goes away, i just dont like the duplication :)
<Chipaca> and it's bloated but not super critical
<ogra_> yeah
<ogra_> hmm
<ogra_> on my BBB snappy list -v shows ubuntu-core 9 active ... webdm only shows 8
<longsleep> mhm now i get Jul 31 11:12:02 odroid ubuntu-core-launcher[1734]: Bad system call when running sed :/
<longsleep> time for lunch
<Chipaca> longsleep: ooh! check syslog again, in particular for seccomp or apparmor issues
<Chipaca> longsleep: bad system call is probably seccomp
<Chipaca> longsleep: sc-logresolve should help you if that's the case
<Chipaca> longsleep: super interested in what you find
<Chipaca> but alas, lunch calls
<longsleep> Chipaca: yeah i will investigate now - i just returned from lunch and finishing up my ice cream :P
<ogra_> yummy
 * Chipaca having a big cool fizzy drink instead
<Chipaca> (no it's not beer, shaddup)
 * ogra_ slurps a hot espresso :) 
<ogra_> you and your frozen stuff
<longsleep> Chipaca: so, this is all in syslog: http://paste.ubuntu.com/11973062/
<longsleep> Chipaca: and my start script is this (for testing) http://paste.ubuntu.com/11973068/
<jjohansen> sergiusens, ogra_: how do you build a base image with a custom kernel using ubuntu-device-flash?
<ogra_> you need your own device tarball
<ogra_> jjohansen, this is the script i use to create the rpi device tarball from ppisati's PPA builds http://paste.ubuntu.com/11973145/
<jdstrand> ogra_: how much of that applies to generating something for generic-amd64?
<ogra_> well, the format is the same in both
<ogra_> the paths might differ though
<ogra_> (since x86 doesnt use uboot indeed)
<c-lob> longsleep, I saw that calling the binary directly from its folder (like /apps/appname/ver/binary) give more information than "bad system call"
<jdstrand> I saw dtb too
<longsleep> c-lob: all right
<ogra_> jdstrand, jjohansen, you can ignore the System.-map, config and dtb stuff though
<longsleep> c-lob, Chipaca : I narrowed it down to  the -i parameter in sed. sed works just fine without -i
<Chipaca> oops, missed your syslog
<Chipaca> sorry was pulled into a different thing
 * Chipaca reads now
<longsleep> Chipaca: yeah there is not much in syslog
<longsleep> c-lob: no further details with callling /bin/sed instead just sed
<Chipaca> longsleep: and sed -i works outside of a script?
<longsleep> Chipaca: when i run it as root yes
<longsleep> let me try again
<Chipaca> jdstrand: an idea what can cause a silent "bad system call" with nothing in syslog, when running something as root under seccomp, but not when running as root wihtout it?
<pilil> jdstrand, can you help me with question about system wrappers? After installation all apps and services should be started only through wrappers, but when one wrapper trying to launch another wrapper I receive errors like this:
<longsleep> Chipaca: yes confirmed, sed -i works fine as root
<pilil> $sudo /usr/bin/ubuntu-core-launcher myapp myapp_service_0.0.1 /apps/myapp/0.0.1/bin/myapp-wrapper
<pilil> ubuntu-core-launcher: error while loading shared libraries: cannot apply additional memory protection after relocation: Permission denied
<pilil> even with frameworks, without ubuntu-core-launcher - everything ok. Is there proper way to launch one file from another?
<Chipaca> pilil: i don't think you should call one wrapped thing from another
<Chipaca> inside the same app, call your things directly
<Chipaca> outside the same app yes
<jdstrand> pilil: Chipaca is right. if it is in your own snap, just use $SNAP_APP_PATH/path/to/your/thing
<Chipaca> *gasp*
 * Chipaca takes a snapshot and frames it
<pilil> Chipaca, if I have framework LXC, how could i run commands like lxc-ls from my app?
<jdstrand> Chipaca: it was bound to happen sometime
<jdstrand> </rimshot>
 * jdstrand hugs Chipaca :)
<jdstrand> pilil: the framework has to expose that via its framework policy
<Chipaca> :)
<jdstrand> pilil: so install the framework, then you can do 'snappy-security list'
<jdstrand> pilil: then have your snap depends on the framework and use either the security-template or caps (for policy groups), or both in your yaml for the service/binary
<jdstrand> Chipaca: yeah, that is one strange error
<pilil> jdstrand, even if policy set up to unconfined, we have this error. Or there are some other policy?
<jdstrand> Chipaca: (Bad system call). that isn't a seccomp denial
<jdstrand> pilil: if the policy is unconfined, don't use a wrapper, just go into the install directory of the the you want to execute
<jdstrand> pilil: /apps/foo/current/path/to/binary
<Chipaca> longsleep: do you still get it if you set your policy to unconfined?
<jdstrand> Chipaca: that feels like the launcher was compiled on one system that had that system and run on another that didn't
<longsleep> Chipaca: how would i do that? Didnt investigate on policies yet
<pilil> jdstrand, yes, now we deal with this way, but its look insecure, and we are researching how to improve security
<jdstrand> s/that system/that system call/
<longsleep> Chipaca: i have caps: networking and network-service
<jdstrand> pilil: well, you are running unconfined so... :)
<jdstrand> pilil: when you go confined, use the framework policy method I described
<pilil> it was just first run, we have plans to use profiles :)
<longsleep> Chipaca: from my syslog, does it not already run with unconfined?
<longsleep> Chipaca: operation="profile_replace" profile="unconfined"
<jdstrand> pilil: a framework will express what it is safe to do via its framework-policy
<pilil> jdstrand, thanks, now I need addition research about it
<Chipaca> longsleep: no, I don't think that's your app there
<jdstrand> pilil: fyi, https://developer.ubuntu.com/en/snappy/guides/frameworks/ and https://developer.ubuntu.com/en/snappy/guides/security-policy/
<longsleep> Chipaca: its not - but it has name="spreed-webrtc.sideload_spreed-webrtc_0.0.1" pid=1718 in the line?
<pilil> jdstrand, yeah, already there, thanks
<Chipaca> longsleep: yes; I don't know what that means (jd.strand would know), but i do know that unless you're specifying unconfined in your package.yaml, it'll be confined
<jjohansen> ogra_: I am afraid I am missing some context to get that scipt to work for me. I assume you have mounted the image and are in its root?
<longsleep> Chipaca: so i just add security-template: unconfined ?
<ogra_> jjohansen, no
<ogra_> jjohansen, i create a device tarball fs structure and tar that up after putting the files in place
<ogra_> jjohansen, then you use it with ubuntu-device-flash to create an image (with the --device-tarball option pointing to it)
<jdstrand> longsleep: yes
<longsleep> Chipaca, jdstrand: When running unconfined it just works
<jdstrand> longsleep, Chipaca: the STATUS line is just telling you that the profile was reloaded into the kernel
<Chipaca> ta :)
<Chipaca> i knew it was an irreal elephant, but not exactly why
<longsleep> so, but this cannot be the solution right?
<Chipaca> nope
<longsleep> i mean we do want to run things confined
<Chipaca> jdstrand: is there an easy way for longsleep to run the service confined, but via strace?
<longsleep> well there is no strace in my snappy
<Chipaca> longsleep: you can copy strace-the-binary from ubuntu and it'll work
<longsleep> Right, assuming i find an armhf one somewhere - let me look
<Chipaca> heh
<Chipaca> you don't have an armhf notebook?
<Chipaca> ;-p
<Chipaca> longsleep: i can put one up for you, give me a bit
<Chipaca> longsleep: you based on 15.04?
<jdstrand> Chipaca: look at the line in the systemd service file for the launcher and do 'sudo strace -o /tmp/strace.out -f ubuntu-core-launcher ...'
<jjohansen> ogra_: device-tarball is only available for touch, I am trying to do core?
<Chipaca> jdstrand: or edit the start script similarly :)
<Chipaca> good one
<jjohansen> ogra_: can I just use touch instead of core?
<Chipaca> not the start script, the systemd file
<jdstrand> Chipaca: well, the start script will run strace under confinement. the way I described strace will be out of confinement
<Chipaca> jdstrand: yep yep
<jdstrand> both can be useful
<longsleep> Chipaca: yes 15.04
<Chipaca> jdstrand: last i tried, strace wouldn't play well seccomp
<jdstrand> so, the service probably needs to have the cd to the WorkingDirectory and the env setup to what is in Environment
<jjohansen> Chipaca: strace should work with seccomp, if seccomp allows ptrace
<jdstrand> Chipaca: yeah, to run strace under confinement the security policy would have to be modifed, which took us out of 'an easy way' :)
<jdstrand> Chipaca: I mean, I could get you there... :)
<Chipaca> jjohansen: jdstrand: after my holidays, i'll try strace under seccomp
<longsleep> Chipaca: ok i got strace, hold on a sec
 * Chipaca makes a note
<ogra_> jjohansen, sorry, --device-part= for core ... not -tarball
<Chipaca> longsleep: ah, ok :)
 * Chipaca had just found it
<Chipaca> http://people.canonical.com/~john/strace_4.8.1ubuntu5_15.04_armhf fwiw
<Chipaca> longsleep: you know what to edit to use that?
<jjohansen> ogra_: what is the best way to mount these images, last touch images I mount were fine, these core images fail
<jdstrand> Chipaca: for your after holidays notes> you can just drop syscalls into /var/lib/snappy/seccomp/profiles/foo. I have a feeling you'll need something for apparmor too (a simple '/path/to/strace' ixr,' and 'ptrace,' in /var/lib/apparmor/profiles/...  would probably get you very close)
<sergiusens> jjohansen: https://github.com/longsleep/snappy-odroidc#build-snappy-image-for-odroid-c1
<sergiusens> jjohansen: kpartx -avs img.img; mount ...; umount ...; kpartx -ds img.img
<jjohansen> sergiusens: hrmm okay, maybe I have a corrupted image
<longsleep> well .. Jul 31 13:30:10 odroid ubuntu-core-launcher[2762]: /apps/spreed-webrtc.sideload/0.0.1/bin/strace: test_ptrace_setoptions_for_all: unexpected signal 31
<jjohansen> sergiusens: thanks
<longsleep> Chipaca: did i do something wrong or strace does not work
<Chipaca> longsleep: what did you edit?
<sergiusens> jjohansen: parted on the img file might tell yo, but if it's x86, it should have 5 partitions
<longsleep> my start script
<longsleep> Chipaca: so i have a strace line now in the start script for sed
<Chipaca> longsleep: ah. no :) edit your systemd service file
<Chipaca> longsleep: /etc/systemd/system/somethingobvious
<longsleep> ah ok
<Chipaca> longsleep: and may i recommend strace -s 999 -f -o /tmp/mytrace
<Chipaca> and then the launcher
<Chipaca> i.e. strace -s 999 -f -o /tmp/mytrace ubuntu-core-launcher yadda yadda
 * Chipaca notes signal 31 is USR2
<longsleep> Chipaca: all right http://paste.ubuntu.com/11973341/
<longsleep> oh i didnt at the parameters
<longsleep> hold on
<longsleep> Chipaca: and here it comes: http://paste.ubuntu.com/11973352/
<jdstrand> longsleep: can you paste 'sudo grep audit /var/log/syslog'?
<longsleep> sure
<longsleep> jdstrand: http://paste.ubuntu.com/11973370/
<Chipaca> jdstrand: nothing strange there, amirite?
<Chipaca> i think this needs to go to a bug
<Chipaca> i'll see if i can reproduce it, then file it myself
<Chipaca> meanwhile, longsleep, you could do http://pastebin.ubuntu.com/11973383/
<longsleep> Chipaca: yeah it could be related to my kernel as well
<Chipaca> longsleep: avoid an extra exec, and an extra file move :)
<jdstrand> Chipaca: yeah, there is no seccomp denial
<longsleep> Chipaca: yes sure, i can go without -i
<Chipaca> longsleep: you know -i isn't *actually* in place, yes?
<Chipaca> it creates a tmpfile then moves it over
<longsleep> Chipaca: yes - it creates a tmpfile
<Chipaca> so your .new was dupe effort
<longsleep> i see those by the way
<Chipaca> yep, see it in strace too
<jdstrand> ogra_: so, in thinking about it, there is no reason why in an generic-amd64 vm jjohansen can't just remount rw, put the kernel wherever grub is looking for it, remount ro and reboot, right?
<ogra_> jdstrand, yeah
<jdstrand> ok cool :)
<ogra_> i thought he wanted to build an image
<ogra_> sorry, i misunderstood that
<jdstrand> well, that was the question posed to you, but the motivation was to test a debug kernel
<Chipaca> :)
<jdstrand> but now we have all this very interesting information that will just go away once kernel snaps are implemented :)
<ogra_> yeah, for that you can just cp ... but be careful with modules ;)
<ogra_> (initrd side specifically)
<jdstrand> knowing jj, he isn't changing abi for what he is looking at, but note taken
<jdstrand> jjohansen: ^
<jdstrand> jjohansen: I suppose I should be the one to apologize for not thinking of the cp into place sooner :)
<jjohansen> well, uh that would be nicer if it was the same kernel version
<jjohansen> don't ask
<jdstrand> heh, well then yes, take ogra_'s point to heart I guess :)
<ogra_> not sure if/which modules are needed on x86
<ogra_> perhaps it just works, else you need to repack the initrd (try if update-initramfs works)
<jjohansen> it appears too
<jjohansen> so I am in for some manual copying fun
<elopio> hello!
<longsleep> Chipaca: well i hit the next obstacle: openssl rand -hex 32 yields openssl: Operation not permitted
<Chipaca> longsleep: sudo tail -n 100 /var/log/syslog | grep audit ?
<jdstrand> that is certainly an apparmor denial
<longsleep> Chipaca: http://paste.ubuntu.com/11973546/
<Chipaca> DENIED
<longsleep> not sure if that is related
<Chipaca> I always read that in the quake voice
<jdstrand> we don'twe don't allow ixr on the openssl binary. that is arguably a bug. on the one hand, it is in the platform and it is safe security wise to allow. on the other hand, it is in the platform and it adds a potential coupling to a specific ubuntu release (ie, we could update openssl and break people)
<longsleep> mhm net_admin and block_suspend?
<Chipaca> jdstrand: how can updating openssl break people? is the output different release on release?
<jdstrand> Chipaca: we could drop an antiquated cipher
<Chipaca> let's not ship antiquated ciphers in the first place! /s
<longsleep> :D
<longsleep> too late for that
<jdstrand> mind you, I am speaking theoretically from the pov that has been expressed that we should only allow the minimum platform deps
<ogra_> hey ! what about us patina fans !!
<longsleep> in any case, i need a way to create cryptographically secure random strings, private keys and certificates
<jdstrand> longsleep: apps aren't allowed to have net_admin - it is far too powerful (see man capabilities)
<longsleep> jdstrand: that is helpful thanks - so are you saying openssl does require this?
<jdstrand> longsleep: that I am not sure of
<jdstrand> longsleep: it could be a harmless denial, but I don't see a denial for openssl itself. did you use snapcraft or deb2snap to build this snap?
<longsleep> jdstrand: snapcraft
<longsleep> (with my own plugin)
<longsleep> i have caps networking and network-service
<elopio> fgimenez: could you please write the ips to your jenkins and other machines in canonistack, in the trello card.
<elopio> first column.
<jdstrand> longsleep: can you try this: adjust /var/lib/apparmor/profiles/<something obvious> to have 'capability block_suspend,' before the trailing '}', then do: sudo apparmor_parser -r /var/lib/apparmor/profiles/<something obvious> then try again?
<jdstrand> fyi, there is an open kernel bug on bad logic for checking something ipv6 related which triggers a net_admin denial (that should be harmless) that tyhicks is working on. so lets see if just block_suspend is enough
<longsleep> jdstrand: this made no difference, audit now only shows the net_admin deny
<longsleep> jdstrand: http://paste.ubuntu.com/11973602/
<longsleep> (there are no denies in syslog when it runs openssl)
<jdstrand> longsleep: ok, try to add 'net_admin' in the same way
<longsleep> jdstrand: ned_admin DENY is gone, openssl still fails
<fgimenez> elopio: sure
<jdstrand> longsleep: ok, then it is something else. I haven't use snapcraft-- is the binary executable?
<longsleep> jdstrand: why binary? openssl? i am using it from the system
<jdstrand> longsleep: ie, the openssl binary?
<jdstrand> I don't think you are
<jdstrand> cause there is no apparmor policy to allow that
<longsleep> i just run "openssl rand -hex 32"
<jdstrand> I think snapcraft may have shipped a binary in your snap and adjusted your PATH so it seems like you are
<longsleep> works fine as root
<longsleep> err
<jdstrand> find /apps/spreed-webrtc.sideload -name openssl
<longsleep> snapcraft doesnt know about openssl
<longsleep> its not there
<longsleep> jdstrand: http://paste.ubuntu.com/11973632/
<longsleep> jdstrand: so you are saying that i cannot run openssl from my snap because there is no apparmor policy to allow it?
<longsleep> jdstrand: and i should ship openssl in my snap?
<jdstrand> longsleep: hmm, so your snap isn't shipping openssl. this is weird. perhaps the denial is getting rate limited
<jdstrand> longsleep: the current apparmor policy does not allow openssl, no. that is easy to for us to fix, but before doing that I want to understand what is happening
<jdstrand> longsleep: can you add this rule to the apparmor policy in the same manner as above: /usr/bin/openssl ixr,
<jdstrand> longsleep: then try again
<longsleep> sure
<longsleep> jdstrand: that helped sort of
<longsleep> Jul 31 14:37:32 odroid ubuntu-core-launcher[3434]: unable to write 'random state'
<longsleep> Jul 31 14:37:32 odroid ubuntu-core-launcher[3434]: message repeated 2 times: [ unable to write 'random state']
<longsleep> jdstrand: and it did create the random strings just fine now (so that only seems to be a warning)
<jdstrand> longsleep: ok, one last thing. can you remove the net_admin and block_suspend rules, reload the profile and try again?
<jdstrand> longsleep: if that works, we can file a bug
<longsleep> jdstrand: sure
<Rlyeh> Hi
<Rlyeh> Does ownlcoud works correctly on ubuntu-core (4)?
<longsleep> jdstrand: still works with the unable to write 'random state' warning
<Rlyeh> "https://192.168.1.102/owncloud/" returns Not Found!!!
<longsleep> jdstrand: full logs: http://paste.ubuntu.com/11973690/
<jdstrand> longsleep: oh, this is a go program?
<longsleep> jdstrand: yes
<jdstrand> right, so that net_admin comment I made earlier applies to you (ie, harmless denial)
<longsleep> jdstrand: yes - it seems to work just fine
<longsleep> jdstrand: and also the block_suspend DENIED does not seem to have any negative effect
<Rlyeh> Solved! "https://192.168.1.102:443"
<ogra_> :)
<longsleep> jdstrand: the random state file can be specified with export RANDFILE="$SNAP_APP_DATA_PATH/.rnd" - then that error goes away as well
<longsleep> jdstrand: do you want me to file a bug or will you do it yourself?
<longsleep> Chipaca: could you reproduce the 'sed -i' issue?
<jdstrand> longsleep: ok. it seems that kernel rate limiting was in effect and we weren't seeing all the denials. fyi: sudo sysctl -w kernel.printk_ratelimit=0
<jdstrand> longsleep: if you could file a bug that would be great
<longsleep> jdstrand: ok - the bug should be to allow /usr/bin/openssl ixr with the default apparmor profile right?
<longsleep> i am adding key generation, dhparams generation, csr genration and self signing to make sure that works as well with that fix
<jdstrand> longsleep: yes
<jdstrand> cool
<longsleep> should i care about the umask for private keys and stuff or does the confinement handle that?
<Chipaca> longsleep: got half way there, got pulled of to see some FTBFS issue
<Chipaca> related to the gcc5 move
<longsleep> Chipaca, jdstrand If you folks are interested in my final start script: http://paste.ubuntu.com/11973970/ (it works fine when profile allows ixr for openssl.
<Chipaca> ta
<ogra_> hmm
<ogra_> does package.yaml allow globbing for files to be included ?
 * ogra_ needs to unclude the overlay/ subdir for rpi overlay dtb's, i dont want to list each dtb individually 
<ogra_> *include
<Chipaca> longsleep: may i suggest a "sync" after you created the conf?
<longsleep> Chipaca: good idea thanks
<ogra_> Chipaca, is sysnc allowed ?
<Chipaca> we'll find out ;)
<ogra_> heh, true
<Chipaca> (how could it not be!)
 * longsleep checks
<longsleep> nope
<longsleep> 49: /apps/spreed-webrtc.sideload/0.0.1/bin/start: sync: Operation not permitted
<ogra_> yeah, thats what i thought :)
<longsleep> jdstrand: so - adding the issue now, in the meantime is there any way to add a workaround to my snap?
<longsleep> jdstrand: bug 1480366
<ubottu> bug 1480366 in Snappy "/usr/bin/openssl should be allowed in default apparmor profile" [Undecided,New] https://launchpad.net/bugs/1480366
<longsleep> Chipaca: Maybe you can tell if i can somehow provide my own apparmor profile which allows openssl?
<ted> mterry, I find it humorous how we basically did independent clean room implementations of get_arch() and they were basically the same :-)
<mterry> ted, ah nice  :)
<mterry> ted, only so many ways to do it  :)
<Chipaca> longsleep: yes, you can. "webdm" does that, for example.
<Chipaca> AFAIR :)
<Chipaca> longsleep: also the docker snap
<longsleep> Chipaca: great thanks
<fgimenez> have a nice weekend everyone o/
<longsleep> Chipaca: mhm  snapp.go:498: The "integration" key is deprecated, and all uses of "integration" should be rewritten
<longsleep> Chipaca: thats how webdm does it :D
<sergiusens> longsleep: no, webdm does it like this: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/package.yaml
<sergiusens> with security-policy:\napprmor|seccomp entries
<longsleep> oh i was at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/webdm/view/head:/pkg/meta/package.yaml
<longsleep> thats probably wrong then
 * sergiusens adds note to delete snappy-hub's webdm
<longsleep> sergiusens: thanks for the hint
<sergiusens> np
<sergiusens> bbs
<longsleep> well i just read that custom apparmor profiles trigger manual review, i guess i just add a copy of openssl to my snap
 * longsleep found that he cant just copy /usr/bin/openssl :D
<jdstrand> longsleep: right, so stepped away for a bit. I'm going to upload this today and it will be in 15.04/edge. it won't hit stable for a few weeks
<jdstrand> longsleep: so, since you are using snapcraft, 'just' add openssl to your list of debs and it should add it for you
<jdstrand> longsleep: I put 'just' in quotes because I've not used snapcraft and I don't know how easy that is. but other people here do
<longsleep> jdstrand: yes i did that - it is easy with snapcraft. Even my own plugin supports it
<jdstrand> ok cool
<longsleep> I have finished a working snap now, but fail to upload Service unavailable. Please try again later. ([])
<longsleep> store seems to be borked
<jdstrand> beuno: fyi, ^
<beuno> looking into it
<longsleep> jdstrand: with my debs plugin i can just add any already built deb file from url or file source into the snap. That way i can easily build armhf snaps on amd64 with snapcraft for clean room built debian packages.
<jdstrand> neat
<longsleep> jdstrand: http://paste.ubuntu.com/11974578/ for the snapcraft file
 * longsleep likes snapcraft
<jdstrand> yeah, it is really coming along aiui
<jdstrand> mterry, ted, rsalveti, et al: ^ :)
<beuno> longsleep, can you try and upload again, while I chase this?
<longsleep> now if i would figure out how to push a merge request to launchpad with git i could send the patches for the debs plugin
<longsleep> beuno: trying now
<longsleep> beuno: nope - still Service unavailable. Please try again later. ([])
<beuno> thanks longsleep
<beuno> longsleep, what app is this?  everything else looks healthy
<longsleep> heh - thats the spreed-webrtc snap i just created
<longsleep> (with snapcraft)
<beuno> longsleep, so, a new app instead of an update to an existing one?
<longsleep> yes new one
<beuno> longsleep, you seem to have hit a bug
<beuno> some value in your metadata is too long (over 128 characters)
<longsleep> beuno: hah - i have a talent for that
<longsleep> probably the description
<beuno> we'l queue up a fix, but the quickest option would be for you see which one is too long and shorten it  :)
<longsleep> sure
<beuno> longsleep, it's the title, I'm being told
<longsleep> err
<longsleep> that should not be long
<beuno> "title": "Spreed WebRTC allows people to communicate with audio/video and transfer files over WebRTC. Open Spreed WebRTC with your browser at: https://yoursnappy:8443/ - The SSL certificate, was generated on
<beuno>                  installation and is self signed.",
<longsleep> thats whats in the readme.md
<longsleep> i thought that goes into description
<beuno> I think the format in readme.md is:
<beuno> - title
<beuno> - return character
<beuno> - description
<longsleep> Ah
<longsleep> makes sense
<longsleep> let me just provide the title in the web then
<longsleep> beuno: Yes that worked. Thanks for your help!
<beuno> longsleep, np. Sorry for the hiccup
<longsleep> beuno: yay it even passed automatic review
<beuno> it was probably embarrased about the bug
<longsleep> Chipaca: I managed to put spreed-webrtc into the store (armhf only for now) sudo snappy install spreed-webrtc.longsleep if you want to give it a shot - thanks for your help!
<Chipaca> longsleep: congrats!
<longsleep> i am traveling the next 4 days - so it would be great if sergiusens would eventually review the updated odrodidc oem snap :P
<mterry> ogra_, rsalveti: who has used the webcam demo successfully? I want to pick their brain
<Chipaca> mterry: define success
<Chipaca> i used it, and it took a pic
<Chipaca> longsleep: sergiusens is a new dad, so all bets are off wrt his schedule :)
<mterry> Chipaca, I'm using it and it dies with: "GD Error: gd-jpeg: JPEG library reports unrecoverable error: Not a JPEG file: starts with 0x23 0x7d" when taking a pic
<mterry> Chipaca, I think some weirdness with my webcam I happen to have
<mterry> Chipaca, will play with fswebcam options
<Chipaca> mterry: AFAIK it was built for, and only tested with, logitech cameras
<Chipaca> mterry: so that's quite likely
<Chipaca> mterry: remind me, where was the web demo?
<Chipaca> i'll take another look
<mterry> Chipaca, I'm using a logitech c170...
<Chipaca> webcam*
<Chipaca> hey, that should work :)
<mterry> Chipaca, webcam-webui is the snap name I believe
<Chipaca> mterry: but the source?
<mterry> Chipaca, oh..  https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ is how to build one
<mterry> Chipaca, I don't know where the source for our package is
<Chipaca> mterry: no worries
<Chipaca> mterry: so, question, have you looked at the image file?
<Chipaca> mterry: or is that error thrown by fswebcam before actually producing the image?
<mterry> Chipaca, using "-p YUYV" fixed it!
<mterry> Chipaca, per https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=60076
<mterry> Chipaca, fswebcam wasn't making the image at all (or rather, it was spitting out a blank black jpeg
<Chipaca> hah! good one
<mterry> Chipaca, thanks for looking at it anyway  :)
<Chipaca> no worries
<Chipaca> i'll go have another beer, this one in your honour
<Chipaca> actually some pizza first
<mterry> :)
<Chipaca> don't worry, it'll be beer o'clock for you soon
<Chipaca> mterry: --resolution is also good
#snappy 2015-08-01
<Rlyeh> Hi
<Rlyeh> Yesterday, I was connected to woncloud through "192.168.1.102", but today, it's ip on modem is "192.168.1.105". I get invalid certificate error!!!
<Rlyeh> "You are accessing the server from an untrusted domain."
<Rlyeh> "Please contact your administrator. If you are an administrator of this instance, configure the "trusted_domain" setting in config/config.php. An example configuration is provided in config/config.sample.php.
<Rlyeh> Depending on your configuration, as an administrator you might also be able to use the button below to trust this domain. "
<Rlyeh> How can I enter owncloud again, without changing ip?
#snappy 2016-08-01
<liuxg> when i build my snap project, I get the the same file from two different parts with the same path. I do not know how to resolve the issue.
<qengho> liuxg: In your parts, use "stage:" to exclude it from one or both. """stage: [ -usr/share/haxored.txt, -var/tmp/no ]"""
<liuxg> qengho, thanks. I might have a try.
<liuxg> qengho, thanks. you solved my  problem :)
<dholbach> hey hey
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<seb128> hey dholbach!
<dholbach> salut seb128
<dholbach> didrocks, want to hang out and chat in a bit?
<didrocks> dholbach: I have a meeting at 10am, so either now or this afternoon (as we have the doc meeting at 11am)
<didrocks> I'm fine with both :)
<dholbach> let's quickly chat now
<dholbach> and we can still talk later on
<didrocks> sure!
<mup> PR snapd#1607 opened: changed snapd to snap <Created by liu-xiao-guo> <https://github.com/snapcore/snapd/pull/1607>
<qengho> liuxg: What version of snapd do you have?
<qengho> davidcalle had same question. :)
<davidcalle> :)
<dholbach> can somebody please help with https://github.com/ubuntu/snappy-playpen/pull/197?
<mup> PR ubuntu/snappy-playpen#197: Add Kodi snap for stable release <Created by dgmvecuador> <https://github.com/ubuntu/snappy-playpen/pull/197>
<mup> PR snapcraft#702 opened: Use the new snapcraft.io mailing list as contact information <Created by seb128> <https://github.com/snapcore/snapcraft/pull/702>
<liuxg> qengho, http://paste.ubuntu.com/21735507/
<qengho> Hmm! Should snapcraft provide something like "dh strip"?
<qengho> liuxg: haole. I have no idea of the difference.
<mup> PR snapcraft#703 opened: Update the completion list of commands <Created by seb128> <https://github.com/snapcore/snapcraft/pull/703>
<liuxg> qengho, with snapd, it does not work. I think the documents there are outdated. some of the them have the "snappy" there.
<didrocks> qengho: that's what we discussed and yeah, snapcraft is supposed to provide stripping in the "snap" stage
<mup> Bug #1608244 changed: implement low level usb interface for snaps requiring libusb <Snappy:New> <https://launchpad.net/bugs/1608244>
<mup> PR snapcraft#704 opened: Slightly tweak the "no jar files" errors (lp: #1606352) <Created by seb128> <https://github.com/snapcore/snapcraft/pull/704>
<jamespage> hi all
<jamespage> not sure if I'm just missing something, but  what's the norm for configuration files for a snap?
<ogra_> jamespage, there currently inst an actual norm ... i usually create them on first start of an app or daemon from the wrapper scripts ... in 15.04 we used to have a "snappy config" command that could handle yaml create a config
<ogra_> *isn't
<jamespage> ogra_, hmm ok - so I'm having a stab at some openstack snaps
<jamespage> ogra_, should I be using /etc/nova/ for example ?
<jamespage> or should that be in a snap specific location?
<ogra_> no, you should always use $SNAP for readonly data and $SNAP_DATA (daemons) or $SNAP_USER_DATA (apps) for writable stuff
<ogra_> and teach your app to use its config from there ...
<jamespage> ogra_, ack
<jamespage> ogra_, can I use those in the snapcraft.yaml ?
<ogra_> no, only at runtime i think
<jamespage> ogra_, I was thinking like "command: usr/bin/nova-api-os-compute --config-dir=$SNAP_DATA/nova.conf.d
<jamespage> "
<morphis> zyga: ping
<ogra_> jamespage, well, i'm not sure if $SNAP_DATA survives that when the command is being moved into the generic wrapper, you have to try :)
<jamespage> ogra_, ack - will poke and see
<Son_Goku> morphis, zyga will not return until Wednesday evening
<morphis> Son_Goku: ah ok, thanks
<Son_Goku> he's on his way to Krakow for family things and Flock
<Son_Goku> Fedora's conference
<morphis> ah
<Son_Goku> he's intentionally not taken his laptop with him, either
<Son_Goku> so there's literally no way to contact him unless you have his phone number :)
<sborovkov> Hi. I am using log-observe interface to read system journal. Running unconfined but anyway I am getting this messages. Is this normal?
<sborovkov> apparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system.journal" pid=751 comm="python3" r
<sborovkov> apparmor="ALLOWED" operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/1156d1fe87df441482d57dcd197ca7d5/system@1d2eed63da7b4c60b090256983be47bb-0000000000000ea7-00053901f4ca5813.journal"
<sborovkov> I am just polling for changes in system log using systemd's python API
<jdstrand> sborovkov: yes. notice those say 'ALLOWED'. reading systemd logs is allowed as of snapd 2.0.10
<sborovkov> Ah, I though that's because of me running unconfined. Understood
<ogra_> cjwatson, hmm, is there any way for me to get the info if my snap had proposed enabled ... beyond grepping sources.list from my makefile (like ... an env var ) ?
<mup> PR snapcraft#705 opened: parser - Remove namespacing and subparts <Created by josepht> <https://github.com/snapcore/snapcraft/pull/705>
<mhall119> sergiusens: how do I run the snapcraft test suite in a clean lxc?
<kyrofa> mhall119, just the units? Or everything?
<kgunn> jdstrand: hey, i've done another update to mir interface per your feedback wrt snippets for connected plug/slot for the client
<kgunn> jdstrand: would you mind just quickly eyeballing and telling me if i'm on the right path
<kgunn> https://github.com/snapcore/snapd/pull/1229
<mup> PR snapd#1229: Add in an application-lifecycle interface <Created by ted-gould> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1229>
<kgunn> not that one! ^
<kgunn> jdstrand: this one https://github.com/snapcore/snapd/pull/1299
<mup> PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299>
<SamYaple> yo yo. so I have a PR with a failing test and I can't access the IP to see the details of the failing test
<SamYaple> https://github.com/snapcore/snapcraft/pull/663
<mup> PR snapcraft#663: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663>
<SamYaple> its just packing anyway
<mhall119> kyrofa: the snaps really, so I can try and fix https://github.com/snapcore/snapcraft/pull/688
<mup> PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
<jdstrand> kgunn: it's coming along. I noticed though in PermanentPlugSnippet() you have the mirPermanentSlotAppArmor and mirPermanentSlotSecComp policy
<kyrofa> mhall119, try python3 -m unittest integration_tests.test_nodejs_plugin from the root of snapcraft
<jdstrand> kgunn: your permanent slot variables should go in your permanent slot function, your connected slot policy in your connected slot function, your permenent plug policy in your permanent plug function and your connected plug policy in your connected plug function
<kyrofa> mhall119, that's one of the failures
<kgunn> jdstrand: right, it's just a variable name ...
<kgunn> i'll correct that
<mhall119> kyrofa: I get ImportError: No module named 'fixtures'
<kgunn> jdstrand: i was really wondering if i had the snippet part right
<kyrofa> mhall119, ah, yeah check debian/control, make sure you have the right dependencies. python3-fixtures for that one
<jdstrand> kgunn: well... mirPermanentSlotAppArmor says "Allow operating as the Mir server". that needs to be what PermanentSlotSnippet() uses, not what PermanentPlugSnippet (which is what it is doing now)
<mhall119> kyrofa: thanks, doing that now
<jdstrand> kgunn: so don't change the names of the variables. use the variables in the correct functions
<kgunn> jdstrand: that's just it...if i move it, it will not work
<jdstrand> things aren't all correct
<jdstrand> I'll spell it out
<didrocks> jdstrand: hey! Is it known that latest version of snappy-debug is failing auditing syslog despite the plug being connected? http://paste.ubuntu.com/21762803/
<didrocks> (I guess the issue is in snapd interface not giving the correct permission)
<jdstrand> PermanentPlugSnippet() should use mirPermanentSlotAppArmor and mirPermanentSlotSecComp. right now it is returning nil, nil for apparmor and seccomp, so the server won't start
<jdstrand> kgunn: ^
<jdstrand> kgunn: next, ConnectedSlotSnippet() is returning nil, nil. It should be returning mirConnectedSlotAppArmor
<jdstrand> kgunn: next, ConnectedPlugSnippet is returning nil, nil. it should be using mirConnectedPlugAppArmor and mirConnectedPlugSecComp
<jdstrand> kgunn: and finally, PermanentPlugSnippet(), it should return nil, nil, but is not
<jdstrand> kgunn: what this does is on install, permanent slot policy is auto-generated for anything using 'slots: [ mir ]'. ie, your server would 'slots: [ mir ]' and be allowed to start
<jdstrand> kgunn: then a client that uses 'plugs: [ mir ]' is connected with 'sudo snap connect client:mir mir-server:mir', then the connected slot ploicy is added to the mir server's policy for connecting to the client, and connected plug policy is added to the client for talking to the server
<jdstrand> kgunn: does that make sense?
<jdstrand> didrocks: you need to run it as root
<kgunn> jdstrand: so let me ask you a very direct question, would you expect me to be able to launch my server and run a client the way it is currently implemented?
<jdstrand> didrocks: well, actually, I think you can run it without root, just won't have the sysctl work
<jdstrand> didrocks: the thing you pointed out is known and is fixed in snap-confine 1.0.39
<jdstrand> didrocks: which is in xenial-proposed
<didrocks> jdstrand: hum, IIRC, it was failing even as root when I tried it in front of a client, let me retry
<jdstrand> didrocks: snap-confine 1.0.38 introduced a regression that was fixed in the next upload to xenial-propsed. basically, take the newest version in xenial-proposed and it will work again
<didrocks> jdstrand: ah, ok, so regression, but fixed in -proposed
<jdstrand> didrocks: yes, because /var/log was not bind mounted into the runtime
<didrocks> jdstrand: that explains why I didn't see any denials in /var/log/syslog, thanks for confirming! :)
<jdstrand> kgunn: it depends on the yaml. your implementation is backwards wrt plugs and slots
<jdstrand> kgunn: your policy variables are correct. where they are used is backwards
<kgunn> jdstrand: this is my server yaml
<kgunn> http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snap/view/head:/snapcraft.yaml
<jdstrand> kgunn: yeah, that's wrong
<kgunn> jdstrand: btw - i always knew it was backwards from what i was told (which is what's been disturbing me)
<jdstrand> kgunn: the server should 'slots: [ mir ]'
<kgunn> jdstrand: damn it! :)
<jdstrand> kgunn: the slot side provides an implementation of the interface. your mir server snap is an implementation of a mir server
<jdstrand> kgunn: the server side slots. the client side plugs into the slot to use it
<jdstrand> kgunn: so, if you s/slots/plugs/ in your yaml, and then follow what I laid out in backscroll, it should only then be down to fine-tuning the policy
<mup> PR snapd#1608 opened: tests: add snapd-control interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1608>
<mhall119> sergiusens: ping, what's the rationale behind stripping common path prefixes when unpacking a tarball in snapcraft?
<mup> PR snapd#1609 opened: overlord/devicestate: first pass at device registration logic <Created by pedronis> <https://github.com/snapcore/snapd/pull/1609>
<mup> Bug #1608572 opened: There is no easy way to know what port snapweb is listening to <Snappy:New> <https://launchpad.net/bugs/1608572>
<kgunn> jdstrand: thanks for that, i always knew it wasn't right, i just didn't think the yaml was wrong...so thanks for helping
<jdstrand> kgunn: my pleasure!
<kgunn> jdstrand: and just to be sure...on the client side
<kgunn> http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/snapcraft.yaml
<kgunn> that is correct ^
<kgunn> right?
<kgunn> plugs [mir]
<jdstrand> kgunn: yes, server slots and client plugs
<kgunn> jdstrand: don't know how i overlooked that all this time
<kgunn> :-/
<jdstrand> well
<jdstrand> it isn't the most obvious thing in the world. zyga (hi!) has a blog series that is helpful, but you shouldn't have to read it now after our discussion here (though by all means do so if you want, it is good :)
<jdstrand> he is going to be writing another blog entry on creating interfaces I think soon
<mup> PR snapd#1610 opened: store: soft-refresh discharge macaroon from store when required <Created by matiasb> <https://github.com/snapcore/snapd/pull/1610>
<mup> PR snapd#1611 opened: tests: add locale-control write spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1611>
<ogra_> EEEK!
 * ogra_ just opened the gnome disk utility on a machine with a lot of snaps installed 
<mup> PR snapd#1527 closed: overlord/state,overlord/ifacestate: define basic infrastructure for and then setting up serialising of interface mgr tasks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1527>
<mup> Bug #1608608 opened: Snapweb avahi service is still called webdm.local <Snappy:New> <https://launchpad.net/bugs/1608608>
<mup> PR snapd#1612 opened: interfaces: add /proc/version_signature to appamor template <Created by arges> <https://github.com/snapcore/snapd/pull/1612>
<elopio> kyrofa: josepht: I looked at the code. By fake, I mean just to make sure that shutil.copystat was called.
<kyrofa> elopio, that doesn't seem overly fragile to you?
<elopio> mock.patch('shutil.copystat') and that's it.
<elopio> kyrofa: yes, it is.
<kyrofa> elopio, but the best option, you think?
<elopio> so also add a manual test that does chown, builds an os snap, and verifies the ownership.
<elopio> we might find ways to automate that manual test, probably as an integration test. But that's worth only if it takes a considerable amount of time to run it.
<kyrofa> elopio, sounds good. How do we document such manual tests?
<elopio> kyrofa: we have a file called manual-tests.md
<kyrofa> elopio, oh. How handy!
<elopio> I see that ogra_ has a bug with steps to reproduce this. Ideally, we automate what ogra is doing, but all his links take me to "page not found".
<josepht> elopio: okay, thanks for the direction :)
<stokachu> still running into this ugly loop: https://paste.ubuntu.com/21797159/
<stokachu> my snapcraft.yaml https://www.irccloud.com/pastebin/B3cVKFT7/
<stokachu> it works in snap try mode, but not installing from snap store
<stokachu> using snapcraft 2.13.1
<kyrofa> stokachu, interesting... are there symlinks somewhere in the /home/adam/snap/conjure-up/x1 path?
<stokachu> kyrofa: only thing i can think of is we use os.makedirs in some areas of the code
<stokachu> mainly creating directories in ~/.cache/conjure-up if they dont exist
<stokachu> kyrofa: https://github.com/conjure-up/conjure-up/tree/patch-dl-function this is the branch if you have time to try it out yourself
<stokachu> does the git source support a branch?
<kyrofa> stokachu, yes, using the source-branch keyword
<stokachu> lemme try that, i was trying to remove a wget dep and was pulling master during snapcraft rather than that branch
<kyrofa> stokachu, this does seem to be coming from your source somewhere, not snapd. I suggest trying to figure out which line exactly is busting
<stokachu> kyrofa: how do you debug this?
<kyrofa> stokachu, well first of all, does the application support some sort of --debug flag or something else that would enable stack traces?
<stokachu> kyrofa: yes
<kyrofa> stokachu, I'd start there
<stokachu> heh
<kyrofa> Can you pastebin the output of `conjure-up -h --debug` (or whatever)?
<stokachu> that pastebin above was from just running conjure-up -h
<stokachu> dont worry about it ill try to figure it out on my own
<stokachu> thanks
<kyrofa> Sure, but it's still swallowing the trace
<kyrofa> Okay
<ogra_> elopio, oh, which bug is that ?
<elopio> ogra_: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1605903
<mup> Bug #1605903: "type: os" should prevent stage and prime stages from mangling content <snapcraft (Ubuntu):In Progress by joetalbott> <https://launchpad.net/bugs/1605903>
<elopio> ogra_: could you please document the steps to reproduce that?
<ogra_> elopio, sure
<elopio> ty.
<ogra_> hmm, though thats a  bit tricky .. the image PPA has the fix backported already ...
<ogra_> to actually repro it you would need a copy of the PPA with the patches snapcraft removed ...
<ogra_> *patched
<elopio> ogra_: don't worry. Just mention that it will not fail because the ppa is patched. It is nice that it actually passes already :)
<ogra_> elopio, i added a comment with instructions ... but it is non-trivial  due to the PPAs involved
<ogra_> added a note :)
<ogra_> if anyone feels like, you guys can also just upload snapcraft to that PPA ... every snappy-dev member has upload access
<ogra_> happy to do test builds
<josepht> elopio: fwiw, I think we can just have a test that does 'snapcraft build; sudo chown nobody:nogroup <some-file>; snapcraft prime' and ensure that 'prime/<some-file>' isn't owned by root
<josepht> elopio: a manual test, I mean
<elopio> josepht: sure, that works.
<elopio> at some point we need to make sure that we never break ogra's workflow, but I have the feeling that it will be a test in ubuntu-core-snap.
<ogra_> feel free to make a merge proposal ... the branch is owned by snappy-dev ... we all are members ;)
<kyrofa> I need my new house... internet is sooo flaky out here
<ogra_> still not moved ?
<kyrofa> ogra_, the move has multiple stages :P
<kyrofa> ogra_, made it across the country, but crashing with in-laws while we're waiting for the house to close
<kyrofa> Needing to run snapcraft + 30k downloads/occasional complete connection death = kill me now
<ogra_> right, you said so in heidelberg ... i thought thaat phase would be over eventually :)
<kyrofa> Yeah, another month
 * kyrofa cries
<ogra_> kyrofa, sudo snap install packageproxy ... point your sources.list to localhost:9999 ...
<elopio> kyrofa: mosh + byobu + canonistack.
<kyrofa> Hmm... canonistack might be a good idea. As long as it doesn't eat my VM before I'm done with it :P
<kyrofa> ogra_, what is packageproxy?
<ogra_> kyrofa, a snap using approx ...
 * kyrofa wants a `snap show` command or something
<ogra_> it sets up a local package proxy on your machine, so packages only get downloaded once
<kyrofa> ogra_, ah, that's handy
<ogra_> https://github.com/ogra1/packageproxy
<kyrofa> ogra_, you should put the cache in SNAP_COMMON now, not SNAP_DATA
<ogra_> i used it all the time for local image buiulds ... i'D go crazy when having to download gigs for every build when i do like 20 in a row
<kyrofa> ogra_, unless you really want it versioned?
<ogra_> kyrofa, yeah, i need to re-work that snap a lot... it is originatig from 15.04 :)
<kyrofa> Oh, nice
<ogra_> (i have a 15.04 snappy server with it running in active use here :) )
<ogra_> i only did a few quick hacks to make it series 16 compatible ... but it should actiually be re-done completely ... i'm kind of waiting for the new config interface first though
<ogra_> in the 15.04 version you could actually manage all aspects of its config with snappy config commands
<kyrofa> ogra_, ah, right
<stokachu> kyrofa: so i have juju as a stage-package but i can't get it to run juju version
<kgunn> ogra_: hey , i bet i missed an incantation change...this used to work sudo ubuntu-device-flash --verbose core 16 --channel edge -o xen_aug1.img --developer-mode --gadget=canonical-pc --kernel=canonical-pc-linux --os=ubuntu-core --size=5
<stokachu> thats where it is hanging at
<kgunn> but now complains no hw description in gagdet
<kgunn> pointers?
<stokachu>  /snap/conjure-up/x6/usr/bin/juju: 3: exec: juju: Argument list too long
<kyrofa> kgunn, I think the gadget yaml format changed...
<invapid> if the source code is updated, how do you make a snap build using the new source code?
<invapid> just rm -rf stage/ # ??
<kyrofa> invapid, if it's just a single part in the snap, run `snapcraft clean <part> && snapcraft`
<invapid> hmm, must not be snapcrafts fault then
<kyrofa> invapid, what's happening?
<invapid> still debugging, but source code changes aren't getting compiled
<invapid> I assume it's just cached somewhere
<kyrofa> invapid, even with the clean command I just gave you?
<invapid> yep
<kyrofa> Huh... odd. Yeah that will completely remove the source cache that snapcraft keep in parts/<partname>/src
<mhall119> kyrofa: sergiusens: https://github.com/snapcore/snapcraft/pull/688 is passing now
<mup> PR snapcraft#688: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <https://github.com/snapcore/snapcraft/pull/688>
<kyrofa> invapid, is the source kept locally? Or is it on the internet somewhere?
<mup> PR snapd#1446 closed: interfaces/builtin: add dbus-bind interface <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1446>
<invapid> ahh - the "part" isn't pull from the source being modified
<invapid> thanks kyrofa figured it out
<kyrofa> invapid, ah ha! Good deal
<kgunn> jdstrand: ok, had time to get back to interface work...so i've cleaned it up and was testing, server is starting fine, mir-server:mir connection under slot...the mir-client:mir connection is listed under plug like expected
<kgunn> but there's an aa denail on client for open/read of /usr/share/applications, so i added /usr/share/applications r, to connected plug
<kgunn> but denial is still there...
<kgunn> am i missing something
<kgunn> ?
<kyrofa> kgunn, did you reinstall the snap after making the plug modification in snapd?
<kgunn> kyrofa: yep, removed / installed
<kyrofa> kgunn, yep, that's the length of my knowledge :P
<kgunn> (even rebooted the vm, cause snapd was pissed :)
<kyrofa> Hahaha
<kyrofa> kgunn, how are you testing your dev tree of snapd, by the way?
<kgunn> kyrofa: https://docs.google.com/document/d/1fhRDn8KkeOICgO3fxDwFbqPmultEuL18ThKaa-pjyzc/
<kgunn> granted i'm on a 2 week old image
<kgunn> (was too lazy to grab the experimental udf and build a new one)
<kgunn> maybe i should do that now
<kyrofa> kgunn, that plug isn't in master, right? It's completely new?
<kgunn> kyrofa: correct...it's the mir interface (which is a perma slot for server, and connected plug for client
<kgunn> )
<kyrofa> kgunn, okay. I was thinking maybe you were hitting the re-execution stuff, but then it wouldn't work at all
<kgunn> hmm...experimental u-d-f not happy
<mup> PR snapd#1613 opened: add dbus-app interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>
<kgunn> mmm, can't run VM while you run experimental udf
<jdstrand> kgunn: you would need '/usr/share/applications/ r,' (trailing slash is important)
<jdstrand> kgunn: but I'm not sure that should be there, but fine to add now and we can discuss in PR
<jdstrand> kgunn: also, nice! :)
#snappy 2016-08-02
<bananabot> hi, i'm trying to build a snap which includes a opencv program accessing an openni2 camera. wondering if someone has any hints on getting setting the permissions so the snap thing gets access to the hardware. is there any way to define this in snapcraft? I found this here https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ but it seems to be old documentation from when snap was called snappy. is there an equivalent to sudo
<bananabot> snappy hw-assign webcam-demo.canonical /dev/video0 or better something to define udev rules for a snap?
<ali1234> there is a v4l plug/interface
<ali1234> you put plugs: [camera] in your snapcraft.yaml
<ali1234> then you connect it after installing it
<ali1234> something like sudo snap connect camera <snap>
<bananabot> the problem is that camera doesn't show up as a /dev/video device. i think openni uses libusb to access the camera directly
<ali1234> then you are out of luck because there is no interface for that yet
<ali1234> bug 1598266
<mup> Bug #1598266: Cannot read/write to usb device [libusb][hidapi] <snapd-interfaces> <Snappy:Triaged> <https://launchpad.net/bugs/1598266>
<mup> Bug #1607265 changed: Ubuntu-core downloads before querying store for missing snap <Snappy:Invalid> <https://launchpad.net/bugs/1607265>
<bananabot> hm ok. that makes it pretty hard to use in robotic applications then. thanks for the link that explains at least that snappy hw-assign got removed.
<ali1234> you can always run in devmode until it gets implemented
<ali1234> i'm waiting on the same stuff
<bananabot> is there anything else other than "confinement: devmode" i need change to get it working. i have udev rules to get the camera working in the normal system.
<ali1234> yes you have to sudo snap install --devmode
<kalikiana> Note: sudo is only needed if you're not logged in ;-)
<ali1234> logged in to what?
<bananabot> thanks, it seems to be working in devmode now
<mup> PR snapd#1614 opened: Update documentation of /v2/system-information GET result <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1614>
<liuxg> has anyone tried the example mosqitto at https://github.com/snapcore/snapcraft/tree/master/demos/mosquitto. after I install the app, it seems there is no output.
<qengho> liuxg: What output are you expecting?
<liuxg> qengho, I did not see any output from running http://paste.ubuntu.com/21857552/. it could possible that the broker is not ready before the publish app is running
<liuxg> qengho, I can see the output of the broker at http://paste.ubuntu.com/21857599/, it seems that it is running. the subscriber is not running as well.
<qengho> liuxg: Ah.
<liuxg> qengho, this is the output of the subscriber http://paste.ubuntu.com/21857694/. I think it is good to define the order of the running services in snapcraft since some of the apps depending on the some of of services.
<qengho> liuxg: "not found" seems weird.
<liuxg> qengho, i did not install the snapd from the proposed channel. I just install it from the normal channel.my snapd version is like http://paste.ubuntu.com/21858068/
<liuxg> qengho, I think it could be possible that broker should be running first, then subscriber/publisher
<qengho> liuxg: I don't think you're seeing the systemctl message correctly  "No such file or directory" is a big deal.
<qengho> That's not an app failure. That's a systemd failure, right?
<liuxg> qengho, I am not quite sure about that. it is weired to me.
<qengho> liuxg: systemd could not reach down into the app to find out how and why it failed to find something. systeemd itself(!) couldnot find something.
<liuxg> qengho, OK. does it mean that it is a bug somewhere?
<qengho> liuxg: Yes. Probably snapcraft.yaml
<liuxg> qengho, do you how I can install the latest snapd 2.11 version?
<qengho> Though, I thoughsnapcraft catchesthis problem.
<liuxg> qengho, maybe I file a bug against snapcraft?
<qengho> [5~Sure.
<liuxg> qengho, thanks. my colleague got the latest https://paste.ubuntu.com/21858180/ snapd version. How can I install it without installing the latest xenial-proposed? thanks
<qengho> liuxg: you need the deb file.
<liuxg> qengho, where can I find the debian file?
<qengho> liuxg: And you need luck that it doesn't pull new deps.
<qengho> How should I know?
<liuxg> qengho, what is your version of it?
<qengho> liuxg: If it's in Y, you can use "APT pinning" to upgrade only it. Google will help.
<liuxg> qengho, ok. thanks
<qengho> liuxg: I'm stale because I can't afford to break anything right now.
<liuxg> qengho, yeah, I am using the stable as well :)
<liuxg> qengho, I just reported a bug at https://bugs.launchpad.net/snapcraft/+bug/1608794
<mup> Bug #1608794: snapcraft mosquitto demo got "not-found (Reason: No such file or directory)" <Snapcraft:New> <https://launchpad.net/bugs/1608794>
<qengho> liuxg: is your colleague with snapd YC?
<liuxg> qengho, yes
<mup> PR snapcraft#706 opened: Added "camera" plug into the example <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/706>
<liuxg> qengho, sorry, I made  mistake in running the mosquitto demo app. the "subscribe" and "publish" are both apps instead of daemon. they both need to run using commands. now, the demo works fine as expected :)
<mup> Bug #1608807 opened: create-user fails to create user <create-user> <Snappy:New> <https://launchpad.net/bugs/1608807>
<dholbach> hey hey
<didrocks> good morning dholbach!
<dholbach> hey didrocks
<trijntje> when I open a file dialog from a snapped program it starts in $USER/snap/snapname/x1
<trijntje> Is there a way to have it start in $HOME so the user doesnt have to navigate there each time the app is used?
<didrocks> trijntje: there is no env variable AFAIK pointing to user's $HOME, $HOME in the snap is in $USER/snap/snapname/<version>/ as you told
<didrocks> maybe a discussion to trigger on the ML?
<didrocks> (ask niemeyer about his thoughts on this)
<trijntje> didrocks: Ok thanks, I thought so. Maybe add a soft link to home in the snap folder itself? You can set HOME for most programs, but then it will try to put configs and data in there which is not allowed
<didrocks> trijntje: that's exactly the issue, worth raising it IMHO :)
<trijntje> didrocks: I'll put it on the ML later today, I'll just wait a bit for niemeyer to respond
<didrocks> yeah, let's see :)
<mup> PR snapd#1614 closed: Update documentation of GET /v2/system-information result <Created by robert-ancell> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1614>
<mwhudson> ogra_: good morning
<mwhudson> ogra_: we (cyphermox and i) have been having some fun with ubuntu-core images that don't dhcp
<mwhudson> ogra_: do you know anything about any problems like this?
<mwhudson> (sometimes they do dhcp... just not very often)
<kalikiana> trijntje: You can do HOME=/home/$USER so long as you tell the app not to use it for . files. That's what I do in neovim.
<kalikiana> XDG_ variables point inside the snap folders
<qengho> That is a big assumption about home dir. Be careful. Convention is not law.
<kalikiana> Law very often is based on convention ;-)
<kalikiana> Alternate suggestions welcome, I'm really just tweaking things as I go along as many things aren't established
<mup> PR snapd#1615 opened: overlord/snapstate, daemon: support for multi-snap refresh <Created by chipaca> <https://github.com/snapcore/snapd/pull/1615>
<ogra_> mwhudson, i see the firstboot setup stuff panic in syslog, and i noticed that i sometimes dont end up with a /etc/network/interfaces.d/eth0 ... which i think the firstboot job sets up
<ogra_> so yeah, that usually results in not getting dhcp requests
<mwhudson> ogra_: hm, what does that panic look like?
<mwhudson> Aug  2 02:55:41 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE
<mwhudson> Aug  2 02:55:41 localhost systemd[1]: Failed to start Run snappy firstboot setup.
<mwhudson> hm informative
<mwhudson> oh is error: cannot read seed yaml: /var/lib/snapd/seed/seed.yaml related?
<mwhudson> hmm maybe
<mup> PR snapd#1616 opened: tests, integration-tests: implement the cups-control manual test as a spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1616>
<mwhudson> ogra_: what is supposed to create seed.yaml?
<ogra_> mwhudson, ubuntu-devcie-flash i think
<ogra_> (or in the new worldorder perhaps "snap prepare-image"
<ogra_> )
<mwhudson> ogra_: ah so maybe my bootleg ubuntu-device-flash is too old?
<ogra_> mwhudson, is that syslog or journald ? i thin journald doesnt show the panic
<mwhudson> ogra_: syslog
<ogra_> k
<mwhudson> i don't see an actual panic though
<mwhudson> in my case :-)
<ogra_> and is that real HW ir kvm ?
<ogra_> *or
<mwhudson> kvm
<ogra_> interesting ... i see the panic all the time
<mwhudson> i come from the server space, none of these toys :-)
<ogra_> lol
<ogra_> http://people.canonical.com/~mvo/all-snaps/16/ ... thats the latest udf
<ogra_> it seems to have issues when you use any local snaps though ... works fine with snaps from the store
 * mwhudson bangs head on desk
<ogra_> the seed.yaml actually describes the preinstalled and existing snaps ... when you boot like that, does snap list show you anything ?
<mwhudson> no
<ogra_> right
<mwhudson> i have noticed the oddness where on a system like this when you run snap install hello-world, the first thing it does is install the ubuntu-core snap
<ogra_> yeah
<mwhudson> which given what you said is not surprising
<ogra_> well, the feature comes from the desktop...
<ogra_> not sure if it should even kick in here
<ogra_> you dont have a kernel or gadget snap either ...
<ogra_> (i mean, you have thgem, but snapd doesnt know)
<mwhudson> hmmm
<mwhudson> this is all interesting but seems unrelated to networking, on looking at the code
<mwhudson> ogra_: what panic do you see, do you have one lying around to pastebin?
<ppisati_> is there a way to patch an app on-the-fly when snappying it?
<ogra_> mwhudson, http://paste.ubuntu.com/21754413/
<mwhudson> ogra_: wee
<ogra_> and this is the seed.yaml i end up when sideloading ubuntu-core http://paste.ubuntu.com/21762356/
<ogra_> not sure if the two are actually related though
<mwhudson> heh so i make an image to test this and of course it dhcp's this time
<ogra_> heh
<kalikiana> ppisati_: Not formally, no. You'd have to add your own build scripts.
<kalikiana> Unless you count environment variables.
<mwhudson> ogra_: so yeah, on an image that got networking there is /e/n/i.d/eth0, on one that did not there is not
<ogra_> right
<ogra_> Chipaca, do you happen to know what is supposed to create /e/n/i.d/eth0 nowadays ?
<ogra_> (i know we forcefully disable cloud-init network setup currently because snapd used to be supposed to create it, perhaps thats not the case anymore ? )
<mwhudson> it sure looks like snapd is trying to create it
<ogra_> k
<ogra_> i wonder if it is supposed to change though
<Chipaca> ogra_: `snap firstboot` creates it
<mwhudson> could this be a race with whatever populates /sys/class/net/eth* ?
<ogra_> ok
<ogra_> mwhudson, hmm, that would be the NIC module
<mwhudson> looks from the code that the only reason EnableFirstEther would return without writing a file is no /sys/class/net/ thingies
<ogra_> probably firstboot should wait til module-init-tools (or however systemd calls it) has run
<Chipaca> ogra_: mwhudson: snapd.firstboot.service is run before network-pre.target which might be bad
<Chipaca> in that the whole early boot ordering is a nightmare
<Chipaca> early for snappy that is
<Chipaca> :-)
<ppisati_> kalikiana: what you mean "Unless you count environment variables"?
<ogra_> well, snappy is also special in the initrd setup ... we dont ship each and every NIC module in the world like a classic install would
<ogra_> so module loading actually only happens after the rootfs is fully set up
<ogra_> which is a lot later than in classic
<mwhudson> Chipaca: should i file a bug at launchpad.net/snappy saying 'firstboot does not always create populate /e/n/i.d' or something like htat?
<Chipaca> ogra_: mwhudson: could you post the output of `systemd-analyze --system plot` somewhere?
<Chipaca> I'm assuming this is in an all-snaps system
<mwhudson> yes
<Chipaca> good :-)
<kalikiana> ppisati_: You can supply a wrapper that tweaks the environment as needed, maybe affects modules loaded by the binary, or even edits use-writable files during launch.
<mwhudson> Chipaca: can you remind me how to run kvm so that i get the tty on stdin/stdout, not in a window?
<ppisati_> kalikiana: nope, a wrapper in this case won't cut it
<mwhudson> Chipaca: also a non-custom ubuntu-core snap would make this easier...
<Chipaca> mwhudson: -nographic ?
<kalikiana> ppisati_: Personally I would aim for solving everything through config values - if the snapped binary has no option to let you snap it properly, it can probably be added
<mwhudson> oh wait, i have a sufficiently un-custom snap i think
<flixr> hi guys, I'm wondering what happend to the support of assiging udev rules to allow a snap to access certain hw devices as described in https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<flixr> has this support gone away with 16.04 and snapcraft?
<flixr> how would I allow my snap to access multiple cameras and other hw devices like sensors connected via iio?
<mwhudson> Chipaca: oh heh, right
<Chipaca> mwhudson: if this is to get the output of analyze, note it's an svg
<mwhudson> Chipaca: oh
<kalikiana> ppisati_: In the short term you can of course simply fork whatever it is and patch that before you consider upstreaming (as I did because I required new options in neovim's build)
<ppisati_> kalikiana: yeah, i see what you mean
<mwhudson> Chipaca: i guess i can scp after running dhclient manually...
<Chipaca> :-)
<Chipaca> thank you
<mwhudson> of course now my images are consistently managing to dhcp by themselves
<ppisati_> kalikiana: i'm actually snaping two apps: midnight command (so i can probably tweak some stuff with ./configure --... there) and a second unrelated python scrpt based app (that requires the patching too)
<ppisati_> let's see
<Chipaca> mwhudson: oh, wait, this is a "sometimes yes sometimes no" problem? have you checked journalctl for circular deps?
<Chipaca> otherwise yeah timing probably
<Chipaca> meaning the deps are wrong one way or another
<ogra_> on my working system the firstboot job runs ~2sec before network-pre
<mwhudson> Chipaca: i did look in journalctl but not specifically for that, how does it show up?
<Chipaca> mwhudson: in angry red (if your term supports it), search for "cyclic"
<mwhudson> Chipaca: nothing like that
<mwhudson> i've just had a terrible thought
<mwhudson> which is that i didn't see this with -nographic
<mwhudson> a difference with nographic is that you don't see grub and so have to wait 2 seconds for the default to be taken
<mwhudson> whereas with kvm in a window i can be impatient and hit return early
<trijntje> kalikiana: The app I'm snapping looks for .dot files and folders in$HOME, so I have to set $HOME to the snapdir. Ideally, we would have something for every snap that takes care of this, so we don't have to modify every app ;)
<mwhudson> Chipaca: http://people.canonical.com/~mwh/plot.svg
<ogra_> wow
<ogra_> your boot takes awfully long
<Chipaca> mwhudson: and that time it worked?
<Chipaca> mwhudson: (i'm assuming you remove the stampfile or start from pristine every time)
<ogra_> nearly 5sec longer than mine here
<Chipaca> actually if the stampfile is there systemd would not even run it, so yeh
<mwhudson> Chipaca: no that was a failed boot
<mwhudson> Chipaca: i've been re-running udf between boots
<Chipaca> oooh, what is sys-subsystem-net-devices-eth0.device
<mwhudson> well not a failed boot but a failed to network boot
<Chipaca> mwhudson: can you edit the firstboot service file?
<Chipaca> mwhudson: by copying it to /etc/systemd/system for example
<Chipaca> mwhudson: and change it to be After: network-pre.target Before: snapd.service networking.service
<mup> PR snapcraft#702 closed: Use the new snapcraft.io mailing list as contact information <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/702>
<mwhudson> Chipaca: it's nearly 2300 here so...
 * ogra_ notes he definitely does not have sys-subsystem-net-devices-eth0.device on a successfully booted setup
<trijntje> Can anyone build the plank snap from the snappy playpen? It asks me for my git.launchpad.net credentials but fails anyway. I want to take a look at how the mime types are defined in the final snap https://github.com/ubuntu/snappy-playpen/tree/53d3668ab6dc1a5c711f9c5e2deddd6abd59482b/plank
<ogra_> oh
<ogra_> wait, i do
<Chipaca> mwhudson: aw
<Chipaca> mwhudson: get out of here then :-)
<mwhudson> Chipaca: let's give it one shot
<Chipaca> hoping that one's not cyclic :-/
<mwhudson> Chipaca: seems to have worked!
<mwhudson> of course it sometimes worked anyway, but eh
<Chipaca> mwhudson: go to bed, more tomorrow
<mwhudson> Chipaca: feel free to talk to cyphermox about this when he wakes up :-)
<Chipaca> and if there isn't a tomorrow, not going to bed won't fix it either
<mwhudson> (if you are still around then)
<mwhudson> heh
<mwhudson> i like your plan though
 * mwhudson zzz
<trijntje> I'm reading the terms on the  ubuntu snap store, and it says "App(s): one or more applications or content items owned by you which you submit through the Developer Site and any associated screen shots and marketing materials provided by you. "
<trijntje> what about snapping software that you are not the owner of, like most open source projects?
<mwhudson> Chipaca: final thought, this will all change when netplan takes over the world i guess!
<mwhudson> Chipaca: i need to talk to someone about that, definitely not right now though
<Chipaca> mwhudson: i can't hear you because you are asleep
<ogra_> mwhudson, depends if pitti plans to backport everything to 16.04  :)
<ogra_> (and i mean everything ... )
<kalikiana> trijntje: Teach the app XDG_ variables. Other than that what else would you do? Bind-mount . files to fool the snapped executable?
<trijntje> kalikiana: no, the app respects XDG_ variables, but then we tell it that its home is in $USER/snap/mysnap/x1. So when we then go to open a file, the file dialog starts there, instead of in /home/$USER
<kalikiana> trijntje: Which is why I would map HOME=/home/$USER
<stokachu> so how does one include config files into our snap that's not in the same directory as our snapcraft file?
<kalikiana> stokachu: Where do those files come from? A subfolder? Or a separate repository?
<stokachu> kalikiana: https://github.com/conjure-up/conjure-up is my current directory structure, snapcraft/snapcraft.yaml holds that metadata and etc/conjure-up.conf holds the config
<stokachu> i want to make sure etc/conjure-up.conf ends up in my snap user data directory
<kalikiana> stokachu: Afair it must be in the read-only bit first, then the wrapper could determine if it exists and create/copy it on startup
<kalikiana> You could use the copy plugin to make sure it's in there
<stokachu> i tried the copy plugin but i don't know where to copy the config from while int he build
<stokachu> i have to do weird stuff with the requirements.txt file,     requirements: parts/conjure/src/requirements.txt
<stokachu> i dont understand why it doesn't just pick it up during the build
<kalikiana> stokachu: Copy is relative to the snapcraft.yaml, so files: etc/conjure-up.conf: etc/conjure-up.conf should work
<stokachu> kalikiana: snapcraft/snapcraft.yaml is the location
<stokachu> and doing ../etc/conjure-up.conf: etc/conjure-up.conf doesn't work
<kalikiana> Oh, I see
<stokachu> i could just move the snapcraft.yaml but i want to understand how to grab those files regardless of location of snapcraft.yaml
<stokachu> like what if snapcraft.yaml was a different repo from the source
<kalikiana> stokachu: I think in theory you could use copy with the same git repo and get it from there, although I've not tried it
<flixr> is there any replacement for giving access to devices in snappy 16.04 (was possible via assign: rules: -kernel: foo in 15.04), is there anything planned?
<flixr> or why was it removed in the first place?
<kalikiana> stokachu: ie. if you specify source, it won't look at the snapcradft folder
<flixr> kind of makes it not usable for IoT devices anymore
<stokachu> kalikiana: ok ill play with that a bit
<flixr> zyga, r u there?
<stokachu> can you specify multiple plugins for a single part?
<Mirv> is there something like source-sha256: or how would I make a validation of the upstream source fetched?
<Mirv> if source is upstream tarball, or do I need to just download the source locally and validate manually?
<kalikiana> stokachu: No. But snapcraft should be smart enough to re-use it and not re-download.
<stokachu> kalikiana: it rechecks out the git source it looks like
<kalikiana> stokachu: Hrm. I'd say that's a bug.
<stokachu> verifying now with a clean install
<kalikiana> There's one bug about deb packages being pulled in by multiple parts so there might be other flaws in the caching.
<stokachu> sergiusens: ^ do you know if this is the case
<stokachu> hmm, the snap shows /etc/conjure-up.conf but conjure-up.shell doesn't see that file at all
<ali1234> by default snapd doesnt set up XDG_DATA_DIRS
<ali1234> so "teaching" the app about them doesn't actually help very much
<stokachu> so in my snapcraft.yaml where do i copy those files too?
<stokachu> right now it's etc/conjure-up.conf: etc/conjure-up.conf
<stokachu> this is my current yaml https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541
<ali1234> that seems reasonable?
<stokachu> im guessing it's not reasonable? since it doesn't work
<ali1234> you need to make the app look for $SNAP/etc/conjure-up.conf
<ali1234> by changing the source code if necessary
<stokachu> so we have to basically code our applications to be snap specific?
<ali1234> no
<ali1234> you just have to code them with a command line option that allos you to specify the location of the config file
<ali1234> all good software already does that since years...
<ahoneybun> cwayne: I'm using your snapcraft.yaml to try to build atom 1.9 that came out today
<stokachu> same with directory structure since years...
<ali1234> yes, XDG_DATA_DIRS has been around for a long time
<kalikiana> stokachu: So what doesn't work? Is the file in the snap?
<stokachu> the file is in the snap
<stokachu> but not when i run conjure-up.shell
<stokachu> unsquashfs list the file
<cwayne> ahoneybun: are you hitting any issues? i know didrocks cleaned mine up quite a bit
<ahoneybun> not sure yet still building
<ahoneybun> I used your snap to make mine lol
<ahoneybun> or try to
<ali1234> the problem is this https://github.com/conjure-up/conjure-up/blob/master/conjureup/app.py#L185
<stokachu> so if conjure-up.shell shows files in /etc, why doesn't my file show up there even though is specifically told it to copy there
<ali1234> because that is not what copy plugin does
<ali1234> copy plugin copies a file in to your snap
<didrocks> cwayne: IIRC, yours should work without devmode
<kalikiana> stokachu: If they are in the snap, where are they? .shell should see anything that is in there once it's installed
<stokachu> ali1234: if it's in the snap why isn't it in the shell?
<ali1234> what do you mean "in the shell"?
<stokachu> https://www.irccloud.com/pastebin/V9HfBlV2/
<stokachu> kalikiana: ^
<stokachu> ali1234: conjure-up.shell
<ali1234> because snaps arent uncompressed over /?
<stokachu> ali1234: are you asking me if they are?
<kalikiana> stokachu: As the code looks for ../etc/conjure-up.conf maybe you need a subfolder in there
<ali1234> no
<ali1234> your code looks for /etc/conjure-up.conf and ../etc/conjuse-up.conf. the file will actually be at /snap/conjure-up/xn/etc/conjuse-up.conf
<cwayne> didrocks: nope, cause it tries to call nohup
<cwayne> for some reason
<ahoneybun> mm an error
<stokachu> ali1234: so that goes back to using $SNAP to figure out where the file is
<ali1234> stokachu: yes, exactly
<ahoneybun> cwayne: http://pastebin.ubuntu.com/21888796/
<stokachu> ali1234: even if i give it a cli option to poitn to the config file
<ahoneybun> I used the one from playpen
<stokachu> it still requires $SNAP
<ali1234> stokachu: then you use the cli option from within your wrapper script
<stokachu> and where do i edit that file?
<stokachu> in the apps section?
<ali1234> yes
<stokachu> command: conjure-up <what goes here>
<ali1234> command: mywrapper conjure-up
<stokachu> just the relative path to the config?
<stokachu> oh i see
<stokachu> i have to create another file to do this
<ali1234> yes
<ali1234> see for example the desktop-launcher
<stokachu> https://github.com/snapcore/snapcraft/tree/master/demos?
<ali1234> you could also do it by just supplying arguments
<stokachu> where is that example
<ali1234> https://github.com/ubuntu/snapcraft-desktop-helpers
<ali1234> so you could probably just do command: conjure-up -c <path-to-config>
<ali1234> if conjure-up accepted a -c option
<stokachu> ali1234: can i do conjure-up -c $SNAP/etc/conjure-up.conf
<ali1234> yes
<stokachu> i didnt realize $SNAP was translated in the snapcraft.yaml file
<stokachu> or do i still need the wrapper?
<ali1234> $SNAP isn't know until install time
<stokachu> ok so still need the wrapper
<ali1234> no, you don't
<ali1234> maybe not for this
<ali1234> but you might need it for something else
<ali1234> depends what problem you run into next?
<stokachu> how do i know where the conjure-up.conf file is located if i just wanted to do it in the snapcraft.yaml?
<ali1234> you write $SNAP
<ali1234> snapcraft.yaml copies it into the shell script it generates automatically
<balloons> hey kyrofa, do you expect your godeps PR to land soon? https://github.com/snapcore/snapcraft/pull/691
<mup> PR snapcraft#691: Add godeps plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/691>
<ali1234> look at /snap/bin/conjure-up
<ali1234> it is a shell script
<stokachu> i see
<stokachu> ali1234: https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541#file-snapcraft-yaml-L12 can i do something liek this?
<ali1234> when you run a snap it is shell scripts inside shell scripts
<ali1234> yes if you add that command lne option to conjure-up
<stokachu> yea i will
<stokachu> just curious on that part with snapcraft
<stokachu> ali1234: kalikiana: this clears up a lot, thanks for putting up with my questions
<ali1234> you can also do it with a wrapper script, which is neater if you need a lot of arguments and environment variables
<ali1234> it is just up to your personal preference
<stokachu> ali1234: yea I will probably end up doing that
<cwayne> ahoneybun: that looks like an issue within atom itself somehow
<cwayne> as its failing to run its own bootstrap script..
<mhall119> sergiusens: kyrofa: can one of you let me know when my patch is in a snapcraft release? I'd like to propose my packaging configs to upstream Arduino, but can't until it "just works"
<mup> PR snapd#1511 closed: overlord: actually run hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1511>
<didrocks> cwayne: interesting, I was sure it was it was working, did you talk with the security team about ideas to circumvent that?
<cwayne> nope
<didrocks> cwayne: another way, we can set -f by default, this shouldn't call nohup?
<cwayne> didrocks: i think i tired that, but didnt change anything
<didrocks> interesting, I was sure to have run atom unconfined from the latest playpen
<didrocks> but I might be wrong
<didrocks> or have bad memory :p
<didrocks> but otherwise, open a bug and try to talk about it on the ML with the security guys for ideas
<didrocks> (but the answer might just be "fix upstream" :p
<ali1234> didrocks: is there some better way to achieve this, without putting a wrapper in a wrapper? http://paste.ubuntu.com/21893086/
<didrocks> ali1234: for now, this is the best you can do. I wonder strongly if the desktop-launch wrapper can't source some directories for this
<didrocks> (that would avoid chaining wrappers)
<ali1234> i was thinking more like... make it pull stuff from the yaml
<didrocks> but yeah, no other way right now, sorry
<didrocks> ali1234: easy for simple case like FOO=bar
<didrocks> a little bit less for FOO=$FOO:bar
<didrocks> because in your specific case, you want this to apply after desktop-launch is running
<didrocks> just before its exec=
<didrocks> (you may dep on some variables set by the wrapper)
<ali1234> maybe
<ali1234> however you could just insert things from the yaml verbatim into the launcher
<didrocks> yeah, for env variables, this is planned
<ali1234> cool :)
<didrocks> I don't know where sergiusens is on his long priority list :)
<didrocks> but this is definitively part of it
<ali1234> in this specific case i should probably just build everything with /usr prefix
<ali1234> i'm not really sure about the implications of doing that though
<didrocks> you will get your result in $SNAP/usr/â¦
<ali1234> that's what i want
<ali1234> but is there any risk that absolute paths could creep in?
<ali1234> should i use /usr or usr/?
<ali1234> or just "usr"?
<didrocks> depends on the build system :)
<ali1234> autotools
<didrocks> if they generate a config.h file
<didrocks> (yeah, but what modules?)
<didrocks> for instance, some are doing:
<ali1234> no idea
<didrocks> DATADIR=$PREFIX/share
<didrocks> and so you will get some tools fetching sources from a hardcoded /usr/share
<didrocks> (and so, not being relocatable)
<ali1234> yeah that's the problem that i have
<ali1234> except that if you don't supply a prefix then the plugin uses ""
<ali1234> and it looks in /share
<ali1234> so maybe i should just use "usr" AND ALL MY PROBLEMS GO AWAY LIKE MAGIC
<ali1234> oops caps :)
<didrocks> yeah, setting the prefix wouldn't help in that case IMHO :)
<didrocks> is there any env var to override this?
<ali1234> yes, XDG_DATA_DIRS
<mup> PR snapd#1617 opened: many: move to purely hash based key lookup and to new key/signature format (v1) <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1617>
<ali1234> hence my wrapper script
<ali1234> but it looks in $XDG_DATA_DIRS/share and not $XDG_DATA_DIRS/usr/share
<ali1234> unless you build it with prefix="/usr" (or some variation)
<kalikiana> ali1234: didrocks Environment variables is bug 1583259
<mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <Canonical Click Reviewers tools:Fix Committed by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <https://launchpad.net/bugs/1583259>
<ali1234> thanks
<didrocks> ali1234: yeah, so "fixable" at least :)
<didrocks> kalikiana: thanks for the ref!
<ali1234> yeah but fixable in multiple ways, i don't know which way is the right one :)
<didrocks> env var for now I would say
<ali1234> so double wrapper... okay
<didrocks> yeah, we'll get better at it, but it's an incremental process :)
<ali1234> so it would be nice if you could achieve what the desktop-launcher does, with only the correct lines in the yaml
<ali1234> or at least most of it
<jdstrand> cwayne: please file a bug for nohup and paste the security denials (grep audit /var/log/syslog) for that app
<jdstrand> cwayne: add the snapd-interface tag
<didrocks> jdstrand: I don't think it's something you would really want to allow right?
<didrocks> ali1234: yeah, it's the long term goal :)
<didrocks> nohup wouldn't give you long running process that you wouldn't like?
<ali1234> didrocks: also it would be nice if this was one of the standard built-in vars: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L13
<ali1234> maybe $SNAP-LIBDIR or something
<Odd_Bloke> Hello all, I'm getting 'This application failed to start because it could not find or load the Qt platform plugin "xcb".' when building a PyQT5 application; I'm stage-package'ing python3-pyqt5 and libx11-xcb1.  Am I missing something else I need to add?
<jdstrand> didrocks: well, we already allow background processes in the form of daemons. but, I think the denial is only for the nohup command. and app could ship that itself or trap the signal itself so I don't really see the point in blocking it
<Odd_Bloke> (I'm getting this even in devmode)
<jdstrand> we'll see what the denial is
<didrocks> ali1234: oh don't tell me, it's on my list since a very long time :)
<didrocks> jdstrand: oh, good point
<qengho> Odd_Bloke: that is the most common complaint I see. :(
<kyrofa> balloons, I expect the godeps plugin to land in master tomorrow-ish
<kyrofa> mhall119, will do! I've been in that boat before :)
<kyrofa> mhall119, though you can keep an eye on your bug as well-- it'll be updated as it goes through the SRU process
<renatu> hey guys how I can force snapcraft to re-download the deps after update the stage-packages list.
<SamYaple> can I get some help with this PR? I can't actually access the autopkgtest to see why it failed. https://github.com/snapcore/snapcraft/pull/663
<mup> PR snapcraft#663: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663>
<SamYaple> it was passing before I rebased it since it had gone a while without review
<kyrofa> Odd_Bloke, you're missing the stage-package that includes those plugins (and potentially missing the environment variable to pick them up in the snap)
<kyrofa> Odd_Bloke, is this qt5?
<Spads> https://github.com/scummvm/scummvm/pull/800 <-- zyga
<mup> PR scummvm/scummvm#800: Add snapcraft.yaml so you can `snapcraft build` <Created by spads-spads> <https://github.com/scummvm/scummvm/pull/800>
<sergiusens> Spads \o/
<sergiusens> hello everyone
<seb128> hey sergiusens
<stokachu> ugh, sudo snap install conjure_up_2.0.0.7_amd64.snap --devmode works, sudo snap install conjure-up --devmode does not
<stokachu> i dont understand why
<seb128> stokachu, does conjure-up exist?
<stokachu> yea
<seb128> is that in the store?
<seb128> or a local snap?
<stokachu> both
<seb128> what error do you get if you try to install the .snap?
<seb128> can you pastebin the cmd and output?
<stokachu> that way works, it's installing from the store that fails
<stokachu> it just hangs when i run `conjure-up -h`
<stokachu> https://www.irccloud.com/pastebin/ZkY2QFmd/
<sergiusens> stokachu did you "release" your latest upload?
<stokachu> just tried this ^
<stokachu> sergiusens: yep
<stokachu> https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/9/
<sergiusens> so hashes match
<stokachu> conjure-up   2.0.0.7               9    adam-stokes  devmode
<stokachu> from snap list
<sergiusens> what's the sha512 of conjure_up_2.0.0.7_amd64.snap ?
<stokachu> 9c43bfeb723da09b1e56adb8b42cc41977a937153a34a24ea2211ffb250c71f882b4e16c00f79ad01686dd86bec3176ba129acca2dc2025f33bfdea464f89377  conjure-up_2.0.0.7_amd64.snap
<stokachu> https://github.com/conjure-up/conjure-up/blob/f7ec4ea632ab5f8b8d4f368bcdb09475b6e6f8cd/snapcraft/snapcraft.yaml is my snappy file
<sergiusens> Chipaca can you give us some insight on the client installing with --devmode from the stable channel ?
<stokachu> sergiusens: are you able to download the snap directly and install it?
<sergiusens> stokachu I can, but there is no user facing api that allows this
<stokachu> https://myapps.developer.ubuntu.com/dev/click-apps/5479/download/rev/9/
<stokachu> that doesn't work for you?
<sergiusens> stokachu oh, I can fetch that snap, yes
<stokachu> and then install it locally to see if it works
 * sergiusens is downloading
<sergiusens> stokachu you can also just install remotely and copy over the .snap from /var/lib/snapd/snaps
 * sergiusens is unsure about the exact path
<stokachu> im just curious if it fails the same way for you
<stokachu> installing it locally should allow you to do conjure-up -h
<sergiusens> stokachu will install as soon as it finishes downloading
<stokachu> ok
 * sergiusens leaves to pick up his son from daycare in the meantime
<sergiusens> stokachu sorry to say I am on 3Mbps here ;-)
<stokachu> :\ https://www.irccloud.com/pastebin/kRLqcOUN/
<tianon> jdstrand: ah, good point re seccomp -- I'd managed to narrow down the list of calls Docker itself makes, but forgot that it starts arbitrary processes within containers which might need more O:)
<brendand> https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ seems to imply that after adding the 'parts' section and running snapcraft stage that i should have something in stage/bin, but it's empty
<brendand> the only output i saw that was suspicious was 'Please consider setting `go-importpath` for the 'cam' part'
<sergiusens> stokachu did you get around to logging the snappy bug for that?
<trijntje> kalikiana: but HOME gets mapped to $SNAP_USER_DATA for all snaps:
<trijntje> export HOME="$SNAP_USER_DATA"
<stokachu> sergiusens: no, im not sure if it's a bug on my end or snappy
<sergiusens> stokachu it is snappy for that one, it should exit and be done with it
<stokachu> ok ill file a bug now
<sergiusens> stokachu but it seems to be reexec'ing on and on
<stokachu> sergiusens: file against which project? snapcraft?
<arges> hi is there a way to re-run autopkgtest on a pull request? i seem to have a failure but it seems to be unrelated to my change
<arges> https://github.com/snapcore/snapd/pull/1612
<mup> PR snapd#1612: interfaces: add /proc/version_signature to appamor template <Created by arges> <https://github.com/snapcore/snapd/pull/1612>
<sergiusens> stokachu launchpad.net/snappy
<Chipaca> sergiusens, what about the client installing with --devmode from the stable channel?
<Chipaca> ouch, that linkfest looks wrong :-(
<stokachu> sergiusens: https://bugs.launchpad.net/snappy/+bug/1609045
<mup> Bug #1609045: running conjure-up -h results in the snap re-execing itself over and over <Snappy:New> <https://launchpad.net/bugs/1609045>
<mup> Bug #1609045 opened: running conjure-up -h results in the snap re-execing itself over and over <Snappy:New> <https://launchpad.net/bugs/1609045>
<Chipaca> stokachu, can you add information about where you're running thins?
<Chipaca> this*
<Chipaca> stokachu, like the distro you're on, and the snapd version, etc
<stokachu> Chipaca: done
<seb128> no mvo around?
<Chipaca> seb128, no
<seb128> Chipaca, do you know when he's back?
<sergiusens> seb128 tomorrow
<seb128> sergiusens, thanks
<stokachu> sergiusens: were you able to run conjure-up -h or did it hang?
<trijntje> kalikiana: wait nevermind, that is before the wrapper is called, so you can still change it their
<Chipaca> stokachu, you're re-execing the thing again and again i guess?
<mup> PR snapcraft#663 closed: Improve python2 test coverage <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/663>
<mup> PR snapcraft#706 closed: Added "camera" plug into the example <Created by liu-xiao-guo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/706>
<sergiusens> Chipaca his code isn't doing it
<sergiusens> Chipaca in his snapcraft generated wrapper script I added some echo's to be sure; zyga said something weird was going on
<kyrofa> Hey sergiusens, I expected you to be out another day
<sergiusens> kyrofa next week
<kyrofa> sergiusens, ah!
<sergiusens> but I am so tired; not really inspired today
<sergiusens> so just clearing the PR queue which I would feel bored to do some other day ;-)
<sergiusens> kyrofa is godeps good to go btw?
<kyrofa> sergiusens, yessir!
<kyrofa> I just updated it
<kyrofa> (from master, I mean)
<Chipaca> sergiusens, um
<Chipaca> sergiusens, conjure-up
<Chipaca> sergiusens, calls a wrapper script, something like command-conjure-up.wrapper
<Chipaca> sergiusens, which exec's conjure-up
<sergiusens> Chipaca yes
<sergiusens> Chipaca in that wrapper I added "echo running" and I see that echo'ed eternally
<Chipaca> which, if your machine has a python3 interpreter in /home/adam/something, will pick up a conjure up inside the snap
<Chipaca> but if not, it will look up the path
<Chipaca> and find the conjure-up where it all started
<stokachu> https://www.irccloud.com/pastebin/0XFp8Crt/
<stokachu> Chipaca: should i cahnge the conjure-up key to something else?
<stokachu> is it looping b/c of that?
<Chipaca> "key"?
<stokachu> the key in snapcraft.yaml
<ogra_> well ... dont use the machines interpreter ...
<Chipaca> ah, in the yaml
<stokachu> line 2
<ogra_> but ship your oown python
<stokachu> can i just add that to my stage packages
<stokachu> and does that fix my current issue?
<ogra_> well, what Chipaca said sounded like it could
<Chipaca> let me see
<Chipaca> stokachu, are you familiar with "snap try"?
<stokachu> Chipaca: a little
<ogra_> if you ever want conjure to run on a snap image instead of a classic install it is safer to ship your own interpreter anyway ...
<ogra_> same goes for making your snap cross dristro
<Chipaca> ogra_, they are shipping their own interpreter
<stokachu> i would've though the python3 plugin would take care of that
<ogra_> ah
<Chipaca> in fact they're shipping two of them just to be safe :-p
<Chipaca> snapcraft is putting python 2 and 3 in the snap
<ogra_> well, as long as all shebangs are mangled to point to that ...
<Chipaca> but that's not the issue
<Chipaca> the issue is the shebang
<Chipaca> stokachu, so, do this
<Chipaca> stokachu, in your conjure-up script and all other scripts you want to use
<Chipaca> you see to have
<Chipaca> #!/home/adam/Projects/conjure/snapcraft/parts/conjure/install/usr/bin/python3
<Chipaca> stokachu, change that to #!/usr/bin/env python3
<Chipaca> stokachu, that will work; i've just tried it
<stokachu> ok what do i need to do in my snapcraft.yaml to make that happen?
<Chipaca> it's not snapcraft
<Chipaca> it's the project itself
<stokachu> Chipaca: so i use setuptools to generate the script
<stokachu> https://github.com/conjure-up/conjure-up/blob/master/setup.py#L21
<Chipaca> bah, maybe snapcraft is responsible for the bad mangling of the shebang? sergiusens?
<Chipaca> stokachu, that works
<Chipaca> well, actually i don't know
<Chipaca> i don't know what's generating the conjure-up script itself
<stokachu> so i dont know where to put that shebang line at
<ogra_> i think the python plugin actually re-writes them
<Chipaca> that is the usr/bin/conjure-up script in the snap
<stokachu> it's all happening via setuptools
<Chipaca> sergiusens, this is all on you, it seems :-D
<stokachu> sergiusens: also the python3 plugin still won't pick up my requirements.txt
<stokachu> this all makes
 * stokachu very sad
 * Chipaca hugs stokachu 
<stokachu> sergiusens: feel free to try and reproduce with https://github.com/conjure-up/conjure-up
<stokachu> Chipaca: \o/
<sergiusens> Chipaca oh we fixed that in master, in any case the exec should be fine
<sergiusens> stokachu I can fix requirements.txt today; I thought I told you to use master
<Chipaca> sergiusens, I'm not following what you mean about the exec being fine
<sergiusens> Chipaca in any case, how would the outside app find the exec from the inside? isn't that just wrong in any case?
<sergiusens> Chipaca shebangs are fixed in master
<Chipaca> sergiusens, because the .wrapper is doing PATH=$SNAP/bin:$SNAP/usr/bin:$PATH, and PATH already has /snap/bin
<mup> PR snapd#1618 opened: interfaces: add lscpu to apparmor template <Created by arges> <https://github.com/snapcore/snapd/pull/1618>
<sergiusens> Chipaca so /snap/bin exists inside the contained environment? for what possible reason?
<Chipaca> sergiusens, what do you mean? the whole system is there
<ogra_> i think he meant $SNAP/bin
<Chipaca> no, /snap/bin
<sergiusens> ogra_ no, I mean /snap/bin
<ogra_> what would a snap do with /snap/bin ?
<Chipaca> nothing
<ogra_> it cant exec anything there by default
<Chipaca> nothing, for now at least
<sergiusens> ogra_ which is why I think it shouldn't be there after snap-confine sets up the env
<ogra_> right
<ogra_> well, it should be in the users PATH
<ogra_> but not in any of the wrappers
<sergiusens> also, $SNAP/bin/conjure-up should resolve before /snap/bin/conjure-up given the way we resolve the path
<Chipaca> sergiusens, first, snap-confine isn't a thing yet
<sergiusens> Chipaca heh, zyga sold it to me as a thing ;-)
<sergiusens> talked about it all week ;-)
<ogra_> it is definitely in proposed
<Chipaca> sergiusens, second, the idea isn't that it gives you a chroot-like experience where only your things exist
<Chipaca> sergiusens, snap-confine is 2.11 which is proposed. debian has 2.08 still /o\
<Chipaca> sergiusens, it's still apparmor and seccomp mediating stuff, with the whole system there but inaccessible
<Chipaca> right?
<sergiusens> Chipaca so what is with my statement that $SNAP/bin/conjure-up should resolve before /snap/bin/conjure-up given precedence of path?
<Chipaca> i saw no such statement, but i'll address it now
<Chipaca> sergiusens, that is correct, but only if $SNAP/bin/conjure-up has a valid shebang
<Chipaca> sergiusens, that is, the wrapper sets it up that way
<sergiusens> Chipaca as it is invalid, should it just exit?
<Chipaca> as I said: the .wrapper is doing PATH=$SNAP/bin:$SNAP/usr/bin:$PATH
<Chipaca> sergiusens, feel free to file a bug against posix or something; this isn't our behaviour
<Chipaca> sergiusens, wiht an invalid shebang it is not a valid executable
<Chipaca> sergiusens, so the search continues along the path
<Chipaca> sergiusens, i mean: this is /bin/sh doing the work, not us
<sergiusens> Chipaca http://paste.ubuntu.com/21914894/
<sergiusens> it didn't bounce to the next here
<Chipaca> sergiusens, now try with exec
<sergiusens> Chipaca ah, there we go :-)
<sergiusens> stokachu can you try master with your branch? in the meantime I'll fix that requirements.txt issue
<stokachu> sergiusens: i tried building snapcraft from master and it failed
<sergiusens> stokachu building with snapcraft or building snapcraft?
<stokachu> sergiusens: building snapcraft itself
<stokachu> sergiusens: sorry, ./setup.py install seems tow ork now
<stokachu> lemme try to rebuild
<sergiusens> stokachu how did you try and build? gbp buildpackage?
<sergiusens> stokachu in any case you can just use the sources directly
<ogra_> gbp ?
<stokachu> sergiusens: what do you want me to try master with?
<ogra_> you need to pay in british pounds ?
<stokachu> i thought it was snapcraft
<sergiusens> stokachu just run snapcraft as <path to snapcraft source>/bin/snapcraft
<stokachu> ok
<sergiusens> stokachu master has your shebang fix
<kyrofa> sergiusens, are you +1 on godeps? I can babysit and merge when green if so
<sergiusens> ogra_ gbp == git build package
<ogra_> ah
<sergiusens> kyrofa I want balloons to try it out though
<sergiusens> ogra_ akin to bzr bd
<ogra_> yeah
<balloons> I tried it and failed in Leiden
<ogra_> got it ... never used git for package trees :)
<balloons> as in I failed to get it to run.. it ate my snapcraft
<kyrofa> balloons, huh?
<kyrofa> balloons, you mean you weren't successful in running snapcraft from source?
<balloons> kyrofa, in other words, I have no useful data for you. But yes, I would really like it to land to use it
<balloons> kyrofa, right. I failed to get it to run (though I did a make install)
<balloons> err.. setup.py install
<sergiusens> balloons oh, just run from source
<kyrofa> balloons, yeah just clone snapcraft and run snapcraft from `<snapcraft root>/bin/snapcraft`
<sergiusens> kyrofa do we have docs for running from source?
<kyrofa> sergiusens, honestly I don't think so
<kyrofa> We should
<sergiusens> seems like we should
 * sergiusens is enjoying a nice blackout tethering with a very slow 3g connection for the past hour
<kyrofa> sergiusens, we have "bin: Holds the main snapcraft script. Putting this bin in your PATH or directly running scripts from it will find the rest of the source tree automatically."
<ogra_> could be worse ...
<kyrofa> in HACKIND.md
<kyrofa> sergiusens, haha: https://github.com/snapcore/snapcraft/blob/master/HACKING.md#installing-in-a-virtualenv
<kyrofa> sergiusens, I doubt that actually works
<ogra_> (smoke signs ... having to translate to morse code ... etc)
<stokachu> cant wait for deltas...
<kyrofa> sergiusens, I seem to remember josepht making some setup.py changes to make that better
<kyrofa> But yeah, balloons running straight from source is probably the easiest
<kyrofa> balloons, any chance you can give that a shot for me? Uninstall snapcraft from the system and run from source to use the new plugin, then you can just install snapcraft from the archive again
<balloons> kyrofa, ohh.. I remember one other bit about my attempt actually. It wasn't clear how to use the plugin
<balloons> kyrofa, but yes I can try now. My snap needs this plugin
<kyrofa> balloons, `snapcraft help godeps` will give you the various options it supports
<stokachu> sergiusens: still seems to be re-execing
<stokachu> using snapcraft from master
<stokachu> https://www.irccloud.com/pastebin/FZvrc3li/
<stokachu> sergiusens: ^ maybe running from snapcraft/bin/snapcraft isn't using the source from that tree?
<kyrofa> stokachu, uninstall the snapcraft deb, first
<stokachu> running it in pyenv
<stokachu> should be ok that way
<jcastro> hey, if I apt install snapd on a system that doesn't have it, do I need to logout and back in for the path to work? Seems like /snap/bin wasn't in my patyh
<stokachu> https://www.irccloud.com/pastebin/VkC9E3HR/
<stokachu> sergiusens: still uses this shebang path
<stokachu> holy balls
<stokachu> i think it is working now
<kyrofa> jcastro, yeah, probably. /snap/bin is in /etc/profile.d
<kyrofa> set in, rather
<stokachu> can someone else run `snap install conjure-up --devmode`, then run `conjure-up -h` to see if the help screen works
 * balloons tries
<balloons> whoa, 150mb!
<stokachu> balloons: hah
<stokachu> i even stripped out the juju packages except for the binaries
<stokachu> thats like 40mb
<balloons> kyrofa, I believe my yaml file is correct now, it's cloned and pulling depends. Hopefully my import path is correct
<kyrofa> balloons, it just needs to be whatever the project expects it to be-- the plugin doesn't care
<balloons> stokachu, it works
<stokachu> balloons: \o/
<stokachu> balloons: thanks for checking
<jhobbs> https://github.com/snapcore/snapcraft/pull/697 how do i proceed with this PR? autopkgtest snaps failed, though I can't see its results, and didn't make any changes that would have affected package builds afaict
<mup> PR snapcraft#697: Also use INSTALLROOT for make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/697>
<jcastro> stokachu: works for me too
<stokachu> jcastro: sweet! it doesn't deploy yet but im working on that now
<kyrofa> jhobbs, I just requested a retest, but it looks like it's out of date with master as well. Can you hit the "update branch" button, there?
<balloons> kyrofa, is there a way to easily reattempt the build step? I don't want to have to pull everything again
<balloons> IMHO, snapcraft should just re-execute a step if I specify it specifically
<kyrofa> balloons, indeed, you can `snapcraft clean --step=build` (or `snapcraft clean <part> --step=build`) and then run `snapcraft` again
<jhobbs> kyrofa: k, just did
<balloons> kyrofa, yea go-importpath is not happy
<kyrofa> balloons, what's happening?
<balloons> kyrofa, typically I would go install github.com/juju/juju/...
<kyrofa> balloons, so I assume you specified github.com/juju/juju as the go-importpath?
<balloons> that causes warning: "./github.com/juju/juju/..." matched no packages
<balloons> kyrofa, right
<sergiusens> kyrofa can you look at 707?
<mup> PR snapcraft#707 opened: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
<kyrofa> balloons, any chance you could pastebin your YAML? Or if this is contained within a source tree, push it up somewhere I can take a look?
<balloons> kyrofa, and sure enough, there is no parts/juju/go/src/github.com/juju/juju
<kyrofa> balloons, huh. That should be done as part of the pull step
<kyrofa> Actually, that's not true
<sergiusens> kyrofa during standup I will go over the changes we will do with the go plugin which we could reflect in godeps
<balloons> well, I got parts/juju/go/src/github.com/juju, but not parts/juju/go/src/github.com/juju/juju
<kyrofa> balloons, it should just be a symlink to parts/juju/src
<kyrofa> balloons, so what are you pulling?
<balloons> kyrofa, https://github.com/nskaggs/snap-juju.git
<mup> PR snapd#1619 opened: Add initial "docker" interface based on some of 15.04's privileges <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>
<kyrofa> balloons, take a look at parts/juju/src. Does it contain the entire repo?
<kyrofa> Or is it missing stuff, too?
<balloons> it looks correct
<balloons> hmmm
<balloons> found the symlink
<balloons> it's parts/juju/go/src/src/github.com/juju/juju
<kyrofa> balloons, wait.. src is duplicated? Okay, let me clone your project. It's up to date?
<balloons> yes, it is
<balloons> I may be at fault here
<balloons> fixing the bad symlink is getting a good run now
<balloons> I think I pulled with the import path containing an extra src argument in it. That's my guess
<kyrofa> Oh oops
<balloons> kyrofa, I have a snap now
<kyrofa> balloons, I'll verify what you have up there real quick
<balloons> ack, ty
<mup> PR snapcraft#698 opened: Add option disable-parallel for autotools plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/698>
<balloons> snap works. This is nice. +1 from me
<kyrofa> balloons, I'm testing on a clean lxc. Mind +1ing the PR?
<balloons> btw, testing a new plugin is actually really simple as you say. Just add the python file to the plugins dir :-)
<kyrofa> balloons, indeed. Did you know that you can use plugins from parts/plugins as well?
<kyrofa> balloons, so you can test/develop before upstreaming, or just distribute plugins that do things for weird build systems that shouldn't necessarily be upstreamed
<balloons> kyrofa, I believe I learned that last week, but it's a good reminder. Parts can be reused; not something I've played with yet
<sergiusens> balloons can you unsquashfs -l <snap> and show me the contents?
<kyrofa> balloons, I'm not talking about the parts, I mean plugins. Like you could have copied the godeps.py src and put it into parts/plugins/godeps.py and run snapcraft using the plugin from there
<kyrofa> balloons, you should add bzr as a build-package on this, by the way
<kyrofa> balloons, but yeah, things look good
<sergiusens> kyrofa standup
<kyrofa> sergiusens, finding headphones
<balloons> sergiusens, sure
<balloons> kyrofa, add bzr as a build-package for juju?
<kyrofa> balloons, indeed, some of the godeps pull via bzr
<balloons> kyrofa, ohh.. good catch
<balloons> sergiusens, http://paste.ubuntu.com/21927350/
<balloons> kyrofa, right, you discovered that by running in the lxc container I'd guess :-)
<kyrofa> balloons, you got it. cleanbuild (or running on LP) would discover that as well
<balloons> right -- I hope to have LP build it
<balloons> I need to look into how that works
<SamYaple> sergiusens: regarding https://github.com/snapcore/snapcraft/pull/707 , what behaviour would that be changing?
<mup> PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
<SamYaple> sergiusens: os.getcwd() should always be self.sourcedir right?
<sergiusens> SamYaple you saw my PR?
<SamYaple> sergiusens: i see all PRs
<sergiusens> SamYaple yeah, for when using remote sources
<SamYaple> oh. ok that makes more sense
<sergiusens> SamYaple I was going to ask you if you minded updating with my
<SamYaple> ill update my constraints PR
<sergiusens> SamYaple thanks
<sergiusens> balloons thanks
<sergiusens> balloons was your intention to have all those binaries?
<sergiusens> build them even
<kyrofa> balloons, things have changed slightly since I wrote this, but it'll still be helpful: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<balloons> sergiusens, an excellent question. I want juju, jujud, juju-metadata, juju-upgrade-mongo
<SamYaple> sergiusens: hitting C901, pep8 complexity on _pip()
<SamYaple> :/
<balloons> sergiusens, and sometimes I don't want jujud
<SamYaple> sergiusens: let me refactor it, but one of us will have to rebase
<SamYaple> sergiusens: if you remove the python2 changes from your PR i can incorprate them in mine
<mup> PR snapcraft#691 closed: Add godeps plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/691>
<kyrofa> \o/
<sergiusens> SamYaple I have static conflicts and integration test conflicts
<sergiusens> SamYaple so I need to look at those for a bit
<sergiusens> SamYaple that means, I will rebase
<nacc> so I've got a fairly simple python script in snap, and sys.getfilesystemencoding() is reporting 'ascii'. This is leading to issues with subprocesses, which are unable to parse UTF8 (aiui). Is this a limitation of squashfs? Any suggested workarounds?
<nacc> as far as I've been able to tell, setting LC_ALL or LANG or LC_CTYPE has no effect on the sys.getfilsystemencoding() value
<kgunn> jdstrand: so if my interface is "autoconnect" for mir, does that mean both the server side and the client side are autoconnect?
<mup> Bug #1609045 changed: running conjure-up -h results in the snap re-execing itself over and over <conjure> <Snapcraft:New> <https://launchpad.net/bugs/1609045>
<stokachu> sergiusens: ^ just moved that over, feel free to close it if it's going in the next snapcraft release
<stokachu> kyrofa: ^ not sure if you're also a maintainer
<kyrofa> stokachu, what about the directory creation to be investigated by zyga? Do you want that?
<stokachu> kyrofa: ah, im not entirely sure what sergiusens was referring to
<kyrofa> stokachu, that was Chipaca, from the bug. If this is referring to the python shebang lines, indeed this is a dupe. But it also sounds like there's a snapd bug there
<stokachu> kyrofa: ok i think it'll be best if i get with sergiusens and create a new bug for snapd
<stokachu> so they don't get mixed
<kyrofa> stokachu, alright, I'll dupe
<stokachu> thanks
<kyrofa> stokachu, thank you!
<jdstrand> kgunn: the 'permanent' slot or plug policy is generated unconditionally. auto-connect true will auto-connect a snap that slots: [ mir ] to all snaps that plugs: [ mir ]
<tianon> I wish "snappy-debug.security scanlog" supported colors somehow so the output was easier to visually skim O:)
<tianon> anyone know where I'd report such a "feature request" for that specific snap? :)
<kgunn> jdstrand: what did you mean by "The connected plug should actually be 'common'." in terms of a change?
<tianon> (in case anyone else is interested, if you don't need the suggestions that "scanlog" provides, I've been having reasonable success with "dmesg --follow --color=always | grep --color=none 'audit.*docker'" for colored audit logs that are also single-line and way easier to just skim)
<kyrofa> tianon, I'm not sure where the code for the snappy-debug snap is hosted, but jdstrand might be able to tell you how to log bugs against it
<tianon> sounds like all roads lead to jdstrand eventually :D
<kyrofa> tianon, indeed. jdstrand knows all things
<tianon> :D
<kyrofa> kgunn, where did he say that? He seems to be away, can I help?
<qengho> Okay, so I have a snap. I worked on it for a while, made some local data. I tested new revisions by installing local snaps, and it pulls my data forward each time. Great. Now I have a new version in the store and I want to refresh and I don't want to uninstall and lose that data.
<kyrofa> qengho, unfortunately, sideloaded snaps and snaps from the store, even while sharing names, are completely different snaps
<kyrofa> qengho, there's really no way to do what you ask
<qengho> kyrofa: I don't know what "are different" means when I can't "snap install" a version from the store.
<qengho> Store -> local was trivial. Once I install a local file with same name, it poisons everything?
<kyrofa> qengho, ah, you initially had a version installed from the store and you sideloaded over the top, now you want to go back?
<qengho> Can I uninstall that different snap, then?
<qengho> Yes.
<kyrofa> What does snap refresh <snapname> tell you?
<qengho> '''error: cannot refresh "tor-middle-relay": cannot refresh local snap "tor-middle-relay"'''
<kyrofa> qengho, let me try something, hold on
<qengho> I recall one of the promises of snaps was that one could "roll back" changes.
<kyrofa> qengho, indeed, the initial bits of that is in -proposed, but it's not yet complete
<qengho> kyrofa: I'm looking around, and I see only three xNN revision directories for data. Maybe I'm too far into the future since the store version?
<kyrofa> qengho, no revisions start without x?
<qengho> kyrofa: correct.
<kyrofa> Argh!
<kyrofa> There's obviously a bug here. I'm not sure what it is though. Should it be impossible to sideload over a store snap if you can't go back?
<kyrofa> I didn't think revision cleaning was released yet
<kyrofa> qengho, are you on -proposed?
<qengho> kyrofa: No, stable. Pretty sure.
<qengho> I don't know how to check.
<kyrofa> qengho, that's okay, then you probably aren't on proposed
<kyrofa> qengho, you have a few options. You can come back tomorrow a little earlier in the day when snapd devs are around who can answer your question, or you can log a bug to make it more asynchronous
<kyrofa> qengho, actually, you should send an email to the mailing list
<kyrofa> Since we're not sure where the bug lies
<qengho> kyrofa: I think the first bug is that I can't roll back.
<kyrofa> qengho, that's known though, and in progress
<qengho> kyrofa: The second bug is that installing a local package with the same name is possible. OR, that once a snap is installed locally, "snap refresh" never looks at the store for a replacement.
<kyrofa> qengho, indeed, it's the OR that suggests this would be a good mailing list post
<qengho> kyrofa: It's my 8AM, so I'll be around for a bit. I'll see about the mailing list.
<kyrofa> qengho, yeah, you're pretty much exactly opposite the rest of the team, so that may be your best bet
<qengho> kyrofa: I'm returning to the US tonight, so will be back in sync with them soon.
<kyrofa> qengho, ah! Where are you if I may ask?
<qengho> <- Desktop team guy, spent the summer in Taiwan.
<kyrofa> Nice
#snappy 2016-08-03
<mwhudson> Chipaca: did you get anywhere with dhcp fun?
<kyrofa> mwhudson, it's probably well past his EOD
<ahoneybun> cwayne: I think my issue was my wifi card
<ahoneybun> using a wire seems to be getting more success
<ahoneybun> built
<ahoneybun> but it is not intergating with Unity AppMenu
<ahoneybun> I did install with --devmode
<ahoneybun> nevermind you updated it
<mwhudson> where is the vcs for ubuntu-core-config?
<ahoneybun> jdstrand: any info on LP: #1590679
<mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679>
<dholbach> hey hey
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<dorche> hi
<Odd_Bloke> kyrofa: This is QT5, yeah. I tried using the desktop/qt5 part, but I get a Python encoding error (for which a bug is already filed).
<seb128> oh, mvo is back
<seb128> mvo, hey :-)
<mwhudson> good morning europe
<mvo> hey seb128
<mvo> hey mwhudson, good morning!
<seb128> hey mwhudson
<seb128> mvo, howa re you?
<mvo> seb128: thanks, good, how are you? a gazillon of mail and tasks :)
<seb128> mvo, can you have a look to https://code.launchpad.net/~seb128/livecd-rootfs/snap-hooks-tweaks/+merge/301881 ? I think the duplicated <<EOF was a mistake you added it with a string change and copied over
<seb128> mvo, I'm good thanks :-)
<mvo> seb128: nice catch, thank you!
<seb128> mvo, yw!
<seb128> mvo, do you have any idea when we are going to get an ubuntu-core update in the stable channel? the current version still doesn't have the xdg-open script
<mvo> seb128: it is planed for this week, we are waiting for 2.11 in xenial-updates before we do the update but that is in propsoed now, so it can go to updates today or tomorrow and then we create a image with that
<mvo> eh
<mvo> a core snap :)
<seb128> mvo, also I think your update-desktop-database fix doesn't work, did you test it?
<seb128> oh, I didn't notice we had 2.11 landed in proposed
<seb128> going to install and test
<mvo> seb128: it does not work in what way?
<seb128> but reading the commit I think it's not working, calling update-desktop-database without argument seems to not update /var/lib/snap/...
<seb128> I think you need to call it with that dir as arg
<seb128> at least if I do sudo update-desktop-database I don't get the cache generated
<mvo> seb128: oh, hrm, ok. happy to fix that
<seb128> I can do a PR if you want
<seb128> let me install 2.11 and test
<seb128> do I need to reboot to load the new version?
<seb128> or can I systemctl restart somethin?
<mvo> seb128: it should get restart ed automatically iirc
<seb128> k, let's see
<seb128> mvo, danke
<mvo> seb128: its really only doing that, update-desktop-database, if it needs more, a PR is most welcome
<mwhudson> Chipaca, ogra_: fwiw i installed a hacked snappy into an image and confirmed that nothing matches /sys/class/net/eth* when snap firstboot runs for me
<mwhudson> lool: hey i just sent you a mail, i'll be around for the next 30 mins or so if by any chance you want to chat about it
<lool> mwhudson: seen it
<lool> mwhudson: did you want to chat about it?  :)
<mwhudson> lool: well only if your answer is something other than "everything you say sounds fantastic" :-)
<lool> mwhudson: from what I've read so far it is  ;-)
<mwhudson> lool: excellent
<mwhudson> lool: all good then?
<mwhudson> oh heh you replied
<ogra_> mwhudson, well, like i said yesterday, i think that bit related to module loading
<mwhudson> ogra_: probably
<mwhudson> ogra_: i should file a bug and let someone who knows what they are doing tackle it i guess...
<ogra_> /sys is definitely there since the initrd ... but the subdir comes from the driver
<ogra_> mwhudson, do you see the module loaded at all on a failed boot ?
<mup> PR snapd#1620 opened: give a directory argument to update-desktop-database because the script <Created by seb128> <https://github.com/snapcore/snapd/pull/1620>
<ogra_> (i think kvm uses e1000)
<seb128> mvo, ^
<mwhudson> ogra_: well "dhclient eth0" works fine once booted, so yes?
<ogra_> hmm
<ogra_> and i guess the dir exists too at the time you run dhclient
<mvo> seb128: thanks, I have a look
<mwhudson> ogra_: yeah
<seb128> mvo, is replacing the /usr/lib/snapd/snapd binary enough for testing (and restarting the service)?
<mvo> seb128: yes
<mup> Bug #1609322 opened: snap firstboot can run before /sys/class/net/ is populated <Snappy:New> <https://launchpad.net/bugs/1609322>
<seb128> mvo, so hold on, seems not work at runtime, looking a bit more
<mvo> ok
<ogra_> mwhudson, how did you find that /sys/class/net/eth* isnt there ? i assume you have some ls sprinkled over some start scripts ? if so, could you do the same with lsmod instead ?
<ogra_> so we see when the modules get loaded
<mwhudson> ogra_: i added code to snapd/firstboot/firstboot.go
<mwhudson> ogra_: i can try games with lsmod too (tomorrow)
<ogra_> cool ... (in case i get to it before you i'll note it on the bug)
<seb128> mvo, is there a trick like compiled binaries or a cache or something? I don't understand my snapd log has a string which isn't in the binary even after being restarted
<seb128> mvo, snapd[8273]: desktop.go:177: DEBUG: update-desktop-database successful
<seb128> but
<seb128> $ strings /usr/lib/snapd/snapd | grep successful
<seb128> update-desktop-database successful on %s
<seb128> I added the parameter for debugging but my code doesn't seem to be used?!
<ogra_> mvo, can you share the kernel packages with me in the store ?
<ogra_> also u-d-f doesnt like the dragoboard gadget it seems
<ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo ./ubuntu-device-flash core 16 --channel=edge --os=ubuntu-core --kernel=dragonboard-kernel --gadget=dragonboard -o test-dragon.img
<ogra_> cannot use "dragonboard", must be one of: ["canonical-i386" "pc" "canonical-pc" "canonical-pi2" "canonical-dragon" "beagleblack"]
<timothy> hi, are zyga on vacation this week?
<mvo> seb128: oh, it may restart itself from the core snap, SNAP_REEXEC=0 is the trick, easiest for testing is probably to follow the README.md (there is a subsection on testing)
<mvo> ogra_: please check the latest u-d-f from the all-snaps/16 subdir
<mvo> ogra_: what kernel packages are missing, happy to share them with you
<mvo> ogra_: also, how can I get a serial console for the pi2? I get to starting kernel and then nothing, iirc you menitoned some dtb issues?
<mvo> ogra_: this blocks me right now because I can not debug the early boot on my pi2 with the latest pi2 test image
<mvo> ogra_: see also telegram, there are some fixes (and questions). sideload should work again
<seb128> mvo, even after a reboot still the same, I don't understand what's going on...
<seb128> I did string on the different binary on disk and they have the updated string
<seb128> how can the debug output have the old one?
<ogra_> mvo, i dont have any access to the new -kernel ones only to the old canonical- ones
<ogra_> mvo, i can dig up a uboot.bin that has serial for you ... gimme a bit
<mvo> seb128: its re-execing to ubuntu-core
<mvo> seb128: its a "feature" but I can see that its confusing
<mvo> ogra_: great, thank you
<seb128> mvo, meaning?
<mvo> ogra_: I add you to all the kernels now
<seb128> mvo, what file/version do I need to update and how?
<ogra_> mvo, and if you want my attention on telegram, please ping directly, i dont get any access to super-groups from the ubuntu phone client (which is the only thing permananently on telegram i have)
<mvo> seb128: there is a snapd in /snap/ubuntu-core/current/usr/lib/snapd/snapd which will be used if its there (and has a higher version)
<seb128> oh
<mvo> seb128: the easiest way to test your change is to follow the readme in the github repo
<seb128> lol
<seb128> mvo, thanks
<mvo> seb128: it should be short and sweet (the testing section)
<ogra_> mvo, also, there is still a base package (from a failed and overzealous renaming attempt) in the store that needs unpublishing
<ogra_> seemes we have at least one bug where people installed it :P
<mvo> ogra_: uff, I renamed it to base-delete-me
<ogra_> thanks :)
<mvo> ogra_: hm, so you don't see anything in the group at all? meeh, good to know
<ogra_> we really need an easy way for package owners to wipe their packages in the store ... my packagelist is so full of unpublished crap now
<mvo> ogra_: +100
<ogra_> (and owning 60 click packages in the store really doesnt help to keep the overview ... everything is on one page)
<seb128> mvo, k, going to teach me to read the README upfront next time ;-)
<seb128> mvo, thanks!
<seb128> mvo, change works btw, good to land ;-)
<mvo> seb128: !!! thank you
<seb128> yw!
<mup> PR snapd#1621 opened: store: fix buy method after some refactoring broke it <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1621>
<mup> PR snapd#1553 closed: cmd: support defaulting to the user's preferred payment method <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/1553>
<Cavan> My snap is running in devmode but not confiened anyway to check whats stopping it?
<qengho> Cavan: it will still log many messages if it tries to do too much. Check "dmesg" output.
<qengho> Cavan: Then install in confined mode, and try to run it. When it crashes, you find out why. If there's a seccomp abortion, "scmp_sys_resolver NNN" on the signal number you see in the log.
<qengho> Cavan: It's basically, "run it and see how it crashes."
<Cavan> quengho, do I literally type "dmesg" after trying to run the snap to trace the crash? Or in the directory?
<Chipaca> mwhudson, I didn't do anything with dhcp (not looking into this atm)
<Chipaca> mwhudson, did updating the before/after work in the end?
<mup> PR snapd#1622 opened: client, cmd/snap: use the new multi-refresh endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/1622>
<popey> I have a VPS I am using to build "in the cloud" and when I spin it up I only have a root account, no user. For speed, I just snapcraft as root. I know under normal circumstances "building as root" is ill advised, is that still the case with snapcraft, given confinement?
<popey> i.e. can I be lazy and build as root and be okay?
<ogra_> popey, the danger is that you mess up the host, from a snap POV it shouldnt matter if you run as root or not
<popey> i dont care about the host, i provisioned it just to build the snap
<ogra_> i thought so :)
<popey> and will destroy it afterwards :)
<ogra_> i.e. if you do a snapcraft build on LP it always runs as root
<popey> oh, well that's interesting data point :)
<Chipaca> is launchpad timing out (when commenting on a bug) for anybody else, or does it hate me in particular?
<mup> PR snapd#1596 closed: osutil: support both "nobody" and "nogroup" for grpnam tests <lp> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1596>
<mup> PR snapd#1590 closed: interfaces: add process-control interface (LP: #1598225) <lp> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1590>
<mup> PR snapd#1589 closed: interfaces: miscelleneous policy updates for default, log-observe, mount-observe, opengl, pulseaudio, system-observe and unity7 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1589>
<mup> PR snapd#1562 closed: many: cleanup/update rest.md; improve auth errors <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1562>
<mup> PR snapd#1586 closed: wrappers: set BAMF_DESKTOP_FILE_HINT for unity <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1586>
<mup> PR snapd#1602 closed: interfaces: add kernel-module interface for module insertion <Created by arges> <Conflict> <https://github.com/snapcore/snapd/pull/1602>
<mup> PR snapd#1620 closed: give a directory argument to update-desktop-database because the script <Created by seb128> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1620>
<mup> PR snapd#1570 closed: snapstate: remove artifacts from a snap try dir that vanished <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1570>
<mup> PR snapd#1565 closed: interfaces: also allow rfkill in network_control <Created by lpotter> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1565>
<mup> PR snapd#1566 closed: interfaces/builtin: read perms for network devices in network-observe <Created by jaymell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1566>
<seb128> is snappy giving access to the dbus session bus by default?
<seb128> or is there an interface needed for that? (which one?)
<kyrofa> seb128, I think parts of it, depending on interfaces used (e.g. unity7)
<seb128> kyrofa, that user on the list gets a "Failed to open connection to "session" message bus: Failed to connect to socket /tmp/dbus-OQWDAcdbVG: Permission denied "
<seb128> I wonder if that's just a missing interface, he doesn't use any
<seb128> but also unsure which one to recommend
<seb128> unity7 is not very restrictive and not needed there
<kyrofa> seb128, indeed. Hold on, the mailing lists changed again so my filters are garbage. I'm redoing them now then I can see what you're talking about
<kyrofa> seb128, ah, the xdg one?
<seb128> yes
<kyrofa> seb128, xgd-open is used for links, right? Click a link within the snap, want firefox to open?
<seb128> correct
<seb128> but the dbus question is orthogonal
<seb128> he did a minimal part to test
<seb128> kyrofa, but yeah, basically the command he uses does "dbus-send  --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1" "
<kyrofa> Indeed, just making sure I'm clear on what's happening here
<seb128> and he got an access denied to the session bus
<kyrofa> Yeah I don't think there are any interfaces which grant generic access to the session bus
<seb128> k, I replied suggesting that he tries unity7
<seb128> thanks
<kyrofa> Yeah that should definitely cover it. However, does the SRU of xdg-open solve this issue for him? He'd still need that interface, no?
<kyrofa> seb128, also, while I understand he was just testing it out, would xdg-open ever be utilized from a non-gui application?
<seb128> yes
<seb128> it's a shell script and is used in random places
<seb128> including small sysadmin scripts and command lines tools
<kyrofa> Can you give me an example? I wonder if we need a simpler interface that includes it
<seb128> kyrofa, http://sources.debian.net/src/mc/3:4.8.17-1/misc/ext.d/image.sh/?hl=9#L9
<seb128> kyrofa, from a random search on codesearch.debian.net
<kyrofa> Huh, interesting
<seb128> debian reportbug is in the list
<seb128> kyrofa, http://sources.debian.net/src/lptools/0.2.0-2/bin/lp-review-notifier/?hl=160#L160
<kyrofa> mvo, what do you think about that? Should we be recommending cli applications that utilize xdg-open to use the unity7 interface, or would it be better to have a more fine-grained interface?
<kyrofa> (I ask you since you were the last person I talked to about xdg-open, but jdstrand may be better)
<seb128> could make sense to have an "url-handler" interface
<seb128> xdg-open does mailto: also
<jacekn> I am trying to snap python project and I need to get config.yml from the source repo to parts/<part>/install (python setup tools don't put it there). How can it be done? I can add filesets in "stage" and "snap" but not "build" phases
<Spads> jacekn: organise?
<jacekn> Spads: explain?
<Spads> jacekn: it's a stanza that lets you shuffle file locations around, but it may be the wrong part of the process for this
<Spads> http://snapcraft.io/docs/build-snaps/parts
<Spads> there's filesets and organize(sic)
<jacekn> Spads: I'l have a look but it's not that simple. The file is in the source dir but setuptools don't copy it to parts/<part>/install
<Spads> right
<Spads> and really this is a problem I've had a few times
<Spads> where the install step wasn't fully automated
<kyrofa> Spads, if the build system doesn't install it really the only way to do it is to have another part that uses the copy plugin and the same source and places the config where it needs to go
<Spads> and I could set up a second part to go through the whole build process a second time
<Spads> which seems pointless
<Spads> when really what we usually need is "build system X, plus a copy"
<kyrofa> Spads, something like this: http://pastebin.ubuntu.com/22031026/
<jacekn> kyrofa: ok that will work for me I think. It's suboptimal but will do the job
<mvo> kyrofa: jdstrand is probably better
<Spads> yeah
 * jacekn thinks "ship that sample config file with my build" will be pretty common use case
<Spads> The other common use case I'm still trying to work out is the "copy this example config file to $SNAP_USER_DATA before first run"
<kyrofa> jacekn, indeed, which is why build systems typically take care of that
<jdstrand> kyrofa: how safe is xdg-open? I mean, if everything is expected to be able to use it and it is safe, could just add it to the default template
<Spads> jacekn: so one of the things about snappy is that the real goal is to get upstreams to adopt it, so if we can add that file to the build system and get the snapcraft.yaml merged in, that's better
<kyrofa> jdstrand, seb128 or attente can probably answer that better than me
<jacekn> Spads: kyrofa: ok thanks, I'll use the workaround and try to improve upstream
<kyrofa> jdstrand, but it causes browsers or mailers to open... so off the cuff I'd say that doesn't sound like a great thing for everything to have blanket access to
<jdstrand> kyrofa, seb128: there is also the question of if xdg-open is in all snaps images
<kyrofa> Indeed, good question
<mup> PR snapd#1621 closed: store: fix buy method after some refactoring broke it <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1621>
<seb128> jdstrand, kyrofa, we need to MIR it so I guess it's going to go through a security review, but it's basically an hundred line of C and small service getting on the bus and calling g_app_info_launch_default_for_uri() on the uri you gave to it
<jdstrand> kyrofa: well, that is the safety question. the one on touch was safe and we had it in the default policy
<seb128> jdstrand, kyrofa, the script in the ubuntu-core image is just calling "dbus-send  --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1""
<seb128> then the small service is on the system side
<seb128> which get the message and call the glib function to open the uri provided in the default handler
<jdstrand> if it makes sense for all snaps and iot, I would suggest adding it to the default template. if it does not, I think I would suggest adding a new interface: 'url-handle' (not 'handler')
<jdstrand> if someone submits a PR, then the interfaces team can discuss
<seb128> k
<seb128> unsure if it makes sense for iot
<seb128> but it's used by sysadmin in scripts and in command line tools
<jdstrand> if it can be used in a cli environment, then it might make sense. if not, I would say no
<seb128> it can, it only calls to your default handler
<seb128> that could be links
<mup> PR snapd#1612 closed: interfaces: add /proc/version_signature to appamor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1612>
<mup> PR snapd#1617 closed: many: move to purely hash based key lookup and to new key/signature format (v1) <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1617>
<jdstrand> I suggest submitting a PR with it in the default template then (that will be easier to implement), then if the fuller interfaces team wants it in a separate interface, then moving it out is easy
<mup> PR snapd#1611 closed: tests: add locale-control write spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1611>
<mup> PR snapd#1607 closed: changed snapd to snap <Created by liu-xiao-guo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1607>
<mup> PR snapd#1608 closed: tests: add snapd-control interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1608>
<mup> PR snapd#1601 closed: partition: clear snap_try_{kernel,core} on success <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1601>
<mup> PR snapcraft#708 opened: Add support for use of pip constraints <Created by javacruft> <https://github.com/snapcore/snapcraft/pull/708>
<seb128> jdstrand, thanks, going to do that
<mup> PR snapd#1623 opened: interfaces: udev: avoid doubled rules and put all in a per snap file <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
<morphis> zyga: ^^
<morphis> zyga: took the time and implemented that now
<morphis> joc_: ^^
<arges> jdstrand: hey for https://github.com/snapcore/snapd/pull/1618, adding this to the hardware-observe seems fine
<mup> PR snapd#1618: interfaces: add lscpu to apparmor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1618>
<arges> jdstrand: for https://github.com/snapcore/snapd/pull/1612 is there an existing interface i should add that to?
<mup> PR snapd#1612: interfaces: add /proc/version_signature to appamor template <Created by arges> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1612>
<jdstrand> arges: ./interfaces/apparmor/template.go has a typo using @{PROC}/@{pid}/version_signature and @{PROC}/@{pid}/version. clearly, no one has complained about the currect path in the default template, so how about remove from there and add to system-observe?
<jdstrand> I commented in the 1612 PR
<arges> jdstrand: i was wondering about that extra @{pid} in the path!
<jdstrand> I half suspect it was a java app that was looking in the wrong place
<arges> jdstrand: ack I can do that, and I'll just submit them as three separate patches into one pull-request
<jdstrand> arges: sounds great
<jdstrand> arges: feel free to ping me
<seb128> mvo, if you have some review slots still, https://code.launchpad.net/~seb128/livecd-rootfs/snap-xdg-defaults/+merge/301917 ... that's creating a .desktop/mimetype registration so clicking on http/mailto/help urls in gnome software know what handle to use
<imexil> Hi. I was wondering, are there any plans to make  snapd also available to older Ubuntu versions. Like 14.04 LTS or is this technically not possible?
<mup> PR snapd#1624 opened: Use `cp -aLv` instead of `cp -a` (no symlinks on vfat) <Created by mvo5> <https://github.com/snapcore/snapd/pull/1624>
<ogra_> imexil, not as long as there is a systemd requirement
<mup> PR snapd#1610 closed: store: soft-refresh discharge macaroon from store when required <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1610>
<imexil> ogra_: OK
<mvo> seb128: oh, nice! thank you
<seb128> mvo, yw!
<mup> PR snapcraft#618 closed: parser - Support .snapcraft.yaml files <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/618>
<Beret> any snappy folks around?
<mup> PR snapcraft#662 closed: Update the Standards-Versions and the Vcs* tags in the debian/control file <Created by tsimonq2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/662>
<mup> PR snapd#1625 opened: asserts: make account-key's `until` optional to represent a never-expiring key <Created by emgee> <https://github.com/snapcore/snapd/pull/1625>
<mup> PR snapcraft#688 closed: Strip common path prefixes from linkname as well as name when extracting a tarfile <Created by mhall119> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/688>
<mhall119> \o/
<mup> PR snapd#1624 closed: boot: use `cp -aLv` instead of `cp -a` (no symlinks on vfat) <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1624>
<Cavan> I can run my snap in devmode, but when confined im getting "[28234.099513] audit: type=1400 audit(1470242246.729:353): apparmor="DENIED" operation="exec" profile="snap.zeppelin.zeppelin" name="/usr/bin/nohup" pid=21467 comm="zeppelin-daemon" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0" through 'dmesg'
<Spads> Cavan: does it need unity7?
<Spads> some programs hit dbus walls just trying to tell the unity dock they're there and have an icon etc
<Spads> I found adding the unity7 plug helped there
<Spads> oh it's a daemon
<Spads> as you were!
<Cavan> Spads, aha thanks anyway!
<mup> PR snapcraft#669 closed: Add detection for an existing `.snapcraft.yaml` file before running `snapcraft init` <Created by tsimonq2> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/669>
<Odd_Bloke> At the sprint last week, oneshots were mentioned as being supported; snapcraft rejects "daemon: oneshot".  Is there something else I should be doing?
<jdstrand> Cavan: that came up yesterday. please file a bug at https://bugs.launchpad.net/snappy/+filebug and add the 'snapd-interface' tag and we'll allow calling nohup
<sergiusens> Odd_Bloke in is in master, no as a deb yet
<sergiusens> *not
<Odd_Bloke> sergiusens: OK, cool, so long as I'm not remembering things that aren't true. :p
<Cavan> jdstrand, is there anything I can do in the meantime to make it work?
<sergiusens> Odd_Bloke in case you want to git clone and just run from master https://github.com/snapcore/snapcraft/blob/master/HACKING.md#project-layout
<sergiusens> just use the snapcraft in that bin
<sergiusens> and yes, it was added for lxd
<sergiusens> now adding timers and socket activation
<Odd_Bloke> Cool!
<Odd_Bloke> I'll probably have a few more (non-lxd) things incoming at some point.#
<Odd_Bloke> We build Ubuntu cloud images using a chroot.  This chroot (obviously) does not have snapd running in it, which means that running 'chroot foo snap install ...' produces a "dial unix /run/snapd.socket: connect: no such file or directory" error.  How can we go about installing snaps within a chroot?
<Odd_Bloke> slangasek: Have you done any relevant thinking around this for doing things in livecd-rootfs/buildds?
<Cavan> jdstrand, is there anything I can do in the meantime to make it work? (Sorry if I already sent this I disconnected)
<sergiusens> Odd_Bloke preinstall snaps instead of fetching/caching them?
<Odd_Bloke> sergiusens: Yeah, this is looking at replacing deb packages that we ship installed in images with snaps.
<Odd_Bloke> (So is separate from pre-caching snaps that users might want to install themselves)
<sergiusens> ah, ic
<sergiusens> Odd_Bloke so ogra_ is the image builder master hacker
<sergiusens> he might have some insight
<Odd_Bloke> OK, he's in my sort of timezone, so I can bug him in the morning.
<Odd_Bloke> ogra_: In the meantime, if you want to bless me with some wisdom around the above, it would be much appreciated. ;)
<mup> PR snapd#1626 opened: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1626>
<sergiusens> elopio mind updating https://github.com/snapcore/snapcraft/pull/656/files ?
<mup> PR snapcraft#656: Use requirements files in travis tests <Created by elopio> <Conflict> <https://github.com/snapcore/snapcraft/pull/656>
<sergiusens> Odd_Bloke heh, ogra_ is awake at weird hours though ;)
<mup> Bug #1609499 opened: move interface-specific OS mounts to interface.SecurityMounts <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1609499>
<mup> Bug #1597842 changed: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <Snappy Launcher:In Progress by jdstrand> <Snappy:Invalid> <https://launchpad.net/bugs/1597842>
<elopio> sergiusens: done. Let's see if travis is still happy.
<TaleOfThor> Does anyone know when a snappy version for Raspberry pi 3 will be released?
<kyrofa> TaleOfThor, ogra_ will know best, but I believe you can use the rpi2 image if you're okay with 32-bit
<kyrofa> 64bit is harder since the firmware blobs are only 32 (right ogra_?)
<mup> Bug #1609509 opened: No "slot" exists that allows read-only access to any file <Snappy:New> <https://launchpad.net/bugs/1609509>
<niemeyer> morphis: You got some feedback on snapd#1623
<mup> PR snapd#1623: interfaces: udev: avoid doubled rules and put all in a per snap file <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
<morphis> niemeyer: thanks
<mup> PR snapcraft#656 closed: Use requirements files in travis tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/656>
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Long time no speak!
<niemeyer> jdstrand: I'm sure we have a vast number of pending topics to talk about :)
<niemeyer> jdstrand: But this ping is a minor one.. :)
<niemeyer> jdstrand: snapd#1626 needs a go fmt
<mup> PR snapd#1626: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1626>
<jdstrand> niemeyer: hi!
<jdstrand> niemeyer: whoops, let me fix that, sorry
<niemeyer> jdstrand: Thanks!  Trying to cut down on that never ending list of PRs
<jdstrand> niemeyer: yeah, lots of outcomes, bugs, etc, etc :) A lot of PRs is better than no PRs though :)
<niemeyer> jdstrand: I should stop reviewing then!
<jdstrand> lol
<jdstrand> that's one way to look at it I guess :)
<mup> PR snapd#1627 opened: squashfs: do not install a snap if its already exists and is valid <Created by mvo5> <https://github.com/snapcore/snapd/pull/1627>
<tianon> kyrofa, TaleOfThor: proper 64bit rpi3 kernels are still scarse and WIP :)  if you want ubuntu classic, I've been using the one Ryan Finnie maintains linked from https://wiki.ubuntu.com/ARM/RaspberryPi on my pi3 with good success (including snap/snapcraft), but generally yeah, rpi2 images are the current "state of the art"
<jdstrand> niemeyer: fyi, committed (it's going through the various tests now)
<powersj> Going through the hello world tour and there is mention of a --broad flag, however when I use it with `snap find` I get unknown flag
<mup> PR snapd#1627 closed: squashfs: do not install a snap if its already exists and is valid <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1627>
<niemeyer> jdstrand: Thanks!
<snappy_> Hi
<snappy_> Can anyone help me with installing shout in snappy? I'm getting an error saying "unsupported protocol scheme"
<sergiusens> snappy_ snap install shout
<snappy_> it says snap command is not found
<snappy_> we're using the 15.04 version
<mup> PR snapd#1628 opened: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1628>
<mwhudson> Chipaca: no, i didn't try your before= suggestion, maybe today :)
<mup> PR snapd#1626 closed: interfaces: add system-trace interface LP: #1600085 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1626>
<mup> PR snapd#1597 closed: tests: add hardware-observe spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1597>
<bladernr> Hey, noob question... how do I install a snap locally?  I just built a snap following the Your First Snap walkthrough.
<bladernr> Now how do I install it?
<mup> PR snapd#1574 closed: tests: add network-control interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1574>
<bladernr> webdm is up, I found something that hinted at scping my snap to ubuntu@webdm.local.  That fails on my system though :/
<kyrofa> bladernr, webdm is a bit in flux. You should probably just use the device IP if you have it
<bladernr> no device, it's localhost?
<kyrofa> bladernr, but yeah, scp it to the device and just install it via snap install <local file>
<bladernr> hrmmm... oh... ok
<bladernr> doh
<kyrofa> bladernr, oh well then, skip the scp step and just snap install it!
<bladernr> hahaha...
<bladernr> thanks, I was overthinking it
<kyrofa> bladernr, I mean, you could scp if you wanted to. An encrypted-in-transit, slower cp
<kyrofa> :P
<bladernr> Hah!
<kyrofa> But yeah, you got it
<mup> PR snapd#1629 opened: daemon,docs: drop license docs and error kind <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1629>
<mup> PR snapd#1569 closed: Drop license documentation and error kind - this has not been implemented <Created by robert-ancell> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1569>
<mup> PR snapd#1628 closed: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <https://github.com/snapcore/snapd/pull/1628>
<sergiusens> elopio what is the story with https://github.com/snapcore/snapcraft/pull/593 ? I give the ball to you to say it is ready to merge ;-)
<mup> PR snapcraft#593: git demo snap update - Bug 1595229 <Created by stub42> <Conflict> <https://github.com/snapcore/snapcraft/pull/593>
<sergiusens> kyrofa do we still need this https://github.com/snapcore/snapcraft/pull/497 ?
<mup> PR snapcraft#497: Catkin plugin: Enforce C.UTF-8 locale <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/497>
<kyrofa> sergiusens, yes, that snapd bug is taking too long to fix and people are starting to ask questions
<kyrofa> sergiusens, particularly because we're recommending people test on desktop now
<sergiusens> kyrofa so why did the test fail? if due to nothing important let's just get it in
<kyrofa> sergiusens, checking now
<elopio> sergiusens: it's missing at least the removal of the other git test.
<elopio> and well, it has a conflict.
<sergiusens> elopio can you make the comment there please?
<sergiusens> kyrofa also, is this one still relevant after your source management change https://github.com/snapcore/snapcraft/pull/645 ?
<mup> PR snapcraft#645: If "source: .." do not copy the current directory into itself <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/645>
<kyrofa> sergiusens, actually yeah, my change might have caused that :(
<kyrofa> We need to have a test for that case
<sergiusens> kyrofa well sheppard that in then ;-)
<kyrofa> Okay
<Pharaoh_Atem> does anyone know who created snap?
<Pharaoh_Atem> like I know Alexander Larsson created flatpak/xdg-app, but who created snap?
<sergiusens> kyrofa fwiw, I think it was broken before
<kyrofa> elopio, is http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-snaps-cloud/201/console just an infrastructure failure?
<elopio> kyrofa: yes, something weird happened during the reboot of the testbed.
<kyrofa> elopio, did the tests all run, then? Or did it fail partway through and I should re-run them?
<tsimonq2> sergiusens: I would much rather " instead of ' :P
<tsimonq2> but yeah yeah I have to be consistent... :P
<elopio> kyrofa: rerun. Only the unit tests during the package build ran.
<kyrofa> tsimonq2, gotta stick with the standard established in the project :)
<tsimonq2> kyrofa: :P
<kyrofa> elopio, good deal, thank you
<sergiusens> tsimonq2 consistency makes things easier to read
<elopio> sergiusens: this one is up-to-date, and all tests are passing: https://github.com/snapcore/snapcraft/pull/687
<mup> PR snapcraft#687: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
<elopio> it will just need a change in the script to run the staging store tests. cprov: can you please take a look?
<elopio> you'll have to add: TEST_STORE=staging.
<sergiusens> elopio lgtm. I will wait for cprov
<sergiusens> elopio nice cleanup!
<mup> PR snapd#1630 opened: daemon: stop using group membership as succedaneous of running things with sudo <Created by chipaca> <https://github.com/snapcore/snapd/pull/1630>
<mup> PR snapcraft#497 closed: Catkin plugin: Enforce C.UTF-8 locale <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/497>
<sergiusens> kyrofa ^
<kyrofa> sergiusens, thanks!
<mup> PR snapcraft#703 closed: Update the completion list of commands <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/703>
<mup> PR snapcraft#703 closed: Update the completion list of commands <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/703>
<mup> PR snapcraft#686 closed: Add missing dependencies <Created by cholcombe973> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/686>
#snappy 2016-08-04
<sergiusens> kyrofa one more look at https://github.com/snapcore/snapcraft/pull/707 maybe?
<mup> PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
<sergiusens> kyrofa if you are still around can you do a review of this for me ? https://github.com/snapcore/snapcraft/pull/689
<mup> PR snapcraft#689: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
<mup> PR snapcraft#709 opened: Improve the go plugins usability <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/709>
<mup> PR snapd#1631 opened: client, osutil: chown the auth file	 <Created by chipaca> <https://github.com/snapcore/snapd/pull/1631>
<trijntje> Hi all, I'm looking for a snap that requires the user to accept a license before installing. Is there a way to browse all snaps in the ubuntu store and filter for license?
<mup> PR snapd#1632 opened: Do not install a snap if it is already valid <Created by mvo5> <https://github.com/snapcore/snapd/pull/1632>
<dholbach> hey hey
<didrocks> good morning dholbach
<dholbach> salut didrocks
<seb128> hey dholbach, re didrocks
<dholbach> salut seb128
<mup> PR snapd#1561 closed: many: remove integration-test coverage metrics  <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1561>
 * dholbach relocates to the office, bbiab
<Odd_Bloke> ogra_: o/ I was told to bug you about advice on how to install a snap within a chroot; any ideas?
<brendand> is vivid really the latest image available for raspberry pi2?
<mup> PR snapd#1632 closed: Do not install a snap again if it is already valid <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1632>
<mvo> brendand: yes, but we are working (hard) on updated images, the goal is to have them today
<brendand> mvo, what a nice coincidence :)
<brendand> mvo, so there must be something i can test ;)
<mvo> brendand: the branch above (#1632) was the last blocker we are/were aware of, so once that is fully build I will create a new test image, if nothing goes wrong  ~30min to 1h
<mvo> (then the test image is ready for â¦ testing :)
<brendand> hth
<mup> PR snapcraft#708 closed: Add support for use of pip constraints <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapcraft/pull/708>
<mup> PR snapd#1572 closed: interfaces: add bluetooth-control interfaces <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1572>
<mwhudson> mvo: hey, i was wondering, are there any other expected users for snap create-user other than first boot stuff?
<mwhudson> mvo: it would be convenient if it reported the new user's username in a easier to parse form :-)
<mvo> mwhudson: happy to store it in whatever way you want
<mvo> mwhudson: first-boot is the big use-cas
<mwhudson> mvo: in the longer term, it would also be good to know if the user had ssh keys or not
<mwhudson> mvo: so, i dunno, yaml on stdout or something?
<ogra_> Odd_Bloke, uuh, no idea, i dont think that can work
<mvo> mwhudson: I can give you a switch for this I think, probably not as default
<ogra_> a container might
<mwhudson> mvo: yeah, makes sense
<mwhudson> mvo: i wonder if "sudoer or not" should be a switch too?
<mvo> mwhudson: yeah, probably
<Odd_Bloke> ogra_: Oh. :(
<mwhudson> mvo: should i comment on the pr to this effect or do you remember when people badger you on irc? :)
<Cavan> I'm trying to set up an eviorment to get my snap to run in confined, I keep getting the error: Issues while validating snapcraft.yaml: Additional properties are not allowed ('environment' was unexpected)
<ogra_> Cavan, i'm not sure the environment handling has been released yet
<Odd_Bloke> ogra_: So is there currently a plan to handle pre-installing snaps in classic images built by the buildds?  (I'm guessing this is a pretty similar issue.)
<Cavan> I was following the 'https://bugs.launchpad.net/snappy/+bug/1583259' but if its not released yet thats fair enough. Any Idea when it will be? can't complete my snap because it wont run in confined
<mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <click-reviewers-tools (Ubuntu):Fix Released>
<mup> <click-reviewers-tools (Ubuntu Xenial):In Progress> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
<mvo> mwhudson: a short comment (or irc paste) of this in the PR would be great, sometimes I have the memory of a goldfish
<ogra_> Odd_Bloke, that would likely happen at install time, not prior to it
<Odd_Bloke> Ah, OK.
<Odd_Bloke> That makes things awkward in the cloud image world. :/
<mwhudson> ogra_: hey did you see my mail about making things writable?
<mwhudson> things == /etc/netplan, /var/lib/firstboot or something
<ogra_> mwhudson, yeah, i'll take care of the change today
<mwhudson> ogra_: yay
<Cavan> So is the enviorment handling realeased, I'm confused sorry aha?
<ogra_> mvo, dragon fails to start the login service again and cloud-init falls on its face too ... was it szupposed to work yet ?
<ogra_> Cavan, if you mean snap-confine, i think it is still sitting in xenial-proposed
<ogra_> https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.4
<ogra_> yeah
<Cavan> ogra_, sorry what does 'xenial-proposed' mean?
<mvo> ogra_: not yet, soon
<ogra_> Cavan, the test archive where things go for testing before they go into xenial-updates
<ogra_> mvo, ah, k ...
<mvo> ogra_: in ~30min maybe
<ogra_> no huryy, just wanted to know if i should expect anything :)
<ogra_> mvo, when exactly do we mount the snaps, are we sure that happens only after resizing ?
 * ogra_ would like to know why the first boot fails differently to the others
<Cavan> ogra_, ah thanks. Is there anyway around my 'calling nohup' problem until then or should I just wait?
<ogra_> Cavan, the xenial task of that bug is still "In Progress" :)
<mvo> ogra_: please give dragonboard a go again
<mvo> ogra_: I will not do images for now because we are still missing the final gadget/kernel name
<ogra_> mvo, yeah ... dobnt forget they should go to cdimage (which means we can definitely not use it anymore for builds now until we rip out the publishing)
<ogra_> hmm, pi2 bootd very slow but not a single failure yet
<mvo> ogra_: yeah, happy to push them to cdimage once we had a chance to test them a little bit more
<mvo> ogra_: cloud init makes it slow
<mvo> ogra_: same here fwiw, no error, I'm re-doing the amd64 image now
<ogra_> well, it prints:
<ogra_>          Mounting Mount unit for ubuntu-core...
<ogra_> [  OK  ] Mounted Mount unit for ubuntu-core.
<ogra_> does it copy the snaps around ?
<mvo> ogra_: no, just mounts them to /snap/ubuntu-core/243324
<ogra_> (and yes, cloud-init starts before that but the output makes it look like the mount is super slow)
<ogra_> dragon is dd'ing ...
<mvo> cool
 * ogra_ snap installs htop on the pi
<ogra_> curious if the interfaces are actually there and working
<ogra_> yay, cool
<ogra_> works after connection system-observe
<ogra_> *connecting
<ogra_> nice ... the OS eats less than 50MB RAM ...
<ogra_> (when idling)
<ogra_> mvo, dragon looks pretty good, i'm at the login prompt
<ogra_> no networking indeed :/
 * ogra_ creates a manual /e/n/i.d entry and reboots
<ogra_> woah ... htop on the dragon shows 85MB ram usage on idle ...
<ogra_> mvo, so looks like both images are good here
<ogra_> hmm ...
<ogra_> i wonder if classic mode works
<sheh_> How can I update the ubuntu-core package without internet connection?
<ogra_> i dont think you can
<ogra_> you could try to snap install it from a local .snap file, but not sure that will work
<ogra_> WHEEE !
<ogra_> ubuntu@localhost:~$ sudo classic.shell
<ogra_> (classic)ubuntu@localhost:~$ uname -a
<ogra_> Linux localhost.localdomain 4.4.0-1022-snapdragon #25-Ubuntu SMP Fri Jul 22 22:11:20 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
<ogra_> (classic)ubuntu@localhost:~$
<ogra_> mvo, ^^^
<ogra_> we need to add more output to "sudo classic.create" ... it sits there for a long time very quietly before it starts to do anything
<ogra_> oh
<ogra_> and we need to make sudo work
<ogra_> (classic)ubuntu@localhost:~$ sudo apt-get update
<ogra_> sudo: no tty present and no askpass program specified
<timothy> ogra_: adding NOPASSWD in sudoers should fix it
<ogra_> timothy, yeah, but i want it to ask for a password ...
<ogra_> the wrapper script needs to properly mount /dev/pts
<ogra_> bug 1564369
<mup> Bug #1564369: sudo broken in latest classic <Snappy:Confirmed> <https://launchpad.net/bugs/1564369>
<mvo> ogra_: good stuff. I will upload that once we have final names
<ogra_> (it is a rergression)
<ogra_> /dev/pts needs its own mount in the script ... currently only /dev is bind mounted
<mvo> ogra_: let me upload a fix
<ogra_> hmm, there is more
<ogra_> logging in with "sudo SUDO_USER="" classic.shell" gets me a root shell ...
<mvo> ogra_: can you please try r5
<ogra_> but apt update falls over
<ogra_> 0% [1 InRelease gpgv 247 kB] [2 InRelease 43.0 kB/95.7 kB 45%]Couldn't create tempfiles for splitting up /var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-Err:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease
<ogra_> seems we are also missing some additional writable places
<ogra_> err
<ogra_> or not
<ogra_> Could not execute 'apt-key' to verify signature (is gnupg installed?)
<ogra_> i guess we neerd that in the tarball
<ogra_> oh
<ogra_> apt-get works, just apt doesnt
<ogra_> thats interesting
<mvo> ogra_: indeed, looking
<ogra_> aha
<ogra_> drwxr-xr-x   2 root root 4096 Aug  4 10:33 tmp
<ogra_> i guess thats the issue
<mvo> ogra_: yes
<ogra_> yeah, works
<mvo> ogra_: /tmp in the core snap has the wrong permissions
<mvo> ogra_: probably a livecd rootfs fix
<ogra_> mvo, no, that was a snapcraft issue i fixed in the PPA
<ogra_> mvo, are you sure that snap was built with the PPA on ?
<ogra_> (the ubuntu-core one)
<mvo> ogra_: yeah, I triggered it from the ppa
<ogra_> weird
 * ogra_ downloads
 * mvo lunches
<ogra_> mvo, hmm the patch is in and i.e. /home7ubuntu has the right permissions  .. but /tmp is still  wrong, so you might be right that we need to chmod it from a hook
<mwhudson> oh yeah, i noticed that too
<mup> Bug #1609757 opened: Enable ordering of services provided by a snap <Snappy:New> <https://launchpad.net/bugs/1609757>
<mup> Bug #1609762 opened: Enable snaps to run before SSH comes up in classic boot process <Snappy:New> <https://launchpad.net/bugs/1609762>
<Odd_Bloke> niemeyer: Any movement/further thoughts on https://bugs.launchpad.net/snappy/+bug/1607710 ?
<mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
<ogra_> Odd_Bloke, that wouldnt work on snappy images
<ogra_> (because /etc/passwd is only used for system users created at ubuntu-core snap creation time and is readonly)
<ogra_> you should rather use a tool that can handle the different backends
<Odd_Bloke> ogra_: Well, I'm not that bothered about how it's implemented, but the jenkins user should really be able to write to its home directory (i.e. /var/lib/jenkins).
<Odd_Bloke> I've changed the title to "Home directories listed in /etc/passwd should be honoured by home interface".
<ogra_> Odd_Bloke, well, that still weouldnt solve the issue ... if a juju snap on a snappy image would creat a user it would be handled by libnss-extrausers and not show up in /etc/passwd
<Odd_Bloke> I'm not proposing a generic solution to this problem; I am describing a part of the problem space which has (presumably) not yet been considered.#
<mup> PR snapcraft#710 opened: Make formatting of daemon options consistent <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/710>
<Chipaca> ogra_: the problem with what Odd_Bloke needs is that it implies a level of dynamism in apparmor rules i'm not sure we support
<Chipaca> it's not really a niemeyer question but a jdstrand question, as such
<ogra_> yeah
<ogra_> Chipaca, well, it brings up a general question about images vs classic too
<Chipaca> ogra_: how so?
<ogra_> Chipaca, if a snap is ever allowed to create its own user the user will not end up in /etc/passwd on images
<brendand> mvo, something i can try yet?
<ogra_> so you cant just grep it from there
<mup> PR snapcraft#710 closed: Make formatting of daemon options consistent <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/710>
<Chipaca> ogra_: I mean, Odd_Bloke's request is to use passwd-the-data-structure, not explicitly /etc/passwd, as i read it
<Chipaca> ogra_: ie getpwent or whatever it is called
<mvo> brendand: ups, sorry http://people.canonical.com/~mvo/all-snaps/16/all-snaps-pi2.img.xz
<Chipaca> ogra_: snap install xbill-xaw :-p
<Chipaca> no highscores as yet, didn't feel like patching it
<ogra_> xbill !!!
<Chipaca> jdstrand: any updates on shipping i386 binaries in amd64 snaps?
<Chipaca> I've got a rather old binary I'd like to snap :-D
<jdstrand> Chipaca: re /etc/passwd-- that file is read and we could read any other file. apparmor itself needs to know ahead of time, but there are ways of doing that, for example, updating /etc/apparmor.d/tunables/home.d
<jdstrand> drop files in there and @{HOME} can expand to other things
<mup> Bug #1602845 opened: unity7 interface does not work with libnotify <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1602845>
<mup> Bug #1596717 opened: please add getsockopt to pulseaudio interface <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1596717>
<mup> Bug #1605768 opened: incomplete 'opengl' interface <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1605768>
<jdstrand> Chipaca: as for i386 binaries on amd64, that is a seccomp limitation. I'm trying to find the bug
<Chipaca> jdstrand: :-(
<jdstrand> bug #1592022
<mup> Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592022>
<mup> Bug #1609792 opened: Interface to access .git directories <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1609792>
<brendand> what's an easy way to make an arm build of a snap?
<ogra_> cjwatson, so whom do i have to bribe to have s390x for https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ? (the setup page just talks about "Admins" )
<brendand> do i need to perform the build on the desired arch, or is there another way?
<ogra_> brendand, right, you need to do it natively
<ogra_> iirc kernel snaps are an exception (since they dont really use dependencies)
<Odd_Bloke> ogra_: I generally ask for architectures to be added to (livefses|PPAs) in #webops in Canonical IRC; I expect it's similar.
<sborovkov> brendand: for rpi I use Ubuntu Mate and build there. So you could do the similar thing I guess
<ogra_> sborovkov, well, there should be new snappy images before EOW
<ogra_> so you can just use the classic shell on it and install snapcraft
<sborovkov> oh right, that works as well
<sborovkov> I just have Mate for that since 15.04
 * ogra_ too, but i hate having to swap SD cards all the time
<mup> PR snapd#1630 closed: daemon: stop using group membership as succedaneous of running things with sudo <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1630>
<Odd_Bloke> I'm snapping something which has some npm dependencies, but then needs to run a "compilation" command using the installed dependencies.
<Odd_Bloke> I'm using a nodejs part at the moment, to get all the dependencies, but I'm not sure how to go about then running that command with all the things in place.
<ogra_> mvo, hmmm
<ogra_> ubuntu@localhost:~$ sudo classic.shell
<ogra_> Failed to start transient scope unit: Unit classic.scope already exists.
<ogra_> i am already logged in and have a classic shell running from another machine ... is there a way that we can allow multiple ones ?
<mvo> ogra_: yes, a simple matter of programming
<ogra_> k
<beowulf> Odd_Bloke: what's the compilation command?
<Odd_Bloke> "browserify -t coffeeify -d js/git-deps-graph.coffee -o js/bundle.js"
<Odd_Bloke> (Which I'll then need to put in the right place for it to be found by a Flask web server :)
<beowulf> Odd_Bloke: i'm not sure what the correct snapcraft way would be, but i might look at wrapping the nodejs thing you are using in an npm package and using an npm postinstall hook to run the transform (which would use local browserify) https://docs.npmjs.com/misc/scripts
<SamYaple> sergiusens: what do you think of javacrufts suggestion to create a common python base class for python2 and python3?
<SamYaple> sergiusens: should only take me a day or so to implement and would get rid of alot of dup
<popey> Anyone ( dholbach / didrocks ?) had "Error: unsupported locale setting" when launching a snapped app at all?
<popey> I tried snapping calibre (the ebook manager) and it barfs on launch:- http://paste.ubuntu.com/22183092/
<dholbach> hum, no I haven't seen that one yet
<popey> ok
<sergiusens> SamYaple sure, if you feel like it would make for a good improvement, go ahead; when there is so much duplication like this we have been preferring to just make the plugin parametrizable like the qmake one... due to backwards compatibility woes I guess we cannot atm
<sergiusens> SamYaple btw, I went a ahead and fixed this https://github.com/snapcore/snapcraft/pull/707
<mup> PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
<sergiusens> not sure you mind if I go ahead and get it in
<SamYaple> sergiusens: do your thing. i dont mind rebasing
<SamYaple> ill look into the qmake one to see the deal
<didrocks> popey: not that one by itself
<SamYaple> sergiusens: we can do what is done with qmake and create a new plugin called python, having python2 and python3 extend the new python plugin and then deprecate python2 and python3
<didrocks> some different variant, but I can it's about missing locales in general
<ogra_> popey, add libc and the locale package to your snap and make sure to a) generate the right locales on first startup and b) point the env variables to the generated locales
<ogra_> popey, see nethack.sh and snapcraft.yaml https://github.com/ogra1/nethack
<popey> hm
<popey> okay, thanks
<ogra_> line 7-21 in netchack.sh specifrically
<popey> thank you
<sergiusens> SamYaple sounds a lot better; while you are at it; if you don't mind experementing; make the stage-packages python-dev one a build-package and see if everything still works fine
<sergiusens> SamYaple that might be asking for too much, but it would make for smaller default python snaps
<SamYaple> sergiusens: im going to be working on the python plugins for a while as i need ot make changes for what im packaging (openstack in this case) so ill play with that
<SamYaple> sergiusens: i am still hitting C901 in that PR though.
<sergiusens> SamYaple \o/
<SamYaple> cant reproduce that locally
<sergiusens> SamYaple hmm, might be the version of flake8/mccabe being used
<sergiusens> we've seen these before
<cmagina> can you give an app access to fchown on files it created itself?
<sergiusens> cmagina anything can be done really, the thing is, why would you need that?
<sergiusens> sqlite?
<SamYaple> sergiusens: ah. youre using the deb and im pip installing. let me test that
<sergiusens> SamYaple if you are on latest and greatest I think we pip install everything now
<cmagina> sergiusens: its trying to verify the files weren't created via a sudo run. not really an issue in a snap environment, but its a workaround for non-snap environments :)
<cmagina> sergiusens: fish
<cmagina> figured it was simple, see what limitations it hits, i figured it would hit some :)
<sergiusens> cmagina can't that logic be removed then?
<SamYaple> sergiusens: https://travis-ci.org/snapcore/snapcraft/jobs/149773303 <--- it seems no. python3-flake8
<sergiusens> in the end, something will need to change for tihis to work
<sergiusens> SamYaple ah, interesting; elopio any reason for using python3-flake8 instead of a requirements-test.txt one?
<SamYaple> and i am confirming that is the delta
<SamYaple> latest flake8 doesnt have the c901 issue
<cmagina> sergiusens: yeah, that wouldn't fly with upstream. why can't snap allow a program to change permissions on its own files?
<sergiusens> cmagina I would ask jdstrand who is in the security team
<cmagina> sergiusens: ok, thanks
<sergiusens> SamYaple ah, good to know, in any case we'd lock down the version to the one in xenial to be able to continue building with it
<cmagina> jdstrand: trying to snap a shell, fish, and it has code to ensure ownership of its history file using fchown, this causes a seccomp error with snap
<ogra_> cmagina, to what would you change these permissions, given you cant create a user or anything
<SamYaple> sergiusens: thanks for the help. ill get the PR into shape and work on the refactor of python
<ogra_> and if you copy somethiong to $SNAP_USER_DATA for eth executing user it should automatically be created with the ownership of the calling user
<cmagina> ogra_: yeah, the permissions look correct, not sure why its falling into this code path yet. it works fine in devmode of course
<sergiusens> SamYaple thank you!
<jdstrand> cmagina: we'll fix that when the snap-confine is available in 16.04
<cmagina> jdstrand: awesome, thanks
<jdstrand> cmagina: it has a required feature called seccomp arg filtering that we can use to open up things like chown
<cmagina> jdstrand: alright, good to hear
<jdstrand> cmagina: for now, feel free to use --devmode or if you are trying to test locally, you can add the syscalls to /var/lib/snapd/seccomp/profiles/snap.your.app (they won't survive a snap refresh/reinstall/etc but the technique can be handy)
<cmagina> jdstrand: yeah, i used devmode already, but i will look into adding the syscalls, thanks for that pointer
<mup> Bug #1609864 opened: Enable a command to be run on machine shutdown <Snappy:New> <https://launchpad.net/bugs/1609864>
<elopio> sergiusens: I don't know. I think we only use it in travis, so the one from pip should work.
<elopio> it is in the dep8 integration tests as a dependency, but I think that's wrong. We should remove it.
<elopio> SamYaple: can you please file a bug? Bonus points for fixing it too :)
<elopio> sergiusens: https://github.com/snapcore/snapcraft/pull/687 Ready.
<mup> PR snapcraft#687: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
<SamYaple> elopio: are you saying we _want_ to be using flake8 from pip rather than package install?
<SamYaple> once i knew what version to install the test passed locally. honestly this might be a bug in flake8
<mhall119> zyga: I'm in another call still, do you want to reschedule ours?
<elopio> SamYaple: I think that for people hacking snapcraft it would be nicer to set up the environment in a virtualenv.
<elopio> with the recent changes in requirements.txt, that's doable now easily. So yes, maybe from pip is a good idea, and it will be more recent than the one in debian.
<elopio> what do you think?
<trijntje> Is there a list of what kind of issues will trigger a manual review when publishing a snap? I made a hello world snap with a license that has to be accepted and its status is now 'manual review pending'
<mup> PR snapd#1633 opened: many: move to purely hash based key lookup and to new key/signature format (v1) <Created by emgee> <https://github.com/snapcore/snapd/pull/1633>
<elopio> trijntje: you can run the click reviewers tool.
<elopio> https://launchpad.net/click-reviewers-tools
<trijntje> elopio: http://pastebin.com/nB2K7VqR
<elopio> trijntje: you need at least one app in there, or user architectures: [all]
<elopio> the policy vendor thing, I don't know. Haven't seen that before.
<trijntje> elopio: can you elaborate on the user architectures bit? I haven't seen that anywhere
<kyrofa> jdstrand, zyga how is that snap-confine SRU going?
<kyrofa> Ah nevermind, I see another discussion about it
<elopio> trijntje: https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/basic/snapcraft.yaml#L5
<mup> Bug #1609883 opened: Add an interface to allow access to /var/lock and/or /run/lock/ <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1609883>
<trijntje> elopio: thanks, I couldn't find that metadata field in the docs for some reason
<Odd_Bloke> In the following, is my snap trying to execute /sbin/hwclock in the system or in the ubuntu-core snap:  audit: type=1400 audit(1470327924.785:509): apparmor="ALLOWED" operation="exec" profile="snap.gce-compute-image-packages.google-clock-skew-daemon" name="/sbin/hwclock" pid=3230 comm="python3" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<Odd_Bloke> target="snap.gce-compute-image-packages.google-clock-skew-daemon//null-/sbin/hwclock"
<SamYaple> elopio: i agree. the reason im in this situation is because im using a virtualenv
<SamYaple> elopio: ill file the bug, though im not familiar with the testing suite for snapcraft, ill look at it
<slangasek> Odd_Bloke: wrt pre-installing of snaps, I'm afraid I hadn't noticed this issue.  There needs to be some way to preinstall a snap, certainly
<slangasek> Odd_Bloke: a model assertion declares a list of required snaps
<slangasek> Odd_Bloke, gaughen: and 'snap prepare-image' (which, afaik, hasn't landed to trunk yet) should download these and put them all in the right place, without relying on a snapd running on the host system
<slangasek> Odd_Bloke, gaughen: so perhaps the right answer is simply "put it in the model assertion, and trust that this will shake out over the next couple of weeks"?  (Since it's required for RTM)
<slangasek> oh shoot
<slangasek> you're talking about pre-installing snaps for an image that is not an all-snap image
<Odd_Bloke> slangasek: So this specific question fell out of classic images.
 * slangasek think think
<Odd_Bloke> Yeah.
 * gaughen nods
<slangasek> ok
<slangasek> we're going to have a 'snap fetch', I think?
<Odd_Bloke> Yeah, I've heard about that in the context of caching a snap for later installation.
<slangasek> Odd_Bloke: right.  So I think that we may need to do a 'snap fetch', followed by a bit of manual fiddling to put the snap bits in the right place as part of the image build
<mup> PR snapcraft#711 opened: Add make-install-var field to the make plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/711>
<slangasek> niemeyer: ^^ maybe you'd be able to comment on this problem (pre-installing snaps as part of a classic image build, which happens in a chroot with no running snapd service)
<mup> Bug #1609792 changed: Interface to access .git directories <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1609792>
<mup> PR snapcraft#687 closed: Enable integration tests to run in the production store <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/687>
<Odd_Bloke> slangasek: Shall I file a bug so we have somewhere more persistent than IRC to track this?
<slangasek> Odd_Bloke: seems advisable
<Odd_Bloke> slangasek: niemeyer: I've filed that as https://bugs.launchpad.net/snappy/+bug/1609903
<mup> Bug #1609903: Enable the installation of snaps in a classic chroot <Snappy:New> <https://launchpad.net/bugs/1609903>
<mup> Bug #1609903 opened: Enable the installation of snaps in a classic chroot <Snappy:New> <https://launchpad.net/bugs/1609903>
<aatchison> hello
<ahoneybun> mm they removed the snap find ?
<ahoneybun> commdn
<mup> PR snapd#1634 opened: store: add device nonce API support <Created by matiasb> <https://github.com/snapcore/snapd/pull/1634>
<aatchison> lol, hi ahoneybun
<aatchison> So, I either need to be able to call one part from inside another, or call an application from within another snap, is that possible at this time?
<ahoneybun> not sure, I'm a noobie at this
<aatchison> I made some progress with mycroft, but I need to call mimic...
<ahoneybun> oh aatchison
<aatchison> what's up hehe
<ahoneybun> I'm on the slack channel
<ahoneybun> for Mycroft
<aatchison> ahh, cool
<aatchison> I'm just asking around these parts for some snap specific stuff
<ahoneybun> yea I tried to make a snap for pithos but got stuck
<ahoneybun> I think mycroft would hit the same bug as it would make a service
<ahoneybun> yay finally got into to my Mycroft unit!
 * ogra_ notes that Chipaca has his own article on omgubuntu.co.uk today
<ahoneybun> I don't see anything about Chipaca
<ogra_> ahoneybun, Chipaca is john lenton ... quoted about 50 times in the snap find article
<kyrofa> Ouch
<ogra_> ("felt" 50 times, i didnt actually count them :) )
<aatchison> I'm using daemon: simple, and the services are running ok
<aatchison> I just need to reference one app from another, or an app from another snap
<aatchison> aka, mimic
<ahoneybun> is there a mycroft room aatchison?
<aatchison> yeah, #mycroft is the channel on freenode, but it's bridged to our general slack channel
<kyrofa> aatchison, you can't reference one app from another in that mycroft.app1 can't call mycroft.app2 (defined by those present in /snap/bin/)
<kyrofa> aatchison, but you can still call the command itself
<aatchison> hmm. So, in my case, I've tried to add a part for mimic, and it runs on it's own, but calling 'mimic' doesn't work, as there is the mycroft-core.mimic prefix. I tried calling it by that name as well, maybe I'm doign something wrong
<aatchison> wait, command itself?
<aatchison> no need to define an app?
<ahoneybun> mm we can make snaps from deb's right?>
<aatchison> not that I know of
<ahoneybun> I mean it's not that different from source
<kalikiana> ahoneybun: "from debs" meaning what exactly?
<ahoneybun> https://github.com/kasramp/UbuntuIndicatorWeather/releases/download/v0.5/indicator-weather_0.5ubuntu_all.deb
<brendand> is there any detailed tutorial on how interfaces/plugs/slots work? the docs i can find seem a bit sparse
<kalikiana> ahoneybun:  you could have a snap that just pulls in stage-packages for indicator-weather if that's what you mean
<ahoneybun> I guess I could just install the deb
<kyrofa> aatchison, snaps don't have access to /snap/bin, so they can't call things that are in there
<ogra_> you can also pull the deb source and dpkg-buildpackage/debuild it :)
<kyrofa> aatchison, but they can definitely call things within themselves, so just use the `command` you used for the app
<kalikiana> ahoneybun: It may be worth asking another question first: (how) can an indicator be snapped so that it shows up in the panel
<kyrofa> apps are for exporting for _users_ to call
<kyrofa> (or services)
<ogra_> (i do that in some snaps via a Makefile and the make plugin)
<ahoneybun> kalikiana: if it has access to the panel
<kalikiana> ahoneybun: well, it'd be somewhat pointless without that, no? :-D
<ahoneybun> yea it would
<ahoneybun> lol
<kalikiana> I'm guessing it would be using daemon
<kalikiana> But not sure about the dbus side
<ogra_> thats a tricky one ...
<ahoneybun> yea dbus can't be accessed with services or something
<ogra_> daemon actually refers to a system deamon
<ogra_> which an indicator isnt
<ogra_> we'd need something like "session-daemon" for that specific usecase
<ahoneybun> pithos needed access as well
<ogra_> (and it might need to hook into a systemd user session ... which ubuntu has only in yakkety ... which in turn isnt really a snappy target)
<mup> PR snapcraft#690 closed: Preserve file ownership for 'os' snaps <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/690>
<ogra_> \o/
 * ogra_ hugs sergiusens 
<Chipaca> ogra_, omgubuntu really needs to practice its reading comprehension before writing these articles
<ogra_> heh
<Chipaca> responded as well as i could
<aatchison> I'm also having a boatload of problems trying to run ubuntu core on the pi3 :D
<ogra_> he makes sound a bit like that was solely your decision
<ogra_> aatchison, http://people.canonical.com/~ogra/snappy/all-snaps/ fresh from the press
<aatchison> hurray!
<aatchison> Always saving my bum
<ogra_> still experimental, mind you :)
<ogra_> but should be good enough for tinkering
<aatchison> everything I'm working with is hehe
<aatchison> cool
<ogra_> :)
<sergiusens> Chipaca congrats on the promotion to marketting btw
<ogra_> LOL
<Chipaca> sergiusens, I come from U1. Bring it on.
<niemeyer> jdstrand: Some updates on snapd#1409.. can you please have a look when you have a moment and let me know what you think
<mup> PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <Conflict> <https://github.com/snapcore/snapd/pull/1409>
<niemeyer> jdstrand: Would like to get that to a conclusion soonish, or else break it down into pieces we can more easily agree upon
<mup> PR snapd#1635 opened: interfaces: builtin: add pluggable storage interface <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1635>
<ahoneybun> Chipaca: was there really a reason to remove snap find (I'm just curous)
<sergiusens> ahoneybun it is not removed
<sergiusens> ahoneybun it just requires a search param
<trijntje> I'm trying to create a snap that requires accepting a license before install, but I don't get asked to accept the license when using snap install. Who can tell me what I did wrong? http://pastebin.com/bdzQLxuC
<ahoneybun> snap find tele was a good way
<niemeyer> jdstrand: One more: fgimenez addressed your comments on snapd#1550.. can you please re-review when you have a spare moment?
<mup> PR snapd#1550: tests: base security spread tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1550>
<niemeyer> trijntje: You didn't do anything wrong, we did! :)
<niemeyer> trijntje: We dropped the license logic before 16.04 as we didn't want to commit to the form just yet
<niemeyer> trijntje: This is coming back soon as a first-class term-acceptance mechanism
<trijntje> niemeyer: ah, thats too bad, I just noticed deprecation warnings about license as well
<niemeyer> trijntje: It will definitely come back
<niemeyer> trijntje: For the time being, this may be done on the app side
<niemeyer> trijntje: Hooking some logic that runs on the first execution
<trijntje> niemeyer: I think I'll wait for the real mechanism to land. I've been talking to the owners of some popular bioinformatics software about snapping their products, but they require all users to accept their 'non comercial use' license
<trijntje> So they want to see what the license implementation looks like before they'll allow their product on the ubuntu store
<trijntje> Is there somewhere I can follow the development of this feature, or find a rough timeline for this?
<jdstrand> niemeyer: ack
<niemeyer> trijntje: Not sure if we have a ticket open.. would you mind to open one?
<niemeyer> jdstrand: Thanks!
<niemeyer> trijntje: I wouldn't block on it, though.. it seems so easy to show people the LICENSE file the first time they run the application
<mup> PR snapcraft#707 closed: Use the proper requirements.txt path <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
<trijntje> niemeyer: where should I open a ticket for this?
<elopio> thanks SamYaple. Let me know if I can help you with the test suite.
<elopio> cprov: my branch landed in master. So remember to add TEST_STORE=staging
<niemeyer> https://bugs.launchpad.net/snappy/+filebug
<niemeyer> trijntje: ^
<trijntje> niemeyer: I'll contact them and let them know that for now we can show the license on first use as a work around.
<trijntje> But it will probably go to their legal team so they might want to opt to wait for the full feature to land
<cprov> elopio: thanks, let me try.
<trijntje> niemeyer: https://bugs.launchpad.net/snappy/+bug/1609930
<mup> Bug #1609930: wishlist: re-enable mandatory click-through license for snaps <Snappy:New> <https://launchpad.net/bugs/1609930>
<trijntje> to all: please set this bug to 'affects me' if you want this fixed ;)
<mup> Bug #1609930 opened: wishlist: re-enable mandatory click-through license for snaps <Snappy:New> <https://launchpad.net/bugs/1609930>
<niemeyer> trijntje: It affects all of us :)
<niemeyer> trijntje: It'll definitely be fixed
<trijntje> niemeyer: that is good to know, I'll contact the developers as well and see how they feel about having a workaround
<niemeyer> morphis: Another one on #1623
<niemeyer> morphis: Another one on snapd#1623
<mup> PR snapd#1623: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
<niemeyer> trijntje: Let us know how it goes
<Pharaoh_Atem> niemeyer: I figured you might get a kick out of this: https://www.yoctoproject.org/blogs/khem/2013/get-smart-smart-package-manager
<kgunn> jdstrand: got a sec for some questions?
<jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
<Pharaoh_Atem> niemeyer: https://www.yoctoproject.org/blogs/jefro/2013/yocto-project-14-dylan-released
<Pharaoh_Atem> Smart is now used in most Yocto derived distros I know of: Wind River Linux, JunOS NG, etc
<niemeyer> Pharaoh_Atem: Nice :)
<Pharaoh_Atem> there's even a variant of Tizen that runs on Yocto where it uses smartpm instead of zypper
<Chipaca> trijntje, they're aware they can make them private to get them working confined and all that, without blocking on this?
<kgunn> jdstrand: got a sec for some questions? (sorry if this is a repeat)
 * kgunn is having fun with network and irc
<ali1234> is snapcraft cleanbuild supposed to work?
<jdstrand> 15:05 < jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
<jdstrand> kgunn: 15:27 < jdstrand> 15:05 < jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
<kgunn> :)
<kgunn> jdstrand: so i'm down to tuning as you know, and when i have
<kgunn> unix (receive, send) type=seqpacket addr=none,
<kgunn> it will connect fine
<kgunn> sorry....when i have that in my connectedplug snippet
<kgunn> but when i try to change that to
<kgunn> unix (receive, send) peer=(label=###SLOT_SECURITY_TAGS###) type=seqpacket addr=none,
<kgunn> i get a failure on the snap connect call
<kgunn> like so
<kgunn> https://pastebin.canonical.com/162369/
<tsimonq2> kgunn: people not employed at Canonical can't see that
<kgunn> sorry bad habit
<kgunn> http://pastebin.ubuntu.com/22224395/
<jdstrand> kgunn: use: unix (receive, send) type=seqpacket addr=none peer=(label=###SLOT_SECURITY_TAGS###),
<jdstrand> kgunn: it appears ordering matters
<kgunn> jdstrand: thanks
<jdstrand> kgunn: fyi, a technique I use is copy a known good profile from somewhere to /path/to/profile, then modify /path/to/profile with rules I want, then see if it compiles with apparmor_parser -QTK /path/to/profile
<jdstrand> kgunn: something like this: http://paste.ubuntu.com/22225124/
<mup> Bug #1609965 opened: snapweb store is a blank page <Snappy:New> <snapweb:New> <https://launchpad.net/bugs/1609965>
<kyrofa> jdstrand, I get "cannot remain in %s, please run this snap from another location" from snap-confine no matter what. Can you explain the logic there?
<kyrofa> jdstrand, the %s is whatever path I'm in
<kyrofa> Ah, I had to get back into /home apparenty
<kyrofa> That's odd
<jdstrand> kyrofa: I know there is some check for being in /tmp
<jdstrand> otherwise the private /tmp isn't applied
<kyrofa> jdstrand, I was in /gopath (and various subdirectories)
<jdstrand> maybe cause that dir doesn't exist in the runtime env?
<jdstrand> seems the error message could be better
<kyrofa> jdstrand, so I can't run any commands from something that isn't accessible from the runtime environment? That seems problematic
<kyrofa> s/something/somewhere/
<jdstrand> I suggest filing a bug with your use case. this is the area zyga hsa worked most with
<jdstrand> in terms of security, a strategically placed chdir(/) is enough to make sure all the bind mounts apply (and a corresponding chdir(orig) after)
<kyrofa> jdstrand, use-case: all snapd's spread tests :P
<kyrofa> But we can probably relocate them
<tianon> there's not a snap of snapcraft yet? :o
<mup> Bug #1610001 opened: Regression: snap run no longer runs hooks <Snappy:In Progress by kyrofa> <https://launchpad.net/bugs/1610001>
<mup> PR snapd#1636 opened: snap: don't load unsupported implicit hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1636>
<mup> PR snapd#1637 opened: cmd/snap,cmd/snap-exec: support hooks again <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1637>
<mup> PR snapcraft#697 closed: Also use INSTALLROOT for make plugin <Created by jhobbs> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/697>
<tianon> kyrofa: kudos for snapcraft#680 :D  (went digging into why "plugin: python2" was creating bad shebangs for me and found you'd fixed in master already :D)
<mup> PR snapcraft#680: Rewrite shebangs generated by the python plugins <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/680>
<mup> PR snapcraft#709 closed: Improve the go plugins usability <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/709>
<mup> PR snapcraft#711 closed: Add make-install-var field to the make plugin <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/711>
#snappy 2016-08-05
<mup> Bug #1610025 opened: snapd fails to start after installing snaps <Snappy:New> <https://launchpad.net/bugs/1610025>
<b-yeezi> Hi all. I'm trying to snappify an electron app that I'm a fan of. I'm following the SimpleNote example, but get an error
<b-yeezi> ~/.../parts/.../build/wrapper so such file.
<b-yeezi> no such file
<b-yeezi> my wrapper file is in the $SNAP directory before I run snapcraft
<b-yeezi> any suggestions?
<b-yeezi> The only difference is that I'm pulling the tar.gz from the internet instead of untarring it locally
<b-yeezi> hi
<ahoneybun> just did a popey and made a script for running snapcraft on a linode server
<dholbach> hey hey
<morphis> zyga: ping
<morphis> does someone know how to fix this issue https://travis-ci.org/snapcore/snapd/jobs/149977843 with the spread tests running on linode?
<morphis> looks like they broken with the now landed snapd 2.0.11 in xenial
<mup> PR snapd#1638 opened: interfaces: add uefi-manager interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/1638>
<popey> ahoneybun: yay
<popey> dholbach: lemme know if/when you get a chance to try my silly script :)
<dholbach> popey, probably not today :-/
<dholbach> I looked at the team option already though and it looks like what we want :)
<popey> well that's good news!
<lucalar> hi guys
<lucalar> I would like to ask you something on IoT project development on Ubuntu Snappy
<lucalar> if someone could answer I appreciate
<lucalar> I'm a newbie on Ubuntu Snappy, and I have to develop a project using a gateway (where snappy is installed) and sensors connected to it
<lucalar> which is the best way, the language that I have to use, etc.. ???
<dholbach> you can build your software whichever language you are most comfortable using
<dholbach> snapcraft (the tool to turn your software into a snap) has a lot of different build plugins, so building it should be easy
<dholbach> http://snapcraft.io has more info about it
<lucalar> yes, i've read something on snapcraft
<lucalar> but in this context, I would like to know if I can test the software during the developing
<lucalar> I mean, my Ubuntu Snappy is installed on a gateway, so I have no GUI
<lucalar> and I'm not sure if I can install snapcraft on it
<dholbach> I'm not sure how you would debug or interact with your software - is it a service you can reach over the network?
<dholbach> or do you mean building it on an ARM machine while you're on x86?
<lucalar> nop
<lucalar> yes, something like that
<lucalar> i have to build it for a different machine
<mup> PR snapd#1639 opened: tests: allow-downgrades on upgrade test to prevent version errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1639>
<dholbach> I'm not quite sure what the best way to do this is... I'll leave the question for somebody else
<dholbach> if nobody responds in time, maybe best send an email snapcraft@lists.snapcraft.io and explain your setup
<dholbach> I'm sure you're not the only one looking for this :)
<lucalar> thank you guys
<Odd_Bloke> Launchpad supports building snaps on multiple architectures; there are some restrictions on what architectures are generally available, so I don't know if that helps.
<dholbach> ah, nice one - of course
 * dholbach clearly needs some more mate tea
<Odd_Bloke> Alternatively, you could try running snapcraft inside a $arch KVM, if you can get one running.
<lucalar> I see
<Odd_Bloke> I haven't actually done either of these things though (as I lead a blessedly amd64 life ;), so I can't promise they'll work for you. :)
<dholbach> https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<dholbach> lucalar, ^
<Odd_Bloke> Hmm, update-alternatives not running when you stage-packages is irritating.
<lucalar> cool, I will give it a look ;)
<Odd_Bloke> Just spent several iterations of snap/upload/install trying to work out why awk wasn't in my path after installing gawk. >.<
<lucalar> wow, cool...launchpad is very interesting. Thanks a lot dholbach and Odd_Bloke
<mup> PR snapd#1639 closed: tests: allow-downgrades on upgrade test to prevent version errors <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1639>
<lucalar> another question, do you know the existance of a Java API to work with sensors on an OS Ubuntu Snappy installed on an architecture amd64?
<dholbach> I don't, but I'd recommend just using the java api your sensors work with and bundling that in the snap (snapcraft will help you do that)
<beowulf> Odd_Bloke: hey, did you figure out the browserify step?
<Odd_Bloke> beowulf: I haven't, no.
<beowulf> Odd_Bloke: let me know what you come up with :) I think using npm's package.json to define that steps pre and post installing some modules via snapcraft's node plugin is worth exploring, but i haven't had time
<Odd_Bloke> beowulf: I don't really know enough about npm/node to really dig in to it; I was hoping it would Just Work (TM). ;)
<beowulf> Odd_Bloke: let me try something simple and if it works it might help you :)
<mup> Bug #1610149 opened: writing to the "common" directory needs to have sudo right <Snappy:New> <https://launchpad.net/bugs/1610149>
<Odd_Bloke> beowulf: :) Thanks!
<willcooke> ogra_, I assume the answer is yes, but.. does your Pi3 core image include drivers for BT and Wifi?
<ogra_> willcooke, the answer is no currently
<ogra_> :)
<ogra_> sorry ... they will land soon
<willcooke> ogra_, ah :)  Glad I asked then.  What about wired ethernet?
<ogra_> (it includes the drivers, but not the additional firmware)
<ogra_> wired works fine
<willcooke> perfect, thanks!
 * willcooke ponders netbooting a pi3 in to core
<ogra_> unlikely to work ... but try it
<willcooke> will try and carve out some time to play this afternoon
<ogra_> (the initrd searches for labels on partitions for the whole system setup ... if the label isnt there or the snaps arent in the right place on the labeled partition it will fall flat on its face)
<willcooke> Ah, I see
<ogra_> for netbooting we'd need to add some bits to the scriptery
<willcooke> Not worth it atm I expect.
<ogra_> well, there was some desire to do netbooting at some point, i thinnk lool worked on that ... though i also think that was via a special system that puts bits into place first
<lool> I have not but I'd like it too  :-)
<lool> in Heidelberg we noted it would be a quite desirable thing ot have
<willcooke> Is this made any easier by the recent Pi annoncement of netbooting?
<ogra_> nope
<willcooke> darn
<ogra_> in all cases you need an SD to boot the pi ...
<ogra_> since we default to using uboot for booting, a generic solution would kick in on that level, not in the first stage bootloader
<ogra_> i.e. you would have an SD with the binary blob plus the uboot binary and config
<ogra_> (in general the pi isnt realyl a great target given you will always need an SD due to a missing eMMC boot)
<willcooke> yeah
<ogra_> (if you need an SD anyway, you could as well do a local boot)
<willcooke> only use case for netbooting I have is that SD cards don't like getting hot, so industrial applications might want to boot from SD card and load everything else over the network
<willcooke> plus, people like me who like to play
<ogra_> well, it is definitely a valid target ... (i guess also for cloud stuff)
<willcooke> This confuses me:  https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md
<willcooke> It says that the boot ROM is "One Time Programmable"
<willcooke> and then it talks about setting bits in there
<willcooke> But does suggest that it might be possible to boot without an SD card
<ogra_> ah, well, try it if you like
<willcooke> I'll see what I can get working, and then bother you about it next time we meet
<lool> willcooke: prompted by your remark about netbooting, I landed on the exact same page and I have been diving into it; seems quite useful
<lool> willcooke: the OTP seems indeed to be write once; my understanding is that the firmware supports USB netboot and USB mass storage, but that's disabled by default because potentially buggy or unsecure
<lool> so we flip a bit once to enable it forever
<lool> can't disable it
<lool> Hmm https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md says if you remove it it's turned off
<willcooke> lool, I think there are a few typos in those docs.
<lool> can't find much about this flash except that it holds a bunch of device specific stuff like serial
<willcooke> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md
<lool> http://www.elinux.org/RPI_vcgencmd_usage is where I found the info on the otp contents
<lool> willcooke: ah well the net tutorial page is consistent with the hardware behavior I suspect: program_usb_boot_mode=1 is only needed to be present once, and then it's enabled forever
<willcooke> lool, this page talks about getting involved in the beta of netbooting:  https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/README.md
<mup> Bug #1591664 changed: 'snap install' should support --beta, --candidate and --edge options <Snappy:Fix Released> <https://launchpad.net/bugs/1591664>
<willcooke> lool, @ program_usb_boot_mode - yeah, I think so too
<lool> https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/bootflow.md is pretty nice
 * willcooke reads
<lool> willcooke: if I read the bottom correctly ("By default the USB device boot mode is enabled at manufacture time [...]"), once you switch to netboot you can't ever go back to device mode
<willcooke> erk
<willcooke> maybe you can change that with pulling the GPIOs up?
<willcooke> or down
<ogra_> or with pliers and a soldering iron :P
<willcooke> :)
<mup> Bug #1602154 changed: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1602154>
<mup> Bug #1605471 changed: Cannot refresh a devmode snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1605471>
<mup> Bug #1606100 changed: "snap revert" command  cannot be found <Snappy:Fix Released> <https://launchpad.net/bugs/1606100>
<mup> Bug #1607717 changed: no snaps installed error <Snappy:Fix Committed by chipaca> <https://launchpad.net/bugs/1607717>
<beowulf> Odd_Bloke: so, the nodejs plugin would probably need a few changes to make my suggestion work :(
<mup> Bug #1590704 changed: "snap interfaces" command doesn't filter by snap <verification-done> <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1590704>
<cpaelzer> on a minor note on http://snapcraft.io/create/ "... the two highlighted files ...", but there is only one highlighted - prime/command-hello-service.wrapper should be bold as well I think
<cpaelzer> link https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute/ as referred by http://snapcraft.io/create/ is broken as well
<mup> Bug #1610211 opened: Interface to manage block devices <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1610211>
<ali1234> popey, didrocks: i am currently getting this exact error http://askubuntu.com/q/787258/12435
<ali1234> even to the extent that one day later the error changed from failing on the package lists to the deb files
<popey> erk
<popey> i have no idea what I did to fix it
<popey> I think I nuked my lxd config and started again
<ali1234> i started with a fresh lxd config
<didrocks> I guess the issue is Err:5 http://archive.ubuntu.com/ubuntu xenial-updates/main Translation-en
<didrocks> 500  Internal Server Error
<popey> oh, also, I had an apt-cacher-ng which I removed
<ali1234> installed it yesterday for this purpose
<popey> oh
<didrocks> it can't update that repo
<ali1234> no cachers here
<popey> ok
<ali1234> actually
<ali1234> yesterday it failed on a en translation file
<ali1234> today it didn't even try to download that
<ali1234> http://paste.ubuntu.com/22306053/ is today's error
<ali1234> didrocks: yes, yesterday that was the error. today the error is different ^
<ali1234> i have changed nothing on my end. just gave up yesterday and went to bed...
<didrocks> weird, and no issue from your host at all?
<ali1234> apt works fine on the host afaik
<didrocks> maybe ask stgraber if there is some lxd cache?
<mup> PR snapd#1640 opened: tests: add gsettings interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1640>
<mup> PR snapd#1628 closed: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1628>
<jdstrand> kyrofa: hey, now for me to ask you a couple questions :) 1) if I run 'snapcraft' which directory is mksquashfs run on? 2) Let's suppose that I stage-packages and all the debs are unpacked but I want to add/tweak something that was unpacked. is it possible to insert a command at sometime after unpack but before mksquash?
<morphis> niemeyer: are you looking at https://github.com/snapcore/snapd/pull/1432 today? jhodapp is waiting already for some days
<mup> PR snapd#1432: interfaces/builtin: improve pulseaudio interface <Reviewed> <Created by jhodapp> <https://github.com/snapcore/snapd/pull/1432>
<niemeyer> morphis: I've been actively going through the queue in the last few days.. will get to it
<morphis> aye
<jhodapp> thanks niemeyer
<niemeyer> jhodapp: np, sorry for the delay.. it's obviously been a little hectic after the sprints
<jhodapp> niemeyer, yeah understood
<jhodapp> niemeyer, this PR has been reviewed many times, so it should just be ready to go...an easy merge
<niemeyer> jhodapp: Yeah, this is an epic branch
<niemeyer> jhodapp: What is that line 217 on manual-tests.md?
<jhodapp> niemeyer, that shouldn't be there...slipped through in my conflict resolution
<mup> PR snapd#1641 opened: interfaces: implement systemd-control <Created by morphis> <https://github.com/snapcore/snapd/pull/1641>
<jhodapp> niemeyer, let me get rid of that quickly
<niemeyer> jhodapp: Can you please also take this chance to fix the tab indentation on the yaml snippets?
<niemeyer> jhodapp: It's being improperly tagged red there for good reasons.. yaml can't take tabs
<niemeyer> (not your fault)
<niemeyer> jhodapp: 4 spaces on all of them please
<niemeyer> I mean, four spaces indents
<jhodapp> niemeyer, I can change it but those tabs are not from me
<jhodapp> oh you said that
<niemeyer> jhodapp: You've marked it as yaml in the branch, though (correctly)
<jhodapp> sure I can fix that
<jhodapp> it was bugging me too
<niemeyer> jhodapp: Thanks, the indentation is also pretty broken in that one snippet you touched at least.. it has 8 spaces and 4 spaces, interchangeably
<niemeyer> and then next one has 2 spaces.. indentation party
<jhodapp> niemeyer, fixed that section
<niemeyer> jhodapp: Why were the consts changed to vars on all snippets?
<jhodapp> niemeyer, at least pulseaudioConnectedPlugAppArmor is modified in the code later
<kgunn> jdstrand: ok, i'm getting a seccomp denial for sendto and it's clearly in my connectedplug snippet
<niemeyer> jhodapp: It's actually not, I think
<jdstrand> kgunn: is it in the resulting policy in /var/lib/snapd/seccomp/snap.your.thing.that.is.failing
<jhodapp> niemeyer, oh you're right it isn't...sorry brand new to Go
<jhodapp> niemeyer, so am I able to just slap "const" back on the front of those?
<jhodapp> even as byte slices
<niemeyer> jhodapp: No, unfortunately not.. you'll need to move them back to being strings, and use []byte in place
<niemeyer> jhodapp: I'd prefer that in general, as a guideline.. it means those strings are in unchangeable memory, and won't be mutated behind our back
<niemeyer> jhodapp: A bit of paranoia, arguably, but not too crazy given the context
<jhodapp> niemeyer, using []byte in place is a cast, yes?
<niemeyer> jhodapp: Type conversion, not a cast
<niemeyer> jhodapp: Cast means something else if we're pedantic enough
<jhodapp> niemeyer, so it's not the same thing as in C/C++
<niemeyer> jhodapp: No, it's not.. in those languages you can actually tell the compiler you want to look at that memory under different eyes, whethere that's correct or not
<niemeyer> jhodapp: That's casting
<jhodapp> niemeyer, yeah ok, so this is safer
<niemeyer> jhodapp: On b := []byte(s) you're allocating new memory, copying data over, and converting the type..
<jhodapp> yeah
<kyrofa> Hey jdstrand!Sorry, I had to switch work locations
<kyrofa> jdstrand, (1) snapcraft (which defaults to snapcraft snap) runs mksquashfs on the prime/ directory
<mup> PR snapd#1642 opened: many: pass device to store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1642>
<kyrofa> jdstrand, (2) not by utilizing the default plugins, but you have a few options. You can either write your own plugin that does stuff right after the pull step, or write a Makefile that does stuff in the all: rule (which is run during build, right after pull
<kyrofa> jdstrand, you can ship a local plugin alongside the snapcraft.yaml
<jhodapp> niemeyer, fixed
<niemeyer> jdstrand: This is an interesting point to keep an eye on for future reviews.. the snippets should ideally live as consts rather than var []byte
<liuxg> kyrofa, ping
<kyrofa> liuxg, pong
<liuxg> kyrofa, if I want to write to the common directory, do I need to have the root previlege? thanks
<kyrofa> liuxg, there are two common directories: SNAP_COMMON and SNAP_USER_COMMON. Yes, SNAP_COMMON (like SNAP_DATA) is owned by root
<jdstrand> niemeyer: noted
<kyrofa> SNAP_USER_COMMON though is owned by the user. Note however that it's not currently usable as nothing creates it. niemeyer, speaking of that, did you see the email thread about that?
<niemeyer> jhodapp: Just waiting for it to go green
<jhodapp> niemeyer, cool
<liuxg> kyrofa, I mean the directory SNAP_COMMON
<niemeyer> kyrofa: Nope
<kyrofa> liuxg, then yes
<jdstrand> kyrofa: great, thanks!
<kyrofa> jdstrand, let me know what path you decide to follow and I can give you a few more hints
<liuxg> kyrofa, do you mean it needs have the root previlege? it is like /home/<user_name>/snap/hello/common
<kyrofa> liuxg, that's SNAP_USER_COMMON
<kyrofa> liuxg, SNAP_COMMON is in /var/snap/<snapname>/common
<kyrofa> But yes
<niemeyer> kyrofa: My vague memories are that with snap run creating that directory becomes trivial
<niemeyer> kyrofa: Not sure what changed since we last discussed this, though
<kyrofa> niemeyer, indeed, that's true. But snap run is taking a while to land and people are starting to get confused by the behavior of not creating them
<liuxg> kyrofa, right. so, the one SNAP_USER_COMMON a user right is fine, right?
<kyrofa> niemeyer, will that land soon you think? Or should we add that logic back to snap-confine?
<kyrofa> liuxg, right
<liuxg> kyrofa, thanks for your clarification. By the way, I have shared you a document about core, would you please help to review it, thanks.
 * kgunn has more fun with network
<kyrofa> kgunn, I share your pain
<kyrofa> liuxg, sure!
<kgunn> jdstrand: sorry had to re-run and yes it is listed in /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start
<kgunn> the denial signature in syslog appears as
<kgunn> Aug  5 14:34:56 localhost kernel: [  267.421706] audit: type=1326 audit(1470407696.839:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1383 comm="clocks" exe="/snap/mir-client/x1/clocks" sig=31 arch=c000003e syscall=44 compat=0 ip=0x7fcdea268b7f code=0x0
<niemeyer> kyrofa: The only blocker for snap run is snap-confine, which I believe is now about to be in updates
<liuxg> kyrofa, by the way, another developer yesterday met a same problem, and he confirmed it.. https://bugs.launchpad.net/snapcraft/+bug/1601834
<mup> Bug #1601834: Error "[Errno 21] Is a directory" when building a snap package for a qmake project <Snapcraft:Confirmed> <https://launchpad.net/bugs/1601834>
<niemeyer> kyrofa: So *maybe* next week
<kyrofa> niemeyer, ah, good deal. Okay, we'll just live with it then
<jdstrand> kgunn: is clocks running under snap.mir-client.client-start?
<jdstrand> kgunn: and it this on amd64?
<niemeyer> kyrofa: Did I miss something else in that conversation?
<kyrofa> niemeyer, no, people seemed to think snap run was already used. I tried to clarify, but asked you and mvo about timeline. It would be great if you could quickly respond just to close the thread, if you have a minute
<ali1234> what's snap run? test the current snap without installing it?
<niemeyer> kyrofa: Where's the thread?
<mup> PR snapd#1643 opened: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1643>
<niemeyer> ali1234: Any app may be run via "snap run snap[.app]"
<niemeyer> ali1234: Instead of /snap/bin/snap[.app]
<ali1234> oh right, i was thinking of "snapcraft run"
<niemeyer> ali1234: The latter will become just a symlink to /usr/bin/snap
<niemeyer> ali1234: So it's a much nicer pipeline for how things get executed
<mup> Bug #1610149 changed: writing to the "common" directory needs to have sudo right <Snappy:Invalid> <https://launchpad.net/bugs/1610149>
<ali1234> yeah, i see. i was thinking of something else entirely
<niemeyer> ali1234: It's coming for a while, but there were several moving parts, so it took a while to get to this point
 * ogra_ grumbles about not being able to use sidloaded kernel snaps anymore with latest u-d-f
<mup> PR snapd#1625 closed: asserts: make account-key's `until` optional to represent a never-expiring key <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1625>
<jhodapp> niemeyer, looks like CI completed successfully
<kgunn> jdstrand: sorry, network killing me....not sure if you saw i do have sendto in the seccomp profile for the client
<jdstrand> kgunn: is clocks running under snap.mir-client.client-start?
<jdstrand> kgunn: and it this on amd64?
<jdstrand> is*
<kgunn> jdstrand: yes, this is on amd64 and clocks is the exe launched by client-start
<kgunn> http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start
<jdstrand> kgunn: and you are 100% sure that sendto is listed in /var/lib/snapd/seccomp/snap.mir-client.client-start ?
<jdstrand> kgunn: grep sendto /var/lib/snapd/seccomp/snap.mir-client.client-start
<jdstrand> kgunn: and you are seeing the denial by launching mir-client.client-start ?
<kgunn> jdstrand: it is literally on line 469 of /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start
<jdstrand> kgunn: is the interface connected?
<kgunn> jdstrand: the interface is connected manunally
<jdstrand> meh, if it is in there it should be
<kgunn> jdstrand: so i put a sleep at the top of client-start, then manually connect
<jdstrand> kgunn: can you tail -f /var/log/syslog in one terminal, then sudo systemctl stop your.unit ; sudo systemctl start your.unit
<jdstrand> kgunn: then tell me if you see a new denial in syslog?
<kgunn> jdstrand: sure will try
<kgunn> jdstrand: when i call sysctl on snap.mir-client.client-start.service
<kgunn> it fails with
<kgunn> Failed to stop snap.mir-client.client-start.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
<kgunn> See system logs and 'systemctl status snap.mir-client.client-start.service' for details.
<jhodapp> niemeyer, are you still around?
<ysionneau> hmm I have two snaps that must communicate through unix socket
<ysionneau> where do I put the socket ?
<ysionneau> in /tmp one won't be able to open it
<ysionneau> in home, the home interface isn't autoplug I think ...
<ysionneau> (and I guess I won't be in devmode since I install the snap through webdm)
<jdstrand> kgunn: did you run that with sudo?
<kgunn> jdstrand: i can try
<ysionneau> so what's the way to communicate between two snaps via unix socket without devmode ?
<jdstrand> kgunn: basically, I don't understand how the sendto denial is being logged. it shouldn't be. I think it is either an old denial or it happens on install before the connection. I'd like to see confirm that a sudo sysctemctl stop ... followed by start triggers it
<jdstrand> kgunn: if it wasn't working, there would be people screaming left and right about it being broken...
<didrocks> ysionneau: I would recommend using SNAP_DATA if both are running as root, until we get a better answer from jdstrand or niemeyer :)
<ysionneau> hmmm i'm running as root yes
<ysionneau> but I guess one snap does not have access to another snap's SNAP_DATA, right ?
<didrocks> ah, it's 2 snaps, sorry, I read 2 apps
<didrocks> so, yeah, question for jdstrand & niemeyer in that case (maybe ask on the ML so that they can catch up later on?)
<ysionneau> I have lool helping me out in fact at the moment :)
<ysionneau> thanks !
<didrocks> lool: ysionneau: do you mind keep us posted on the ML? That would be interesting to quite a lot of people I think
<lool> didrocks: at the moment it's a bit hackish with a devmode snap
<lool> didrocks: the docker snap is a good example of how to do this properly, but it requires landing an interface in snapd
<lool> didrocks: https://github.com/snapcore/snapd/pull/1619/files has the interface
<mup> PR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges <Created by tianon> <https://github.com/snapcore/snapd/pull/1619>
<lool> you can see it gives access to /run/docker.sock
<didrocks> lool: hard for 3rd party apps to land an interface for their specific socket thoughâ¦
<ysionneau> yep I would prefer to not have to modify snapd, for now at least, even if it's a bit hackish like reusing some interface
<lool> didrocks: well it's the otherway around here
<lool> didrocks: they have a first (devmode) snap with a socket somewhere, and another snap (confined) accessing it, I'm not sure which dir is accessible by default to all snaps though, checking default policy
<ysionneau> yes it would be for out autopilot, that Parrot should land an interface to allow 3rd party apps to connect to our unix ocket
<ysionneau> socket*
<lool> ysionneau: BTW I wanted to tell you about shm
<ysionneau> ah!
<lool> ysionneau: not sure if you saw the exchange on the ML, but shm is open by default with snap.XXX prefix
<lool> ysionneau: https://lists.ubuntu.com/archives/snapcraft/2016-August/000611.html
<lool>   /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,
<ysionneau> !!
<ysionneau> ah this is for shm, ok thanks!
<lool> ysionneau: damn, I'm out of time, but I think this is the default policy: https://github.com/snapcore/snap-confine/blob/master/debian/usr.bin.snap-confine
<lool> ysionneau: I have to run to a meeting, perhaps you'll find a dir in there
<lool> ah no I still have :30
<ysionneau> I have updated my fw btw
<ysionneau> I'm using ubuntu-core_148.snap
<ysionneau> usr.bin.ubuntu-core-launcher -> usr.lib.snapd.snap-confine
<ysionneau> I'm not very fluent in apparmor profiles though, where to look for "unix socket rights"?
<kgunn> jdstrand: sorry otp, but sudo systemctl stop/start worked...and now i get a different denial so that's good
<ysionneau> does not seem to be any unix socket stuff related in the default profile :/
<lool> ysionneau: I think it's just about read on the socket
<lool> ysionneau: to do open()
<ysionneau> hmmm no special rights for connect listen bind send recv sendmsg ?
<ysionneau> hmm maybe I can use the shm related exception ?
<lool> I think you get these from network
<lool> which is autopluggable
<lool> ysionneau: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network.go
<lool> ysionneau: so
<lool> ysionneau: just say plugs: [network]
<ysionneau> I already have it
<cholcombe> hey snappy peeps!  I'm looking at the snapcraft-daily ppa and it looks like it hasn't been built in a week
<cholcombe> i need the latest so i can try out the rust plugin
<ysionneau> lool: question is, where do I put it (the socket :p)
<lool> ysionneau: ah I was wrong, the default perms are in https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go
<ysionneau> thx
<lool> ysionneau: unfortunately the 3 rw locations seem to be /tmp which is diverted to a per snap tmp, shm, and ptmx
<lool> ysionneau: is this a rw socket you need?
<ysionneau> hmmm
<lool> well you'll need to send messages I guess
<ysionneau> yes
<ysionneau> send and receive
<ysionneau> both sides are going to send/recv
<lool> ysionneau: so I guess your best bet is to use a snap specific location, but avoiding the version; perhaps /snap/<snap name>/common/foo.socket
<lool> that way the confined snap has rw access
<lool> and the dir wont be removed if you ever create it
<ysionneau> hmm so, autopilot snap, would create the socket in /snap/facedetect/common/ so that facedetect snap can open it ?
<jdstrand> didrocks, lool, ysionneau: different snaps aren't allowed to talk to each other. the canonical answer is that the snap that is providing a service should provide a slot implementation of a new interface, then the other snap plugs [ the-new-interface ]
<lool> jdstrand: right, this is just for doing a PoC without rebuilding snapd
<ysionneau> jdstrand: that's the "clean" way, I agree with that (except that I'm not very happy to have to submit a pull request to snapd), but I would need a hackish temporary solution
<lool> ysionneau: that's what I was thinking, haven't tested
<ysionneau> lool: ok let's try that
<didrocks> lool: I doubt the autopilot snap will be able to create in /snap/facedetect/common (confined), right?
<lool> didrocks: autopilot isn't confined
<jdstrand> ysionneau, lool: I think it might be possible to use the content intreface to export a rw path and then use a named socket
<jdstrand> in that path
<kyrofa> elopio, is snapcraft not building daily?
<kyrofa> (saw cholcombe's question above)
<jdstrand> caused named sockets don't need a unix rule, only a file rule, which is provided by the content interface
<lool> jdstrand: is there a pointer on using content interface and is it landed? I saw it in master but have never used it
<didrocks> jdstrand: content inteface doesn't enable to expose anything which isn't in $SNAP if I'm right, though?
<kyrofa> elopio, is that only snapd?
<didrocks> lool: I guess that's not going to fix it for you (as per ^)
<lool> didrocks: not sure what you mean
<jdstrand> lool: you need snapd 2.0.11 and snap-confine from xenial-proposed
<lool> didrocks: sounds like exactly what we'd need: autopilot shares its socket as the contents to the facedetect snap
<didrocks> you can only expose /snap/<snap_name>/<version>/
<didrocks> so the ro path
<jdstrand> lool: this PR has doc updates that better document the content interface: https://github.com/snapcore/snapd/pull/1409/files
<mup> PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1409>
<ysionneau> hmmm maybe I can create the socket in the $SNAP at build time
<didrocks> no SNAP*_DATA or anything like this
<didrocks> ah, if you create it at build time, that could work
<jdstrand> didrocks: the exported dir is bind mounted into one of the SNAP dirs
<didrocks> jdstrand: indeed, but the snap exposing the content interface requires (from the examples I saw) a path under it's $SNAP/
<lool> jdstrand: +* Auto-Connect: yes for snaps from same publisher, no otherwise
<lool> jdstrand: will it work with a devmode local snap?
<jdstrand> didrocks: suppose the service snap exports a rw path via content interface. that snap then creates a named socket in that rw path. then the plugging snap imports that rw path into its area and accessing that named socket
<jdstrand> lool: I think you can force a manual connection. I didn't implement this feature, not sure without reading the code
<didrocks> jdstrand: my point is that content interface only expose ro path (under it's $SNAP), you can't export rw path
<jdstrand> no, you can
<didrocks> that's what zyga told though at the heidelberg sprint
<jdstrand> write (slot): read-write paths from providing snap to expose to the consuming snap
<didrocks> he was going to remove the write keyword as it didn't work
<jdstrand> oh, well, this is pre-Heidelberg
<ysionneau> hmmm not sure in fact a socket can be created at build time and bind() to at runtime :/
<ysionneau> maybe the server *has* to create it :/
<lool> jdstrand: so providing snap would say slot [content:write: [foo.socket]] and consumer [content:target: [foo.socket]]
<jdstrand> if he couldn't get that to work then this technique won't work
<lool> jdstrand: how do you specify autoconnect to a fixed name snap?
<lool> ysionneau: you can probably ship a socket file in the squashfs of the snap and bind it at runtime
<ysionneau> well, that's the thing I'm not sure if it's possible
<jdstrand> lool: I think it needs to be a dir, but yes, that is the idea. as for autoconnect, aiui it is part of snapd's interaction with the store-- if from same publisher it just does it
<ysionneau> there is high chance bind()ing an already existing socket file will say "address already in use"
<jdstrand> lool: note that didrocks said that zyga said that 'write' doesn't work
<lool> jdstrand: but I dont see where one says which snap to connect to
<lool> yeah, write is needed too
<jdstrand> lool: you don't say what can connect, it just does it
<jdstrand> ie, I upload a content snap, so any plugging snap I upload will autoconnect. if you plugged my content, it would not
<lool> jdstrand: how do I say which content I want to autoconnect to?
<didrocks> lool: http://paste.ubuntu.com/22328522/
<pmp> lool: ysionneau: maybe related?! There seems to be a env-variable called $SNAP_USER_COMMON (which currently not working according to the mailing list's discussion)
<ysionneau> ok let's try the "autopilot creates the socket in /var/snap/facedetect/common" trick then
<didrocks> for a content slot example
<jdstrand> you get all the exports
<lool> didrocks: ah great
<lool> jdstrand: got it with didrocks' example
<didrocks> lool: see that you only say "/foo", and this is intended as /snap/content-slot/current/foo (so relative to $SNAP)
<jdstrand> ok
<mup> PR snapcraft#689 closed: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
<jdstrand> it's too bad that write doesn't work
<lool> pmp: There's SNAP_COMMON as well; this is the one you want
<didrocks> lool: the other side is http://paste.ubuntu.com/22328645/
<lool> pmp: USER_COMMON is per user (in home), a bit ugly IMO
<didrocks> (you need to ship an empty import/ dir in $SNAP in that case ^)
<jdstrand> I wonder what the issue would be. seems if you picked 'write' you'd look at the slotting snaps SNAP_DATA and if read the slotting snap's SNAP
<didrocks> jdstrand: that's when I told him that all paths were related to $SNAP, and so, write won't work if you can't specify which env variable you want to be relative to that he told me write is going to be removed
<lool> ----(=    (..)-----
<didrocks> but yeah, write would be relative to SNAP_DATA (if it worked)
<jdstrand> didrocks: sure, but I don't understand why all paths must be relative to SNAP. why not SNAP_DATA?
<didrocks> jdstrand: that was my question to him when this discussion happened :)
<didrocks> maybe he or I was jetlag and there is a clear answer and write is going to work
<lool> yeah, I think everything related to SNAP_DATA is more logical
<jdstrand> didrocks: I mean, snapd could even be super smart and create the dir and everything...
<lool> even read-only
<lool> don't know if symlinks would work, but that's much more useful
<lool> e.g. to share read-only view on live files
<didrocks> lool: not really, read relative to SNAP is great for sharing libs
<lool> you can always expose static contents by copy or symlink
<lool> didrocks: but you can still do it
<didrocks> jdstrand: +1 (yeah, creating it in the mount namespace)
<lool> from SNAP_DATA
<didrocks> yeah, so rather read: [SNAP_DATA/foo, SNAP/bar]
<didrocks> that would be the best
<jdstrand> my takeaway is that today write is probably broken, but that it is probably supportable
<didrocks> and same for write: (of course, relative to SNAP, that would failâ¦)
<didrocks> that would fix a lot of use case and avoid blocking on interface creation
<ysionneau> arggggg
<ysionneau> I forgot something
<jdstrand> tyhicks: so, I think I may have discovered a bug
<ysionneau> boxinit( autopilot snap) is sandboxed (chroot) ... it cannot easily create a socket in another snap's SNAP_DATA
<ysionneau> well, I can still create a mount bind before chrooting
<ysionneau> grrrrr
<jdstrand> tyhicks: just so you have code to look at, https://code.launchpad.net/~jdstrand/+git/snap-userns-test
<jdstrand> tyhicks: the issue is that I can't use clone(CLONE_NEWUSER) inside the sandbox. it doesn't seem related to nnp
<lool> ysionneau: just bind mount when starting your chroot
<lool> ysionneau: ah you've said that already
<jdstrand> tyhicks: I get EPERM and no denials. I'm starting to think it might have something to do with the namespace patches
<lool> ysionneau: or use shm!   :-)
<ysionneau> shm ?
<lool> shm_open() etc.
<ysionneau> I'm passing file descriptors via unix sockets etc
<lool> I mean stop using real sockets and files
<ysionneau> to do dmabuf (mmap)
<lool> ah yeah, dont think you can pass fds over shm
<jdstrand> shm_open() paths are mediated between snaps
<ysionneau> to send video buffers
<jdstrand> it seems like you are trying to find a hole in the sandbox (which is great, but if you find it, I will plug it :)
<jdstrand> snaps are by definition isolated from each other except though defined interfaces
<pmp> with jdstrand supporting us like this we will need to do a real interface in snapd for our needs
<lool> jdstrand: one of them is unconfined here though
<jdstrand> if all you need it a demo, then drop a rule in /var/lib/snapd/apparmor/profiles/... and run apparmor_parser -r on it after install
<lool> pmp: I can hear you branching github.com/snapcore/snapd already
<jdstrand> oh, well, if you use devmode your fine
<jdstrand> you're
<ysionneau> jdstrand: so far I found no hole, I'm using the help of a devmode snap to create the hole =)
<pmp> couldn't we add an shared-files-interfaces, or shared unix-socket interfaces - where the providing snap defines a filename and users of this snap can get this filename somehow
<jdstrand> put the file in SNAP_DATA on one and the then one in devmode can access it
<pmp> an alternative for us would be to load the snap via the market in devmode
<jdstrand> pmp: technically, sure, we could code that, however niemeyer won't approve generic interfaces like that because they are by definition not well-defined and interfaces should be well-defined
<pmp> jdstrand: ack
<lool> jdstrand: yes, SNAP_DATA is exactly what I suggest, but with COMMON to have a stable nam
<lool> name
<lool> and also a place you can use even if the snap is being removed/added
<kgunn> jdstrand: any thots on why the sendto denial happens on the first start attempt?
<pmp> jdstrand: another alternative would be to have snap implement/provide new interfaces
<pmp> jdstrand: custom ones
<pmp> jdstrand: but this won't help us for the POC
<jdstrand> kgunn: presumably because the interface isn't connected yet
<pmp> really, can't we convince webdm to load all snaps with --devmode?
<jdstrand> pmp: I'm curious what the service is-- is it public?
<jdstrand> pmp: is it webdm?
<cholcombe> how do you list which plugs are available?
<pmp> jdstrand: for the poc it is just that we'd like to have a snap insert something into our gstreamer-video-pipeline
<jdstrand> cholcombe: snap interfaces
<cholcombe> jdstrand, thanks.  i get no interfaces found :(
<pmp> jdstrand: we decided to do a face-detection
<jdstrand> pmp: this is for webdm?
<pmp> jdstrand: no
<jdstrand> hmm
<jdstrand> inserting something into a gstreamer pipeline, that sounds tricky
<pmp> so, ehm, yes, well, how to explain?...
<jdstrand> anyway, for a demo, I think one in --devmode is your best shot
<pmp> we have 2 snaps, one which contains "everything" - including a video-processing-pipeline
<pmp> we want to install the second snap, which modifies the video-stream, via the market
<jdstrand> this is essentially the plugin problem
<pmp> the market installed is done via webdm and webdm is not installing snap in devmode
<pmp> yes, I wasn't aware, but the "plugin-problem" sounds like it
<tyhicks> jdstrand: does it work in devmode?
<jdstrand> anyway, I don't mean to distract you. we won't solve the problem now
<jdstrand> tyhicks: oh, it works if I launch directly but not in strict mode. let me try devmode (silly me)
<pmp> jdstrand: every input is welcome
<pmp> just thinking, how is webdm installing snaps, if itself is a snap?
<jdstrand> well, I can promise you I will be a part of the conversation as these things are submitted :)
<jdstrand> pmp: it has access to snapd-control
<jdstrand> the snapd-control interface
<pmp> ok, logic, could it request an install in devmode?
<jdstrand> I don't see why not
 * jdstrand is not a webdm developer
<jdstrand> tyhicks: huh, it doesn't seem to work in devmode either. let me test something. gimme a sec
<mup> PR snapd#1644 opened: A gpio interface for os and gadget snap <Created by jocave> <https://github.com/snapcore/snapd/pull/1644>
<ysionneau> ok I made progress but it still does not work, I will have a look on monday, thanks guys for the help !
<ysionneau> see you !
<ysionneau> see you on monday pmp
<pmp> ysionneau: yep, bon week-end
<ysionneau> thx
<tyhicks> jdstrand: ok, I'm going to step away for a short bit and will check in when I get back
<jdstrand> tyhicks: ok, I confirmed the security policy is in complain mode and it doesn't work
<jdstrand> tyhicks: guessing it is something with snap-confine and the bind mounts then
<jdstrand> tyhicks: let me play with it
<jdstrand> tyhicks: thanks for that idea
<tyhicks> jdstrand: sounds good but don't rule out the possibility of a bug that affects complain mode, as well
<jdstrand> tyhicks: yes, but I don't want to distract you while I (dis)prove that
<mup> PR snapd#1432 closed: interfaces/builtin: improve pulseaudio interface <Reviewed> <Created by jhodapp> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1432>
<mup> PR snapd#1642 closed: many: pass device to store <Created by matiasb> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1642>
<niemeyer> jhodapp, morphis: ^^^
<morphis> niemeyer: what a weekend present :-D
<niemeyer> morphis: Just in time! ;)
<jhodapp> is it approved? :)
<morphis> jhodapp: better, merged :-)
<cholcombe> silly question but how do i give my snap a configuration file?  I'm looking through the docs and I don't see where that's mentioned
<kyrofa> cholcombe, what do you mean?
<cholcombe> kyrofa, i need to give my daemon a config file to start up properly.  where do i put that in that snap?
<sergiusens> kyrofa I think cholcombe is talking about configuration hooks ;-)
<kyrofa> cholcombe, you mean how do you get a config file into the snap itself using snapcraft? Or provide it at runtime?
 * sergiusens goes for lunch
<kyrofa> cholcombe, does the config file need to be altered at runtime, or is it something you can distribute in the snap yourself?
<cholcombe> kyrofa, well ideally it should be user provided.  i don't know the credentials to their database, etc
<cholcombe> kyrofa, no i can't distribute it
<kyrofa> cholcombe, ah, indeed, then sergiusens is right
<cholcombe> kyrofa, are there docs for the config hooks? :)
<kyrofa> cholcombe, heh, they don't exist yet. I'm writing them right now :P
<cholcombe> haha
<kyrofa> cholcombe, the hooks themselves, I mean
<kyrofa> cholcombe, but, you said something a little concerning
<cholcombe> oh yeah?
<kyrofa> cholcombe, snaps are supposed to bundle their dependencies. But it sounds like you haven't-- what database are you connecting to?
<cholcombe> i'm connecting to influxdb
<cholcombe> i assume that will be provided by the end user
<cholcombe> is that a bad thing to assume?
<cholcombe> i don't want influxdb to live on the same host as i'm installing this snap on
<kyrofa> cholcombe, no, that sounds reasonable
<cholcombe> this snap i'm building collects metrics and sends them off
<elopio> kyrofa: no, it seems we lost the daily snapcraft job in one of the reboots.
<kyrofa> cholcombe, actually, before we go anything further-- are you using 15.04, or the in-progress 16 series?
<elopio> kyrofa: do you need it? It's really easy to set up.
<cholcombe> kyrofa, i'm on 16.04
<kyrofa> elopio, cholcombe wanted to try out the rust plugin
<cholcombe> kyrofa, yeah the rust plugin works great
<cholcombe> that's all fine.  i built snapcraft from the source tree and i'm using that
<cholcombe> it's the config file business i'm stuck on now
<kyrofa> cholcombe, okay, so you know snapd is still being developed for 16, right? Obviously you're free to use it, but you'll run into this type of thing (e.g. config not being completed)
<kyrofa> cholcombe, if you're okay with that, you have a few options
<cholcombe> kyrofa, oh i didn't know that
<cholcombe> i mean i'm fine using whatever
<kyrofa> cholcombe, you're on the cutting edge!
<cholcombe> i can back off to 15.10.  that's no problem
<kyrofa> cholcombe, it's up to you. If you can deal with the current limitations you might be happier sticking with 16 since 15 is pretty much end-of-life
<cholcombe> kyrofa, i just thought 16.04 was the stable one to use.
<kyrofa> cholcombe, 16.04 desktop, definitely. But the snap side is still being developed
<cholcombe> kyrofa, that's fine
<kyrofa> Okay, so here's what you can do
<cholcombe> i'm basically just kicking the tires here.
<kyrofa> Rather, let's talk about how this WILL work real quick
<cholcombe> sure
<kyrofa> cholcombe, when I'm done, your users will be able to call `snap set <yoursnap> username=<username> password=<password>`
<cholcombe> interesting
<kyrofa> That will end up calling an executable contained within your snap located at meta/hooks/apply-config
<kyrofa> That's all snapd will do for you. The apply-config executable you provide will need to handle those parameters and write them to the config file you intend
<cholcombe> ok that's no problem
<elopio> hum, all the slaves died. How lucky.
<kyrofa> cholcombe, so: that doesn't exist yet. What I suggest you do is write something that fits similar logic though, and expose it via the apps: keyword like everything else
<cholcombe> kyrofa, ok
<kyrofa> Then your users can just call it directly for the time-being, and once config hooks land, the amount of work you have to do is minimal
<cholcombe> kyrofa, cool.  that sounds fine
<kyrofa> cholcombe, remember the snap only has a few places it can write (I'm not sure how long you've been kicking the tires)
<cholcombe> kyrofa, for about a week :)
<kyrofa> cholcombe, so you know about SNAP_DATA, SNAP_USER_DATA, etc.?
<cholcombe> kyrofa, i do yeah
<kyrofa> cholcombe, you're set then. Let me know if I can help any more!
<cholcombe> kyrofa, thanks :)
<lool> ogra_: do you have a reliable rpi3 classic image?
<lool> ogra_: I used a community one a while back, but it had misinstalled .debs and such, and relied on a PPA
<ali1234> lool: the official rpi2 classic image has misinstalled debs and relies on a ppa, so i doubt you'll find anything for the rpi3
<lool> ali1234: oh wow really? I don't remember hitting this with our official rpi2 server image
<ali1234> lool: yeah, it's broken
<ali1234> lool: dist-upgrade breaks networking
<ali1234> you can't use hats because the dt overlays are missing
<lool> ali1234: crap, is there a workaround for the dist-upgrade?
<ali1234> and you need a ppa to do anything with opengl
<lool> I dont care about hats that much
<lool> nor opengl
<ali1234> lool: yes, hack the /etc/netowkr/interfaces manually until it works
<ali1234> the issue is systemd persistent interface names
<lool> Ah
<ali1234> the base image expects that disabled. after dist-upgrade you cant disable them
<ali1234> and yes i reported these bugs on launchpad
<elopio> kyrofa: cholcombe: https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily it's enabled again.
<kyrofa> Thanks elopio!
<cholcombe> elopio, nice :)
<JamesTait> I can't help thinking this is a question that must have been asked before, but I haven't found an answer: I'm pretty sure my (cuberite) snap is hitting some seccomp constraint when running confined which results in the process being killed. How can I trace the call that's causing that?
<jdstrand> JamesTait: look in /var/log/syslog. easiest is to install snappy-debug then do: sudo /snap/bin/snappy-debug.security scanlog
<JamesTait> Ah - I thought that only gave output for apparmor-related stuff?
<jdstrand> JamesTait: if you look just in /var/log/syslog, you'll need to use scmp_sys_resolver NN to resolve the syscall number
<jdstrand> JamesTait: nope, seccomp too (it will resolve syscalls for you)
<JamesTait> Then I think it's the fchown call, which I think comes from libsqlite3. ð
<JamesTait> But armed with the knowledge, I'll have a more thorough dig into the problem this evening. Thanks jdstrand!
<jdstrand> once the snap-confine in xenial-proposed finally lands, I'll be able to make some changes to allow fchown to your own uid
<kgunn> jdstrand: success! fully confined....will do final clean ups
<JamesTait> jdstrand, that sounds great, can't wait!
<jdstrand> kgunn: nice!
<JamesTait> Have a great weekend, folks!
 * JamesTait waves
<tsimonq2> sergiusens: when's the next release planned?
<sergiusens> tsimonq2 almost today
<sergiusens> why?
<tsimonq2> just curious
<tsimonq2> and what does almost mean?
<tsimonq2> :P
<tsimonq2> I guess my question is, do I have a chance of getting stuff in before the next release?
<ogra_>  lool only a snappy one from yesterady, no classic ...
<ogra_> lool, http://people.canonical.com/~ogra/snappy/all-snaps/all-snaps-pi3.img.xz in case that helps in any way ("sudo snap install classi --devmode --edge" works fine as well in case you need a classic env ... (use "sudo classic.create" and classic.shell with it )
 * ogra_ vanishes back into the hight
<kyrofa> Hight. Must be a German word
<ssweeny> pretty short for a German word
<kyrofa> tsimonq2, probably not
<kyrofa> ssweeny, haha, no kidding!
<tsimonq2> kyrofa: alright thanks
<tsimonq2> kyrofa: nice catch re: bug 1586423
<mup> Bug #1586423: File-based sources (.tar, .zip, etc.) should show a progress bar when downloading <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1586423>
<Guy1524> how does snap contain programs?
<Guy1524> nvm
<kgunn> sergiusens: i just thot of an interesting feature for snap ...remove-all, or has someone already asked for this ?
<sergiusens> kgunn I am totally out of context
<kgunn> sergiusens: was just thinking, as developers may pull down a clean core...then install a bunch of snaps, they may want to take it back to a clean core
<kgunn> e.g. i've got 2 snaps...now and was just thinking it'd be nice to have one shot wipe them both
<kgunn> and i suspect over time people will load more than 2 and have the same feelig
<kyrofa> kgunn, https://github.com/zyga/devtools/blob/master/reset-state ?
<kgunn> kyrofa: ah nice...does that work with vm's? or just local
<kyrofa> kgunn, I've only run it local
<Guy1524> I have a question, why does snap need to duplicate libraries, couldn't libraries be isolated separately from applications so duplicates of the same library version don't exist
<mup> PR snapcraft#712 opened: New plugin: dump <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/712>
<kgunn> jdstrand: just letting you know, i'm trying to go back through all the confinement one more time...i'm noticing there's a variety of denials that occur BUT i can still launch my app
<kgunn> so i'm guessing those are errant
<mup> PR snapd#1645 opened: interface: add transitional browser interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1645>
<jdstrand> kgunn: if you collect them in a paste, I can have a look
<niemeyer> jdstrand: ping
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Trying to get to some quick agreements on the browser interface so we can land it
<jdstrand> tyhicks: fyi, the CLONE_NEWUSER is resolved if I use the ubuntu-core-launcher in the archive. seems like a problem with snap-confine
<jdstrand> niemeyer: ok
<niemeyer> jdstrand: We need a new suffix for interfaces which say "this is what I need from the system to work"
<jdstrand> yeah. it's weird cause that is kinda true for all of them
<jdstrand> access... but that doesn't really cut it
<jdstrand> tbh, I picked browser cause it was sorta like 'home'
<jdstrand> in that it was a pure perm
<niemeyer> Yeah.. harness, although not quite.. hmm
<niemeyer> -support!
<jdstrand> oh
<jdstrand> that is pretty good
<jdstrand> niemeyer: I think that is good
<niemeyer> Let's do it
<jdstrand> ok
<niemeyer> About hte sandbox option
<jdstrand> niemeyer: thoughts on allow-browser-sandbox vs sandbox?
<jdstrand> heh
<niemeyer> jdstrand: How does chrome call the feature internally?
<niemeyer> Is it "sandbox" simply?
<jdstrand> sandbox
<jdstrand> they have different sandboxes
<jdstrand> setuid, usernamespace, seccomp
<jdstrand> but I didn't want to expose all that
<jdstrand> firefox also calls it a sandbox
<jdstrand> use-internal-sandbox?
<niemeyer> Ok, so we can't avoid the term.. hmm
<niemeyer> Seems too much like the sandbox is about snapd
<jdstrand> yeah
<jdstrand> use-browser-sandbox?
<jdstrand> we're pretty close to what I initially suggested :)
<jdstrand> browser-sandbox?
<niemeyer> can-sandbox feels okayish, I think
<niemeyer> browser-support... can-sandbox..
<niemeyer> allow-sandbox isn't bad either
<niemeyer> (which was your first term suggestion)
<niemeyer> Alternatively, we might break that down
<niemeyer> jdstrand: How specific to browser are those bits?
<niemeyer> jdstrand: Would sandbox-support make sense on its own?
<ahoneybun> mm wonder about that dbus-bind
<niemeyer> ahoneybun: What are your wonders? :)
<jdstrand> in this transitional interface, right this second, not very. but I'd like to use a child profile at some point that would be
<ahoneybun> when it's coming
<niemeyer> Soon!
<niemeyer> ahoneybun: What are your needs?
<ahoneybun> Pithos can't run without a service
<jdstrand> niemeyer: so, I was trying to avoid a general sandbox-support right now, cause I don't yet understand how we can make it general
<jdstrand> I know what the browsers need, right this second, so was trying to just do it all there with an attribute
<jdstrand> of course, I guess there is nothing saying the attribute itself can't be 'sandbox-support'
<ahoneybun> niemeyer: http://pastebin.ubuntu.com/21338511/
<jdstrand> that would look slightly weird
<jdstrand> niemeyer: I could just use 'sandbox: true' and handle it in the documentation
<camako> trying to run 'snapcraft cleanbuild' on my snap, but I'm getting "500  Internal Server Error"... here's the log ---> http://pastebin.ubuntu.com/22354532/
<niemeyer> jdstrand: If browsers need it and we know they need it, why is it behind an attribute, considering the only purpose of said interface is the browsers who need it?
<jdstrand> this is really only meant for the major vendors in the short-medium term, not everyone in the world and not forever
<jdstrand> niemeyer: well, not all browsers need it. did you see my rather long description?
<camako> my lxd otherwise appears sane... anyone have an idea?
<jdstrand> eg, electron doesn't need that
<jdstrand> niemeyer: in other words, I expect only google and mozilla to use (and be able to use) sandbox: true. people just embedding webviews don't need it
<niemeyer> jdstrand: I see.. let met review the sandbox-specific code once more
<jdstrand> niemeyer: do read my (I know its lengthy) description though-- it gives justification for the implementation, talks about the store, etc
<niemeyer> jdstrand: I skimmed through it all, but need to re-read enough to understand it
<jdstrand> niemeyer: this also isn't the 'forever interface'. this is the 'today interface'. as we implement more and more we can move stuff out of the browser-support interface into non-transitional interfaces. I suspect one of those is user-namespace-support
<jdstrand> (for example)
<niemeyer> jdstrand: I have a feeling we'll live with this interface for a long time :)
<jdstrand> but I was asked to unblock all this with a transitional interface
<jdstrand> eh
<niemeyer> jdstrand: It's responable, not complaining.. just being realistic
<jdstrand> I don't know. we can get rid of all but oom_score_adj in the medium term for 'sandbox: false'. then most of sandbox: true is in 'user-namespace-support'
<niemeyer> reasonable
<niemeyer> jdstrand: Reading through the code, I'm not sure.. it feels like there's a lot of stuff that is there just because the browser happens to do it rather than being specific to sandboxes
<jdstrand> yes
<jdstrand> but we can fix that with various things
<jdstrand> like the preload library
<niemeyer> jdstrand: It seems better to be honest and have a wildcard browser interface that fixes the problem at hand than to generalize it poorly with unclear settings
<jdstrand> or a kernel patch to allow safe use of ptrace
<niemeyer> (which is exactly what you're doing there)
<niemeyer> (the being honest part :)
<niemeyer> jdstrand: Okay, let's go with browser-support + allow-sandbox
<jdstrand> right, I didn't want to generalize poorly, which is why user-namespace-support is not a thing yet
<jdstrand> ok
<niemeyer> jdstrand: Hold fire, let me add a couple more comments and we can try to merge the next push
<jdstrand> niemeyer: note that zyga once dinged my for your suggestion of 'allowSandbox, _ := plug.Attrs["allow-sandbox"].(bool)'
<jdstrand> s/my/me/
<jdstrand> niemeyer: he said I should use the method I am since I want to test for the presence of the attribute first and then test if the bool or not
<jdstrand> well
<jdstrand> I already did that in SanitizePlug
<jdstrand> niemeyer: ok, nm
<niemeyer> jdstrand: Ok, done
<niemeyer> jdstrand: Just trivials..
<jdstrand> niemeyer: the unity7 change was in fact needed for chrome. do you want another PR?
<niemeyer> jdstrand: If it's related it's fine
<niemeyer> jdstrand: Let me know when you're done
<jdstrand> just running ./run-tests
<jdstrand> github has a much nicer way of showing the changes after a git mv than 'git show'
<jdstrand> ok, pushed but let me double check twith real snaps
<niemeyer> jdstrand: Thanks!
<niemeyer> jdstrand: renames in git are a bit weird
<niemeyer> jdstrand: It's all detection based
<niemeyer> Sometimes github shows really awkward "renames", when files are too small.. it thinks it's a move as the license header remains the same
<niemeyer> jdstrand: One of the trivial code improvement suggestions didn't land.. no biggie though
<mup> PR snapd#1637 closed: cmd/snap,cmd/snap-exec: support hooks again <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1637>
<niemeyer> ahoneybun: Sorry for the trouble there.. will try to get the dbus iface in sooner rather than later
<niemeyer> jdstrand: On those topics, we need to find a good name for that general dbus interface
 * jdstrand notes running 5 snapcraft's in parallel on big snaps is probably not the best idea
<kyrofa> jdstrand, pshh. Half the time is pulling anyway
<kyrofa> jdstrand, perhaps you should start them staggered, though
<jdstrand> not on these snaps :)
<kyrofa> Oh :P
<kyrofa> jdstrand, what is a big snap that doesn't involve pulling?
<kyrofa> jdstrand, also, why aren't you using launchpad to build them?
<jdstrand> it involves pulling
<jdstrand> it is just the other bits take a long time too
<sergiusens> jdstrand snap try!
<jdstrand> chrome, chromium, firefox, electron and vscode all in parallel
<jdstrand> no, I needed real snaps
<jdstrand> anyway
<kyrofa> Ah, very nice
<jdstrand> it's done
<jdstrand> niemeyer: ok, I pushed the simplification. things are good on my end
<niemeyer> jdstrand: Cool, will just wait for tests
<niemeyer> jdstrand: dbus-object is an interesting candidate for that other interface
<jdstrand> niemeyer: hmm, it is. I've got a hard stop in 4 minutes. I'll think about that and maybe we can pick up on Monday?
 * jdstrand used dbus-app since it had mild acceptance on the list, but is happy to change it
<niemeyer> jdstrand: Yeah, let's talk on Monday
<niemeyer> jdstrand: Have a good weekend
<jdstrand> niemeyer: have a nice weekend :)
<jdstrand> heh
<niemeyer> !
<niemeyer> :)
<niemeyer> Thanks
<jdstrand> niemeyer: something with freedesktop in the name might be interesting too (it is  af.d.o spec)
<jdstrand> thank you
<jdstrand> too :)
<jdstrand> gotta run! :)
<mup> PR snapd#1636 closed: snap: don't load unsupported implicit hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1636>
<mup> PR snapd#1645 closed: interface: add transitional browser-support interface <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1645>
<mup> PR snapd#1646 opened: cmd/snap,overlord/hookstate: support hook data transfer <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1646>
#snappy 2016-08-06
<netphreak> Hi, guys!
<cjwatson> 14:20 <ogra_> cjwatson, so whom do i have to bribe to have s390x for https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ? (the setup page just talks about "Admins" )
<cjwatson> ogra_: done
<netphreak> What's the status on Ubuntu Core in RPI 3?
<ogra_> cjwatson, thanks (building) :)
<ogra_> yay ... and auto uploads work too !
<ogra_> (to bad that type:os is auto-blocked and i now get spammend for every upload :P )
<ogra_> cjwatson, hmm, something seems still wrong, it failed to build but i dont see a build log
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2539
<cjwatson> ogra_: The lack of log is a slight exception-catching problem in launchpad-buildd, fixed in my local tree now.  The actual problem looks like a firewall bug though; seems that the s390x builders can't talk to snap-proxy.launchpad.net.  File a bug on launchpad-buildd and I'll look into it when it's work time.
<ogra_> cjwatson, will do, thanks for checking
<kevinmcquown> does anyone on this channel know if ubuntu core supports access to the gpio pins on a raspberry pi 2 ?  I am looking to access the uart pins to communicate with another microcontroller.
<ali1234> kevinmcquown: there is no interface for that yet
<kevinmcquown> ok, unfortunate that ubuntu core is targeted to embedded internet of things devices but doesn't still support simple communication to other hardware devices using serial, i2c or spi
<kevinmcquown> I'm guessing this will have to be resolved and supported by LTS 16 release in a couple of months?
<kevinmcquown> I do see under snapcraft.io > interfaces a reference to serial-port, where the description says "Can access serial ports. This is restricted because it provides privileged access to configure serial port hardware."
<lool> ogra_: yeah I had followed your work on the updated series 16 image, I'll likely use it â thanks for that! â but I was also looking for a corresponding pi2 image
<ogra_> lool, http://people.canonical.com/~mvo/all-snaps/16/ has the pi2 equivalent
<lool> ogra_: yep, seen that too first
<lool> i have all of them here including the server rpi2 image
<mup> PR snapd#1646 closed: cmd/snap,overlord/hookstate: support hook data transfer <Created by kyrofa> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1646>
<qengho> I have snapd running on a beaglebone with U 16.04.
<qengho> One of my packages runs fine on amd64.
<qengho> Here, it stops. I think the cause is near this message in syslog:  """ubuntu-core-launcher[25729]: unable to mount '/dev/pts/ptmx'->'/dev/ptmx'. errmsg: Permission denied"""
<qengho> AND
<qengho> '''apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 parent=1 profile="/usr/lib/snapd/snap-confine" name="/dev/ptmx/" pid=25729 comm="ubuntu-core-lau" srcname="/dev/pts/ptmx/" flags="rw, bind"'''
<Pharaoh_Atem> zyga: I see you finally submitted go-check to stable
<mup> PR snapd#1638 closed: interfaces: add uefi-manager interface <Created by timchen119> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1638>
<mup> PR snapd#1631 closed: client, osutil: chown the auth file	 <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1631>
#snappy 2016-08-07
<tachyons> Hi
<tachyons> What does this error means
<tachyons> https://paste.gnome.org/pmcynf3br
<tachyons> unknown policy-vendor 'ubuntu-core'
<mup> PR snapd#1647 opened: many: various fixes around the `create-user` command <Created by niemeyer> <https://github.com/snapcore/snapd/pull/1647>
<mup> PR snapd#1600 closed: many: various fixes around the `create-user` command <lp> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1600>
<mup> PR snapd#1644 closed: interfaces/builtin: add gpio interface <Created by jocave> <Conflict> <https://github.com/snapcore/snapd/pull/1644>
<trijntje> I have snapped an application and added an icon to it. When I start it from the dash it uses the proper icon in the unity bar. However, when I start it from the terminal it uses the default java icon. Anyone know how to fix this?
<mup> PR snapcraft#712 closed: New plugin: dump <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/712>
#snappy 2017-07-31
<mup> PR snapcraft#1431 closed: tests: do not check the opencv command if it wasn't installed <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1431>
<zyga-ubuntu> goot morning
<pstolowski> good morning!
<zyga-ubuntu> pstolowski: hola!
<zyga-ubuntu> pstolowski: are you back from holidays?
<pstolowski> zyga-ubuntu, hola! yes
<zyga-ubuntu> pstolowski: how was it?
<zyga-ubuntu> pstolowski: it's been raining like crazy here
<zyga-ubuntu> morphis: hey
<morphis> zyga-ubuntu: hey
<pstolowski> zyga-ubuntu, yeah, i know.. it's been fantastic. we managed to carry our plans through wrt visiting places in barcelona, all worked great
<pstolowski> zyga-ubuntu, we also went to girona the other day; is this the place where you lived?
<zyga-ubuntu> pstolowski: no, but we visited girona much more often than barcelona
<zyga-ubuntu> pstolowski: we were 30 minutes away from girona, at the coast
<zyga-ubuntu> pstolowski: in Palamos
<zyga-ubuntu> pstolowski: any plans to go back for holidays next year?
<pstolowski> zyga-suse, not really, we will probably finally go to Tatry mountains next year, we postponed this for too long
 * zyga-ubuntu iterates on the new test...
<janisozaur> zyga-ubuntu: hi. I was trying to proceed a little with snapd on Arch, but didn't go far. Mostly just updated package locally to use .14 version and then git one
<zyga-ubuntu> janisozaur: hey, nice!
<janisozaur> .14 didn't solve my issue
<zyga-ubuntu> janisozaur: I updated my arch vm and got into some isuses where I couldn't use gnome anymore :/
<zyga-ubuntu> janisozaur: I wanted to reproduce the bug you reported
<janisozaur> currently, the tests in the package are disabled
<zyga-ubuntu> janisozaur: which snap did you try and which intel CPU do you have?
<zyga-ubuntu> janisozaur: I think they were disabled when arch moved the /snap directory away
<janisozaur> there is at least one test that fails (maybe more, but it bailed out on that first one)
<janisozaur> TestInternalToolPathWithReexec
<zyga-ubuntu> janisozaur: I think the unit tests could pass now as fedora did the same thing and over time more and more tests were adapted
<zyga-ubuntu> janisozaur: let's do this
<zyga-ubuntu> janisozaur: I'll commit current arch packaging to snapd master
<zyga-ubuntu> janisozaur: and I'll start proposing patches to that improve it
<zyga-ubuntu> janisozaur: would you be interested in reviewing them?
<janisozaur> I have two machines: trurl {i7 4790k, gtx 960 + proprietary drivers}, klapaucjusz {laptop: i5 5300U, hd 5xx}
<janisozaur> both running Arch
<zyga-ubuntu> janisozaur: I have the same CPU in my laptop, I could try arch on it natively
<zyga-ubuntu> janisozaur: (the i5300U)
<zyga-ubuntu> is that a thinkpad by any chance?
<janisozaur> yes, 2015 L450
<zyga-ubuntu> I think that's close enoug, I have an x250
<janisozaur> I can get a hold of i5 6200U with ubuntu 17.04 on it, if needed
<janisozaur> sure, if I can help in any way, I'd be interested in reviewing the changes
<janisozaur> mind you, all of snapcraft is new to me
<zyga-ubuntu> janisozaur: no, for now I think we need a forum thread that details the issue, with backtraces, snap names and snap versions
<zyga-ubuntu> so that more people can find this and we can rally support
<janisozaur> sureâ¦ I'll report my findings in that thread you linked on Friday
<zyga-ubuntu> thank you!
<janisozaur> what's the plan/ETA for 2.27?
<zyga-ubuntu> janisozaur: that's mvo's decision, I think it's very soon (perhaps he even tagged it)
<janisozaur> github doesn't show a tag just yet
<zyga-ubuntu> mvo often pushes the tag out with a PR that proposes merging the release back to master
<janisozaur> it would be nice if the opengl on Arch could be taken care of before the release takes place
<janisozaur> i see there are a lot of patch releases, too?
<zyga-ubuntu> yes, we were trying to get 2.26.x right
<zyga-ubuntu> but each release was followed by one more as we found new edge cases
<zyga-ubuntu> somewhat tiresome process but many of the issues we found were there for a long time, it seems 2.26 was just used more than any other release
<janisozaur> i know the pain :D
<janisozaur> ok, i'll work on it a bit when I'm home, feel free to suggest any debug methods you would find suitable
<zyga-ubuntu> janisozaur: thank you, I'll propose the PR for arch packaging in a moment
<janisozaur> to recap, a sample snap with plugs [opengl, x11]: on intel glxinfo reports error about being unable to find suitable config; on nvidia outright crashes
<janisozaur> and TestInternalToolPathWithReexec fails when trying to enable tests in the PKGBUILD using current master
<zyga-ubuntu> janisozaur: ack
<zyga-ubuntu> Chipaca: how are you doing?
<Chipaca> zyga-ubuntu: not bad! you?
<zyga-ubuntu> Chipaca: good, fixing some cross-distro things
<zyga-ubuntu> Chipaca: found a bug you may want to know about
<zyga-ubuntu> Chipaca: snap install core; snap install stuff
<zyga-ubuntu> that works
<zyga-ubuntu> Chipaca: snap install stuff
<zyga-ubuntu> that is broken
<Chipaca> waht
<zyga-ubuntu> Chipaca: broken on debian 9
<zyga-ubuntu> Chipaca: the reexec logic is flawed there
<zyga-ubuntu> Chipaca: it is repeatable 100%
<Chipaca> silly debian 9
<zyga-ubuntu> Chipaca: if you want to see, I cna give you a test case now
<Chipaca> zyga-ubuntu: is this a regression?
<zyga-ubuntu> Chipaca: not sure
<zyga-ubuntu> Chipaca: but I think now
<zyga-ubuntu> not*
<zyga-ubuntu> it's been there forever
<zyga-ubuntu> just finishing a test run and I'll commit and push
<scoopex> if i build the snap package using "snapcraft" and install the package over the existing previous downloaded package using "snap install --dangerous *.snap" i do not get my modifications. i am pretty new in snap packaging, probably i am doing something wrong...any hints?
<zyga-ubuntu> scoopex: how do you determine that you do not get your modifications?
<Chipaca> zyga-ubuntu: then let's get 2.27 out before tackling it
 * zyga-ubuntu -> breakfast
<zyga-ubuntu> Chipaca: mmm somewhat unhappy about it as it affects everyone on re-executing systems
<zyga-ubuntu> Chipaca: but I'll just defer to mvo's decision
<zyga-ubuntu> Chipaca: I want to have a test that breaks first
<zyga-ubuntu> Chipaca: so that we can show it's really there and that it got really fixed
<Chipaca> zyga-ubuntu: yes, but everyvody everywhere would be disserviced by messing up our releases again
<zyga-ubuntu> Chipaca: I'd only agree if it wasn't the "I cannot use your release because the delivery mechanism is broken bug"
<zyga-ubuntu> Chipaca: but I also ack the fact that not everyone is affected
<Chipaca> zyga-ubuntu: I too will defer to mvo on this. The above is my opinion, but as those things go it's not a particularly strongly-held one.
<zyga-ubuntu> Chipaca: ack
 * zyga-ubuntu had a good breakfast, let's see how tests are doing
 * zyga-ubuntu adds opensuse to OOTB test
<janisozaur> zyga-ubuntu: are there any tests for opengl?
<zyga-ubuntu> janisozaur: no, not at present
<zyga-ubuntu> janisozaur: we can add tests that can be executed on real hardware but nobody attempted this yet
<janisozaur> hmm, too bad
<zyga-ubuntu> janisozaur: it wasn't easy TBH
<zyga-ubuntu> janisozaur: and arch has no tests yet
<zyga-ubuntu> note that there are two types of tests
<janisozaur> given that in my case even swrast fails, or so it seems, perhaps that could be a step 1?
<zyga-ubuntu> there are unit tests that test mainly snapd internals
<zyga-ubuntu> and there are tests (ran via spread, a separate tool)
<zyga-ubuntu> janisozaur: that test the whole system
<zyga-ubuntu> janisozaur: (all of them are in thest tests/ directory)
<zyga-ubuntu> janisozaur: we can now run spread tests against an "external" target, which is anything one can ssh into
<zyga-ubuntu> janisozaur: as well as a whole array of virtual machines, both local and in the cloud
<janisozaur> sounds nice, but launching opengl apps remotely is always tricky
<zyga-ubuntu> janisozaur: remotely as through ssh?
<zyga-ubuntu> I think it should work, we can unset / set env variables as desired
<zyga-ubuntu> and this gives us the advantage of keeping the same testing systme which is very flexible
<zyga-ubuntu> janisozaur: once this is working we can establish some nightly tests in a QA lab
<zyga-ubuntu> ok, little by little
<zyga-ubuntu> this test will be very useful (I'm talking about out-of-the-box tests I've just added) for package refreshes
<zyga-ubuntu> morphis: where do I send updates to snapcraft.io page like https://snapcraft.io/docs/core/install-opensuse
<zyga-ubuntu> Chipaca: is mvo around today?
<Chipaca> zyga-ubuntu: no; gustavo comes back before mvo remember?
<Chipaca> zyga-ubuntu: in fact I'm wondering if I shouldn't do something like work on 20% projects until Wednesday
<Chipaca> zyga-ubuntu: 'cause it's just you and me afaik
<Chipaca> zyga-ubuntu: going to be hard to get two reviews :-)
<Chipaca> or, i could take the day off and go for a ramble
<Chipaca> it's lovely outside
<zyga-ubuntu> Chipaca: and when are gustavo and mvo coming back?
<zyga-ubuntu> Chipaca: haha
<zyga-ubuntu> Chipaca: indeed, it's a great day here in Warsaw as well
<zyga-ubuntu> Chipaca: I need to go out today, to register my company, it officially shoud start running tomorrow
<Chipaca> zyga-ubuntu: I don't have mvo's nor niemeyer's leaves on my calendar
<ogra_> well, niemeyer mailed
 * zyga-ubuntu looks
<Chipaca> ogra_: wait, we're supposed to _read_ those?
<ogra_> (havent heard of mvo vacation thozugh ...)
<Chipaca> zyga-ubuntu: "off until thursday" says gustavo
<zyga-ubuntu> offtopic, I bought an used book on saturday night
<morphis> zyga-ubuntu: https://github.com/CanonicalLtd/snappy-docs
<ogra_> Chipaca, nah, you're supposed to write a bot that doe it for you and crate a snap from it :P
<zyga-ubuntu> (like midnight-night)
<zyga-ubuntu> and it just arrived, from india
<zyga-ubuntu> how is that even possile
<zyga-ubuntu> *possible
<Chipaca> zyga-ubuntu: crushing poverty and very lax work laws
<Chipaca> zyga-ubuntu: or robots
<Chipaca> zyga-ubuntu: but i wouldn't count on it being robots
 * zyga-ubuntu imagines human uber drivers driving shiny robots to work each day
<ogra_> robots ?
<zyga-ubuntu> yes
<zyga-ubuntu> why not
<ogra_> "they are stealing our joobs !"
 * ogra_ sighs ... 
<ogra_> so testing an rfkill script for someone else on a system that has no local logins was obviously not a clever move
<ogra_> but at least i know rfkill works reliably on the pi3
<zyga-ubuntu> ogra_: in the future, robots will have human animals as pets
<zyga-ubuntu> ogra_: lol!
<zyga-ubuntu> nice
 * ogra_ hacks the SD 
 * zyga-ubuntu imagines someone hacking the SD card with a huge hammer against an huge anvil
<ogra_> nah, i use pliers ...
<zyga-ubuntu> Chipaca: quick idea
<zyga-ubuntu> Chipaca: a one-like patch that skips core config on debian?
<ogra_> oh! i found a bug !
<Chipaca> ogra_: you're holding it wrong
<Chipaca> zyga-ubuntu: how does that help?
<zyga-ubuntu> Chipaca: the bug doesn't happen then, the bug is because we hang on configure
<zyga-ubuntu> Chipaca: AFAIR we considered this before
<zyga-ubuntu> ok, ready to push
<ogra_> can someone who has more knowledge about snap aliases comment on https://forum.snapcraft.io/t/aliyundup-snap-based-on-python/1458 ?
<ogra_> ah, well ... found the issue myself
<mup> PR snapd#3635 opened: tests: add out-of-the-box test suite <Created by zyga> <https://github.com/snapcore/snapd/pull/3635>
<zyga-ubuntu> Chipaca: https://forum.snapcraft.io/t/snapd-out-of-the-box-experience-debian-9/1484/2
<zyga-ubuntu> Chipaca: to run the broken test you need to run linode:debian-unstable-64:tests/ootb/install-1st-snap-and-core
<zyga-ubuntu> Chipaca: (and remove the code that disables it in the task.yaml)(
<zyga-ubuntu> hmm
 * zyga-ubuntu had a bad spread day
<zyga-ubuntu> Son_Goku: I'm looking after distros today
<zyga-ubuntu> Son_Goku: so I should get to that 32 bit bug
<zyga-ubuntu> sigh
<zyga-ubuntu> it seems I need to re-organize spread tests
<Chipaca> zyga-ubuntu: why?
<zyga-ubuntu> I want a suite that doesn't do anything
<zyga-ubuntu> and each test just runs in a pristine distro
<zyga-ubuntu> I almost feel like it's not supposed to be in snapd
<ogra_> just add "exit 0" at the top :P
<Chipaca> zyga-ubuntu: ah, and we have prepare too far up for you to be able to do that?
<zyga-ubuntu> yes
<zyga-ubuntu> I tried to be "smart"
<zyga-ubuntu> but it seems spread is not
<zyga-ubuntu> have a look at 3635 please
<zyga-ubuntu> hmm :/
<Chipaca> zyga-ubuntu: I'm not sure what I'm looking at
<Chipaca> zyga-ubuntu: in the console log i mean
<zyga-ubuntu> not the console
<zyga-ubuntu> the diff
<zyga-ubuntu> I tried to disable the steup
<zyga-ubuntu> *setup
<zyga-ubuntu> but this breaks legitimate tests
<zyga-ubuntu> not sure why
<Chipaca> ah, that's two of us then :-)
<Chipaca> the diff seems ok
<Chipaca> i can only assume there's a bug in it that's not immediately obvious
<zyga-ubuntu> I'll keep digging, thanks for looking
<popey> is mvo in vacation? not seen him about for a bit.
<zyga-ubuntu> I think so
 * zyga-ubuntu tries coffee using turkish brew recipe
<zyga-ubuntu> (well, kind of, not all hardware required was present)
<popey> k
 * Chipaca ~> afk
<mup> PR snapcraft#1424 closed: Release changelog for 2.33 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1424>
<janisozaur> huh? 2.26->2.33?
<janisozaur> or snapd.version != snapcraft.version?
<Chipaca> janisozaur: snapd and snapcraft are distinct projects
<Chipaca> so, the latter
 * Chipaca really afk now
<cachio> zyga-suse, any idea about this error in the pi3
<cachio> https://paste.ubuntu.com/25194761/?
<zyga-ubuntu> cachio: hey
 * zyga-ubuntu looks
<cachio> tx
<zyga-ubuntu> well, connection refused is probably because the socket is there but snapd is dead
<zyga-ubuntu> can you interact with the system?
<cachio> didn't try yet
<zyga-ubuntu> ssh into the box and check the status of snapd.service please
<zyga-ubuntu> that's my guess
<cachio> I'll try, but I need to write the ssd again
<cachio> zyga-ubuntu, I had to use it for dragonboard
<zyga-ubuntu> aha
<zyga-ubuntu> you mean the SD cards?
<zyga-ubuntu> I'd recommend to have x2 many SD cards as you have boards
<zyga-ubuntu> just get and expense them
<zyga-ubuntu> 8/16GB should do
<zyga-ubuntu> they die randomly and you will need spares
<zyga-ubuntu> and it's useful to have a "side B" to test (a 2nd card for experiments while the main card for given device has some important data)
<zyga-ubuntu> cn
<zyga-ubuntu> Chipaca: are you going to make it for the standup?
<Chipaca> yikes
<Chipaca> zyga-ubuntu: yes
<cachio> zyga-ubuntu, well, I see there is a previos error
<cachio> gzip: stdout: Structure needs cleaning
<cachio> that is making the setup tail
<cachio> fail
<cachio> https://paste.ubuntu.com/25213261/
 * ogra_ hands zyga-ubuntu a mop to clean the gzip
<zyga-ubuntu> cachio: hmm, looks like SD card corruption
<zyga-ubuntu> maybe run fsck on the disk
<ogra_> is that command running as root ?
<ogra_> you cant tar up /dev (which the core snap contains) as a user
<cachio> ogra_, yes, as root
<ogra_> hmm, then it should work ...
<ogra_> (or at least thats not the error)
<cachio> I'll try with another sdcard
 * zyga-ubuntu wants to hide in an ice box
<mup> Bug #1707655 opened: "Get support" in Get a Store should link to snapcraft forum <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1707655>
<cachio> zyga-ubuntu, ogra_ seems to be working with the new sd card
<cachio> at least it didn't fail preparing that
<niemeyer> Hey folks
<niemeyer> How're things going there?  All good?
<cachio> niemeyer, hey, yes
<cachio> running beta validation on my side
<niemeyer> cachio: Heya
<niemeyer> cachio: Is Linode behaving itself?
<cachio> niemeyer, yes, linode is nice this week :)
<niemeyer> Phew :)
<cachio> niemeyer, I have made a PR for spread
<cachio> niemeyer, trying to fix the exits in the code
<niemeyer> cachio: I think the exits in the code are fixable by just reorganizing them
<niemeyer> cachio: This is usually referred to as the "single return" issue when talking about programming languages in general
<cachio> niemeyer, yes, well, I proposed something like a "single return"
<niemeyer> cachio: I'll have a look for sure, but again this doesn't seem related to a feature in spread.. the way to have a single return is to not exit in the first place
<cachio> niemeyer, nice
<cachio> niemeyer, not hurry with that
<zyga-ubuntu> niemeyer: hey, all good so far
<niemeyer> zyga-ubuntu: Heya
<niemeyer> zyga-ubuntu: Sweet
 * zyga-ubuntu breaks 
<zyga-ubuntu> too hot to think
<zyga-ubuntu> I'll work at night
<Chipaca> zyga-suse: the nice thing about poland is that it's cool, right?
<janisozaur> not right now
<Chipaca> janisozaur: I'm pulling his leg because he recently moved there from Barcelona
 * ogra_ is really happy we got rid of the heat here in germany ... (we fanned it all eastwards ...)
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<ogra_> uh, whats that ?
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<Chipaca> ogra_: I see nothing
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#15 opened: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<janisozaur> what's going on?
<janisozaur> is that due to outages everywhere?
 * zyga-ubuntu is unsure
<zyga-ubuntu> seems like mup re-discovered everyting
<janisozaur> github is having major outage, other places seem to be taking vacation too according to various reports
<zyga-ubuntu> aha
<zyga-ubuntu> well
<zyga-ubuntu> and here I was trying to do stuff when there is less heat
<janisozaur> the heat must have move on to US
<janisozaur> but seeing you suddenly have time to spareâ¦ :D
<Chipaca> vacation \o/
 * Chipaca approves
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430
<zyga-ubuntu> hold your horses mup, github is drunk
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR # opened: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<Chipaca> ogra_: could you mute mup for an hour?
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430
<jdstrand> roadmr: hi! would you mind pulling r893? again, not urgent
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # opened: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3609, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3623, snapd#3624, snapd#3625, snapd#3630, snapd#3632, snapd#3633, snapd#3634, snapd#3635
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<roadmr> jdstrand: sure
<jdstrand> roadmr: thanks! :)
<zyga-ubuntu> jdstrand: some initial layout work: https://github.com/snapcore/snapd/pull/3636
<zyga-ubuntu> jdstrand: parsing of the layout structure and initial validation
<jdstrand> zyga-ubuntu: ok, I'll add it to the list. note the list is quite large atm
<zyga-ubuntu> jdstrand: large/
<zyga-ubuntu> ah
<zyga-ubuntu> the list is large
<zyga-ubuntu> fine :)
<jdstrand> the list is large
<zyga-ubuntu> I just wanted to let you know this is slowly coming
<jdstrand> yes. we have a card for it. I've let ratliff_ and tyhicks know it is coming
<zyga-ubuntu> I'll experiment with this and snap-update-ns now, nothing binding, just to have a base for conversations
<cachio> ogra, running in pi2 with the beta image using a 8gb sd card I am getting this https://paste.ubuntu.com/25215062/
<cachio> ogra, any idea?
<cachio> it is really weird
<cachio> ogra, more info https://paste.ubuntu.com/25215067/
<cachio> so far I could not make the tests run in pi2 or pi3 with the last beta
<jdstrand> ogra: hey, not sure you saw, but I responded to https://bugs.launchpad.net/snapd/+bug/1707612
<ogra> cachio, has that image fully booted before ? (the resize-to-full-disk only happens on first boot)
<ogra> cachio, though this is the same on all images apart from amd64 ...
#snappy 2017-08-01
<zyga-ubuntu> good morning
<JamieBennett> Good morning zyga-ubuntu
<zyga-ubuntu> JamieBennett: hey :)
<zyga-ubuntu> how are you doing? you're up early!
<JamieBennett> nah, in Germany today so I've gain an hour ;)
<zyga-ubuntu> aha, I see
 * zyga-ubuntu looks at PRs
<zyga-ubuntu> JamieBennett: is it as hot in Germany as it is in Poland this week?
<JamieBennett> 35 degrees or so
<zyga-ubuntu> who needs Spain with weather like that ;-)
<JamieBennett> indeed
<zyga-ubuntu> ogra: do you understand the impact of https://github.com/snapcore/core-build/pull/15 ?
 * zyga-ubuntu looks at https://github.com/snapcore/snapd/pull/3260
<ogra> zyga-ubuntu, no, but i think enough cloud people spoke up there to merge it
<popey> ogra: any luck with the nano pi kernel update? :)
<ogra> popey, sorry, not yet
<popey> ok, no worries
<ogra> i'll let you know
 * popey puts it back on the shelf for now
 * zyga-ubuntu reads through endless reviews
<zyga-ubuntu> tests are somewhat unhappy late
<zyga-ubuntu> lately*
<zyga-ubuntu> download speeds from DC are low
<zyga-ubuntu> (or from CDN)
<zyga-ubuntu> 111KB/s
<zyga-ubuntu> then tests time out
<zyga-ubuntu> Chipaca: can you please look at https://github.com/snapcore/core-build/pull/15#pullrequestreview-53445957
<mup> PR core-build#15: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <https://github.com/snapcore/core-build/pull/15>
<Chipaca> no
 * Chipaca lies
<Chipaca> zyga-ubuntu: +1
<zyga-ubuntu> morphis: hey
<zyga-ubuntu> morphis: I reviewed the userd branch
<morphis> yeah!
<zyga-ubuntu> morphis: I marked is as needed changes because there were a few details
<morphis> finally I got a review  on it :-)
<zyga-ubuntu> morphis: but overal it is good
<morphis> thanks very much!
<zyga-ubuntu> morphis: I plan to try it on real hardware but I don't think there are packaging changes done yet
<zyga-ubuntu> (are there?)
<zyga-ubuntu> and lastly I'm melting (warmest day of the year here)
<morphis> zyga-ubuntu: there are
<zyga-ubuntu> so please forgive me if I missed something
<morphis> those are in the PR
<zyga-ubuntu> excellent
<morphis> for fedora/suse/ubuntu
<mwhudson> zyga-ubuntu: any progress on the debian upgrade?
<mwhudson> (i haven't made any)
<zyga-ubuntu> mwhudson: no, but slowly getting there
<zyga-ubuntu> mwhudson: I need to fix 32bit builds and give it a try first
<zyga-ubuntu> mwhudson: and there's a bug on debian that I worked on reproducing (successfully) yesterday with new spread tests
<mwhudson> zyga-ubuntu: cool
<zyga-ubuntu> mwhudson: also I miss winter
<zyga-ubuntu> ;)
<mwhudson> zyga-ubuntu: anything you need from me? i guess i could/should check that the golang deps in the archive are appropriately close to the version in snapd
<mwhudson> zyga-ubuntu: heh, i am kind of tired of winter now
<zyga-ubuntu> mwhudson: I didn't check any deps and I expect us to grow some more items
<mwhudson> although the days are getting noticeably longer now
<zyga-ubuntu> mwhudson: if you want you can do a pass over that
<mwhudson> i keep getting mails "Waiting for previous upload(s) to complete their review process. If you want to prioritize this last one, go to the other upload(s) page in https://dashboard.snapcraft.io/ and click on the 'Reject and remove from review queue' button."
<zyga-ubuntu> hmmm
<zyga-ubuntu> mwhudson: which snap were you uploading?
<mwhudson> zyga-ubuntu: go-tip
<zyga-ubuntu> mwhudson: is it a classic confinement snap?
<mwhudson> yes
<zyga-ubuntu> aha
<zyga-ubuntu> was it approved before?
<mwhudson> yes
<zyga-ubuntu> odd
<mwhudson> it seems to happen to one arch each upload
<zyga-ubuntu> maybe the review database state got lsot
<mwhudson> (it's built daily)
<zyga-ubuntu> lost*
<zyga-ubuntu> jdstrand and roadmr can probably help you out
<zyga-ubuntu> but timezone :/
<mwhudson> and i *think* the snap gets approved in the end
<zyga-ubuntu> ondra: hey, any plan to iterate on 3624?
<zyga-ubuntu> or do you want me to?
<mwhudson> oh yeah i wonder which architecture this is
<mwhudson> (store emails do not mention the arch :()
<mwhudson> oh wait no they don't get approved
<mwhudson> and it's a different grab bag of arches each day i think
<zyga-ubuntu> I think at this point you want to open a forum topic and CC daniel and jamie
<zyga-ubuntu> btw, do you get snow down there?
<mwhudson> zyga-ubuntu: ack
<mwhudson> zyga-ubuntu: nah, not where we are, too close to the sea, it's very moderate temperature wise
<zyga-ubuntu> sounds perfect :)
<mwhudson> it snowed in 2010 or so, for the first time in 40 years
<zyga-ubuntu> mwhudson: if you want please CC me on debian bits, I'm a bit rusty on the process I bet
<zyga-ubuntu> and I'd love to help
<mwhudson> zyga-ubuntu: all i want from you is an appropriate debian directory :)
<mwhudson> i can do the other bits
<zyga-ubuntu> aha
<mwhudson> ah hahaha i bet github.com/mvo5/libseccomp-golang is not in debian
<zyga-ubuntu> pstolowski: ey
<pstolowski> zyga-ubuntu, hey! did you get my email?
<zyga-ubuntu> hmm, maybe
 * zyga-ubuntu looks
<zyga-ubuntu> oh! I have it now
<mup> PR core-build#15 closed: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/15>
<mwhudson> zyga-ubuntu: i think all of github.com/mvo5/libseccomp-golang, github.com/mvo5/net/bpf, github.com/ojii/gettext.go will need packaging
<mwhudson> zyga-ubuntu: how come both github.com/ojii/gettext.go and github.com/ojii/gettext.go/pluralforms are in vendor.json?
<mwhudson> don't you get the latter along with the former
<zyga-ubuntu> mmmm
 * zyga-ubuntu looks
<zyga-ubuntu> I don't know
<zyga-ubuntu> interesting
<mwhudson> zyga-ubuntu: at least they specify the same revision :-)
<zyga-ubuntu> mwhudson: I think this is how it works (oddly)
<zyga-ubuntu> same is done for mgo.v2
<mwhudson> oh you have to least each package?
<mwhudson> oh yeah
<zyga-ubuntu> or go-systemd/
<mwhudson> seems like a stupid feature but well
<mwhudson> not an actual problem
<zyga-ubuntu> it seems more of "this is the subset I care about" but yeah, I didn't expect this either
<Chipaca> zyga-ubuntu, mwhudson, maybe you can use this feature to make things more interesting for people
<mwhudson> Chipaca: because snapd development is too boring
<mwhudson> ?
<Chipaca> mwhudson: "and here we see an adult snapd developer, luring a mate by making the code less boring"
<mwhudson> also if you do use different revs of packages in the same repo i, as a debian packager, will kneecap you
<Chipaca> but... but... i like my knobbly knees
<mwhudson> Chipaca: so you know what to do!
<mwhudson> (or not do)
<Chipaca> I'm being repressed!
<mwhudson> i'm going to bed
<Chipaca> mwhudson: enjoy
<ogra> hmpf
<ogra> so wlan-only installs on the pi3 work fine but now i end up with a systemd service timeout counter that stalls the boot for 2min :(
<ogra> funnily that doesnt happen on the dragonboard
 * ogra guesses the unconfigured wired device causes it ... since there is no wired on the db
<ogra> ogra@pi3:~$ systemd-analyze blame
<ogra>       2min 230ms systemd-networkd-wait-online.service
<ogra>           6.473s snapd.service
<ogra>           5.658s apparmor.service
<ogra> hrm
<ogra> not really informative
<Chipaca> ogra: which timer?
<Chipaca> ah
<ogra> systemd-networkd-wait-online.service
<Chipaca> ogra: journalctl -u systemd-networkwwhatever-bork-bork?
<ogra> does analyze list the services in the order they were started or just ordered by duration ?
<ogra> Jul 31 09:45:11 pi3 systemd-networkd-wait-online[837]: ignoring: lo
<ogra> Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
<ogra> Aug 01 10:28:36 pi3 systemd[1]: Failed to start Wait for Network to be Configured.
<ogra> Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state.
<ogra> Aug 01 10:28:36 pi3 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
<Chipaca> ogra: try: systemd-analyze plot
<mup> PR snapcraft#1432 opened: kbuild: Support Makefile without install target <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1432>
<ogra> Chipaca, i was to lazy to shovel the picture around :P
<Chipaca> aw
<ogra> obviously the system wasnt online though ... the clock isnt set in the first line
<mwhudson> aargh
<ogra> so it waiting may be correct
<mwhudson> my impression is that systemd-networkd-wait-online is rarely what you actually want
<Chipaca> ogra: python3 -m http.server and dump it into a file in the local dir
<Chipaca> mwhudson: bed!
<mwhudson> Chipaca: thanks
<ogra> yeah!
<Chipaca> goo'boy
<Chipaca> ogra: of course if you don't actually have network, no http server will help :-)
<ogra> i do have network, everything is fine ...
<ogra> its just that the boot stalls for 2 min
<Chipaca> ogra: tbh it looks like a bug in the wait thing
<Chipaca> ogra: "crash and burn" does not sound like "wait"
<ogra> well, it doesnt crash and burn and eventually moves
<Chipaca> systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
<Chipaca> ^ crashing
<ogra> hmm
<Chipaca> ogra: https://bugzilla.redhat.com/show_bug.cgi?id=1277257
<Chipaca> although that's NetworkManager-wait-online
<Chipaca> hrmph
<Chipaca> ogra: ah! maybe the problem is that by default systemd-networkd-wait-online waits for _all_ devices to be online?
<ogra> ouch
<ogra> yeah, that would be it
<Chipaca> ogra: man systemd-networkd-wotsit
<ogra> yeah, just reading it
<Chipaca> k
<ogra> it has --ignore and --interface
<Chipaca> additionally https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1673092, which is not fixed on xenial
<mup> Bug #1673092: systemd doesn't wait until the tentative flag isn't removed before firing units depending on network-online.target <systemd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1673092>
 * ogra blames xnox for closing the xenial task
<ogra> we dont configure v6 by default though
<xnox> ogra, i keep the list of tasks in systemd down, as I do look at /ubuntu/series/+source/systemd as my todo list for things to SRU.
<xnox> ogra, if you prefer, i can reopen xenial task and mark it as won't-fix
<xnox> ogra, somebody needs to bisect that bug, if they want/need that fix.
<Chipaca> xnox: you do you
<ogra> i dont "want" it but customers wont be happy if their devices wait for 2min during boot :P
<Chipaca> xnox: as long as you include some of that coleslaw in the you you do
<Chipaca> :-D
<Chipaca> ogra: if we don't enable v6 that bug won't bite though
<ogra> well, actually
<ogra> i'm sure i didnt configure v6 in console-conf
<xnox> is this the same thing that smb compalained about?!
<ogra> but that probably says nothing ...
<ogra> i see that my wlan0 device actually has a v6 ip
<xnox> Chipaca, ogra - in that bug do you per chance receive RA advertisements, that are not true at all?
<ogra> wlan0     Link encap:Ethernet  HWaddr b8:27:eb:e1:ab:81
<ogra>           inet addr:192.168.2.45  Bcast:192.168.2.255  Mask:255.255.255.0
<ogra>           inet6 addr: fe80::ba27:ebff:fee1:ab81/64 Scope:Link
<ogra> xnox, how would i check
<ogra> xnox, this setup only started working with the last netplan backport ... before you could only configure wlan after already having a working eth0 ... now you can configure wlan standalone and leave eth completely out
<Chipaca> ogra: fe80 i think means it's not up
<Chipaca> but i might be wrong
 * Chipaca knows too little v6, needs to fix this
<xnox> this is not ipv6.... fe80 address is like 127.0.0.1
<ogra> ok
<xnox> note the mac address.....
<xnox> fe80::macaddress
<ogra> ah
<ogra> wopw
<ogra> wow even
<ogra> http://paste.ubuntu.com/25219497/
<ogra> so netplan actually configures it even though i told console-conf not to
<ogra> and systemd-networkd-wait-online.service does not check the cable state
<ogra> these are the moments where i miss the event based upstart :P
 * ogra tries something
<ogra> ok .... kind of a mix between a UX and a user error
<ogra> console-conf defaults to keep ethernet enabled and configured for dhcp ... even if you never touch its config and only configure wlan
<ogra> re-running console-conf and explicitly turning off everythiong around the ethernet device fixes everything ... the defaults are broken
 * ogra files a subiquity bug 
<Chipaca> go has no support for dbm files :-(
 * ogra files Bug #1707888
<mup> Bug #1707888: ethernet defaults for unconnected device are wrong <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1707888>
<Vamsi> Hi, I hadf queried on the forum about the availablilty of a snappy core specific SDK for a given HW platform. One of the members responded that there was no such SDK availables and that we could work with standard SDKs meant for the HW. This is fine. But my question - sounds a bit trivial but I don't know - is that if I were to use astandard sdk, how are I to make use of snappy core interfaces such as the ones meant to access physical memory
<Vamsi>  etc?
<ondra> zyga-ubuntu yeah, I made changes you asked, but now two tests panic for me and I can't see reason why
<Vamsi> I mean are there some libraries that I can include while developing my snap?
<ogra> Vamsi, creating a snap is basically a single yaml file ... there isnt really a need for an SDK for that ... just use whatever SDK you use for your normal development, once done drop a snapcraft.yaml in and run snapcraft
<zyga-ubuntu> ondra: can you push, I'll have a look
<ondra> zyga-ubuntu sure
<ogra> (having hooks in different SDKs to call snapcraft might surely make sense though ... but some dedicated SDK wouldnt)
<Son_Goku> well... snapcraft itself counts as an SDK
<Son_Goku> it does a crapload of things
<Son_Goku> or rather a toolchain
<Vamsi> ogra: I got that. So in the interface, I would just be detailing what methods could be used for the communication?
<zyga-ubuntu> Vamsi: note that interfaces don't do anything new or require new APIs, instead they model existing interactions with the system
<zyga-ubuntu> Vamsi: interfaces can control available system calls, acccess to files, access to dbus, etc
<zyga-ubuntu> Vamsi: if you give me an example that you care about we can discuss how the interface would look like
<Vamsi> zyga-ubuntu: Got it. I shall get back to you shortly with my requirement.
<ogra> cachio, did you get my reply from last night btw ?
<jdstrand> mwhudson (cc zyga-ubuntu): I looked in the store for 'go-tip' and could not find the snap. do you have a store url?
<ondra> zyga-ubuntu it's updated now
<jdstrand> mwhudson: fyi, I asked in https://forum.snapcraft.io/t/go-snap-getting-stuck-in-review/1512/5 so feel free to respond there
<zyga-ubuntu> ondra: thanks,
<ondra> zyga-ubuntu I get this https://paste.ubuntu.com/25219883/
<zyga-ubuntu> right
<zyga-ubuntu> let me fix that
<cachio> ogra, no
<mup> PR snapd#3623 closed: interfaces/builtin: implement broadcom-asic-control interface <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3623>
<ogra> cachio, all images except amd64 (for kvm) do not have any free space at all until first boot, they all resize to full space before mounting writable for the first time ... seems the resize failed for some reason in your pi2 and  setup
<ogra> cachio, the resize hook of the initrd atually writes a log into /dev/.initramfs (thats not saved, so you need to capture it right after first boot)
<ogra> cachio, err ... sorry thats /run/initramfs actually
<cachio> ogra, ok, I'll try to reproduce it again
<cachio> and see what happened
<zyga-ubuntu> Chipaca: standup?
<ogra> cachio, try to capture the logs when it happens
<cachio> ogra, so far all the tries that I did with the pi2 and 3 have failed
<cachio> because of this error or other errors as I showed before
<ogra> what kind of Sd is that ? how do you write to it ?
<ogra> (and do you do any modifications before the first boot)
<Chipaca> man i'm terrible at the standup
<cachio> ogra, microsd card
<cachio> I use dd to write on it
<ogra> heh, yeah, i guessed that
<ogra> (given there is only a microSD slot :) )
<ogra> how big is that card ... what brand etc
<cachio> 8GB
<ogra> and do you modify anything or do you let it boot straight away ?
<cachio> kingston
<cachio> I don't touch it
 * ogra will check if he finds such a card in his drawer 
<cachio> I just boot it
<ogra> ok ... well, the resizing definitely failed for whatever reason
<ogra> there are two steps to it ...
<cachio> ogra, with the sandisk cards that I tried yesterday I got the error doing tar that I showed yesterday
<ogra> first it adjusts the partition table, second it runs resizefs
<cachio> I reproduced that with 3 different cards
<ogra> would be good to know which of the two steps fails (and indeed why ... )
<ogra> the logs should tell ... i havent seen resize fail in ages here in my tests
<ogra> ogra@pi3:~$ df -h|grep writable
<ogra> /dev/mmcblk0p2  3.6G  1.4G  2.1G  40% /writable
<ogra> ogra@pi3:~$
<ogra> (from last wed.)
<cachio> ogra, ok, I am writting again the card
<cachio> ogra, I used a sandisk card and got the same results
<cachio> it is after I run console conf and connect through ssh to the pi2
<cachio> >> /dev/mmcblk0p2  496M  345M  116M  75% /writable
<cachio> always using 8GB cards
<ogra> cachio, did you capture the logs ?
<ogra> also the output of "sudo sgdisk -p /dev/mmcblk0" would be interesting
<ogra> (note the logs are gone after the first reboot)
<cachio> ogra, yes https://paste.ubuntu.com/25220346/
<cachio> ogra, https://paste.ubuntu.com/25220352/
<ogra> cachio, wow
<ogra> that smells like the first sector of the SD is broken ... (though then you should not see it if you use another SD)
<cachio> mmm, I got the same with 2 sdcards
<cachio> ogra, I can try with a different one, np
<ogra> cachio, http://paste.ubuntu.com/25220363/ is roughly what you should see
<ogra> (except for the sizes indeed, that should match your phys. size)
<cachio> ogra, should I format the cards in any specific way previous to run dd?
<ogra> no
<ogra> dd should binary overwrite anything you do to the card
<ogra> so whatever you would do would be wiped anyway
<ogra> cachio, oh, where exactly do you write the SD, is that an ubuntu desktop machine ?
<ogra> if so ... did you make sure that auto-mounting of the SD didnt happen ... dd'ing to a mounted SD can indeed cause weird unexpected issues
<cachio> https://paste.ubuntu.com/25220436/
<cachio> ogra, the same happened with the other card
<cachio> ogra, it is automounting
<ogra> and do you manually unmount it ?
<ogra> before dd'ing
<ogra> i always have to do "sudo umount /dev/sdc1; sudo umount /dev/sdc2, dd ...." when writing an SD here
<cachio> ogra, I am umounting the cards
<ogra> hmm
 * ogra is baffled ... i havent seen such behaviour in about a year ... and i use SDs from 4GB up to 256GB randomly here when testing my edge images
<cachio> I am trygin again with no flags for dd
<ogra> what are the flags you use ?
<ogra> (should only be bs= to speed up the write ...)
<cachio> bs=4M oflag=sync status=noxfer
<cachio> I removed thost
<cachio> those
<ogra> keep bs
<cachio> ok
<ogra> (though if you have a lot of ram actually raise the 4M a bit ... i use 64M on my desktop machine with 16GB  ram and 2M on my laptop ... that gets me the fastest write rates)
<ogra> err
<ogra> s/2M/32M
<ogra> (bs defines the size of the chunks dd pulls iinto ram before dumping it to disk)
<cachio> ogra, yes
<cachio> writting
 * ogra wonders if ubuntu-image changed in any way that could cause a corrupt partition table 
<ogra> cachio, i'd be interested to know if you see such bahaviour with http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ as well ... (which is what i regulary test)
<ogra> (thats edge though)
<cachio> ogra, ok, I'll try
<ogra> i can really not explain what happens there ... the resize log doesnt show any particularly bad errors or anything and you should see a proper partition table
<cachio> ogra, well, it worked well just with bs=4M
<cachio> and nothing else
<ogra> you mean the resize worked ?
<cachio> yes
<ogra> phew
<ogra> ok
<cachio> >> /dev/mmcblk0p2  3.6G  345M  3.0G  11% /writable
<ogra> status=noxfer should really only suppress the final output though
<ogra> not sure why oflag=sync would mess u anything either
<ogra> *up
<cachio> I don't understand neither
<cachio> ogra, I am running the tests now, I'll see how they go
 * ogra goes to read up about oflag=sync
<cachio> zyga, abaut your comment of --disable-seccomp
<cachio> in the opensuse branch
<cachio> I uncommented this and all the tests passed
<cachio> zyga-ubuntu, is it enough?
<zyga-ubuntu> cachio: yes, I think that's good
<mup> PR snapd#3634 closed: interfaces/many, cmd/snap-confine: miscellaneous policy updates <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3634>
<roadmr> jdstrand: hey, tools r892 are now deployed!
<roadmr> r893 is in the queue, should be there in the next couple of days
<bub_> Hi, following https://tutorials.ubuntu.com/tutorial/create-your-first-snap#0 .. and it's not working.. anyone else had any problem at all with this tutorial? "hello" doesn't run after I've installed the snap
<zyga-ubuntu> bub_: what happens when you try to run it?
<bub_> -bash: hello: command not found
<bub_> uhm, thinking of it, do I have to get out of classic-mode?
<zyga-ubuntu> bub_: can you provide a trace of what you did so far?
<nacc> bub_: also, what is in PATH currently?
<bub_> https://tutorials.ubuntu.com/tutorial/create-your-first-snap#3 .. and down to typing 'hello'
<zyga-ubuntu> bub_: are you doing this *on* a all-snap/core device with the classic snap installed?
<zyga-ubuntu> bub_: can you run "snap version" to make sure we know some basics?
<bub_> /home/admin/bin:/home/admin/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
<bub_> zyga, yes, I'm in classic-mode, creating the snap
<zyga-ubuntu> bub_: aha, you may need to go out to run it
<zyga-ubuntu> not sure, I never tried it this way
<bub_> haha, that was it
<bub_> 'exit' first.. then 'hello' worked as intented
<bub_> tyty all!
<bub_> first snap, now.. to build our proprietary software, using Qt.. I think I might be in for a lot of pain
<zyga-ubuntu> bub_: I think it should be fairly easy
<zyga-ubuntu> bub_: snapcraft has support for lots of things
<zyga-ubuntu> bub_: if I can suggest something though
<zyga-ubuntu> bub_: build a version that works on classic ubuntu first
<zyga-ubuntu> bub_: so built a snap that runs on your desktop
<zyga-ubuntu> bub_: are you making software for an embedded product or for desktop devices?
<bub_> embedded
<bub_> dell edge actually
<zyga-ubuntu> bub_: does it have a GUI?
<zyga-ubuntu> bub_: or is it a web/remote software?
<bub_> nopes
<zyga-ubuntu> ah
<bub_> no GUI, afaik
<zyga-ubuntu> headless is very easy
<zyga-ubuntu> you should be just fine
<bub_> we just got it, hehe..
<zyga-ubuntu> but
<zyga-ubuntu> still
<zyga-ubuntu> dell is x86 AFAIK
<bub_> yeah
<zyga-ubuntu> so just do it all on your destkop
<zyga-ubuntu> once it works there you can just try it on the gateway
<zyga-ubuntu> and it's much easier to iterate this way
<zyga-ubuntu> bub_: in case you need help see forum.snapcraft.io
<zyga-ubuntu> bub_: lots of people making or using snaps there
<bub_> ah, my bad.. some of the executables in our software is GUI.. but first we're going to focus on the servermodule, which is non-GUI
<bub_> ok, it's a whole new world for me
<zyga-ubuntu> bub_: for a gui you will need a few more things
<zyga-ubuntu> (display server or embedded qt)
<bub_> quite experienced with linux, but not ubuntu core, or any other embedded-linux for that matter
<janisozaur> zyga-ubuntu: I ended up being busy yesterday, sorry. I have some time to spend on debugging my Arch now
<bub_> ah ok, will look into it
<bub_> zyga-ubuntu: tyty for info and help!
<zyga-ubuntu> janisozaur: no worries, I'm melting in the heat today
<zyga-ubuntu> janisozaur: I managed to do some code reviews and I'm debugging one thing
<janisozaur> ugh, tell me about it
<zyga-ubuntu> janisozaur: but still haven't touched openGL
<zyga-ubuntu> bub_: ubuntu core is different and familiar at once, once you wrap your head around immutable snaps and how snapcraft build them it gets easier
<zyga-ubuntu> bub_: there are some non-obvious things that happen at runtime
<zyga-ubuntu> janisozaur: let me boot my arch VM (if it works, I think it's not very cooperative lately)
<janisozaur> I can build snapd 2.26.14 by tweaking the package version, is that good enough?
<janisozaur> I haven't figured out how to build one outside of the package
<janisozaur> or should I try sticking to master?
<zyga-ubuntu> janisozaur: I'd start by using the released tarball
<zyga-ubuntu> let me check if mvo made one
<zyga-ubuntu> janisozaur: the version can be generated with a script in the tree
<janisozaur> Arch's PKGBUILD will pull the release from tag on github
<zyga-ubuntu> ah
<zyga-ubuntu> mvo didn't :/
<zyga-ubuntu> we want 2.26.14 for now https://github.com/snapcore/snapd/releases
<zyga-ubuntu> janisozaur: booting now
<zyga-ubuntu> hmm
<zyga-ubuntu> (watching fsck log)
<zyga-ubuntu> ok, I can log into a text console
<janisozaur> I can't seem to be able to run the simplest commands from within snap nowâ¦
<zyga-ubuntu> janisozaur: I'm fixing my arch systme, I'm in #archlinux as well
<janisozaur> right, I should probably join there too
<jdstrand> roadmr: awesome, thanks! :)
<janisozaur1> welp, can't even install snaps now
<zyga-ubuntu> janisozaur1: I poked you in arch channel
<wililupy> cyphermox: Do you know if there is an equivlent of manual setting in ifupdown with netplan?
<wililupy> cyphermox: for example, in ifupdown I can set an interface to manual and the boot process will not be held up waiting for that interface to raise. How do I acheive the same thing with netplan?
<cyphermox> there is no equivalent; except you might be able to approximate this by setting a static IP you'd want to be included, making that sufficiently private and I would expect systemd to let your system finish booting
<cyphermox> I have not tested that though :)
<wililupy> cyphermox: hmm... I can give that a shot, I worry about how the interface would work when the child interfaces come online.... Thanks!
<cyphermox> don't do that on the member of a bridge or bond, that won't work
<cyphermox> in that kind of case it should be the bond/bridge that blocks you, not the underlying device
<jdstrand> roadmr: hey. I have some code for fetching stuff from the store, but it doesn't seem to be working right: http://paste.ubuntu.com/25222189/
<cyphermox> that is, unless your network setup is very complex; in which case you might want to set a dummy IP like that on more than one... it depends on the network layout really
<roadmr> jdstrand: let me see
<cyphermox> (assuming that trick works at all)
<jdstrand> roadmr: both of these were given to me some time ago. it wouldn't surprise me at all if things changed
<roadmr> jdstrand: which snap name are you trying that doesn't work?
<jdstrand> roadmr: ufw
<jdstrand> roadmr: I can get a response, but not the snap yaml
<roadmr> jdstrand: aaa
<jdstrand> roadmr: while the first one would be handy, it is actually the python code I was trying to use just now, which just gives me a list like:
<jdstrand> ...
<jdstrand> zeronet: {'package_name': 'zeronet', 'name': 'zeronet.mkg20001'}
<jdstrand> zerotier-one: {'package_name': 'zerotier-one', 'name': 'zerotier-one.lh'}
<jdstrand> zile-tealeg: {'package_name': 'zile-tealeg', 'name': 'zile-tealeg.tealeg'}
<jdstrand> ie, no 'plugs'
<jdstrand> roadmr: I tried both on and off the vpn
<jdstrand> (I have a 3rd snippet that needs to be on the vpn for grabbing assertions)
<roadmr> jdstrand: right. Let me check something quickly
<jdstrand> that third one is for assertions. it still seems to work
<roadmr> jdstrand: so I don't think you can specify a list of fields when doing a search. You'd have to then walk by "package_name" doing something like
<roadmr> https://api.snapcraft.io/api/v1/snaps/details/$THE_PACKAGE_NAME?fields=name,channel_maps_list,confinement
<roadmr> channel_maps_list,confinement are just example fields. You'd say "plugs,slots" - but I just tried it and it doesn't work hehe :) still checking.
<jdstrand> roadmr: ok, so the url I had was search.apps.ubuntu.com, so that seems to be part of it
<roadmr> jdstrand: if you leave fields blank or omit it, it gets you all the fields *except* for plugs/slots :(
<roadmr> jdstrand: the URL shouldn't matter, the old one redirects to this
<jdstrand> I see
<roadmr> jdstrand: same with the snap_yaml_raw; I don't see it in the data if there's no field specified. Let me ask Celso (though he was away, will be a bit)
<jdstrand> ok, thanks
<jdstrand> yeah, hmm: curl -H 'x-ubuntu-series: 16' -H 'x-ubuntu-architecture: amd64' https://search.apps.ubuntu.com/api/v1/snaps/details/ufw (no plugs)
<jdstrand> curl -s 'https://search.apps.ubuntu.com/api/v1/snaps/search?q=ufw' -H 'X-Ubuntu-Series: 16' | jq .
<jdstrand> also no
 * jdstrand is looking at bug reports where plugs used to be listed
<roadmr> jdstrand: yep; as I said, the old URL just redirects to the new service anyway
<jdstrand> right
<jdstrand> that isn't what I meant. I meant the details/ vs search/ vs different -H-*
<roadmr> oh! I see
<jdstrand> plugs is just gone
<roadmr> jdstrand: I concur. Asking Celso just in case we're doing it wrong (tm), but I suspect this is a bug :)
<roadmr> jdstrand: no celso, I'll file a bug since I'm almost EOD
<mup> PR snapd#3637 opened: interfaces/unity7: allow receiving media key events in (at least) gnome-shell <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3637>
<roadmr> jdstrand: curl -s -H 'X-Ubuntu-Series: 16' -H "X-Ubuntu-Architecture: amd64" "https://api.snapcraft.io/api/v1/snaps/details/ufw?fields=snap_yaml_raw" |jq .
<roadmr> jdstrand: plugs and slots are there. cprov says they're no longer exposed as individual fields in the details json
<jdstrand> roadmr: ok thanks. I can work with that
<roadmr> jdstrand: so it complicates your process a bit: first do the search, then walk the list of packages getting details, ask for snap_yaml_raw in the fields, and then json-parse that to get plugs/slots
 * jdstrand nods
<roadmr> jdstrand: aaactually.. you *can* search?q=whatever&fields=snap_yaml_raw
<jdstrand> curl -s -H 'X-Ubuntu-Series: 16' https://api.snapcraft.io/api/v1/snaps/search?fields=snap_yaml_raw | jq .
<jdstrand> cool
<jdstrand> roadmr: thanks again!
<roadmr> np :)
<mwhudson> ogra: why does ubuntu core boot block on systemd-networkd-wait-online?
<mup> PR snapcraft#1433 opened: core: cache FileBase entries when a checksum is provided <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1433>
#snappy 2017-08-02
<mwhudson> oy slackers get https://github.com/mvo5/net/commit/0c0cd2628b36f2b053b7cc1ec04b76aab4c5189c upstream pls
<mwhudson> or at least try
<mwhudson> ah https://github.com/golang/go/issues/20556
<zyga-arch> good morning
<mup> PR snapd#3638 opened: packaging: add current arch packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/3638>
<zyga-arch> janisozaur1: https://github.com/snapcore/snapd/pull/3638
<mup> PR snapd#3638: packaging: add current arch packaging <Created by zyga> <https://github.com/snapcore/snapd/pull/3638>
<zyga-arch> that's the current packaging
<zyga-arch> so there's a nice way to review changes later
<zyga-arch> I'll merge this as soon as I can
<mwhudson> zyga-arch: o/
<zyga-arch> hey
<mwhudson> you have mail
<mwhudson> s
<mwhudson> even
<mwhudson> but i'm not really here for an hour or so so no hurry :)
 * zyga-arch looks
<zyga-arch> mwhudson: aha
<zyga-arch> mwhudson: thank you for pointing that out and finding it
<zyga-arch> mwhudson: I think that mvo may be on holidays still, if he's back we should pursue this
<zyga-arch> jamesh: hey
<jamesh> hi zyga-arch
<pstolowski> jamesh, hey! :)
<zyga-arch> I replied to the thread with you and jdstrand
<zyga-arch> please have a look and if you want to discuss something quickly now, let's do it
<jamesh> zyga-arch: thanks.  reading
<jamesh> hi pstolowski
<jamesh> zyga-arch: do you currently ever update the persistent namespaces rather than throwing them away to start over?
<janisozaur1> zyga-arch: nice, but I see some unrelated(?) test failed on travis?
<zyga-arch> jamesh: we update them when the fstab file (content interface and parts of layouts) change
<zyga-arch> jamesh: we have a very serious bug where we don't update them on base snap change that I cannot fix because it breaks apparmor and we'd have to unconfine snap-confine
<zyga-arch> jamesh: and I also forgot to meniton that snap-update-ns may need to get a new, specific, confinement for a *given snap* as it will process snap-specific mount profile
<zyga-arch> otherwise it must be unconfined to do that
<zyga-arch> janisozaur1: yes, master is very unhappy lately
<zyga-arch> janisozaur1: I ran into an issue where snap-seccomp needs to link libseccomp statically, I need to reverse that for arch
<jamesh> zyga-arch: but does "update" mean changing the existing namespace in use by running processes, or only making sure new processes see the changes?
<zyga-arch> yes
<zyga-arch> we change it live
<zyga-arch> existing processes see this
<zyga-arch> the "easy" solution was nacked as this fractured the view
<zyga-arch> that is essentially what snap-update-ns does
<zyga-arch> jamesh: the invalidation of base snap includes snap-confine figuring out that the base snap is not the same device anymore, using the freezer cgroup to see if any process uses the namespace and discarding/rebuilding it
<zyga-arch> jamesh: one more complexity is that snap-confine/snap-update-ns must work from within the constructed namespace and this brings in extra complexity (mainly around bugs in apparmor)
<zyga-arch> where naive setns() to pid 1 breaks everything
<jamesh> ah.  I'd been concentrating on snap-confine and missed snap-update-ns
<zyga-arch> there's a small PR that starts this already...
<zyga-arch> https://github.com/snapcore/snapd/pull/3621
<mup> PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
<zyga-arch> please have a look
<zyga-arch> jamesh: oh, and also reexec and base snaps adds more complexity (obviously)
<zyga-arch> because snap-confine needs to run snap-update-ns
<zyga-arch> but the base snap may not even have a normal FHS
<zyga-arch> reexec certainly adds some level of problems where we need to ensure tools use a consistent set of executables
<zyga-arch> and not a mix of the two
<zyga-arch> "reexec" only conceptually, really it is "using binaries from core snap"
<zyga-arch> jamesh: I'll grab something for breakfast, please tell me what you think, I'll be readin
<jamesh> zyga-arch: sure.  I'm replying to your email with a description of what I need.
<jamesh> zyga-arch: okay.  Replied with some details of how xdg-document-portal works
<zyga-arch> jamesh: wait, so this is /run/user/$UID/doc?
<zyga-arch> jamesh: so... we need nothing?
<zyga-arch> run is mounted as a slave of the host /run
<zyga-arch> so if you mount /run/whatever on the host this automatically works in the snap
<zyga-arch> no user-specific mount namespaces necessary
<zyga-arch> just make sure this is mounted on from the session and not from the snap (since it is a slave of the peer group)
<zyga-arch> does that make sense or am I prematurely enthusiastic?
<jamesh> zyga-arch: it is a different bind mount per package
<zyga-arch> per-package?
<jamesh> yes
<jamesh> read on a bit further :)
<zyga-arch> ok
<jamesh> the daemon produces per-package subdirectories inside the fuse file system that get mounted at /run/user/$UID/doc
<zyga-arch> aha
<zyga-arch> so we're back to square one
<jamesh> presumably because a fuse daemon doesn't know what pid originates each request, and/or the kernel may cache inode information between requests
<zyga-arch> are you familiar with bubblewrap and how flatpak uses it?
<zyga-arch> what's the mount namespace story there?
<jamesh> it builds a new namespace for each instance of the app
<zyga-arch> jamesh: so snapd 2.0.2 story
<jamesh> it doesn't try to share or update existing namespaces
<zyga-arch> jamesh: how does it access process specific namespace? just via /proc/$PID/ns/mnt?
<jamesh> (at least that's what I understood from reading it)
<zyga-arch> ohhh
<zyga-arch> and it's also FUSE
<zyga-arch> man
<zyga-arch> all the stars align to spell "oblivion"
<zyga-arch> rbind is just a set of recursively created bind mounts *at the time you call mount*
<zyga-arch> further changes are propagated using peer groups
<zyga-arch> so if I do a change in one process
<zyga-arch> and another process shares that peer group
<zyga-arch> and is a slave
<zyga-arch> it will see the change (things get mounted)
<zyga-arch> if a slave does a change the master won't see it
<jamesh> but does it break the master/slave relationship if the slave makes changes?
<zyga-arch> there are a few sharing modes (private, shared, slave, master, and one more I forgot)
<zyga-arch> no
<zyga-arch> slave can make changes that only it will see
<zyga-arch> so if you think about making changes to /run from within the snap namespace they won't propagate outwards
<jamesh> so if the process creates a new mount namespace as a slave rbind of the persistent namespace and then mounts the document portal over the top, things might work?
<zyga-suse> well, not sure, the sharing is per *mount point*
<zyga-suse> one sec
<zyga-suse> https://forum.snapcraft.io/t/feature-snap-layouts/1471
<zyga-suse> there's a link to how peer groups function there
<zyga-suse> https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt
<zyga-suse> so assuming we still need the user mount namespace
<zyga-suse> and that it *probably* has to be persistent too
<zyga-suse> (for that users)
<jamesh> https://github.com/projectatomic/bubblewrap/blob/master/bubblewrap.c <- that's the bubblewrap code.  It definitely isn't trying to share namespaces
<zyga-suse> we could do a bind mount from /run/user/doc/by-app (which is tricky if >1 app is in a snap) to /run/user/doc
<jamesh> zyga-suse: treat by-app as by-package
<jamesh> my proof of concept patches were doing permissions at the package level, since that seemed most sane
<jamesh> for flatpak, apps == packages so they are a bit loose with that terminology
<zyga-arch> right
<zyga-arch> but in our model one snap can ship two flatpaks really
<zyga-arch> hmm
<jamesh> right.  I'm just saying that the "by-app" directory inside the document portal file system is effectively per-package
<jamesh> If you give one app from a snap access to a document, there isn't much to stop it giving another app from the same snap access
<zyga-arch> well, we can still use apparmor
<zyga-arch> ;-)
<zyga-arch> but yeahg
<zyga-arch> so, who does the bind mounting of all of that?
<zyga-arch> the portal runtime running in the session?
<mwhudson> how many zyga's is too many
<jamesh> flatpak constructs a bubblewrap command line that says how to set up the sandbox
<mwhudson> also 2.26.*14* ? oh dear
<zyga-arch> mwhudson: well, it's just cooperative multi tasking so it's not any better than one :D
<jamesh> one of the arguments tells bubblewrap to bind mount the document portal
<zyga-arch> mwhudson: *yes*
<zyga-arch> we found more bugs but mvo didn't want 15
<mwhudson> zyga-arch: i made a thing https://docs.google.com/spreadsheets/d/1ndk9eN5uSSY9A3SYzBRLBxOLMWw5--A2KNbS0v0y6_g/edit?usp=sharing
<zyga-arch> aha, looking
<zyga-ubuntu> mwhudson: I requested write access to add some notes
<mwhudson> zyga-ubuntu: granted
<zyga-ubuntu> mwhudson: ok, comments made
<zyga-ubuntu> I think the biggest thing is the net fork
<zyga-ubuntu> the gettext package seems like a low hanging fruit
<mwhudson> is that only used for a test?
<zyga-ubuntu> as is the go-flags update
<zyga-ubuntu> gettext?
<mwhudson> the net fork
<zyga-ubuntu> or net?
<zyga-ubuntu> I don't recall, let me check
<zyga-ubuntu> but my bet is not just tests
<mwhudson> git grep mvo5/net/bdf
<zyga-ubuntu> mwhudson: actually
<zyga-ubuntu> it seems just for tests
<mwhudson> ok good
<zyga-ubuntu> so we could patch that away for now
<mwhudson> yeah
<zyga-ubuntu> (except on big-endian arches where it works by accident)
<zyga-ubuntu> Chipaca: hey hey
<Chipaca> zyga-ubuntu: hiya
<mwhudson> zyga-ubuntu: looks like subunit-go is unused in 2.26.14 too?
<zyga-ubuntu> I had a look at weather in London today
<zyga-ubuntu> 16C vs 30+ here :/
<zyga-ubuntu> I miss London
<zyga-ubuntu> mwhudson: I think we never used it
<zyga-ubuntu> it may have been pulled in earlier by something else
<zyga-ubuntu> but not directly via snapd tests
<zyga-ubuntu> no matches in grep
<mwhudson> oh i guess it could be a transitive dep
<mwhudson> easy to find out
<zyga-ubuntu> I think it is gone totally now, I grepped in the vendor tree as well
<mwhudson> zyga-ubuntu: hnngh https://github.com/mvo5/libseccomp-golang is a fork too?
<zyga-ubuntu> https://github.com/mvo5/libseccomp-golang/commits/master it seems so
<zyga-ubuntu> not sure if we want to package the fork
<zyga-ubuntu> or work with upstream
<zyga-ubuntu> aha, mvo added support for older libseccomp
<zyga-ubuntu> but not sure if this is even landable
<zyga-ubuntu> I think it may refer to our special-cased patched 2.1.1 from ubuntu
<mwhudson> https://github.com/mvo5/goconfigparser is not a fork but the debian package is of a version that is not tagged in the repo
<zyga-ubuntu> (wehre it is more like 2.2)
<zyga-ubuntu> mwhudson: I think for that we can use master or ask mvo for a release
<zyga-ubuntu> is that even used though?
<mwhudson> yeah i don't know if it's a problem, it's just making filling this sheet out less trivial :)
<zyga-ubuntu> /partition/grub_test.go:	"github.com/mvo5/goconfigparser"
<zyga-ubuntu> partition/grub_test.go:	cfg := goconfigparser.New()
<zyga-ubuntu> just in tests?
<zyga-ubuntu> feels bogus
<zyga-ubuntu> I think it's a leftover
<zyga-ubuntu> and the test can be patched away
<zyga-ubuntu> we moved to something else in the tree now
<zyga-ubuntu> I think this became "partition/grubenv"
<zyga-ubuntu> well, maybe, not sure
<Chipaca> sigh
<Chipaca> an hour and a bit wasted because 17.10 was using wayland behind my back
<pedronis> Chipaca: it was one hour in the future
<Chipaca> pedronis: hey, welcome back :-)
<zyga-arch> Chipaca: oh? what broke?
<zyga-ubuntu> Chipaca: could you please do a review of https://github.com/snapcore/snapd/pull/3636
<mup> PR snapd#3636: snap: add support for parsing snap layout section <Created by zyga> <https://github.com/snapcore/snapd/pull/3636>
<mup> PR snapd#3637 closed: interfaces/unity7: allow receiving media key events in (at least) gnome-shell <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3637>
<Chipaca> zyga-ubuntu: if you ssh -X into a thing that's running wayland, gtk apps start in the wayland session
 * zyga-ubuntu posted https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/1
<zyga-ubuntu> Chipaca: and?
<zyga-ubuntu> Chipaca: about that cache thing you mentioned
<zyga-ubuntu> Chipaca: you'd be interested, I suspect
<mwhudson> zyga-ubuntu: in general for the deps where snapd is way behind debian should i just propose PRs that update the snapd version?
<mwhudson> and let CI decide if it works
<zyga-ubuntu> mwhudson: I'd say yes
<zyga-ubuntu> mwhudson: but one by one so that we can evaluate where it breaks
<mwhudson> heh yes
<zyga-ubuntu> thanks
<mwhudson> i'm not that daft :)
<pedronis> mwhudson: :)
<mup> PR snapd#3638 closed: packaging: add current arch packaging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3638>
<zyga-ubuntu> wow
<zyga-ubuntu> Chipaca: not quantitative, but this feels way faster
<Son_Goku> hm?
<Son_Goku> you mean the Arch packaging?
<Son_Goku> it's deliberately designed to not be able to do a lot
<Son_Goku> it's derived from how we do things in RPM, but drastically simplified
<zyga-ubuntu> Son_Goku: no, I was talking to Chipaca in private about this https://forum.snapcraft.io/t/slow-core-downloads-breaks-tests/1521/2
<zyga-ubuntu> Son_Goku: a small optimization with huge wins for testing
<zyga-ubuntu> Son_Goku: pre-cache heavy snaps we download
<zyga-ubuntu> no coding required
<Son_Goku> duh?
<Son_Goku> why weren't we doing that before?
<Chipaca> Son_Goku: Â¯\_(ã)_/Â¯
<zyga-ubuntu> effort != 0
<zyga-ubuntu> ;)
<Son_Goku> I thought we were already doing that
<zyga-ubuntu> and nobody cared before
<Chipaca> sure, easy to say "duh" after the fact
<Chipaca> :-D
<zyga-ubuntu> now when it takes one failure out of a 1000 tests to break the run
<Son_Goku> Chipaca: there's thing thing that I call base expectations
<zyga-ubuntu> nobody expected base expectations
<Son_Goku> when we do not even do system updates before running the tests anymore, I expected we were caching the snaps
<zyga-ubuntu> proper caching is still not there
<zyga-ubuntu> but this is a huge win
<zyga-ubuntu> test took 19 minutes
<mup> PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
<zyga-ubuntu> I'll do some tweaks and do A/B
<Son_Goku> hm, does that mean that with this dep upgrade, snapd won't build on Fedora 25 anymore?
<Son_Goku> Debian sid is on Go 1.8, and Fedora 25 is only on 1.7
<zyga-ubuntu> Son_Goku: dep update?
<Son_Goku> [06:34:47 AM]  <mup>	PR snapd#3639 opened: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
<mup> PR snapd#3639: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
<zyga-ubuntu> ah
<zyga-ubuntu> good question
<mwhudson> Son_Goku: i don't think so, this is only the crypto bits, they should still support 1.7
<Chipaca> zyga-ubuntu: i have code i can push
<Chipaca> actually, let me run all the unit tests first :-D
 * Chipaca _thinks_ he's covered all the angles, but
<mup> PR snapcraft#1434 opened: lxd: clean with no parts should only delete <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1434>
<Chipaca> basically: if the snap has a known size, and it's equal to the resume, then skip the download; and if it has a non-empty hash, check the hash
<Chipaca> those ifs should make it work with the tests as they stand (and they make some sort of sense)
 * mwhudson zzzz
<zyga-ubuntu> Chipaca: haha, easy prey :)
<zyga-ubuntu> thank you for fixing it
<zyga-ubuntu> Chipaca: will it rename .partial files that aren't "partial" too?
<zyga-ubuntu> mwhudson: night night! thank you!
<Chipaca> zyga-ubuntu: what does that mean?
<zyga-arch> Chipaca: if I naively "snap download core"
<zyga-arch> stick it as .partial in /var/lib/snapd/snaps/
<zyga-arch> will it choke?
<zyga-arch> I mean, I don't mind chopping of the final byte
<Chipaca> zyga-arch: yes, that's what the patch is for
<zyga-arch> excellent
<Chipaca> zyga-arch: no need to even talk to the server if we already have the whole thing
<Chipaca> and, unit tests pass
<Chipaca> if you have a pr i can push this to it
<Chipaca> or
<Chipaca> we can do it backwards
<Chipaca> maybe easier to do it backwards :-)
<zyga-ubuntu> backwards as in who goes first?
<Chipaca> zyga-ubuntu: yes
<Chipaca> zyga-ubuntu: https://github.com/snapcore/snapd/pull/3640
<mup> PR snapd#3640: store: do not resume a download when we already have the whole thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3640>
<mup> PR snapd#3640 opened: store: do not resume a download when we already have the whole thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3640>
<Chipaca> zyga-ubuntu: if you push your changes to that, everybody should be happy
<zyga-ubuntu> Chipaca: understood
<Chipaca> it changes the logic for downloading deltas a teeny bit
<Chipaca> bit it shouldn't change things in practice
<zyga-ubuntu> I'll review it in a moment
<Chipaca> if the store says "no deltas", download begins, download is canceled, download is reattempted and the store says there are deltas, currently we don't resume; this makes the resume win
<Chipaca> in practice it shouldn't make much difference except outside tests
<Chipaca> i mean except inside tests :-)
<Chipaca> anyway
<Chipaca> time for me to take a break, run, and lunch
 * Chipaca afk
<zyga-ubuntu> ok, I will need ~45 minutes to finish the A/B timing tests
<zyga-ubuntu> and in the meantime I can review
<zyga-ubuntu> actually
<zyga-ubuntu> scratch that
<zyga-ubuntu> I can push my PR directly to see how long it takes
<ogra> hrm ... travis ??
<ogra> Chipaca, are you still working on the shutdown stuff (unmounting /writable and /lib/modules failing) or is that on hold ?
<mup> PR snapd#3641 opened: tests: download core and ubuntu-core at most once <Created by zyga> <https://github.com/snapcore/snapd/pull/3641>
<zyga-ubuntu> ogra: that's merged
<zyga-ubuntu> ogra: loooong ago
<ogra> zyga-ubuntu, where ? that never changed on any ubuntu core images i run
<zyga-ubuntu> ogra: look at /usr/lib/snapd/
<zyga-ubuntu> there should be a shutdown executable there
<zyga-ubuntu> there's a systemd job that puts it in the special place that systemd uses on shutdown
<zyga-ubuntu> I think it runs all the time for ~6 months now
<ogra> well, it didnt fix the bug obviously
<zyga-ubuntu> oh?
<zyga-ubuntu> Chipaca: ^
<ogra>      [FAILED] Failed unmounting /lib/modules.
<ogra>      [  OK  ] Unmounted /etc/sudoers.d.
<ogra>      [  OK  ] Unmounted /run/snapd/ns.
<ogra>      [FAILED] Failed unmounting /writable.
<ogra> i still see that all the time on every shutdown on every install
<zyga-ubuntu> mmmmm
<zyga-ubuntu> maybe something broke?
<zyga-ubuntu> I wonder if we can get some logs from the tool
<ogra> well, i never "not" saw it
<zyga-ubuntu> I remember testing the thing in kvm
<ogra> (i actually thought john is still working on it )
<ogra> i see the systemd job simply copies it to /run/initramfs/
<zyga-ubuntu> another faiure of FAIL: overlord_test.go:360: overlordSuite.TestEnsureLoopPrune
 * ogra pokes https://travis-ci.org/snapcore/core-build/builds/259703332 with a pointy stick in the eye ...
<zyga-ubuntu> ogra: remember the abyss quote
<jdstrand> mwhudson: haven't read all backscroll. it seems like getting snapd in Debian (properly?) depends on using non-embedded code copies?
<zyga-ubuntu> jdstrand: yes, and we did de-vendorize everything
<zyga-ubuntu> jdstrand: but now the problem is we have a few forks
<zyga-ubuntu> jdstrand: and it's unclear if we should move the vendorized deps ahead when we do this in debian
<mup> PR snapd#3642 opened: cmd/snap: get keys or root document <Created by stolowski> <https://github.com/snapcore/snapd/pull/3642>
<jdstrand> that's interesting. we have asimilar policy in Ubuntu but was told do to time constraints to relax the requirement for snapd
<jdstrand> due*
<jdstrand> interesting the work is happening now
<zyga-ubuntu> ogra: can you open a thread about that /writable bug?
<zyga-ubuntu> jdstrand: it's only happening for debian
<zyga-ubuntu> jdstrand: I think that in ubuntu it is not even considered
<zyga-ubuntu> jdstrand: especially since it impacts testing value
<zyga-ubuntu> jdstrand: and that we reexec anyway
<jdstrand> well, if there weren't outside factors influencing what we are doing in Ubuntu I would imagine we wuld do it in Ubuntu
<zyga-ubuntu> jdstrand: I think the key factor was OMG time
<jdstrand> it seems like Debian picked up on Ubuntu's definition of how to support golang packages but are actually enforcing it
<zyga-ubuntu> jdstrand: though we lack in debian/copyright heavily todayu
<pstolowski> cachio,hey! have you found any pattern for reproducing hook errors from https://paste.ubuntu.com/25218225/ ? e.g. linode vs local qemu etc?
<Chipaca> huh, i might've broken deltas (according to spread)
 * Chipaca will fix after lunch
<Chipaca> zyga-ubuntu: ogra: those [FAILED] are from systemd
<Chipaca> zyga-ubuntu: ogra: our helper runs _after_ that; those failed are the reason we need the helper
<zyga-ubuntu> jdstrand: jdstrand:policy-updates-xxvi
<zyga-ubuntu> jdstrand: wow, roman numerals!
<zyga-ubuntu> Chipaca: lots of refresh tests failed with your PR https://travis-ci.org/snapcore/snapd/builds/260146033?utm_source=github_status&utm_medium=notification
<ogra> Chipaca, well, can we quieten them ?
<Chipaca> zyga-ubuntu: yes, as i said, i seem to have broken deltas (or their tests)
<Chipaca> ogra: sure! systemd is free software, right?
<ogra> dunno, ask redhat :P
<ogra> (surely open source though :) )
<Chipaca> nu-uh, they're on the other side of the river from me
<jdstrand> zyga-ubuntu: yeah, rocking it old school. keeping it fun! :)
<Chipaca> zyga-ubuntu: about your patch, unless i'm much mistaken the way you've done it won't work
<Chipaca> zyga-ubuntu: that is: only the first test will find the .partial
<Chipaca> zyga-ubuntu: you need to download them somewhere, and then at the start of each test copy them? or sth like that
<zyga-ubuntu> Chipaca: isn't that exactly what is going on
<Chipaca> otherwise, test downloads thing, tests its stuff, cleans up -> no more thing
<zyga-ubuntu> this is doing in the "prepare the magic state tarball" stop
<zyga-ubuntu> step*
<zyga-ubuntu> and then it gets restored in each one
<zyga-ubuntu> or maybe I misunderstood the restore logic
<Chipaca> zyga-ubuntu: ah... if that's the case then it's ok :-)
<zyga-ubuntu> Chipaca: but now that you said it, I'm not sure it is restored in each test
<Chipaca> zyga-ubuntu: easy to test
<zyga-ubuntu> TBH the spread setup is so wonky now someone could sit down and write a comprehensive document about it
<zyga-ubuntu> Chipaca: how?
<Chipaca> zyga-ubuntu: spread --shell yadda
<zyga-ubuntu> mmm, let me try, thanks!
<Chipaca> zyga-ubuntu: tweak spread.yaml to workers:1
<zyga-ubuntu> ah
<zyga-ubuntu> good iea
<zyga-ubuntu> ctrlc-
<zyga-ubuntu> I think too late
<zyga-ubuntu> 2017-08-02 14:43:04 Server <nil> (Spread-44) exceeds halt-timeout. Shutting it down...
<cachio> pstolowski, I could reproduce it in qemu
<zyga-ubuntu> interesting server!
<zyga-ubuntu> Chipaca: on the up side, it's very refreshing to see green tests
<pstolowski> cachio, every time?
<cachio> yes
<cachio> using branch
<cachio> release/2.27
<cachio> pstolowski, so far I ran it twice and I saw it twice
<pstolowski> cachio, interesting; did you run just this problematic test or entire suite?
<zyga-ubuntu> pstolowski: hey, any hints on which snaps have config or how to play with your PR?
<cachio> no, the entire mainsuite
<pstolowski> zyga-ubuntu, i guess you can try core; you can try to add extra dummy config to core via snap set core foo=bar
<zyga-ubuntu> pstolowski: and they are not discarded?!
<zyga-ubuntu> pstolowski: this seems pretty dangerous
<zyga-ubuntu> pstolowski: $ snap set author.name=frank
<zyga-ubuntu> pstolowski: snap set --help
<zyga-ubuntu> pstolowski: this example seems broken since there's no snap-name there
<zyga-ubuntu> woah
<zyga-ubuntu> that's surely a bug
<zyga-ubuntu> people can set whatever they want now
<zyga-ubuntu> and once we add options tomorrow it starts to have a meaning
<F0rTh3J3st> nyce!
<zyga-ubuntu> brb, see you at the call
<pstolowski> zyga-ubuntu, yeah, not discarded, and also known I think. i'm not sure it was considered an issue
<pedronis> you can read it as a bug or a feature depending
<pedronis> I think the plan is still to have some kind of schema at some point
<zyga-ubuntu> Chipaca: the .partial files are there
<zyga-ubuntu> 2fa
 * ogra wonders if travis will ever start ... in total i'm waiting for that job since 14h now 
<ogra> (with a timeout over night and a manual re-start)
<pedronis> Chipaca: was my explanation  about timeouts understandable?
<Chipaca> pedronis: that our timeouts were too aggressive?
<pedronis> yes
<Chipaca> pedronis: for downloads, right?
<pedronis> for everything really
<Chipaca> pedronis: well... for interactive things, we're waiting too long, not too little
<Chipaca> but that might mean that, for interactive things, we should retry less and wait more
 * ogra shakes fist at https://travis-ci.org/snapcore/core-build/builds/259703332
<pedronis> Chipaca: well, is not realistic to get a server answer in 100ms from almost anywhere
<pedronis> if we are too slow we need to cache
<Chipaca> pedronis: OTOH the store is taking >1s to anser more than 1% of requests
<pedronis> yes, but an aggressive timeout doesn't help, it's just more load
<Chipaca> pedronis: is the random >1s responses because of load?
<pedronis> I don't know
<pedronis> but using 2+ requets for everything doesn't help
<Chipaca> pedronis: are we?
<pedronis> I suspect so
<zyga-arch> janisozaur1: hey, I made some progress, I fixed two things breaking tests
<zyga-arch> janisozaur1: and I got the bulk of the code to build
<zyga-arch> janisozaur1: still a few things to do but I should have a *much* better package soon
<pstolowski> cachio, so, I need release/2.27 to reproduce the bug?
<cachio> pstolowski, yes
<pstolowski> thanks
<zyga-arch> hmmm
 * zyga-arch breaks for some drinks while staring at the test failure
<PhoenixMage> Hi all, is it possible to set the SSO credentials for a fresh install in a config file prior to first boot?
<ogra> PhoenixMage, https://docs.ubuntu.com/core/en/reference/assertions/system-user
<ogra> you need an USB key though
<PhoenixMage> USB keys I have plenty of but no monitor that has HDMI and no serial cable
<PhoenixMage> Thanks for the tip
<zyga-arch> hmm
<PhoenixMage> ok so I understand how to create the assertion but have no idea what the format on the usb has to be such as filename
<zyga-arch> PhoenixMage: hey
<zyga-arch> PhoenixMage: you need to put "auto-import.assert" in the root of the drive
<zyga-arch> PhoenixMage: the file can contain any assertions
<zyga-arch> PhoenixMage: I think you want to format the USB drive as a FAT filesystem
<zyga-arch> PhoenixMage: it will be auto-imported on boot
<zyga-arch> PhoenixMage: you can test this with "snap auto-import"
<zyga-arch> PhoenixMage: but you must be on a core device (it is disabled on classic)
<PhoenixMage> zyga-arch: I can run it up in a core VM
<PhoenixMage> zyga-arch: Sorry for the silly question but where can I get an authority-id?
<zyga-arch> PhoenixMage: you probably want to talk to pedronis about this, ideally in a forum thread so that it is reusable for others
<zyga-arch> PhoenixMage: in short you want to have your own brand
<zyga-arch> PhoenixMage: and then issue (as the brand) an assertion that lets you create accounts on unowned machines using that brand
<zyga-arch> PhoenixMage: canonical could issue such assertions but for the moment this is not done
<zyga-arch> PhoenixMage: for some insight you can also look at a test that is checking this feature
<zyga-arch> PhoenixMage: where it is fully done (end-to-end)
<zyga-arch> PhoenixMage: but I'm not that sure it's easier than asking pedronis given that it assumes a lot of context
<PhoenixMage> zyga-arch: Thanks, might have to leave that to another day, its nearly 1am here
<mup> PR snapcraft#1435 opened: lxd: Wait on lock files before running apt commands <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1435>
<zyga-arch> PhoenixMage: good luck :-)
<ogra> PhoenixMage, good morning !
<ogra> :)
<zyga-arch> (insert quote about bilbo and gandalf good morning)
<PhoenixMage> I still call this evening, in my book there is no such thing as a good morning
<PhoenixMage> Appreciate the sentiment though ;)
<PhoenixMage> Was hoping to create a couple of headless active directort domain controllers using Pis and Core :/
<ogra> surely possible ... but you need a snamba snap first i guess
<ogra> *samba
<ogra> (not sure there is one in the store yet)
<PhoenixMage> ogra: first I need a Pi core instance I can use
<ogra> true
<PhoenixMage> Then I will worry about learning how to make/use snaps
<PhoenixMage> Core is new to mwe
<zyga-arch> PhoenixMage: then you don't need the assertion yet
<PhoenixMage> Getting close to morning, there goes my typing
<zyga-arch> PhoenixMage: that's for waaaaaay later
<ogra> zyga-arch, well, he has no kbd, serial or monitor ...
<zyga-arch> ogra: pi zero?
<PhoenixMage> Understand the whole secure at first boot thing, my background is security but there should be a way I can at least put an ssh-key on it without having internet access
<ogra> no idea, does that matter if you dont have any peripherials ?
<zyga-arch> ogra: if normal pi then it is significantly easier to get a serial port connected
<zyga-arch> PhoenixMage: there is but only the brand has a way to issue those
<PhoenixMage> But then again, web devs
<ogra> zyga-arch, only if you have the cable :)
<zyga-arch> ogra: you do realize we are arguing about making a model assertion and making a new core image just so that we don't need to get a 5$ cable
<ogra> we need to really make it easier to set up a board without any peripherial HW
 * ogra was pondering to fiddle with USB gadget networking ... then you can ssh through the OTG port 
<ogra> zyga-arch, we're not arguing
<ogra> (at least i'm not)
<PhoenixMage> I dont think its unreasonable to expect someone to have a usb thumb drive, but a serial cable or a compatible screen or keyboard isnt necessarily available
<zyga-arch> arguing as in discussing :-)
<zyga-arch> PhoenixMage: for embedded devices it's pretty common, I recognize there are some things missing in the story today, I'm just telling what is the easiest path forward
<PhoenixMage> I like to play with stuff like this in hotel rooms when I travel so nothing is given except board access and I have likely forgotten a serial cable
<zyga-arch> for hacking just use kvm
<ogra> what i'd  really like is to enable gadget networking in our images ... then you can just access console-conf via USB without extra cables
<zyga-arch> no more hardware needed
<zyga-arch> if you need an intro to snaps and core that's the most comfortable way to do it
<PhoenixMage> ogra: that would be nice, everyone has at least 1 micro usb cable around
<ogra> right
<PhoenixMage> Well until usb c is ubiquitous
<zyga-arch> raspberry pi, shiny metal ass edition
<zyga-arch> with usb-c
<zyga-arch> 40GB cable
<zyga-arch> doing 100MBit networking
<PhoenixMage> I'd settle for gig networking
<zyga-arch> 40Gb
<zyga-arch> and the board will be white
<zyga-arch> with no sharp edges
<ogra> that sounds like a beaglebone white ...
<ogra> :P
<PhoenixMage> I am trying to get all my essentials on to Pi to minimise my power bills and will fire up the rest of my lab when I need it
<PhoenixMage> I am looking at an Olimex Lime 2 for my more network intensive applications like next cloud
<PhoenixMage> So does a brand cost money?
<PhoenixMage> I am assuming not but hey
<ogra> no, it is just your store account
<PhoenixMage> It says talk to sales on the website lol
<zyga-arch> PhoenixMage: nope
<PhoenixMage> I did look at banana/orange pis too but the olimex looks nicer
<ogra> if you look at https://dashboard.snapcraft.io/dev/account/ .... there is your account id ...
<ogra> if you are the owner of the kernel and gadget snaps for yur image you can use that id as your brand-id
<zyga-arch> PhoenixMage: think about software, not hardware
<ogra> (model assertion, kernel and gadget need to be owned by the same id as the system-user assertion ... )
<zyga-arch> all the hardware is nice on the product page
<zyga-arch> then you get it and, whoops, the kernel is weird
<zyga-arch> anyway
<zyga-arch> back to hacking
<PhoenixMage> And sleep for me
<PhoenixMage> Thanks for all your help, appreciate it
<zyga-arch> o/
<ogra> sleep well ...
<PhoenixMage> I got a pregnant lady in the bed not much chance
 * zyga-arch fixed a bug in cmd_test.go
<rharper> ogra: thanks for merging my change to core-build;  when would the core snap in edge get that change?  I looked at core_2554 in edge today and it's not there yet;
<ogra> rharper, well.... i'm waiting for https://travis-ci.org/snapcore/core-build/builds/259703332 since yesterday afternoon
<rharper> ogra: ok
<ogra> rharper, it needs a new deb in the PPA,, i'll get to it once travis passed
<rharper> cool, thanks for the info
<ogra> i'll ping you once it is in edge
<rharper> thanks!
<mup> PR snapd#3643 opened: overlord/devicestate, store: update device auth endpoints URLs <Created by matiasb> <https://github.com/snapcore/snapd/pull/3643>
<zyga-arch> Chipaca: yo, you around sir?
<Chipaca> zyga-arch: yup
<Chipaca> for now at least
<zyga-arch> excellent
<zyga-arch> one liner fix for you
<Chipaca> zyga-arch: go on then
<pstolowski> cachio, hey, no luck with reproducing the failure you saw :(
 * zyga-arch makes a few PRs
<zyga-arch> Chipaca: https://github.com/snapcore/snapd/pull/3644
<mup> PR snapd#3644: cmd: fix tests that assume /snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/3644>
<mup> PR snapd#3644 opened: cmd: fix tests that assume /snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/3644>
<mup> PR snapd#3645 opened: cmd: mark arch as non-reexecing distro <Created by zyga> <https://github.com/snapcore/snapd/pull/3645>
<zyga-arch> and 3645
<zyga-arch> I made them separate because I wanted nice description on GH and it's easier to cherry pick
<Chipaca> zyga-arch: lel
<zyga-arch> lel?
<zyga-arch> lets-evaluate-laughing?
<zyga-arch> oh
<zyga-arch> 3644 is buggy
<zyga-arch> but not caught by tests
<Chipaca> zyga-arch: it can't be, i approved it
<zyga-arch> (corrected)
<zyga-arch> sorry, I didn't notice
<zyga-arch> now it's good
<zyga-arch> I force pushed to get the easy cherry pick for the packaging
<zyga-arch> thank you sir!
<zyga-arch> janisozaur1: ^ little by little
<zyga-arch> pedronis: ^ if you have a sec and could do a 2nd review on the pair?
<zyga-arch> Chipaca: fun fact
<zyga-arch> I just logged into my server
<zyga-arch> as root, unusually
<zyga-arch> my /root/snap/core is interesting
<zyga-arch> we never recycle those directories
<zyga-arch> I see all the revisions we ever did
<zyga-arch> all empty
<zyga-arch> but ... well
<zyga-arch> is that the same thing that pstolowski reported ?
<Chipaca> zyga-arch: a'yup
<zyga-arch> perfect, thank you
<pstolowski> zyga-arch, yes
<pedronis> what's the policy, our queue is grewing again?
<zyga-arch> pedronis: downstream bugfixes for packaging
<zyga-arch> pedronis: not sure if we have a policy, we should definitely process the review queue
<zyga-arch> Chipaca: are we using some local proxy during testing?
<zyga-arch> Aug 02 14:38:41 autopkgtest snapd[32266]: 2017/08/02 14:38:41.789947 retry.go:52: DEBUG: The retry loop for http://localhost:11028/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2 finished after 1 retries, elapsed time=1.850053ms, status: Get http://localhost:11028/api/v1/snaps/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: dial tcp 127.0.0.1:11028: getsockopt: con
<zyga-arch> nection refused
<zyga-arch> this is from a failed test run
<zyga-arch> now why is snapd calling localhost?
 * ogra cries ... 
<ogra> https://travis-ci.org/snapcore/core-build/builds/259703332
<ogra> sigh
<zyga-arch> ogra: at least travis has nice faces
<Chipaca> zyga-arch: some of the tests use a fake store
<zyga-arch> ogra: restarted
<ogra> zyga-arch, yeah, i only noticed recently that there a females now
<zyga-arch> aha, I see
<ogra> zyga-arch, i restarted it twice already since yesterday
<zyga-arch> ogra: how does it fail?
<ogra> it sits there forever and then fails with that error
<zyga-arch> travis hiccup?
<ogra> dunno the exact wording since you just restarted it and the  page auto-refreshed :P
<zyga-arch> ogra: it said auto-restarting is limited
<ogra> yeah
<zyga-arch> ogra: did you force push to it?
<ogra> no
<ogra> i only merged the PR after you and Chipaca approved it yesterday
<zyga-arch> interesting, weird
<ogra> and the PR is a one word change
<zyga-arch> let's see what happens now
<zyga-arch> well ;D
<zyga-arch> quality :D
<ogra> i bet the same as the two times before
<ogra> (nothing ... until something times out)
<pedronis> zyga-arch: that localhost is the fake store
<ogra> zyga-arch, hmmm .... the last merge before this hanging one is https://github.com/snapcore/core-build/pull/14
<mup> PR core-build#14: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/14>
<zyga-arch> It *did* pass
<zyga-arch> maybe something broke since
<ogra> zyga-arch, are yyou sure that travis gets along with the --rbind change you added there ?
<zyga-arch> like travis-side
<zyga-arch> --rbind?
<ogra> yeah, you changed the travis.yaml ... part of that is to replace all --bind calls with --rbind
<zyga-arch> I see
<ogra> uh oh
<ogra> and i never noticed that you run kvm inside a double stacked chroot !
<zyga-arch> I think those are for qemu
<ogra> oh my
<zyga-arch> but yes, it all passed
<zyga-arch> what
<ogra> (that should really have been a separate test ... not inside the chroooted chroot)
<zyga-arch> why do you feel thta?
<zyga-arch> *that
<ogra> because too many layers ??
<zyga-arch> and is that a problem?
<zyga-arch> layers of what
<zyga-arch> anyway, this *did* pass
<zyga-arch> I'm all into figuring out what happens but this is not really anything controversial
<ogra> there is a travis 14.04 chroot ... in which we create an ubuntu 16.04 chroot ... inside which you tghen install kvm and qemu to run a vm
<zyga-arch> yes, and I would expect this to just work
<ogra> well
<zyga-arch> it runs without kvm on travis btw
<ogra> me too ... but there can be millions of corner cases
<zyga-arch> I really don't see how
<zyga-arch> I'm running an userspace process, without kvm in a chroot
<zyga-arch> btw, does travis do 16.04 now?
<zyga-arch> maybe we could drop some of the chroots
<ogra> no
 * ogra got a notification that tthey gradually updating to 14.04 from 12.04 right now 
<ogra> (got that today)
<ogra> so i guess 16.04 native is far out
<ogra> but we should really separate the two tests and not mix-mash them
<zyga-arch> separation will not get you anything positive from travis
<ogra> chroots in chroots that run a vm really doesnt sound sane
<ogra> if you run a vm anyway, do it at the toplevel
<zyga-arch> I'd rather switch to using spread as the substrate so that we can ignore silly travis limitations
<ogra> there is no need to do this inside the chroot
<ogra> well, not sure what spread would buy us anyway ... its dpkg source packages ... we should rather use autopkgtest all over
<pedronis> zyga-arch: seems IÂ should look at some older branches before, anyway about to eod
<ogra> but since i was forced into that weird tree setup you cant just auto-build the debs anymore
<ogra> (there is no more toplevel /debian dir due to the fact that i had to put both packages into one tree)
<zyga-arch> pedronis: as you want, those are super short and tiny
<zyga-arch> pedronis: I can cherry pick for packaging for now
<zyga-arch> so no worries
<ogra> zyga-arch, btw, https://github.com/snapcore/core-build/pull/14 doesnt even seem to have had any travis runs at all
<mup> PR core-build#14: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/core-build/pull/14>
<ogra> (unless the UI somehow hides them lately)
<ogra> oh, it actually does ... found it
<zyga-arch> yeah, that's the green tick
<ogra> wowo, but we need to fix a lot there
 * ogra is just reading the logs 
<ogra> all the initrd re-packing should definitely use the proper compression method ... and the cpio calls should use the correct options from the system, so we end up with the same initrds the system would produce
<ogra> (there are config files we can read from the system that have all the bits and pieces, so we dont need to re-invent the wheel)
<ogra> zyga-arch, FYI ... failed fast this time (same error)
<zyga-arch> ogra: proper compression method?
<ogra> zyga-arch, yeah, whatever is set for the specific OS in initramfs tools config
<ogra> you are lucky that gz is still supported :P
<ogra> (we havent used that iin years for initrds)
<ogra> core defaults to lzma ...
<zyga-arch> ogra: can you give me an example?
<ogra> ?
<zyga-arch> like the options you refer to
<ogra> your code hardcoded gzip everywhere
<zyga-arch> gzip is fast to compress and works
<ogra> sure
<zyga-arch> that's the only reason I used it
<ogra> but not what the actual initrd will use
<zyga-arch> that's okay, we're not testing that
<zyga-arch> we're just testing the bash functions
<ogra> we should be as close to reality as possible with our tests or shouldnt we ?
<zyga-arch> no, we should not be as close to reality, the point is to test a specific part of the code (the shell code) in a reasonably efficient and sensible way
<zyga-arch> otherwise everything would be an integration test
<zyga-arch> look how there are tons of mocking calls there
<zyga-arch> we're not testing the real thing
<zyga-arch> ogra: btw, can you please pass a link to the PR again
<zyga-arch> I cannot find it somehow
<ogra> which one ? the failing one ?
<zyga-arch> yep
<ogra> https://github.com/snapcore/core-build/pull/15
<mup> PR core-build#15: cloud-init: fix strict mode, ensure cloud-init only runs on positive id <Created by raharper> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/15>
<ogra> -policy: search,found=first,maybe=all,notfound=disabled
<ogra> +policy: search,found=first,maybe=none,notfound=disabled
<ogra> thats the change
<ogra> (all vs none)
<zyga-arch> ah, you merged it now
<ogra> nothing fancy
<zyga-arch> did tests pass?
<ogra> well, yes and no
<ogra> it passed when the PR was created
<zyga-arch> I see
<ogra> not sure why travis runs again on merge ... did it do that before ?
<zyga-arch> travis has two options: to run on branch push (so branch is tested) and to test merges
<zyga-arch> it's a per-repo choice
<ogra> right, i didnt change that ... (i doubt i can actually)
<ogra> and i dont know if it did that for any of the former PRs in that branch
<ogra> the tree definitely shows it landed properly in https://github.com/snapcore/core-build/blob/master/config/etc/cloud/ds-identify.cfg
<ogra> so i dont really get what travis tries to do there
<zyga-arch> perhaps we turned that off
<ogra> i can imagine it to run before merge ... but why would it run after ...
 * zyga-arch rebuilds the arch package with some more fixes
<ogra> hmm, funny ... the PR actualy links to the successful travis run from 27 days ago
 * ogra decides to simply ignore that travis run 
<mup> Bug #1707474 opened: FTBFS on i386: incompatibility with new xfsprogs <Snappy:New for zyga> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1707474>
<zyga-arch> hmm
<zyga-arch> ah, I had a stale file
<zyga-arch> janisozaur1: hey, how does it work if I would like to maintain a package in the community repo?
<zyga-arch> janisozaur1: or just co-maintain snapd with timothy?
<janisozaur1> zyga-arch: I assume it must be trivial or near-trivial
<zyga-arch> not trivial in any way but I'm an upstream, does that help?
<janisozaur1> in a project I work on, the Windows developer submitted an AUR package
<zyga-arch> and it's not a core package
<zyga-arch> we did an AUR package before but it got updated to community
<zyga-arch> (I'm talking about snapd)
<janisozaur1> you can submit snapd-git to AUR without raising any eyebrows
<zyga-arch> yeah, I think we already had that one, I could do it
<zyga-arch> ideally I'd work with timothy on the real packge
<janisozaur1> it's a common practice to have `x-git`, `x-beta` and so on packages in AUR
<zyga-arch> package*
<zyga-arch> aha
<zyga-arch> that's good to know
<zyga-arch> we should to that then
<zyga-arch> especially the -git one
<janisozaur1> quite commonly PKGBUILDs used for real repos would be the same as used on AUR
<janisozaur1> with the only difference being the sources version they point to
<zyga-arch> yeah, that's the goal here
<zyga-arch> ok, one more test to fix
<janisozaur1> the one that you downloaded from community repo, just change the pkgver and it will produce updated version
<zyga-arch> oh, and a *real* bug
<zyga-arch> well, I have a lot of changes/fixes there
<zyga-arch> with a bit of luck the last one to make
<zyga-arch> Chipaca: do you have a sec to hand-hold my logic?
<zyga-arch> Chipaca: what is the expected value of $SNAP on a distro that uses non-standard /snap location
<zyga-arch> since we don't support classic confinement
<zyga-arch> I would say it should just say /snap
<zyga-arch> since on the inside, where the variable matters,
<zyga-arch> it is always the same
<Chipaca> zyga-arch: i do
<zyga-arch> excellent
<zyga-arch> one more patch then
<zyga-arch> really one liner :)
<Chipaca> zyga-arch: $SNAP is /snap/<snapname>/<revision>/
<zyga-arch> right!
<zyga-arch> +1 that's exactly what I made
<zyga-arch> just wanted to get an ack that I didn't miss any loophole
<Chipaca> zyga-arch: now if the snap is classic, i don't know if that is reality
<zyga-arch> Chipaca: those don't work without /snap on the distro
<zyga-arch> so that's +1
<zyga-arch> Chipaca: PR away
<zyga-arch> one more patch to my collection
<mup> PR snapd#3646 opened: snap/snapenv: always expect /snap for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/3646>
<zyga-arch> one more makepkg
<zyga-arch> some say that this is the one where tests pass
<Chipaca> cachio: i've just had fedora fail to prepare, is that on your radar?
<Chipaca> cachio: https://s3.amazonaws.com/archive.travis-ci.org/jobs/260290219/log.txt?X-Amz-Expires=30&X-Amz-Date=20170802T174918Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170802/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=ca82ef1041c0f438b599060ab83bf69d943193fed63576fd4a05e273e31399b3
<Chipaca> gah, bad url
<Chipaca> cachio: https://api.travis-ci.org/jobs/260290219/log.txt
<zyga-arch> Chipaca: and one more
<mup> PR snapd#3647 opened: gitignore: ignore more build artefacts <Created by zyga> <https://github.com/snapcore/snapd/pull/3647>
<zyga-arch> and to be fair
<zyga-arch> it worked
<zyga-arch> just run-checks is silly
<Chipaca> ok, i'm EOD
<zyga-arch> Chipaca: o/
<Chipaca> zyga-arch: \o
<zyga-arch> janisozaur1: it built (and passed all tests!)
<janisozaur1> great success!
<janisozaur1> what's the plan now? will you submit snapd-git package to AUR?
<zyga-arch> janisozaur1: how can I merge two packages into one?
<zyga-arch> first I want to play with it
<zyga-arch> I will propose a PR to merge the improvements to master
<zyga-arch> and work on building it there as well (so that it doesn't regress)
<janisozaur1> what do you mean "merge two packages"?
<zyga-arch> as tests turn positive I will ping timothy to update the package in community
<janisozaur1> the split package?
<zyga-arch> there are two binary packages: snapd and snap-confine
<zyga-arch> we merged them into one in all the other places
<zyga-arch> so almost good
<zyga-arch> arch is wrong, must be something still missing from uname mapping
<zyga-arch> odd, uname just uses x86_64 like all normal kernels do
<zyga-arch> let me check the place
<zyga-arch> but
<janisozaur1> just have one "package()" instead of two and remove references to split package in header
<zyga-arch> woot
<zyga-arch> let me try
<zyga-arch> how do I deprecate/remove the stale snap-confine package
<zyga-arch> some files will move to snapd
<janisozaur1> i think `replaces=('snap-confine')` should do
<janisozaur1> but honestly that might be a better question for #archlinux
<zyga-arch> good point
<zyga-arch> ok
<zyga-arch> snaps seem to work for me
<zyga-arch> ok
<zyga-arch> I still need to do tab completion
<zyga-arch> and then do some comparison to what we ship here and in fedora or debian
<zyga-arch> but
<zyga-arch> I can share what I have, do you want to play with it?
<janisozaur1> yes
<janisozaur1> yes, please :)
<zyga-arch> can I just say package() { } when I have one binary package?
<janisozaur1> yes
<janisozaur1> if you submit a PR with updated PKGBUILD, I can work with that
<janisozaur1> double check packaging snapd itself works
<zyga-arch> yep, just building locally
<zyga-arch> I'll install the tab completion files as well
<zyga-arch> snaps can do pretty nifty confined tab completion
<zyga-arch> so far so good
<mup> PR snapd#3648 opened: release: remove default from VERSION_ID <Created by zyga> <https://github.com/snapcore/snapd/pull/3648>
<zyga-arch> ok, trying the build with tab completion
<zyga-arch> if this works I'll push the branch
<zyga-arch> I also fixed the unknown
<zyga-arch> (in snap version)
<zyga-arch> I tried a few snaps already and it's ok
<zyga-arch> though the update from previous snapd with snap-confine didn't work OK
<zyga-arch> I had to remove snapd and snap-confine
<zyga-arch> maybe it works better when this is done in a repo
<zyga-arch> and not when I just use pacman on files
<janisozaur1> I think it should work the same way
<zyga-arch> maybe I did it incorrectly, I really promise to push in a sec
<zyga-arch> let me review the patch and push now
<zyga-arch> can you please try https://github.com/zyga/snapd/commit/4bf43f3f68e856f7a45375f972aaca98bc3295e5
<zyga-arch> just get that branch https://github.com/zyga/snapd/tree/feature/improve-arch-package
<zyga-arch> and do makepkg in packaging/arch
<zyga-arch> if you have stale src you may need to kill it
<zyga-arch> aww, hold on
<zyga-arch> didn't build
 * zyga-arch correts
<zyga-arch> have a look but don't build :)
<zyga-arch> I'll push the fix over this in a moment
<zyga-arch> janisozaur1: how do I build a package and skip tests?
<zyga-arch> just to gain speed
<janisozaur1> makepkg --nocheck
<zyga-arch> build successful, let me install and run a simple snap to check
<zyga-arch> I think the version is wrong
<zyga-arch> it should convey "prerelease"
<zyga-arch> not sure how to do that
<zyga-arch> 2.27~1-1 something
<zyga-arch> like in debian?
<janisozaur1> is 2.27 already a tag?
<zyga-arch> no, not yet
<zyga-arch> that's why :/
<zyga-arch> pushed
<zyga-arch> try it
<zyga-arch> I'll try it with GUI snaps now
<janisozaur1> so the usual way would be:
<zyga-arch> maybe, krita?
<janisozaur1> 1. have the package name `snapd-git`
<zyga-arch> tab completion for snap works!
<janisozaur1> 2. the (stored) package version is only changed when the PKGBUILD itself changes, otherwise it should be autogenerated
<zyga-arch> janisozaur1: note that the purpose of packaging/arch directory is to keep the refenrence *downstream* release packaging
<janisozaur1> 3. the `pkgver() {}` should report dynamic version, e.g. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=zopfli-git#n13
<zyga-arch> snapd-git should be a separate AUR package
<zyga-arch> ah
<zyga-arch> thank you!
<zyga-arch> no GLX :/
<zyga-arch> I need to improve opengl support :)
<zyga-arch> it seems this is the thing were we all started
<janisozaur1> so you can have the pkgver set to something like 2.26.14-1414-g1bb7d6da9
<zyga-arch> I see a billion gpg-agents on my system
<zyga-arch> hmm
<zyga-arch> is this gnome-web being dumb or did I break something with tests?
<zyga-arch> yep
<zyga-arch> tests are leaking crap
<zyga-arch> but that's for another moment
<zyga-arch> janisozaur1: I'll add pkgver and push again
<zyga-arch> thank you for the link
<zyga-arch> ok try it!
<mup> PR snapd#3649 opened: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649>
<zyga-arch> and please comment on https://github.com/snapcore/snapd/pull/3649
<mup> PR snapd#3649: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649>
<zyga-arch> I also commented on https://forum.snapcraft.io/t/updates-to-snapd-package-on-arch/1467/6
<zyga-arch> aww
<zyga-arch> I got one odd test failure but I didn't change that branch, feels like tab/spaces thing
<zyga-arch> janisozaur1: any luck?
<zyga-arch> janisozaur1: I replied on your comment
<zyga-arch> janisozaur1: let me know how it works with various snaps
<zyga-arch> I definitely want to look into GLX issues but given my environment (libvirt vm with virtio GPU) I'm not sure that is representative
<zyga-arch> I need to boot natively and see how it works
<zyga-arch> but, if you are native today you can tell me how it works for yoiu
<zyga-arch> you*
<janisozaur1> after realoading the daemon i can get textual things to work
<zyga-arch> what is the hardware you are on?
<janisozaur1> i7 4790, geforce 960
<zyga-arch> I see
<zyga-arch> I see DNS resolution issues
<zyga-arch> wethr snap for instance
<zyga-arch> doesn't work
<janisozaur1> trying to run glxinfo definitely does not work
<janisozaur1> > [1]    9519 segmentation fault (core dumped)  snap run gl-test-janisozaur.glxinfo
<zyga-arch> janisozaur1: do a local test
<zyga-arch> rebuild without --with-nvidia-arch
<zyga-arch> and see if that changes anything
<zyga-arch> after doing this you must "sudo unmount /run/snapd/ns/$SNAP_NAME.mnt"
<janisozaur1> `--enable-nvidia-arch`?
<janisozaur1> it's already in PKGBUILD, though
<zyga-arch> right
<zyga-arch> remove it
<zyga-arch> without it :)
<zyga-arch> I think it causes the crash
<zyga-arch> it does some crazy things
<zyga-arch> *ahem*
<zyga-arch> I wonder who wrote that
<janisozaur1> :P
<zyga-arch> I should have never done that
<zyga-arch> without this option you are not going to mix anything from the snap world with the distro world
<janisozaur1> i can try that same package on intel gpu
<zyga-arch> all we need from the system is a running kernel
<zyga-arch> so if you have the GPU driver module in place
<zyga-arch> we need a snap with the userspace proprietary bits that is built using a compatible compiler
<zyga-arch> (compatible with the base/core snap of the snap the app requires)
<zyga-arch> and then it will work
<zyga-arch> we're interested in fixing it but it's not super high on the priority list yet
<zyga-arch> (GNOME theme support is first)
<zyga-arch> along with other general feature work
<zyga-arch> but with some experiments it could be made to work
<zyga-arch> nothing trivial though
<janisozaur1> are there any standard debugging snaps?
<zyga-arch> janisozaur1: depends on what you want
<zyga-arch> you can always run "snap run --shell snapname.appname
<zyga-arch> that will drop you into bash instead of whatever the command was
<zyga-arch> so
<zyga-arch> I can confirm that I don't get a working resolver
<zyga-arch> because /etc/nsswitch.conf uses files mymachines resolve
<zyga-arch> I need to patch this, one sec
<janisozaur1> one with glxinfo?
<zyga-arch> (this is just another bug out of the old design mistake to share /etc)
<zyga-arch> I don't know any actually
<zyga-arch> but
<zyga-arch> you can do some crazy stuff by accessing it from the real filesystem
<zyga-arch> from /run/snapd/hostfs
<zyga-arch> not sure if it will work
<janisozaur1> can i list apps of a installed snap?
<zyga-arch> you may need to set library search path
<zyga-arch> jamespage: snap info $SNAP_NAME
<zyga-arch> commands: section
<janisozaur1> > error: cannot find signatures with metadata for snap "/home/janisozaur/gears_gears_amd64.snap"
<janisozaur1> say whaaaa?
<zyga-arch> sudo snap install --dangerous
<zyga-arch> snaps come with assertions that describe what the snap is, who made it, etc
<zyga-arch> this is the root of trust and permissions
<zyga-arch> those are *separate* from the actual image as they come from the store, signed
<zyga-arch> you can install a locally built snap with --dangerous
<janisozaur1> right, I was using it yesterday, a minor brainfart today
<zyga-arch> ok, rebuilding with one more patch
<zyga-arch> if this works I'll open another PR and push an update
<zyga-arch> this should fix DNS
<zyga-arch> really the next step is to run comprehensive suite of integrationtests
<janisozaur1> on the other system, where i installed the same pacman package, trying to run a snap:
<zyga-arch> but those take more time to integrate with
<janisozaur1> > cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_SVXQPd//dev: No such file or directory
<zyga-arch> unmount anything in /run/snapd/ns/
<zyga-arch> that *may* be at fauld
<zyga-arch> *fault
<zyga-arch> and check if you have "core" in "snap list"
<zyga-arch> hmm
<zyga-arch> no luck
<zyga-arch> so
<zyga-arch> how does it work?
<zyga-arch> my /etc/hostname is 127.0.0.1
<janisozaur1> I've unmounted /run/snapd/ns/
<zyga-arch> is that dnsmasq running as a local resolver?
<janisozaur1> now i get
<janisozaur1> > core                         2462  canonical  broken
<zyga-arch> woah?
<zyga-arch> are you in snap run --shell shell?
<zyga-arch> or on the "outside"
<zyga-arch> and can you run snap list
<janisozaur1> outside, that's from snap list
<zyga-arch> and check /var/lib/snapd/snap/
<zyga-arch> is the core snap mounted there?
<zyga-arch> "broken" says it cannot read the mounted snap
<zyga-arch> specifically meta/snap.yaml
<zyga-arch> so
<janisozaur1> no, empty
<zyga-arch> is there a systemd unit for the core snap
<zyga-arch> maybe something is broken
<zyga-arch> in /etc/systemd/system
<zyga-arch> you should see var-lib-snapd-snap-core-2462.mount
<janisozaur1> `systemctl| grep snap` says nothing about core
<zyga-arch> if you start that unit it should work
<janisozaur1> yes, much better now
<janisozaur1> and custom snap runs work now too
<janisozaur1> trying to run glxinfo on that machine with intel gpu: https://hastebin.com/doneyaxolu.md
<janisozaur1> zyga-arch: can I PM you?
<mup> PR snapd#3650 opened: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650>
<zyga-arch> janisozaur1: re
<zyga-arch> sure
<zyga-arch> I was rebooting to figure out what was wrong on my setup
<zyga-arch> all fixed now
<mup> PR snapd#3647 closed: gitignore: ignore more build artefacts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3647>
<mup> PR snapd#3644 closed: cmd: fix tests that assume /snap mount <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3644>
<mup> PR snapd#3645 closed: cmd: mark arch as non-reexecing distro <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3645>
<mup> PR snapd#3646 closed: snap/snapenv: always expect /snap for $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3646>
<cratliff> Has anyone booted a core image recently?  I've been trying to generate one and if I reboot the device it cannot find the kernel snap.  I've tried kvm and running on a physical pc, this is using the pc-kernel and my custom kernel snap and I keep seeing the same issue.
<cratliff> If anyone is interested this is the json used to generate the model.
<cratliff> {   "type": "model",   "series": "16",   "model": "truck",   "architecture": "amd64",   "gadget": "pc",   "kernel": "pc-kernel",   "authority-id": "",   "brand-id": "",   "timestamp": "2017-08-02T15:29:45+00:00",   "required-snaps": ["bluez", "network-manager", "dnsmasqd"] }
<om26er> if a restricted snap is connected to snapd-control interface, does that allow it to be able to talk to snapd commandline interface ?
<om26er> s/restricted/confined.
<cratliff> Sorry, how would I check that?
<mwhudson> well https://github.com/snapcore/snapd/pull/3639 didn't go so well
<mup> PR snapd#3639: Update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
<mwhudson> i'm fairly confused as to what actually broke though
<mwhudson> oh eh what?
<mwhudson> src/github.com/snapcore/snapd/vendor/golang.org/x/crypto/acme/acme.go:18:2: cannot find package "context" in any of:
<mwhudson> oh right, x/crypto no longer compatible with 1.6 i guess
#snappy 2017-08-03
<PhoenixMage> Is there an ova for snappy?
<PhoenixMage> How can I stop snapcraft from pulling the source for a package every time I run it
<mup> PR snapd#3651 opened: update golang/x/net to version currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3651>
<PhoenixMage> hmmm, found it :)
<PhoenixMage> Does a snap compile inside of a qemu instance or something? I get a weird error trying to compile samba
<PhoenixMage> libattr.a(syscalls.o): relocation R_X86_64_PC32 against symbol `syscall@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
<PhoenixMage> Doesnt happen if I dont use snapcraft
<CodeMouse92__> I need some help. I'm trying to package a Python3 app, and I've got the following setup.py...https://bpaste.net/show/ae2837e13a50
<CodeMouse92__> And this snapcraft.yaml: https://bpaste.net/show/b0a5a817f700
<CodeMouse92__> Running 'snapcraft', everything seems to go fine, and then I slam into THIS: https://bpaste.net/show/687682e4738c
<CodeMouse92__> What is going on, and how do I get past this?
<mup> PR snapd#3652 opened: update gopkg.in/check.v1 to version currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3652>
<mup> PR snapd#3653 opened: update gopkg.in/yaml.v2 to version currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3653>
<mup> PR snapd#3654 opened: update github.com/coreos/go-systemd to version currently in Debian unâ¦ <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3654>
<mup> PR snapd#3655 opened: update github.com/gorilla/mux to version currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3655>
<zyga-ubuntu> good morning
<PhoenixMage> Hey zyga-ubuntu
<PhoenixMage> good evening
<zyga-ubuntu> Hey! :)
<zyga-ubuntu> what a day, after unending heat I was woken up by fierce rain
<PhoenixMage> Just sprinkling here
<zyga-ubuntu> pstolowski: good morning
<PhoenixMage> Can you list the files in a snap file?
<zyga-ubuntu> PhoenixMage: sure, unsquashfs -l foo.snap
<PhoenixMage> thanks
 * zyga-ubuntu looks after https://github.com/snapcore/snapd/pull/3609/files
<mup> PR snapd#3609: interfaces/builtin: add kvm interface <Created by Saviq> <https://github.com/snapcore/snapd/pull/3609>
<mwhudson> zyga-ubuntu: did you see my little pile of dep upgrade PRs?
<zyga-ubuntu> mwhudson: yes
<zyga-ubuntu> mwhudson: I want to do some diffs before/after though and this is something that requires more focus
 * zyga-ubuntu wasn't sleeping till 2Am
<mwhudson> zyga-ubuntu: fair enough
<zyga-ubuntu> mwhudson: I would also like to have Chipaca around for 2nd opinion
<mwhudson> the tests passed "enough" that i'm not expecting problems in this regard for the debian update
<zyga-ubuntu> mwhudson: yes, I think it is okay as well
<mwhudson> also this:
<mwhudson> mwhudson@aeglos:~$ go get github.com/ojii/gettext.go
<mwhudson> stat github.com/ojii/gettext.go: no such file or directory
<zyga-ubuntu> mwhudson: I'll probably merge the test dependencies
<mwhudson> does that happen for everyone?
<zyga-ubuntu> hmm
<zyga-ubuntu> mwhudson: yes
<zyga-ubuntu> so weird
<zyga-ubuntu> why do people name a repository .go?
<mwhudson> i presume it's the trailing .go that screws it up
<zyga-ubuntu> yep
<mwhudson> means dh-make-golang won't work on it :(
<zyga-ubuntu> just fork it
<zyga-ubuntu> do the package
<zyga-ubuntu> and sed
<mwhudson> heh
<zyga-ubuntu> and watch your fork gain in popularity
<zyga-ubuntu> because 1) not insane 2) packaged ^_^
<mwhudson> not sure those are actual helps when it comes to popularity
<zyga-ubuntu> mwhudson: if you cannot "go get" something that does count as an eyebrow-raiser to me
<mwhudson> i'll file an issue for now
<pstolowski> zyga-ubuntu, hey!
<zyga-ubuntu> hej hej
<zyga-ubuntu> mwhudson: working on arch update I found one thing I think we may need
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3650
<mup> PR snapd#3650: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650>
<zyga-ubuntu> I think all modern distros will have this problem
<zyga-ubuntu> ah, forgot apparmor update
<PhoenixMage> w00t got samba compiled as a snap, now to work out everything I need to do to get it to run
<PhoenixMage> Thanks to launchpad for making sure it doesnt take a month to do on an actual pi
<zyga-ubuntu> PhoenixMage: just build it on x86 first
<zyga-ubuntu> then once it all works, cross compile
<PhoenixMage> Bit of information leakage in a snap file
<PhoenixMage> It lists my home directory path, etc
<zyga-ubuntu> can you clarify?
<PhoenixMage> the parts directory in the snap has a full path to where it was built, including my home directory
<zyga-ubuntu> can you show me your snapcraft file?
<PhoenixMage> squashfs-root/home/phoenix/samba/parts/samba/build/sbin/smbd
<zyga-ubuntu> or the listing of files from the snap
<zyga-ubuntu> aha
<zyga-ubuntu> then it is built incorretly and will not work
<zyga-ubuntu> incorrectly*
<PhoenixMage> https://pastebin.com/3uVZ7y6Z
<zyga-ubuntu> this looks ok
<zyga-ubuntu> and the listing of files?
<zyga-ubuntu> how did you build the snap in the end?
<zyga-ubuntu> just running snapcraft or did you pass any arguments?
<PhoenixMage> https://pastebin.com/JxDkFBs3
<PhoenixMage> This is the local one on my ubuntu instance
<PhoenixMage> And all I did was run snapcraft with no arguments
<PhoenixMage> Well after I ran a snapcraft clean
<PhoenixMage> Anyway, I am out for dinner, will look into it more when I am done
<Chipaca> o/
<zyga-ubuntu> PhoenixMage: looks very wrong but not sure if this is related to snapcraft or the environment you were in
<zyga-ubuntu> Chipaca: hey
<Chipaca> 'sup
<zyga-ubuntu> Chipaca: reviews!
<Chipaca> zyga-ubuntu: huzzah!
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3650
<mup> PR snapd#3650: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650>
<zyga-ubuntu> more arch-y thingfs
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3648
<mup> PR snapd#3648: release: remove default from VERSION_ID <Created by zyga> <https://github.com/snapcore/snapd/pull/3648>
<Chipaca> uh
<Chipaca> zyga-ubuntu: why not share nsswitch from host?
 * Chipaca looks
<zyga-ubuntu> because it depends on loadable modules core doesn't have
<zyga-ubuntu> an host may have
<zyga-ubuntu> and in practice: systemd-resolved
<zyga-ubuntu> on arch you don't look at resolv.conf when you are using systemd-resolved
<zyga-ubuntu> anyway, this makes wethr snap work
<zyga-ubuntu> :D)
<zyga-ubuntu> btw, I was looking for a snap with bash tab completion
<zyga-ubuntu> I thought http had some
<Chipaca> nope
<Chipaca> i'll look into giving it some though
<Chipaca> ooh, they already _have_ completion
<Chipaca> i just need to plug it in
<ondra> zyga-ubuntu I pushed some changes in, now all tests pass and also more changes to address rest of the comments
<ondra> zyga-ubuntu let me know what you think
<zyga-ubuntu> ondra: nice, I didn't get to it yet
<zyga-ubuntu> ondra: though I'm churning through interface PRs today
<ondra> zyga-ubuntu I just pushed it, panic was my mistake
<ondra> zyga-ubuntu just don't know if I got right what you wanted to change about using snaptest.MockInfo, I did change it, as I saw it used in other tests, so curious if it is right :)
<zyga-ubuntu> I'm still improving many interfaces
<zyga-ubuntu> some use older style of tests
<zyga-ubuntu> some use newer already
<zyga-ubuntu> don't worry, I'll update it
 * zyga-ubuntu is now happy about https://github.com/snapcore/snapd/pull/3499 and moves to the next PR
<mup> PR snapd#3499: interfaces/builtin: add the spi interface <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
 * zyga-ubuntu -> break 
<Chipaca> zyga-ubuntu: want to try http from candidate/
<Chipaca> ?
<Chipaca> httpie's completion is far from brilliant, but there you go
<Chipaca> i'll offer them a patch if i ver get around to making this better
<niemeyer> Good mornings!
<Chipaca> niemeyer: o/!
<niemeyer> Chipaca: \o
<pedronis> niemeyer: hi,  should this be closed  for now snapd#3526 ;  didn't we decide in London to wait a bit before implementing this ?
<mup> PR snapd#3526: hooks: support for refresh hook <Created by stolowski> <https://github.com/snapcore/snapd/pull/3526>
<Chipaca> zyga-ubuntu: _now_ you can try it (testing ftw)
<niemeyer> pedronis: Looking
<pstolowski> pedronis, hey, afair we it was clear we don't want revert hook, not sure about refresh though
<niemeyer> pedronis: Yeah, as pstolowski mentions I think it was refresh we were talking about
<niemeyer> Erm
<niemeyer> *revert
<niemeyer> That was the one a bit confusing because we may want to call it on the opposite end
<niemeyer> (call revert before reverting)
<niemeyer> Or both?  ... that's why we deferred
<niemeyer> willcooke: Morning
<willcooke> hi niemeyer
<zyga-ubuntu> Chipaca: trying
<zyga-ubuntu> hmmm
<zyga-ubuntu> openpgp invalid signature
<zyga-ubuntu> hash tag doesn't match
<zyga-ubuntu> woah
<zyga-ubuntu> more weird stuff
<zyga-arch> Chipaca: look
<zyga-arch> https://paste.gnome.org/pb3e5ztde
<zyga-ubuntu> Chipaca: http weirdness on 1.8?
<zyga-ubuntu> *golang 1.8
<PhoenixMage> zyga-ubuntu: Its zesty server
<pedronis> zyga-ubuntu: seems for openpgp crypto weirdness with 1.8
<pedronis> or whatever the moving part is here
<zyga-ubuntu> this is snapd master on arch with vendorized everything and stock golang 1.8.3
<pedronis> something looks broken there
<zyga-ubuntu> but itnterestingly, it worked on 1st install of all the snaps I have
<zyga-ubuntu> *interestingly
<Chipaca> zyga-ubuntu: whaa?
<Chipaca> zyga-ubuntu: context of this?
<Chipaca> zyga-ubuntu: that looks like a pedronis one :-)
<Chipaca> pedronis: âCannot prepare auto-refresh change: cannot add some assertions to the system database:â
<pedronis> Chipaca: as I said something seems wrong with the data or the crypto code, a bit hard to judge from afar
<Chipaca> ah i missed your response there
<Chipaca> sorry
<zyga-ubuntu> Chipaca: how did you get that error?
<Chipaca> zyga-ubuntu: which error?
<Chipaca> zyga-ubuntu: the one you pointed me to?
<zyga-ubuntu> ah, sorry
<zyga-ubuntu> right
<Chipaca> :-)
<zyga-ubuntu> I thought you reproduced it
<pedronis> zyga-ubuntu: do asserts unit tests pass ?
<zyga-ubuntu> I wonder if it happens on zesty/artful
<zyga-ubuntu> pedronis: yes
<zyga-ubuntu> pedronis: all of them
<Chipaca> zyga-ubuntu: what were you doing when doing that?
<Chipaca> i mean, context of that error?
<zyga-ubuntu> Chipaca: I wanted to install your http snap from candidate
<Chipaca> so not in tests
<Chipaca> in actual real life use
<zyga-ubuntu> yes
<Chipaca> but _your_ real life, so most people's zany fantasies :-p
<zyga-ubuntu> arch uses gpg 2.1.21
<zyga-ubuntu> hahaha
<zyga-ubuntu> nice
 * zyga-ubuntu could not sleep much last night, was chasing and hunting mosquitoes 
<ogra> did you win at least ?
<Chipaca> ogra: zyga-ubuntu: https://www.youtube.com/watch?v=DQeyjgSUlrk
<zyga-ubuntu> yum
<zyga-ubuntu> are they waiting for some to feed to make ketchup
<zyga-ubuntu> ?
<Chipaca> zyga-ubuntu: no, that's fake news: http://bangaloremirror.indiatimes.com/bangalore/others/fake-news-buster-blood-urine-and-cocaine-used-to-make-ketchup/articleshow/56922945.cms
<zyga-ubuntu> I was actually making things up, I didn't hear about this
<Chipaca> zyga-ubuntu: you make things up, the internet delivers
<pedronis> zyga-ubuntu: we don't use gnupg directly for anything but snap sign (and related commands)
<zyga-ubuntu> so it must be a regression/change in the libraries we use
<zyga-ubuntu> or golang proper
<zyga-ubuntu> not fun :/
<zyga-ubuntu> pedronis: I'll check artful
<mup> PR snapd#3656 opened: store: don't call useDeltas() twice in quick succession <Created by chipaca> <https://github.com/snapcore/snapd/pull/3656>
<pedronis> zyga-ubuntu: well at least autopkgtest pass on artful afaiu
<zyga-arch> hmm, good point
<zyga-ubuntu> niemeyer: offtopic, if you feel like doing a review: https://github.com/snapcore/snapd/pull/3636
<mup> PR snapd#3636: snap: add support for parsing snap layout section <Created by zyga> <https://github.com/snapcore/snapd/pull/3636>
<zyga-ubuntu> just the syntax, I think nothin controversial, landing this will help with my experiments
<niemeyer> zyga-ubuntu: I feel like doing many reviews.. putting my mail in order first
<ogra> zyga-ubuntu, since you just reviewed the spi interface stuff today ... how about ack'ing https://github.com/snapcore/pi3-gadget/pull/12 as well ? :)
<mup> PR pi3-gadget#12: enable spidev by default <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/12>
<zyga-arch> ogra: looking
<ogra> (one liner config change)
<zyga-arch> ogra: done
<ogra> thx
<mup> PR snapcraft#1434 closed: lxd: clean with no parts should only delete <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1434>
 * ogra sees the kernel ML and hugs ppisati 
<ogra> wohooo !!!
<zyga-ubuntu> ogra: ? :)
<ogra> zyga-ubuntu, fixed a hang of the spash screen on rpi when the kms driver is used
<ogra> well
<ogra> not a hang of the splash ... actually a hard hang of the board if you start the boot splash
<zyga-ubuntu> pedronis: what is a SAS?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3632/files
<mup> PR snapd#3632: asserts,overlord/assertstate: auto refresh account-keys <Created by pedronis> <https://github.com/snapcore/snapd/pull/3632>
<ppisati> ogra: who is the store guy nowadays?
<pedronis> zyga-ubuntu: snap assertions service
<zyga-ubuntu> ah
<zyga-ubuntu> thanks
<ogra> ppisati, try cprov
<ppisati> ogra: k
<ogra> your snapcraft.yaml looks nice btw ...
<ogra> (for the pi kernel)
<ppisati> ogra: yep, and it builds locally (finally!)
<ogra> ppisati, with the new gadget build system you theoretically dont need to tar up the overlays anymore
<ppisati> ogra: i still have one pet peeve with the snapdragon snapcraft.yaml, but i don't know how to fix it yet...
<ppisati> ogra: is that aleady in place?
<ogra> (teh uboot build now pulls the kernel deb and extracts them from there)
<ogra> not for all pi's yet ... still have the 2 and the cm on my todo
<ogra> s/the uboot build/the gadget build/
<cprov> ppisati: hey, how can I help ?
<ppisati> cprov: i'm about to send an email, hold on
<cprov> ok
<mup> PR snapd#3609 closed: interfaces/builtin: add kvm interface <Created by Saviq> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3609>
<sergiusens> ogra: do share!
<sergiusens> wrt kernel ml
<sergiusens> ah, kept reading and saw the rpi comment
<mup> PR snapd#3652 closed: update gopkg.in/check.v1 to version currently in Debian unstable <Created by mwhudson> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3652>
<mup> PR snapd#3653 closed: update gopkg.in/yaml.v2 to version currently in Debian unstable <Created by mwhudson> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3653>
<mup> PR snapd#3655 closed: update github.com/gorilla/mux to version currently in Debian unstable <Created by mwhudson> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3655>
<zyga-ubuntu> Chipaca: interesting https://forum.snapcraft.io/t/snap-store-download-slow/1463
<ogra> sergiusens, i'm working on including https://github.com/ogra1/psplash-snap/ in the gadget by default and load it into the initrd on boot (which is a breeze with the split initrd stuff :) ) ... that hang was the blocker for me :)
<Chipaca> zyga-ubuntu: yes, looking into that now
 * zyga-ubuntu feels so so and takes a break
<zyga-ubuntu> not enough sleep, too much coffee
<zyga-ubuntu> ondra: I'm 50% through your PR, making some small test changes
<Chipaca> zyga-arch: _right now_, i'm seeing up to ~80MB/s in linode, better than what i get from google's chrome archive
<ondra> zyga-arch thanks  :)
<Chipaca> zyga-arch: actually no, gogole's archive is better
 * Chipaca updated
<Chipaca> anyway, luncheon
<sitter> heya, can I somehow bypass the publisher constraint on content snap (i.e. I have a content snap from the store and want to connect it to a locally built snap)
<pedronis> sitter: we don't check the constraint if the snap is locally  installed and unsasserted afair
<pedronis> it doesn't autoconnect either though I think
<mup> PR snapd#3656 closed: store: don't call useDeltas() twice in quick succession <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3656>
<Chipaca> zyga-arch: snapd#3654 is green if you want to take a look at that one (you +1'ed the others)
<mup> PR snapd#3654: update github.com/coreos/go-systemd to version currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3654>
<mup> PR snapd#3651 closed: update golang/x/net to version currently in Debian unstable <Created by mwhudson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3651>
<Chipaca> heh
<Chipaca> zyga-arch: never mind :-D
<pedronis> Chipaca: things were green
<mup> PR snapd#3654 closed: update github.com/coreos/go-systemd to version currently in Debian unstable <Created by mwhudson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3654>
<Chipaca> pedronis: yep! they weren't at start-of-day
<Chipaca> but i reran and they passed
<pedronis> now just crypto which maybe it's just a matter of splitting, if mwh doesn't get to look into that, IÂ might, but many things on my plate
<pedronis> Chipaca: I added some comments to your PRs
 * Chipaca looks
<mup> Bug #1661265 changed: [regression] sched_setscheduler denied with Qt/QML applications <personal> <snapd-interface> <verification-done> <Canonical System Image:Fix Released by pat-mcgowan> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released by mvo> <snapd (Ubuntu Trusty):Fix Released by
<mup> mvo> <snapd (Ubuntu Xenial):Fix Released by mvo> <snapd (Ubuntu Yakkety):Fix Released by mvo> <snapd (Ubuntu Zesty):Fix Released by mvo> <https://launchpad.net/bugs/1661265>
<mup> Bug #1533265 changed: /dev/vchiq is inaccessible for unprivileged user <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1533265>
<mup> Bug #1600154 changed: Reading gsettings key don't work locally (writing does) <snap-desktop-issue> <snapd-interface> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1600154>
<mup> Bug #1604967 changed: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <snapd:Incomplete by jdstrand> <https://launchpad.net/bugs/1604967>
<mup> Bug #1658298 changed: The (administratively maintained) mapping file /etc/iproute2/rt_tables is not writeable. <snapd-interface> <Snappy:Fix Released by jdstrand> <ubuntu-core-config (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1658298>
 * zyga-ubuntu goes out of the part to work from a choffe shop
<mup> Bug #1603879 changed: Requesting additions to optical-drive interface for cdparanoia. <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1603879>
<mup> Bug #1602233 changed: "X11 connection rejected because of wrong authentication." when using snaps over ssh <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1602233>
<mup> Bug #1607763 changed: Interface to manage sudoers <cpc> <snapd-interface> <snapd:Incomplete> <https://launchpad.net/bugs/1607763>
<mup> Bug #1609499 changed: move interface-specific OS mounts to interface.SecurityMounts <snapd-interface> <snap-confine:Won't Fix by jdstrand> <Snappy:Won't Fix by jdstrand> <https://launchpad.net/bugs/1609499>
<mup> Bug #1610211 changed: Interface to manage block devices <cpc> <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1610211>
<sergiusens> ogra: woah, we have first class split initrd support now?
<ogra> sergiusens, not officiaylly yet, but soon :)
<sergiusens> ogra: can we fix our kernel plugin to not "compose" an initrd?
<sergiusens> tyhicks:  jdstrand any idea why I get this: "[259955.380790] audit: type=1400 audit(1501720353.476:196): apparmor="DENIED" operation="capable" profile="/snap/core/2462/usr/lib/snapd/snap-confine" pid=7348 comm="snap-confine" capability=4  capname="fsetid""
<ogra> sergiusens, well, we will neeed it to create a modules.img then ... thats still on the TODO
<mup> Bug #1616833 changed: need new interface: time-hardware <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1616833>
<mup> Bug #1626359 changed: Cannot authorise quotactl syscall for Q_GETQUOTA <snapd-interface> <verification-done> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix
<mup> Released> <snapd (Ubuntu Trusty):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1626359>
<mup> Bug #1658793 changed: App needs resolvconf data access <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1658793>
<ogra> i only focused on the gadget side for now ... but with the new setup you can theoretically assemble an initrd from unlimited amounts of img files (as long as the compression and cpio options were identical when creating them)
<ogra> sergiusens, we'll still need to build the modules.img and snapd needs to learn to put the initrd from core into system-boot
<ogra> so still a lot to do, but the basic concept works nicely
<mup> Bug #1664297 changed: Snapped indicators using custom themes or actions doesn't properly work <snapd-interface> <Snappy:Fix Released by 3v1n0> <https://launchpad.net/bugs/1664297>
<mup> Bug #1664484 changed: Missing interface to record audio from pulseaudio <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1664484>
 * ogra notes jdstrand has "paperwork cleanup day" today ... 
<sergiusens> zyga-arch: any idea about my snap-confine above? ^
<mup> Bug #1577472 changed: The remapped $HOME directory shows as read-only to applications running in a snap <snapd-interface> <snapd:Incomplete> <https://launchpad.net/bugs/1577472>
<mup> Bug #1607067 changed: Add a dotfiles / hidden files interface <isv> <snapd-interface> <snapd:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1607067>
<cachio> zyga-arch, I try to install zeronet-js and I get this errror
<cachio> https://paste.ubuntu.com/25233361/
<cachio> this is an snap in the store
<cachio> one of the most popular ones
<mup> Bug #1630690 changed: A snap with git fails because it can't access /etc/mailname <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1630690>
<cachio> Chipaca, I saw the log you sent me yesterday
<Chipaca> ok
<cachio> but no errors on there
<Chipaca> cachio: i restarted the run as you didn't reply, so it's gone
<cachio> Chipaca, ah, ok
<Chipaca> cachio: howerver, 1sec
<cachio> tx
<Chipaca> cachio: today i got a different one; 2017-08-03 05:29:49 Failed project prepare: 1
<Chipaca>     - linode:ubuntu-core-16-64:project
<Chipaca> cachio: and this time i downloaded the log before restarting
<Chipaca> cachio: want to see it?
<cachio> yes
<Chipaca> cachio: I'll tweet it to you, one line at a time
 * Chipaca is super productive
<mup> Bug #1663175 changed: chroot interface needed <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1663175>
<Chipaca> cachio: http://people.canonical.com/~john/failure_2017080301.txt
<cachio> Chipaca, E: Package 'autoconf' has no installation candidate
<cachio> i'll see if other branches are failig because of that too
<Chipaca> cachio: it didn't fail again, fwiw
<cachio> Chipaca, do you remember which error you saw in fedora?
<Chipaca> cachio: no
<cachio> Chipaca, did you see this error trying to install zeronet-js? https://paste.ubuntu.com/25233361/
<Chipaca> cachio: I looked, didn't understand whether it was important or not, pointed you at it, and moved on
<Chipaca> cachio: I didn't retain anything about it, sorry
<Chipaca> cachio: but I then remembered i should've downloaded the logs, which is why i did it with today's failure (which i didn't even look at beyond seeing that it was in prepare)
<pedronis> Chipaca: approved the branches
 * pedronis break
<Chipaca> pedronis: woo, thanks
 * Chipaca break as well
<mup> Bug #1683364 changed: Cannot get properties of an Udisks2.Filesystem object <snapd-interface> <Snappy:Fix Released by morphis> <https://launchpad.net/bugs/1683364>
<mup> Bug #1684893 changed: "fonts", "themes" and "icons"  interfaces for desktop apps <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1684893>
<jdstrand> sergiusens: re fsetid> yes, https://github.com/snapcore/snapd/pull/3634
<mup> PR snapd#3634: interfaces/many, cmd/snap-confine: miscellaneous policy updates <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3634>
<sergiusens> jdstrand: thanks, where does that profile end up in so that I can add this in
<jdstrand> sergiusens: it is snap-confine's profile
<jdstrand> sergiusens: in /etc/apparmor.d/
<sergiusens> jdstrand: how do I reload?
<cachio> Chipaca, https://paste.ubuntu.com/25233684/
<Chipaca> something must be broken; the autopkgtests are only taking about an hour to run
<Chipaca> cachio: ooh! pedronis ^
<cachio> Chipaca, any idea why it is happening (look at the paste)
<Chipaca> cachio: not me, but pedronis and zyga were looking at something like that earlier
<pedronis> Chipaca: no
<Chipaca> no?
<pedronis> different thing
<pedronis> this is not a signing problem
<pedronis> ah, not it says that too
<pedronis> mmmh
<pedronis> what system is this?
<cachio> 16.04
<cachio> pedronis, also failing in 14.04
<pedronis> it works here
<pedronis> fwiw
<pedronis> 16.04
<cachio> pedronis, I ran it in linode and in my machine and got the same error
<pedronis> I believe you
<pedronis> but it's not completely broken
<cachio> :)
<pedronis> so I wonder what is going on
<pedronis> can you run it with SNAP_HTTP_DEBUG logging only
<pedronis> s/only/on
<pedronis> Chipaca can tell you more
<Chipaca> cachio: SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 in /etc/environment, restart everything (including your shell)
<Chipaca> cachio: "everything" == "snapd" fwiw :-)
<cachio> ok
 * Chipaca has a small everything
<cachio> pedronis, https://paste.ubuntu.com/25233775/
<Chipaca> cachio: and journalctl -u snapd ?
<cachio> https://paste.ubuntu.com/25233789/
<cachio> Chipaca, pedronis
<Chipaca> cachio: that's truncated horizontally
<Chipaca> cachio: how did you get it to be like this?
<Chipaca> (asking because somebody else recently pastebinned a log with the same error, so i want to know what to say to get it right the first time)
<cachio> Chipaca, https://paste.ubuntu.com/25233809/
<cachio> sorry, I didn't realize that
<cachio> Chipaca, I need to leave for 30 minutes, I'll be back soon
<cachio> Chipaca, do you need for info ?
<Chipaca> pedronis: go
<Chipaca> um
<Chipaca> cachio: go
<cachio> tx
<pedronis> so now is a spot the difference game  (or if there's no difference wonder what is the other variable)
<Chipaca> pedronis: do you have logs from when it worked also
<pedronis> no, but IÂ can make some
<Chipaca> pedronis: that log includes the full assertion, so spot-the-diff should be easy :-)
<Chipaca> it's split between two lines, because Â¯\_(ã)_/Â¯ but still easy
<Chipaca> pedronis: i'll get the assertion out of the logs while you do that
<pedronis> one sec, doing a bit too many things at the same time
<Chipaca> k
<Chipaca> http://pastebin.ubuntu.com/25233836/ is the assert from cachio's logs
<pedronis> there should be many?
<Chipaca> d'oh. Give me a bit :-)
<pedronis> Chipaca:  https://pastebin.canonical.com/195119/
<jdstrand> sergiusens: sudo apparmor_parser -r /path/to/profile
<jdstrand> sergiusens: do keep in mind the denial is harmless and all the PR does is silence it
<sergiusens> jdstrand: ok, maybe I am mislead
<jdstrand> there is a denial for sure but it doesn't affect anything and leads to confusion (which is why the PR silences it)
<sergiusens> jdstrand: in a container I get everything working just fine, on digital ocean, unless I cd $SNAP I get a 148 exit
<jdstrand> sergiusens: you can try adding 'capability fsetid,' instead of a deny rule and see if it fixes it, but I suspect that it is something else
<Chipaca> pedronis: http://paste.ubuntu.com/25233928/ from cachio's logs
<Chipaca> pedronis: this from yours: http://paste.ubuntu.com/25233937/
<pedronis> Chipaca: this is what "snap dowload": gives me https://pastebin.canonical.com/195120/
<Chipaca> pedronis: one thing missing from cachio's are the odd numbers
<Chipaca> dunno what they are :-)
<Chipaca> like the 994
<pedronis> no clue
<pedronis> not those aren't part of assertions
<pedronis> or needed
<Chipaca> it might be a bug in my script :-)
<Chipaca> pedronis: nope, they're there
<Chipaca> not a bug in my script i mean
<Chipaca> pedronis: âX-Vcs-Revision: 137\r\n\r\n994\r\ntype: account-key\nauthority-idâ
<Chipaca> that 994
<pedronis> I have no clue
<Chipaca> ok
<pedronis> don't think they belog
<pedronis> belong
<pedronis> I mean, there's nothing like that in my other paste
<pedronis> nor is it expected
<pedronis> might be a weird bug in api though
<pedronis> not sure why I'm not breaking then though
<pedronis> Chipaca: ah, but I'm still using  assertions  and caio is using api
<pedronis> wondering if api is flaky and we didn't notice so far
<pedronis> but flaky would mean something would be different/truncated
<pedronis> IÂ don't if it's the case
<Chipaca> ooooooohhhhh
<Chipaca> there's a buuu uuu uuuhg
<Chipaca> buuuuhhhhhhhhhhh*cough*<dies>
<pedronis> where?
<pedronis> in 2.27 or your script?
<pedronis> or logging?
<Chipaca> 1 secv
<Chipaca> pedronis: http://pastebin.ubuntu.com/25233999/
<Chipaca> pedronis: but not every time
<pedronis> Chipaca: api has an encoding bug?
<Chipaca> pedronis: would that make an assertion not load?
<pedronis> a flaky one though?
<pedronis> of course
<pedronis> we take the hash of the stuff
<pedronis> so there's some double encoding or something going on
<Chipaca> pedronis: i assumed so , but checked
<Chipaca> pedronis: yes, something somewhere is double-encoding
<Chipaca> pedronis: can you reproduce this?
<Chipaca> i tried a second time but being a little smarter and failed, let me try with the dumb way again just in case
<pedronis> Chipaca: so assertions gives back correct utf8 , right?
<pedronis> afaict
<Chipaca> yes
<Chipaca> and api is now consistently returning double-encoded utf8 to me
<Chipaca> yep
<pedronis> mmh, not here
<Chipaca> pedronis: fun for all the family
<pedronis> one sec
<Chipaca> let me do it with curl, in case it's GET doing something wrong
<Chipaca> curl gives me same output (with bad enc)
<pedronis> Chipaca: yes, sorry, spotted it
<pedronis> Chipaca: 2.26 was still talking to assertions, 2.27 starts talking to api it seems
<Chipaca> export u=assertions/account/7xN2sMCILuFk10e6DxrTrQWprdmV0Vi9?max-format=0 h='Accept: application/x.ubuntu.assertion'; diff <(curl -sH "$h" https://api.snapcraft.io/api/v1/snaps/$u) <(curl -sH "$h" https://assertions.ubuntu.com/v1/$u)
<Chipaca> ^ just so it's super clear it's the same thing it's getting
<pedronis> Chipaca: thanks for digging
<Chipaca> pedronis: I don't envy the person having to figure out where it's doing this :-/
<Chipaca> my hands are firmly by their sides there's no way to interpret this as volunteering
<pedronis> well we added a layer of proxying
<pedronis> now
<pedronis> that seems the obvious candidate
<pedronis> it's probably even python3 likely, which makes me sad, because is supposed to avoid exactly that
<Chipaca> pedronis: sorta-kinda-maybe. the three-types-of-text in the http stack in python3 flies against the intention i think
<pedronis> I know
<mup> PR snapd#3630 closed: many: implement "snap logs" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3630>
<mup> PR snapd#3640 closed: store: do not resume a download when we already have the whole thing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3640>
<pedronis> Chipaca: I pinged the relevant people, I can dig myself if they don't have time
<mup> PR snapcraft#1433 closed: core: cache FileBase entries when a checksum is provided <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1433>
<cachio> pedronis, Chipaca do you need anything else from me?
<cachio> can I help you with something?
<Chipaca> cachio: send criollitos
<cachio> Chipaca, hehhe
<Chipaca> cachio: we've determined it's probably because there is a bug in the server
<cachio> Chipaca, snapd server?
<Chipaca> cachio: assertions
<cachio> good
<pedronis> Chipaca: not assertions, snap device gateway
<pedronis> the new kid
<Chipaca> durn new kid
<pedronis> Chipaca: I created also a bug: https://bugs.launchpad.net/snapstore/+bug/1708490
<mup> Bug #1708490: there is some kind of encoding/double encoding bug in the proxying of assertions by snapdevicegw <Snap Store:New for adam-collard> <https://launchpad.net/bugs/1708490>
 * pedronis eods
<Chipaca> pedronis: ok
<Chipaca> niemeyer: you got a sec?
<niemeyer> Chipaca: Heya
<niemeyer> Chipaca: Yeah, still fighting my email.. 100+ now
<Chipaca> niemeyer: hi
<Chipaca> niemeyer: good man
<niemeyer> Wassup?
<Chipaca> niemeyer: I'm trying to get the last bit of services out, and was wondering about how you saw the rest api working for this
<niemeyer> Chipaca: Ok
<Chipaca> niemeyer: should there be individual endpoints for each operation?
<niemeyer> Chipaca: Which ops?
<Chipaca> niemeyer: or should there be an "op" struct that client and server both know about?
<Chipaca> start, stop, restart
<niemeyer> Chipaca: I think we need a single operation, otherwise we get into that issue of lack of atomicity
<Chipaca> ok. This means there'll be a, say, client.ServiceOperation that's public but marked as "not for clients"
<Chipaca> that ok with you?
<Chipaca> this would be separate from, say, client.StopOptions (but it'd embed them all i guess)
<niemeyer> Hmm
<niemeyer> How would that look?  What do we need to pass in?
<niemeyer> Chipaca: The public but not for clients is strange
<Chipaca> niemeyer: each op has a different option
<niemeyer> Chipaca: There's a sane expectation that anything public in client is supposed to be for clients
<Chipaca> and the server doesn't know the op until it's read the request
<niemeyer> Chipaca: Do you have some examples?
<Chipaca> niemeyer: sure. StopOptions{Disable: false} vs StartOptions{Enable: false} vs RestartOptions{Reload: false}
<niemeyer> Hmm
<Chipaca> so the service operation would be e.g. ServiceOperation{Names: ["foo"], Operation: "frobble", PertinentOptions: false}
<pedronis> Chipaca: snap operation itself is a bit like that, no?
<pedronis> not all the bits always apply
<Chipaca> pedronis: yes
<Chipaca> pedronis: but to make it more magic and mysterious snap ops are not shared between client and daemon, and half of the time go via a post form so they don't exist as a struct anywhere
<Chipaca> but as that's a little bit insane i'd rather not go that way :-)
<niemeyer> That sounds okays.. the two ends really have different goals..
<niemeyer> okayish
<pedronis> well they are organic grown as much as anything
<niemeyer> One end evolves and needs to support compatibility with crazy old code..
<niemeyer> The other end is supposed to be a sane abstraction for writing a client with
<niemeyer> Doesn't mean we should design the server to be terrible, though :)
<Chipaca> I _could_ drop ServiceOperation in internal/client/apps.go
<Chipaca> or sth like that?
<niemeyer> I honestly don't think it's worth the trouble for a type with two or three fields
<Chipaca> they all start with two or three fields
<Chipaca> look at daemon/api.go's snapInstruction
<Chipaca> (which is the snap op on the daemon side)
<Chipaca> eh, if the answer isn't immediately obvious, i think i'd rather go forward with dupe'ing them and resolving this later
<Chipaca> don't want to block any more (and hoping to wrap this up before my eod)
<niemeyer> Yeah, I was just looking at SnapOptions in snap_op.go.. I find it quite nice
<Chipaca> niemeyer: you'll notice that that one is missing things like Snaps
<Chipaca> ie it's not the one used for multi
<Chipaca> look for actionData
<pedronis> Chipaca: snapInstructions comes still from 15.04 I think, it was just evolved, there's even a couple of fields kept there because we thought we would get back to support them quickly *cough*
<niemeyer> Chipaca: That's because we specifically blacklisted the use of options with multiple snaps..
<niemeyer>                 return "", fmt.Errorf("cannot use options for multi-action") // (yet)
<niemeyer> This is actually a bug/missing feature
<niemeyer> Makes sense to have "snap install foo bar"
<Chipaca> as I say, I'll go ahead with having duplicated structs
<niemeyer> Chipaca: So how would the API look like?
<Chipaca> niemeyer: which api
<niemeyer> Chipaca: For these actions
<Chipaca> niemeyer: REST, or client?
<niemeyer> Chipaca: REST
<niemeyer> "REST"
<Chipaca> niemeyer: you POST a JSON document to /v2/apps
<niemeyer> (how we ended up calling HTTP as REST tells a lot about how we do things in general)
<Chipaca> niemeyer: with e.g. {"action": "start", "names": ["foo"], "enable": true}
<niemeyer> Chipaca: Sounds good
<niemeyer> Chipaca: We may want mixed mode at some point, but that's less obvious and can wait
<Chipaca> niemeyer: "mixed mode"?
<niemeyer> start+stop
<Chipaca> /o\
<Chipaca> easy enough to add later
<niemeyer> Chipaca: Yeah
<cachio> Chipaca, I am runnig a new install snap tests with release/2.27 and I am reproducing this error with many snaps
<Chipaca> cachio: yes
<Chipaca> cachio: any snap with a non-ascii character
<cachio> Chipaca, opps
<Chipaca> cachio: yes
<Chipaca> cachio: (in any assertion in the snap's chain)
<Chipaca> anyway, got service ops working, now need to stop for dinner and such
<Chipaca> EOD, mostly
<cachio> yes
<pedronis> cachio: it's getting fixed in the server
<pedronis> cachio: it affects 2.27/master but not 2.26 (because 2.26 was not talking to the proxy involved here)
<cachio> pedronis, ah, ok
<cachio> pedronis, I am testing 2.27 beta validation :)
<kyleN> hi pmcgowan
<ahasenack> hi, I'm getting this INFO message after installing my first snap:
<ahasenack> 2017-08-03T18:39:15Z INFO cannot auto connect core:core-support-plug to core:core-support: (slot auto-connection), existing connection state "core:core-support-plug core:core-support" in the way
<ahasenack> full paste: http://pastebin.ubuntu.com/25234781/
<ahasenack> anything to worry about? Is that known noise?
<cjwatson> cachio: yep, fix in progress, wasn't actually too hard
<cachio> cjwatson, awesome
<cachio> thanks
<pedronis> ahasenack: known noise I think
<cachio> niemeyer, there?
<niemeyer> cachio: Still here
<cachio> niemeyer, nice,
<cachio> niemeyer, I have created a new test which installs popular snaps
<cachio> niemeyer, Jammie talked to you about this?
<niemeyer> cachio: Nope
<cachio> niemeyer, ok, he asked to me to consider a test which installed most popular snaps
<cachio> I implemented this and found the issue in the assertions because of that
<cachio> my question is where to put it?
<cachio> I already added it to the main suite but not sure if it is the correct place for that
<cachio> I think this test comes from the last sprint in Polland
<niemeyer> cachio: That feels a bit like crossing a line.. we don't want to make snapd depend on every single snap out there
<pedronis> it seems the thing that we should run nightly
<niemeyer> cachio: Sorry, that's a bit extreme..
<pedronis> but not part of the suite for earch commit
<niemeyer> cachio: We don't want to make snapd depend on a random set of snaps
<pedronis> we don't really know what is their quality
<pedronis> over time
<niemeyer> cachio: Even if they are popular, they have their own schedule, and their own terms
<niemeyer> cachio: Our tests are supposed to ensure that the *features* they need are properly covered
<cachio> niemeyer, agree with that
<niemeyer> cachio: Please feel free to open a forum topic and I'll reply there as well with the rationale
<cachio> niemeyer, sure
<niemeyer> cachio: We already depend on way too many external factors in our suite, as you know better than I do :)
<pmcgowan> hey kyleN
<cachio> niemeyer, ok, lets discuss it in the forum
<mup> Bug #1708527 opened: Add /proc/partitions to system-observe <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1708527>
<cjwatson> cachio: the assertions thing should all be better for you now
<cachio> cjwatson, perfect
<cachio> cjwatson, is it already merge in master?
<cachio> or a PR?
<cachio> or a PR?
<cjwatson> cachio: it's on the production store
<cjwatson> cachio: no change in snapd required
<cachio> cjwatson, great!
<PhoenixMage> What is a correctly formatted snap structure supposed to look like?
<PhoenixMage> ie, what dirs are supposed to be in the root
<PhoenixMage> I have found this https://snapcraft.io/docs/snaps/structure but thats not what mine looks like
#snappy 2017-08-04
<zyga-arch> o/
<PhoenixMage> hey zyga-arch
<zyga-arch> hey
<PhoenixMage> what plugin can I use to manaully specify a config file
<zyga-arch> config file?
<PhoenixMage> instead of ./configure
<zyga-arch> well, configure is not a config file :)
<zyga-arch> are you using the autotools plugin today?
<PhoenixMage> Sorry, I am lazy :P
<PhoenixMage> I am for most things
<zyga-arch> if your project is using auto{conf,make} then that's the right way
<PhoenixMage> I was going to compile openssl
<PhoenixMage> It uses ./config
<zyga-arch> if you have some other executable that is "autotools like" then you may need a custom plugin or just use the make plugin and write a makefile with all the rules
<zyga-arch> not a perfect example but... https://github.com/zyga/python0
<zyga-arch> this uses makefile plugin to essentially do whatever you want
<zyga-arch> note that openssl is probably in the core snap
<zyga-arch> so you may not want to build it
<PhoenixMage> I can probably use stage-packages
<PhoenixMage> Compiling samba says it cant find openssl
<zyga-arch> you probably want openssl-dev package or something alike
<mwhudson> waiting for travis for 7 hours on https://github.com/snapcore/snapd/pull/3639 now
<mup> PR snapd#3639: update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
<zyga-ubuntu> hmm
<zyga-ubuntu> odd
<zyga-ubuntu> seems like travis bug
<PhoenixMage> I thought that but openssl-dev doesnt exist anymore.. I'll have to track down the package
<zyga-ubuntu> mwhudson: since vendor.json conficted I'd suggest resolving the conflict and pushing over
<mwhudson> zyga-ubuntu: yeah fair enough
<PhoenixMage> libssl-dev I love consistency
<zyga-ubuntu> openssl is an empty dependency package
<zyga-ubuntu> it depends on libssl1.0.0
<zyga-ubuntu> s/empty/mostly empty/
<zyga-ubuntu> ondra: hey
<ondra> zyga-arch hey
<ondra> zyga-suse or here?
<zyga-ubuntu> ondra: commented and updated https://github.com/snapcore/snapd/pull/3624
<mup> PR snapd#3624: interfaces/builtin: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624>
<ondra> zyga-ubuntu just saw it, good comments and sorry for test code, I used some existing test code, but I guess it's evolving all the time
<zyga-ubuntu> that's fine, I didn't expect anything else, the test code is really in disarray
<zyga-ubuntu> but changing that globally takes some time, ~100 interfaces is a lot of tweaking
 * zyga-ubuntu just saw one more thing to weak
<zyga-ubuntu> fixed
<zyga-ubuntu> ok, what's next..
<zyga-ubuntu> Chipaca: 2nd review on https://github.com/snapcore/snapd/pull/3650 please
<mup> PR snapd#3650: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <https://github.com/snapcore/snapd/pull/3650>
<Chipaca> hadn't i already done this one?
<Chipaca> sorry
<zyga-ubuntu> morphis_: do you have a sec to eyeball https://github.com/snapcore/snapd/pull/3649
<mup> PR snapd#3649: packaging: update arch packaging for 2.27 snapshot <Created by zyga> <https://github.com/snapcore/snapd/pull/3649>
<Chipaca> zyga-ubuntu: +1
<zyga-ubuntu> Chipaca: thank you!
<morphis_> zyga-ubuntu: let me check
<zyga-ubuntu> Chipaca: almost down to zero patches for arch :)
<Chipaca> zyga-ubuntu: I _had_ already done it, just forgotten to â¦ you know, *do* do it
<zyga-ubuntu> Chipaca: 2.27.1 will be a nice release
<zyga-ubuntu> hahaha
<zyga-ubuntu>  :D
<mup> PR snapd#3650 closed: cmd/snap-confine: don't share /etc/nsswitch from host <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3650>
<zyga-ubuntu> Chipaca: btw, I read the chatter from last night and noticed you found the double utf8 encoding bug that broke assertions
<zyga-ubuntu> Chipaca: really nice and ouch!
<Chipaca> harrumph
<pedronis> it should be fixed now
<Chipaca> nothing nice about double encodes
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3648 is simple as well
<mup> PR snapd#3648: release: remove default from VERSION_ID <Created by zyga> <https://github.com/snapcore/snapd/pull/3648>
<pedronis> Chipaca: they fix was easy, but also totally python3 meet http and surrender
<zyga-ubuntu> pedronis: is the fix public to see somewhere?
<zyga-ubuntu> or just ... to see somewhere?
<pedronis> no
<pedronis> anyway it was mostly  s/resp.txt/resp.contet/
<pedronis> *content
<pedronis> *text
<zyga-ubuntu> aha
<zyga-ubuntu> I see
<zyga-ubuntu> django?
<pedronis> no
<morphis_> zyga-ubuntu: done
<zyga-ubuntu> morphis_: thank you
<pedronis> requests (IÂ think)
<abeato> has anybody seen something like this before?:
<abeato> $ snap refresh --beta --ignore-validation network-manager
<abeato> error: cannot perform the following tasks:
<abeato> - Mount snap "network-manager" (218) (installation not allowed by "core-support" plug rule of interface "core-support")
<zyga-ubuntu> morphis_: replied, thank you, I'll iterate!
 * zyga-ubuntu needs to buy more than 4GB of ram
<zyga-ubuntu> morphis_: will you have a sec to do one more? https://github.com/snapcore/snapd/pull/3622
<mup> PR snapd#3622: tests: enable regression, upgrade and completion test suites for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3622>
<morphis_> zyga-ubuntu: if you review my snapd-xdg-open PR again :-)
<morphis_> zyga-ubuntu: done
<zyga-ubuntu> morphis_: I will, thank you!
<zyga-ubuntu> morphis_: basically today I will do just code reviews
<morphis_> :-)
<zyga-ubuntu> morphis_: and I may iterate a little on this huge PR https://github.com/snapcore/snapd/pull/3617 to tweak it to my preference
<mup> PR snapd#3617: Using udev tagging for snap interfaces <Created by adglkh> <https://github.com/snapcore/snapd/pull/3617>
<morphis_> zyga-ubuntu: please talk with gerry before you do so
<morphis_> he is actively working on that
<zyga-ubuntu> morphis_: gerry is adglkh?
<morphis_> yes
<zyga-ubuntu> morphis_: is here around somewhere where I can talk?
<zyga-ubuntu> (I never met him before)
<morphis_> on slack :-)
<zyga-ubuntu> uh
<morphis_> asking him
<zyga-ubuntu> morphis_: where is he from roughly (timezone)
<morphis_> china
<zyga-ubuntu> morphis_: and is he a canonical person?
<morphis_> yes
<morphis_> part of my team
<zyga-ubuntu> why slack then? is irc blocked?
<zyga-ubuntu> morphis_: if he can join here, please ask him
<zyga-ubuntu> otherwise let me know how to join slack
<morphis_> zyga-ubuntu: asked him to join here
<zyga-ubuntu> thank you
<zyga-ubuntu> I heard there is a crackdown on VPNs in china
<zyga-ubuntu> so not sure how to talk to people there
<zyga-ubuntu> why are you using slack currently?
<zyga-ubuntu> gary-wzl77: hey!
<zyga-ubuntu> gary-wzl77: nice to meet you, thank you for joining
<zyga-ubuntu> gary-wzl77: and thank you for working on fixing that huge udev issue, that's quite some work
<gary-wzl77> zyga-ubuntu: Thanks for your code review.
<gary-wzl77> Yes,  I was told by Simon that you have sth to check with me about udev tagging.
<zyga-ubuntu> gary-wzl77: I wanted to discuss a few ideas, mainly because that branch is huge (I'm still reviewing it)
<gary-wzl77> sure
<zyga-ubuntu> gary-wzl77: and that I wanted to de-compose it into pieces
<zyga-ubuntu> gary-wzl77: if you don't mind me doing that I can work on the current state of the branch until the diff from there to master shinks to zero
<gary-wzl77> Never mind :)
<gary-wzl77> I'll submit changes later on per jamie's comments
<zyga-ubuntu> gary-wzl77: I'll start with your improvement to common interface, then to individual interfaces that can be simplified with it
<zyga-ubuntu> gary-wzl77: yes please, let's keep your PR open and iterating on the udev details
<zyga-ubuntu> gary-wzl77: I'll work on the side, proposing small branches that land in master and also merging master back into your branch
<gary-wzl77> Nice .thanks
<zyga-ubuntu> gary-wzl77: so that it can shring in diff size
<zyga-ubuntu> gary-wzl77: and then we can hopefully get to the point where everyone agrees and we can just merge it
<gary-wzl77> RE: Interface simplified
<gary-wzl77> I spoke to Jamie about it and I've been bit reluctant to do it for complex interface like mir, docker, browser-support and alike
<zyga-ubuntu> gary-wzl77: I understand that given the nature of the bug we are in the red anyway until *all* the interfaces are fixed to use udev tagging
<zyga-ubuntu> gary-wzl77: so I think it's fine to fix interface-by-interface
<zyga-ubuntu> gary-wzl77: and even leave TODO/FIXME markers in things we know need love but are non-trivial to do
<gary-wzl77> The reason is it will introduce a few code in common function(like connectedPlugAppArmor , connectedSlotAppArmor or permanent**) of commonInterface
<gary-wzl77> That makes commonInterface a bit fat
<zyga-ubuntu> that's fine
<zyga-ubuntu> it's there to make most of the interface code easy to reason about
<zyga-ubuntu> gary-wzl77: also, I recommend that you stick around on IRC (assuming it is not hard firewall-wise) and on the forum.snapcraft.io
<gary-wzl77> sure:D
<zyga-ubuntu> gary-wzl77: ok, starting now
<gary-wzl77> zyga-ubuntu: sure thing, I also left a comment about spread-test in snap-confine. Would you mind to take a look if you find time-slot.
<zyga-ubuntu> gary-wzl77: looking
<zyga-ubuntu> gary-wzl77: huh, git.launchpad.net/snap-confine should be dead
<zyga-ubuntu> gary-wzl77: which tests are you referring to?
<gary-wzl77> zyga-ubuntu: just generic spread test in snap-confine folder, follow the guidance `make hack` and `run ./spread-prepare`
<gary-wzl77> zyga-ubuntu: then we will have one dependency issue when building deb package along the way
<zyga-ubuntu> gary-wzl77: in the snapd repo, in snapd/cmd/snap-confine folder?
<zyga-ubuntu> hmmm
<zyga-ubuntu> make hack should never be used for spread testing
<zyga-ubuntu> can you point me to the tests you are thinking about?
<gary-wzl77> yes
<zyga-ubuntu> note that the spread tests in snap confine sub-directory are *not* working and need porting
<gary-wzl77> Okay, that's it
<gary-wzl77> zyga-ubuntu: I saw a few changes that we submitted recently improving the spread test for each interface.
<gary-wzl77> Probably we need some tweaks then after we land udev tagging feature
<zyga-ubuntu> definitely
<mup> PR snapd#3657 opened: daemon, client, cmd/snap: implement snap start/stop/restart <Created by chipaca> <https://github.com/snapcore/snapd/pull/3657>
 * zyga-ubuntu -> food
<Chipaca> so, I'm stopping for lunch, and then I need to take one of the boys to the doctor. PR of services ops #n is up, hopefully alright and this PM I'll be working on completion.
 * Chipaca out
<kjackal__> Chipaca: ogra_: Hi again, do we have any news on https://bugs.launchpad.net/snappy/+bug/1687079 ?
<mup> Bug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:Confirmed> <https://launchpad.net/bugs/1687079>
<ogra_> kjackal__, what would you expect as a fix beyond a more descriptive error (i doubt mainline will want to hardcode apparmor support) ?
<kjackal__> ogra_: that bug spawned the discussion we had last week on having daemons wait for the completion of other services before they start up
<kjackal__> ogra_: honestly I am not sure what the fix for the above bug should be
<ogra_> oh, that one ... well, that discussion doesnt really look 100% related
<ogra_> IIRC Chipaca offered to extend the systemd unit generation with options for that ...
<kjackal__> ogra_: Chipaca: here is the problem we are facing: https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/357
<ogra_> (which should really be its own whishlist bug or even better a forum topic)
<ogra_> kjackal__, better make it a forum thred, so it doesnt get lost
<ogra_> *thread
<kjackal__> ogra_: like this one: https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470 ?
<ogra_> yeaah
<ogra_> (that doesnt reflect any of the IRC discussion though)
<ogra_> (IIRC there was aan offer from Chipaca for a fix ... )
<kjackal__> ogra_: Chipaca: we said we would setup a meeting next week with your architect, to discuss what we can do about this issue. If I am not mistaken daemons on lxd will not survive a reboot.
<ogra_> kjackal__, right, but i think he didnt know that niemeyer is (kind of) off this week ...
<ogra_> it would help if the findings from the discussion would be in the thread though ...
<ogra_> that forum topic is as undescriptive as it can be (like the bug :) )
<ogra_> we will need it to end up with a specification what has to be implemented in snapd etc
<ogra_> (and how)
<kjackal__> The issue on github is the point where we gather all the info on the incident. Should I link it to the topic?
<ogra_> kjackal__, i changed the title of the topic ... https://forum.snapcraft.io/t/snap-services-on-lxc-after-a-host-reboot/1470
<ogra_> can you flesh the content out a bit more instead of talking about random snaps and bugs ... (like what do we want to achieve, what has been discussed and offered as possible implementation)
<ogra_> it should look more like a spec in the end
<ogra_> that way the snapd guys can just grab it, nod it off and start working on it
<kjackal__> ok, thanks ogra_
<ogra_> kjackal__, http://paste.ubuntu.com/25239691/ from my IRC logs
<zyga-ubuntu> kjackal__: which kernel are you using?
<ogra_> zyga-ubuntu, not kernel related at all, see my paste
<ogra_> (that linking of these bugs is totally confusing the issue)
<ogra_> zyga-ubuntu, this is solely about snap services being able to wait for oother services to be up
<ogra_> (essentially about allowing "After=*" in snapd units of snaps)
<zyga-ubuntu> aha
<zyga-ubuntu> ok then, not my problem today :)
 * zyga-ubuntu gets back to interfaces
<ondra> zyga-ubuntu double check changes I commented on, I'm not sure about two changes there
<zyga-ubuntu> ondra: thank you, I will in a moment
<ondra> zyga-ubuntu I might be wrong, just double checking :)
<zyga-ubuntu> Chipaca: question, what kind of tab completion should I get out of http?
<zyga-ubuntu> I don't see any
<abeato> zyga- it possible to run a command from inside the snap inside the configure hook?
<abeato> zyga-ubuntu,  it possible to run a command from inside the snap inside the configure hook?
<zyga-ubuntu> ondra: replied
<zyga-ubuntu> abeato: which command?
<abeato> zyga-ubuntu, like using nmcli inside network-manager's configure hook
<zyga-ubuntu> abeato: all hooks are arbitrary programs, so you can run anything you can otherwise run, remember that you are confined, as usual
<zyga-ubuntu> abeato: one restriction is you should not run snap's exposed apps via /snap/bin/snap.app again
<zyga-ubuntu> abeato: instead just run them directly via $SNAP/bin/app
<abeato> zyga-ubuntu, it is strange because I get permissions error that should not happen if running it as root :  https://pastebin.canonical.com/195195/
<zyga-ubuntu> oh please not that one
<zyga-ubuntu> can you repaste to normal one, I don't have my token handy
<abeato> zyga-ubuntu, http://paste.ubuntu.com/25239783/
<zyga-ubuntu> thank you, looking
<zyga-ubuntu> abeato: can you show me the snap.yaml please?
<abeato> zyga-ubuntu, http://paste.ubuntu.com/25239786/
<ogra_> abeato, i suspect you need to connect all the interfaces the snap uses first
<abeato> ogra_, they are connected
<zyga-ubuntu> ogra_: no, not that
<zyga-ubuntu> abeato: so
<ogra_> ok
<zyga-ubuntu> abeato: notice that all the plugs are on the apps
<zyga-ubuntu> abeato: the hooks don't get any
<abeato> zyga-ubuntu, can I add plugs to the hooks?
<zyga-ubuntu> you need to either define a plug at the top level (where it applies to everything)
<niemeyer> Helloooo
<ondra> zyga-ubuntu not sure I follow
<zyga-ubuntu> or also add a hooks section and add specific plugs to your hook
<zyga-ubuntu> ondra: look at that file, look at the symbols I replaced
<ogra_> couldnt he call the apps as well ?
<abeato> aha, did not know that
<ondra> zyga-ubuntu why do we need then avahiControlConnectedSlotAppArmor twice there?
<abeato> zyga-ubuntu, thanks, that is useful :)
<zyga-ubuntu> ondra: before my replacements there were unused snippets
<zyga-ubuntu> ondra: looking
<ogra_> (if the apps are connected, calling them should work as well, no ?)
<zyga-ubuntu> maybe some silly mistake on my end
<zyga-ubuntu> ogra_: no
<zyga-ubuntu> ogra_: the hooks have no slots
<zyga-ubuntu> ogra_: according to that def
<ondra> zyga-ubuntu and idea there was that control also includes rules from observe
<zyga-ubuntu> oooooh
<zyga-ubuntu> ondra: I'm blind
<zyga-ubuntu> I didn't see the +
<zyga-ubuntu> thanks!
<ondra> zyga-ubuntu so it does not need to be defined same again there
<zyga-ubuntu> yes, I don't know how I missed that :)
<ogra_> zyga-ubuntu, why would i need slots ... if i have an app "foobar" that has a plug connected, my hook shoud be able to use foobar
<zyga-ubuntu> ondra: still, I'm somewhat inclined to use a common one
<zyga-ubuntu> and not do + on snippets
<zyga-ubuntu> just call the helper twice
<ogra_> (without any extra plugs or slots)
<ondra> zyga-ubuntu don't worry I was staring at it for 5mins and even used string compare to make sure :D
<zyga-ubuntu> ogra_: sorry, I meant plugs
<zyga-ubuntu> ogra_: no, that's not how this is designed, the app may need super strong permissions
<ondra> zyga-ubuntu ahh is that is possible then for sure calling helper twice is better
<zyga-ubuntu> ogra_: and the hook can be separate
<zyga-ubuntu> ogra_: like two apps can get two separate permissions
<ogra_> is it any different to me executing the foobar app manually ?
<ondra> zyga-ubuntu shall I do the change?
<zyga-ubuntu> ogra_: each hook and app can have a separate set of plugs
<zyga-ubuntu> ogra_: a plug is either connected or not
<ogra_> hmm
<zyga-ubuntu> ogra_: but the application of that connection is not the same to all executables
<ogra_> i wouldnt expect it to work like that as a consumer
<zyga-ubuntu> ogra_: whoever is making the snap can associate a particular app or hook with a particular set of plugs
<zyga-ubuntu> ogra_: so that you can do privilege separation inside one snap
<zyga-ubuntu> ogra_: where nmcli doesn't need the full power to run as network-manager
<zyga-ubuntu> ogra_: and the same thing applies to the hook
<zyga-ubuntu> ogra_: inside that snap only network manager itself needs that
<zyga-ubuntu> ogra_: the hook and the cli tool just need the permission to talk to it
<zyga-ubuntu> ogra_: depending on how you define a plug it is scoped to either everything in the snap (by defining a top-level plug)
<zyga-ubuntu> ogra_: or to a specific set of apps (by refering to a plug from their definitions)
<ogra_> right, and i would expect that if the cli tool is connected i could call out from any script to it to run it ... even if that script was a hook
<zyga-ubuntu> ogra_: I think hooks have one more quirk but I'm not sure now
<zyga-ubuntu> ogra_: right but he's not calling the CLI tool
<zyga-ubuntu> ogra_: he's running the hook
<zyga-ubuntu> and the hook runs as its own profile
<ogra_> yes, what i suggested was calling the cli tool from the hook :)
<zyga-ubuntu> ogra_: and we don't allow profile transitions
<zyga-ubuntu> ogra_: note that the CLI tool has two "instances"
<zyga-ubuntu> ogra_: the /snap/bin/network-manager.cli (say) is one
<zyga-ubuntu> ogra_: and $SNAP/bin/nmcli is another
<zyga-ubuntu> that's the same executable
<zyga-ubuntu> but two profiles
<zyga-ubuntu> well
<zyga-ubuntu> one profile and one no-profile
<ogra_> right
<zyga-ubuntu> ogra_: the one in /snap sets the profile
<zyga-ubuntu> (in /snap/bin)
<ogra_> and i as a user of it would expect that my script can use $SNAP/bin/nmcli
<zyga-ubuntu> the other one runs as whoever is running it (it inherits the profile)
<ogra_> as long as all interfaces for it are cnnected
<zyga-ubuntu> it can, but nmcli cannot talk to network manager because the hook doesn't have the permission to do so
<ogra_> wether that script is a hook or some script in my lhomedir
<zyga-ubuntu> because as the user (developer of the snap really) that is what was specified
<ogra_> that seems duplicated to me
<zyga-ubuntu> I don't understand the script in homedir aspect
<zyga-ubuntu> ogra_: what exactly?
<ogra_> the only person that can alter the hook is the developer of the snap anyway
<zyga-ubuntu> ogra_: it's like having two apps in a snap
<zyga-ubuntu> and defining a plug on just one of them
<ogra_> so why do we need double confinement here
<zyga-ubuntu> the other is not getting those permissions
<zyga-ubuntu> that's exactly what is going on here
<ogra_> shipped apps should just be callable from a hook
<zyga-ubuntu> ogra_: it's not double confinement, it's *scoping* the confinement
<ogra_> (as long as the app interfaces themselves are connected)
<zyga-ubuntu> ogra_: they *are* with the permissions of the *hook*
<zyga-ubuntu> and a hook is just as any other pap
<zyga-ubuntu> *app
<zyga-ubuntu> it has permissions derived from the plugs that apply to it
<ogra_> well, call it "wrapped confinement" then :)
<ogra_> its an extra level ...
<zyga-ubuntu> and the only problem is that the *hook* was not defined as needing that permission (no plug) so it didn't et them
<ogra_> and i dont get why we'd need that
<zyga-ubuntu> no, you don't understand
<zyga-ubuntu> the hook is not calling /snap/bin/nmcli
<zyga-ubuntu> if it did there would be a different message
<zyga-ubuntu> that this is not allowed
<niemeyer> Chipaca, zyga-ubuntu: standup
<zyga-ubuntu> oh
<zyga-ubuntu> sorry
<zyga-ubuntu> joiuning
<zyga-ubuntu> ogra_: let's discuss this later
<ogra_> i have one level of confinement in the app ... and another layer on top for the hook ... but i'm also the owner of the snap so i dont see the need for the extra confinement in the hook (just adds extra work for me to define additional slot/plug connections ... i have the power to do so anyway but need to separately declare it)
<ogra_> zyga-ubuntu, yeah
<ondra> zyga-ubuntu I just pushed change, let me know if this is better way
<ogra_> nessita_, since you transferred the orangepi-zero gadget i have a giant red "REVOKED" at the top of my dashboard, is there any way to get rid of the snap from my dashboard oveview ?
<zyga-ubuntu> ondra: thank you, I'll check after the call
<ondra> zyga-ubuntu thanks :)
<zyga-ubuntu> ogra_: those are not levels, those are scopes, each app and hook has its own confinement, you don't get any nested confinement in any place
<ogra_> well, i need to declare confinement stuff twice when wanting to use foobar in my hook ... once for foobar itself and once for the hook
<ogra_> what i mean is that any apps shipped inside the snap shouldnt require that to use them from the hook of the same snap
<zyga-ubuntu> you *never* apply the conifnement to binaries in the snap
<zyga-ubuntu> you only apply them to launchers (the command: section in each app)
<ogra_> yes
<ogra_> and my hook should be able to use them from the launchers ... thats what i mean
<ogra_> without having to specify any additional confinement
<zyga-ubuntu> it can, that's never the problem, the problem is that they cannot do what they want because how would we know what they need?
<zyga-ubuntu> you can *exec* each binary in your snap
<ogra_> no, then the interfaces for the app dont apply
<zyga-ubuntu> nmcli talks over dbus with network-manager
<zyga-ubuntu> binary != app
<zyga-ubuntu> app is a command
<zyga-ubuntu> what if I have two apps
<zyga-ubuntu> that run one binary
<zyga-ubuntu> with two different options
<ogra_> right and there is an interface that applied if i call it as /snap/bin/nmcli
<zyga-ubuntu> and two different permissions?
<ogra_> *applies
<zyga-ubuntu> yes but you cannot call that from inside a snap, that's explicitly denied
<ogra_> instead of $SNAP/usr/bin/nmcli directly
<ogra_> yes
<ogra_> and thats what i'm debating ;)
<zyga-ubuntu> that /snap/bin/nmcli should be allowed?
<ogra_> an app shipped inside my own snap shouldnt be denied when called from inside that same snap
<ogra_> so that i can use it from a hook without having to jump through hoops
<zyga-ubuntu> man, that's not the problem
<zyga-ubuntu> one sec
<ogra_> indeed the dbus interface still needs to be connected for the app
<ogra_> (which my hook cant do)
<zyga-ubuntu> ogra_: http://pastebin.ubuntu.com/25239924/
<ogra_> yeah
<zyga-ubuntu> ogra_: what permissions would you expect to see if the hook runs bin/foo?
<ogra_> well, my hook should run /snap/bin/a (or b)
<ogra_> and the normal confinement for a or b should apply
<ogra_> so that my hook doesnt need any different or separate confinement
<zyga-ubuntu> right
<zyga-ubuntu> that I agree with
<zyga-ubuntu> but this is not allowed today for a few reasons
<ogra_> and in that case the answer to alfonso above would have been use /snap/bin/nmcli and be done
<ogra_> the thing is that the person writing the hook has the power to allow this anyway ...
<ogra_> but needs to jump through more hoops by defining interfaces for the hook today
<ogra_> apps declared in my snapcraft.yaml shoudl just be usable from my hook without extra work ... thats the point i'm making :)
<zyga-ubuntu> ogra_: right, and that's, as I said, not allowed for a few reason
<zyga-ubuntu> *reasons
<ogra_> i dont see any security advantage of the current model
<zyga-ubuntu> the primary reason was that it would be tempting to run run stuff from another snap
<zyga-ubuntu> and at the point when snap-confine runs we don't have a way to reject just those
<ogra_> well
<ogra_> i didnt say ""allow calling something from another snap"
<ogra_> just within the same snap
<zyga-ubuntu> right, but at the time the request comes in there's not enough context to decide
<zyga-ubuntu> so we reject all of them
<ogra_> if the app and hook are inside the same ...
<zyga-ubuntu> and we're back to square one
<ogra_> ah
<ogra_> so we'll need meore context :)
<ogra_> *more
<niemeyer> popey: ping
<zyga-ubuntu> ondra: looks good, thank you for noticing :)
<ondra> zyga-ubuntu thank  you for helping me with PR :)
<cachio> ogra_, I try to configure my pi3 and I see -> Canât find valid F2FS filesystem in 1th/sth superblock
<cachio> any idea?
<ogra_> cachio, thats nothing bad ... just the kernel looping over filesystems
<cachio> ok
<cachio> ogra_, tx
<ogra_> like it also does for ext2 and ext before it actually mounts an ext4 FS
<ogra_> *for ext2 and ext3
<ogra_> that also spills some ugly messages
<bub_> Humm, how do I install X?
<bub_> X Window.. or some displayservice..
<ogra_> you mean on UbuntuCore ?
<ogra_> you cant
<ogra_> there is not way X ever matches the security model
<bub_> Aha, haha..
<ogra_> there is a mir-kiosk snap that you can use for having kiosk apps (standalone fullscreen app)
<bub_> yeah right, but no way we're going to get Qt with its graphiclibraries run on Ubuntu Core then I Guess
<bub_> s/Guess/guess
<ogra_> but indeed your app then needs to support mir
<ogra_> Qt runs fine on mir-kiosk
<popey> niemeyer: heya.
<ogra_> in fact the demo apps are all Qt
<popey> niemeyer: i guess i scheduled the meeting too early?
<niemeyer> popey: Yo
<niemeyer> popey: No, I was the one screwing up, sorry
<niemeyer> popey: Do you want to have a quick catch up now?
<bub_> ok, so mir-kiosk might save us.. tyty
<ogra_> bub_, the guys in #ubuntu-mir might know more details
<popey> niemeyer: unfortunately I'm a busy for the next 2.5 hours. After that? 16:30 UTC?
<niemeyer> popey: Deal
<popey> niemeyer: invite sent
<niemeyer> popey: Thanks, talk soon
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> around?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
<mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
<zyga-ubuntu> anyway, some small PR for quick landing, I'll iterate on next part
<mup> PR snapd#3658 opened: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
<cachio> ogra_, when I insert the sdcard it I showing a disk on /dev/mmcblk0
<cachio> ogra_, but not /dev/mmcblk0p0
<cachio> is that a problem?
<cachio> it has two partitions p1 and p2 instead
<zyga-ubuntu> gary-wzl77: around?
<zyga-ubuntu> well, probably not on Friday
<Chipaca> zyga-ubuntu: http's tab completer for bash is rather poor, it only offers options (i.e. type -, hit tab)
 * zyga-ubuntu checks
<zyga-ubuntu> nothing
<mup> PR snapd#3659 opened: tests: fix install-hook test failure <Created by stolowski> <https://github.com/snapcore/snapd/pull/3659>
<zyga-ubuntu> is that a thing that's out in stable core?
<Chipaca> zyga-ubuntu: have you sourced complete.sh?
<zyga-ubuntu> Chipaca: where is it?
<Chipaca> zyga-ubuntu: /snap/core/current/usr/lib/snapd/complete.sh
<pstolowski> cachio, ^ fix for the install-hook test failure, for master first. i'll propose fix for 2.27 too if that makes sense?
<zyga-ubuntu> ah
<zyga-ubuntu> Chipaca: right
<zyga-ubuntu> we need "re-exec" for that
<zyga-ubuntu> thanks
<ogra_> cachio, what would you expect 0p0 to be ? :)
<Chipaca> zyga-ubuntu: we wha?
<zyga-ubuntu> Chipaca: sourced but nothing
<zyga-ubuntu> Chipaca: (let's talk reexec later)
<Chipaca> zyga-ubuntu: complete -p http
<Chipaca> zyga-ubuntu: your trying it before probably loaded _minimal in there
<ogra_> cachio, /dev/mmcblk0 is the device ... /dev/mmcblk0p1 is system-boot and /dev/mmcblk0p2 is writable ...
<zyga-ubuntu> complete -F _minimal http
<Chipaca> zyga-ubuntu: in which case, complete -r http
<Chipaca> zyga-ubuntu: and try agian
<ogra_> cachio, partitioning starts to count at 1 not at 0
<ogra_> so it should all be fine as is
<cachio> ogra_, ok, it was appearing p0
<ogra_> that would be a massive kernel bug :)
<zyga-ubuntu> Chipaca: that said:
<zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ complete -r h
<zyga-ubuntu> bash: complete: h: brak definicji dla uzupeÅnienia
<zyga-ubuntu> (I set locale to english but... well)
<gary-wzl77> zyga-ubuntu: yeah, still here :D
<ogra_> ogra@pi3:~$ cat /proc/partitions |grep mmc
<ogra_>  179        0    3921920 mmcblk0
<ogra_>  179        1     131072 mmcblk0p1
<ogra_>  179        2    3789779 mmcblk0p2
<zyga-ubuntu> "no definitions for completion"
<zyga-ubuntu> gary-wzl77: ah, nice, can you please have a look at
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
<mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
<Chipaca> zyga-ubuntu: literally h, or http?
<zyga-ubuntu> Chipaca: that was a typo, I did write http
<gary-wzl77> zyga-ubuntu: sure
<zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ complete -r http
<zyga-ubuntu> bash: complete: http: brak definicji dla uzupeÅnienia
<cachio> ogra_, ok, just trying to understand why it is showing the message that I told you before
<Chipaca> zyga-ubuntu: and complete -p http?
<ogra_> cachio, hmm, perhaps if you format the raw device instead of partitioning it at all you might get a p0 ... i never did such insanity ... (but could be that cameras or some such do that)
<zyga-ubuntu> "przed wyruszenie w podrÃ³Å¼ naleÅ¼y zebraÄ druÅ¼yne"
<zyga-ubuntu> Chipaca: -p says the same thing
<Chipaca> zyga-ubuntu: ok so you dropped the _minimal definition
<Chipaca> um
<Chipaca> zyga-ubuntu: do you have two shells open and did the other -p in the other one?
<cachio> ogra_, ok, just I wanted to make sure there was not an error on there
<zyga-ubuntu> Chipaca: no, it's all in one shell
<ogra_> no, the system SD should always have p1 and p2
<zyga-ubuntu> zyga@fyke:~/go/src/github.com/snapcore/snapd/interfaces/builtin$ snap version
<zyga-ubuntu> snap    2.26.14
<zyga-ubuntu> snapd   2.26.14
<zyga-ubuntu> series  16
<zyga-ubuntu> ubuntu  16.04
<zyga-ubuntu> kernel  4.8.0-58-generic
<zyga-ubuntu> in case this is relevant
<Chipaca> zyga-ubuntu: ok, what does âtype _complete_from_snapâ say
<zyga-ubuntu> tons of stuff
<zyga-ubuntu> the good thing
<Chipaca> zyga-ubuntu: good
<mup> PR snapd#3633 closed: overlord/devicestate: fix, don't assume that the serial is backed by a 1-key chain <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3633>
<Chipaca> zyga-ubuntu: so now http -<tab> should do something
<zyga-ubuntu> it's a function with the code
<zyga-ubuntu> nope :)
<zyga-ubuntu> it doesn't
<zyga-ubuntu> what are we missing? :)
<Chipaca> zyga-ubuntu: what revision of http do you have?
<zyga-ubuntu> 21
<Chipaca> zyga-ubuntu: what does âcomplete -p httpâ say _now_?
<zyga-ubuntu> no definitions
<Chipaca> zyga-ubuntu: what does âcomplete -p -Dâ say?
<zyga-ubuntu> bash: complete: _DefaultCmD_: brak definicji dla uzupeÅnienia
<zyga-ubuntu> (little by little I can teach you polish)
<Chipaca> double to the you to the eff
<Chipaca> zyga-ubuntu: ok, so, start a new shell
<zyga-ubuntu> reday
<zyga-ubuntu> ready*
<Chipaca> zyga-ubuntu: complete -p -D
<zyga-ubuntu> complete -F _completion_loader -D
<Chipaca> zyga-ubuntu: now, source complete.sh
<Chipaca> zyga-ubuntu: note: source, not run, source
<zyga-ubuntu> k
<zyga-ubuntu> done
<Chipaca> zyga-ubuntu: complete -p -D
<zyga-ubuntu> complete -F _complete_from_snap_maybe -D
<Chipaca> zyga-ubuntu: http -<tab>
<zyga-ubuntu> nothing
<Chipaca> zyga-ubuntu: tab again
<zyga-ubuntu> I'm tab-tab-tabbing
<zyga-ubuntu> nothing
<Chipaca> zyga-ubuntu: AGAIN
 * Chipaca throws things
<zyga-ubuntu> 12s of times actually
 * zyga-ubuntu hugs chipaca
<zyga-ubuntu> wanna hangout?
<zyga-ubuntu> can it be locale somewhere
<Chipaca> zyga-ubuntu: complete -p -D ?
<zyga-ubuntu> or something like
<zyga-ubuntu> complete -F _complete_from_snap_maybe -D
<Chipaca> zyga-ubuntu: set -x
<Chipaca> zyga-ubuntu: http -<tab><tab>
<zyga-ubuntu> stuff flies
<zyga-ubuntu> very chatty
<Chipaca> zyga-ubuntu: _what_ stuff
<zyga-ubuntu> wanna see?
<zyga-ubuntu> sec
<Chipaca> zyga-ubuntu: set +x now, for sanity
<Chipaca> ;-)
<Chipaca> zyga-ubuntu: please
<zyga-ubuntu> http://pastebin.ubuntu.com/25240232/
<zyga-ubuntu> gary-wzl77: if that looks ok to you +1 it please
<zyga-ubuntu> gary-wzl77: I tweaked some things
<zyga-ubuntu> I'll merge this into your branch and start iterating on interfaces (I did one as a sanity check)
<Chipaca> zyga-ubuntu: that pastebin makes no sense to me
<zyga-ubuntu> Chipaca: welcome to my world
<zyga-ubuntu> at least you understand some of it
<Chipaca> zyga-ubuntu: ok, try this
<Chipaca> zyga-ubuntu: complete -F _complete_from_snap http
<zyga-ubuntu> empty
<zyga-ubuntu> technically
<zyga-ubuntu> $ complete -F _complete_from_snap http
<zyga-ubuntu> + complete -F _complete_from_snap http
<zyga-ubuntu> (nothing else)
<Chipaca> zyga-ubuntu: set +x
<zyga-ubuntu> now really empty
<Chipaca> zyga-ubuntu: does http -<tab> do stuff now?
<zyga-ubuntu> YES!
<zyga-ubuntu> wow
<zyga-ubuntu> what changed?
<zyga-ubuntu> I see some denials
<Chipaca> zyga-ubuntu: could you pastebin âtype _complete_from_snap_maybeâ?
<zyga-ubuntu> but it completes
<zyga-ubuntu> http://pastebin.ubuntu.com/25240249/
<Chipaca> zyga-ubuntu: and could you confirm that complete -p -D is still _complete_from_snap_maybe?
<zyga-ubuntu> sie 04 16:29:25 fyke kernel: audit: type=1400 audit(1501856965.430:1150): apparmor="DENIED" operation="open" profile="snap.http.http" name="/etc/init.d/" pid=13425 comm="bash" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga-ubuntu> (unrelated denial)
<zyga-ubuntu> nope
<zyga-ubuntu> $ complete -p -D
<zyga-ubuntu> bash: complete: _DefaultCmD_: brak definicji dla uzupeÅnienia
<Chipaca> WTF
<zyga-ubuntu> (in the same terminal)
<zyga-ubuntu> and it still completes OK
<Chipaca> yes now it's completing because of the -F
<Chipaca> it's not going via the default
<zyga-ubuntu> aha
<Chipaca> zyga-ubuntu: ok, so now
<Chipaca> zyga-ubuntu: compelte -r http
<Chipaca> complete*
<zyga-ubuntu> empty (typo corrected)
<Chipaca> zyga-ubuntu: complete -F _complete_from_snap_maybe -D
<zyga-ubuntu> empty as well
<Chipaca> zyga-ubuntu: does that end up with http -<tab> working again?
<zyga-ubuntu> it still works
<zyga-ubuntu> it didn't break since I said *wow*
<Chipaca> zyga-ubuntu: something is removing the default completer
<Chipaca> zyga-ubuntu: (that's the -D one)
<Chipaca> zyga-ubuntu: so if âcomplete -p -Dâ says there's no uzupeÅnienia, it's bad
<zyga-ubuntu> that says
<zyga-ubuntu> complete -F _complete_from_snap_maybe -D
<Chipaca> zyga-ubuntu: something's unuzupeÅnieniaing it!
<zyga-ubuntu> :') grammar
<Chipaca> zyga-ubuntu: the great unuzupeÅnieniator!
<zyga-ubuntu> hahaha
<Chipaca> zyga-ubuntu: why âfykeâ btw?
<zyga-ubuntu> fyke is my x250
<zyga-ubuntu> faroe is my t430
<Chipaca> zyga-ubuntu: i mean, it's a bag net for catching fish
<Chipaca> (in english i mean)
<zyga-ubuntu> oh, I just pulled this out of the witcher 3 locations map
<Chipaca> ah :) ok
<zyga-ubuntu> http://witcher.wikia.com/wiki/Fyke_Isle
<Chipaca> k
<Chipaca> anyway, somehting needs fixing, but not sure what
<Chipaca> i'll dig into it
<zyga-ubuntu> (read that description)
<zyga-ubuntu> it's fun :D
<Chipaca> i've got a suspicion that needs checking out
<gary-wzl77> zyga-ubuntu: I left one comment. please take a look.
<zyga-ubuntu> gary-wzl77: thank you, looking now
<cachio> niemeyer, I am planning to try a way yo reproduce the error on the reboot for ubuntu-core on linode, are you going to be available this afternon?
<zyga-ubuntu> gary-wzl77: replied, thanks!
<zyga-ubuntu> Chipaca: I feel like getting a coffee
<zyga-ubuntu> do you need me now or can I just go>
<niemeyer> cachio: Yeah, I have meetings early on, but then I'm available til the end of the day
<zyga-ubuntu> Chipaca: and if you can +1 I'll land and iterate on some stuff
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3658
<mup> PR snapd#3658: interfaces: add common support for udev <Created by zyga> <https://github.com/snapcore/snapd/pull/3658>
<cachio> niemeyer, good, I'll ping you once I reproduce the error
<zyga-ubuntu> Chipaca: and as for http itself, it would be great to make it not read /etc/init.d/
<zyga-ubuntu> Chipaca: ok, I'm really going now, I'll be online in 20 minutes
<zyga-ubuntu> just need to go downstairs to make the coffee there
<gary-wzl77> zyga-ubuntu: Since we added kvm interface lately,  I'll update it to use my version of UDevConnectedPlug for the time being.
<gary-wzl77> zyga-ubuntu: And will make some tweaks later after you PR is merged into master.
<cachio> ogra_, getting the resize problem again https://paste.ubuntu.com/25240332/
<cachio> does it helpÂ¡
<cachio> ?
<cachio> it is in the pi3
<ogra_> cachio, i dont see a problem there (just normal fs corrections) ... what do "df -h" and "sudo sgdisk -p /dev/mmcblk0" show ?
<ogra_> (and did you make sure the SD isnt mounted when dd*ing it ... etc etc ... )
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<cachio> ogra_, https://paste.ubuntu.com/25240354/
<cachio> ogra_, I'll try again
<ogra_> cachio, right, your partition table is broken once again ..
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#48 opened: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
<mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48>
<mup> PR core#49 closed: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#49 opened: more detailed build instructions <Created by ogra1> <https://github.com/snapcore/core/pull/49>
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # closed: snapcraft#1277, snapcraft#1298, snapcraft#1302, snapcraft#1313, snapcraft#1346, snapcraft#1348, snapcraft#1364, snapcraft#1382, snapcraft#1387, snapcraft#1388, snapcraft#1392, snapcraft#1395, snapcraft#1399, snapcraft#1407, snapcraft#1412, snapcraft#1414, snapcraft#1417,
<mup> snapcraft#1419, snapcraft#1420, snapcraft#1425, snapcraft#1427, snapcraft#1428, snapcraft#1429, snapcraft#1430, snapcraft#1432, snapcraft#1435
<ogra_> cachio, perhaps you should file a bug and assign it to me to add more stuff to that log (i think it should perhaps run dh -f and sgdisk -p after the resize and dump that data into the log too )
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
<ogra_> hmpf ... mup going mad again ?
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
<mup> PR # closed: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
 * ogra holds the flyswatter over mup's head ...
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # opened: snapd#2807, snapd#2837, snapd#3120, snapd#3260, snapd#3346, snapd#3372, snapd#3398, snapd#3456, snapd#3478, snapd#3484, snapd#3499, snapd#3502, snapd#3520, snapd#3524, snapd#3526, snapd#3556, snapd#3560, snapd#3565, snapd#3568, snapd#3569, snapd#3571, snapd#3573, snapd#3581,
<mup> snapd#3585, snapd#3586, snapd#3590, snapd#3593, snapd#3594, snapd#3604, snapd#3616, snapd#3617, snapd#3621, snapd#3622, snapd#3624, snapd#3625, snapd#3632, snapd#3635, snapd#3636, snapd#3639, snapd#3641, snapd#3642, snapd#3643, snapd#3648, snapd#3649, snapd#3657, snapd#3658, snapd#3659
<ogra> :P
<Chipaca> ogra: thank you
<Chipaca> does this mean github is down again?
<ogra> seems fine for my own branches
<ogra> and i can open snapcore ones as well ... (at least via the website)
<Saviq> hey all, can build.snapcraft.io accept a pre-existing snap name? one that I am a collaborator for?
<Saviq> I've tried to register https://github.com/MirServer/mir-kiosk-apps, but it says mir-kiosk-apps is already taken and I may file a claim...
<ogra> well if you want to take it over, file a claim
<ogra> if you just want to upload ... just do it without claiming the name
<Saviq> ogra: how do I do this with build.snapcraft.io? the repo is shown as "Not registered", when trying to register, it tells me that it's taken
<ogra> hmm
<ogra> thats a  question for evan ... who isnt much on IRC anymore recenly
<ogra> try opening a forum thread i guess
<ogra> (and ping him there)
<Saviq> thanks, did so
<cachio> ogra, after make snap refresh and reboot in the pi 3 I see this in the screen https://paste.ubuntu.com/25240921/
<cachio> is it normal?
<pstolowski> cachio, do need that fix for install-hook test for 2.27? or only master?
<ogra> cachio, i have this with one SD card that is completely worn out due to too many write cycles to the bootloader config (it used to be my development card where i tested stuff and changed the config like ten times a day) ... smells like the SD is done (at least for booting, i guess you can use it fine in a camera for saving pictures still)
<pstolowski> *do we*
<cachio> pstolowski, if it is possible to add that to the nect RC should be great
<pstolowski> cachio, sure, np, i'll propose a PR
<cachio> pstolowski, great
<cachio> ogra, ok, I'll try with another one
<ogra> cachio, do you have that card in use for testing for long already ?
<cachio> ogra, no so much
<ogra> hmm
<cachio> ogra, https://paste.ubuntu.com/25240943/
<cachio> then I see this
<ogra> yeah
<ogra> thats notmal if it cant find any config anymore
<ogra> the uboot.env is corrupt
<ogra> *normal
<cachio> ogra, ok, I'll try with another sdcard in that case
 * cachio will need to buy new sd cards soon
<ogra> the prob here is that the uboot.env always sits at the same sector on the card ... and if you re-write it a lot it gets worn out (that wont happen in nromal use )
<cachio> ogra, ok, that makes sense
<ogra> what you see there is just the hardcoded default boot process of uboot
<ogra> (it falls back to netbooting )
<pstolowski> cachio, PR #3661
<ogra> your dhcp server obviously serves tftp btw :)
<cachio> pstolowski, tx
<cachio> ogra, I switched off/on the pi3 and I don't see the error anymore, I could log in
<ogra> yeah
<cachio> ogra, the problem was after restart it
<ogra> it will show up after next kernel or core upgrade again
<cachio> yes,
<ogra> as soon as the uboot.env file gets written again
<cachio> just want I need to test :(
<ogra> you likely tested the rollback mechanism ;)
<ogra> check with snap list ... and snap info what core and pi2-kernel say
<cachio> hehehe, yes, unfortunately
<cachio> ogra, snap changes is showing the error
<ogra> yeah
<cachio> I'll try with another sdcard
<ogra> and snap info likely shows you that you are one revision behind on one of core or pi2-kernel
<ogra> (whatever you updated before the reboot)
<cachio> ogra, which sd card do you recommend for this kind of use
<cachio> =
<cachio> ?
<cachio> ogra, which brand and type
<ogra> i usually jjust randomly buy a cheap offer at my electronics discounter ... sandisk or transcend typically
<ogra> i have a few 4GB ones in use but also 64G and 128G ones
<cachio> ok
<ogra> i dont think you can still easily buy 4G thogh ... i think 8 is the lowest atm
<ogra> (at least here in germany ... it bought two new cards before london (that i didnt even unpack yet) and they didnt have smaller than 8 anymore)
<cachio> ogra, ok, I'll try with 8GB ones
<Chipaca> pedronis: have you EOWed yet?
<pedronis> Chipaca: what's the question?
<Chipaca> pedronis: i pushed code to the services branch, was wondering if it what you had in mind, but i'm this >< close from EOW myself as well :-)
<pedronis> Monday :)
<Chipaca> pedronis: :-)
<Chipaca> pedronis: have a good'un!
<pedronis> same
<Chipaca> niemeyer, zyga, ogra, cachio, and you guys too!
<Chipaca> \o
<niemeyer> o/
<superjonotron> does anybody know the official way to confiure network interfaces in ubuntu core 16?  have yet to find official documentation and files in /etc/network/interfaces.d folder do not seem to have any effect
<Neeraj> I am not able to update the snap on dell 5000 GW did any one tried snap update
 * zyga-arch returns
 * zyga-arch will make lots of PRs like this: https://github.com/snapcore/snapd/pull/3662
<cachio> niemeyer, running tests to detect reboot issue
<niemeyer> cachio: Ok
<Neeraj> hi anybody used DELL GW5000 "snap refresh " is not working
<Facu> Neeraj, hello
<Facu> Neeraj, you opened this?
<Facu> https://forum.snapcraft.io/t/dell-gw5000-snap/1559
<Neeraj> <facu> yes
<Neeraj> yes
<Facu> Neeraj, sorry, I already commented on the forum
<Facu> Neeraj, most surely is this (transient) problem: a new version was released for that snap, but still not verified, and (because of a bug) we're failing to serve it properly.
<Facu> Neeraj, bug is recorded here: https://bugs.launchpad.net/snapstore/+bug/1707206 , it's already fixed, but still not in production (will be rolled out first days next week)
<Neeraj> Facu, thanks for the update
<Neeraj> Facu is their any way to install sanp classic for now
<Facu> Neeraj, the problem is on refresh, on install it should work ok
<Neeraj> Facu you mean to say that after sucessfull refresh the installation of classic will work
<Facu> Neeraj, mmm... I say that if you do "snap install something" it will work, that the bug I'm talking about is exposed when you do "snap refresh something"
<Facu> Neeraj, currently you can not do "snap install something"?
<Facu> (maybe there's another problema and I'm misleading)
<Neeraj> Facu you are correct I guess after refreshing the installation should work ::: the error is "ERROR snap "classic" assumes unsupported features: snapd2.23 (try to refresh the core snap)"
<noise][> Neeraj: ah, so your device is quite a bit behind on core updates
<Facu> Neeraj, I see
<noise][> Neeraj: what does `snap version` and `'snap info core` show?
<Neeraj> noise snap version is "  snap --version snap    2.17 snapd   2.17 series  16"
<noise][> ok, very far behind then :/
<Neeraj> Noise : once I execute "snap info core" i get error :: error: unknown command "info", see "snap --help"
<noise][> When Facu's fix lands hopefully Mon/Tues that should unblock your 'core' snap refresh and then let you install classic
<noise][> sorry for the inconvenience
<Neeraj> thanks
<cachio> niemeyer, Spread-50
<cachio> 173.230.156.151
<niemeyer> cachio: Okay, what should I look for?
<cachio> the output in the console
<cachio> it is not starting after reboot
<cachio> niemeyer, I need to know what is showing the linode console
<cachio> niemeyer, or if you can save the disk should be nice too
<niemeyer> cachio: http://paste.ubuntu.com/25242314/
<cachio> niemeyer, nice
<cachio> No space left on device
<niemeyer> Yep
<cachio> niemeyer, which disk are we using for core runs?
<cachio> on linode
<niemeyer> cachio: This is what happens before the panic:
<niemeyer> + mount -t tmpfs none /tmp
<niemeyer> + cp /bin/busybox /tmp
<niemeyer> + cp /home/image/all-snap-amd64.img /tmp
<niemeyer> cachio: So it's not actually adisk
<niemeyer> cachio: The tmpfs is too small
<niemeyer> Not enough memory
<cachio> I see
<niemeyer> cachio: Problem most likely is that all-snap being too large
<niemeyer> cachio: Sorry, that's obvious.. what I actually mean is
<niemeyer> cachio: The problem most likely is that somehow we're leaving trash around during the test run, and then trying to pack it into that file
<niemeyer> cachio: let me try to give you a debug environment on that machine.. just a second
<cachio> niemeyer, good, thanks
<cachio> niemeyer, in this case, the machine did not run any test before the reboot
<cachio> so, I don't think there is any trash
<niemeyer> cachio: Your spread is still running, right?
<cachio> niemeyer, it is on travis
<cachio> niemeyer, if you can save the disk should be great
<cachio> it will be killed in few minutes
<niemeyer> cachio: Oh, ouch
<niemeyer> cachio: Glad you warned me ;)
<niemeyer> cachio: Okay, the machine should be up again now
<niemeyer> cachio: root has the same password
<niemeyer> cachio: It's a pristine 16.04 image, though
<niemeyer> cachio: Original disk is under /dev/sdc
<niemeyer> cachio: Have fun! :)
<cachio> niemeyer, I don't have the password :)
<cachio> how do I get it?
<niemeyer> cachio: Now you do
<cachio> niemeyer, :)
<cachio> tx
<niemeyer> cachio: School run, will bbiab
<cachio> niemeyer, np
<niemeyer> cachio: Back.. any news?
<cachio> niemeyer, not yet, trying to reproduce it
 * zyga-suse EOWs
<cachio> niemeyer, the only thing I see is that /tmp is not being cleaned before reboot
<cachio> and as the first thing the system does when reboots is to mount /tmp
<niemeyer> cachio: How would that be relevant?
<cachio> in /tmp already are a lot of things
<niemeyer> cachio: But how would that matter?
<cachio> niemeyer, it is mounting /tmp on memory
<cachio> so if /tmp has data, it will waste memory on that data
<cachio> niemeyer, perhaps I am missunderstanding the script
<niemeyer> cachio: Isn't it mounting a tmpfs on /tmp?
<cachio> yes
<cachio> niemeyer, or at least it is doing > mount -t tmpfs none /tmp
<niemeyer> cachio: SO how is the data in the underlying /tmp relevant?
<cachio> niemeyer, is it going to memory that data?
<cachio> I mean RAM memory?
<niemeyer> cachio: Yeah, tmpfs is supposed to keep the data in memory
<cachio> niemeyer, my point is that previous to do that, we are storing data in /tmp, this data will go to the RAM, so perhaps when we try to copy the all-snap-amd64.img we go out of memory
<niemeyer> cachio: That's not how mounting works
<cachio> niemeyer, ok, my bad in that case
<niemeyer> cachio: Once you mount something over a mountpoint, the data under the mounted filesystem just stays there
<cachio> niemeyer, ok
<niemeyer> What's the size of the data file?
<cachio> niemeyer, should be about 300 MB
<cachio> niemeyer, let me check
<cachio> trying to run the test on that machine but getting a problem
<cachio> Run configure hook of "core" snap (run hook "configure": cannot stat /var/lib/snapd/seccomp: No such file or directory)
<cachio> niemeyer, and the dir exists
#snappy 2017-08-05
<cachio> niemeyer, I am gonna build it by hand
<cachio> niemeyer, -rw-r--r-- 1 root root 676M Aug  5 00:57 /home/image/all-snap-amd64.img
<cachio> this is the size in that machine
<niemeyer> cachio: That's pretty large.. we have 2GB of RAM.. doesn't seem so surprising that it's failing
<cachio> niemeyer, well, in fact in this machine I see 1GB
<niemeyer> cachio: Wat?
<cachio>  https://paste.ubuntu.com/25243786/
<cachio> yes
<cachio> the vm1 is the one failed
<cachio> the 2 is another one
<niemeyer> That'd explain it.. let me double-check
<cachio> sure
<niemeyer> /o\
<niemeyer> cachio: That's the issue
<niemeyer> cachio: and that's why it was so hard to reproduce
<cachio> niemeyer, yes
<niemeyer> cachio: We had a 1/70 chance of breaking
<cachio> niemeyer, hehe
<niemeyer> cachio: Sorry for the trouble, my bad
<cachio> niemeyer, np
<cachio> niemeyer, happy to help
<niemeyer> cachio: Problem fixed.. Spread-50 is now 2GB as well
<cachio> niemeyer, is spread50 the only one? is it needed to check the others?
<niemeyer> cachio: I've just checked
<niemeyer> It was indeed the only one
<cachio> niemeyer, nice
<cachio> niemeyer, nice weekend in that case
<niemeyer> The original 50 had a hardware issue, and I replaced it.. that's when I got it wrong
<niemeyer> cachio: Thanks, you too
<Son_Goku> niemeyer, I did a thing: https://forum.snapcraft.io/t/in-progress-snapd-2-27/572/10?u=conan_kudo
<Son_Goku> hopefully zyga can remember what he did last time to fix this so that it won't be released broken for 2.27
<Son_Goku> I tried scrolling back through the commits, but alas... there's a lot :D
<niemeyer> Son_Goku: Thanks for reporting, let's get that fixed next week
<Son_Goku> awesome
#snappy 2017-08-06
<PhoenixMage> Are fileset variables per part?
<k_f_> Hi, i am trying to use snapd on debian, but i am not able to install core
<k_f_> it tells me: Setup snap "core" (2462) security profiles (cannot setup seccomp for snap "core": fork/exec /usr/lib/snapd/snap-seccomp: no such file or directory)
<k_f_> is some one able to help me?
<k_f_> seems to be fixable by installing ubuntu-core
<PhoenixMage> How do you guys test your snaps? Is there an ova I can use on vmware workstation or something? Or do you just run an Ubuntu desktop and use the snap command within that?
#snappy 2018-07-30
<mborzecki> morning
<mborzecki> mvo: hi, looks like we might have a bug in time schedule, with some specific days of the month, i'm looking into it
<mvo> mborzecki: ok, thank you
<mborzecki> according to go hmm 2017-08-01 00:00:00 +0200 CEST is Tuesday
<abeato> mvo, hey, I had to make this small change in MM and other interfaces: https://github.com/snapcore/snapd/pull/5572
<abeato> mvo, would appreciate if this can be incorporated to the nex release
<mvo> abeato: checking
<abeato> thx
<mvo> abeato: we will need jdstrand for this - at least for a second review. but yeah, happy to merge into one of the release PRs once it got that review
<abeato> mvo, sure, we indeed need him
<mvo> abeato: slightly unfortunate timing :/ we did 2.34.3 on Friday so there will be a bit of time before the next regular release. how urgent is this for you?
<abeato> mvo, well, urgent, but can wait a bit in principle. When is the next release planned?
<mvo> abeato: the next regular release would be 2.35 which is ~4-6 weeks away. we can do a point release if its critical which will take ~2 weeks (because the 2.34.3 needs to be released first which is ~1 week)
<abeato> mvo, ok, I see. I need to check these dates with the client, thanks for the info - will let you know
<mvo> abeato: if does do not match we need talk and think about options
<abeato> sure :)
<mvo> mborzecki: woah, the amazon linux packaging is pretty neat, looks like someone (looking at Neal most likely) did a great job on the fedora packaging to make it pretty universal
<mborzecki> mvo: yes, a couple of %if and it built just fine
<mvo> mborzecki: why do we need "storage: preserve-isze" for there?
<mvo> mborzecki: yeah, neat!
<mborzecki> mvo: the default image is 25gb, and iirc if we resize it to 10gb it does not boot anymore
<mvo> mborzecki: aha, right
<mvo> mborzecki: and there is a spread bug that prevents setting this more fine grained(?)
<mborzecki> mvo: cachio knows the details, he's proposed the intial pr to spread
<mvo> mborzecki: ok
<mvo> abeato: 5469 got two +1 but has some conflicts. do you think you have some cycles to look at those conflicts?
<mborzecki> hm weird, so in the tests 2017-08-01 00:00:00 +0200 CEST .Weekday() is Tuesday, when I run a similar sample in play it's wednesday https://play.golang.org/p/i1-tcO-OzBx same sample ran locally is wednesday too :(
<abeato> mvo, sure, let me take a look
<mvo> cjwatson: quick question about building snaps on LP. I tried to build the openstreetmap editor josm directly from their svn in LP but get an error: svn: E170013: Unable to connect to a repository at URL 'https://josm.openstreetmap.de/svn/trunk'
<mvo> cjwatson: is this just not possible or anything I can do to fix it?
<mvo> mborzecki: a second review for 5563 would be great, hopefully straightforward
<mborzecki> mvo: looking
<mvo> and 5450 needs a second review as well but its less important (just a small optimization)
<cjwatson> mvo: It's in principle possible but needs some work in launchpad-buildd - see https://bugs.launchpad.net/launchpad-buildd/+bug/1668358
<mvo> cjwatson: thank you
<mvo> cjwatson: would it be https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-git-proxy/+merge/323691 for svn? or is there more to it?
<mvo> cjwatson: hm, probably not because this is using plain http for the checkout(?)
<mborzecki> note to self, double check the year before swearing at go time parser
<mvo> mborzecki: haha
<mborzecki> i clearly need more coffee
<cjwatson> mvo: I think it would involve writing out ~/.subversion/servers with proxy info
<cjwatson> Probably not super-hard but needs testing ...
<mborzecki> mvo: #5573 fixes the timers
<mvo> mborzecki: thank you
<Chipaca> moin moin
 * Chipaca started a bit late
<mborzecki> mvo: i'll label it 2.34 in case we do another .34 release
<mborzecki> Chipaca: hi there, there's always a timezone in which it's early :)
<Chipaca> clearly i'm on UTC and just on time
<mvo> mborzecki: +1
<mvo> Chipaca: hey, good morning!
<Chipaca> mvo: how're you doing?
<mvo> Chipaca: I'm doing well, thank you! how are you?
<Chipaca> mvo: not bad! anything on fire?
<mvo> Chipaca: no new fire afaict, git deb package builds are unhappy to a varying degree, s390x in particular is unhappy since some time. but thats not yet too much of a problem (it will be once we need to do a new release)
<Chipaca> boo
<mvo> Chipaca: also some review would be great but otherwise things are calm right now. we need to aim for a beta of snapd that supports booting core18 this week
<mvo> Chipaca: so not entirely calm :)
<Chipaca> heh
<Chipaca> mvo: other than 5557 is there anything for core18 that needs a review?
<mvo> Chipaca: only 5549 which will be needed as part of the failover code for snapd but its not super urgent as on its own its not super useful
<mvo> Chipaca: 5570 is an easy win
<mvo> Chipaca: and 4.15 does not boot today again, *maybe* the entropy bug again in a different form, I'm just looking into this
<Chipaca> there's been a bunch of people on 18.04 that found all their snaps stopped working, btw
<Chipaca> not sure if that's already been sorted
<Chipaca> #1757284
<mborzecki> #5572 probably needs a look from jdstrand
<mvo> Chipaca: is this similar to the forum thread from last week?
<mvo> Chipaca: I think we got a report that after an update there was suddenly havoc
<Chipaca> mvo: ah, probably, i might've merged the two in my head
<Chipaca> yeah sounds like it
<mvo> https://forum.snapcraft.io/t/bug-broken-snaps-after-each-update/6536
<mborzecki> mvo: Chipaca: have you seen this https://forum.snapcraft.io/t/all-snap-app-crashed-on-ubuntu-18-04/6596/2 ?
<Chipaca> mborzecki: isn't that #1757284?
<Chipaca> mborzecki: and given mvo replied to that thread, my magic ball says he's seen it
<mborzecki> Chipaca: the forum topic feels like a mix of 2 different issues
<mvo> could well be two similar issues, I have not tried to reproduce myself, no time :/ but I think we need to look at this
<mborzecki> nice how firefox has connection refusded on display, chromium gets sigtrap, ohmyfiraffe just segfaults
<mvo> hm, is mup actually back?
<mvo> apparently not, pretty trivial PR https://github.com/snapcore/core18/pull/52
<mvo> (this is the reason why core18 was hanging in my local spread run, testing this right now)
<mvo> mborzecki, Chipaca did you figure anything out about the bugreport(s) above? sorry, was a bit distracted with looking into kernel hang (tricky to debug, easy once understood :/
<mborzecki> mvo: left a note in the forum, my bet is on apparmor for now
<mvo> ta
<mvo> 5560 needs a second review (trivial I hope)
<Chipaca> mvo: isn't it superseded?
<mvo> Chipaca: I just updated it
<Chipaca> ohhhh
<Chipaca> mvo: lgtm, then :-)
<mvo> Chipaca: ta
<Chipaca> mvo: want to know something hilarious: the _internal_ copy of runtime has a BigEndian boolean
<Chipaca> ah, no, internal/sys (so syscall)
<mvo> Chipaca: oh, *fun*
<mvo> Chipaca: I remember reading a long discussion why you shouldn't care about endianess in one of the bug bugs and I have given up on anything like official support for this
<Chipaca> mvo: yeah
<Chipaca> mvo: it's entirely possible they're right, and either our test is doing more work than it should, or udev is bonkers, or both
<Chipaca> mvo: Â¯\_(ã)_/Â¯
<Chipaca> it's also not outside of the realm of the possible that this particular bit is the exception
<mvo> yeah
<Chipaca> mvo: should I add IsBigEndian to osutil?
<mvo> Chipaca: hm, that sounds like a nice idea
<mvo> Chipaca: fwiw, for practical purposes the check for s390x is fine, we don't support mips and our ppc64 is little endian (I will double check that though)
<mvo> Chipaca: yep - endian-little
<Chipaca> mvo: yep, ppc64 vs ppc64el
 * mvo nods
<Chipaca> Let's write a cpu that _only_ works in bigendian bcd
<Chipaca> mvo: anyway, just lunchtime rambling, not blocking or anything
<mvo> Chipaca: ta
<mvo> Chipaca: yeah, probably a good idea to make it pretty
<mvo> (prettier than it currently is)
<Chipaca> mvo: also, did you inhale lunch, or are you IRCing while eating, and in either case, dude
<pedronis> mvo: mborzecki: Chipaca: anything I can still do for you today before calling it a week?  (after the standup IÂ have a bunch of meetings)
<mvo> Chipaca: was a bit optimist about it, its not quite ready, should be any minute hopefully :)
<Chipaca> mvo: ah :-)
<Chipaca> pedronis: I've got half a mind to drop the horizontal snapshot approach, close snapshotstate, and instead do verticals
<mborzecki> pedronis: i'm finishin up with with some changes to 5561, would be great it you could date a look before you leave, i understand it's a bit mind numbing though so no worries if you cannot make it :)
<Chipaca> pedronis: like, "this pr implements 'snap snapshots'", etc
<Chipaca> and maybe then slice _those_ into horizontals
<Chipaca> and maybe, maybe, i can get reviews
<pedronis> Chipaca: that doesn't sound something like I can help today, unless you propose it this second
<Chipaca> pedronis: no, it's a week's work imo
<Chipaca> OTOH I could also do the arch-indep work
<Chipaca> that's also a week + in my estimate
<Chipaca> dunno
<Chipaca> pedronis: to answer your question: I doubt I'll have anything for you to do for me today before the standup, thank you
<pedronis> ok
<mvo> pedronis: all good from my side
<pedronis> mborzecki: I'll see what I can do, we should chat a bit in the standup about what is not there and the state overall of parallel installs
<rbasak> error: open /var/lib/snapd/hostfs/home/ubuntu/snap/lxd/common/snapcraft7l7sklw8/core_4917.assert: no such file or directory
<rbasak> Known issue? Sounds familiar but my Googling is failing me.
<rbasak> subprocess.CalledProcessError: Command '['lxc', 'file', 'push', '/home/ubuntu/snap/lxd/common/snapcraft7l7sklw8/core_4917.assert', 'local:snapcraft-nondiffidently-overfastidious-luetta/run/core_4917.assert']' returned non-zero exit status 1
<rbasak> Ah, bug 1746612.
<rbasak> Except that I am using the lxd cnap.
<rbasak> snap
<rbasak> Oh no, I'm not. I thought I was.
<rbasak> Never mind :-/
<mborzecki> pedronis: regarding https://github.com/snapcore/snapd/pull/5561#discussion_r205805753 do you think it makes sense to verify this again in checkSnap() ?
<pedronis> mborzecki: sorry I don't understand which PR are you referring to?  it doesn't seem to check that the name matches
<pedronis> if you mean #5567
<mborzecki> pedronis: what i meant that it's probably more applicable to snap.Validate(), as it feels like a part of sanity check, and snapstate checks seem more like functional checks
<mborzecki> pedronis: pff nvm, was thinking about something else entirely :)
<pedronis> mborzecki: maybe, but  but something has to give,  Validate takes an info, either that info already has a full intance name split into it
<pedronis> but then it's late or something needs tweaking in that interface
<pedronis> mborzecki: I removed my -1,  don't think I can manage to review it again fully, we can discuss a bit about state in the standup as I said
<mborzecki> pedronis: ack, who do you tnink is equally well familiar with those internals that might take a look too?
<pedronis> mborzecki: mvo, also John,   what you are likely to be blocked on is alias stuff
<mborzecki> yeah, i remember pulling my hair on this not long ago
<pedronis> otoh you might be able to attack some of the interface bits
<mborzecki> pedronis: heh, i dug up the changes for that TODO in SetupSnap in some other branch i have, guess I'll refactor this to be in checkSnap instead
<mborzecki> no link in the calendar for the standup?
<mvo> mborzecki: strange
<mborzecki> it's not in my calendar either
<pedronis> mvo: I pinged Gustavo about this last week, it's probably related to hangout vs meet
<abeato> mvo, https://github.com/snapcore/snapd/pull/5469 passed now the spread tests
<mvo> abeato: cool, thank you
<mvo> abeato: I have a look after the meeting
<abeato> mvo, great, thanks
<Chipaca> jdrab: in tty[a-zA-Z]*[0-9]*, doesn't that still match 'tty' (and 'ttyprintk')
<Chipaca> ?
<Chipaca> er
<Chipaca> jdstrand: ^
<jdstrand> Chipaca: it is shell glob matching, not regex, so, 'no'
<jdstrand> Chipaca: eg: ls /dev/tty[a-zA-Z]*[0-9]*
<Chipaca> jdstrand: ah! i thought it was regexps because of the alternation
<jdstrand> it looks like a regex to be sure
<jdstrand> but it isn't
<Chipaca> :-) ok
<Chipaca> jdstrand: i'll dig out my udev dunce hat in a moment
<jdstrand> Chipaca: well, that is quite the subtlety for that hat!
<jdstrand> I just assume you keep it in the drawer
<Chipaca> jdstrand: under my pillow
<jdstrand> heheh
<cachio> mborzecki, that error on amazon PR is not a problem now
<cachio> I took a look and everything is ready to be landed
<cachio> I'll create the PR today on spread to setup the preserve at system level
<mborzecki> cachio: great
<mborzecki> cachio: could you do another review of #5552 too?
<cachio> mvo, we got the +1 to go to candidate
<cachio> mborzecki, sure
<mborzecki> cachio: thank you
<mvo> cachio: cool, lets do it
<cachio> mvo, 2.34.3 in candidate now
<mborzecki> mvo: could you upload a release tarball for snapd later on?
<mvo> mborzecki: sure, let me do this now
<mborzecki> mvo: thank you!
<mvo> mborzecki: should be there now
<mborzecki> mvo: it is, thanks a lot!
<xnox> mvo, snapd will break on cosmic with usrmerge =) or possibly not, not sure.... https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1784394
<xnox> there is a small patch there.... =)
<mvo> xnox: thanks, looking
<mvo> xnox: thanks, will do, it probably won't break as this should just be a symlink but its more correct this way
<xnox> yeah
<mvo> xnox: will do a PR shortly!
<mborzecki> arch package updated to 2.34.3
<mvo> ta
<mborzecki> 5573 is green, if anyone wants to do a 2nd review we could land it soon :)
<cachio> mborzecki, #5552 merged
<mborzecki> cachio: thanks!
 * pedronis eows
<ogra> EOWing on a monday ... nice :)
 * genii slides ogra a mug of their favourite beverage
 * ogra slurps
 * cachio lunch}
<mvo> Chipaca: this core18 snapd unit writing is a bit of a pita - but thanks a lot for your PR (and thanks to mborzecki  as well). I'm slowly moving forward here, the restarting is still a bit fiddly
<Chipaca> mvo: when you say my PR, you mean my review of your PR?
<mvo> Chipaca: yes! the heat make me take mental shortcuts
<Chipaca> mvo: HLQP! :-)
<Chipaca> mvo: why the // FIXME instead of changing the Start to a Restart?
<mvo> Chipaca: because it does not work yet
<mvo> Chipaca: I got errors with exitcode: -1
<mvo> Chipaca: which is strange
<Chipaca> mvo: boooo ð»ð
<mvo> Chipaca: looking into this now but wanted to get a spread run with improved tests
<mvo> Chipaca: yeah :) or rather: :(
<Chipaca> mvo: ok :-)
<mvo> Chipaca: the fact that we get -1 is a bug in itself
<Chipaca> mvo: yeah
<mvo> Chipaca: oh well
<ogra> just add a +2 at the top !
<mvo> Chipaca: you mention ReplaceAllString in pr#5557, content is byte, do you think this is still preferable? or am I misreading your comment?
<cachio> mvo, I have seen the lxd issue
<cachio> let me see the images because lxd should not be pre-installed
<mvo> cachio: thanks, I'm not sure what is going on, the PR is mostly a stab at the problem, I have not run it locally
<cachio> mvo, I'll fix the image
<mvo> cachio: ok, in this case feel free to close my PR once the image is fixed
<cachio> mvo, great, thanks
<cachio> mvo, updating the image for xenial 32 bits, if tests pass I'll close the PR
<mvo> Chipaca: the issue was RequiredBy vs WantedBy - oh well :) hopefully with that the restart is fine!
<cachio> mvo, lxd issue fixed
<cachio> I cloosed the PR and pasted the logs with the test results
<mvo> cachio: great, thank you
<cachio> mvo, np
<jdstrand> tyhicks: fyi, https://github.com/snapcore/snapd/pull/5578 and https://github.com/snapcore/snapd/pull/5579
<tyhicks> jdstrand: cool, thanks
<jdstrand> tyhicks: hopefully it'll make it into a new 2.34 (the latest stable), but it might not and be only in 2.35. up to mvo
<FreeBDSM> okay, I'm ready to build firefox 52.9.0esr into a snap, how do I do that?
<FreeBDSM> `man snapcraft` `No manual entry for snapcraft`
<FreeBDSM> `autoreconf -i`: `autoreconf: 'configure.ac' or 'configure.in' is required` `Failed to run 'autoreconf -i' for 'firefox': Exited with code 1.` `Verify that the part is using the correct parameters and try again.`
<FreeBDSM> jesus christ, snaps are awful
<FreeBDSM> I just took a look at what is inside skype snap
<FreeBDSM> piles of shite
<kyrofa> Hey cachio, you still around today?
<jdstrand> FreeBDSM: I think that would be an indication that particular snap isn't to your taste. not all snaps are created equal
<cachio> kyrofa, yes
<cachio> kyrofa, what do you need?
<FreeBDSM> jdstrand: true
<FreeBDSM> I think it'll be easier to do `snap install firefox` and just replace firefox files with the ones from ESR 52.9.0
<FreeBDSM> and just never update
<FreeBDSM> however, that's not much portable
<kyrofa> cachio, I'm trying to learn how snapd does spread testing in autopkgtests
<kyrofa> cachio, I see the `autopkgtest` group in spread.yaml
<kyrofa> Is that all there is to it?
<kyrofa> Basically, just point the test to happen on localhost?
<kyrofa> I don't understand why there are so many systems if that's all that happens, though
<cachio> kyrofa, the systems which you see are the targat systems for autopkgtests
<cachio> kyrofa, first you need to generate the machine with that systems
<cachio> then you run the tests against that one
#snappy 2018-07-31
<mborzecki> morning
<mborzecki> hmm arch's kernel package changed their LOCALVERSIONing scheme and our checks are failing
<CyberManifest> are there any plans to port snapd (snap support) to macOS ?
<mborzecki> CyberManifest: snapd is closely tied with linux atm as such i'm not aware of any plans to support other platforms, feel free to experiment though and ping us if you'd like to know more about the internals
<mborzecki> CyberManifest: however we have plans to port the utilities for building snaps to windows and macos and this work should commence sooonish, next month most probably
<mborzecki> mvo: hi, i've opened #5581 to fix the current problems on arch
<CyberManifest> mborzecki: couldn't https://mesonbuild.com be used to contain the linux portions i.e. sandbox the environment?
<CyberManifest> mborzecki: building doesn't help me run snap apps on macOS
<mborzecki> CyberManifest: meson is a build system, so it could replace the autotools magic we currently use to build one of the elements, the rest of the code is in Go but makes use of systemd, udev, makes certain assumptions about system components and paths and so on
<CyberManifest> so snap can't run on non systemd systems that use sysV init?
<mborzecki> CyberManifest: we make use of some kernel interfaces like mount namespace, seccomp, i'm not familiar with macos and don't know if there are similar intefaces on macos, though it'd be exciting if anyone wanted to explore this
<CyberManifest> mborzecki: and could homebrew not be used to port it?
<mborzecki> CyberManifest: afaik homeberew i just for building, you'd still need to provide the functional counterparts of the intefaces we use at the system level
<mborzecki> CyberManifest: but as i said, i'm not a mac user and have limited experience with osx
<CyberManifest> mborzecki: it's for distribution as well; it's mostly described as a package manager
<mvo> mborzecki: good morning! master is failing right now on arch with an "running unexpected kernel version 4.17.11-arch1 error. is that a known issue?
<mborzecki> mvo: yes, #5581 addresses that
<mvo> mborzecki: cool
<mborzecki> i should porbably label it as simple ;)
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/5581
<mvo> mborzecki: curious, why do we check the kernel version on arch?
<mborzecki> mvo: because there's just one kernel version installed at a time, we do an upgrade before the tests, reboot, and just to be extra sure verify that we're running the right kernel (iirc there were some issues at the early beginnign of arch integration with that too)
<mvo> mborzecki: aha, ok. makes sense, thank you
<mborzecki> mvo: apt-hooks tests is still a bit flaky
<mvo> mborzecki: yeah, I noticed yesterday I'm a bit puzzled about the why, the debug output shows the commands.db is populated :/
<mborzecki> mvo: yup, but iirc you've added a wait loop in the test right?
<mvo> mborzecki: yes
<mborzecki> ah right, but the file is there
<mborzecki> hm
<mborzecki> mvo: maybe we could dump the db in the test debug section?
<mborzecki> or it's stale from one of the previous tests
<mvo> mborzecki: dump|grep is a good idea
<mborzecki> mvo: snap debug commands would be useful
<mborzecki> mvo: strings /var/cache/snapd/commands.db is a bit hard to read
<mvo> mborzecki: yeah, I think we need a debug dump command or similar
<mborzecki> mvo: hm i think i can make it work with strings & some sed magic
<mborzecki> mvo: super low tech https://paste.fedoraproject.org/paste/KeXaitkPbRn59wnVakr5ng/raw
<CyberManifest> mborzecki: systemd is covered by http://mesonbuild.com/Users.html don't know the rest though.
<mvo> mborzecki: heh, nice! I think thats good enough for now
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/5582
<mvo> mborzecki: nice! and magic :)
<mborzecki> mvo: left a comment in https://github.com/snapcore/snapd/pull/5557
<mborzecki> mvo: otherwise it's looking good
<mborzecki> brb, need to do a quick run by the bike shop to get a new tube
<mborzecki> re
<Chipaca> mvo: mborzecki's commands.db pr died with an error you might know about or be interested in
<Chipaca> - Mount snap "test-snapd-control-consumer" (2) ([start snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount] failed with exit status 1: Job for snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount failed.
<Chipaca> in google:ubuntu-core-18-64:tests/main/install-remove-multi
<mborzecki> damn
<Chipaca> mborzecki: i've got the logs, if you want to just restart your run
<mborzecki> btw. i don't recall the mount thing failing on ubuntu
<mborzecki> it was always fedora & arch
<mvo> Chipaca: hrm, hrm, the protocol error again?
<Chipaca> mvo: http://r.chipaca.com/log.txt
<Chipaca> mvo: I don't see protocol error in there, but i don't recall the exact error message it would throw
<Chipaca> mvo: changing subjects, 16.04 having 2.34.2 and stable being 2.33 is weird :-)
<mvo> Chipaca: no kidding
<mvo> Chipaca: but yeah, will be fixed soon :)
<mvo> Chipaca: the one and only time that the deb is ahead because we had issues on core devices with the refresh (pi2)
<mvo> Chipaca: we will release 2.34.3 on Monday
<Chipaca> mvo: I'm mostly surprised the sru got there that fast
<mvo> Chipaca: yeah, we did all we could this time to get it ready in time for 18.04.1
<mvo> Chipaca: and all is fine on "normal" devices
<Chipaca> mvo: to be fair I only noticed because my /usr/bin/snap was broken (because I broke it) so it was suddenly crashing
<mvo> Chipaca: Jul 31 08:09:10 jul310756-078436 snapd[6023]: Jul 31 08:09:09 jul310756-078436 systemd[1]: snap-test\x2dsnapd\x2dcontrol\x2dconsumer-2.mount: Failed with result 'protocol'.
<Chipaca> mvo: ah
<mvo> Chipaca: so yeah, this is the error we are hunting since some time
<mvo> Chipaca: maybe a systemd bug but so far elusive
<abeato> mvo, hey, tests/main/apt-hooks is failing for https://github.com/snapcore/snapd/pull/5572 all the time, is that expected? it does not seem to be related to the PR
<Chipaca> abeato: not related
<Chipaca> abeato: also, often but not all the time. Sorry... we're looking into it
<abeato> nw, good to know
<Chipaca> abeato: i'll punch 'retry' for you
<abeato> Chipaca, thanks
<Chipaca> abeato: actually, if it's happening often for that pr, could you merge master?
<Chipaca> abeato: mborzecki added some debug to that test
<abeato> Chipaca, I rebased like one hour ago, so mborzecki could take a look at the log
<Chipaca> abeato: the debug pr landed seconds ago
<abeato> ok
<Chipaca> abeato: (i merged it between punching restart, and asking you to merge master)
<abeato> Chipaca, I've rebased my branc now
<Chipaca> k
<Chipaca> now of course it'll just work :-p
<abeato> I would prefer that :p
<mvo> <mvo> Chipaca: 5583 is a bit of an rfc, let me know about any obvious holes in the approach
<mvo> <mvo> mborzecki: ^- you are welcome as well of course
<mvo> got disconnected, not sure I the above made it to the channel
<Chipaca> mvo: it hadn't
<Chipaca> mvo: thanks
<mvo> Chipaca: thanks for the review! at least no obvious holes in the approach that is good. I'm sure this will have some more iterations once gustavo and samuele get a chnace to look at it :)
<Chipaca> mvo: a'yup
 * mvo hugs Chipaca 
<mborzecki> anyone feeling like looking at some c code? https://github.com/snapcore/snapd/pull/5584
<mborzecki> second review for the timers fix? https://github.com/snapcore/snapd/pull/5573
<mvo> mborzecki: careful, when I review C code I usually get grumpy ;)
<mborzecki> mvo: heh, i get so when writing c code
<mborzecki> mvo: i'm thinking about that socket activation code, i'm afraid that the idea behind it may be that snapd must not be started at all
<mvo> mborzecki: how do you mean? you mean in an ideal world it would not start at all?
<mborzecki> mvo: meaning, it probably goes down to the fact that once started there will be pages allocated on the host anyway, even if you stop it later the ripple effect is on
<mborzecki> mvo: at least that's the line of thinking i'd have should i be running a dense vm/container environment
<mvo> mborzecki: I don't disagree! however this was discussed a good while ago (not starting at all) and there was pushback from Gustavo for various reasons. so for now the consensus was to start and stop if we can
<mborzecki> mvo: well, i agree that you have proposed is a saner solution :P i recall the hack we had before 2.3x release and that was ugly
<mvo> mborzecki: I had a PR once that tried to do it all with systemd conditionals but I can't find it right now
<mvo> anyway, lunch first
<mborzecki> mvo: enjoy
<mvo> mborzecki: thank you! and thanks for the review(s)
<Chipaca> mvo: mborzecki: what we _could_ do is have snapd touch files that we can then use from conditionals
<mborzecki> Chipaca: then gate on ConditionPathExists or like?
<Chipaca> mborzecki: say we touch /var/lib/snapd/up-to-date once everything is fine
<Chipaca> mborzecki: and we remove that file if it's more than N days old
<Chipaca> mborzecki: the problem is the catalog will be stale unless we have a way of triggering snapd to run periodically
<mborzecki> Chipaca: hm we have timers now :)
<Chipaca> mborzecki: in systemd we've had timers for yonks
<Chipaca> there even was a snapd.timer
<Chipaca> or was it snapd-service.timer
<Chipaca> something like that
<mborzecki> repair?
<Chipaca> mborzecki: repair only runs in core
<Chipaca> in any case, we'll see
<Chipaca> maybe if the problem is VMs and clouds we add the dumb conditionals just to there
<mborzecki> meanwhile, i've added a temporary label for parallel installs PRs
<jdstrand> mvo: would you mind taking a look at https://github.com/snapcore/snapd/pull/5579
<jdstrand> mvo: hi btw :)
<mvo> jdstrand: in a meeting right now, will do so soon
<mvo> jdstrand: and *thnk you*
<Chipaca> mborzecki: https://api.travis-ci.org/v3/job/410245666/log.txt
<mborzecki> jdstrand: hi, i've requested your review on some of my prs, they should appear in your dashboard
<mborzecki> shellchecks part 5 https://github.com/snapcore/snapd/pull/5585 - 'the song of quoting and escaping'
<jdstrand> mborzecki: ack
<mvo> jdstrand: now I'm back, looking at your PR now
<mvo> jdstrand: thanks for the PR - I look forward killing ptrace trace :)
<jdstrand> mvo: yes, me too :)
<mvo> mborzecki: I cherry picked the arch fix for 2.34 - thanks for this one
<mborzecki> mvo: thanks for picking it up for 2.34!
<thresh> I wonder why I no longer have a _NET_WM_ICON xprop on a snapped firefox
<thresh> =/ snap refresh to a previous revision and back to stable fixed it
 * Chipaca takes a break
<mvo> mborzecki: I added some comments to your C code PR - just like I said, I got a bit grumpy, sorry for this. hope its still useful.
<mborzecki> mvo: sure, thanks for the review and the diff
<mvo> mborzecki: I should add, your stuff is fine (the indent is a bit off though) and I think the extra tests would be nice. but the other bits are fine
<mvo> mborzecki: this was just my take on this
<kyrofa> cachio, picking up where we left off yesterday (autopkgtests), I know I need to generate the system locally, but not when actually running in autopkgtests, right?
<mborzecki> mvo: yeah, the indent thing i did not notice even, showed fine in git diff & emacs
<cachio> kyrofa, right
<kyrofa> That was phrased badly. I mean when running the real deal, the system is generated for us, right?
<mvo> mborzecki: iirc we use indent (or was it clang-format?) on the code
<cachio> kyrofa, yes
<cachio> kyrofa, you generate it when you run it locally
<mborzecki> mvo: right, afaik it didn't cover snap-update-ns, probably need to run it manually
<mvo> mborzecki: aha, I think you are right. slightly sad
<kyrofa> cachio, can you explain why, since all the systems do the same thing, we have so many of them? Why not just call it "my-autopkgtest-system" and use it for everything? I feel like there's something I'm missing
<mvo> mborzecki: I just ran indent and the diff was huge so probably best to fix maually and call it a day ;)
<mborzecki> mvo: heh, run it now and it basically redid the whole file :(
<mvo> mborzecki: yep
<cachio> kyrofa, because then we use the system in the tests
<kyrofa> Ah, the SPREAD_SYSTEM var or whatever?
<cachio> if the system name is ubuntu-14 we do something
<cachio> if the system is arch-linux we do something different
<cachio> if it is ubuntu-18 the same
<kyrofa> That was the only situation I could think of, sounds like we're on the same page. Perfect, thanks cachio, I'm going to proceed to, uh, borrow, all of this
<cachio> kyrofa, also we filter tests by systems
<cachio> in a task you can define which system you want to run and which to skip
<cachio> kyrofa, something like https://github.com/snapcore/snapd/blob/master/tests/main/ubuntu-core-create-user/task.yaml#L2
<cachio> this test will be just executed on ubuntu-core-16
<mborzecki> mvo: looks like the whole bootstrap.c is using space indentation
<kyrofa> cachio, ah, right, I do that too in retrospect
<Chipaca> mvo: mborzecki: I _think_ https://github.com/snapcore/snapd/pull/5586 should fix the apt-hooks test breakage
<mborzecki> mvo: my guess about not using islower() and friends is that s-c code is almost the same, same function names, code copied and so on
<mborzecki> mvo: probably makes it easier to keep the code in sync
<mvo> mborzecki: *shrug* no strong opinion but generally I'm not a fan of cargo culting. but then I usually avoid the C review to avoid getting grumpy :)
<mvo> Chipaca: oh, nice. looking at your fix
<mvo> mborzecki: 5586 is probably an easy win, if you have a moment for this one
<cachio> mborzecki, I already pushed the PR to setup the storage at system level
<cachio> we will need to wait few weeks for it
<mvo> jdstrand: do you think you could review 5340 ? it got a +1 from zyga already but not from you yet
<mborzecki> cachio: thank you
<jdstrand> mvo: it is on my list, yes
<mvo> jdstrand: thank you, I was asked about the status I will relay that then
<mborzecki> Chipaca: left some comments in 5586, count that as +1 if i'm pushing too much :)
<Chipaca> mborzecki: as i answered there: i can't create a boltdb from a file
<Chipaca> so, no
<Chipaca> unless we want to actualy fork it
<Chipaca> (which AIUI we don't)
<mborzecki> Chipaca: very well then
<Chipaca> mborzecki: i looked into passing in a file (or a writecloser, or even just a writer), but the only thing that i could do is create the db and then use tx.WriteTo
<Chipaca> which seems like a lot of copying around
<mborzecki> meh
<Chipaca> soz
<Chipaca> brb, compiz hates me
<om26er> (sorry if this is coming as a repeat message, freenode had an issue and I believe my message were no going through)
<om26er> How can we create an Ubuntu Core image for the RPi with one additional snap installed.
<om26er> ogra: ^
<om26er> in this case, we are using RPi3 and want our privately built snap preinstalled on it.
<ogra> by creating a model assertion that has "required-snaps:" populated
<ogra> ah, if you dont want to cycle it through the store (or cant) use the --extra-snaps option to ubuntu-image
<om26er> we'll probably publish the snap to the store as well, so need to play with mode assertion probably.
<Chipaca> abeato: I merged master, with fixes for apt-hooks concurrency from #5586, into #5572 and it's now green. Any reason not to merge it?
<Chipaca> abeato: if there is, comment in the PR (you can use the 'blocked' label also)
<Chipaca> abeato: otherwise i'll merge it in the mron
<Chipaca> morn
<Chipaca> g'night
<FreeBDSM> how to cut some files from a .snap?
<FreeBDSM> can a snap be mounted as an rw mount?
<mcphail> FreeBDSM: as far as I know, a snap is just a squashfs file. I think you can unsquash it, adjust it then mount the unsquashed snap with "snap try"
<FreeBDSM> why does a firefox snap include usr/share with lots of non-related stuff, like pkgconfig, bash-completion, avahi, alsa, X11, themes, upstart etc?
<FreeBDSM> actually, nevermind, fat package is a fat package, I just need it to work
#snappy 2018-08-01
<erio> hey
<erio> is there a way to set a snap as not stable
<erio> from the dashboard ?
<erio> I was testing the build from github feature...
<erio> is there an unrealease command ?
<mborzecki> morning
<mborzecki> i must be going blind https://paste.ubuntu.com/p/yvvV6dwk6D/
<mborzecki> mvo: hi, hopefully a simple one https://github.com/snapcore/snapd/pull/5587
<mborzecki> mvo: also if you could take a look at this bugfix https://github.com/snapcore/snapd/pull/5573
<mvo> mborzecki: this looks good, thank you. do we already block that at the model assertion level as well?
<mvo> mborzecki: if not we probably should just to ensure people find out about htis early enough
<mvo> mborzecki: aha, the weekday fix - yes, will also look this morning
<mborzecki> mvo: i'll double check the model assertion
<mborzecki> mvo: right, it's not blocked at model assertion yet, i've only added some code around this in image
<mvo> mborzecki: hm, image is maybe/probably fine as well
<mvo> mborzecki: as long as this is rejected early enough I'm good
<mvo> mborzecki: probably makes sense not too have too much policy in the model assertion
<mborzecki> mvo: yeah, so image is there already ;)
<mvo> cool
<mborzecki> mvo: came in with this one https://github.com/snapcore/snapd/pull/5417
 * mvo nods
<mborzecki> a trivial cleanup https://github.com/snapcore/snapd/pull/5588
<Chipaca> mborzecki: any reason not to restart #5561 ("overlord/snapstate: parallel snap install")?
<mborzecki> Chipaca: nope, restarted it just now
<Chipaca> mborzecki: #5549 plz
<mborzecki> hm i think i have it open already
<mborzecki> nope, the wrappers thing
<Chipaca> <mvo> Chipaca: you mention ReplaceAllString in pr#5557, content is byte, do you think this is still preferable? or am I misreading your comment?
<Chipaca> mvo: ignore me, i just saw the `[]byte` in the second argument and didn't look at what `content` was
<Chipaca> mvo: I think the only core18 PR that I haven't reviewed is the one by zyga that's got a 'changes requested' from jdstrand
<Chipaca> mvo: is that one a blocker?
<Chipaca> mborzecki: i'm taking a break now, but i'll be going down the parallel instlal prs when i get back
<mborzecki> Chipaca: great :) aside from snapstate the rest is labeled as simple
<mborzecki> which they are
<Chipaca> mborzecki: I tried tagging snapshotstate as simple but it didn't help
<mborzecki> hehe
 * Chipaca goes on that break
<mborzecki> need to go to the car shop for a while, i'm taking my gear so i'll work from there if possible
<mborzecki> mvo: regarding https://github.com/snapcore/snapd/pull/5589#discussion_r206824163 it's a bit confusing, the code used to use snapName everywhere, then we started uding instanceName wherever changes were introduced (and was applicable), but this place can take either
<mborzecki> mvo: maybe simply using 'name' would be fine there
 * Chipaca goes to see about lunch
<mvo> mborzecki: yeah, maybe name is better
<mborzecki> mvo: renamed
<mborzecki> moving back home
<Chipaca> cachio: ok, so, bug
<Chipaca> cachio: we need to translate -n=all to --no-tail
<cachio> Chipaca, yes
<Chipaca> because 14.04 does not support -n=all, but 16.04 does support --no-tail
<Chipaca> i should shell into an 18.04 to check there
<Chipaca> cachio: are you on 18?
<cachio> Chipaca, no, but test is passing on 18.04
<cachio> Chipaca, I can start a sell
<cachio> shell
<cachio> hold on
<Chipaca> cachio: my question was does 18.04's journalctl support --no-tail
<cachio> Chipaca, not sure, let me check
<Chipaca> otherwise we can do conditionals but, ew
<cachio> Chipaca, 1 min, I am starting a machine
<cachio> Chipaca, bionic supports --no-tail
<Chipaca> ok
<ogra> mvo, zyga https://forum.snapcraft.io/t/rfc-single-universal-raspberry-pi-gadget-and-image/6634
<ogra> comments appreciated
<mvo> ogra: thanks
<mborzecki> ogra: nice
<mborzecki> ogra: i see what you did there `git clone --depth=1 https://github.com/raspberrypi/firmware.git` :)
<ogra> mborzecki, thats just what our default gadget does as well :)
<ogra> mborzecki, the magic is in config.txt and in the fact that i use the linaro toolchain for the u-boot versions that require a newer gcc
<mborzecki> ogra: wish they hadn't pushed the whole rootfs at one point, now it's there if you a full clone and bloats everyone's downloads
<ogra> yeah
<ogra> well, my git knowledge is only basic but i bet you can teach git to pull individual files from a tree
<ogra> o it would likely be possible to just download one subdir
<ogra> *so
<Chipaca> cachio: https://github.com/snapcore/snapd/pull/5591 (change journalctl -n=all to --no-tail)
<Chipaca> I'd give it the 'easy' tag but of course i changed things around a little as well
<cachio> Chipaca, nice, thanks
<ogra> ppisati, is https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1784025 actually for 4.4 ?
<ogra> oh, it says so in the description ...
<ogra> ... reading helps, sorry :P
<ogra> jdstrand, hmm, should hardware-observe not allow me to read /proc/device-tree/model ?
<ogra> $ cat /proc/device-tree/model
<ogra> Raspberry Pi 3 Model B Rev 1.2
<ogra> i think that would be a valuable addition
<ppisati> ogra: yep, bionic supports it natively
<mvo> Chipaca: did I mention yet how nice the small green tickmark looks
<Chipaca> mvo: next step: make it strobe through a rainbow on May 17
 * mvo tries to remember what significance May 17 has
<Chipaca> mvo: International Day Against Homophobia, Transphobia and Biphobia
<mvo> heh, nice!
<popey> Oooh! How can I see the green tick!? :)
<Chipaca> popey: are you back from holidays?
<popey> I am
<Chipaca> popey: snap refresh core --edge
<popey> any chance I can use beta? :) or is it really bleeding edge?
<Chipaca> popey: really not in anything but edge yet
<popey> ok, I'll wait a bit :)
<Chipaca> (i just tried beta to be sure)
<popey> Not ready for the firehose of core edge yet
<Chipaca> popey: you can go and come back (right now it's safe)
<mvo> popey: we should have it in beta early next week :)
<popey> Super.
<Chipaca> ok, eod for me
<Chipaca> ttfn etc
<jdstrand> ogra: something should (but currently doesn't) allow you to read that. it seems hardware-observe would be that thing, unless perhaps system-observe is a better fit. it feels more 'hardware-y' though
<FreeBDSM> how to remove a specific version of an installed snap?
<roadmr> FreeBDSM: did you try snap remove?
<roadmr> FreeBDSM: do it without options and it will tell you what the options are
<roadmr> one of them does what you want, it seems
<roadmr> FreeBDSM: by default snapd keeps the current and 2 previous versions of the snap in case it needs to roll back but these are simply cached in /var/lib/snapd/snaps/ and you can delete the .snap files if you want
<roadmr> (after doing snap remove, of course!)
<roadmr> good night FreeBDSM ! /me goes to sleep
#snappy 2018-08-02
<mborzecki> morning
<mborzecki> snap instance user directory mappings are a bummer
<mvo> mborzecki: is it hard to do?
<mvo> mborzecki: btw, does 5561 need a sameule/gustavo review or could this go in with two reviews?
<mborzecki> mvo: the setup is ugly, it already relies on SNAP_USER_DATA being set, now it's even worse
<mborzecki> mvo: it'd be great if someone did a 2/3rd review perhaps
<mvo> mborzecki: ok
<mvo> mborzecki: I hope to find time for reviews today/tomorrow
<mborzecki> mvo: thanks
<mborzecki> meanwhile i'll try to find a way to do user mappings in s-c that does not invovlve exploding the number of env vars passed from snap and does not call getpewnt
<mvo> mborzecki: sounds good
<mborzecki> mvo: the silly thing about this part is that since it's bind mounting stuff it needs to run with elevated privs, this makes relying too much on env vars is a bit scary
<Chipaca> moin moin
<Chipaca> mborzecki: if you could take a look at https://github.com/snapcore/snapd/pull/5591 it'd be great: it's a fix for a bug found in spread tests of https://github.com/snapcore/snapd/pull/5580
<mborzecki> Chipaca: looking
<Chipaca> mborzecki: thanks
<mborzecki> Chipaca: high order math, +2 < 2 +1 :)
<Chipaca> mborzecki: IKR
<Chipaca> the maths was there because the +6 was rather mysterious
<Chipaca> but, not that much, i dunno
<Chipaca> i add comments when requested :-)
<mvo> kyrofa: hey, 5569 probably needs a master merge. I tried to do that for you but it appears that you disabled the ability for maintainers to push to your branches(?)
<mvo> kyrofa: master merge to make tests great^Wgreen again
<mvo> some easy wins: 5548 and 5450 (both relatively short)
<mborzecki> opened https://github.com/snapcore/snapd/pull/5594 for snapenv, i suppose it might be a bit controversial
<Chipaca> mvo: in looking at #5450, I saw a bit of code that looked suspicious
<Chipaca> mvo: in Put, if the Chtimes fails with an IsNotExist, we re-link the file
<Chipaca> mvo: but we don't re-Chtimes the file
<mvo> Chipaca: aha, let me have a look
<Chipaca> mvo: a few more comments there
<Chipaca> mvo: overall looks good though
<mvo> Chipaca: yeah, nice one on the hardLinkCount, thats indeed a bit silly
<Chipaca> mvo: that's the one that stopped me from +1'ing it :-)
<Chipaca> the others are a non-rhetoric question, and a nit
<mvo> Chipaca: yeah, on it. thank you!
<Chipaca> mvo: the cache's Count isn't used outside of tests, right?
<mvo> Chipaca: correct, we can probably unexport it
<Chipaca> mvo: was the cache size a config?
<Chipaca> mvo: i was more worried about it being used in a loop somewhere, as it's not particularly efficient if the cache is arbitrarily sized
<Chipaca> if the cache size is not configurable, it's less of a worry
<mvo> Chipaca: it is not configurable right now (the cache count)
<mvo> Chipaca: aha, yes, building a list of the content for the size is silly if the size is large
<mvo> Chipaca: I can: a) add a FIXME b) rework
<Chipaca> mvo: (a) is fine -- and it'll only be an issue if the list is big
<Chipaca> mvo: OTOH
<Chipaca> mvo: why even count n>1 files in the cache size?
<mvo> Chipaca: heh, yeah, maybe it should simply be "cacheTooBig() bool" instead of count
<mvo> (well, proper name of course)
<Chipaca> maybe we want to invert that: first step, remove n>1 files from fis; _then_ see if it's too big, sort it, etc
<mvo> Chipaca: hm, not sure I get the idea but let me first address the other comments and then I read it again and ponder about it
<Chipaca> mvo: i mean https://pastebin.ubuntu.com/p/wnrzqp72Gb/
<Chipaca> er, except the last loop should be on filtered :-)
<Chipaca> of course, as hardLinkCount is just an accessor, it probably makes more sense to do that twice instead of copying all the file infos over
<Chipaca> lovely morning for bikeshedding, isn't it?
<mvo> Chipaca: aha, I see what you mean, let me poke at it a bit more
<mvo> Chipaca: it is lovely! and the cache gets better with every iteration :)
<Chipaca> mvo: https://pastebin.ubuntu.com/p/H9fwdVrb7d/
<mvo> Chipaca: yeah, feel free to pull and commit, this looks nice
<Chipaca> mvo: and the 'are we ready yet' condition further down would need a tweak also
<Chipaca> mvo: ah ok, will do
<mvo> Chipaca: I would keep the comment about the link count and that we get stuff for free if the link count is > 1
<mvo> Chipaca: but other than that I think this is nice and clean
<Chipaca> mvo: yeah, i was trying to explain the idea, not provide a diff :-D
<Chipaca> mvo: is "numOwned" the right name for that count?
<mvo> Chipaca: I can take your diff and run with it as well, I did not want to make you work, just had the impression it was "done"
<mvo> Chipaca: yeah, I think numOwned is good, trying to think of anything more descriptive
<mvo> Chipaca: I think this is a good name
<Chipaca> mvo: 550d714b179733cc8e96bd2c91a1890af3613d69
<Chipaca> oh wait, it's already there
<Chipaca> mvo: I pushed it to your repo :-D
<Chipaca> I thought I could only do that when it was a PR
<Chipaca> gah, github needs to refresh my gpg keys
<mvo> Chipaca: tests are unhappy now - not sure if that is a bug in the tests or in the code. off by one it seems
<Chipaca> mvo: a bug? in code I wrote?! inconceivable!
<Chipaca> mvo: ah, not a bug, just tests not updated for the smarter cache :-D
<mvo> Chipaca: oh? whats the issue with the test?
<mvo> Chipaca: aha, count needs an update as well? to return just unowned? or what is the best fix?
<Chipaca> mvo: looking
<mvo> ok
<mvo> mborzecki: when you have some spare cycles, 5540 is probably another easy win, just needs a second review
<mborzecki> mvo: ack
<Chipaca> mvo: this might actually be a bug somewhere
<Chipaca> mvo: in TestPutMany, I print the Nlink of every file, and the last one is always 2
<Chipaca> mvo: https://pastebin.ubuntu.com/p/rZFjtd39Sw/
<Chipaca> mvo: so it doesn't get cleaned up, so Count() > maxItems
<Chipaca> mvo: but the question is why is nlink>1
<Chipaca> is something holding the file open?
<mvo> Chipaca: hm, let me double check iirc its using iotutil.WriteFile() for the temp file creation
<Chipaca> actually holding it open doesn't increase nlink
<Chipaca> hmm
<mvo> Chipaca: is this maybe simply an ordering problem? the last file is put in and it exists as a test file. now put sees it has a link count of 2 (one the test file and the file in the cache) and skips it
<mvo> Chipaca: the remove of the test file is after the put
<mvo> Chipaca: so probably just a confusing test
<Chipaca> oh drat
<Chipaca> mvo: i'm counting before the remove
 * Chipaca is  dumb :-)
 * Chipaca moves it and tries again
<mvo> Chipaca: its complicated
<mvo> Chipaca: I mean life and computers and all that
<Chipaca> mvo: relationships also
<mvo> Chipaca: *cough* wise words!
<Chipaca> mvo: so, yes, it's that at Put time the count is 2
<mvo> Chipaca: so all good, we just need to update the test and add a comment I guess
<Chipaca> mvo: should I, or will you?
<mvo> Chipaca: either way is fine, let me do it, I pulled you deep enough into this rabbithole already
 * Chipaca puts down his "100 ways of cooking rabbit" book
<mvo> Chipaca: update pushed, I will merge once tests are green
<mvo> 5576 is also a trivial win
<Chipaca> mvo: 'has a link count of 2 because it still exists outside of the cache dir so its is not counted' sounds like you're talking about Count(), when the link count of 2 and it not being counted is at Put time
<mvo> Chipaca: hm, good point, let me try to correct this
<mvo> Chipaca: I force pushed an updated version
<Chipaca> mvo: s/has/had/, s/its/it's/, but only because I'm at nit central and it's nit breeding season
<Chipaca> ah
<Chipaca> mvo: s/its is/it's/
<Chipaca> :)
<mvo> Chipaca: heh, force pushed again
 * Chipaca is busy with a technical issue involving biscuits and coffee in a mug that is too narrow for dunking
<mvo> down to 36 PRs and counting!
<mborzecki> hm i'm missing a bit about apparmor, `aa-complain /snap/core/5183/usr/lib/snapd/snap-confine` should be enough to put it in complain mode for snap-confine right?
<Chipaca> mvo: 35
<cachio> mvo, https://paste.ubuntu.com/p/rWZNvyVXpc/
<cachio> I was taking a look to the PR which fix that
<cachio> mvo, #5440
<xnox> 2018-08-01 20:43:25 Failed tasks: 1
<xnox>     - autopkgtest:ubuntu-18.10-arm64:tests/main/auto-refresh
<xnox> i hope this is a fluke, retrying cosmic snapd autopkgtest
<ogra> xnox, yo ... how good is your journald fu ? (i'm looking for someone who has some insight into it)
<Chipaca> mvo: mborzecki: https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b4
<ogra> not sure you saw my questions in the backlog in #ubuntu-devel from last night
<xnox> ogra, nothing beyond what the manpage says..... but you can try
<ogra> xnox, well, so i always thought journald uses a ringbuffer in ram by default ... but found out that this isnt true ... it actually logs to a file in /run ... and by default has no upper limit set
<mborzecki> aare expert needed, @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ?
<mvo> mborzecki: thats surprising - jdstrand will know why @{HOME}/snap/*_*/ does not match /home/test/snap/test-snapd-tools_foo/ ?
<mborzecki> i get apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/snap/core/5183/usr/lib/snapd/snap-confine" name="/home/test/snap/test-snapd-tools/" pid=24324 comm="snap-confine" srcname="/home/test/snap/test-snapd-tools_foo/" flags="rw, rbind"
<mvo> cachio: is the fix for  refresh.timer=managed incomplete?
<Saviq> hmm refreshing a snap just now, snapd seems stuck at "Copy snap... data" (there's a whole of 512 bytes in $SNAP_DATA...)
<Saviq> that a known issue?
<cachio> mvo, well, it is not working
<cachio> we received an email yesterday about this issue
<cachio> mvo, sudo snap set system refresh.timer=managed
<cachio> it is not working neither
<mborzecki> Saviq: can you do snap change --last=refresh? maybe its waiting for some dependency
<mvo> cachio: thanks, checking
<cachio> mvo, thanks
<mvo> cachio: will send a pr shortly, quite annoying, the validation is in the way
<cachio> mvo, thanks
<cachio> mvo, I could make a new spread test for that, or update one
<mvo> cachio: I'm updating the existing one as part of the fix
<cachio> mvo, great :)
<mvo> cachio: but yeah, that was the problem, the previous change lacked a full end-to-end test
<mvo> cachio: I think I missed the mail from yesterday about this, who send it?
<Saviq> mborzecki: sorry, missed it, seems to have refreshed after all
<cachio> mvo, it was a reply for the announcement which I did saying the 2.34.3 was promoted to candidate
<cachio> mvo, Tony Espy sent it
<mborzecki> Saviq: can you post the output nonetheless? it's interesting if there was some dep after all
<Saviq> mborzecki: http://paste.ubuntu.com/p/c8cXZhTRv3/
<mborzecki> Saviq: when that happens (i mean a task is waiting for some dep), the prompt is seemingly stuck, probably bad ux on our side
<Saviq> so it took 16 mins
<mborzecki> Chipaca: do you remember of 'ready' column is when the task is done?
<Chipaca> mborzecki: yes
<Chipaca> spawntime is when the task was created, readytime is when it's finished
<mborzecki> so maybe it did take that long after all
<Saviq> http://paste.ubuntu.com/p/DRWwF5hptt/
<Chipaca> mborzecki: well, maybe
<Saviq> 280MB...
<Chipaca> we're probably missing a 'start time' to know exactly what happened
<Chipaca> OTOH if you run with SNAPD_DEBUG=1 you'd know more
<jdstrand> mborzecki: can you show me the full denial and the full rule that doesn't match?
<jdstrand> (for the '_')
<Chipaca> Saviq: were you running with SNAPD_DEBUG=1?
<mborzecki> jdstrand: https://github.com/bboozzoo/snapd/commit/07de54fe9b126923dbc15251a09fbda0a8f84204 and https://paste.ubuntu.com/p/y4kNfM734Y/
<mborzecki> jdstrand: the other 2 rules for /snap/*_* and /var/snap/*_* seem to match, i was getting denials before and now they are gone
<Saviq> Chipaca: I'm afraid no
<mborzecki> heh weird failure with MATCH https://paste.ubuntu.com/p/M3rXxHD35Y/, obviously works if running in the debug shell
<jdstrand> mborzecki: you are hitting https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1612393
<mborzecki> jdstrand: so just /home/*/snap.. ?
<thresh> neat, gcloud packaged in snap
 * thresh apt removes it
<mvo> cachio: 5595 fixes the refresh.timer issue for real this time
<jdstrand> mborzecki: by default, /home/*/snap/*_*/ and /root/snap/*_*/. but see /etc/apparmor.d/tunables/home (and home.d/*) if the user updated the tunables for some other location
<jdstrand> mborzecki: that said, snap-confine itself falls over if people use an alternate location for home (ie, they tried to adjust home.d/something so probably should mention LP 1612393 and also that snap-confine doesn't support other locations for home.d in a code comment
<cachio> mvo, great, thanks, I'll take a look now
<jdstrand> mborzecki: and move on
<mborzecki> jdstrand: had to use 'mount options=(rw rbind) /home/*/snap/*_*/ -> /home/*/snap/*/,'
<mborzecki> jdstrand: and it sort of works, thanks for the help! :)
<jdstrand> oh right, you aren't mounting on /home/*/snap/*/
<jdstrand> err
<jdstrand> you aren't mounting on /home/*/snap/*_*/
<jdstrand> you are mount from foo_parallel to foo
<jdstrand> so that makes sense
<ogra> jdstrand, regarding the device-tree/model access i think it should live in the same interface that allows /proc/cpuinfo (whichever that is)
<ogra> IMHO they are equivalent
<jdstrand> ogra: that is allowed by default in the base abstraction because it is used by glibc's sysconf
<ogra> bah ... damned :)
<ogra> i thought i found a clever criteria ;)
<mborzecki> parallel installs integration branch https://github.com/snapcore/snapd/pull/5596
<ogra> *criterium
<Chipaca> mvo: I'm looking at 5592
<ogra> *criterion ??
<ogra> hmm
<jdstrand> ogra: I mean, we can add it anywhere we want. there are basically two questions: what fails if it isn't allowed? how sensitive is the information?
<Chipaca> mvo: without this, would the broken snapd snap install succeed?
<Chipaca> ogra: critteropolis
<ogra> jdstrand, nothing fails, thats really optional but allows you to i.e. distinguish on which specific Pi model you run
<jdstrand> ogra: it seems like very few things fail otherwise we would have heard about it much sooner
<jdstrand> ok
<ogra> yeah, nothing fails ... but it would be good to be able to get to that info
<jdstrand> sure
<jdstrand> it'll be added
<ogra> thx
<jdstrand> $ cat /proc/device-tree/model
<jdstrand> TI AM335x BeagleBone Black
<ogra> (i'm working towards a unified Pi image that runs on all Pi's and there it would be come ore important)
<jdstrand> ok, that isn't very sensitive
 * jdstrand nods
<jdstrand> I saw the thread. sounds neat
<ogra> its the same as "Hardware:" in /proc/cpuinfo in most cases i think
<jdstrand> Hardware: Generic AM33XX (Flattened Device Tree)
<ogra> ah, k ... so it is actually more secific
<ogra> *specific
<jdstrand> *barerly*
<ogra> Hardware	: BCM2709
<jdstrand> barely*
<ogra> on a pi3
<jdstrand> huh, on pi 2 it is quite different
<jdstrand> barely*$ grep Hardware /proc/cpuinfo
<jdstrand> Hardware	: BCM2709
<jdstrand> meh
<jdstrand> $ grep Hardware /proc/cpuinfo
<jdstrand> Hardware	: BCM2709
<jdstrand> $ cat /proc/device-tree/model
<jdstrand> Raspberry Pi 2 Model B Rev 1.1
<ogra> well, they use the same CPU core ... but differet SoC peripherials
<jdstrand> but obviously someone can create a map having only BCM2709
<ogra> so here the devicetree model is actually helpful
<jdstrand> ogra: this doesn't sound sensitive at all with the things that we already allow by default
<ogra> ah, you mean we could allow it without interface
<ogra> fine with me as well
<jdstrand> that is what I'm thinking
<ogra> yeah
<mvo> Chipaca: yes
<ogra> if cpuinfo is accessible the model should be too
<jdstrand> ogra: is it generally useful? like, will a library ever look at that to try to optimize something?
<mvo> Chipaca: so without 5592 a broken (or empty) snapd snap would lead to snapd stopping but no new snapd in place
<ogra> dunno, i guess they'd rather use cpabilities from /sys or some such ...
<jdstrand> ogra: well, I'll do some more investigating
<ogra> at least on a deb/distro evel you typically dont have per cpu optimization but have the binaries rather look up single capabilities
<ogra> t is definitely useful info for i.e. wrapper scripts in snaps
<jdstrand> yep
<jdstrand> ogra: oh, it is actually already allowed by hardware-observe
<jdstrand> @{PROC}/device-tree/{,**} r,
<ogra> oh, wow ... it allows all of it even
<ogra> perfect
<jdstrand> (it was added to support 'lshw -quiet')
<Chipaca> mvo: conflcits in 5592 fwiw
<mvo> Chipaca: yeah, on it
<mvo> Chipaca: just testing locally a bit
<Chipaca> ouf, 2pm and i haven't had lunch
<mborzecki>  https://paste.ubuntu.com/p/M3rXxHD35Y/
<jdstrand> mvo: hey, is the forum ok? I got only 2 emails from it last night. nothing after 01:29 UTC until 09:25 UTC. then got one at 09:58 UTC and then nothing since
<jdstrand> mvo: I'm still looking to see if it is local
<ogra> there wasnt much ... probably because most people in europe are simly melting and not sitting on computers :)
<jdstrand> ogra: ok, that confirms it at least isn't local (I couldn't find it to be either)
<jdstrand> 2 emails over night. that is unprecedented :)
<ogra> i dont have cnstant emailing set up (only for direct notifications/mentions) but in general there wasnt much traffic tonight
<jdstrand> I have constant
<mborzecki> mvo: Chipaca: replaced MATCH with grep -qE in the first line the test failed and it failed on the next line
<Chipaca> mborzecki: remind me what was the pr?
<Chipaca> mborzecki:  Ran for 1 hr 1 min 13 sec !
 * Chipaca runs the test by hand
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/5594
<mborzecki> Chipaca: tests/main/snap-env
<mvo> mborzecki: hm, maybe a subtle bug in the new MATCH since it got fixed?
<mvo> mborzecki: are you in a debug shell? if so, what do you get with declare -f MATCH?
<mvo> mborzecki: the fact that there is no echo at all is a bit strange
<Chipaca> mvo: running MATCH by hand works
<Chipaca> that is, it passes
<mborzecki> mvo: Chipaca: added set -x in MATCH https://paste.ubuntu.com/p/fRbXRQFVKk/ and it's not failing now
<mborzecki> hmm
<mborzecki> i'll try an earlier commit in spread
<mvo> mborzecki: yeah, try the one before "echo | grep" was replaced with <<<
<mborzecki> mvo: mhm, doing this right now
<mborzecki> mvo: older revision is also failing
<mvo> mborzecki: "good" I guess
<mvo> mborzecki: also WTH?
<mvo> mborzecki: what exit code do you get when it fails?
<mvo> mborzecki: I mean right after match failure what is $? ?
<Chipaca> mborzecki: you say ou added 'set -x' and it started passing?
<Chipaca> mborzecki: because I  overwrote MATCH in task.yaml itself, and it failed because of the wc -l test
<Chipaca> because snap-vars.txt has 18 lines, now, not 12
<mborzecki> Chipaca: yes, in MATCH()  https://paste.ubuntu.com/p/fRbXRQFVKk/
<mborzecki> Chipaca: yup, so it went throught the MATCH lines that were failing previously
<Chipaca> ah, yes
<mborzecki> Chipaca: what do you mean you rewrote it? copy & paste to task.yaml directly?
<Chipaca> yah
<Chipaca> but, i can reproduce the failure
<mvo> local stdin=\"$(cat) <- this failing might make the script fail without any message
<Chipaca> by which I mean: python3 -c $'import yaml;y=yaml.load(open("task.yaml"));\nfor i in ("execute","prepare","restore"):\n if i in y: open(i+".sh", "w").write(y[i])'
<Chipaca> and the ( set -eux; source execute.sh )
<Chipaca> and i see it fail in the same way
<mvo> Chipaca: you see it always failing the same way?
<Chipaca> yes
<mvo> Chipaca: you say "-x" there, does that yield anything useful?
<Chipaca> mvo: if I overwrite MATCH with one that doesn't +x, the tests pass
<Chipaca> mvo: if I add a add -v, the tests pass
<mvo> Chipaca: can you add strace?
<mvo> Chipaca: i.e. strace the entire beast with -f -s1024
<mvo> Chipaca: and then we can look for execve and wait and sigchild
<Chipaca> hmmmmmmmmm
<mborzecki> mvo: your favourite topic https://lwn.net/Articles/760584/
<mvo> Chipaca: and hopefully get a clue
<mvo> mborzecki: *garrr*
<Chipaca> mvo: if I add "echo HELLO" at the top of MATCH, I see 11 HELLOs, even when it fails
 * cachio afk
<mvo> Chipaca: *cough* wuut? 11?
<Chipaca> mvo: so the MATCHes are passing
<Chipaca> mvo: we're just not seeing the output
<Chipaca> 11 is where the first known-to-fail test is
<mvo> Chipaca: hm, ok. if you remove the fist 11 that work, I assume nothing changes and the 12th still fails? can that one be straced :) ?
 * mvo would love to see the strace
<Chipaca> mvo: the first one that fails is not a MATCH but the test
<Chipaca> test $(wc -l < snap-vars.txt) -eq 12
<Chipaca> ^ that one
<mvo> Chipaca: oh, sorry, I misunderstood this then. so match is fine for some reason we just don't see that it is "test $(wc -l)" that is failing?
<mvo> Chipaca: if you add an "echo" before the test, is that visible in the failure output?
<mborzecki> heh
<Chipaca> mvo: before the "test $(wc -l < snap-vars.txt) -eq 12" line?
<mvo> Chipaca: yeah, just curious if the echo (and possible output) is also eaten up
<Chipaca> mvo: echo HELLO, and echo HELLO STDERR >&2, both work
<Chipaca> right before the test line
<mvo> Chipaca: interessting
<Chipaca> mvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( â¦  )  instead of  MATCH() { â¦ }
<kyrofa> mvo, interesting, no, that box is checked
<mvo> kyrofa: aha, then I was maybe just confused (its very hot here). anyway, I can merge master for you or you can do it, that should fix the spread tests (they were a bit unhappy in the past days)
<mvo> Chipaca: confusing
<kyrofa> mvo, happy to do it, the button isn't showing up for me either so I'll do it manually
<kyrofa> Github might be a little sad right now
<kyrofa> mvo, done
<mvo> kyrofa: ta
<mvo> Chipaca: do you have a reproducer that you could pastebin for lazy people like me to just run? or is it complicated?
<Chipaca> mvo: working on it
<mvo> Chipaca: ta!
<mborzecki> https://pastebin.com/EBFtyBnr 'not seen' is actually seen, but after the first match the second one does not appear
<Chipaca> mvo: got a reproducer
<Chipaca> mvo: now working on minimising it a bit
<mborzecki> Chipaca: https://pastebin.com/raw/4nzDYLRf
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/D3nbpBtvMw/
<Chipaca> mvo: ^
<mvo> Chipaca: nice
<mvo> mborzecki: nice as well :)
<mvo> Chipaca: ok, so without "<<<" (replaced that with pipes) things seems to work
<Chipaca> mvo: https://pastebin.ubuntu.com/p/7kyVQ373hy/
<Chipaca> mvo: changing 'gep <<< "$(cat)"' to 'cat | grep' fails in the same way
<mvo> Chipaca: removing " {
<mvo>         set +ux
<mvo>     } 2> /dev/null" fixes it for me
<Chipaca> mvo: as does dropping the x from that,  or doing a set -v
<mvo> Chipaca: egon@bod:~/devel/go/src/github.com/snapcore/snapd.mvo$ pastebinit /tmp/lala4.sh http://paste.ubuntu.com/p/GDJZCGz2CY/
<Chipaca> mvo: wa
<Chipaca> haha lel
<Chipaca> is this a new feature in bash
<mborzecki> magic
<Chipaca> mborzecki: you mean maciej
<mborzecki> shall we fix it in spread then?
<Chipaca> mborzecki: fix it how?
<Chipaca> that bit of code is to avoid having debug output from MATCH itself
<Chipaca> easiest fix is probably to do the subshell thing
<Chipaca> behaviour-preserving fix i mean
<mvo> hm, hm, let me check something
<mborzecki> meanwhile pushed to fix to change 12 to 18, higher order algebra
<mborzecki> btw. funny quote from the entropy pool article
<mborzecki> > Laura Abbott was set to test the patch on a Fedora Rawhide kernel, but found that the hang at boot time waiting for random numbers ..
<mvo> Chipaca: yeah, I was wondering if we need shopt or something but subshell seems least intrusive
<mvo> mborzecki: yeah, I was reading this too, sad sad
<Chipaca> mborzecki: wrt your PR, fix the wc -l test and it should pass
<mborzecki> Chipaca: yup
<Chipaca> the MATCH bug should not affect successful test results
<mborzecki> https://i.imgur.com/CB7qWD6.jpg 45C
<mvo> Chipaca: interesstingly http://paste.ubuntu.com/p/h72s4vVyB4/ works, so the pipe seems to trigger some cleanup in the stderr redirect
<Chipaca> mvo: I'm pretty sure this counts as a bug in bash, fwiw
<Chipaca> OTOH given how it behaves the same in 14.04 through 18.04, they might say it's working as intended (somehow)
<Chipaca> OTOÂ²H it wouldn't be the first antediluvian bug we've found
<mvo> Chipaca: fun, looks like their bugtracker is a mailinglist
<mvo> Chipaca: hm, let me quickly run an idea by you: this is our bug: we do "set +ux" in MATCH which is a function so no subshell. we run MATCH foo <<< foo which will also not create a subshell. at this point we did set +x which means we truned of tracing globally. when doing "echo foo|MATCH something" this will run match inside a subshell which means the traceing that is turned off does not affect our main shell. makes sense?
<mvo> mborzecki: your input on the above is of course appreciated as well
<mvo> mborzecki: 45Â°C?!? uhhh
<Chipaca> mvo: makes sense
<mvo> Chipaca: which means the fix is more () (you can never have enough): http://paste.ubuntu.com/p/jZJ5ySrCpV/
<Chipaca> mvo: I meant: MATCH() ( â¦ )
<Chipaca> mvo: instead of MATCH() { â¦ }
<mvo> Chipaca: aha, yes!
<mvo> Chipaca: are you on it already? or shall i do a spread fix?
<Chipaca> mvo: go for it
<mvo> Chipaca: thanks
<mvo> Chipaca: I guess this is what you had in mind all along when you said "lets just use a subshell" earlier?
<Chipaca> <Chipaca> mvo: things that also work: making the funciton run in a subshell (i.e. MATCH() ( â¦  )  instead of  MATCH() { â¦ }
<Chipaca> mvo: ^there? :-)
<mvo> Chipaca: yes
<Chipaca> mvo: yes
<mvo> Chipaca: *cough* I should read more carefully :) thank you, nice that we have yet another bug squashed
<cachio> mvo, https://paste.ubuntu.com/p/Xn2vN9N7hz/
<cachio> here: https://travis-ci.org/snapcore/snapd/builds/411259659?utm_source=github_status&utm_medium=notification
<mvo> cachio: this looks like an empty reply, no?
 * mvo needs to be afk for some minutes
<cachio> don't know
<cachio> because mborzecki saw the same in another test
<cachio> mborzecki, empty reply or we are not managing well in MATCH function
<cachio> I am trying to reproduce it locally
<cachio> mvo, I'll keep you updated
<mvo> cachio: you may want to try my latest spread PR
<cachio> mvo, sure
<cachio> mvo, I was wondering if it is already possible to create a core-18 image on edge?
<cachio> using ubuntu-image
<kyrofa> noise][, I'm getting a 504 trying to get snap metrics, status seems all green
<noise][> kyrofa: what URL?
<kyrofa> noise][, https://snapcraft.io/account/snaps/nextcloud/metrics
<noise][> looks like it's timing out, working on other snaps. Can you please file a bug?
<kyrofa> noise][, done: https://bugs.launchpad.net/snapstore/+bug/1785094
<noise][> thx, we'll dig in.
<cachio> mvo, I could reproduce the issue using your spread PR
<FreeBDSM> snap is too complex
<FreeBDSM> I use mozilla's script that built firefox esr 60+
<FreeBDSM> I've used it to build 52.9.0-esr
<FreeBDSM> it built fine, it runs and works, but instead of pages I see nothing
<kyrofa> mvo, yikes: https://api.travis-ci.org/v3/job/411316584/log.txt
<kyrofa> mvo, that's https://github.com/snapcore/snapd/pull/5569 after merging with master :P
<ads20000> popey Wimpress is it possible to use custom Wine patches within your tmnationsforever Wine schema? :)
<ads20000> (well, I guess it is possible, just wondering if there's an easy way of doing that... presumably I bundle the .patch files in the repo and then put in patch -pi < foo.patch somewhere in the .yaml but I don't know where...)
<mvo> cachio: sorry for the delay. hm, sad to hear that spread MATCH still has the same issue
<mvo> cachio: re core18 image, let me mail you some details
<cachio> mvo, np
<cachio> mvo, nice, thanks
<mvo> cachio: see /msg
<roadmr> mvo: you're still up! can I trouble you a bit?
<mvo> roadmr: sure
<roadmr> mvo: two things! 1) I checked that seeds repository seb pointed me to, but can't find where snap:core is included. Is that implicit somewhere if the image has any snap:whatevers?
<roadmr> and 2) how is the revision of the snap that gets baked in the image determined? is it mentioned anywhere, or a simple snapshot of what was currently on stable when the image was built?
<mvo> roadmr: I haven't looked at the seed but I'm pretty sure its implicit
<roadmr> ok... yes, that sounds plausible for core
<mvo> roadmr: (2) not 100% sure but about 80% that its whatever is in stable at the image building time
<roadmr> mvo: the reason we want this is: we want to know which revisions of snaps are included in images (isos and maybe cloud images) so we can ensure deltas to go from that version to the latest stable are always available
<mvo> roadmr: everything else would also be difficult because the builder cannot access snaps by revision
<roadmr> mvo: right - oh that's a very good point.
<mvo> roadmr: aha, I see
<roadmr> then I guess it's what's on stable... which leads to - do you know if there's a build log or something which tells us which version ended up in the image?
<mvo> roadmr: the images usually have a manifest, let me see if I can find the LP builders
<roadmr> ah exactly :) thanks!!
<mvo> roadmr: I need to find it :) but yeah, there is one
<roadmr> mvo: for example - the download to upgrade an 18.04 image's core was 91 MB; yesterday we built the deltas and download size went down to 27 mb
<roadmr> anyone booting 18.04 and waiting until the snaps refresh will benefit from this, starting yesterday
<roadmr> mvo: no rush/problem, if you happen to remember where they are that'd be useful
<roadmr> mvo: as is, we have to look at our metrics and react when we see lots of misses for a snap. Not intractable but we'd like something more preemptive/authoritative.
<mvo> roadmr: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu has the builds and the build logs
<roadmr> mvo: marvelous :) thanks!
<mvo> roadmr: my pleasure
<mvo> has anyone seen "- Fetch and check assertions for snap "core" (5183) (cannot get device session from store: store server returned status 400 and body "{\"error_list\":[{\"code\":null,\"message\":\"Nonce is missing or invalid.\"}],\"errors\":[\"Nonce is missing or invalid.\"],\"result\":\"error\"}\n")"
<roadmr> mvo: hmm is that reproducible? when a device gets a session from the store, it does a handshake that includes a nonce and it has to send that back as part of the dance
<roadmr> mvo: it usually just works, but if this is happening consistently it might need a look
<mvo> roadmr: thanks! its the first time I saw it, probably a one-off issue then, I retriggered the test now
 * mvo crosses finggers
<roadmr> mvo: hope it works, but let me know if not.
<roadmr> (might have been a memcached hiccup; but that hasn't been an issue in ages)
<robert_ancell> Has anyone talked to Gitlab about making snaps? It would be pretty awesome to 'snap install gitlab-runner'
#snappy 2018-08-03
<mborzecki> morning
<Chipaca> mborzecki: morning
<mborzecki> Chipaca: hey, i see there's a PR to spread https://github.com/snapcore/spread/pull/67
<Chipaca> mborzecki: yup
 * Chipaca changing locations
<mvo> mborzecki: do you think you could have a look at 5592?
<mborzecki> mvo: hi, i'm going through it now
<mvo> mborzecki: yay, thank you! once that is in I hop eI can build a first beta(ish) image
<mborzecki> not sure we can do anything about remaining reviews at this point
<mvo> mborzecki: yeah, it looks like the other reviews are all blocked in one way or the other
<mvo> mborzecki: did you write more? I got disconnected so may have missed bits
<mborzecki> mvo: nope
<Chipaca> hello again
<mvo> hey Chipaca
<mborzecki> Chipaca: welcome back
<mborzecki> hmm noticed that experimental.parallel-instances has no effect when doing install from file :(
<mborzecki> need moar coffee
<mvo> ogra: does the pi3 gadget needs updates for the 4.15 kernel? when I boot it using a serial port I see: Starting kernel ...
<mvo> ï¿½
<mvo> ogra: and then lots of these: ï¿½fï¿½ï¿½~ï¿½ï¿½ï¿½ screenfulls. but the uboot messages are all normal
<mvo> ppisati: -^
<ogra> mvo, yes
<mvo> ogra, ppisati pi2 with 4.15 show kernel boot message but shows https://paste.ubuntu.com/p/Zq9wqg3qfF/ and hangs
<mvo> ogra: so we need a new/updated gadget in any case? what does need to change?
<ogra> oh, wait, not sure about just 4.15 (4.15 on pi3 B+ needs new gadget stuff)
<ogra> mvo, but it is likely we need new blobs all over since they are always built for a certain kernel vetrsion
<ogra> (they are backwards compatible so it should be fine to update and keep 4.4 working)
<mvo> ogra: ok
<mvo> ogra: I guess raspberrypi/firmware git repo is the place?
<ogra> mvo, try my universal gadget, it pulls new FW during build
<mvo> ogra: ok
<ogra> (was needed for cm3)
<ogra> https://github.com/ogra1/pi-kiosk-gadget
<ogra> oh, wait, it doesnt
<ogra> damn
<ogra> mvo, you actually want master from https://github.com/raspberrypi/firmware, all stable versions point to 4.9
<mvo> ogra: yeah, looks like we are pulling from the 201705xx tag
<ogra> master has at least support for 4.14
<mvo> ogra: let me try to rev that
<mvo> ogra: is the uboot v2017.05 version still good? or should this get an update as well?
<ppisati> mvo: for the serial, what is the content of config.txt? do you have the 'enable_uart=1' line?
<ogra> mvo, thats fine for 4.4 ... but i'm a bit confused .,... i merged ondra's https://github.com/snapcore/pi3-gadget/pull/15 and that sjhould have bumped use to 1.20170515 a while ago
<mvo> ppisati: yeah, enable_uart=1 is set. but the firmware bits are pretty old, I'm trying to update those now first
<ppisati> mvo: ack
<ppisati> mvo: and you are using the dtb that comes with the kernel, right?
<ogra> mvo, looks like our auto-builds are not working, i clearly see 1.20180417 in the git tree here https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml
<mvo> ppisati: probably not, iirc the default is that those are put into the gadget still
<ogra> ppisati, hah, the gadget indeed pulls the dtb out of the xenial-security deb
<mvo> ogra: ok, I was looking at pi2 at this point
<ogra> mvo, ah
<ppisati> bionic kernel + xenial dtb = no good
<ogra> mvo, really time to switch to the unified approach :P
<ogra> mvo, i guess you need to manually copy the dtb around on the SD for testing
<mvo> ogra, ppisati hm, if the dtbs must be part of the gadget we need a new gadget snap or a new track for the exiting pi2 gadget to work 4.15 kernel, right?
<ogra> mvo, right
<ogra> mvo, unless your and ondra's planning is far enough to have them updateable (i understand you guys discussed that)
<mvo> ogra: it sounds like hte universal one is the most effective way forward for now, let me try that
<ogra> mvo, it uses the new "build on" "run on" stuff for snapcraft, so if you build it, dont use --target-arch in the snapcraft call ... also, to see boot stuff on HDMI, drop "splash vt.handoff=2 and nogetty" from cmdline.txt
<mvo> ogra: I forked it and started building it
<mvo> ogra: will probably take a while, I keep you updated
<ogra> 10min or so ...
<mvo> ogra: psplash fails to build for me, its master it seems to maybe just a hickup, I disable it for now
<ogra> mvo, ok
<ogra> weird though ...
 * ogra tries a build 
<ogra> even master never changes :P
<mvo> yeah, I noticed that just now, 11month ago
<ogra> mvo, are you building on bionic (i always build on xenial, perhaps thats the difference)
<mvo> ogra: yeah, bionic
<ogra> might be some build dep
<mvo> ogra: http://paste.ubuntu.com/p/dJW7TTTzhZ/
<ogra> oh, wow
<mvo> ogra: heh, looks like psplash.patch is the culprit
<mvo> ogra: what is it and where does it come from?
<mvo> ogra: and do we need it :) ?
<mvo> ogra: it looks like the patch either needs to rename radon-font.h to font.h or undo this
<ogra> mvo, the gadget was made for kiosks so *it* needs it ... a normal gadget can indeed work witjhout psplash (though t would be great to have it because it exercises split-initrd ;) )
<ogra> -		  psplash-poky-img.h psplash-bar-img.h radeon-font.h
<ogra> +		  psplash-core-img.h psplash-bar-img.h font.h
<ogra> that is what it does
<ogra> and it builds here
<mvo> ogra: yeah but there is no font.h in my parts dir, just radeon-font.h
<ogra> https://paste.ubuntu.com/p/B74sVK8Hp2/
<ogra> mvo,  - ttf-ubuntu-font-family is in build packages ... i suspect that name changed in bionic
<ogra> font.h is generated IIRC
<ogra>  ${TREE}/font-gen.sh "$FONT"
<ogra> ogra@anubis:~/datengrab/appliances/pi-kiosk-gadget:master$ ls psplash/font-gen.sh
<ogra> psplash/font-gen.sh
<mvo> ogra: font-gen.sh was missing a set -e
<mvo> ogra: now I see the error
<ogra> mvo, there must be an error with font-gen.sh earlier in your build
<ogra> mvo, whats the error, looking at the archive it seems all build deps are still there
<ogra> oha ... ttf-ubuntu-font-family is an empty package !
<ogra> https://packages.ubuntu.com/bionic/all/ttf-ubuntu-font-family/filelist
<mvo> ogra: yeah, it can open the input file
<ogra> right ... i wonder where Ubuntu-R.ttf moved in bionic
<ogra> mvo, want a binary ? i have a built one here
<mvo> ogra: thanks, appreciated. I dig a bit more, it looks like this will become the new gadget so it needs fixing at some point anyway
<ogra> lp #851457
<ogra> hmm, no ubottu
<ogra> https://bugs.launchpad.net/ubuntu/+source/fonts-ubuntu/+bug/851457
<ogra> mvo, seems "fonts-ubuntu" is the new name
<ogra> https://launchpad.net/ubuntu/+source/fonts-ubuntu
<mborzecki> another simple one https://github.com/snapcore/snapd/pull/5597
<ogra> mvo, and the path in psplash/config needs to be adjusted to "/usr/share/fonts/truetype/ubuntu/"
<ogra> mvo, here are some hints that should work: https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e
<mvo> ogra: yeah, I found this. now font-gen.sh is failing because I added set -e - the fun thing is that otf2bdf returns exit code 8 - because it bubbles up the result of the last fprintf call which happens to write 8 chars. this is a bit odd to say the least
<ogra> lol
<mborzecki> and another trivial review https://github.com/snapcore/snapd/pull/5598
<mvo> ogra: same issues with universal gadget, pi3 prints gibberish (https://paste.ubuntu.com/p/CsmFxsvmN7/) and pi2 hangs at boot (https://paste.ubuntu.com/p/Df3TrFb69Z/) - the hang could be entropy related of course
<mvo> ppisati: -^
<ogra> mvo, but you did bump to the newer firmware ? like in https://github.com/ogra1/pi-kiosk-gadget/commit/3ec65a9ea98e8479e1ee9f40331eadb741cf1e6e
<mvo> ogra: yeah, this is updated, but I noticed the dtbs are still from xenial, fixing this now
<ogra> oh, indeed
<mvo> ogra: https://github.com/mvo5/pi-gadget/commits/master has my bits, some probably worth cherry-picking too
<ogra> (and who cares about serial anyway as long as you see a pretty splash screen during boot :P)
<mvo> ogra: heh
<ogra> mvo, will pull that in
<mvo> ogra: hm, linux-image-4.15-....deb does no longer have any dtbs, just the kernel image, I guess some packaging changes
<ogra> oh ... ppisati where did they go ? ^^^
<mborzecki> need top drop by doggos off at the groomer, back in 15
<mvo> ogra: looks like it moved to the movuldes package
<ogra> oh, they are separate debs now
<ogra> interesting
<mvo> ogra: pi3 is booting now, not working but at least booting
<ogra> yay
<ogra> how is it not working
<mvo> ogra: whats the most easy way to add "systemd.debug-shell=1" to the u-boot prompt cmdline?
<mvo> ogra: seeding fails but I can't see how
<ogra> mvo, system-boot/cmdline.txt
<ogra> mvo, but i think that systemd debig shell doesnt support serial input
<ogra> *debug
<ogra> mvo, so you want to drop nogetty from the cmdline.txt too and use kbd/monitor
<ogra> (and probably also turn off the splash)
<ogra> (thats sadly a systemd shortcoming)
 * mvo nods
<mborzecki> glob := filepath.Join(dirs.SnapDesktopFilesDir, s.InstanceName()+"_*.desktop"), i sense trouble
<ogra> pessimist :P
<mvo> ogra: yay, its booting and seeding now with a bit of manual fiddling - it lookslike cloud-init is doing strange things in core18 at this point
<ogra> awesome !
<ogra> does core18 not disable cloud-init as it should ?
<mvo> ogra: not yet
<ogra> ah ... needs to :)
<mvo> ogra: yeah
<ogra> but good to hear the gadget works
<mvo> yeah, I need to talk to gustavo but I'm inclined to make this the pi gadget/model for 18
<ogra> \o/
<ogra> mvo, i talked to the kernel team btw ... and they talked to the store guys ... apparently it isnt easily possible to rename pi2-kernel to just be pi-kernel (or to alias the name in the store)
<ogra> and the kernel team douesnt want to maintain two snaps
<mvo> ogra: yeah, renames are not done yet
<mvo> ogra: its ok I think, not great but ok
<ogra> yeah
<ogra> just shows that we suck at picking names :)
<mborzecki> and another easy win https://github.com/snapcore/snapd/pull/5599
<Son_Goku> zyga, how are we doing on the demo for Flock?
<Chipaca> huh,  the single biggest .a file is from asserts
<mvo> Chipaca: interessting, crypto code?
<mvo> Chipaca: initialization tables and all that?
<Chipaca> mvo: wouldn't that be in its respective .a?
<mvo> Chipaca: maybe stuff like htis https://github.com/golang/go/blob/master/src/crypto/sha512/sha512block.go#L5 but its just a guess
<mvo> (a very wild one too!)
<mvo> Chipaca: probably nonsese, not nearly big enough
<Chipaca> mvo: 66K	/snap/go/current/pkg/linux_amd64/crypto/sha512.a
<mvo> Chipaca: yeah, probably not it - how big is asserts.a?
<Chipaca> crypto/tls is bigger
<Chipaca> mvo: 2.5M
<Chipaca> that's not a small difference :-)
<Chipaca> might be stripped vs non-stripped though
<Chipaca> dunno
<Chipaca> just found msyelf pondering if there'd be an easy way of getting a handlde on how much each package contributed to snapd's size
<mvo> Chipaca: interessting
<Chipaca> mvo: bolt is 408k for ex
<mvo> Chipaca: nice
<Chipaca> anyhow. I should either take a nap, or get more coffee
<mvo> Chipaca, mborzecki I had fun as well: https://github.com/jirutka/otf2bdf/pull/1
<Chipaca> i was typing irc into the browser
<mvo> Chipaca: haha
<mvo> Chipaca: quick nap should be fine :)
<mvo> Chipaca, mborzecki if the patch makes sense I will upload this to cosmic
<mborzecki> wow
 * Chipaca hugs  mvo 
<Chipaca> mvo: why u writing c again
<mvo> Chipaca: because I love it
<mborzecki> mvo likes the grumpy feels
 * Chipaca calls the police
<mvo> Chipaca: just kidding, necessity is the mother of invention?
<mvo> Chipaca: haha - the C-police
<mvo> mborzecki: yeah, I was too happy in the morning
<Chipaca> "this pull request rewrites the whole project in go and python because you had this bug"
<mborzecki> da sound of c-police
<mvo> mborzecki: actually not, I need to dive into cloud-init on core18 and I don't want to :/ I need some extra strong tea for that
<mvo> Chipaca: lol (https://www.thinkgeek.com/product/374d/  - also not funny anymore these days)
<mvo> or maybe, I guess very small shell scripts are still ok
<mborzecki> mvo: as long as you don't quote and don't use redirects
<Chipaca> mvo: necessity is the mother of grumpiness. Grumpiness might then father invention. Or war.
 * Chipaca has cold coffee and hope
<Chipaca> why would you need a kernel module to make a backup of a btrfs partition?
<ogra> heh, i was wondering the same
<Chipaca> ogra: it might be https://github.com/datto/dattobd
<ogra> so it intercepts all write operations ? ... what could possibly go wrong :P
<Chipaca> ogra: and it creates /proc/datto-info which is JSON
<Chipaca> I'd ban it just based on that
<ogra> "although filesystems with their own block device management systems such as ZFS and BTRFS can not be supported"
<ogra> so probably not that
<pbek> I wrote a hosts-file switcher https://github.com/pbek/hswitch that generates an /etc/hosts file. It needs to be an as root (which doesn't seem to work with the snapped version of hswitch) and needs to write to the hosts file. is that reason enough to ask for classic confinement in the snap store?
<pbek> *ran
<ogra> pbek, theoretically i'd expect this file to be accessible through the network-control interface, but seems it is not ... perhaps jdstrand would add access to it there though
<ogra> i'd start a post on the forum about it
<pbek> thank you ogra, so should I apply for classic confinement? I got the message " If your snap needs classic confinement to function, please make a request for this snap to use classic by creating a new topic in the forum using the 'store' category and detail the technical reasons why classic is required.". Do you know where that forum is duckduckgo/google couldn't help me and I dodn't find it on https://ubuntuforums.org/
<ogra> well, classic is generally a bad idea if there is any chance to instead extend an existing interface or cover the needed task with a new interface, so i'd first ask if there is a possibility to allow write access to /etc/hosts through one of the interfaces ...
<cjwatson> there's a link to the forum in the topic
<ogra> if there isnt, classic is surely a possible fall-back
<ogra> jdstrand, could we add a forum link to that review-tools message above ?
<pbek> thank you for your help ogra and cjwatson. I wrote a post now on https://forum.snapcraft.io/t/writing-to-etc-hosts/6651
<ogra> yup, i saw it popping up in the forum :)
<Chipaca> mmm, hosts-control sounds good to me
<ogra> well, i guess hostname-control would work too ...
<Chipaca> ogra: hostname-control already exists though
<Chipaca> ogra: and it's not clear that granting one should grant the other (and bicerveza)
<ogra> yeah and sets the hostname ...
<Chipaca> but, totally jdstrand land :-)
<ogra> given that local name resolution for the host happens in /etc/hosts it might or might not be a avlid place to have /etc/hosts writable
<ogra> *valid
<ogra> so it could perhaps be extended instead of having a complete new interface
<ogra> yeah, totally :)
<jdstrand> otoh, /etc/hosts is quite different from hostname-control. /etc/hosts is about static name resolution and hostname-control is about the system hostname. sure, the system hostname is included in /etc/hosts, but for different reasons
<ogra> yeah
<Caelum> was just trying the gentoo overlay, I get this when installing spotify: - Fetch and check assertions for snap "spotify" (16) (parsing assertion headers: expected 4 chars nesting prefix after multiline introduction "slots:": "  mpris:")
<jdstrand> ogra, pbek: the review-tools actually have a link and the store shows it
<jdstrand> pbek: where did you see the message? snapcraft?
<jdstrand> mvo: hey, are there core18 images that can be used in a VM for some testing?
<jdstrand> core18-based images...
<mvo> jdstrand: not quite, I hope to get something ready today though, I can upload some snapshot if you want to test something specific now
<Chipaca> mvo: if ubuntu moves to require xattrs, will that impact core18, or only from core20?
<Chipaca> Caelum: where do you get that?
<Chipaca> Caelum: is the 'gentoo overlay' the way you can use snapd from gentoo?
<Chipaca> Caelum: what's the output of 'snap version'?
<mvo> Chipaca: as long as bionic does not requuire them yet I think we are fine until core20
<mvo> Chipaca: where is this discussed?
<Chipaca> mvo: ubuntu-devel, 'RFC: baseline requirements for Ubuntu rootfs: xattrs and fscaps'
<Chipaca> mvo: mtr uses caps in 16.04 already
<Chipaca> mvo: in fact so does /usr/bin/systemd-detect-virt
<jdstrand> mvo: what I'm thinking about is the socketcall multiplexer in the default template. I'd like that to go away and a core18 image seems like a way to do that
<jdstrand> mvo: that said, I'm not completely sure how to achieve it. you need a new enough kernel and a new enough glibc
<jdstrand> mvo: I don't have the details of which otoh, but assuming I had that, I could system-key the kernel bit easy enough, but would need to figure out the base snap in use I guess. then, how to know the difference between a core16 device and a core18 device?
<Chipaca> jdstrand: and snaps using core16 on a core18 device?
<Chipaca> jdstrand: you should be hearing https://www.youtube.com/watch?v=ZI6Qgvy33Uc about now
<jdstrand> Chipaca: well, my assumption was I could look at snap_info to see if a base snap was specified. I could then say 'if !core16...'. I wasn't sure how to figure out the default for the system though
<jdstrand> hehe
<Chipaca> jdstrand: ah, so if the kernel were new enough, you'd make this per-snap?
<jdstrand> how is that supposed to work actually. if I have a snap that was built for xenial that doesn't specify a base, and install it on a core18 device, what does the core18 device do?
<mvo> jdstrand: snapstate can access "Model()" which can then check for model.Base() but I guess thats not ideal, ideally we would check based on some introspection of libc/kernel, no?
<jdstrand> Chipaca: I think so
<jdstrand> mvo: the kernel bit is easy since we already do that and that isn't subject to change
<mvo> jdstrand: when you build a xenial snap and install it on a core18 device it will pull in core as the base and run it inside the core environment (effectively core16)
<jdstrand> mvo: so from now until the end of time you'll have to specify a base snap for anything other than core16?
<Caelum> Chipaca: the overlay is https://github.com/zyga/gentoo-snappy the version of snapd is 2.15.2
<jdstrand> ie, not specifying base will always get you core16?
<Caelum> I guess that's really old
<Caelum> and the overlay needs to be updated
<Caelum> I'll work with zyga on that
<Chipaca> Caelum: yeah. Error could be better though.
<Chipaca> Caelum: i thought somebody was looking at gentoo recently, but not sure who
<Chipaca> maybe it was you :-)
<Caelum> nah not me, I just barely got it installed
<mvo> jdstrand: we want to transition people gently with snapcraft
<mvo> jdstrand: i.e. warn (or add core16) as the base when nothing is specified
<Caelum> I was going to help zyga get snapd into the main opensuse repos too
<Caelum> dunno how that all went
<jdstrand> mvo: sure, but what I'm getting at is that if a base snap is not specified in the snap.yaml, you'll always default to core16?
<Chipaca> Caelum: the person I'd ask about this _just_ EOWed
<Chipaca> Caelum: (the might've seen you asking and made a runner)
<jdstrand> cause then I could do 'if not specified or is core or is core16...' or something
<Chipaca> s/made/done/
<jdstrand> mvo: ^
<mvo> jdstrand: yes
<mvo> jdstrand: but note that people might use "base: fedora-core" or whatnot in the (near) future
<Chipaca> base: bo
<jdstrand> yeah
<jdstrand> I didn't really want to have to if core18 or fedore-core or core20 or core22 or core24 or arch-core or...'
<jdstrand> but I might have to
<jdstrand> I guess we could peek at the libc6.so in /snap/<base>/<current> but youchie
<jdstrand> yowchie
 * jdstrand likes to make sure he spells his made up words correctly
<ogra> heh
<jdstrand> mvo: I could just check the kernel and arch. that would, for example, at least remove it for amd64. hmm, but compat mode..
<jdstrand> mvo: do you have other ideas on how to migrate away from it?
<mvo> jdstrand: hm, hm, there is no way to introspect libc somehow I guess?
<jdstrand> actually, socketcall doesn't exist on amd64 or arm
<jdstrand> mvo: well, but which one? I mean, the snap isn't going to get the one on the system on a core18 device with a base: core16 snap
<mvo> jdstrand: could we look at the base and look at the bases filesystem when we generate the apparmor profiles?
<mvo> jdstrand: or maybe we can add hints to the bases, we talked about this before
<mvo> jdstrand: hints like "you need these special confinement rules"
<jdstrand> mvo: possibly, but I don't think libc6.so is guaranteed to be in the same place
<jdstrand> I mean, on base: bo and base: core16 it won't be (multiarch), let alone fedora-core
<mvo> jdstrand: yeah, its a rathole, the code would have to inspect the elf file(s) :/
<jdstrand> mvo: let me get completely up to speed on the conditions that would guarantee where it can be removed
<jdstrand> mvo: maybe that will give some more details for inspiration
<mvo> jdstrand: ok, its also friday afternoon for me, so I'm not 100% fresh  :)
<mvo> jdstrand: so I'm probably also lacking inspiration
<jdstrand> mvo: sure. assuming we can come up with something reasonable, is this something you'd be willing to accept for core18 devices?
<jdstrand> mvo: or is it too late to make this type of change?
<Chipaca> mvo: jdstrand: we could have a .yaml for bases that described things
<jdstrand> Chipaca: that might be useful for more than just this
<Chipaca> mhmm
<mvo> mwhudson: just in case you are around, I get the following error on the pi3 with core18: https://paste.ubuntu.com/p/7rFKyY5Zbs/ when running console-conf
<mvo> mwhudson: the generated netplan yaml: http://paste.ubuntu.com/p/pQ8W9544cw/
<mvo> jdstrand, Chipaca yeah, some meta data would be fine - we just need blessing from gustavo but I think its not too late for this
<mvo> sil2100: hey, great to have you around - I have questions :) I get the following error on the pi3 with core18: https://paste.ubuntu.com/p/7rFKyY5Zbs/ when running console-conf the generated netplan yaml: http://paste.ubuntu.com/p/pQ8W9544cw/  any ideas?
<jdstrand> mvo: we could infer from the base snap name though. that would be simple. eg, 'if kernel >4.3 and base in [core18, fedora-core]: don't add socketcall'
<jdstrand> mvo: that would at least separate the need for said base.yaml
<jdstrand> mvo: and if it that yaml was interesting enough on its own, we could modify this check for it
<jdstrand> mvo: we still aren't expecting a huge number of bases, right? that said, even if we did, we don't *today* and an internal list is a fast way to get socketcall out
<jdstrand> and we could refine that check going forward
<mvo> jdstrand: yeah, today checking for core18 is fine
<mvo> jdstrand: and when we get new bases we just add them there
<Chipaca> it'd have to be a very long list to be slower than parsing yaml :-)
<mvo> Chipaca: heh :)
<mvo> Chipaca: I guess what might be slow is that snapd will need updates for new bases but I guess thats ok
<Chipaca> this is for a generated file, that somebody could tweak by hand for development/
<Chipaca> ?
<sil2100> mvo: hey! Let me take a look
<Chipaca> mup: are you back?
<Chipaca> i guess no
<mvo> Chipaca: no, very sad
<mvo> sil2100: I also removed (temporarily?) cloud-init from core18 as it was interfering with the pi boots
<mvo> sil2100: we should probably talk next week aobut this :)
<mvo> sil2100: and congrats for the 16.04.5 releass btew
<mvo> sil2100: btw
<Chipaca> Son_Goku: zyga is away
<Chipaca> Son_Goku: (i saw you ask him something earlier)
<Chipaca> Son_Goku: should be reachable on telegram though
<Son_Goku> ah
<Son_Goku> Chipaca, what's his name on Telegram?
<Chipaca> Son_Goku: pm
<Son_Goku> ok
<Chipaca> Son_Goku: on irc, i meant :-)
<sil2100> mvo: thanks! Yeah, let's do that - btw. good that you're testing this on pi3 as well, do you know if there was anyone looking at core18 on arm64 hardware? (since I suppose the pi3 you're testing on is the armhf one, right?)
<sil2100> mvo: as for the netplan issue, I wonder why it's only a problem now! set-name requires match: since like 2 years IIRC
<mvo> sil2100: I don't have arm64 hardware but cachio has, he is keen to test it. but I guess there will be some work, hte pi2,pi3 required dtb updates
<mvo> sil2100: no idea :) it also works on my amd64 VM
<mvo> sil2100: it just happens on my pi3 test image
<sil2100> huh, let me dive into that
<sil2100> mvo: awesome
<mvo> sil2100: thank you, I can make hte image available if that helps
<Chipaca> jdstrand: quesiton about a denial
<Chipaca> jdstrand: [  512.654826] audit: type=1400 audit(1533308845.960:41): apparmor="DENIED" operation="capable" profile="snap.test-snapd-hostname-control.sh" pid=948 comm="hostnamectl" capability=12  capname="net_admin"
<Chipaca> jdstrand: that's what I get when I try to run 'hostnamectl', in 18.04, from a snap that's got hostname-control
<Chipaca> jdstrand: but only if it's got to start the dbus wotsit
<Chipaca> if it's already running, it works
<Chipaca> when I say 'in 18.04' I do _not_ mean core18, fwiw
<Chipaca> the dbus wotsit is /lib/systemd/systemd-hostnamed fwiw
<Chipaca> cachio: ^ this is why your hostname-control PR is red
<cachio> Chipaca, ahhh
<cachio> nice
<Chipaca> cachio: good on you for catching this
<cachio> Chipaca, thanks
<ogra> mvo, sil2100, note that we set net.ifnames=0 in core images (and thats essential) perhaps netplan is unhappy about that one ?
<ogra> (thogh i guess that wouldnt be device/board specific )
<sil2100> mvo: interesting, console-conf for an amd64 doesn't spit out set-name: eth0
<sil2100> mvo: when you think about it, he shouldn't, I guess I'll take a look what causes that
<sil2100> (anyway, looking at it!)
<jdstrand> Chipaca, cachio: I suspect something is falling back to sethostname()
<Chipaca> jdstrand: this is running  'hostnamectl' on its own, which shouldn't be setting anything (it just prints something afaik)
<Chipaca> jdstrand: https://github.com/snapcore/snapd/pull/5593 if you want to repro this yourself
<Chipaca> anyhoo, i need to run
<Chipaca> ttfn
<jdstrand> cachio: it's possible that if the service isn't running, hostnamectl is using setsockopt with particular options that need net_admin. see man 7 capabilities (I haven't investigated this)
<sil2100> mvo: btw. I'm preparing and testing a new subiquity for core18 based on what's in git, if it turns out to be good I guess I could push it to ppa:snappy-dev/image
<sil2100> (with all the console-conf fixes and branding changes)
<cachio> jdstrand, I'll check that
<mvo> sil2100: sounds good, we may need to tweak the build to pull from the ppa, iirc right now we only pull from the main archive
<sil2100> Yeah, the subiquity in the archives didn't get any uploads in ages, so I want to test this here locally first (building in my PPA)
<mvo> sil2100: *nod*
<kyrofa> When I `sudo snap install --revision=<blah>` it always says "installing <revision> from stable"
<kyrofa> This is released to no channel
<kyrofa> noise][, I've been waiting 10 minutes for a review to even start. Things are starting to queue up
<kyrofa> Are there issues, or just increased load?
<kyrofa> Ah, one finally happened. Must just be load
#snappy 2018-08-04
<pbek> jdstrand: regarding where I get the message about to post in the forums: it was in an email I got from snapcraft
<Caelum> is zyga still with this project? on vacation maybe?
<ogra> Caelum, yes to both
<ogra> (unless he is molten to dust in the european summer :) )
<Caelum> ah great
#snappy 2018-08-05
<andrewebdev> I'm hoping it's ok to post here. I'm trying to set up core on my rpi3 for some prototyping. During the configuration where I have to set up my account details, I get a error: error: while creating user: cannot create user
<andrewebdev> the error immediately below that is: Get https://login.ubuntu.com/api/v2/keys/<redacted>: x509: certificate has expired or is not yet valid
<andrewebdev> hmm, ok never mind that then. The installation finished fine even with that error. Strange
<JamesB192> andrewebdev: is/was the clock thinking it is 1970 all over again?
#snappy 2019-07-29
<mborzecki> morning
<pstolowski> mornings!
<mborzecki> pstolowski: hey, welcome back, well rested?
<pstolowski> mborzecki: yep! i had great time, thanks
<mborzecki> pstolowski: nice ;)
<pstolowski> mborzecki: how was it here?
<mborzecki> pstolowski: few of us left this week, mvo on vac, pedronis & zyga attending a sprint
<mborzecki> pstolowski: rather quiet
<mup> PR snapd#7183 opened: [RFC] many: drop snap.ReadGadgetInfo wrapper <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7183>
<mborzecki> unit tests hanging on travis again, hmm
<Chipaca> hah! finding bugs during a refactor is fun
<mborzecki> Chipaca: bugs == fun
<mborzecki> Chipaca: unless they bite, then run
<mup> PR snapd#7184 opened: daemon: do not modify test data in user suite <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7184>
<mborzecki> Chipaca: can you take a look ^^ ?
<Chipaca> mborzecki: in a mo'
<mborzecki> Chipaca: sure, thanks!
<mup> PR snapd#7185 opened: boot, etc.: refactor boot to have a lookup with different imps <Created by chipaca> <https://github.com/snapcore/snapd/pull/7185>
<mborzecki> brb
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> zyga: how was the trip?
<zyga> hey
<zyga> my flight had 3 hour delay because they had to fly in a replacement
<zyga> but otherwise it was totally uneventful and pleasant
<pstolowski> hey zyga!
<zyga> hey pawel
<zyga> guys, a small heads up
<zyga> despite the sprint I will try to land bug fixes
<zyga> I think core and ubuntu are green now
<zyga> fedora still has some interactions with lxd that I need to address
<zyga> my goal is to make https://github.com/snapcore/snapd/pull/7168 landable
<mup> PR #7168: tests: measure testbed for leaking mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/7168>
<zyga> sorry about the noisy PRs, I'll try to garden them throughout the day
<zyga> if you need anything from me urgently please use telegram
<pstolowski> ack
<zyga> if you don't have me on telegram ping me on IRC, i'll try to check from time to time
<Chipaca> pstolowski: hey! wb :-)
<pstolowski> Chipaca: o/
<pstolowski> Chipaca: thanks for helping land some of my PRs while i was off
<Chipaca> pstolowski: sorry we couldn't manage to land them all :)
<pstolowski> Chipaca: nah, it was better than expected!
<pstolowski> Chipaca: afaiu the PR about snapd type & snapcraft needs passthrough for now, was this something you discussced & agreed on?
<Chipaca> pstolowski: i think using passthrough was deemed acceptable for now
<Chipaca> pstolowski: but i'm not 100% positive on that
<pstolowski> k. i'll give it one more try on spread and see if i can find anything before trying passthrough
<mup> PR snapd#7186 opened: gadget: ensure filesystem labels are unique <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7186>
<Chipaca> I like that Fedora Workstation automatically creates a mugshot for your user, based on your initials
<Chipaca> I particularly like it because, as per my usual approach, the user's name is Fedora User
<mborzecki> simple one ^^ pstolowski maybe?
<Chipaca> so password prompts are like 'FU gimme your password'
<Chipaca> i like distros with attitude
<mborzecki> hahaha
<mborzecki> anyone noticed unit tests getting stuck recently?
<Chipaca> not me
<Chipaca> mborzecki: where?
<mborzecki> Chipaca: go test ./... as run on travis seems to get stuck randomly, i can't reproduce it locally though
<pstolowski> mborzecki: yeah i think i've just experienced it on my PR
<mborzecki> pstolowski: yay
<mborzecki> pstolowski: did you get a bracktrace by any chance?
<pstolowski> mborzecki: nope, it was on travis
<mborzecki> pstolowski: there were some changes recently around socket listen in deamon, i'm suspecting that might be the cause
<zyga> mborzecki: can you try go test with race detector?
<mborzecki> zyga: nothing comes up
<mborzecki> zyga: more problems with lxd & unified cgroups https://forum.snapcraft.io/t/lxd-3-15-fails-with-unified-cgroup-hierarchy/12462/10
<zyga> mborzecki: hey
<zyga> looking
 * Chipaca lunches
<mborzecki> pstolowski: pinged you in https://github.com/snapcore/snapd/pull/7187
<mup> PR #7187: data/selinux: allow snap-confine to read entries on nsfs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>
<mborzecki> zyga: is this something you saw in your tests too? ^^
<mup> PR snapd#7187 opened: data/selinux: allow snap-confine to read entries on nsfs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>
<zyga> mborzecki: re
<zyga> mborzecki: I don't believe so but I didn't focus on fedora yet, it's the next pass
<zyga> mborzecki: I didn't get a clean run on fedora yet
<mborzecki> zyga: ok
<zyga> I'm working on fixing the fedora leaks now
<micah> hi, it seems my 'core' is in the state 'broken', how do I fix that?
<Chipaca> zyga: I don't do it this way: https://www.telegraph.co.uk/politics/2019/07/28/dominic-cummings-one-strike-ban-cabinet-leaks-leaked-daily-telegraph/
<Chipaca> micah: what kernel are you running?
<micah> seems I needed to remove core and install core
<micah> Chipaca: 4.14.119
<Chipaca> micah: hm, that should be working fine (5.2 has some issues)
<Chipaca> micah: how did this happen?
<micah> Chipaca: i dont know how... but it seems when I restart, its broken again
<Chipaca> micah: can you do: snap info cpre | pastebinit
<Chipaca> er
<Chipaca> micah: can you do: snap info core | pastebinit
<Chipaca> micah: or even better,
<Chipaca> micah: can you do: snap info --verbose core | pastebinit
<micah> Chipaca: https://pastebin.com/b4dWfzT9
<ogra> "snap version2 too
<ogra> err
<ogra> "snap version"
<ogra> (little weakness of the shift key)
<ogra> 4.14.119 sounds like some random mainline kernel ...
<mborzecki> ogra: hmm, sounds like an LTS kernel tbh
<micah> https://pastebin.com/2mRCq9K7
<Chipaca> micah: systemctl --all --failed | grep snap  ?
<ogra> mborzecki, well ... 4.14.119-2.pvops.qubes.x86_64
<mborzecki> ogra: 4.14.119 with qubes patches on top likely
<ogra> mborzecki, definitely not an ubuntu kernel (though this seems to be debian ... but also not a debian archive kernel for sure)
<ogra> mborzecki, sure, but you cant know what config options are set, if the apparmor patches are complete etc
<ogra> it is simply not "some distro standard kernel"
<mborzecki> ogra: or whether it defaults to selinux like the mainline builds did/do :)
<ogra> yep :)
<Chipaca> ogra: i'm not going to abort any support as soon as the kernel isn't on a known-good list
<ogra> Chipaca, i didnt ask that anyne stops supporting ... it is just an important fact to know about during support
<ogra> *anyone
<Chipaca> micah: please pastebin the output of that?
<micah> Chipaca: seems systemctl --all --failed | grep snap doesn't give me anything
<Chipaca> micah: so what's at /snap/core/current ? (try with ls -l)
<micah> lrwxrwxrwx 1 root root 4 Jul 29 08:27 /snap/core/current -> 7270
<Chipaca> micah: and in 7270?
 * Chipaca goes for tea
<micah> and 7270 is empty
<Chipaca> micah: does 'systemctl --all | grep snap' give you anything?
<micah> Chipaca: it does
<Chipaca> micah: can i see?
<Chipaca> pstolowski: cachio: standup?
<micah> Chipaca: https://pastebin.com/pNsjmY9u
<Chipaca> degville: standup?
<Chipaca> micah: systemctl status snap-core-7270.mount ?
<micah> chipaca: https://pastebin.com/hySYpyXv
<Chipaca> micah: systemctl start snap-core-7270.mount ?
<micah> Chipaca: that seems to start it
<micah> and 7270 now has things in it
<Chipaca> micah: ok, systemctl restart snapd.service, to get things back in shape
<Chipaca> micah: something went wrong somewhere with systemd for that to be broken, but if you don't know what Â¯\_(ã)_/Â¯
<mborzecki> grr go 1.13 runtime now pokes /sys/kernel/mm/transparent_hugepage/hpage_pmd_size during startup, making selinux complain each time you run snap* command
<Chipaca> stgraber: do you have a link to the 5.3 mount api breakage?
<micah> Chipaca: yeah, definately... too bad I dont know what
<Chipaca> micah: would be good to know if it's still ok on reboot
<micah> Chipaca: i'll try in a second
<Chipaca> micah: no rush, we'll be here tomorrow
<Chipaca> :)
<mborzecki> https://github.com/snapcore/snapd/pull/7187 unit tests hanging on travis again :/
<mup> PR #7187: data/selinux: allow snap-confine to read entries on nsfs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7187>
<Saviq> cachio: hey, would you consider having a `ubuntu-devel` image for spread?
<Saviq> Our at least build a 1910 one?
<Saviq> *Or
<cachio> Saviq, sure
<cachio> Saviq, but also you can used the one published by canonical
<stgraber> Chipaca: https://lkml.org/lkml/2019/7/26/388
<Saviq> cachio: could you review our list please https://github.com/MirServer/mir/blob/master/spread.yaml#L14 ?
 * Saviq tries to remember why we don't use the official images in the first placeâ¦
<cachio> Saviq, just run: gcloud compute images list --project ubuntu-os-cloud-devel
<cachio> this will give you all the devel imags
<Chipaca> stgraber: thanks
<cachio> you just can use any of these by doing image: ubuntu-os-cloud-devel/<image-name>
<Saviq> cachio: thanks, I'll try, I never got gcloud working properly hereâ¦
<cachio> Saviq, https://paste.ubuntu.com/p/z9ckvYwScZ/
<cachio> tihs is the list of images
<Saviq> cachio: thanks :)
<cachio> take a look and if there is not any image that works for you I can create 1 with the lates changes from devel
<cachio> Saviq, your spread.yaml seems to be ok
<cachio> the ubutnu images that you use are the official ones
<mup> PR snapd#7188 opened: data/selinux: allow read on sysfs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7188>
<mborzecki> pstolowski: heh ^^ another one
<micah> Chipaca: on reboot, same problem
<Chipaca> micah: ok, look at 'journalctl --system', and look for anything red
<micah> Chipaca: i see nothing red there that is related (some firmware/acpi things)
<zyga> hey, any news?
<Chipaca> micah: what's systemctl status snap-core-7270.mount ?
<Chipaca> zyga: about what?
<zyga> in general
<zyga> guys, the go unit tests are flaky
<zyga> can we see if a branch from last week would be green
<zyga> I have a feeling it is something we merged mid week
<zyga> is anyone on this?
<mborzecki> zyga: attempted to reproduce this, but only got this https://github.com/snapcore/snapd/pull/7184 obviously the problem doesn't happen locally (at least for me)
<mup> PR #7184: daemon: do not modify test data in user suite <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7184>
<zyga> mborzecki: can you try with GOMAXPROCS=2
<zyga> or something "low"
<micah> Chipaca: i put the output of the journalctl --system and the systemctl status into this paste: https://pastebin.com/MknBeW9T
<zyga> mborzecki: the tests that use lxd should reboot to clean up
<zyga> that's the bottom line from the lxd team
<mborzecki> zyga: sgtm
<zyga> not sure how to do it yet
<mborzecki> zyga: only a handfull of those
<zyga> I know we have REBOOT and REBOOT_COUNT, need to play with that
<mborzecki> zyga: i can look into that, there's a REBOOT in a couple of tests I added already
<zyga> mborzecki: thank you
<zyga> I'll work on other tests
<zyga> though honestly, right now unit tests being red is more problematic
<Chipaca> zyga: mborzecki: do you have an example run of the tests hanging?
<zyga> no, only in travis
<zyga> most recent PRs are red
<Chipaca> zyga: that's what i mean
<zyga> (because of this)
<mborzecki> Chipaca: https://travis-ci.org/snapcore/snapd/builds/564940409?utm_source=github_status&utm_medium=notification
<Chipaca> zyga: not necessarily because of this
<Chipaca> mborzecki: thanks
<ogra> Chipaca, micah, wow, so qubes seems to essentially be a livecd kind of setup (everything readonly, parts of the system are rw bind mounts) ... perhaps some dirs needed by snapd are simply missing (or not there when snapd starts due to races etc)
<ogra> (it is also interesting that your kernel was built on fedora while your rootfs is debian based apparently ... but thats just a fun fact)
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<micah> ogra: Chipaca it appears qubes does this to make it work: https://github.com/QubesOS/qubes-app-linux-snapd-helper
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<ogra> wow https://github.com/QubesOS/qubes-app-linux-snapd-helper/blob/master/qubes-snapd-mount
<ogra> so it re-creates all snap mount units
<ogra> ... on the fly ...
<micah> should it have a pre-dependency on something?
<micah> because it seems like in some boots, it works, and some it does not
<Chipaca> micah: looks like snapd.service should have an after: whatever it is that creates the mounts
<ogra> yeah, my guess would be that snapd is already running while this mount unit recreation still runs
<ogra> it is also rather dangerous what they are doing there, typically snapd creates these mount units ... if anything chenags on the snapd side, the qube script wont pick it up
<ogra> *changes
<ogra> if they need to chnage the pre-snap mount units, they should better take the original ones as input
<ogra> *per-snap
<ogra> Jul 29 10:32:03 browser systemd[1]: snap-core-7270.mount: Succeeded.
<ogra> Jul 29 10:32:03 browser systemd[1]: Unmounted Mount unit for core, revision 7270.
<ogra> Jul 29 10:32:03 browser systemd[1]: Started Rebuild the non-persistent snappy systemd mounts.
<ogra> Jul 29 10:32:03 browser systemd[1]: Starting Snappy daemon...
<ogra> Jul 29 10:32:03 browser systemd[1]: Unmounting Mount unit for firefox, revision 243...
<ogra> Jul 29 10:32:03 browser systemd[1]: rw-bind\x2ddirs-snap-firefox-243.mount: Succeeded.
<ogra> they are definitely stepping on each others toes
<ijohnson> hey Chipaca, degville: I'm finalizing a refactoring of the instructions for running spread in HACKING.md, should I make all the text under 80 chars there?
<ijohnson> The file isn't consistent, not sure if we have a style we try to maintain for markdown
<Chipaca> ijohnson: as long as it looks ok in github i don't mind
 * Chipaca is not a purist
<ijohnson> cool! sounds good
<ogra> make it 78.5 chars .. the you can still have a terminal scrollbar
<ogra> :P
<ogra> *then
<Chipaca> zyga: cpufreq'ed my laptop down to 800MHz and turned off all my cores except 1
<Chipaca> zyga: trying to repro the travis thing
<zyga> thank you
<ijohnson> ogra: how many times have you read markdown from a github repo in a terminal in the past month?
<Chipaca> i haven't had a work machine this slow since the first one i built myself
<zyga> :D
<ogra> ijohnson, every time i used w3m ...
<Chipaca> 200MHz pentium mmx :')
 * ijohnson searches what w3m is
<micah> ogra: yeah, that does look like its stepping on itself there... i'm not familiar enough with what is going on here to know what I should do to make this not happen
<ogra> ijohnson, (like ... never :P ... and i wa indeed joking)
<ijohnson> ah got it
<degville> ijohnson / Chipaca: It's not my jurisdiction, I'm sure, but editing md in vim is definitely easier for me when it's <80 wide.
<ijohnson> hmm, let me see how it looks in GitHub when it's at 80 lines
<ijohnson> we do want to make docs easy for degville to edit :-)
<degville> it should be fine.
<degville> the width shouldn't affect the output.
<ijohnson> those sound like famous last words
<degville> ahahaha!
<Chipaca> degville: in preformatted text it does
<Chipaca> that is, in ```s
<degville> ^ except that of course :)
<ogra> micah, well, it would be interesting to know what they try to achieve by duplicating the snap mount units in the first place
<ogra> it also seems their rw-bind script tries to mount the snap dirs rw alongside ... which is pointless given everything is a squashfs anyway
<ijohnson> ok, what looks better in GitHub: https://github.com/anonymouse64/snapd/blob/feature/HACKING-md-updates/HACKING.md
<ijohnson> or https://github.com/anonymouse64/snapd/blob/feature/HACKING-md-updates-unlimited-chars/HACKING.md
<ogra> perhaps systemd is simply clever enough to recognize that this is producing a mess and simply unmounts them all
<Chipaca> ijohnson: ooh, that needs to say 1.9 now
<ijohnson> I actually don't see a difference
<ijohnson> Chipaca: ah you're right
<ijohnson> honestly, the formatting looks the same whether it's 80 chars or not, so I think degville will get to keep easily editing in vim
<ijohnson> Chipaca: do you know what release of snapd started requiring go 1.9?
<Chipaca> ijohnson: not offhand
<Chipaca> let me check the logs
<ogra> huh ? why would vim have anything to do with 80chars ?
<mborzecki> Chipaca: i got it once with GOMAXPROCS=2 and -count=20, but didn't have GOTRACEBACK set :/
<Chipaca> ijohnson: 2.38
<ijohnson> thanks Chipaca
<ijohnson> ogra: see degville's comment
<Chipaca> ijohnson: that was 'git log' to find #6294, and then 'git tag --contains 618450bb0fb3064a9f310456047993017828556d'
<mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6294>
<ijohnson> how did you know which PR to look for though?
<ogra> ijohnson, we should do some compny wide crowdfunding to pay a proper post-VGA monitor for degville then :)
<Chipaca> ijohnson: I looked for 1\.9
<ijohnson> ah
<Chipaca> :)
<degville> ogra: it's only because I have been used to editing tw=79 for a long time. Probably the only cache size my brain can handle.
<ogra> haha
<micah> ogra: i'm trying to come up with a clear, concise summary of the problem so I can report it to qubes
<micah> ogra: think this is accurate: "Qubes automounts conflict with Snap mounts, causing snaps not to work and appear broken."
<ogra> micah, yeah, kind of ... i think whet they should do is to simply "ln -sf /var/lib/snapd/snap /" and just leave the mount units alone
<ogra> *what
<ogra> Änd they shoudl do that linking before any of the mount units or snapd even attempt to start)
<micah> i see
<ijohnson> btw I think we should update the spread snap to look for the user's real $HOME dir instead of $HOME/snap/spread/current
<ogra> it seems that they do all this re-creation dance just because they do not know if /snap exists or not
<Chipaca> ijohnson: ?
<ogra> there are other options ... they could pretend they are fedora, then /var/lib/snapd/snap would be the default and snapd would be taking care that the mount units do the right thing ...
<ijohnson> well the HACKING.md says to get spread, you should install the snap, but it also says that you should put images inside $HOME/.spread/qemu
<ijohnson> so the instructions don't work if you follow them exactly
<ogra> or they could provide a patch to snapd upstream to put their OS into a list that makes snapd DTRT
<ijohnson> you either need to move qemu images into $SNAP_HOME (or whatever env points there I forget), or you need to export HOME before running spread
<ogra> though it seems their OS actually pretends to be debian even though it is a derivative of some kind
<ogra> so it might be hard to detect for snapd that you run QubesOS
<mborzecki> Chipaca: in case you're playing with the unit tests getting stuck, https://github.com/golang/go/issues/27189
<Chipaca> mborzecki: yay
<mborzecki> Chipaca: heh https://paste.ubuntu.com/p/QGhSdgQWSC/ that's a bit unexpected too
<Chipaca> i'm going to leave this running and go for a run myself
<zyga> niemeyer: https://forum.snapcraft.io/t/rfc-plug-slot-rules-plug-names-slot-names-constraints/12439
<niemeyer> THanks
<mborzecki> Chipaca: another interesting find https://paste.ubuntu.com/p/yFNJcPBjfg/
<Chipaca> mborzecki: /o\
 * Chipaca really goes afk now
<mup> PR snapd#7189 opened: HACKING.md: update spread section, other updates <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7189>
<micah> ogra: well basically its a debian VM, running under xen
<micah> ogra: could I construct a systemd unit file that just does this symlink and is run before the the mount units or snap units and try and see if that works?
 * cachio lunch
<mborzecki> Chipaca: was about to leave when noticed the tests got stuck: https://paste.ubuntu.com/p/yhGfmdRvj7/
<mborzecki> leaving for real now :)
<mborzecki> zyga: ^^
<micah> ogra: The rw-bind script just makes sure that the snaps are saved in the appvm storage rather than being lost on shutdown on the appvm
<mup> PR snapcraft#2646 opened: cli: only say sorry for in-snapcraft issues <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2646>
<ogra> micah, well, try it (the symlink creation) .. i'd also disable the rewrite unit then
<zyga> Re
<diddledan> I'm just installing Windows Insider build 18945 to see what the state of affairs is for snaps now that squashfs is in the shipped kernel
<zyga> diddledan: I'm running that
<diddledan> \o/
<zyga> diddledan: it's not enough but I read that some people managed to run systemd inside a hand-made container
<zyga> diddledan: and then run snapd inside that
<diddledan> yeah you need to trick systemd to believe it's pid1
<mup> PR snapcraft#2646 closed: cli: only say sorry for in-snapcraft issues <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2646>
<mup> PR snapd#7190 opened: tests: set GOTRACEBACK=1 when running tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7190>
<diddledan> snap version: https://www.irccloud.com/pastebin/VHgAuLOx/
<zyga> diddledan: neat
<zyga> diddledan: can you tell me more about how you got that?
<diddledan> start systemd with: $ sudo daemonize /usr/bin/unshare -fp --mount-proc /lib/systemd/systemd --system-unit=basic.target
<diddledan> find the process id of the unshare process and run $ sudo nsenter -t $SYSTEMD_PID -m -p /bin/login -f dllewellyn
<diddledan> then just `snap version`
<zyga>  mmm
<zyga> can you snap install xkcdwebserver and see it from windows?
<diddledan> seems to timeout accessing via either localhost or the wsl instance's ip
<zyga> diddledan: is the service up?
<diddledan> yup
<zyga> diddledan: it's a composite test that checks if many things together actually worked
<zyga> curious, ok
<zyga> thanks!
<zyga> is it on 80 or some other port?
<diddledan> systemctl status snap.xkcd-webserver.xkcd-webserver.service:  https://www.irccloud.com/pastebin/jhhaJwvU/
<diddledan> port 80
<diddledan> there also seems to be a mono service running but that's from the base image rather than via a snap
<diddledan> tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN      1289/mono
<diddledan> that _does_ respond
<diddledan> googler snap (cli for google searches) works
<diddledan> theloungeirc responds from windows on port 9000
<zyga> diddledan: neat
<diddledan> something specific to xkcd is failing tho
<zyga> maybe port 80 is just "busy" with windows stuff?
<diddledan> possibly
<mup> PR snapd#7191 opened: tests: remove installed snap on restore <Created by zyga> <https://github.com/snapcore/snapd/pull/7191>
<diddledan> aah, stopping and restarting the service with `snap stop` and `snap start` appears to have disloged the blockage (I was looking to see what the port did on windows side when it was stopped)
<diddledan> https://usercontent.irccloud-cdn.com/file/aB6fZBpA/image.png
<diddledan> that's coming from the snap in wsl2!
<ijohnson> diddledan: awesome work!
 * ijohnson relocates to coffee shop
<diddledan> what's the debugging command to get the confinement status of a system again?
<diddledan> i.e. to output what confinements the snapd is seeing as available for use
<diddledan> the one that shows the apparmor flags and stuff
<diddledan> aha. found it
<diddledan> https://www.irccloud.com/pastebin/w0UFjDgb/
<diddledan> doesn't support strict confinement yet then
<diddledan> $ snap debug confinement                                                                                     partial
<diddledan> https://www.irccloud.com/pastebin/EAFDkrva/
<zyga> diddledan: yeah, that's expected, apparmor is absent
<diddledan> ahem https://usercontent.irccloud-cdn.com/file/bjIkhr6T/image.png
<diddledan> from `snap install pick-colour-picker` :-)
<diddledan> it doesn't seem to want to respond to clicks tho
<zyga> diddledan: color pickers probably require X features that are not really emulated correctly on windows
<zyga> diddledan: very impressive though :)
<diddledan> calculator works tho: https://usercontent.irccloud-cdn.com/file/XLgwJBtA/image.png
<zyga> diddledan: how long did it take to start?
<diddledan> not long
<diddledan> I didn't really time it
<diddledan> trying to open it again made putty crash on a malformed ssh packet
<diddledan> something funky is happening that kills ssh
<diddledan> the same error occurs trying to open gimp (from snap)
<diddledan> I wonder if that's because I'm going through 127.0.0.1
<diddledan> which means Windows is proxying the ssh
<diddledan> yeah the localhost proxy that MS implemented is breaking SSH
<zyga> diddledan: you need putty for X redirection?
<diddledan> it's the easiest way to do it, yeah
<zyga> diddledan: can you "just" expose X over localhost and not over a unix socket?
<zyga> though not sure if that's supported for real
<zyga> but fun experiments regardless
<diddledan> no, the localhost proxy that allows Windows apps to access Linux sockets is one-directional - i.e. linux bound sockets are propagated to windows, but windows bound sockets aren't exposed to linux
<diddledan> you can probably do it over the network though, because it's "just a VM"
<zyga> ah, I see why ssh helps
<zyga> it sets up the pipe
<diddledan> to achieve that you'd need to expose your X11 server in windows to the network
<diddledan> yeah, ssh just makes it simpler
<mup> PR snapd#7188 closed: data/selinux: allow read on sysfs <Simple ð> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7188>
<mup> PR snapcraft#2647 opened: build providers: catch LXD socket error <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2647>
<diddledan> zyga: of course, no self-respecting Linux user would be without their WINE: https://usercontent.irccloud-cdn.com/file/Musm2Py9/image.png
<zyga> haha, so that's a wine app on windows?
<diddledan> it's a snap of wine running notepad++ which is a windows-only app running on wsl2 on windows :-p
<diddledan> I figured I hadn't seen enough of the movie Inception :-p
<zyga> diddledan: you should record this :)
<zyga> diddledan: it's neat
<diddledan> it's freaking bananas!
<diddledan> I tried a couple OpenGL games but the X11 server I'm using only supports OpenGL 1.4 and they all require OpenGL 2.0+
<diddledan> wat: editing windows and linux files from within a windows app running in linux: https://usercontent.irccloud-cdn.com/file/agBv7vhv/image.png
<diddledan> I'm confused
<mup> PR snapd#7192 opened: tests: Initial change to retry on external files download <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7192>
#snappy 2019-07-30
<mborzecki> morning
<mup> PR snapd#7193 opened: [WIP] cgroupsv2 spread run <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7193>
<mup> PR snapd#7194 opened: packaging: use %systemd_user_* macros to enable session agent socket according to presets <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7194>
<mborzecki> quick errand, back in 30
<mborzecki> re
<mborzecki> hmm 	fmt.Printf("aligninfo: %+v\n", aligninfo)
<mborzecki>     ...open /home/maciek/work/canonical/workspace/src/github.com/snapcore/snapd/cmd/snap/cmd_services_test.go: too many open files
<mborzecki> hmm some http.Response structs with no calls to rsp.Body.Close()
<mup> PR snapd#7184 closed: daemon: do not modify test data in user suite <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7184>
<mborzecki> and there's different --help output when running unit tests via go test or via a prebuilt test binary :/
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: we're leaking fds in unit tests
<mborzecki> pstolowski: and a lot
<mborzecki> pstolowski: ./snap.test -check.f TestSession -test.count=99999 is leaking ~50fds/s on my machine
<mborzecki> pstolowski: as in go test github.com/snapcore/snapd/cmd/snap
<pstolowski> mborzecki: oh /o\, nice discovery.. TestSession appears to be a new thing?
<mborzecki> pstolowski: fwiw, we were leaking fds before that too, just that now there appears to be more
<Talzzz> Hi all, I'm new to Snap and have some questions and will be very happy if you could help me to answer them.
<Talzzz> I'v also posted my question in Snapcraft community: https://forum.snapcraft.io/t/azul-jre-bundled-with-my-snap/12524
<Talzzz> Basically, as I understood it. Snap works similar to AppImage, it should come with all the dependencies bundled in the snap.
<Talzzz> So, when I create a snap package for a Java app I want the jre bundled in the snap and use java from there and not the one installed(if installed) in the system.
<Talzzz> Am I right?
<pstolowski> Talzzz: yes. this is relevant to your question: https://snapcraft.io/docs/java-applications
<pstolowski> Talzzz: i'm not familiar with building java-based snaps at all, but it seems to me that the gradle plugin does the magic
<mborzecki> pstolowski: ok, so http.Server.Shutdown() when passed a context.WithTimeout() does not work the way we think it works
<pstolowski> mborzecki: ah
<mborzecki> pstolowski: in SessionAgent.Stop() when passing a nil or background context, there's no fd leak
<pstolowski> mborzecki: so, we're leaking fds for real, not just in tests?
<mborzecki> pstolowski: in real world, shutdown is in the exit path, so the process will be wrapped up anyway
<pstolowski> mborzecki: good
<mborzecki> quick errand, back in 20
<mup> PR snapd#7195 opened: cmd/snap, usersession/agent: close http.Response body in tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<mborzecki> pstolowski: ^^
<pstolowski> mborzecki: ty! +1
<mborzecki> haha, and need to fix it :P
<mborzecki> pstolowski: force pushed
<pstolowski> mborzecki: hmm. i didn't spot the difference, perhaps i was looking at the new code already?
<mborzecki> pstolowski: https://github.com/snapcore/snapd/compare/88aba0a637d35b96a419f1f1f1018d411b8d9b9e..e6e95530470b25a7dc6fa3a336f541aa8901f0f8
<pstolowski> mborzecki: ah, this, very subtle ;)
<mborzecki> pstolowski: and the unit test job stalled
<mborzecki> more fixes clearly needed
<pstolowski> mborzecki: uhm... this is annoying. i'll look at reproducing this too
<mborzecki> pstolowski: try passing -timeout 5m to go test
<mborzecki> pstolowski: wondering wehether we should even use a graceful shutdown in user session
<Chipaca> mborzecki: is -timeout for one test, or for all of them?
<Chipaca> 'if a test binary runs for more than <timeout>'
<Chipaca> it isn't clear if 'go test ./...' counts as one binary or multiple
<Chipaca> :)
<Chipaca> i can test
<mborzecki> Chipaca: yeah, i think it's per package
<mborzecki> Chipaca: go test builds a *.test binary for each package
<Chipaca> yeah, if your change works, i guess it is :)
<Chipaca> also we can drop the silly 'go list | grep -v vendor' i think?
<mborzecki> Chipaca: well, it did get stuck on travis :/ so
 * Chipaca checks with 1.9
<Chipaca> actually that's >= 1.10 so it should just work with ./... directly
<Chipaca> hmm
<Chipaca> mborzecki: interestingly, why didn't you set -timeout for the 'short' run?
<Chipaca> surely that'd be the interesting one, to catch things fast
<mborzecki> Chipaca: missed that, force pushed now
<mborzecki> omg, and we actually run --unit-short on travis /o/
<Chipaca> :)
<Chipaca> yeah the 'go list | grep' trick is no longer needed with 1.9 either
<Chipaca> just tested :)
<Chipaca> but that's for another time probably
<mborzecki> https://paste.ubuntu.com/p/T5w4r43FSt/ locally with -timeout
<Chipaca> mborzecki: do you have the arch with 5.2 to hand?
<Chipaca> mborzecki: need to know the version of util-linux
<mborzecki> Chipaca: 2.34
<Chipaca> mborzecki: and systemd?
<mborzecki> Chipaca: 242
<Chipaca> ok
<Chipaca> thanks
<Chipaca> things move forward on the 'zany loop zaniness' front
<mborzecki> heh, so travis unit tests job is passing each time i restart it now
<Chipaca> sounds terrible
<mup> PR snapd#7196 opened: packaging: use passthrough for type:snapd <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<mborzecki> Chipaca: something fishy, osutil.RunWithContext() spawns a goroutine to call Process.Kill() when the context times out, just got a failure where there several terminal pages of runnable goroutines in that code
<Chipaca> mborzecki: is this with an insane -count ?
<Chipaca> maybe it's leaking goroutines?
<Chipaca> anyway RunWithContext should go
<Chipaca> (we've got contexts now)
<mborzecki> Chipaca: runnig in this way: 	waitDone := make(chan struct{})
<mborzecki> duh, wrong paste
<mborzecki> hile true; do echo "---------------------- $(date)"; GOMAXPROCS=1 GOTRACEBACK=all go test -count=1 -timeout 5m $(go list ./... |grep -v vendor |grep -v snap-seccomp) || break ; done
<mborzecki> at top of the tree
<mborzecki> Chipaca: just running to go test -count=insane inside osutil doesn't trigger it
<Chipaca> mborzecki: phew
<Chipaca> mborzecki: IIRC the goroutine sticks around until timeout
<Chipaca> mborzecki: which should be fine normally
<mborzecki> Chipaca: hm, but waitDone is closed earlier than that
<Chipaca> but, anyway, seriously stdlib now has exec.COmmandContext which replaces this
<Chipaca> anyway let me see
<mborzecki> Chipaca: is that in 1.9 too?
<Chipaca> mborzecki: 1.7+
<Chipaca> mborzecki: look at the right of https://golang.org/pkg/os/exec/#CommandContext
<Chipaca> mborzecki: with enough contention (e.g. in tests?) i could see some piling up here while it sorts things out
<Chipaca> mborzecki: ctx.Done() has a synchronizing mechanism which will be slow enough to appear
<Chipaca> mborzecki: unless you're telling me it died _because_ of the number of goroutines i wouldn't be alarmed
<mborzecki> Chipaca: heh, couldn't scroll back that far
<Chipaca> mborzecki: the unit tests for osutil alone fire off 76 of those fwiw
<Chipaca> no, 41, sorry
 * Chipaca is very good at counting
<mborzecki> Chipaca: omg https://travis-ci.org/snapcore/snapd/jobs/565388637 no backtrace in the log /o\
<Chipaca> and now i count 74
<Chipaca> mborzecki: ?
<Chipaca> mborzecki: line 1213?
<mborzecki> Chipaca: w8, there's one, maybe i opend the log page too early
 * Chipaca w8s, m8
<diddledan> 2l8
 * Chipaca hugs diddledan 
<diddledan> \o/
<mborzecki> goroutine 2440 [IO wait, 4 minutes]: heh, stuck in godbus read?
<diddledan> godbus!
<diddledan> public transport for heaven?
<mborzecki> go go dbus :)
<Chipaca> <sproing>
<cjwatson> via "go dbus go" I now have a "doo-doo-doo-doo-doo inspector dbus" earworm.  hope you're all happy
<Chipaca> cjwatson: snapd snap, doo doo doo doo doo doo
<mborzecki> Chipaca: fwiw, i don't see the goroutine that's supposed to send SIGUSR1 to the process, so it probably happened and it exited, but signal was not received?
<Chipaca> cjwatson: snapd snap, doo doo doo doo doo doo
<Chipaca> cjwatson: snapd snap!
<Chipaca> hopefully that got rid of the ear bug
<diddledan> cjwatson: https://youtu.be/zuq55zgXxHU
<Chipaca> diddledan: https://www.youtube.com/watch?v=XqZsoesa55w
<Chipaca> mborzecki: maybe it went to the wrong process?
<mborzecki> raising the bar: https://www.youtube.com/watch?v=wcibw-m8tRk
<mborzecki> Chipaca: golang, process signals & goroutines sounds like a bad mix
<Chipaca> https://lore.kernel.org/linux-block/f7e6717f-be46-1dfe-80ed-f85a18065c85@i-love.sakura.ne.jp/T/#m7b86e0c0f368ad6523c80b02bcd758d387a93a77
<Chipaca> fwiw
<Chipaca> bug understood, fix â¦ who knows
<Chipaca> mborzecki: why would you raise the bar, this was a fight to the bottom
<mborzecki> hahaha
<Chipaca> but, ok, let's raise the bar: https://www.youtube.com/watch?v=UMVjToYOjbM
<diddledan> this loop device racing is interesting. maybe ioctl(LOOP_CTL_GET_FREE) could lock the device it returns for the PID (and child PIDs?) calling the ioctl for a short period so that the next ioctl(LOOP_CTL_GET_FREE) gets a different device because the first one is locked
<Chipaca> continuing raising the bar, https://www.youtube.com/watch?v=6SFNW5F8K9Y
<diddledan> or maybe we need a different ioctl entirely that returns the loop number AND does what we're currently requiring a second ioctl for
<Chipaca> psh, locks, who needs those
 * diddledan throws away the key
 * Chipaca proposes https://www.youtube.com/watch?v=11GYvfYjyV0 not as a bar-raising but as a bar-mellowing thing
 * Chipaca just puts things on shuffle now
<mborzecki> pstolowski: Chipaca: can you take another look at https://github.com/snapcore/snapd/pull/7195 i've pushed a couple fixes
<mup> PR #7195: many: fix unit tests getting stuck <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<Chipaca> mborzecki: extra +1 for good fortune
<mborzecki> Chipaca: haha well https://paste.ubuntu.com/p/FnBhJbYYv7/
<mup> PR snapd#7197 opened: usersession: track connections to session agent for exit on idle and peer credential checks <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7197>
<cachio> mborzecki, hey
<cachio> nice forum post
<cachio> just a clarification
<cachio> the image is not fedora 30
<cachio> is fedora rawhide
<cachio> mborzecki, I created that based on our current fedora rawhide image (not useing the previous one)
<mborzecki> cachio: thanks for catching this, can you build one on fedora 30 too? just under a different name
<cachio> mborzecki, yes
<mborzecki> cachio: great, thanks!
<cachio> running process
<cachio> mborzecki, it should be ready in less than 30 minutes
<mup> PR snapd#7198 opened: tests: reboot the node when restoring after a test involving lxd <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<mborzecki> zyga: ^^
<Chipaca> cachio: good job on spread#82
<mup> PR spread#82: Introducing tags for the test which allows to filter executions <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/82>
<cachio> Chipaca, thanks!!
<Chipaca> not a +1 yet, but, yeah, good job
<cachio> Chipaca, :)
<cachio> Chipaca, I did it as simple as posible
<Chipaca> cachio: I can't stress enough how nice it is to see a new, useful feature be minimal so we can be sure it's useful before going crazy
<Chipaca> change that first useful to 'seemingly useful' for that sentence to make sense 100%
<cachio> Chipaca, nice!!
<cachio> Chipaca, and it has spread tests too :)
<Chipaca> yes :-)
<Chipaca> cachio: as noted the implementation can be made even simpler, at the code level (conceptually it's the same)
<cachio> Chipaca, thanks for the review, cheking it...
<Eighth_Doctor> zyga, preset request for new snapd user socket service: https://bugzilla.redhat.com/show_bug.cgi?id=1734371
<Eighth_Doctor> mborzecki: ^
<mborzecki> Eighth_Doctor: nice
<zyga> o/
<zyga> Eighth_Doctor: thank you
<mup> PR snapcraft#2648 opened: remote-build: include project name in build-id <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2648>
<Chipaca> ijohnson: hiya
<ijohnson> pstolowski: what was the issue with snapcraft 3.x and lxd/travis?
<pstolowski> ijohnson: i forgot the exact error message, but it was something about not being able to install core from /var/tmp/core.snap
<ijohnson> is there anyway for that test to remove the hacked core and just use the normal core snap when running snapcraft?
<ijohnson> ah I think I found the PR, it's 7092 right?
<ijohnson> err #7092
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x (2/4) <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
<pstolowski> ijohnson: 7092, correct
<pstolowski> ijohnson: the test it's not hacking the core, it's just trying to install snapcraft 3.x and build snapd snap (using lxd container as multipass doesn't work due to kvm extensions)
<ijohnson> right I understand why you can't use multipass, but I'm wondering why there aren't assertions for that core snap when it runs
<ijohnson> is it perhaps because a test that ran before this one installed an unasserted core snap?
<pstolowski> ijohnson: hmm, interesting idea
<ijohnson> the error here: error: cannot find signatures with metadata for snap "/var/tmp/core.snap" is not coming from snapcraft, it's coming from snapd inside the lxd container
<ijohnson> snapcraft is trying to be smart and re-use the core snap from the host (which in this case is a test VM), but there aren't assertions for that core snap for some reason
<alan_g> jdstrand_, I'm using review-tools.snap-review and getting "uncompressed snap is too large for available space (1160M > 1212M)". Is there a work-around?
<alan_g> nm, was just disc space and a weird "1160M > 1212M" claim
<pstolowski> ijohnson: ahhh, i see, sounds plausible
<pstolowski> ijohnson: i'll see if refreshing to proper core will help
<ijohnson> ack
<pstolowski> ijohnson: thanks for the insight!
<ijohnson> pstolowski: it looks like snapcraft will install the snap in the LXD machine with --dangerous only if the revision number starts with "x", otherwise it assumes it's able to download the .assert file as well as the .snap file from the snaps/${snap}/file snapd endpoint
<pstolowski> ijohnson: also, i've just noticed the comment/suggestion from jamesh (thanks!)
<ijohnson> right, yeah I think there might be a silently ignored error from snapcraft when it tries to copy the assertion file (which doesn't exist in this case) between the host and the container
<pstolowski> i'm trying destructive-mode first, that would be much faster thank lxd for our tests, if it works
<zyga> Hey
<zyga> How arÄ tyings?
 * cachio afk
<zyga> Chipaca, mborzecki, pstolowski anything interesting to report?
<Chipaca> zyga: unit tests hate us
<Chipaca> zyga: but, nah
<Chipaca> nothing on particular fire
<zyga> Chipaca: is that random hang understood better now?
<Chipaca> zyga: we think so
<Chipaca> zyga: not entirely solved yet though
<Chipaca> zyga: signals and threads are fun
<zyga> Chipaca: because of more coding required or because review/landing?
<zyga> Chipaca: indeed :)
<Chipaca> i'm not quite sure where it's at, mborzecki is on it
<zyga> Chipaca: any thread in the process can receive async signals, unless signalling a specific thread and unless sync signal is sent
<zyga> mborzecki: are you around?
<mborzecki> zyga: feel free to take a look at https://github.com/snapcore/snapd/pull/7195
<zyga> thank, you
<mup> PR #7195: many: fix unit tests getting stuck <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<Chipaca> zyga: the 5.2 mount issue is understood, and there's a patch
<Chipaca> zyga: that's also nice news
<mborzecki> zyga: both userd and session-agent use signals to know when to stop, and both tests (run one after another, but inside the same process) send signals to self to stop userd/session-agent
<zyga> Chipaca: excellent, that is indeed good news
<zyga> Chipaca: on the kernel side or on systemd side?
<Chipaca> zyga: kernel
<zyga> upstream or other?
<Chipaca> zyga: the 5.3 mount issue (affecting snapped lxd launching things) is https://lkml.org/lkml/2019/7/26/388
<Chipaca> zyga: upstream
<Chipaca> zyga: the 5.3 has a proposed patch fro al viro, which is probably as good as it gets, at https://lkml.org/lkml/2019/7/26/1441
<Chipaca> i havn't checked to see if that's in yet,
<Chipaca> .
<zyga> Chipaca: thanks, that's really good news
<zyga> mborzecki: I managed to get lucky and https://github.com/snapcore/snapd/pull/7190 is green
<mup> PR #7190: tests: set GOTRACEBACK=1 when running tests <Created by zyga> <https://github.com/snapcore/snapd/pull/7190>
<zyga> mborzecki: it switched the timeout to 5 minutes
<zyga> I think you did that in your branches as well
<zyga> mborzecki: so with the signal fix, do we know why unit tests failed in that PR?
<mborzecki> zyga: no, the test likely sends the signal to stop the agent, but the agent code continues as if there was no signal
<zyga> mborzecki: which signal is that?
<zyga> mborzecki: perhaps the test should fork and run in a separate process
<zyga> mborzecki: (and bridge the gap to the parent for reporting)
<zyga> mborzecki: or perhaps we should entirely mock that away for testing
<mborzecki> zyga: i changed  userd test to use SIGUSR1 and session-agent to use SIGUSR2, but same thing happens
<zyga> mborzecki: are those signals used by the go runtime or by the unit testing stack?
<mborzecki> zyga: go test has no functionality to run test as a process
<zyga> mborzecki: and do you know how exactly is go setting up the signal handling logic?
<mborzecki> zyga: options are, move session-agent and userd into separate pacakges (then they're run as separate processes), or mock away the signal bits
<zyga> mborzecki: I'm happy with both, please use your best judgment
<zyga> Chipaca: do you have preferences on how that should be done ^
 * zyga needs a trivial + 1 on https://github.com/snapcore/snapd/pull/7191/files
<mup> PR #7191: tests: remove installed snap on restore <Created by zyga> <https://github.com/snapcore/snapd/pull/7191>
<Chipaca> mborzecki: zyga: I'm OK with mocking the signal setup for tests
<zyga> Chipaca: +!
<zyga> +1 :)
<Chipaca> mborzecki: zyga: as long as we're sure that bit works :)
<zyga> in case this is not working today let's please revert the code for now or disable the test
<zyga> so that rest of master is not stuck
<mborzecki> zyga: left a note under https://github.com/snapcore/snapd/pull/7198
<mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<zyga> mborzecki: ah, that's cool
<zyga> if that's the case +1
<Chipaca> I need to hear back from samuele before doing more work on the refactor, so I'm going to step out now, and come back for a couple of hours after dinner
<zyga> mborzecki: commented in the lxd branch
<Chipaca> telegram me if you need me to come in before that :-)
<zyga> Chipaca: if you ask me a question I can relay
<Chipaca> zyga: i'm in communication with him
<zyga> +1
<Chipaca> zyga: but thank you
<zyga> great, thanks
<mborzecki> zyga: hmm, it failed on 16.04 only???
<zyga> I think it failed on other systems as well
<mborzecki> zyga: nope, 2019-07-30 12:02:48 Rebooting on jul301153-640125 (google:ubuntu-18.04-64:tests/main/lxd) as requested...
<pstolowski> ijohnson, jamesh: it worked in destructive mode!
<ijohnson> pstolowski: cool!
<ijohnson> hey Chipaca any chance you could comment on my model PR with what direction I should go? from SU I recall that device-key is wrong and it should be at the bottom and use "device-key: |\nblahblahblah", but I'm not sure what you would like me to do about the others
<diddledan> degville: I've just amended the docker and docker-support interface docs slightly. Can you check the wording is appropriate, for me, please? I edited the top-most line in each doc (https://forum.snapcraft.io/t/the-docker-support-interface/7810 and https://forum.snapcraft.io/t/the-docker-interface/7787)
<degville> diddledan: will do - thanks for making the updates.
<diddledan> cheers :-)
<ogra> diddledan, your indendation of the plugs is wrong
<ogra> (in your last forum post)
<diddledan> nuh uh
<diddledan> for lists you can do without the indentation
<ogra> oh ?
<ogra> i never tried ... heh
<diddledan> https://www.irccloud.com/pastebin/iIgMWTmF/
<diddledan> of course it gets confusing when you do: https://www.irccloud.com/pastebin/4h38icL2/
<diddledan> that's why I like to not indent the list so that an object is clearly delineated as being either incorrectly nested or a child of a list-item
<diddledan> s/object/hash/
<diddledan> hash/map
<diddledan> I good words do
<diddledan> what happened to the nice syntax highlighting/colouring on the forums?!
<ijohnson> it went away a while ago and nobody has added it back
<mup> PR snapd#7196 closed: packaging: use passthrough for type:snapd <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<ijohnson> diddledan: https://forum.snapcraft.io/t/code-block-syntax-highlighting-no-longer-works/11004/3
<diddledan> yeah, I don't get why it went away though
<mup> PR snapd#7191 closed: tests: remove installed snap on restore <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7191>
<mup> PR core-build#49 opened: initramfs: check keypress in run mode <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/49>
<mup> PR snapcraft#2647 closed: build providers: catch LXD socket error <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2647>
<mup> PR snapcraft#2649 opened: Release changelog for 3.7.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2649>
<jcrben> hi, coming here from suggestion at https://forum.snapcraft.io/t/network-manager-broken-for-desktop-ubuntu/12512/26?u=jcrben - does anyone know how to make a PR to update text in a store description, such as https://snapcraft.io/network-manager?
<mup> PR snapcraft#2649 closed: Release changelog for 3.7.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2649>
<diddledan> is it snapped yet? https://www.collabora.com/news-and-blog/news-and-events/moving-the-linux-desktop-to-another-reality.html
<ogra> jcrben, https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/ the text comes from the snapcraft.yaml ... but since you already talk to alfonso (who is the maintainer) you can probably just go on discussing changes to the text in the forum thread with him
#snappy 2019-07-31
<jcrben> @ogra: thanks, it's nice to know how things are populated!
<mborzecki> morning
<mborzecki> brb, new kernel
<mborzecki> re
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: great that you're around, can you take a look at the lastest patches in https://github.com/snapcore/snapd/pull/7195 ?
<mup> PR #7195: many: fix unit tests getting stuck <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<mborzecki> pstolowski: the unit tests job was green 6 times in a row
<pstolowski> sure, excellent!
<pstolowski> yay, #7092 is green \o/
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x (2/4) <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
<mborzecki> hm and so is #7195 :)
<mup> PR #7195: many: fix unit tests getting stuck <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<jamesh> pstolowski: glad --destructive-mode solved your problem
<pstolowski> jamesh: thanks, also for the latest remark re snapd base; we special-case snapd snaps not to pull any prerequisites (base) so it has no effect on snapd. but yes, this is unfortunate, build-base would be better. let's see what what pedronis and mvo think when they are back. thanks again!
<pstolowski> i'll actually go ahead and try to fix it in snapcraft
<mborzecki> and merged
<mup> PR snapd#7195 closed: many: fix unit tests getting stuck <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7195>
<mborzecki> quick errand, back in 30 or sth
<pstolowski> Chipaca: hey! do you have a moment to discuss an aspect of https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769 in a HO?
<mborzecki> re
<mborzecki> stray dogs are fun, idk why they keep coming to us
<Chipaca> pstolowski: yes, sorry i didn't see your message
<pstolowski> Chipaca: np; standup HO?
<Chipaca> sure
<Chipaca> hm, i guess rob is at toronto as well?
<mup> PR snapd#7199 opened: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <https://github.com/snapcore/snapd/pull/7199>
<pstolowski> Chipaca: ^
<Chipaca> ack
<mup> PR snapcraft#2650 opened: store: send snapcraft-started-at in push requests <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/2650>
<zyga> Hey there
<pstolowski> hey zyga, how are you? how is the sprint going?
<zyga> Hey, Iâm doing good
<zyga> The sprint is halfway there. There are some small changes but nothing major yet
<zyga> We are doing goodI think
<zyga> Look at the roadmap document
<zyga> If you have any questions please let me know
<pstolowski> Chipaca: one small annoyance with snap switch & #7199, added a comment, wdyt?
<mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <https://github.com/snapcore/snapd/pull/7199>
<Chipaca> pstolowski: 'snap' asks the api for the current snap and shows the channel from there
<Chipaca> pstolowski: see showDone in cmd_snap_op.go
<Chipaca> pstolowski: the same codepath for switch and refresh should it should be the same
<Chipaca> pstolowski: have you tested this IRL
 * Chipaca reaches for his clue-by-four
<pstolowski> Chipaca: nice, missed that. showDone is not currently used by "switch". yep, tested IRL
<Chipaca> pstolowski: switch does _not_ use showDonw?
<Chipaca> that's a bug :-)
<Chipaca> dang
<Chipaca> pstolowski: anyway, switch should either use showDone or call List to look up the current state... Â¯\_(ã)_/Â¯
 * Chipaca whistles innocently and hides the cluebat
<pstolowski> Chipaca: yep, sounds good, especially as we do that for others. And yes, switch doesn't use showDone yet :)
<pstolowski> Chipaca: ty
<Chipaca> pstolowski: seriously, sorry for the snark
<Chipaca> i need to do better than that
<Chipaca> maybe lunch will help
 * Chipaca takes a break
<mborzecki> this still still comes up occasionally https://paste.ubuntu.com/p/K6PPJnGTpS/
<pstolowski> Chipaca: no worries :)
<mborzecki> zyga: investigating #7198 because only logs from rebooting ubuntu-* machines are present, none from ubuntu-core, turns out, the test does not execute on ubuntu-core
<mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<mborzecki> zyga: ubuntu-core is listed in systems anyway, heh
<pstolowski> sergiusens: did anything change wrt --destructive-mode flag in snapcraft with latest release?
<pstolowski> ijohnson: so.. apparently --destructive-mode changed somehow (or got dropped / broken), it's not recognized anymore, also confirmed by #7092 spread test, which now fails. snapcraft just had new updates in all channels on Jul 30/31. i cannot spot anything about that in changelog/release notes though
<mup> PR #7092: packaging: use snapd type and snapcraft 3.x <Created by stolowski> <https://github.com/snapcore/snapd/pull/7092>
<ogra> pstolowski, have you tried SNAPCRAFT_BUILD_ENVIRONMENT=host instead ?
<ogra> (thats what i typically use in my lxd based builds)
<pstolowski> ogra: i didn't know it, let me try
<pstolowski> ogra: it seems to make snapcraft go into "legacy" v2 mode... and i need v3 feature
<ogra> it works fine if you use a base keywrd
<ogra> *keyword
<ogra> either base: core or base: core18
<ogra> then it will use v3 features
<pstolowski> ogra: ahh, right, that, forgot about it again!
<pstolowski> ogra: ahh, and this is actually what affects --destructive-mode flag
<pstolowski> thanks... so confusing
<ogra> heh
<pstolowski> in fact i was playing with base:, removed it for a moment
<pstolowski> sergiusens: nvm
<pstolowski> also ijohnson: mistery solved
<pstolowski> thanks ogra
<ogra> np
<ijohnson> glad you figured it out pstolowski
<zyga> mborzecki: hey
<zyga> mborzecki: do you need me to look at something?
<mborzecki> zyga: updated the list of tests that fail with cgroupsv2 on fedora 30 https://forum.snapcraft.io/t/snapd-with-unified-cgroup-hierarchy/12528/2?u=mborzecki
<mborzecki> zyga: and i'm open to ideas on why reboot via spread fails on 16.04 only https://github.com/snapcore/snapd/pull/7198
<mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<ijohnson> hey Chipaca, do you know what units the snapshot sizes from `snap saved` are in? is it megabytes (i.e. 10^6) or mebibytes (i.e. 2^20)?
<Chipaca> ijohnson: where?
<Chipaca> ijohnson: snap saved prints the units
<ijohnson> right it says `1.71MB`
<Chipaca> ah, sorry, now i read you
<ijohnson> but is MB megabyte or is it mebibyte
<ogra> marshmellow blobs ...
<zyga> mborzecki: Iâm in another meeting but I will try to inspe that
<Chipaca> ijohnson: mebibytes
<Chipaca> etc
<Chipaca> i think
 * Chipaca goes to check
 * Chipaca is terrible at context switching today
<Chipaca> ijohnson: it uses 1000s, not 1024s
<Chipaca> ijohnson: so, MB, not MiB
 * Chipaca relaxes
<ijohnson> Chipaca: got it thanks!
<diddledan> I prefer MH (Mega Hugs)
<diddledan> although I wouldn't be averse to MiH (Mega binary Hugs) over the innernets
<Chipaca> https://linux.slashdot.org/story/19/07/31/1348226/linus-torvalds-prepares-to-wave-goodbye-to-linux
<Chipaca> robert_ancell: hiya. I'd like to dig into how snapd-glib does the channels ops today, at some point
<Chipaca> robert_ancell: we're doing some slight shifts in semantics and are hoping we can do them without creating more work
<Chipaca> robert_ancell: maybe next week :)
<diddledan> that permalink gave me the entirely wrong perception of what the content was gonna be about
<Chipaca> diddledan: I might have done that intentionally, had I been evil
<robert_ancell> Chipaca, I'm in Toronto right now so this week is probably better overlap than next week when I am home.
<Chipaca> robert_ancell: I imagined you'd be busy and jet lagged this week
<Chipaca> robert_ancell: but, sure. Is your calendar up-to-date such that i could throw a meeting on there?
<Chipaca> robert_ancell: or would you rather do it?
<robert_ancell> Chipaca, we just finished the main desktop part so should be less busy for the rest of the week.
<Chipaca> robert_ancell: ah, good
<robert_ancell> Chipaca, yes, calendar should be up-to-date
<diddledan> there's a law that states anything that can be done in javascript eventually will be done in javascript. I think that can be adapted to anything that can run software will eventually be used to mine crypto currencies: https://www.phoronix.com/scan.php?page=news_item&px=Monero-Blackbird-Crypto-Mining
<Chipaca> robert_ancell: sent
<robert_ancell> Chipaca, ................accepted!
<Chipaca> shocking
 * Chipaca goes for some tea and something to nom
 * Chipaca out
<mup> PR core-build#49 closed: initramfs: check keypress in run mode <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/core-build/pull/49>
<mup> PR snapd#7200 opened: recovery: update to latest fde-utils <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7200>
<mup> PR snapd#7201 opened: GitHub not Github <Created by doismellburning> <https://github.com/snapcore/snapd/pull/7201>
<mup> PR snapd#7202 opened: tests: sync journal log before start the test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7202>
#snappy 2019-08-01
<mup> PR snapd#7201 closed: HACKING.md: GitHub not Github <Created by doismellburning> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7201>
<mborzecki> morning
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mup> PR snapd#7203 opened: i18n, vendor, packaging: drop github.com/ojii/gettext.go, use github.com/snapcore/go-gettext <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7203>
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7186 ?
<mup> PR #7186: gadget: ensure filesystem labels are unique <Gadget update> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7186>
<mup> PR snapd#7204 opened: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <https://github.com/snapcore/snapd/pull/7204>
<pstolowski> Chipaca: good morning! something for you sir ^
<pstolowski> mborzecki: will do
<Chipaca> pstolowski: nice. Will look in a bit.
<mborzecki> pstolowski: thanks
<mborzecki> Chipaca: morning
<Chipaca> mborzecki: mo'in
<mup> PR snapd#7175 closed: gadget: effective structure role fallback, extra tests <Gadget update> <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7175>
<mborzecki> is mvo the only one with write access to https://github.com/snapcore/go-gettext ?
<mborzecki> Chipaca: pstolowski: can you take a quick look at https://github.com/snapcore/go-gettext/pull/2 ?
<mup> PR go-gettext#2: Fix unit tests on hosts where /tmp is on a separate device <Created by bboozzoo> <https://github.com/snapcore/go-gettext/pull/2>
<mborzecki> anyways, wonder why this didn't come up earlier
<pstolowski> k
<Chipaca> mborzecki: we weren't running the unit tests of it i guess?
<mborzecki> Chipaca: or /tmp was on the same device as the source dir :/
<Chipaca> mborzecki: or they set TEMPDIR
<Chipaca> or is it TMPDIR
<mborzecki> Chipaca: or that ;)
<pstolowski> mborzecki: can you take a look at #7204?
<mup> PR #7204: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <https://github.com/snapcore/snapd/pull/7204>
<mborzecki> pstolowski: sure
<pstolowski> mborzecki: thanks
<mborzecki> hm weird, perhaps soemthing wrong with our spread images, this minimal task.yaml https://paste.ubuntu.com/p/B4ZBQc5pnT/ REBOOT fails on 16.04 but works on 18.04
<zigford> sorry, I asked this before, but my PC may have fallen asleep by the time I got a response. Anyone think of a reason why snapd 2.40 complains unless I add libncurses to the apparmor profile?
<Chipaca> zigford: complains how?
<zigford> 1 sec, it was about a week ago that I tested. I'll remove my entry and repro
<mborzecki> Chipaca: do you have any idea what could be wrong here? https://paste.ubuntu.com/p/988jjnTcw2/
<zigford> "/bin/sh: error while loading shared libraries: libncurses.so.6: cannot open shared object file: No such file or directory
<zigford> child exited with status 127"
<zigford> "apparmor="DENIED" operation="open" profile="/usr/lib64/snapd/snap-confine" name="/lib64/libncurses.so.6.1" pid=13806 comm="snap-device-hel" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zigford> "
<Chipaca> mborzecki: what am i looking at?
<Chipaca> zigford: what distro is this?
<zigford> Sorry, that's after running snap run packagename
<zigford> Gentoo
<mborzecki> Chipaca: a spread restore script, executed on 16.04, returning 1, same script run on 18.04 returns 213 (as expected)
<zigford> If I add an entry to apparmor.d snap-confine profile, the snaps run fine.
<Chipaca> mborzecki: why doesn't it have a shebang?
<zigford> Just wondering if something had changed in snapd that I need to account for in my snapd ebuild
<mborzecki> Chipaca: running bash script.sh gives the same result, 1 on 16.04, 213 on 18.04
<Chipaca> zigford: there is a libncurses entry in the apparmor profile of snap-confine, at least on master
<Chipaca> mborzecki: hmmmm
<Chipaca> mborzecki: does shellcheck say anything?
<mborzecki> Chipaca: nothing useful
<zigford> Chipaca: is it libncurses or libncursesw? the makefile that generated the profile has libncursesw not libncurses
<Chipaca> mborzecki: w
<Chipaca> although why it even has that is unclear to me
<Chipaca> er
<Chipaca> zigford: libncursesw
<Chipaca> zigford: actually, it used to have both i think?
<Chipaca> ec4f3c07746 added both
<zigford> Chipaca: curious. Guess the best bet might be to dig through the commits and see if/when/why it changed. I know Gentoo isn't supported, but I want to do my best to keep it running
<Chipaca> er
<Chipaca> mborzecki: the subshell
 * Chipaca pokes more
<mborzecki> Chipaca: strace is a bit confusing too https://paste.ubuntu.com/p/VrXKfhQhkf/
<mborzecki> Chipaca: notice how on 16.04 3359 exits with 213, but then 3358 exits with 1 :??
<Chipaca> mborzecki: so
<Chipaca> mborzecki: on 16.04
<Chipaca> ( foo )
<Chipaca> actually, let me double check that
<Chipaca> yes
<Chipaca> so
<Chipaca> mborzecki: on 16.04, given: boo() { exit 213; }
<Chipaca> mborzecki: and 'set -e'
<Chipaca> mborzecki: then ( ( boo ); ( echo hi ) )
<Chipaca> exits with 1
<Chipaca> mborzecki: replace the outer subshell-causing ()s with {}s and it exits with 213
<Chipaca> mborzecki: a workaround
<Chipaca> mborzecki: ( boo ) || exit $?
<Chipaca> so, two workarounds
<Chipaca> either replace the outer subshell with a group, or, explicitly re-raise the exit value
<mborzecki> Chipaca: yet, we still need to get the fix through spread :/
<Chipaca> mborzecki: when did this start breaking?
<Chipaca> what changed?
<mborzecki> Chipaca: noticed this in https://github.com/snapcore/snapd/pull/7198
<mup> PR #7198: tests: reboot the node when restoring after a test involving lxd <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7198>
<Chipaca> mborzecki: so I imagine the issue is that the restore is run in a further subshell, when compared to the test itself
<Chipaca> mborzecki: but I don't know, care to check that?
<Chipaca> the other REBOOT-using tests use it in the body afaik
<Chipaca> anyway I should make lunch
<Chipaca> and then, apparently, i need to go to the bank
<Chipaca> mborzecki: can you lead the standup if I don't make it back in time?
<mborzecki> Chipaca: sure
<mborzecki> Chipaca: commented out restore-each in my spread.yaml, https://paste.ubuntu.com/p/6MkKSf9sqy/
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: I'd call it a bug in bash :)
<mborzecki> Chipaca: yup, trying to find a bug report or a changelog entry
<mup> PR snapd#7204 closed: cmd/snap: use showDone helper with 'snap switch' <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7204>
<mborzecki> Chipaca: since it's fixed in newer version anyway :)
<zyga> Good morning
<zyga> Iâm sorry for not doing more last night
<zyga> I sent some reviews but didnât have time to work on blockers
<zyga> mborzecki, Chipaca what does reboot expand to?
<zyga> Is it the function or the executable
<zyga> Reboot returns 130 AFAIR
<zyga> Did you check what spread does to detect a reboot request?
<mborzecki> zyga: awe already know that set -e ( () () ) behaves differently in bash 4.3 and 4.4
<mborzecki> zyga: the bottom snippet here shows how the script looks like in the minimal test case that fails https://paste.ubuntu.com/p/6MkKSf9sqy/
<zyga> Bash, the bane of development :-(
<zyga> Thank you for digging
<zyga> I read that
<zyga> Did you see my question about command vs function?
<Chipaca> zyga: I don't think that makes a difference
<mborzecki> zyga: it's complicated, REBOOT is a function which echos <REBOOT> and exists with special exit code (213), the spread separately runs `reboot` command
<Chipaca> zyga: you can change the 'REBOOT' for a direct 'exit 213' and it still misbehaves
<Chipaca> mborzecki: REBOOT can also be tests/lib/bin/REBOOT which is what zyga is asking about i think
<zyga> mborzecki: we also unset the function and do the equivalent in a reboot command
<zyga> I wonder if that matters
<zyga> Yeah
<Chipaca> but, as i say, it's not the function, it's the double subshell followed by a subshell
<Chipaca> or as mborzecki said
<Chipaca> anyway why am i not making lunch
<mborzecki> Chipaca: i know, though i'm using a minimal task sample https://paste.ubuntu.com/p/B4ZBQc5pnT/ outside of your spread setup ;)
<mborzecki> zyga: ^^
<zyga> Ack
<Chipaca> zyga: with 'set -e', this: ( ( exit 213 ); ( echo hi ) )
<Chipaca> zyga: exits with 1
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> duh, bash git log is most useless :/
<mborzecki> (set -e ; ( ( exit 213 ) || exit $?; ( echo hi ) || exit $? ) || exit $? ); echo $?
<mborzecki> omg /o\
<mup> PR snapcraft#2651 opened: Extension confinement <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2651>
<mup> PR snapcraft#2648 closed: remote-build: include project name in build-id <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2648>
<mup> PR snapcraft#2650 closed: store: send snapcraft-started-at in push requests <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2650>
<mborzecki> cachio: standup?
<ijohnson> cachio: I talked to field and they said there's a ufw snap - would that work for you? if not, then iptables is included in network-manager, but there's no app exposed for it so you'd need to do `snap run --shell ...`
<cachio> ijohnson, nice, thanks, I'll try ufw snap
<ijohnson> +1
<cachio> and see if it works on the tests
<cachio> ijohnson, thanks!!
<ijohnson> if you have problems with it, blame ogra he recommended it to me so it's all his fault
<cachio> ijohnson, hehhe
<cachio> ijohnson, I'll do
<cachio> thanks
<ogra> ijohnson, cachio i'll pass that blame on to the owner of the snap .... jdstrand_ ;)
<mborzecki> what do we do with changes to spread? shall I open a PR?
<ogra> pstolowski, i'm just wondering, what happens to my hotplugged usb-serial device if i unplug and re-plug ... will the interface an app uses stay connected ?
<pstolowski> ogra: when you unplug the device, the interface gets disconnected and slot disappears from the system; when you plug it back, the connection is restored
<ogra> prefect, thanks !
<diddledan> funny: https://www.reddit.com/r/ProgrammerHumor/comments/btkri6/i_call_for_death_penalty/?ocid=AID740620_FACEBOOK_oo_spl100000841935315
<Chipaca> pstolowski: would you like to join the meeting about the channel vs risk thing?
<Chipaca> pstolowski: wrt snapd-glib and the semantics change
<pstolowski> Chipaca: sure
<Chipaca> pstolowski: ok, i'll add you to the invite
<Chipaca> it starts in ~3 :)
<pstolowski> Chipaca: ok, np
<Chipaca> man, i love short meetings of busy but smiling people
<pstolowski> haha
<pstolowski> Chipaca: thanks for overseeing this change & making Robert aware of it
<Chipaca> "overseeing" is a big label :-)
 * Chipaca adds "overseer" to his business cards
<pstolowski> lol
 * ogra senses the next holliwood movie "The Overseer - featuring J. Lenton as the overseer"
 * Chipaca upgrades his cash-raking rake
<robert_ancell> Chipaca, pstolowski I just noticed the current G-S code doesn't use the full channel names, but I was intending to change that (to match snapcraft.io). Either way this still shouldn't be an issue.
<Chipaca> robert_ancell: ð
<pstolowski> robert_ancell: good, ty
 * cachio lunch
<mup> PR snapcraft#2652 opened: meta: transparently support command-chain <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2652>
<mup> PR snapd#7205 opened: many: introduce security profile failsafe flag <Created by zyga> <https://github.com/snapcore/snapd/pull/7205>
 * cachio EOD
<amurray> kenvandine popey: fyi my lame attempt to get drawing snapped yesterday evening - https://github.com/alexmurray/drawing-snap
<kenvandine> amurray: I have one that's pretty close.  Needs newer things, which are in the gnome build snap
<kenvandine> amurray: which is still a WIP
#snappy 2019-08-02
<amurray> kenvandine: yeah I noticed it at least needs a newer PyGObject for Gtk.Template() but I didn't have much luck figuring out how to add that appropriately as a part (was messing around with the python plugin to try and use that but wasn't successful)
<kenvandine> amurray: i'll get it in the store soon
<amurray> kenvandine: nice - cheers
<mup> PR snapcraft#2652 closed: meta: transparently support command-chain <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2652>
<pstolowski> mornings
<mup> PR snapd#7196 opened: packaging: use passthrough for type:snapd <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
<zyga> Hello
<pstolowski> hey zyga
<Chipaca> #1838654 looks like fun
<mup> Bug #1838654: Snap completely broke <client> <crash> <snaps> <Snapcraft:New> <https://launchpad.net/bugs/1838654>
<pstolowski> amazing
<Chipaca> IKR
<mup> PR snapd#7206 opened: overlord/snapstate: use reflect to improve snapstate.Get <Created by chipaca> <https://github.com/snapcore/snapd/pull/7206>
<mup> PR snapd#7207 opened: snap: prevent duplicated snap name and snap files when parsing seed.yaml <Created by stolowski> <https://github.com/snapcore/snapd/pull/7207>
<Chipaca> ^^^ a bit of friday fun
<Chipaca> sigh, what's up with spread _now_
<Chipaca> pstolowski: did you check how your dupe checker worked from 'snap debug validate-seed'?
<Chipaca> pstolowski: also note image/validate_seed_test.go
<pstolowski> Chipaca: hmm, nope, will do, ty
<ijohnson> morning folks
<pstolowski> hey ijohnson!
<ijohnson> o/ pstolowski
<pstolowski> Chipaca: ValidateSeed calls ReadSnapYaml, so it's covered by the fix (and so is snap debug validate-seed)
<snapuser9> Hi guys, I have a quick question regarding access to /proc. Under flatpak apps such as Discord and Spotify have no access to /proc whatsover, however having made the switch to snap recently I realized that the same apps have access to /proc. As far as I know both Discord and Spotify have not been installed with the --classic flag so I was wondering
<snapuser9>  if this is intended? (If not then) Correct me if I am wrong but shouldn't access to /proc be limited because sensitive data could be read from there?
<pstolowski> Chipaca: but surely an extra test for cmd_debug_validate will not harm
<ijohnson> snapuser9: some snaps declare to use interfaces to access certain things inside /proc, so discord and spotify use some of those interfaces
<ijohnson> what interface depends on what exactly in /proc is desired to access
<Chipaca> snapuser9: access to proc is limited; is there anything the snap has access to that is sensitive?
<mup> PR snapd#7208 opened: cmd/snap, data/completion: improve completion for 'snap debug' <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7208>
<Chipaca> snapuser9: (it's not an all-or-nothing thing)
<mup> PR snapcraft#2651 closed: Extension confinement <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2651>
<ogra> roadmr, cjwatson, i just built a new gadget on build.s.io ... this rightly went into manual review ... yet ... build.s.io tels me "Built and released" and also tells me to "sudo snap install --edge <snapname>" ... i'm pretty sure former gadgets properly showed the store status on build.s.io
<popey_> ogra: there's a bug report link at the bottom of the page :)
<ogra> heh, k
<ogra> it says "we're hiring" though :)
<Chipaca> I'm going to be a minute late for the standup
<pstolowski> k
 * ogra files https://github.com/canonical-web-and-design/build.snapcraft.io/issues/1231
<Chipaca> ogra: while you're there you could re-file https://bugs.launchpad.net/bugs/1838718
<mup> Bug #1838718: Downloaded file is called "snaprcaft.yaml" instead of "snapcraft.yaml" <Snapcraft:New> <https://launchpad.net/bugs/1838718>
<ogra> Chipaca, ??
<ogra> ENOTMYBUG
<Chipaca> aw
<roadmr> adopt a bug â¤  ð·  â¤
<ogra> hah
<diddledan> EWHOCARES
<diddledan> EGOAWAY
<diddledan> :-p
<diddledan> no
<diddledan> oops
<roadmr> EHIDANHOWAREYOUDOINGTODAY
<diddledan> EERRORING
<diddledan> :-D
<diddledan> I'm good ta
<ijohnson_> ETHOSEARENTERRORS
<ogra> EHOWDOYOUKNOW ?
<ijohnson_> EERRORNOTANERROR
<diddledan> EIGAVEUPTHINKINGOFMEANINGFULERRORCONSTANTNAMESANDIDONTKNOWWHATTHISERRORACTUALLYIS
<diddledan> I love those errors, ijohnson_
<diddledan> "Unknown Error" is a great one, too
<diddledan> that's where the developer didn't have a clue what they were doing
<ogra> i still love "Error: success"
<tomwardill> "Unexpected Error" is also a hit
<diddledan> yes!
<diddledan> ogra: what about openSSL with their goto fail; on success?!
<ogra> haha, yeah !
<ijohnson_> we need more emojis in in error messages Eððððð
<roadmr> E ð¤®
<plars> Anyone know of a good way to convince squid to cache downloads from the snap store?  I've set up a simple squid server to try this, and done 'snap set system proxy.http(s)=...' to point it at my proxy, but when I download anything through the store, it doesn't seem to get cached.
<plars> no growth of the cache dir, no speedup on subsequent downloads. squid access log occasionally only logs something like: 1564751506.978  51166 192.168.2.96 TCP_TUNNEL/200 14198 CONNECT api.snapcraft.io:443 - HIER_DIRECT/91.189.92.20 -
<diddledan> plars: it might be uncached because it's an HTTPS request
<diddledan> you need to be intercepting requests for https://fastly.cdn.snapcraft.io
<plars> diddledan: that's what I was thinking, just curious if anyone had any luck getting squid to play nice with that sort of use case. I'm reading up on the ssl_bump stuff on squid which is kind of a terrifying mitm attack I think, and it could be workable if I can figure it out, but would probably take convincing snapd that the cert for squid is valid
<zyga> plars: snapd will detect mitm attacks
<zyga> plars: I think you could try setting up the enterprise proxy instead
<diddledan> that cost money tho
<zyga> plars: it's not transparent as you need to opt in but that's one way out
<zyga> diddledan: not for home use
<diddledan> aah ok
<plars> zyga: that's my backup plan, just trying to see if there's something more basic since I don't need any of the revision control stuff
<zyga> plars: I think that's the only thing that really works
<ogra> ..."opt in to way out" ...
<plars> zyga: kinda what I figured, thanks for confirmation
<diddledan> curiously, the fastly cdn is sending this header as part of its response: x-bzr-revision-number: 7464
<diddledan> I wonder what that's about
<zyga> dunno :)
<roadmr> diddledan: it's the revision number of the backing service on our side ;)
<diddledan> yeah I figured it was the django app
<roadmr> diddledan: think the commit id of the tree from which the code serving the snap was taken
<roadmr> plars: shit, sorry :( looks like my squid suggestion is bogus and you'll need the store proxy which is more aware of the content
<plars> roadmr: no worries, it was an interesting experiment, and it really is a *good* thing that snapd doesn't want to play nicely with that sort of thing. It would be troubling if it were easy to trick it into downloading some random thing from a proxy pretending to be the store :)
<zyga> plars: we'd still verify the assertions on the response so it'd be hard to trick anyway
<plars> yeah
<zyga> but at least snapd replies in clear and simple terms that MITM is in progress
<Chipaca> plars: snap-proxy is a thing
<snapuser9> Sorry for the late reply, I was thinking about something like retrieving window names (e.g. when in incognito mode of firefox) but apparently no such info is stored inside /proc but rather somewhere else? Chipaca ijohnson_
<Chipaca> plars: snap-store-proxy*
<roadmr> Chipaca: he knows; we were just wondering if a squid and a simple snap set system.http= would achieve the purpose of faster downloads for frequently-used snaps (he installs a lot)
<Chipaca> ah ok
<snapuser9> atleast I wasn't able to find anything inside /proc
<roadmr> Chipaca: we're going the store-proxy now :)
 * cachio afk
<ijohnson_> snapuser9: yeah I don't know where window names are stored but snaps shouldn't affect where that is stored, once you figure out what you need access to, feel free to start a forum post and we can try to help you out more
 * cachio lunch
<kenvandine> amurray: the drawing snap has been uploaded to the store awaiting manual review :)
<mup> PR snapd#7074 closed: interfaces: add gpio-control interface <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7074>
<diddledan> kenvandine: awesome!
<hellsworth> hi everyone, i'm new to snap and trying to package a simple gtk application but falling short and seeking some help.
<hellsworth> I've looked at several forum posts, existing gtk snapcraft.yaml files for examples, and tried lots of things.
<hellsworth> would it be best to put all the hairy details into a forum post?
<diddledan> hellsworth: might be worth a forum post. being that we've got the weekend just appearing in a few hours most of the canonical folk will be elsewhere till monday
<hellsworth> ah yes good point. a forum post it is then!
<amurray> kenvandine: approved (but perhaps too soon - I am seeing the following error: https://paste.ubuntu.com/p/wkhbcXKhzz/ )
<amurray> kenvandine: I'm about to board my flight home so will catch you next week - cheers
<kenvandine> Thanks
<kenvandine> amurray: safe travels
<mup> PR snapcraft#2653 opened: scriplets: run override-pull on update_pull <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2653>
#snappy 2019-08-03
<kenvandine> amurray: you will need to manually connect to gnome-3-32-1804 as the auto connection request hasn't been completed yet
<kenvandine> snap connect drawing:gnome-3-32-1804 gnome-3-32-1804
<amurray> kenvandine: one more for you https://www.reddit.com/r/gnome/comments/cl2qcd/simple_news_feed_reader_for_gnome_called_feeds/ ;)
<kenvandine> :)
<kenvandine> i knew that one was coming :)
<kenvandine> amurray: my connection is delayed... maybe i have time now :)
<amurray> kenvandine: so is mine - but I'll leave it to the expert ð
<amurray> kenvandine: it wasn't the interface connection that failed - it was snapd complaining it couldn't install it as a prerequisite since it didn't know the syntax.. do I need snapd from edge?
<kenvandine> no...
<kenvandine> i fixed that
<kenvandine> i thought i could use that syntax for the default provider
<kenvandine> i was wrong :)
<kenvandine> you need gnome-3-32-1804 from edge
<kenvandine> we should be able to publish that to stable in the next couple of weeks
<kenvandine> amurray: brand new and shiney stuff needed here :)
<amurray> kenvandine: hmm I installed gnome-3-32-1804 and then drawing installed :) but seems the connection for it doesn't work right: https://paste.ubuntu.com/p/Y8JWc5NKjf/
<amurray> kenvandine: back in a minute
<kenvandine> amurray: actually i'm going to wait on gnome-feeds.  it needs the Gir for libhandy
<kenvandine> which i'm going to add to the platform next week
<kenvandine> amurray: oh... snapd bug :)
<kenvandine> i think
<kenvandine> once you try to run it without the content interface connected
<kenvandine> connecting it doesn't seem to work
<kenvandine> zyga: ^^
<kenvandine> I noticed that tonight as well
<kenvandine> i think snap-discard-ns will fix it
<kenvandine> or... remove drawing, install drawing, connect the interface, then run it again
<kenvandine> amurray:  /usr/lib/snapd/snap-discard-ns drawing
<kenvandine> corner case, as usually snapd will automatically install the content snap and connect it for you.  But since the auto connection request is still pending, it doesn't
<amurray> kenvandine: huh weird (I had to reboot and it was magically fixed after that)
#snappy 2020-07-27
<mborzecki> morning
<mup> PR snapd#9054 closed: bootloader/assets: generate bootloader assets from files <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9054>
<jamesh> it's nice to see green ticks from CI again
<pedronis> yes
<pedronis> mborzecki: catching up on some things, and then I'll review 9006 first
<mborzecki> pedronis: thanks!
<mborzecki> Saviq: hey, multipass does not plug removable media?
<zyga> good morning
<mup> PR snapd#9060 opened: interfaces/bultin/multipass: replace U+00A0 no-break space with simple space <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9060>
<pedronis> zyga: hi
<zyga> hey pedronis
<zyga> sorry for starting late, it's extremely difficult to sleep lately
<zyga> only one day left though
<pedronis> zyga: how do you want to proceed, start cutting the release this morning, or in the afternoon? I can provide a cleaned up changelog
<zyga> pedronis: I would like to look at the release branch now, run tests manually, review the instructions from Mvo and get everything ready for early afternoon
<pedronis> zyga: ok
<pedronis> zyga: I can do the part of the instruction that is producing the changelong content and cleaning it up
<pedronis> zyga: ping me when you need that
<pedronis> zyga: thank you
<zyga> thank you, that will be most welcome
<zyga> 100 patches between 2.25.2 and release head
<mborzecki> zyga: anything unexpected there?
<zyga> mborzecki: nothing yet
<zyga> I forgot we did some interface changes backports
<zyga> most is just noise and test tweaks
<zyga> brb
<pedronis> zyga: the condesed and edited changelog from mvo tool is: https://gist.github.com/pedronis/c1577c450d53ff3c9fe3086447726232
<zyga> ack, looking
<zyga> nicely readable
<zyga> I've gone through all the patches and everything looks good
<zyga> I'll run tests two more times while reading mvo's instructions
<pedronis> mborzecki: did a pass on #9006, let me know if you have questions
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<zyga> one thing I found in the changelogs that we don't have in mvo's doc is the SRU tracking bug
<zyga> for 2.45 we used https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1875071
<mup> Bug #1875071: [SRU] 2.45 <id-5ef3c1ba59467589703d5ae0> <verification-done> <verification-done-bionic> <verification-done-eoan> <verification-done-focal> <verification-done-xenial> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <snapd (Ubuntu Bionic):Fix Released> <snapd (Ubuntu
<mup> Eoan):Fix Released> <snapd (Ubuntu Focal):Fix Released> <https://launchpad.net/bugs/1875071>
<zyga> but it seems to mention 2.45.1 as well
<zyga> I wonder if I should file a placeholder bug for 2.45.3
<zyga> first run: two tests failed in fedora
<zyga> well, centos and fedora
<zyga>     - google:centos-8-64:tests/main/selinux-clean
<zyga>     - google:fedora-30-64:tests/main/snap-run
<zyga> but worse, preparing arch failed entirely
 * zyga looks 
<mborzecki> zyga: ah, w8, there was a patch for zstd
<zyga> mborzecki: I think I saw one in the patches
<zyga> it's not that
<mborzecki> zyga: 4de033c77e742c166dd075fd5e9db507a99b17dc this one?
<zyga> https://paste.ubuntu.com/p/wdHDqkXFKy/
<mborzecki> zyga: hm that one i cannot fix
<zyga> yes, that patch is in the release
<zyga> heh, only on release day :)
<zyga> that looks like google's own arch repo?
<mborzecki> zyga: yeah, not sure where it's coming from
<mborzecki> tbh i didn't know there's one even
<zyga> different failure now
<zyga> Found unused ./vendor packages:
<zyga>  vu github.com/snapcore/secboot/internal/pe1.14
<zyga> Please fix via 'govendor remove +unused'
 * zyga looks
<mborzecki> zyga: pacman -Sy seems to work, so maybe there really is a repo, but it's only accessible form the nodes?
<mup> PR snapd#9060 closed: interfaces/builtin/multipass: replace U+00A0 no-break space with simple space <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9060>
<mborzecki> zyga: does it work now?
<zyga> now things pass
<zyga> mborzecki: it's weird, I removed vendor bits and ran tests without them
<zyga> why didn't any other system complain?
<mborzecki> zyga: i have no idea, arch should be using go 1.14.6 atm, maybe something about it
<zyga> mborzecki: about the other failures, the snap-run test hangs on strace sometimes so that's not new
<zyga> mborzecki: and the centos 8 selinux policy situation has not changed, correct?
<mborzecki> zyga: nope, i should fix that test sometime
<mup> PR snapd#9061 opened: packaging: add placeholder changelog for 2.45.3 <Created by zyga> <https://github.com/snapcore/snapd/pull/9061>
<zyga> changelogs are ready, I created a PR for the placeholder entry, I've cloned the trello card and I'm looking at the card now
<zyga> I don't think I've ever touched snapd translations on launchpad
<zyga> not sure if anyone knows how that operates
<mborzecki> zyga: mvo maybe (hopefully)?
<zyga> yeah, I wish I knew
<zyga> I think we should rotate this more often
<zyga> feels a bit "muscle memory"
<mup> PR snapcraft#3227 opened: meta: fix content slot to set content when using source key <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3227>
<zyga> brb
<zyga> re
<mborzecki> pedronis: about https://github.com/snapcore/snapd/pull/9006#discussion_r460764489 you mean the same such that the order stays unchanged, i.e. mode/system as specified last?
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<pedronis> mborzecki: the order yes, or anything else, formulated otherwise my question is whether the final command lines are changing or are the same
<pedronis> vs what we have on master right now
<mborzecki> pedronis: hm it does change, that's why i bumped the edition number to 2 initially
<pedronis> mborzecki: can you make a pastebin of old and new somewhere?
<pedronis> side by side
<mborzecki> pedronis: grub.cfg and recovery?
<pedronis> the command lines
<pedronis> for both
<mborzecki> pedronis: ok, let me look at the scripts again, this has changed a bunch of times during the reviews
<mborzecki> pedronis: heh, i was wrong, it changed twice in the course of reviews, at the end of the day it's the same as in master <mode> <static> <extra> (where <extra args> are a new thing and not used atm), see https://github.com/snapcore/snapd/pull/9006/files#diff-6f9b97376e62185c79af158d2d3c9474 and https://github.com/snapcore/snapd/pull/9006/files#diff-d3f0c595846626e6f78fe9b29f0a61e6
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> pedronis: that diff chunk in boot is caused by a fix in bootloadertest mocks
<pedronis> mborzecki: good, my impression was also that in the end the result was the same
<mborzecki> pedronis: while at it, i'll tweak the interface to have CommandLine(mode, system, extraArgs string)
<pedronis> sounds good
<pedronis> mborzecki: to be clear mode and system there  are full "name=value", right?
<mup> PR snapcraft#3228 opened: review tools: fix snap link or copy path <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3228>
<mborzecki> pedronis: yes, just like in the PR now, the only difference is the call will be eg. CommandLine("snapd_recovery_mode=recover", "snapd_recovery_system=123123", "arg=1 other=2")
<pedronis> thx
<mborzecki> pedronis: and grub bootloader implementation verifies snapd_recovery_mode= and snapd_recovery_system= prefixes
<cmatsuoka> mborzecki: the extra args in cmdline should come only from gadget or also from system settings?
 * zyga just got the call
<zyga> 12:30 tomorrow
<zyga> finally
<mborzecki> cmatsuoka: gadget for now, i recall we discussed some system args, but so far only gadget was something we though would happen
<cmatsuoka> ok. I asked because system settings is mentioned once in the doc intro but there are no details about that
<zyga> brb, see you at the standup
<mborzecki> zyga: nice, feeling anxious?
<zyga> no, just wish it was tomorrow already
<mup> PR snapd#9062 opened: releasing package snapd version 2.45.3 <Created by zyga> <https://github.com/snapcore/snapd/pull/9062>
<mup> PR snapd#9061 closed: packaging: add placeholder changelog for 2.45.3 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9061>
<pedronis> zyga: sorry I was confused, obviously edge builds from master normally, but there is this: https://launchpad.net/~snappy-dev/+snap/snapd-2.45
<zyga> ah, nice, it goes to beta directly
<zyga> and it builds automatically
<pedronis> it goes to a branch of beta to be clear
<zyga> hmm, right, I see that now
<pedronis> zyga: and there's https://launchpad.net/~snappy-dev/+snap/core-beta
<pedronis> for core
<pedronis> that one is manual though
<zyga> and this one is built on request, so we can trigger when the ppa is ready
<pedronis> yes
<pedronis> you can trigger the other one as well if needed
 * zyga breaks for 30 minutes for meds and lunch
<pedronis> zyga: lp:snapd will need to be imported though for snapd build to work with the right version
<ijohnson> pedronis: uc20 status meeting ?
<pedronis> omw
<mborzecki> pedronis: cmatsuoka: i've updated #9006
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<pedronis> mborzecki: looked, did you see this comment: https://github.com/snapcore/snapd/pull/9006#discussion_r460770887 ? is that something we should discuss?
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mup> PR snapd#9062 closed: releasing package snapd version 2.45.3 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9062>
<pedronis> zyga: I triggered a repo import for that ^
<zyga> thank you
<zyga> I tried looking at the patch for git-buildpackage, it's a bit unfortunate that we have to carry it
<pedronis> zyga: https://code.launchpad.net/~niemeyer/snapd/+git/snapd
<zyga> 2.45 is still at the code from a few days ago
<pedronis> zyga: yes, look, it's says an import will run soon
<pedronis> it doesn't start immeditately
<zyga> yeah, refreshing the page shows stuff is changing
<zyga> "Repository scan failed"
<zyga> clicking the rescan button
<zyga> not allowed
<zyga> fun
<zyga> I guess
<zyga> what does that even mean?
<zyga> git import into launchpad database?
 * zyga asks on #launchpad
<pedronis> zyga: the import says it worked, but the branches aren't updated yet
<pedronis> ijohnson: are you blocked on reviews by me?
<zyga> the pain is under control now, I'll get some tea and be back soon
<ijohnson> pedronis: no not at the moment
<ijohnson> pedronis: sorting out some things locally then I will push to pawel's debug seeding branch for the devicestate changes then open another PR with the command itself
<pedronis> ijohnson: ok, thx
<zyga> it worked now
<pedronis> zyga: snapd:release/2.45 is up to date on LP now
<zyga> yep
<pedronis> thee snapd-2.45 should start on its own soon
<pedronis> *the snapd-2.45 build
<zyga> I
<zyga> I'll dput to the ppa now
 * cachio lunch
<zyga> lintian says we're a bit rusty on various details
<zyga> but that's fine
<mborzecki> zyga: which package isn't? :)
<zyga> mborzecki: hey, my toy package is clean like a ... clean package
<zyga> dput complete
<zyga> sorry I took forever, I kept struggling with gdp
<zyga> *gbp
<pedronis> zyga: so my theory was wrong, we have snapd snaps but they have ugly versions
<pedronis> zyga: did you create the wrong kind of tag? or wasn't it pushed?
<pedronis> I don't see the tag if I grab release 2.45
<zyga> hmmmmm
<zyga> I opened a PR but that didn't carry the tag!
<zyga> I guess I can just push it now
<mborzecki> zyga: you need to push the tag
<zyga> done
<mborzecki> and it's there
<zyga> I'm sorry, I entirely missed that the tag is a separate entity
<zyga> we need to rebuild the snap now, right?
<mborzecki> hm it ended up on a weird commit, but i guess this is not a problem
<pedronis> zyga: not sure, I'm still getting weird versions
<pedronis> zyga: no, I fear how the tag was attached matters
<pedronis> I get the right version if I go to the tag commit but I can the wrong one if I go to the tip of release/2.45
<zyga> hmmmm
<zyga> I suspect I know why
<zyga> mvo pushes that to release directly
<zyga> I could not
<zyga> so I created a merge PR
<zyga> so we have a new commit
<pedronis> let me see if I can do something
<zyga> ok
<zyga> do we need another lp import?
<pedronis> I haven't solved the problem, I'm not entirely sure how mvo pushes to those branches
<zyga> maybe he has extra permissions
<zyga> next time we should record mvo doing all those things and discuss the details
<zyga> ppa is still building
<zyga> ah no, status was stale
<zyga> it failed
<zyga> on aarch64
<zyga> on unit tests
<ijohnson> pedronis: https://github.com/snapcore/snapd/pull/9035 is now ready for you to review
<mup> PR #9035: o/devicestate: save seeding/preseeding times for use with debug seeding api (3/N) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9035>
<zyga> TestClientTimeoutLP1837804
<zyga> ... error string = "cannot communicate with server: Post http://127.0.0.1:40893/: dial tcp 127.0.0.1:40893: i/o timeout"
<zyga> ... regex string = ".* timeout exceeded while waiting for response"
<pedronis> zyga: now it should work, forced pushed to 2.45 the commit with the tag, instead of the merge
<zyga> great
<pedronis> zyga: please double check that 2.45 is sane
<zyga> so now we need another lp import
<zyga> sure, doing so now
<pedronis> yes
<zyga> scheduled one just now
<pedronis> thx
<zyga> did you force push the tag?
<zyga> I'm looking at https://github.com/snapcore/snapd/commit/b055d1902de062efe536f2c3f7dd7d2a35db2c61
<pedronis> zyga: the tag is there: https://github.com/snapcore/snapd/tree/2.45.3
<zyga> ah, it's just UI that confused me
<zyga> ok
<pedronis> ijohnson: thanks, I'll try to look still today
<ijohnson> pedronis: thanks, also https://github.com/snapcore/snapd/pull/9063 is the next one which is the snap debug command bit
<mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
<ijohnson> (which should be the last bit, I included the spread test bit there too, it's fairly small, but if you prefer I can make the spread test another PR)
<zyga> oh, ijohnson, can you look at https://github.com/snapcore/snapd/pull/9057 please - I removed the environment entry, it was unjused anyway
<mup> PR #9057: overlord: use new tracking cgroup for refresh app awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/9057>
<zyga> *unused
<mup> PR snapd#9063 opened: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
<ijohnson> zyga: sure, I have an in progress review I kept getting distracted from :-)
<zyga> OK
<pedronis> ijohnson: added to my queue
<ijohnson> zyga: and in case I don't get a chance to say it before tomorrow, good luck tomorrow! really hoping things go well for you
<ijohnson> thanks pedronis
<ijohnson> I will address some feedback and do reviews now, but then I will look into the re-exec bug for preseeding then
<pedronis> zyga: I requested a manual build of the snap
<pedronis> zyga: snapd is building now
<zyga> great, the lp import has succeeded as well
<ijohnson> zyga: +1d
<zyga> woot
<zyga> thank you
<ijohnson> no, thank you for sticking with this, we're really close I think :-)
 * zyga listens to the thunder and rain outside
<zyga> ijohnson: and before the anniversary
<zyga> of the v2 branch at least :)
<ijohnson> :-D
<zyga> once this lands the rest is just code removal
<zyga> and some misc changes unrelated to this feature
<zyga> the versions now look good
<zyga> on the beta/2.45 branch that is
<zyga> the ppa is still building for some architectures
<zyga> once that is done we should trigger https://launchpad.net/~snappy-dev/+snap/core-beta
<zyga> I will break for an hour and come back
<zyga> need to double check my hospital bag
<zyga> and see what's going on at home
<mup> PR snapcraft#3229 opened: errors: introduce HostToolNotFoundError exception <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3229>
<cachio> ijohnson, hey
<ijohnson> hi cachio
<ijohnson> I was just about to break for lunch
<ijohnson> (just fyi)
<cachio> do you know what happens during initial boot after the line systemd[1]: Started Journal Service.  --> https://paste.ubuntu.com/p/cBK2cnG6NR/
<cachio> ijohnson, I se most of the random reboots after that line
<cachio> ijohnson, np
<ijohnson> cachio: looking quickly
<cachio> ijohnson, also after line systemd-journald[185]: Received client request to flush runtime journal.
<ijohnson> cachio: I think that just happens to be one of the last things that systemd will do before starting up snapd, etc.
<ijohnson> I don't think what is triggering those lines specifically would be what is causing the random reboot
<ijohnson> but I dunno maybe it is
<cachio> ijohnson, so then snap starts
<ijohnson> cachio: but now immediately after that point
<ijohnson> cachio: but not immediately after that point
<cachio> ijohnson, ok
<ijohnson> I have some ideas for more debugging, but I need to break for lunch now
<cachio> ijohnson|lunch, is it any way to see a log with that info?
<cachio> after that line in the log that I got from the nested vm I see
<cachio> [   14.067916] systemd-journald[539]: Received client request to flush runtime journal.
<cachio> cmatsuoka, any idea?
<mup> PR snapcraft#3228 closed: review tools: fix snap link or copy path <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3228>
<mup> PR snapcraft#3230 opened: lifecycle: check for snap using shutil.which() <enhancement> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3230>
<cmatsuoka> let me see...
<cmatsuoka> cachio: this is the entire log, and the system crashed after that?
<cachio> cmatsuoka, after that the system works well
<cachio> this is the full log
<cmatsuoka> but when it crashes, it crashes at that point after userspace is running, is that correct?
<cachio> [   62.115886] systemd[1]: Starting Remount Root and Kernel File Systems...
<cachio> [   62.154860] systemd[1]: Starting udev Coldplug all Devices...
<cachio> [   62.201278] systemd[1]: Finished Create list of static device nodes for the current kernel.
<cachio> [   62.237719] systemd[1]: modprobe@drm.service: Succeeded.
<cachio> [   62.263067] systemd[1]: Finished Load Kernel Module drm.
<cachio> [   62.275837] systemd[1]: Started Journal Service.
<mup> PR snapcraft#3227 closed: meta: fix content slot to set content when using source key <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3227>
<cachio> after that line at some point it crashed
<cmatsuoka> maybe addming something like systemd.log_level=debug systemd.log_target=console to the cmline could help?
<cachio> cmatsuoka, but not log
<cachio> cmatsuoka, is it possible to update the command line with tpm and secboot enabled??
<cmatsuoka> hmm, you would need to add the parameters to the cmdlines used in sealing too
<cmatsuoka> unless it crashes before you unlock the encrypted device
<cmatsuoka> in this case you could boot with any cmdline
<cmatsuoka> but you won't be able to go past beyond the writable fs mount
<ijohnson> cmatsuoka: cachio: what I was going to propose is a test PR that changes the cmdline everywhere to include taht systemd.log_level kernel cmdline just to see the boot log
<ijohnson> I presume it happens every time so opening a PR with "run nested" label should be enough to trigger it and get some more representative logs
<cachio> ijohnson, ok
<ijohnson> the other issue is that if it is crashing instead of rebooting, we may lose some of the logs as they don't get flushed to GCE in time
<cmatsuoka> ijohnson, cachio: having an instrumented PR is probably the way to go
<ijohnson> cachio: I will send a PR then
<cachio> nice
<cachio> thanks
<ijohnson> cmatsuoka: do you know if it's sufficient to change the kernel cmdline inside snapd now with mborzecki's changes, or do I still need to make changes to the gadget grub.cfg ?
<ijohnson> cmatsuoka: I don't know how far along mborzecki's changes are
<cmatsuoka> ijohnson: uuuhm, I don't know if mborzecki's changes are already effective
<cmatsuoka> if not, the hard-coded cmdline is in gadget/install/install.go
<ijohnson> I think they might be effective already, I tried something similar late last week and found that snapd was writing the grub.cfg
<cmatsuoka> at some point last week I had to change the hardcoded cmdline, but I don't know if I had master merged in that PR
 * cmatsuoka checks 
<cmatsuoka> ah, I think you're right, in my test I edited the bootloader line by hand
<cmatsuoka> (it was a local test, not a test PR)
<cmatsuoka> I have a local branch where I changed the hardcoded lines with calls to maciek's command line building, hence the confusion
<mup> PR snapd#9064 opened: .github/workflows: move snap building to test.yaml as separate cached job <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
<mborzecki> zyga: how's it going?
<zyga> mborzecki: let me chcek
<zyga> builds were going
<mborzecki> nice, ijohnson opened https://github.com/snapcore/snapd/pull/9064
<mup> PR #9064: .github/workflows: move snap building to test.yaml as separate cached job <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
<ijohnson> hey mborzecki
<ijohnson> question on your grub.cfg stuff
<mborzecki> zyga: and upstream monitoring already opened https://bugzilla.redhat.com/show_bug.cgi?id=1861024 for the update
<ijohnson> how much of that is operational right now ?
<ijohnson> i.e. if I wanted to change the kernel cmdline that a uc20 system is booted with for debugging, can I just change the grub.cfg and the internal edition snippet in snapd Go code, or do I still need to make some changes to the gadget's grub.cfg ?
<mborzecki> ijohnson: in what sense? grub.cfg (and recovery) is already written from snapd
<zyga> https://launchpad.net/~snappy-dev/+snap/snapd-2.45 is building again
<zyga> hmm
<ijohnson> mborzecki: right so that should mean that if I build a fresh uc20 image with snapd from master with my modified kernel cmdline, it should be used and sealed against, correct ?
<mborzecki> ijohnson: soo, https://github.com/snapcore/snapd/pull/8947 hasn't landed yet, so an update won't happen
<mup> PR #8947: many: update managed boot config when refreshing snapd <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8947>
<ijohnson> mborzecki: but for a new install
<ijohnson> no updates
<mborzecki> ijohnson: iirc the sealing code in gadget/install.Run is still using the harcoded cmdline
<cmatsuoka> mborzecki: it is, I'm updating it now
<ijohnson> mborzecki: ah good point yes I will have to change that too, but I was more wondering about the grub.cfg's that get written out to disk, if the recovery or ubuntu-boot grub.cfg's from the gadget are used anymore at all
<zyga> mborzecki: yeah, I got that
<zyga> fedbus is nice
<mborzecki> ijohnson: so with #9006 landed, we'd still need a change for the install.Run()
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> cmatsuoka: cool, no issues so far?
<cmatsuoka> mborzecki: I just updated the code and will boot an image to see if it works as expected
<zyga> I wonder when I should click https://launchpad.net/~snappy-dev/+snap/core-beta
<mborzecki> ijohnson: then with claudio's change, if you use custom snapd with `dangerous system.debug-shell=1` added to snapd_static_cmdline and the snippet it should work
<mborzecki> ijohnson: and you need to edit both the snippet in bootloader/assets/grub.go and bootloader/assets/data/grub{.cfg,-recovery.cfg} because we've decided against extracting the static bits during build time
<ijohnson> mborzecki: so do I need 9006 for a fresh install / first boot ?
 * ijohnson feels like the answer is no
<mborzecki> hmm i think no
<mborzecki> ijohnson: though i would not mind if you tried with 9006 :)
<ijohnson> mborzecki: haha ok I will try with 9006
<mborzecki> ijohnson: this and the branch cmatsuoka is working on
<ijohnson> mborzecki: well for the branch cmatsuoka I just made the kernel command line I need show up everywhere manually
<cmatsuoka> mborzecki: I got a "not implemented" error in master, is that expected?
<ijohnson> so the install code doesn't pull it dynamically yet it just happens to still be the same :-)
<mborzecki> cmatsuoka: ah yes, so you need 9006 too
<cmatsuoka> mborzecki: ok
<pedronis> mborzecki: I commented a bit more: https://github.com/snapcore/snapd/pull/9006#discussion_r461075416 , we can chat in the morning if needed
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> pedronis: ok, thanks
<mborzecki> pedronis: haha, ok i see what you mean now and understand why we seem to have different ideas as to what the thing does, let's chat in the morning
<pedronis> mborzecki: remember that we need to be able to know what to expect at the next boot before writing things to disk
<mborzecki> pedronis: yes, i wanted to have a separate call for that, something like CandidateCommandLine() with the same fingerprint, that would use the edition number from the internal asset rather than the disk
<mborzecki> anyways, let's chat in the morning
<mup> PR core20#78 opened: hooks/900-cleanup-etc-var.chroot: rm cloud-init config file which we don't want <Created by anonymouse64> <https://github.com/snapcore/core20/pull/78>
<cmatsuoka> mborzecki, ijohnson: I'll have to debug a little bit here, unlocking failed
<ijohnson> cmatsuoka: my nested run is still going, not sure how far along it has gotten tbh
<ijohnson> it's been here for 5 minutes now
<ijohnson> 2020-07-27 13:15:48 Preparing google-nested:ubuntu-20.04-64:tests/nested/core20/ (jul271804-169453)...
<mup> PR core18#166 opened: hooks/900-cleanup-etc-var.chroot: rm cloud-init config file which we don't want <Created by anonymouse64> <https://github.com/snapcore/core18/pull/166>
 * zyga is unsure what to do with the release now, sorry, my mind is all messed up 
<pedronis> zyga: we have snapd in beta/2.45
<pedronis> zyga: did the package build in the ppa?
<zyga> yes, I think so
<zyga> yes, for all arches now
<zyga> I can see the beta/2.45 branch builds as well
<zyga> I should push those over to beta
<mborzecki> zyga: btw. do you have permissions to upload the source tarballs to releases page on github?
<pedronis> zyga: the changelog looks like from master though
<pedronis> in the ppa, bit confused
<zyga> mborzecki: let me check, I don't know for sure
<zyga> I think everyone does
<zyga> I do
<pedronis> zyga: if you look here: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages the changelong is weird
<pedronis> it has the placeholder
<zyga> it is the placeholder, because that's the package that was built from master, not from the release
<cmatsuoka> mborzecki: I can retrieve the recover mode cmdline correctly, but the run mode cmdline is returning empty for some reason
<zyga> that's step 8 from https://docs.google.com/document/d/1BCOwqjdUZIg-3x9E8iyojUW_P-ZJJjG0fFLeaDZbp5A/edit#
<pedronis> zyga: which one is the one for the release?
<zyga> pedronis: only snapd.snap is correct at this point
<pedronis> zyga: do we understand how to build a correct core?
<ijohnson> mborzecki: cmatsuoka: my nested run finished, it seems that we still need to modify the gadget grub.cfg, my changes only took effect for run mode
<ijohnson> which is fine, I can do that
<zyga> I'm confused about that - way back when I last did this it was built from the ppa directly but that has changed in ways I didn't follow since
<zyga> so back then a dput to that ppa was to provide the actual new snapd
<mborzecki> cmatsuoka: hm, can you check that ubuntu-boot contains the right grub.cfg that matches what's in 9006?
<zyga> I think the instructions are not complete and we're missing something
<zyga> hmm
<zyga> the beta/2.45 branch is wrong as well
<pedronis> zyga: also why would image build from master? I though edge built from master
<zyga> not sure why, maybe it's just broken
<zyga> snap    2.45.3
<zyga> snapd   unknown
<zyga> that's what's in that branch
<cmatsuoka> mborzecki: I don't think we had any recent modification to that file, but I'll check
<mborzecki> cmatsuoka: actually /run/mnt/ubuntu-boot
<zyga> I don't know
<pedronis> zyga: I installed the snapd from the branch and it looks correct here
<pedronis> snap    2.45.3
<pedronis> snapd   2.45.3
<pedronis> series  16
<pedronis> ubuntu  20.04
<pedronis> kernel  5.4.0-42-generic
<zyga> oh wait, perhaps it's my local config
<mborzecki> cmatsuoka: there should be a header, `# Snapd-Boot-Config-Edition: 1`
<zyga> yes sorry
<zyga> I've disabled it for development
<zyga> it's not broken, uff
<ijohnson> mborzecki: w/o 9006, I see that in the /run/mnt/ubuntu-boot grub.cfg
<zyga> I think this is wrong though
<ijohnson> mborzecki: but I don't see that in grub.cfg for /run/mnt/ubuntu-seed for example
<zyga> it's just the 2.45.3 version
<zyga> if you follow the manifest
<zyga> it leads here https://launchpad.net/~snappy-dev/+snap/snapd-2.45/+build/1060861
<pedronis> zyga: anyway you put a snapd into /image and there is only a snapd package build there
<zyga> ah, that's correct
 * ijohnson tries with more hacks to patch grub.cfg from the gadget in nested.sh
<pedronis> zyga: so still not understanding why it built from master
<zyga> sorry, I'm paranoid that it's all broken now
<zyga> the snap in the branch is correct
<pedronis> yes
<cmatsuoka> mborzecki: I have "# Snapd-Boot-Config-Edition: 1" in the first line there
<pedronis> we need to understand the ppa
<pedronis> s
<pedronis> I thought that master built into edge, not image
<zyga> the ppa contains a changelog bump
<zyga> but I think that's only for subsequent edge builds that inherit that somehow
 * zyga look at the PPA
<mborzecki> ijohnson: have you installed new snap command and built an imag with it?
<ijohnson> mborzecki: I just discarded the instance and I'm trying a fresh run with patched gadget snap
<ijohnson> mborzecki: I just ran the nested spread test
<zyga> pedronis: I think the instructions are wrong, we should dput a real .3 to the ppa or this makes no sense
<ijohnson> mborzecki: although good point, maybe the nested spread test needs to be updated to point ubuntu-image at an updated snap command from the spread branch
<pedronis> zyga: sorry, I thought that were the instructions, put a real .3 into the ppa
<pedronis> are we reading them differently
<pedronis> ?
<zyga> pedronis: Go to the master branch and create a debian/changelog with a placeholder entry for 2.46 to ensure the next âppa:snappy-dev/edgeâ build has the right version number
<pedronis> yes
<zyga> gbp doesn't run from the release branch
<pedronis> that's edge
<zyga> yes
<pedronis> for image
<zyga> there's only one dput in the instructions
<pedronis> you need to build from the release branch
<zyga> build what? the .deb?
<pedronis> yes
<zyga> which step is that?
<zyga> I mean, something makes no sense, what's the point of the placeholder
<zyga> if we also upload the real .3
<zyga> are there two ppas?
<pedronis> the placeholder is not meant for upload
<pedronis> it exist for the next automatic edge build
<zyga> so are you saying step 9 is to build the release branch again, not master?
<pedronis> yes
<cmatsuoka> mborzecki: aha, I think that's missing in my workflow
<zyga> but gpb refuses to build from a release branch
<pedronis> maybe that's the patch is about
<pedronis> anyway right now we have in image a build of master
<zyga> no, the patch is about debian being a symlink
<pedronis> which I dont think we want
<zyga> I agree, but that's "just" edge, right?
<zyga> the question now is to decipher what to do to get the real .3
<pedronis> core-beta builds from the image ppa
<pedronis> so I think we need somehow to upload the right thing there
<pedronis> though now it might get confused
<pedronis> because we have a 2.45.3 already
<zyga> it's a ppa, we can remove a package on demand
<zyga> I think I botched the release :/
<cachio> zyga, so .3 is almost ready right?
<zyga> cachio: no
<pedronis> snapd is ready
<pedronis> but core not
<zyga> cachio: it's somewhat in a mixed state for core
<cmatsuoka> mborzecki: hmm, is setting UBUNTU_IMAGE_SNAP_CMD to the new snap binary enough? If it is, I'm doing it
<pedronis> zyga: so you say gdp-buildpackage doesn't work for a branch?
<zyga> pedronis: I can dpkg-buildpackage -S
<zyga> pedronis: yes, it's a part of the git buildpackage scheme
<zyga> you build from master
<pedronis> and then magic?
<zyga> you have several other branches that represent upstream and patch queue
<zyga> master contains the imported orig tarball
<zyga> and applied patches
<zyga> I don't understand how it's used here
<zyga> maybe there's a config file we're missing
<zyga> I can build a regular source package without gbp
<zyga> but at this point we're drifting from the instructions
<zyga> pedronis: I use gbp in a toy package I maintain
<zyga> but that package has real .orig tarballs and separate packaging git and upstream git
<zyga> looking at what dpkg-buildpackage -S produced it looks like a valid source release
<mup> PR snapcraft#3231 opened: file utils: rename get_tool_path() to get_snap_tool_path() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3231>
<zyga> shall we remove the .3, dput that and try again?
<pedronis> zyga: yes, what we there is master, the diff is full of 2.46 stuff
<zyga> ok, starting with package removal
<pedronis> zyga: gpd-buildpackage has something called --git-ignore-branch and something called --git-export=TREEISH that might help
<zyga> requested
<zyga> pedronis: I think we need to ask mvo about this, I don't see what gbp is doing here, there are no orig tarballs anywhere
<zyga> perhaps that's just something mvo does out of a habit
<zyga> once he is back, that is
<zyga> it's a native package so there's no orig anyway
<zyga> ok, dputting real .3 now
<zyga> hmm, the source package is 148MB
<zyga> something is bonkers
<pedronis> do you have a cache or something odd in your tree?
<zyga> it contains .git
<pedronis> that ended up in the source?
<pedronis> mmh
<zyga> yes
<pedronis> I suppose that's something gdp-buildpackage doesn't do?
<zyga> that's one particularly descriptive source package
<zyga> yeah, gbp exports the tree (which is the imported orig tarball and all changes as exported quilt) and builds that
 * zyga tries something 
<zyga> gbp buildpackage -S --git-ignore-branch
<mup> PR core#115 opened: live-build/hooks: add chroot hook to rm cloud-init config file we don't want <Created by anonymouse64> <https://github.com/snapcore/core/pull/115>
<zyga> the config file for gbp is in debian/gpb.conf
<pedronis> is that ignore working?
<zyga> it's still running
<pedronis> I suppose without it fails earlier?
<zyga> yes, it doesn't do anything
<zyga> ok, it finished
<zyga> 3.3M source package
<zyga> we need to wait for the package to be removed though
<zyga>  File snapd_2.45.3.tar.xz already exists in Packages used in constructing the Ubuntu Core component of Snappy, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors.
<zyga> removing is async
 * zyga looks
<zyga> https://help.launchpad.net/Packaging/PPA/Deleting
<zyga> this claims we need to wait for up to 6 hours now
<zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+delete-packages?field.name_filter=snapd&field.status_filter=&field.series_filter= shows the wrong package was deleted 13 minutes ago
<zyga> I think for now that's that :/
<zyga> I can dput again in the morning
<zyga> or at night, 6 hours is probably maximum, so on average it will be 3 hours away
<zyga> we may get it removed before midnight
<ijohnson> cachio: cmatsuoka: so here's a log of uc20 nested boot where we get random reboots with additional systemd logging https://pastebin.ubuntu.com/p/7ftJpJJbzt/
<ijohnson> cachio: as expected, the reboots don't all happen at the same or similar points in time, it seems entirely random to me
<ijohnson> if you grep for `Linux version 5.4.0-42-` in that log, you will see all the spots were the system was rebooted
 * zyga tries to rest for a few hours
<zyga> will be back at midnight
<zyga> o/
<cmatsuoka> ijohnson: so, just after it gets a link-local address?
<cmatsuoka> ijohnson: could you run it again to see if the log is similar?
<ijohnson> cmatsuoka: well that's one such reboot
<ijohnson> cmatsuoka: sure I can run it again
<cmatsuoka> ijohnson: are you running that locally? could you check if there are any strange messages at hypervisor level? maybe it's something that's not visible by guests, it's the VM that power cycled
<ijohnson> cmatsuoka: I'm running it on GCE
<cmatsuoka> ah ok
<cmatsuoka> so we'll never know
<ijohnson> cmatsuoka: afaik this behavior never happens outside of gce
<cmatsuoka> ijohnson: ok, only now I saw the sequence of reboots, it seems pretty random to me
<cachio> ijohnson, checking
<ijohnson> cachio: cmatsuoka: https://github.com/snapcore/snapd/pull/9065 is what I have been running locally to look at the logs
<mup> PR #9065: debug: forward systemd journald output to serial console when booting for uc20 <Precious Logs> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9065>
<cachio> ijohnson, it is 100% random
<ijohnson> yeah
<cachio> ijohnson, I also tried in a different cloud provider
<cachio> and I saw the same reboots error
<ijohnson> cachio: did you reproduce in a different cloud ?
<cachio> yes
<ijohnson> woah weird I didn't realize that
<mup> PR snapd#9065 opened: debug: forward systemd journald output to serial console when booting for uc20 <Precious Logs> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9065>
<cachio> thas's why I am trying to change the servers
<cachio> and this kind of configuration because I think it is related to the architecture
<ijohnson> hmm interesting
<ijohnson> cmatsuoka: when you get a chance, mind taking a really quick look at https://github.com/snapcore/snapd/pull/8998 again ?
<mup> PR #8998: tests/cmd/snap-bootstrap/initramfs-mounts: add test case for empty recovery_mode <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8998>
<cmatsuoka> ijohnson: sure, just let me collect some debug messages from the cmdline building code to see why snapd thinks the ubuntu-boot grub assets are not managed
<ijohnson> k, no rush
<pedronis> ijohnson: I reviewed #9035
<mup> PR #9035: o/devicestate: save seeding/preseeding times for use with debug seeding api (3/N) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9035>
<ijohnson> pedronis: thanks I will address that feedback, we should have a 3rd person look at it, since I modified the code too I don't think my +1 is appropriate
<pedronis> ijohnson: yes
<mup> PR snapcraft#3229 closed: errors: introduce HostToolNotFoundError exception <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3229>
<mup> PR snapd#9066 opened: o/ifacestate: fix bug in snapsWithSecurityProfiles <Created by pedronis> <https://github.com/snapcore/snapd/pull/9066>
<mup> PR snapcraft#3230 closed: lifecycle: check for snap using shutil.which() <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3230>
#snappy 2020-07-28
<mup> PR snapcraft#3226 closed: extensions: kde-neon: use gtk3 platform theme on gtk-based DE's <bug> <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3226>
<mup> PR snapd#9067 opened: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<mborzecki> morning
<zyga> hello
<zyga> I tried to dput the .3 release again at 4AM but it was rejected, - the orig tarball is not removed from te ppa yet
<zyga> I wonder if we could ask someone from launchpad for help
<zyga> I can upload the signed release somewhere so that after the turmoil ends someone else can dput it
<zyga> mborzecki: ^
<mborzecki> zyga: hey, what do i need to dput it?
<zyga> I've sent a copy to maciek
<zyga> you need dput
<zyga> the magic line is
<zyga> dput ppa:snappy-dev/image snapd_2.45.3_source.changes
<zyga> brb, let me get a shower
<zyga> I'm leaving at 11:30
<zyga> I can try to dput now
<zyga> and maybe you can ask in #launchpad
<zyga> if they can somehow speed up the removal / garbage collection of the 2.45.3 release leftovers
<zyga> I will dput now
<zyga> dput always works if the release is valid
<zyga> but an email sent later
<mup> PR snapd#9068 opened: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9068>
<zyga> tells you if you were successful or not
<zyga> I fear the email goes to me
<zyga> as I signed the release
<zyga> I just got another rejected message
<zyga> ok, afk again, I will try to manage the shower now
<mborzecki> via email?
<zyga> and double check my bag
<zyga> yes
<Saviq> mborzecki: hey (late reply) - no, Multipass does not plug removable media, what's the use case?
<mborzecki> Saviq: hey, a scenario when you build a snap using snapcraft & mutipass, and your source tree is somewhere under /media, that would not work currently, would it?
<Saviq> mborzecki: it should, we're re-confining the mount process
<Saviq> mborzecki: ah hmm, but the `multipass` app will barf on trying to mount b/c of ENOPERM
<mborzecki> Saviq: that's what i was suspecting, but i'm trying to mount something locally now
<Saviq> mborzecki: https://github.com/canonical/multipass/issues/1598 btw
<mborzecki> Saviq: btw. can you try to mount something, unmount and mount the same path again? does it work for you?
<mborzecki> Saviq: https://paste.ubuntu.com/p/vYptW9MPPB/ pretty sure it worked once, i could see content under ~/Home in the vm
<Saviq> mborzecki: worked just fine
<Saviq> nothing in your log suggests it didn'tâ¦
<mborzecki> Saviq: hmm for some reason ~/Home was empty, i can try a look into that later
<mup> PR snapd#9069 opened: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9069>
<mborzecki> the tumbleweed images are broken apparently
<mborzecki> 2020-07-27T21:56:14.0598453Z 2020-07-27 21:56:14 Server google:opensuse-tumbleweed-64 (jul272153-296516) is taking a while to boot...
<mborzecki> 2020-07-27T21:57:13.1611691Z 2020-07-27 21:57:13 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (jul272153-296356): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (jul272153-296356)
<ijohnson> mborzecki: I approved https://github.com/snapcore/snapd/pull/9019, but it seems it needs a merge from master to pick up some fixes
<mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
<mborzecki> ijohnson: thanks, let me update it now
<pedronis> ijohnson: hi, I reviewed #9063
<mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
<ijohnson> hi pedronis thanks, let me take a look
<pedronis> ijohnson: also #9067
<mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<pedronis> ijohnson: I answered to some of mborzecki comments to #9063 with my input
<mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
<ijohnson> thanks pedronis makes sense
<ijohnson> pedronis: I wonder if we should have the api for debug seeding use *time.Time in the response, that would make the JSON not include things like `0001-01-01T00:00:00Z` for some cases, it would slightly complicate the logic to test for nil, but maybe that would be good
<pedronis> ijohnson: I thought of that, and is a bit cleaner, otoh it's a debug api, but if you want to do that, it's ok with me
<ijohnson> I was just looking at the case for classic system that was not preseeded, and the time result is very confusing actually, 2562047h47m16.855s is actually like 292 years so I'm a bit confused how we got that result
<ijohnson> I would have expected in that case an output like `seeding-time: -` because we don't actually have in the state.json how long seeding took
<pedronis> we have seed-time
<pedronis> but not seed-start-time
<pedronis> there might be a few more cases where the client code needs to ignore values
<ijohnson> sorry when I said `seeding-time: -` I meant `seeding-completion: -`
<ijohnson> so what would you expect `seed-completion` to show in that case where we don't have a seed-start-time ?
<pedronis> ijohnson: yes, my point is, we have had seed-time since long time
<ijohnson> I mean at the end of the day this is a debug command
<ijohnson> if it shows weird things on unsupported scenarios it's probably ok
<pedronis> yes, otherwise I would say either ? or -
<pedronis> or we need to think if we can guess a start-seed-time but it gets weird
<ijohnson> I will timebox it, if I can fix it in 10 minutes I will fix it, otherwise classic / non-preseeded systems will just be buggy with this command
<pedronis> why classic?
<pedronis> you just mean older systems without all the values, no?
<ijohnson> yeah sorry that's what I mean
<pedronis> ah ok
<ijohnson> I just said classic cause I can test this case easily on my classic system
<ijohnson> BTW when was SeedTime added ?
<ijohnson> err
<ijohnson> seed-time
<pedronis> I would need to check
<ijohnson> was that a long long time ago sufficient that I can probably assume it will always be there ?
<pedronis> ijohnson: I think it was added when we added the 2h delay for classic
<pedronis> but it will take me a bit to confirm because the code has been moved around
<pedronis> so blame doesn't give an immediate result
<ijohnson> that's ok, I will assume it's always there and if it's not I think the code will just do "-" anyways I think
<pedronis> ijohnson: Mar 2018
<pedronis> so bionic times
<ijohnson> mmm seems old enough to me to say that it will always be there
<ijohnson> for a debug command at least
<pedronis> yes
<mborzecki> ijohnson: https://github.com/snapcore/snapd/pull/9064 spread jobs are close to finishing, we should restart it once more to make sure that caching of snapd snap job works
<mup> PR #9064: .github/workflows: move snap building to test.yaml as separate cached job <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
<mborzecki> ijohnson: and btw the artifact is available already
<ijohnson> mmm nice
<ijohnson> so probably it shows up after the first run, and if you restart it, it doesn't discard that one from the UI
<mborzecki> pedronis: https://github.com/snapcore/snapd/pull/9066 i think this one can be merged now, the failure on arch is unrelated (actually got 408 from the store)
<mup> PR #9066: o/ifacestate: fix bug in snapsWithSecurityProfiles <Bug> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9066>
<ijohnson> ok, made all the local changes, seems it took a bit longer than 10 minutes but meh
<mup> PR snapcraft#3232 opened: build providers: install apt-transport-https <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3232>
<mborzecki> cachio: hey, tumbleweed images seem to be broken, were they updated recently?
<ijohnson> pedronis: #9067 is updated with your feedback addressed
<mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<cachio> mborzecki, hey, yes, yesterday
<cachio> do you have a link to see the error?
<mborzecki> cachio: 2020-07-28 11:10:01 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (jul280906-365867): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (jul280906-365867)
<mborzecki> this is all i get
<mborzecki> cachio: looks like they are not booting at all?
<cachio> yes
<cachio> I can revert the image
<ijohnson> mborzecki: did you restart spread on #9064 ? if so then the caching didn't work
<mup> PR #9064: .github/workflows: move snap building to test.yaml as separate cached job <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
<mborzecki> ijohnson: no, i haven't
<cachio> mborzecki, let me take a look first
<ijohnson> mborzecki: ah ok
<ijohnson> mborzecki: I will re-run spread after the current round of runs finishes
<ijohnson> to ensure that the caching works
<mborzecki> ijohnson: ok
<mborzecki> hope the queue is not stuck again
<ijohnson> mborzecki: no all the jobs are in progress, I just saw you approved, and wasn't clear if you approved because you saw the cacching work after restarting it or not
<pedronis> mborzecki: thx, merged, I will prepare a backport a bit later
<cachio> mborzecki, I see 2020-07-28T13:00:33.756313+00:00 localhost systemd-vconsole-setup[3050]: syntax error, unexpected ERROR
<cachio> 2020-07-28T13:00:33.758590+00:00 localhost systemd-vconsole-setup[3049]: /usr/bin/loadkeys failed with exit status 1.
<mborzecki> cachio: that's on the console with updated image?
<cachio> mborzecki, yes
<mup> PR snapd#9066 closed: o/ifacestate: fix bug in snapsWithSecurityProfiles <Bug> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9066>
<Gargoyle> Hi.
<Gargoyle> Why won't you fix your mailserver?
<mborzecki> quick errand to pick up the pi4
<mborzecki> re
<mborzecki> geee restarted the spread job in #9006 since the build status was showing like half of jobs queued
<mup> PR #9006: bootloader: compose command line with mode and extra arguments <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mborzecki> now after restart, most of them are complete, and it's not the first time, as if there's some issue reporting job status
<mborzecki> cachio: fwiw the tumbleweed spread jobs are running again, have you reverted the image?
<cachio> mborzecki, yes
<mborzecki> cachio: cool, thank you!
<cachio> I am creating a new image to test
<cachio> mborzecki, yaw
<cachio> ijohnson, cmatsuoka hey
<cachio> I see hte new logs https://paste.ubuntu.com/p/F5HvDdvvnW/
<cachio> and the reboots are related to this error ide_atapi_cmd_error
<cachio> look at line 1578
<cachio> also I see this: vmport: unknown command 56
<ijohnson> cachio: ah that's really interesting I bet that's related
 * ijohnson afk for break
 * cachio lunch
 * ijohnson considers getting a specific boot for kicking github actions more
<mup> PR snapd#9070 opened: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <https://github.com/snapcore/snapd/pull/9070>
<cmatsuoka> cachio: ah interesting
<pedronis> mborzecki: ijohnson: backport ^
<pedronis> ijohnson: mmh, #9070 is running a differen set of tests?
<mup> PR #9070: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <https://github.com/snapcore/snapd/pull/9070>
<ijohnson> pedronis: hmm ?
 * ijohnson looks
<ijohnson> woah what
<pedronis> maybe I'm just confused, and some haven't been added yet?
<pedronis> we haven't pushed changes to actions to 2.45
<pedronis> also Maciej's previous PR today had all the tests
<ijohnson> I'd say let's just wait to see what happens
<pedronis> this looks fine: https://github.com/snapcore/snapd/pull/9069
<mup> PR #9069: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9069>
<cachio> cmatsuoka, I am running now with more specific traces
<cachio> to see if I can find something else
<cmatsuoka> cachio: nice, I'm checking that unknown command to see what that could be
<ijohnson> pedronis: ah ok, so after the unit test runs passed, I see all the spread ones show up now too
<pedronis> ok, just me confused
<pedronis> good
<ijohnson> pedronis: so I think the UI is just slow to show them all
<ijohnson> pedronis: it might have something to do with those checks not being required for the release branch
<ijohnson> I dunno though
<mup> PR snapd#8677 closed: cmd/snap, daemon: detect and bail purge on multi-snap <Simple ð> <Test Robustness> <Created by chipaca> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8677>
<pedronis> ijohnson: can you look at #9068, I made a comment but not sure it makes sense or not
<mup> PR #9068: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9068>
<ijohnson> sure I can look but I'm no SELinux expert
<ijohnson> thanks for the reviews pedronis
<cachio> cmatsuoka, I reproduced this as well
<cachio> https://paste.ubuntu.com/p/FcBqbvC4jj/
<mup> PR snapcraft#3222 closed: fix typo <bug> <Created by snshn> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3222>
<mup> PR snapcraft#3223 closed: sentry: don't report tool missing errors <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3223>
<ijohnson> cachio: can you resolve the conflicts in https://github.com/snapcore/snapd/pull/8558?
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<cmatsuoka> cachio: I think the log is not in the last paste
<cmatsuoka> it's one level of indirection away
<cachio> ijohnson, I think I'll close that one and open this in small ones
<ijohnson> cachio: ack sounds goof
<ijohnson> *good
<mup> PR snapcraft#3171 closed: snap: debug enabled by default <do-not-merge> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3171>
<cmatsuoka> cachio: could you try with -machine q35,vmport=off
<cmatsuoka> cachio: the unknown vmport command should be only a debug message, it doesn't seem that the crash is related to it but that property disables vmport
<cachio> surew
<cachio> cmatsuoka, running
<cmatsuoka> cachio: my expectation is that it will still crash, but you won't see the vmport message in logs
<mup> PR snapd#9069 closed: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9069>
<cmatsuoka> cachio: these are the known vmware i/o port commands, they go from 0 to 43: https://sites.google.com/site/chitchatvmback/backdoor
<cachio> checking
<mup> PR snapcraft#3147 closed: Use `pylxd` instead of `lxc exec` <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3147>
<mup> PR snapcraft#3156 closed: log: trace HTTP connections with developer debug <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>
<mup> PR snapcraft#2890 closed: extensions: add opengl extension to support classic and strict <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2890>
<cachio> cmatsuoka, well, with the vmport=off the command error is not shown anymore
<mup> PR snapcraft#2413 closed: kernel plugin: introduce a _get_kernel_version() helper <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2413>
<cachio> cmatsuoka, do you have all the parameters for -machine?
<mup> PR snapd#9070 closed: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9070>
<cmatsuoka> cachio: I used the qemu-system(1) man page to see the parameter list
<cachio> cmatsuoka, I am testing some specific parameters for intel machjnes
<cmatsuoka> cachio: did you get any new logs when the vm crashes?
<cachio> cmatsuoka, yes, but all is similar
<cmatsuoka> ah ok
<mup> PR snapd#9071 opened: release: 2.45.3.1 <Created by pedronis> <https://github.com/snapcore/snapd/pull/9071>
<mup> PR snapd#9072 opened: packaging: add placeholder changelog for 2.45.3.1 <Created by pedronis> <https://github.com/snapcore/snapd/pull/9072>
<pedronis> ijohnson: I re-prepared the release ^
<mup> PR snapd#8499 closed: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8499>
#snappy 2020-07-29
<mup> PR snapcraft#3233 opened: travis: set cla check as final stage <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3233>
<az> https://forum.snapcraft.io/t/get-snap-package-and-dependencies-size-before-installing/19135
<az> https://forum.snapcraft.io/t/how-to-get-dependencies-and-reserve-dependencies-for-a-sanp-package/19134
<mborzecki> morning
<pedronis> mborzecki: hi, seems we got a new strange centos failure? https://github.com/snapcore/snapd/pull/9068
<mup> PR #9068: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9068>
<mborzecki> pedronis: hi, hmmm that's weird
<pedronis> it's not related to your change but yes
<mborzecki> huh, /sys/fs/cgroup/unified really isn't there
<mup> PR snapd#9006 closed: bootloader: compose command line with mode and extra arguments <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
<mup> PR snapd#9068 closed: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9068>
<mborzecki> pedronis: systemd was switched to use default-hierarchy=legacy
<pedronis> interesting
<mup> PR snapd#9071 closed: release: 2.45.3.1 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9071>
<mup> PR snapd#9072 closed: packaging: add placeholder changelog for 2.45.3.1 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9072>
<pedronis> mborzecki: I merged the various release related branches, and I uploaded the release source package
<pedronis> to the ppa
<mborzecki> pedronis: great, thank you for working on it
<mborzecki> let's see what the build will contain
<mborzecki> as for centos8, something is off, there is a changelog entry for systemd, but the switch to legacy was back in 2018 in version 239-7
<pedronis> mborzecki: the changelog here now looks right: https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<pedronis> let's say how the build goes
<mborzecki> we still have the named systemd hierarchy
<pedronis> s/say/see
<mborzecki> pedronis: hmm, the diff is large
<mborzecki> ah right, it's a diff between 2.45.3 upload (whic was really master) and 2.45.3.1
<mborzecki> and it removes things that were on master, so looks legit
<pedronis> mborzecki: are you blocked on me on something atm?
<mborzecki> pedronis: no, i'm good
<mborzecki> quick errand, delivery
<mborzecki> or not
<pedronis> mborzecki: when you have a moment, could you review #9067 ? (UC20 related)
<mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<mborzecki> pedronis: yeah, have it open since yesterday :/
<pedronis> mborzecki: so amd64 build worked, but we have some build failures (test timeouts)
<mborzecki> retry?
<pedronis> yes, that's what I'm doing
<pedronis> there's quite a bit of conflicts merging back into master :/
<mborzecki> pedronis: #9063 is not waiting for anything, we can land it right?
<mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
<pedronis> mborzecki: I think so
<pedronis> mborzecki: btw there were few changes on master to arch PKGBUILD hope they aren't mandatory
<mborzecki> pedronis: i can take a look when you open the 2.45->master merge branch
<mup> PR snapd#9063 closed: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9063>
<pedronis> mborzecki: there's 20 files in conflict, might take a while
<doko> please could somebody have a look at the snapd autopkg test regressions triggered by dpkg?
<mborzecki> doko: do you have a link to the test?
<doko> mborzecki: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<mborzecki> hmm that should be an easy fix hopefully
<mborzecki> quick errand, this time for real
<mup> PR snapd#9073 opened: release: 2.45.3.1 <Created by pedronis> <https://github.com/snapcore/snapd/pull/9073>
<mborzecki> re
<mborzecki> doko: this should be fixed in 2.45.3
<mborzecki> and .3.1 too
<mup> PR snapd#9074 opened: bootloader: extend managed assets bootloader interface to compose a candidate command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9074>
<mborzecki> pedronis: do you know how the vendor, no_vendor tarballs get generated for the github releases page?
<pedronis> mborzecki: not really, but I would imagine no vendor can be created with git archive maybe?
<mborzecki> pedronis: hm my guess it's from slicing the tarball we have in LP, mvo usually uploaded those after the builds were done
<pedronis> mborzecki: do we have a tarball in LP?
<mborzecki> pedronis: there's the source tarball that was uploaded for build
<pedronis> there is, that has vendor in though
<mborzecki> ha, w8 i think i got something
<ijohnson> morning folks
<ijohnson> seems that #9063 was landed without some of the changes that I made in #9035
<mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding ð> <Run nested> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9063>
<mup> PR #9035: o/devicestate: save seeding/preseeding times for use with debug seeding api (3/N) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9035>
<ijohnson> shall I merge master into #9035 or just open a separate PR to make for simpler git history ?
<ijohnson> 9035 is also green, so perhaps that would be quickest to just get another +1 to that PR
<mborzecki> ijohnson: hey, i'll take a look
<ijohnson> thanks mborzecki
<mborzecki> ijohnson: maybe you could do a pass over #9074
<mup> PR #9074: bootloader: extend managed assets bootloader interface to compose a candidate command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9074>
<ijohnson> it's just two patches after pedronis' review fixing error message and tests
<ijohnson> mborzecki: sure I will add it to my queue
<mborzecki> ijohnson: oh, and i fixed the caching & artifact
<ijohnson> mborzecki: yes I saw that, thanks for keeping up with that
<ijohnson> seems my idea last night was a bit too naive
<mborzecki> fwiw 33MB of a snap is ok to fit in the cache ;)
<mborzecki> wonder how large the files can be and if we can use that in an interesting ways maybe
<pedronis> mborzecki: did you find out how to make those tars?
<mborzecki> pedronis: sorry, yes, there's a release-tools/repack-debian-tarball.sh script in snapd source tree which does the slicing and stitching
<mborzecki> pedronis: ./repack-debian-tarball.sh snapd_2.45.3.1.tar.xz will produce 3 tarballs
<pedronis> ah, good
<mup> PR snapd#9035 closed: o/devicestate: save seeding/preseeding times for use with debug seeding api (3/N) <Preseeding ð> <Created by stolowski> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9035>
<mup> PR snapd#9075 opened: daemon/api: use pointers to time.Time for debug seeding aspect <Preseeding ð> <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9075>
<ijohnson> thanks mborzecki I just merged it
<ijohnson> and opened the final bit for snap debug seeding, 9075, which is very simple
<mborzecki> ijohnson: https://github.com/snapcore/snapd/pull/9067#discussion_r462261549 little tweak
<mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<ijohnson> mborzecki: thanks! I will take that into a followup I think since this is green
 * ijohnson really likes how green things are to master as of late 
 * ijohnson (with much kicking of github actions)
<mup> PR snapd#9067 closed: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
<mup> PR snapd#8558 closed: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
 * cachio afk -> buy a medicine
<ijohnson> pedronis: #8867 is sudo git mergable, the tests that failed are unrelated, but we could also try to make it green with a master merge
<mup> PR #8867: interfaces: add uinput interface <Needs Samuele review> <â Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8867>
<pedronis> ijohnson: did you look at it, it changed a bit since it was last reviewed by others but me?
<ijohnson> pedronis: sorry no I didn't, do you want me to do another review since it changed ?
<pedronis> ijohnson: yes, also maybe a master merge is in order, though I think is quite self contained
<ijohnson> pedronis: ok, I will do a master merge and review it then
<pedronis> ijohnson: thank you
<ijohnson> pedronis: I approved that PR and merged master there
<mborzecki> cmatsuoka: hmm i forgot we have ModeRun/ModeRecover in the boot pacakge
<mup> PR snapcraft#3233 closed: travis: set cla check as final stage <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3233>
<ijohnson> 8-line test only PR that only needs 1 more +1: https://github.com/snapcore/snapd/pull/8998
<mup> PR #8998: tests/cmd/snap-bootstrap/initramfs-mounts: add test case for empty recovery_mode <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8998>
<ijohnson> also pedronis do you need me to review 9073 too ?
<pedronis> mborzecki: :)
<pedronis> ijohnson: yes if you can
<ijohnson> pedronis: ack will do
<mborzecki> cmatsuoka: btw can you try your branch with the code from #9074 ?
<mup> PR #9074: bootloader: extend managed assets bootloader interface to compose a candidate command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9074>
<ogra_> do we still have the limitation that content interfaces can only be consumed if both snaps come from the same publishr (by default that is ... ) ?
<ijohnson> ogra_: that limitation is only about _auto-connection_
<ijohnson> ogra_: you can have a content interface from snap from publisher A and another snap from publisher B use that content snap, but either you need to get an auto-connection from the store or make the connection manually
<ogra_> okay, thanks ... i guess that means a store-request then
<mup> PR snapcraft#3231 closed: file utils: rename get_tool_path() to get_snap_tool_path() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3231>
<mup> PR snapcraft#3234 opened: project loader: refactor errors to conform to SnapcraftException <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3234>
<mup> PR snapcraft#3235 opened: tests: fix assert ordering for error format tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3235>
<mup> PR snapd#8867 closed: interfaces: add uinput interface <Created by jdstrand> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8867>
<mup> PR snapcraft#3225 closed: specifications: default tracks <specification> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3225>
 * cachio kinesiologist
<mup> PR snapcraft#3236 opened: snap: use python3-apt stage-package <maintenance> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3236>
<mup> PR snapd#8932 closed: o/ifacestate: update security profiles in connect undo handler <Bug> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8932>
#snappy 2020-07-30
<mup> PR snapd#9073 closed: release: 2.45.3.1 <Created by pedronis> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9073>
<mborzecki> morning
<mup> PR snapd#9075 closed: daemon/api: use pointers to time.Time for debug seeding aspect <Preseeding ð> <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9075>
<pedronis> hello
<pedronis> gah
<mborzecki> pedronis: hey
<pedronis> mborzecki: hi, can we chat after the desktop meeting?
<mborzecki> pedronis: yes
<mborzecki> pedronis: that unit test failure is only when building debs?
<mborzecki> pedronis: i don't see it locally
<mup> PR snapd#9076 opened: interfaces: make the unmarshal test match more the comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/9076>
<pedronis> mborzecki: I opened this ^
<pedronis> to tweaks the test because it wasn't actually testing what it said, but also add more debugging
<mborzecki> pedronis: interesting, spread tests don't complain either, do you have more of a log where the failure occurred?
<pedronis> mborzecki: there's only false,
<pedronis> that's why I did we need more debugging
<pedronis> see my PR
<pedronis> *I think
<mup> PR snapd#9076 closed: interfaces: make the unmarshal test match more the comment <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9076>
<mup> PR snapd#9077 opened: boot: add current recovery systems to modeenv <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9077>
<mborzecki> pedronis: ^^
<mup> PR snapd#9078 opened: [RFC] boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<pedronis> mborzecki: thx, finishing lunch break and then I will look
<pedronis> mborzecki: I reviewed #9074 , I dismissed Ian's review though becuase it has changed in some significative ways
<mup> PR #9074: bootloader: extend managed assets bootloader interface to compose a candidate command line <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9074>
<mborzecki> damn gofmt
<mborzecki> pedronis: thanks for the review, i'll poke ijohnson or cmatsuoka when they are online
<mborzecki> pedronis: #9077 should hopefully be easy
<mup> PR #9077: boot: add current recovery systems to modeenv <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9077>
<pedronis> yes, I will look at it next
<mborzecki> cmatsuoka: hey, do you have the script for booting in secure mode? something does not work in my setup and i'm not sure why
<cmatsuoka> mborzecki: sure, just a sec
<mborzecki> it's clearly doing something because the vm is significantly slower and getting stuck on low entropy occasionally
<cmatsuoka> mborzecki: https://paste.ubuntu.com/p/mRHs9rx5QM/
<cmatsuoka> mborzecki: don't forget to re-sign shim with the snakeoil key
<cmatsuoka> mborzecki: this is Ian's script to do that: https://paste.ubuntu.com/p/4CczzWSHzR/
<mborzecki> cmatsuoka: thanks!
<mborzecki> cmatsuoka: which ovmf do you use?
<mborzecki> (i mean version)
<cmatsuoka> mborzecki: the one from the focal archive
<mborzecki> cmatsuoka: hmm so it should be the same, idk i'm getting dropped to efi shell now
<cmatsuoka> mborzecki: I'll check my steps here after the SU
<mup> PR snapcraft#3237 opened: spread: use host pip <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3237>
<ijohnson> seems I forgot to leave lunch mode yesterday haha
<cmatsuoka> mborzecki: dropping to efi shell happened to me if I didn't re-sign shim IIRC
<mborzecki> cmatsuoka: ok, that would make sense, another question then, where do i get that snakeoil cert/key? or do you have a scipt to generate a custom one
<cmatsuoka> mborzecki: it's in the ovmf package
<mborzecki> ijohnson: can you take a look at https://github.com/snapcore/snapd/pull/9077 ?
<mup> PR #9077: boot: add current recovery systems to modeenv <Simple ð> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9077>
<ijohnson> mborzecki: sure
<ijohnson> mborzecki: you can also get that snakeoil cert/key from the gadget snap repo in snapcore/pc-amd64-gadget
<mborzecki> ijohnson: cmatsuoka: thanks, i see it in the ovmf package
<mborzecki> heh funny how that package ships usr/share/OVMF and usr/share/ovmf
<mborzecki> ofc both directories have differnt content
<mborzecki> and a key with a password
<cmatsuoka> it's "snakeoil"
<mborzecki> yup, found that in docs
<mborzecki> hmm still getting dropped to efi shell
<mborzecki> btw. there's a problem with lxd tests, they reach kill timeouts, no matter the host (ubuntu, fedora etc)
<mborzecki> yay, works with secure boot now
<cmatsuoka> \o/
<mborzecki> cmatsuoka: i didn't have unit=0, unit=1 for the CODE/VARS entries, although code was listed first
<mborzecki> hmmm Retrieving image: rootfs: 1% (99.00kB/s)
<cmatsuoka> mborzecki: what's the thing about gofmt 1.9 in the Modeenv struct initialization?
<cmatsuoka> I mean, what does it complain about?
<mborzecki> cmatsuoka: gofmt changed the maximum line length around 1.9/10 iirc, so 1.n+1 formatting is different from earlier versions
<cmatsuoka> ah ok
<mborzecki> cmatsuoka: or not the max line length, but the maximum empty whitespace run, something like that
<mborzecki> wow, gcp is also getting same downlaod speeds of lxd images: Retrieving image: rootfs: 3% (95.97kB/s)
<mborzecki> wasn't there like a different remote rpeo we could use to get the images?
<cmatsuoka> mborzecki: I had this kind of download rate with snaps some time ago, and it possibly triggered that write loop issue
<zyga-x240> mborzecki: yes but it has different images
<zyga-x240> mborzecki: ubuntu/foo
<zyga-x240> mborzecki: vs foo IIRC
<zyga-x240> mborzecki: those images don't have snapd and have other tweaaks
<zyga-x240> *tweaks
<mborzecki> zyga-x240: hm well, the ubuntu repo is super slow atm, tests are failing
<zyga-x240> try lxc remote list
<zyga-x240> there are images/ubuntu-abc
<zyga-x240> and there's ubuntu/foo
<zyga-x240> and ubuntu-daily/foo
<zyga-x240> IIRC images is very fast
<mborzecki> zyga-x240: it is, but our tests don't use that ;)
<zyga-x240> they could but they would need to be adjusted to cope with the different environment
<cachio> cmatsuoka, about the reboots
<cachio> cmatsuoka, could be possible we are rebooting the instace because of a race?
<cachio> cmatsuoka, is it possible to track that?
<mborzecki> wonder what's causing the load on cloud-images.ubuntu.com, boothole updates?
<cmatsuoka> cachio: in our side? I don't think we're doing it
<zyga-x240> mborzecki: IIRC it was never fast
<cmatsuoka> cachio: otherwise it would log something, there it looks like the VM is simply "power-cycled"
<zyga-x240> it was just some what okay
<cachio> cmatsuoka, yes, makes sense
<cachio> trying a new configuration now, I had 1 run without any reboot
<cachio> but perhaps it was just lucky
<cachio> I was
<ogra_> jdstrand, so it looks like we wont need any specific pcscd interface at all ... just an approved content interface (i.e. https://forum.snapcraft.io/t/auto-connections-for-pcsc-daemon/19170 ) should be enough ...
<mborzecki> errands, bbl
<ogra_> jdstrand, also https://forum.snapcraft.io/t/module-blacklisting-interface/19171 ...
<ogra_> as requested ð
<ogra_> (and i know you are busy with grub fixing ... so feel free to ignore as needed ð )
 * cachio lunch
<ijohnson> cachio: I think 9027 is probably ready to be merged when it's green
<ijohnson> I responded to your comment there
<mborzecki> ijohnson: meh, hardly anything is green now
<ijohnson> haha yeah probably
<ijohnson> mborzecki: your fancy modeenv marshalling/unmarshalling looks good to me
<ijohnson> mborzecki: I am going to do another pass on 9074 just so I can understand, but feel free to merge without my +1
<mborzecki> ijohnson: thanks, i think it'll be easier to put more complex things there
<ijohnson> yeah
<mup> PR snapd#9074 closed: bootloader: extend managed assets bootloader interface to compose a candidate command line <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9074>
<mup> PR snapd#9079 opened: gadget/install: retrieve command lines from bootloader <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9079>
 * cachio afk
<mup> PR core20#79 opened: Add secureboot-db package, try #2 <Created by xnox> <https://github.com/snapcore/core20/pull/79>
<mup> PR snapd#9077 closed: boot: add current recovery systems to modeenv <Simple ð> <UC20> <Created by bboozzoo> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9077>
<mup> PR snapcraft#3237 closed: spread: use host pip <maintenance> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3237>
<cachio> cmatsuoka, hey
<cachio> I see this error: https://paste.ubuntu.com/p/pFMF5NJdDn/
<cachio> related to tpm
<cachio> is it something expected?
<cmatsuoka> let me see...
<cmatsuoka> cachio: this is strange indeed
<mup> PR snapcraft#3236 closed: snap: use python3-apt stage-package <maintenance> <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3236>
<cmatsuoka> cachio: was it a normal installation run, or did you do something unusual in this test?
<cmatsuoka> (like not clearing the tpm or something like that)
<cachio> I am manually running
<cachio> cmatsuoka, this is the full log https://paste.ubuntu.com/p/MVQCNz4RF3/
<cmatsuoka> cachio: the two error messages are different, so it failed twice?
<cmatsuoka> cachio: the second one suggests that the tpm was not cleared before installing
<cachio> sorry, the second was my fault
<cmatsuoka> the first one is not something i've seen before
<cmatsuoka> is it reproducible?
<cachio> cmatsuoka, https://paste.ubuntu.com/p/zg3gKVQN5C/
<cachio> I am trying again
<cmatsuoka> cachio: the last paste is a tail -f command :)
<cachio> few lines before it is the error
<cachio> this is the full log for that error
<cmatsuoka> cachio: I mean, there's only a tail command in the paste
<cmatsuoka> google-nested:ubuntu-20.04-64 .../tests/nested/core20/tpm# tail -f /tmp/work-dir/serial-log.txt
<cachio> cmatsuoka, perhaps hte error was caused because a reboot
<cachio> https://paste.ubuntu.com/p/zg3gKVQN5C/
<cachio> I see the full log there
<cachio> line 2982
<cachio> cmatsuoka,
<cmatsuoka> cachio: ah ok I got it, sorry
<cmatsuoka> there's a lot of empty lines there
<cmatsuoka> let me see where the reboots happened...
<cmatsuoka> cachio: yes, maybe the crashes placed the tpm in some inconsistent state?
<cmatsuoka> but that shouldn't happen, it's strange
<cachio> cmatsuoka, how should I clean tpm
<cachio> forgot that
<cmatsuoka> you can delete the "permall" file in /var/snap/swtpm-mvo/current
<cachio> thanks
<cmatsuoka> tpm2-00.permall, but I think the number may change if you have more instances
<mup> PR snapcraft#3235 closed: tests: fix assert ordering for error format tests <maintenance> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3235>
<cmatsuoka> cachio: did you reproduce that error?
<cachio> no
<cachio> cmatsuoka, I was running the whole afternoon and didnt see that error again
<cmatsuoka> hm interesting, ok, let me know if that ever happens again
<cmatsuoka> in this case it seems that it was caused by the random reboots, which is also strange but...
<mup> PR snapd#9080 opened: osutil/disks: use xerrors to indicate a fs label wasn't found <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9080>
<mup> PR snapd#9081 opened:  secboot,cmd/snap-bootstrap: cross-check partitions before unlocking, mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9081>
<mup> PR snapd#9082 opened: interfaces/system-key: in WriteSystemKey during tests, don't call ParserFeatures <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9082>
#snappy 2020-07-31
<mup> PR snapd#9083 opened: tests: new parameters nested uc20 <Run nested> <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9083>
<mborzecki> morning
<pedronis> mborzecki: hi
<mborzecki> pedronis: hey
<pedronis> mborzecki: should I force merge 9082 ?
<mborzecki> pedronis: yes, i looked at the failures and they are unrelated
<pedronis> ok
<pedronis> mborzecki: anything else that requires my immediate attention?
<mup> PR snapd#9082 closed: interfaces/system-key: in WriteSystemKey during tests, don't call ParserFeatures <Bug> <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9082>
<mborzecki> pedronis: no i think that's it for now, there's some more review i'll be doing and probably need a 2nd reviewer too
<pedronis> mborzecki: I commented in #9080  and I think #9079 needs a review
<mup> PR #9080: osutil/disks: use xerrors to indicate a fs label wasn't found <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9080>
<mup> PR #9079: gadget/install: retrieve command lines from bootloader <Simple ð> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9079>
<pedronis> mborzecki: did you see my comment/question in #9078?
<mup> PR #9078: [RFC] boot: fancy marshaller for modeenv values <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<mborzecki> pedronis: yes, i've finished the change and ii'll be pushing that in a couple of minutes
<pedronis> ok
<mborzecki> pedronis: goconfigparser is something we keep bundled like other deps right?
<pedronis> mborzecki: in which sense?
<mborzecki> pedronis: ah ok, it's vendored like everything else, for minute there i thought we were moving it around in the tree
<mborzecki> pedronis: anywyas, the trouble it we need to land a fix in goconfigparser for json to work
<pedronis> :/
<pedronis> we package it at least for debian afaict: golang-github-mvo5-goconfigparser-dev
<mborzecki> it's confused by [] in lists
<pedronis> ah, because the section stuff
<pedronis> doesn't have ^$ ?
<pedronis> I was wondering about that, also not sure why it's like that
<mborzecki> oerheks: yes, regexp.MustCompile(`\[(?P<header>[^]]+)\]`), but should be regexp.MustCompile(`^\[(?P<header>[^]]+)\]`)
<mborzecki> pedronis: ^^
<pedronis> mborzecki: fedora has:  Provides:      bundled(golang(github.com/mvo5/goconfigparser))
<pedronis> not sure what that means
<mborzecki> pedronis: i've updated #9078 and opened https://github.com/mvo5/goconfigparser/pull/6
<mup> PR #9078: [RFC] boot: fancy marshaller for modeenv values <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9078>
<mup> PR mvo5/goconfigparser#6: configparser: fix section header regex to not interfere with JSON data <Created by bboozzoo> <https://github.com/mvo5/goconfigparser/pull/6>
<mborzecki> Eighth_Doctor: hey, any clue what changed in rawhide recently that could break building go binaries statically? the usual set of flags does not build a static bin anymore, heck even -ldflags=-extldflags=-static does not
<Eighth_Doctor> ugh
<Eighth_Doctor> Go 1.15 landed
<Eighth_Doctor> you probably should file a bug report about this
<mborzecki> Eighth_Doctor: hm -buildmode pie used to trigger external linker, but it does not anymore, i need to explicitly pass -linkmode external to get what i want
<Eighth_Doctor> Go compiler upstream doesn't really have a concept of "stability" here
<mborzecki> heh
<ijohnson> morning folks
<cachio> ijohnson, hello
<ijohnson> hi cachio
<cachio> good morning
<ijohnson> hey cmatsuoka
<cmatsuoka> ijohnson: hi, good morning
<ijohnson> cachio: something like https://pastebin.ubuntu.com/p/MB9Qh36xkd/ should work for you to run nested jobs via github actions nightly
<ijohnson> I didn't filter for all the relevant jobs, so that just runs all nested suites on 20.04, but that should be easy to fix with spead, etc.
<ijohnson> s/spead/spread/
<cachio> yes
<cachio> now I am comparing the times with and without kvm
<cachio> ijohnson, so then I can adjust the workers needed to run when we use the "Run nested" label
<ijohnson> right
<cachio> thanks for the code, I'll add that to the PR that I am creting
<cachio> creating
<cachio> ijohnson, what I am testing now is to add more cores when kvm is not used
<cachio> perhaps that help as well
<ijohnson> ah true, I remember that bug, yes having more cores should help us I think
<ijohnson> mborzecki: pedronis: I sent an invite for next week to brainstorm about bootstate refactorings/improvements before we add resealing to the mix there
<mborzecki> ijohnson: ack
 * cachio lunch
<cmatsuoka> ijohnson: with L1 focal it boots correctly, and then strange things happen
<ijohnson> interesting, strange things as in similar strange things we see on GCE ?
<cmatsuoka> it didn't reboot, but it locked. I wonder if GCE has a watchdog for such cases
<cmatsuoka> I'll keep it locked to see if it still reboots after some time
<cmatsuoka> in the meantime I'll look for my cell phone, I think lost it
<ijohnson> interesting one thing we don't know is when the machine reboots vs when it hangs from output to the serial file
<ijohnson> cachio: it would be good to also add the debug output of the serial log for a nested VM when we fail to prepare, currently the debug-each I have that shows the boot log only runs if the execute section is where we fail
<ijohnson> cachio: i.e. from this log, I can't see the serial boot log of the nested VM
<ijohnson> https://github.com/snapcore/snapd/pull/9083/checks?check_run_id=930252395
<mup> PR #9083: tests: new parameters nested uc20 <Run nested> <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9083>
<cmatsuoka> ijohnson: it's really freezing at random points during the boot process, and I think it could be possible that GCE is rebooting the machine if it reaches that state
<ijohnson> cmatsuoka: ahhh very interesting
<cmatsuoka> maybe we could display an RTC  timestamp at the very beginning of userspace to measure the time between reboots?
<pedronis> ijohnson: sorry, but I xerrors.Errorf is more meant to stack errors that comes from other packages, than to label own errors but making it nested on the spot, that is a bit odd
<pedronis> s/but making/by making/
<ijohnson> pedronis: sorry I was just trying to do the easy thing with less code but I can make an Error type
<pedronis> ijohnson: yes, but in this case the easy thing is also a bit odd :)
<ijohnson> well the error isn't currently surfaced to the user anywhere and we have much more confusing errors coming from the initramfs so I just shrugged when writing the code
<ijohnson> but it appears that shrugging was not justified
<pedronis> ijohnson: no, in general we should try to improve our errors, I had cmatsuoka remove some nesting on some secboot errors for example
<cmatsuoka> yep, at a certain point it becomes too verbose and not very informative
<pedronis> anyway when writing a ErrorMatches test it's always a chance to consider if the error is ok, can be improved
<ijohnson> Sure
<cmatsuoka> ijohnson: watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [systemd-modules:210]
<cmatsuoka> https://paste.ubuntu.com/p/9hsS2jHhc8/
<pedronis> ijohnson: I re-reviewed #8917
<mup> PR #8917: osutil/disks: add mock disk and tests for happy path of mock disks <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8917>
<cachio> ssh ijohnson I'll add that
<pedronis> do we print the go version we use to build the snapds in the spread tests?
<ijohnson> cmatsuoka: ah good find, I was about to say what we could try is some kind of fifo that qemu logs the serial log to, where at the other end of the fifo we prepend the real host (well L1) time stamps for each line that was output to the log
<ijohnson> cachio: thanks
<cmatsuoka> ijohnson: adding timestamps is a good idea
<ijohnson> pedronis: thanks, I responded to one point about checking the uniqueness of the dev strings, unfortunately we can't enforce that from MockMountPointDisksToPartionMapping
<cmatsuoka> ijohnson: I think ts(1) does exactly that
 * ijohnson is always learning about new tools that do exactly what I think of without complicated shell scripts :-)
<cmatsuoka> ubuntu@nested-test:~$ uname | ts
<cmatsuoka> Jul 31 13:25:59 Linux
<pedronis> ijohnson: I see, I made a comment, I'm not sure we want to go there but well disks are actually complicated
<ijohnson> pedronis: sorry I didn't understand, where are you not sure we should go there ?
<pedronis> ijohnson: my suggestion in the new comment
<ijohnson> let me look
<ijohnson> sorry I still don't understand, how could we have a single MountPoint map to multiple MockDiskMappings ?
<ijohnson> which one would be used ?
<ijohnson> pedronis: ^
<pedronis> ijohnson: sorry, let me stare at this more carefully, there is something odd here for sure
<ijohnson> cmatsuoka: mmm for the purposes of debugging spread runs I wonder why we even need a file for the serial log, we could just have qemu have serial go to stdout and then pipe that through ts, and that just goes to journald because we run qemu through systemd-run ?
<ijohnson> pedronis: ok I will wait to push any more patches to the mockdisk PR until we are aligned
<pedronis> ijohnson: I see
<pedronis> ijohnson: made this make more sense: https://github.com/snapcore/snapd/pull/8917/files#r463717116
<mup> PR #8917: osutil/disks: add mock disk and tests for happy path of mock disks <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8917>
<pedronis> heh, maybe this makes more sense
<ijohnson> pedronis: so then you mean to check if the pointers to MockDiskMapping are different, and if the pointers are different that they have unique DevNum strings ?
<pedronis> yes, though I really probably mean to use map and to take pointers, taking values of MockDiskMapping is odd
<pedronis> it's not a very valuey struct
<pedronis> to me
<ijohnson> cachio: cmatsuoka: I pushed this: https://github.com/snapcore/snapd/pull/9065/commits/05fe6d8f383396e6a53d2cb70739e4c632b483f4 if it is useful I will submit a separate PR for that
<mup> PR #9065: debug: forward systemd journald output to serial console when booting for uc20 <Precious Logs> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9065>
<ijohnson> pedronis: mmm ok
<pedronis> ijohnson: I mean, go for example will not let you compate two of them
<pedronis> *compare
<pedronis> that makes it non valuey in my book
<ijohnson> pedronis: the only reason they are not comparable is because they have a map in them
<pedronis> ijohnson: yes
<ijohnson> which perhaps is your whole point
<pedronis> partly yes
<ijohnson> mmm alright I can do that then I don't think anything should be broken doing it this way
<pedronis> ijohnson: yes, I don't think it should mess too much with your downstream PRs
<pedronis> maybe a few more & somewhere
<ijohnson> pedronis: ok updated 9080 and 8917
<pedronis> ijohnson|lunch: re-reviewed, closer but not quite
<ijohnson> yes I saw
 * pedronis is also a bit melting here
<pedronis> ijohnson: sorry this is becoming a bit an adventure in the ontology of disks
<ijohnson> haha it's ok
<ijohnson> let's just remember to squash merge everything otherwise we will inevitably have to relive this ontology
<pedronis> ijohnson: +1 on 9080
<ijohnson> \o/
<pedronis> I changed the summary as well
<ijohnson> ah yes I suppose that is now out of date
<ijohnson> s/is/was/
<pedronis> ijohnson: reviewed 8987 as well, one small thing (which I should have mentioned before :/ )
<ijohnson> pedronis: you mean 8917 ?
<ijohnson> ah yes I see
<cmatsuoka> ijohnson, cachio: I think I tweaked the configuration enough to have the nested machine working with ovmf on my local amd, but I'll do some more tests and try to minimize the amount of changed variables
<ijohnson> nice!
<cachio> cmatsuoka, nice
<cachio> I am still testing with no kvm
<cachio> is not so bad
<cmatsuoka> cachio: there are two independent things that cause problems here: smp and rng passthrough
<cmatsuoka> if I disable rng passthrough and set smp to 1, it tends to be much more stable
<cachio> cmatsuoka, how did you disabled rng passthrough?
<cmatsuoka> cachio: I removed  "-object rng-random,filename=/dev/hwrng,id=rng0 -device virtio-rng-pci,rng=rng0" from the parameter list, but it depends on you having these parameters already or not
<cachio> in my last pr I added that
<cachio> but didnt see much change with or without it
<cmatsuoka> I had to remove it here, otherwise I get a consistent crash
<cachio> if I disable kvm the test takes about 8 minutes more to run
<cmatsuoka> so it seems that from my original set of parameters, if I set -smp 1 and remove rng passthrough it works, but my L0 host is a Ryzen7
<cmatsuoka> I'll try with a generic host to see if it still works
<cmatsuoka> cachio: this is what worked for me: https://paste.ubuntu.com/p/yZhhrFBwBR/
<cachio> it is pretty similar to what we use on nested on google
<cmatsuoka> yes, I changed more parameters initially then I placed them back to find which ones were actually causing the problem
<cachio> bu you run kvm
<cmatsuoka> but it could depend on the version of their L0 host and cpu as well
<cachio> I am runnign qemu with kvm enalbed
<cachio> I think it is the same
<cmatsuoka> and this is L0 focal + L1 focal
<cmatsuoka> it's more likely that they have L0 bionic (+patches maybe) + L1 focal
<cachio> yes
<cachio> who knows
<cmatsuoka> 8 minutes more is not that bad if it's reliable
<cachio> cmatsuoka, seems to be acceptable
<cachio> I am running 2 tests together to see the time
<ijohnson> yah 8 minutes is acceptable to me
<cachio> ijohnson, cmatsuoka updated #9083
<mup> PR #9083: tests: new parameters nested uc20 <Run nested> <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9083>
<cachio> with the no kvm scenario
<ijohnson> nice thanks cachio
<cachio> ijohnson, yaw, let see the action results
#snappy 2020-08-01
<mup> PR snapd#9080 closed: osutil/disks: use a dedicated error to indicate a fs label wasn't found <Squash-merge> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9080>
#snappy 2020-08-02
<portd> sent here. hello
<portd> trying to install Snappy Core on disk.
<portd> okay so I want to live-mount my home directory where I have large downloads on my system. is that not what Snappy is for?
<portd> can anyone explain âWhy is #Snappy?â
